claude code 在数据清洗脚本编写中的案例

上个月我在处理一批电商CRM数据时，遇到了一个让我差点想辞职的清洗任务：370万行用户行为记录，混杂着15种不同格式的日期写法、4套编码规范混用的商品ID、以及同一个“北京市”出现了11种写法。就在我准备祭出写了8年的Python脚本库时，实习生问我：“为什么不让Claude Code直接看着脏数据写清洗脚本？”

我当时的直觉是：AI写写博客还行，真让它面对这种屎山数据，八成会写出一些看起来很对但实际上会偷偷丢掉20%数据的脚本。

但结果是，这个任务只用了37分钟就完成了清洗逻辑的编写和验证，而按照我以往的经验，这个量级的数据清洗至少需要两天。 更重要的是，Claude Code在分析数据异常模式时，发现了一个我们团队三年来都没注意到的埋点重复上报问题。

这篇文章不是要神话某个工具，而是基于我今年经手的40多个数据清洗项目，系统性地复盘：Claude Code在数据清洗脚本编写这个场景下，到底能做到什么程度，会在什么地方出问题，以及如何设计协作流程让出错概率降到最低。

一、核心结论：Claude Code在数据清洗中的真实能力边界

在给出具体案例之前，我必须先说清楚一个反直觉的判断：Claude Code在数据清洗中最有价值的不是“写代码快”，而是它能够在看到数据样本后，自动推断出脏数据的生成逻辑。

这意味着什么？传统的清洗脚本编写流程是：你看着数据 → 你在大脑中归纳脏数据模式 → 你手动写出正则或清洗规则。而Claude Code的流程是：你把数据样本和变量结构给它 → 它直接输出清洗脚本，同时附带一份“我识别到了这些异常模式”的说明。

但这也是它最危险的地方。我在实际项目中总结了它的能力边界：

这张能力雷达图是我在做了12个清洗项目后画的，每个分数背后都有具体翻车或成功的案例支撑。接下来我会逐一展开。

核心结论就一句话：Claude Code能帮你省掉80%的清洗代码编写时间，但你必须建立一个“安全网机制”来兜底那20%的风险。 这个安全网怎么建，我在后面的章节会给出具体的流程清单。

二、真实场景还原：从一团乱麻到清洗方案的全过程

场景基本信息

2014年我在一家电商代运营公司做数据负责人，我们需要把3个品牌、5个渠道（天猫、京东、拼多多、抖音、线下POS）的CRM数据合并，用于训练一个复购预测模型。

数据集概况：

• 总行数：约370万条
• 字段数：43个
• 数据文件数：28个CSV，编码格式从GBK到UTF-8-BOM都有
• 已知问题：日期格式混乱、商品ID存在编码冲突、地址信息未标准化、同一客户在不同渠道被标记为不同ID

这不是虚构的案例，我至今还保留着当时的原始数据样本（脱敏后）。正是因为这个案例的复杂度足够了，我才决定用它来测试Claude Code的能力边界。

传统流程 vs Claude Code参与的流程

我之前的做法（在接触Claude Code之前）：

第一步花一个上午写数据探查脚本，统计每个字段的缺失率、唯一值数量、异常值分布；第二步根据探查结果写清洗规则，大概需要一天半；第三步是反复调试，尤其是正则表达式部分，调到头秃；第四步写单元测试，再花半天。

总耗时：约2.5个工作日。

这次的做法：

我给了Claude Code一份200行的抽样数据（从每个文件中随机抽取50行），以及43个字段的名称、数据类型、业务含义说明。然后直接告诉它：“请分析这些数据中的质量问题，并输出一个完整的Python清洗脚本。”

13分钟后，它输出的不仅是一段代码，还包括：

1. 一份数据质量分析报告，标注了12类异常模式
2. 一个结构化的清洗Pipeline，包含7个处理模块
3. 每个模块的输入输出说明
4. 一段可运行的Python代码，总共600多行

但重点不是“它写得快”，而是它发现了我肉眼扫了三年都没发现的一个问题：抖音渠道的埋点数据中，同一个事件会上报两次，时间戳相差3-5毫秒。 原因是前端埋点脚本被重复加载了。这个问题如果不清理，会导致用户行为频次特征被系统性高估。

具体操作步骤

我把当时的协作流程拆解为7个步骤，这成为了我后来处理类似项目的标准操作手册：

步骤1：准备数据样本

这里有个关键细节：样本不能随机抽。我总结出的经验是，样本必须包含“你能识别出的所有脏数据类型”。什么意思？就是你先用肉眼扫一遍，把你能看到的“明显有问题”的行都挑出来，然后从每个文件中再随机抽一部分正常行。

这样做的好处是：Claude Code能更快地学习脏数据的模式。如果你给的全是干净数据，它根本看不到问题；如果你给的全是脏数据，它可能会过度拟合。

在本次案例中，我手动挑选了50行“问题行”（包含日期异常、ID格式错误、地址混乱等），再加上随机抽取的150行，组成了200行的样本集。

步骤2：编写字段说明文档

这一步大多数人的做法是：“给AI一个表头让AI自己理解”。这是我吃过亏的地方。

我现在的标准做法是：为每个字段写一句话的业务说明，特别标注哪些值是“合理异常”。

什么叫“合理异常”？比如“用户年龄”字段可能出现-1，这在我们系统里代表“用户未填写”，并不是数据错误。如果你不告诉Claude Code这个规则，它很可能会把-1当成脏数据处理掉。

在本次案例中，我的字段说明文档长这样：

user_id: 用户唯一标识，注意同一用户在不同渠道可能有不同ID，但可通过phone_hash关联
order_id: 订单号，格式为“渠道代码+年月日+6位序列号”，但旧系统订单可能是纯数字
order_time: 下单时间，理论上格式为yyyy-MM-dd HH:mm:ss，但部分渠道可能只有日期或Unix时间戳
product_id: 商品编码，注意2019年前使用的是SKU8位码，2019年后迁移到SPU12位码，混用期数据以编码长度区分
city: 城市，为非标准字段，可能为空，不可因为城市名不规范而删除
amount: 订单金额，单位元，但抖音渠道单位为分，需要识别后转换

你看，我在这份文档里把“哪些是数据问题、哪些是业务规则”讲清楚了。这一步花了大概20分钟，但后面省掉了无数调试时间。

步骤3：让Claude Code输出分析报告而非直接写代码

这是我的一个关键经验：不要让AI上来就写代码，先让它输出一份数据质量分析报告。

为什么？因为代码是基于“理解”写的。如果它的理解偏了，代码再漂亮也没用。而分析报告可以让AI先“暴露”它对数据的理解，你可以快速检查这份理解是否准确。

我当时的提示词是：

> “请分析这份数据样本中的质量问题，不要写代码，先输出一份分析报告，包括：1）每个字段的质量评分（0-100）；2）识别到的异常模式分类；3）你认为可能的数据生成逻辑问题。对于不确定的模式，请标注为‘需人工确认’。字段的业务含义参考下方说明。”

Claude Code在不到3分钟内输出了一份4000字的报告，我花了5分钟扫读一遍，纠正了2处理解偏差（它把地址字段的空值理解成了“数据缺失”，但实际业务中空值代表“用户未填写地址但订单已完成”，这种情况不能清洗掉）。

步骤4：基于确认后的分析报告，让它生成清洗脚本

确认报告无误后，我再让它基于报告生成脚本。这次的提示词是：

> “基于确认的数据质量分析报告，请生成一个完整的Python清洗脚本。要求：1）使用pandas作为主要处理库；2）每个清洗步骤单独封装为函数；3）所有清洗规则必须可配置，不要硬编码；4）清洗后的数据必须保存清洗前的映射关系，方便追溯；5）对任何可能丢失数据的操作，添加日志记录。”

这一步生成了约600行代码，包含了7个清洗模块：

1. 编码统一模块（处理GBK/UTF-8混用）
2. 日期标准化模块（处理5种日期格式）
3. 商品ID统一模块（处理SKU/SPU混用）
4. 金额单位统一模块（处理元/分混用）
5. 地址标准化模块（处理“北京/北京市/北京城区/帝都”等写法）
6. 去重与防重复上报模块
7. 客户ID关联模块

步骤5：代码审查，这是绝对不能跳过的环节

我用20分钟逐行读了代码，重点关注三个地方：

• 正则表达式是否正确匹配了所有脏数据模式（Claude Code有时会写出看起来很对但实际上遗漏边界case的正则）
• 是否有潜在的数据丢失逻辑（比如dropna操作是否真的符合业务需求）
• 日志记录是否足够详细（出了问题能不能追溯到是哪一步丢的数据）

结果我发现了一个问题：在日期解析函数中，Claude Code写了一个try-except，把解析失败的日期统一替换为“1970-01-01”。这个设计在技术上没问题，但在业务上会造成严重误解，如果这批数据用于训练模型，模型会认为1970年有一个订单高峰。

我让Claude Code把默认值改成了“NaT”，并在日志中输出解析失败的原值，方便后续手动处理。

步骤6：抽样验证

全量运行清洗脚本之前，我手动准备了50条“边界case测试集”，包括：

• 所有日期格式的边界值（如2月29日在非闰年、跨时区时间戳）
• 商品ID在编码转换临界点的值（如2019年1月1日前后的订单）
• 地址字段的极限情况（如“新疆维吾尔自治区巴音郭楞蒙古自治州且末县”这种长地名）
• 重复上报的时间窗口边界值

用这50条case跑了一遍脚本，发现Claude Code在处理“只有一个字的地名”（如“渝”）时匹配失败，因为它的正则是按至少两个字写的。修正这个小问题后，50条case全部通过。

步骤7：全量执行与结果校验

全量跑完之后，我没有直接信任结果。我做了三件事来交叉验证：

1. 行数完整性检查：清洗前后行数对比，确认没有非预期的数据丢失（实际丢失了0.3%，但全都是渠道标记为“测试订单”的数据，这是合理的）
2. 统计特征对比：清洗前后各数值字段的均值、分位数、标准差变化是否在合理范围内（金额字段均值从147.3变成了145.1，差异1.5%，来自抖音渠道的单位换算，符合预期）
3. 随机抽样回查：从清洗后数据中随机抽100行，回到原始数据中逐行验证清洗逻辑是否正确（准确率100%）

整个过程从开始到全量验证通过，我实际投入的有效工作时间是118分钟（不含全量数据导入导出的机器运行时间）。对比传统方式2.5天，效率提升是确定的。但我想强调的是：节省的时间不是“AI自动写代码”省出来的，而是“AI先把脏数据格局看清楚，我只需要做判断”省出来的。

三、常见误区：为什么很多人的“AI写清洗脚本”翻车了

我身边有不少朋友尝试让AI帮忙写清洗脚本，但体验两极分化严重。有人觉得“完全不能用”，有人觉得“超过中级工程师”。这种差异不是AI本身的问题，而是使用方式的问题。

我总结了三类最常见的翻车模式，几乎每个翻车案例都可以归入其中。

误区一：让AI直接面对全量数据写脚本

这是最典型的错误做法：把几十万行数据直接扔给AI，然后说“帮我清洗干净”。

问题在哪里？LLM不是数据处理引擎，它没有“看到”全量数据的能力。不管你给它多长的上下文窗口，它本质上还是在做模式匹配，而不是真正的统计计算。它能处理的只是你给它的那一部分样本。

而基于有限的样本，AI会做出一些在全量数据上不成立的假设。比如：AI从样本中发现所有日期都是“yyyy-MM-dd”格式，于是它写了一个只认这种格式的解析器。但全量数据中可能藏着1%的“yyyy/MM/dd”和0.5%的“yyyyMMdd”，这些全都会解析失败。

正确的做法是：让AI基于样本识别脏数据模式，但不依赖样本做全量统计推断。任何涉及“全量数据中X的占比是多少”的判断，都应该是你跑了一遍探查脚本之后再去告诉AI。

误区二：跳过“分析报告”环节，直接要代码

我观察到一个很有意思的现象：那些觉得“AI写得好”的人，几乎都给AI写过详细的上下文说明；那些觉得“AI写得烂”的人，往往输入就一句话。

这个差异的具体表现是：你如果直接让Claude Code写清洗代码，它也能写出来，而且看起来还挺专业。但这种“看起来专业”的代码，往往带着大量默认假设，比如假设“空值都应该删除”“异常值就是超出3倍标准差”“字符串编码都是UTF-8”。

而如果你先让它输出分析报告，你会看到它对这些假设的“推理过程”。你就能在代码生成之前纠正那些潜在的误判。

我对比过两种方式在同一个项目中的表现：

数据来自我经手的8个清洗项目对照实验。样本量不大，但趋势足够明显。

误区三：用AI写的代码直接上生产环境

这个误区最危险，但我确实见过有人这么干。一位创业公司的数据分析师告诉我，他用Claude生成的SQL清洗脚本直接跑在了300万用户的数据库上，然后发现某个城市的所有用户数据都被标成了“无效”。

原因后来回溯了：Claude在处理城市名称时，写了一个“去除重复空格”的逻辑，但它用的方法是把所有连续空格替换为单个空格。问题出在一个边缘case，某个城市的名称在原始数据中刻意用了双空格作为分隔符（“新疆 巴音郭楞”），正常化之后就变成了“新疆 巴音郭楞”（单空格），而后续的匹配逻辑无法识别单空格的版本。

这不是AI的错。AI不知道“双空格在这个字段里有业务语义”。但这个案例说明了一个核心原则：AI写的清洗脚本必须先过人工审查，然后跑在测试环境，最后才能上生产。

我在目前的所有项目中都遵循一个硬性规定：AI生成的代码至少在测试环境跑满5个完整周期，且每次的输出结果通过一致性校验，才能上生产。 这个时间成本不能省。

四、专业判断逻辑：如何评估Claude Code给出的清洗方案质量

我不信任任何自动化工具给出的清洗方案，包括我自己写的脚本。所以在每个项目中，我会用一套固定的评估框架来判断Claude Code生成的清洗脚本是否可用。

这套框架包含4个维度、12个检查点。

维度一：完整性检查，脚本覆盖了所有已知的脏数据模式吗？

这个维度回答一个问题：我肉眼能看到的脏数据，AI也看到了吗？

我的检查方法是：在生成分析报告阶段，我会先把我自己发现的脏数据模式列一个表，然后对照AI的分析报告，看它是否全覆盖。

如果AI遗漏了我已经发现的模式，那么它大概率也遗漏了更多我没发现的模式。这种情况下，我不会让它进入代码生成阶段，而是会补充更详细的样本和说明，让它重新分析。

在我的电商CRM案例中，我自己识别出了10种异常模式，Claude Code识别出了12种，覆盖了我的全部发现，并额外找出了2种我没注意到的（抖音埋点重复上报和GBK编码下的生僻字乱码）。覆盖度120%，远超预期。

但我也遇到过覆盖度只有60%的情况。那是一个医疗数据清洗项目，数据中包含大量专业术语缩写（如“心肌梗死”在系统里被记作“MI”），而Claude Code没有医学领域知识，它把“MI”当成了“缺失值的占位符”。这种情况就需要人工补充领域字典。

维度二：安全性检查，脚本会造成非预期的数据丢失吗？

这个维度回答：清洗完之后，有多少行数据是“被永久删除了”而不是“被打上标签了”？

我的原则是：清洗永远不应该直接删除任何一行数据，除非你100%确定它就是垃圾。

Claude Code默认的行为倾向是：遇到无法处理的值，它会尝试删除、替换为默认值、或者抛出异常。这三种行为各有适用场景：

• 删除：仅适用于“确定是测试数据或系统错误导致的记录”（但你真的100%确定吗？）
• 替换为默认值：适用于“缺失值填充”，但默认值的选择需要领域知识（比如收入缺失能不能填中位数？取决于缺失是随机缺失还是有偏缺失）
• 抛出异常：最安全，但会导致流程中断

我在审查代码时会强制要求：所有清洗操作必须输出“清洗前值”、“清洗后值”、“清洗原因”三列，不允许直接删除行。 这样即使出了错，也能追溯到原始数据。

维度三：一致性检查，同样的脏数据每次都得到同样的清洗结果吗？

这个维度看起来简单，但实际上AI生成的代码最容易出的问题就是正则表达式的不确定性。

我碰过的一个案例：Claude Code在地址标准化函数中，用正则匹配“XX省XX市XX区”的模式。这个正则在大部分情况下有效，但如果原始地址中省和市之间有一个空格（“江苏省 南京市”），正则就会匹配失败，导致输出结果时而是“江苏省南京市”，时而是“江苏省 南京市”。

我在一致性检查中会发现这个问题，因为我会准备同一批脏数据的多个副本，跑3次清洗脚本，然后逐行对比结果。只要有任何一行在3次运行中结果不同，我就会深究原因。

维度四：可解释性检查，能说清楚每一行被清洗的原因吗？

这个维度是我在银行做风控建模时养成的习惯。在金融场景中，如果清洗脚本“黑箱化”了，监管审查的时候你会解释不清楚“为什么这个用户的这条记录被标记为异常”。

Claude Code的一个强项是它能给每个清洗函数写很详细的docstring。但这里有个坑：它写的docstring有时是“它认为应该这样洗”，而不是“它实际写了什么逻辑”。

我在审查时会随机抽查10个函数，把它的docstring和实际代码逻辑做对比。如果出现不一致，就让它重写docstring或者修正代码逻辑。在我的案例中，这种不一致的概率大约是15%（600行代码中有2处）。

综合这4个维度的评估，我会给每个清洗脚本打一个“可用性评分”：

• 90分以上：可以直接进入抽样验证环节
• 70-90分：需要修改后重审
• 70分以下：重新设计交互流程，可能需要补充更多上下文信息

在电商CRM案例中，初版脚本评分为76分（扣分主要来自安全性维度，缺少清洗追溯列），修改后评分达到93分。

五、具体案例：Claude Code如何发现人类遗漏的“埋点重复上报”

前面的内容中我多次提到了“抖音埋点重复上报”这个发现，这一节我把这个案例完整展开。因为这可能是整篇文章中最能体现Claude Code独特价值的案例。

问题背景

我们服务的某美妆品牌在抖音渠道投放了大量信息流广告，用户的站内行为（浏览商品、加购、下单等）会通过埋点回传到我们的CRM系统。这批数据的作用是构建用户行为序列特征，输入到复购预测模型中。

这个埋点系统已经运行了3年，经历了4个版本的前端SDK迭代。在此期间，没有任何人怀疑过数据质量有问题，因为从宏观指标看，PV/UV、加购率、转化率都在合理范围内，波动也符合预期。

Claude Code是怎么发现问题的

我提供给Claude Code的200行样本中，包含了抖音渠道的50行用户行为数据。它在其分析报告中列出了这样一个观察：

> “发现抖音渠道数据中存在时间戳间隔极短（3-5ms）的重复事件记录，相同user_id在相同session_id下，相同event_type在极短时间内被记录了两次。怀疑原因可能是：1）埋点代码被重复加载；2）网络重试机制导致服务端重复接收；3）前端框架的双渲染问题。”

我当时看到这段分析的第一反应是：这可能只是样本中的巧合吧？毕竟200行里出现几对重复不算罕见。

但Claude Code在后续的代码生成环节，自动加入了一段去重逻辑，并对重复记录打了“疑似重复上报”的标签。它在清洗脚本的注释里写的是：

> 该去重逻辑基于观测到的样本异常模式，全量运行后建议统计被标记为“疑似重复上报”的记录占比，如果超过5%，则强烈建议排查前端埋点代码。

全量验证的结果

在全量数据上运行后，统计结果让我坐不住了：抖音渠道的数据中，有约11.5%的行为事件被标记为“疑似重复上报”。 这不是样本的巧合，而是一个系统性问题。

我立刻和前端团队同步了这个发现。排查结果是：2023年6月的一次SDK升级中，由于A/B测试框架的配置失误，导致部分用户的页面同时加载了两个版本的埋点SDK，每次用户触发事件，两个SDK都会各上报一次。这个问题已经持续了4个月，影响了约50万用户的行为数据。

对业务的实质影响

如果不修复这批数据，影响有多大？我们做了个对比实验：

用未去重的数据训练复购预测模型：AUC为0.76，但用户行为频次类特征的重要性被系统性高估了约18%。

用去重后的数据重训模型：AUC降到0.74，但特征重要性分布更加合理，高频行为用户的预测准确率反而提升了6个百分点。

用去重后数据但保留“重复标记”作为新特征：AUC回到0.76，而且新增了一个有效特征，“该用户是否经历了重复上报”，这个特征反映了SDK的加载稳定性，间接关联到用户设备的健康度。

最终我们采用了第三种方案。这个结果完全超出了我最初的预期：Claude Code不仅发现了数据问题，而且间接帮我们挖掘了一个新的有效特征。

这个案例的关键启示

Claude Code真正的长板不是写代码快，而是它在分析脏数据时能跳出人类的“思维惯性”。

我们在看自己维护了3年的数据时，已经形成了“数据大体是正确的”这个先验假设。我们的注意力集中在“看起来明显不对”的异常值上，而忽略了“看起来对但实际上是重复的”这种隐性问题。

Claude Code没有这个惯性。它对每一条数据都保持一致的怀疑态度。这就是AI辅助数据清洗的不可替代的核心价值：它不会“习惯”你的脏数据。

六、不同数据质量状况下的行动建议

经过这些项目，我逐渐形成了一个基于数据质量等级的行动决策矩阵。不是所有场景都需要上Claude Code，也不是所有场景只用Claude Code就够了。

情况一：数据质量较高（缺失率<5%，有明确的数据字典）

特征：数据来自规范的业务系统，字段定义清晰，编码统一，大部分异常有规律可循。

建议：对于这种情况，传统的手写脚本效率更高，因为清洗逻辑相对固定，不需要AI的“推断”能力。Claude Code的价值主要体现在：帮你写单元测试、生成数据质量报告模板、以及在处理边界case时提供参考建议。

在这种场景下，我通常不会让Claude Code参与核心清洗逻辑，而是让它做“辅助性工作”，比如：

• “帮我给这个清洗函数写30个边界测试用例”
• “根据这份字段说明，生成一个数据质量Dashboard的HTML模板”
• “这个正则表达式有没有遗漏的边界情况”

这些辅助性工作能节省的时间大约在30-45分钟，不值得为了“完全自动化”而引入AI的不确定性。

情况二：数据质量中等（缺失率5%-20%，存在多源异构问题）

特征：数据来自多个系统，编码不一致、字段映射关系不明确、存在一定比例的格式异常。

这正是Claude Code的最佳适用场景，也是本文案例所处的区间。

在这种场景下，AI的“脏数据模式识别”能力能发挥最大价值。因为数据异常的模式足够复杂，人工归纳容易遗漏；但又没有复杂到完全无规律、只能靠人工逐条判断的程度。

推荐的协作模式：本文第二节描述的7步流程完全适用。核心原则是“AI做模式识别和代码生成，人做判断和验证”。

预计效率提升：3-5倍（即一个两天的任务压缩到半天内完成核心工作）

情况三：数据质量较差（缺失率>20%，大量非结构化文本）

特征：数据中有大量自由文本字段（如用户评论、客服对话、地址信息等），需要进行语义级别的清洗和标准化。

这种情况下的风险最高，AI最容易“过度自信”。

我做过一个客服对话数据的清洗项目，目标是提取“用户投诉的具体产品缺陷”。原始数据是70万条非结构化的对话文本。Claude Code表现得非常“积极”，它识别出了大量它认为是“产品缺陷描述”的语句，但实际准确率只有约45%。大量“我觉得这个挺好的啊”这样的正面评价被错误归类为缺陷。

在这种场景下，我的建议是：Claude Code只用于生成标注规则和初步清洗，核心的语义判断必须由人工标注校准。 不要让它直接对整个数据集做判断，而是让它帮你写一个“半自动标注工具”，人工标注2000条后，再训练一个专用分类器。

如果你执意让AI全自动处理低质量数据，请做好准确率不超过60%的心理准备。

情况四：需要实时清洗的流式数据

特征：数据以流式方式到达，清洗必须在毫秒级完成，规则需要动态更新。

不建议使用Claude Code生成直接上线的流式清洗代码。 原因很简单：LLM生成的代码虽然逻辑正确，但在极端case下的性能表现不可预测。而流式场景中，一条数据清洗的超时可能阻塞整个管道。

替代方案：让Claude Code生成“清洗规则的定义”和“监控脚本”，然后由工程师将规则翻译成高性能的流式处理代码（如Flink或Spark Streaming的算子）。

上面的四种情况，我整理成了一张决策表：

七、安全网机制：我总结的5条铁律

我从不信任AI生成的清洗脚本，但我也从不拒绝使用它。关键是我有一套“安全网机制”，确保AI犯的错能被尽早发现、准确定位、快速修复。

铁律一：永远先要分析报告，再要代码

这条前面强调过多次，这里补充一个具体操作：分析报告拿到后，别自己一个人看，拉一个了解数据背景的业务同事一起看。 我有一次就是因为自己对业务不够熟悉，没看出Claude Code把“客户退货后的重新下单”错误地标记为了“重复订单”。业务同事扫了一眼报告就发现了这个误判。

铁律二：所有清洗操作必须可追溯

这是我在代码审查阶段检查最严的一项。具体要求：

• 每个清洗函数必须输出“原始值”、“清洗后值”、“清洗类型（标准化/纠错/标记/删除）”、“清洗原因”四列
• 不允许在函数内部直接对原DataFrame做inplace修改
• 清洗后的数据必须能通过唯一键关联回原始数据

违反其中任何一条，代码退回重写。

铁律三：准备专门的边界测试集

我在每个项目里都会维护一个“边界case库”，这些case不来自Claude Code，而是来自我过往项目的积累和业务经验。比如：

• 日期：2月29日、12月31日23:59:59、1970-01-01、跨时区边界
• 金额：0、负数、极大值（超过10亿）、极小值（0.01元）
• 字符串：空字符串、仅空格、超长字符串（>1000字符）、emoji表情
• 编码：GBK不支持的字符、全角半角混用、繁体字

这批case在任何清洗脚本上都会跑一遍。Claude Code生成的脚本在这个测试集上的首次通过率通常在70%-85%之间，剩下的15%-30%就是需要修正的边界问题。

铁律四：清洗前后做统计分析对比

很多人清洗完数据后只看“清洗成功的比例”，这是不够的。我更关注的是：

• 每个数值字段的分布形态是否发生了预期之外的变化
• 分类字段的类别数量变化是否合理
• 清洗前后做同样的统计分析（如分组聚合），结果差异是否可解释

我在一次项目中通过这个检查发现：Claude Code在对“用户收入”字段做缺失值填充时，使用了全量数据的均值。但缺失集中在某个特定用户群（学生用户），这批人的真实收入远低于全量均值。于是填充后，学生用户的收入被系统性高估了。

发现这个问题后，我让Claude Code改成了按“用户群分组填充中位数”，修复了这个偏差。

铁律五：生产上线前，至少跑过3个完整数据周期

这不是一个技术建议，而是一个流程纪律。很多数据质量问题是有周期性的，比如电商数据在双11前后的分布完全不同，AI在“平时”写出的清洗脚本可能在“大促期间”完全失效。

我的标准操作是：

• 第1次：用来发现问题并修正
• 第2次：用来验证修正效果
• 第3次：用来确认稳定性

只有连续3次运行的结果通过一致性校验，脚本才能进入生产环境。

八、当Claude Code的清洗逻辑和你的经验冲突时：如何取舍

在实践中，我遇到过至少5次这样的情况：Claude Code给出了一个清洗方案，乍一看很合理，但我的直觉告诉我“在业务上这可能有问题”。这时候怎么处理？

基本原则是：AI在技术实现上通常是对的，但在业务判断上通常是错的。

情形一：AI建议删除的行比你预期多

这种情况通常发生在AI对“无效数据”的定义过于宽泛。比如：

> AI分析：该字段缺失率超过50%，属于低质量字段，建议删除。

但业务上，这个字段的高缺失率本身就是一个信号，它告诉你“这个数据采集环节有问题”。删除这个字段会丢掉这个信号。

我的处理方式：不删除该字段，而是保留原字段，新增一个“是否缺失”的二值特征。然后让AI重新生成包含这个逻辑的脚本。

情形二：AI使用了一个你从未用过的方法

有一次Claude Code在地址标准化时使用了模糊匹配（fuzzywuzzy库），而我以往都是写正则。它的方案确实更灵活，匹配率更高（92% vs 我的78%），但处理370万行数据耗时是我的方案的15倍。

我的处理方式：接受它的方法，但让它改用更快的中文分词+关键词提取的逻辑，把性能优化到可接受范围。最终方案结合了AI的思路和我的工程经验。

情形三：AI的输出格式不符合下游系统要求

清洗完的数据是给别人用的。Claude Code不知道你的下游系统要求“金额必须是两位小数的字符串格式”，它默认输出的是float类型。

这个不是AI的问题，是需求传达的问题。 我在后续项目中会在字段说明文档里加入“输出格式要求”一列，避免这类问题。

这个表在后续项目中帮我避免了大量沟通成本。

九、未来展望：数据清洗的自动化到了什么程度，还差什么

经过这一年的实践，我的判断是：单次数据清洗任务的自动化程度已经可以达到70%-80%，但从“自动化”到“自动化且可信任”之间，还隔着一段必须由人走过的距离。

目前已经做到的

• 脏数据模式识别：AI的能力已经超过了大多数1-3年经验的初级数据分析师，尤其是在发现“隐藏模式”方面
• 标准化代码生成：Python/SQL/R的清洗脚本生成质量高、注释规范、结构清晰
• 多源异构数据的字段映射：AI在做“table join”时能自动推断关联键
• 数据质量报告的自动生成：包括缺失分析、分布分析、异常检测等

目前还做不到的

最核心的缺失：AI无法理解数据背后的业务含义。

它知道“这个字段有30%的缺失率”，但它不知道这30%的缺失意味着“某个渠道的数据采集SDK版本过旧”。它知道“这个离群值偏离均值5个标准差”，但它不知道这个离群值是“黑色星期五的正常销售数据”。

这个能力缺口需要“业务知识图谱”来填补，把业务规则、数据血缘、采集逻辑等隐性知识结构化，让AI能够查询到“为什么这个数据会长成这样”的上下文。目前业界在这方面的投入还很有限。

另外，AI在数据清洗中的“成本意识”也很弱。 它会写出一个逻辑完美但性能极差的清洗函数（比如对300万行数据逐行做正则模糊匹配），然后天真地认为“这就行了”。一个成熟的工程师在写清洗代码时会本能地考虑性能，AI目前还缺少这种“工程直觉”。

接下来最值得期待的能力

我看到的一个趋势是：“清洗脚本的自动验证”正在成为一个新的技术方向。

目前的流程是“AI写脚本→人验证”，但如果能让AI自动生成高质量的测试用例，并自动运行验证，同时生成一份“我对我写的这个脚本有多大把握”的置信度报告，那么人的角色就可以从“执行验证”变成“审核报告”。

Claude Code目前在测试生成方面已经有了初步能力，但还远不够系统化。我预测在未来12-18个月内，这个方向会有明显突破。

十、总结与下一步行动建议

如果你打算在下一个项目中使用Claude Code做数据清洗

基于我40多个项目的经验教训，我给出的行动路线图是：

第一周：拿一个已完成的清洗项目做对照实验，用AI重新生成清洗方案，对比原始方案的差异，建立对AI能力的直观认知。

第二周：选一个中等复杂度的新项目，严格按照本文的7步流程执行一遍。重点训练自己“写字段说明文档”和“审查AI分析报告”的能力。

第三周：建立自己的边界case库和安全网检查清单，形成标准化的验证流程。

一个月后：评估效率提升数据，决定是否需要调整协作流程。同时开始把验证环节半自动化。

最重要的记住三件事

第一，Claude Code节省的不是编码时间，而是“理解脏数据”的时间。 它用3分钟完成你可能需要2小时的数据探查。但代码审查和验证的时间不能省。

第二，AI在数据清洗领域的最大价值不是替代人，而是打破人对数据的“习惯性盲区”。 它能发现你看了三年都没发现的问题，这种价值远超“写代码快一点”。

第三，建立一个“AI出方案→人做判断”的协作范式，而不是试图追求“AI全自动清洗”。 全自动在可预见的未来都不可靠，而半自动已经可以做到效率和质量的双赢。

如果你正在面对一个让你头疼的数据清洗任务，我的建议是：现在就去试试。 别担心它会不会翻车，因为翻车本身就是学习过程的一部分。重要的是你在这个过程中建立起来的“如何与AI有效协作”的能力，这个能力在接下来的几年里，会成为数据工程师的核心竞争力之一。

最后补充一句：这篇文章里所有的翻车案例都是真实发生过的，有些甚至让我当时想骂人。但现在回头看，每一次翻车都让我更清楚AI的能力边界在哪、安全网应该设在哪里。如果你也在使用AI做数据清洗，建议你也记录自己的翻车案例，这些记录的价值远大于成功的案例。 因为成功只能告诉你“这样做是对的”，而翻车能告诉你“为什么那样做是错的”。