脏数据清洗规则没人愿意写？我让AI替团队把这件事变成了流水线

作为一个带五个人的小团队负责人，我过去最怕听到的不是“这个需求做不完”，而是“这批数据有点脏，能不能清洗一下再入库”。

脏数据这件事，技术含量不高，但极其消耗人。地址写法五花八门、手机号里混着空格和横线、日期字段既有时间戳又有中文日期、公司名一会带“有限公司”一会带"Ltd"——每次清洗，都是有人在深夜一边骂一边写正则。更让我头疼的是：清洗规则散落在各个临时脚本里，人一离职，规则就跟着消失了。

痛点：清洗规则是团队最隐蔽的技术债

我们盘点过一次，发现问题集中在三点：

第一，规则依赖个人经验。 谁接手数据，谁的判断就是标准。同一条“北京市朝阳区”，A写成北京/朝阳，B保留原文，下游对账时全乱。

第二，规则没有沉淀。 清洗逻辑写在一个用完即弃的 Python 脚本里，下次遇到类似脏数据，又是从零开始。三个月前踩过的坑，三个月后再踩一遍。

第三，规则没法评审。 正则表达式对管理者来说接近天书，我想在上线前把关，实际上只能“信了”。风险完全黑盒。

后来我们把AI引入这条流程，做法不是让AI“直接清洗数据”（数据不出内网是红线），而是让AI批量生成可评审、可版本化的清洗规则。这一步转变是关键。

AI使用流程：四步把清洗规则做成资产

第一步：抽样不外传，只传“模式”。 我们从脏数据里人工挑出每类问题的代表性样本，脱敏后归纳成“问题描述 + 示例片段”，喂给AI。全程不接触原始全量数据，这一条写进了我们的数据安全规范。

第二步：让AI批量生成规则草案。 一条提示词下去，AI按问题类型输出规则：正则表达式、标准化映射表、异常判定逻辑、边界case的处理建议。一次能产出几十条，覆盖我们人工要想两天的量。

第三步：人工评审 + 测试集验证。 这是我作为管理者最看重的一步。AI输出的规则会先跑一遍我们准备好的测试样本（含预期结果），通过的进规则库，不通过的标注原因退回重新生成。AI负责产量，人负责放行。

第四步：规则入库、版本化、写注释。 每条规则带生成时间、适用场景、负责人、测试通过率。新人接手，看规则库就能理解全部清洗逻辑，不用再去翻离职同事的电脑。

可复用的提示词模板

我们内部打磨后的规则生成模板，直接可用：

你是一名数据质量工程师，请为以下脏数据问题批量生成清洗规则。

【数据背景】
数据类型：{如：用户注册信息表}
字段列表：{如：name, phone, address, created_at, company}
数据量级：{如：约50万行}
下游用途：{如：BI报表统计、客户去重}

【已知脏数据问题与示例（已脱敏）】
1. 手机号格式混乱，如：{示例1}、{示例2}
2. 地址缺失行政区，如：{示例}
3. 日期格式混用，如：{时间戳示例}、{中文日期示例}
4. 公司名后缀不统一，如：{示例}

【输出要求】
对每个问题输出：
- 规则编号与问题分类
- 清洗逻辑的中文描述（一句话，便于非技术人员评审）
- 具体实现（正则表达式 / SQL / Python代码，任选标注）
- 无法自动清洗需人工介入的判定条件
- 3个边界case及建议处理方式

【约束】
- 规则必须幂等：重复执行结果一致
- 不得删除原始字段，清洗结果写入新字段
- 每条规则单独输出，便于逐条评审与测试

这个模板的好处是输出天然按“一条问题一组规则”组织，直接对应评审流程，不用二次整理。

前后对比：从黑盒到流水线

成本方面，我们通过API网关调用模型生成规则，花的token远低于直接让AI处理全量数据（因为只送模式不送数据），费用以官网价格页为准，但整体只占我们AI预算很小的比例。

管理者要守住的三个风险控制点

1. 数据不出域。 AI只接触脱敏样本和模式描述，全量清洗在本地脚本执行。
2. AI只出草案，人负责放行。 所有规则必须过测试集才能生效，测试集由人维护。
3. 规则变更走评审。 即使是AI重新生成的规则，替换旧规则也要记录原因，避免下游口径悄悄漂移。

写在最后

清洗规则这件事，过去是团队里没人认领的隐形债务，现在是我们数据流水线的第一站。AI在这里的角色不是替人清洗数据，而是把“生成规则”这个最枯燥的环节的产能拉满，让人把精力放在评审和口径把关上——这恰好是管理者真正可控的部分。

如果你的团队也在被脏数据消耗，不妨先从搭建这条“AI出规则、人来放行”的流水线开始。想动手试试的话，可以先注册一个API账号：https://api.thistoken.ai/register，把上面的提示词模板跑起来，第一批规则草案当天就能出来。

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。