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

去年十一月，我收到了运营团队丢过来的一份Excel，标题是“全渠道销售明细_初步整理版.xlsx”，文件大小237MB，行数大约52万条。他们的需求听起来很简单：“把数据弄干净，下周要上BI大屏，数据源必须可靠。”我打开文件后，第一眼就看到了六种不同的日期写法、手机号列里混杂着座机和空字符串、“退款金额”列里出现了“已取消”这样的文本，甚至还有几十行明显是测试数据。按我以往的经验，这种规模的数据清洗任务，如果纯粹手写Python脚本，从分析、编写、调试到最终稳定输出，即使在高度专注的情况下，也需要至少一个半到两个工作日。但那一次，我决定换一种工作方式，全程用Claude Code辅助完成。最终，从接收原始文件到交付可复用的清洗流水线，总共耗时不到5个小时，并且产出的脚本结构清晰、注释完整、容错能力极强。这篇文章，就是把那次真实经历，连同我这大半年以来在多个数据清洗项目中深度使用Claude Code的观察、判断、取舍和方法论，一次性讲透。

一、核心结论：Claude Code改变的不是“要不要写代码”，而是“怎么写代码”

很多人第一次听说用AI写数据清洗脚本时，脑海里浮现的画面是：把脏数据扔进一个对话框，AI直接吐出一份干净的数据。这是彻底的误解，也是导致后来骂“AI根本不行”的根源。我在实际工程中得到的核心结论非常明确：

Claude Code在数据清洗脚本编写中的真实价值，不在于替代人类决策，而在于将“数据理解→清洗逻辑设计→代码实现→验证调试”这个循环的每一次迭代成本，从半小时级压缩到分钟级，同时显著降低低级错误出现的概率。

这本质上是一种人机协作的范式迁移。传统模式下，我拿到一堆脏数据，需要用pandas或PySpark手动写探查代码，肉眼观察输出，然后构思清洗逻辑，再逐段编写处理缺失值、异常值、格式统一、去重、关联验证的脚本，中间还要反复查阅文档确认某个函数的边界行为。而借助Claude Code，我可以直接用自然语言描述当前看到的数据问题，并给出业务约束，让Claude Code在完整的上下文里生成第一版脚本；接下来我只需要像代码审查一样快速判断逻辑是否正确，马上就能在真实数据子集上跑起来验证。如果出错，我把错误信息贴回去，Claude Code能在几秒内定位到问题并给出修正。这个极短的反馈闭环，彻底改变了脚本编写的效率曲线。

为了把这个结论说清楚，我需要先还原一下数据清洗的真实场景和常见误区。

二、背景和真实场景：数据清洗绝不是“删删空值、改改格式”那么简单

在外行眼里，数据清洗是一个机械劳动：找到空值删掉、把日期格式统一、去个重就完事了。但真正干过数据分析工程的人都知道，清洗环节往往是整个数据链路里心智负担最重的部分。因为脏数据的产生是业务系统设计缺陷、人为操作失误、多方数据源口径不一致、历史数据迁移丢失等复杂因素的共同结果，每一个字段的清洗逻辑背后，都对应着一条必须理解的业务规则。

以那份52万行的销售明细为例，真正棘手的问题包括：

• 时间戳跨时区且来源混杂：部分订单记录的是下单客户端本地时间，部分记录的是服务器UTC时间，还有一部分是仓库出库扫描时间，但列名全都叫“order_time”。如果不做时区归一化，统计出来的每日GMV完全不可用。
• 退款金额有文本、正负数意义不明：系统A导出的退款用正数表示，系统B用负数，人工补录的直接写了“已退款”。清洗时必须先统一符号规范，再将文本转为结构化标记，否则聚合计算必定炸掉。
• 手机号格式五花八门：有带国际码的、有不带的、有中间加横杠的，而且约4%的行手机号长度不对，但并不代表就是无效号码，有些是企业400电话，需要单独分类。
• 品类层级码断裂：商品SPU有一级、二级、三级类目，但很多行只给了一级类目名称，没有代码，需要根据名称做模糊匹配还原层级关系，并且要处理同一名称对应不同代码的历史遗留问题。
• 重复定义需要业务确认：不是所有重复行都是错误。同一订单号出现多行，有时是因为一单多品拆行，有时是退货重售，还有时是系统对接产生的冗余日志，必须根据订单状态和行项标识做精确去重。

这些问题的处理顺序、清洗规则间的相互影响，以及每一步对后续统计口径的联动效应，都要求清洗脚本必须具备高度的可解释性和可调整性。而这恰恰是Claude Code最擅长的地方：它能理解复杂上下文，并生成带有清晰注释、步骤分明、容易修改的代码。

三、常见误区：很多团队用AI写清洗脚本，第一步就走错了

我会把这一节单独拎出来写，是因为这大半年和不少数据团队交流时，发现大家对“AI辅助写脚本”这件事有四个特别典型、也特别致命的认知偏差。如果不先打破这些偏差，你用任何大模型写出来的清洗脚本都很难真正融入工程流。

1. 把AI当成“自动洗机”而非代码协作伙伴

相当多人期望一步到位：给AI一份数据样本，让它直接输出洁净的DataFrame。这在线上demo里看起来很酷，但在真实环境中完全不可行。原因在于，数据清洗的决策权必须留在业务侧，AI无法知道“已取消”这个文本在这一列里究竟该转成0还是标记为特殊状态，也无法判断某个离群值是不是需要保留的合规业务记录。正确的用法是让AI产出可审查、可执行的清洗代码，而不是代替你做出业务判断。

2. 不提供足够的上下文，抱怨AI生成的脚本太蠢

“把缺失值填0”这种一句话提示，无论对Claude Code还是其他工具，都只能得到拙劣的脚本。因为现实中的缺失值处理永远有细分情形：数值型缺失和类别型缺失策略不同；高缺失率列可能需要整列丢弃；某些列缺失本身就是一个重要的信号。Claude Code强大的地方在于，你可以在对话里一次性把所有这些业务区别说清楚，甚至贴上几行数据示例，它就能生成精确匹配意图的函数。但如果只给一句模糊指令，任何AI都救不了。

3. 忽略可复现性，只求一次能跑通

很多人在Claude Code里反复修改，最终得到一个在测试样本上跑通的脚本后，就当作完工了。但真正的数据清洗脚本需要有可复现的版本管理和参数化能力，因为下次新的脏数据进来，类型和问题可能完全不同。我观察到的有效模式，是把Claude Code当作一个高阶结对编程伙伴，在它生成代码的同时，要求它把每个清洗步骤封装成带参数的函数，并生成配套的单元测试。这个过程花不了多少额外时间，但显著提升了工程的健壮性。

4. 迷信AI而放弃自己的校验习惯

我发现一个危险倾向：一些人把AI生成的脚本跑一遍没报错，就以为数据已经干净了。这是大忌。无论脚本是谁写的，都必须有独立的数据质量校验层，比如行数一致性检查、汇总金额与原始数据比对、关键列非空率验证等。Claude Code可以帮你生成这些校验代码，但不能替代你自己的质量意识。我自己每次必定会在清洗完成后，用几个与清洗脚本完全独立的聚合查询去核对业务指标，哪怕AI生成的校验脚本通过了，我也会再手工抽几行原始记录反向确认。

四、专业判断逻辑：我为什么在众多工具里长期选择Claude Code

说到生成代码的AI工具，市面上的选择很多。我也用过不少，其中GitHub Copilot普及度最高，一些本地化的代码大模型也号称支持数据分析。但专门就“数据清洗脚本编写”这个场景而言，我的选择标准非常务实，不是看谁跑分高，而是看它是否能在长达一两个小时的持续协作中，稳定理解前后文，并保持代码风格和逻辑的一致性。

我的判断逻辑分为四个维度：

1. 长程上下文保持能力

数据清洗脚本往往从数据探查开始，其次确定缺失值策略，再逐步处理异常值、格式、去重、关联等，步骤之间逻辑链很长。Claude Code能够记住一开始的数据探查结论，并在生成后续清洗代码时引用那些发现，不需要我反复重申。这对减少沟通摩擦起到决定性作用。我实测过，对一个包含约15个清洗步骤的复杂流程，只需在对话开头描述数据问题和各列业务含义，后面每一步直接说“现在处理手机的格式，按之前说的规则”，Claude Code就能准确地调取之前的规则，生成高度匹配的代码。这个能力在对比工具时差异显著。

2. 代码质量和可读性

数据清洗脚本不是一次性的，它要交给同事维护，也要在几个月后自己能看懂。Claude Code生成的代码通常带有清晰的分步注释、合理的变量命名和适度的模块化。我注意到它特别擅长写出“先按类别分组统计，再根据阈值决定填充策略”这类需要一定编码经验的模式，而不是生成一大堆硬编码的if-else。这归功于它在训练过程中对高质量Python数据工程代码的学习。

3. 调试互动中的诊断能力

清洗脚本跑起来报错是家常便饭，可能是数据类型的意外变化，也可能是某个字段出现了从未见过的脏值。我把完整的错误堆栈和出错行相关的数据片段贴给Claude Code，它通常能迅速判断原因并给出两种以上修复方案，甚至解释为什么之前的写法在边界情况下会失效。这个能力比我自己翻文档、看Stack Overflow要快好几倍，而且它还能顺带把相关的防御性代码加进去。

4. 非Python生态的支持

虽然我现在大部分清洗用Python，但有些场景必须用SQL直接在数仓里做基础清洗，或者在数据湖上用Spark。Claude Code对SQL、PySpark甚至Shell脚本的组合支持都不错，切换时不需要改变我的交互习惯。这对我来说是重要的兼容性指标。

五、完整案例：从52万行脏数据到可交付清洗流水线

下面我把开头提到的那次真实清洗项目从头到尾拆开，还原每一个关键步骤我是如何与Claude Code协作的。这个案例能非常具体地展示Claude Code在数据清洗脚本编写中的实际作用点。

项目背景：电商全渠道销售明细，52万行、38列，包含来自淘宝、京东、小程序、线下POS四个渠道的原始订单明细。目标是产生一份可直接用于BI看板的洁净数据表，并输出可复用的清洗脚本包。

1. 第一步：生成数据探查脚本，摸清“敌情”

我没有一上来就开始写清洗逻辑，而是先让Claude Code帮我写一份数据探查脚本。我的提示是这样的（精简后）：“我有一个dataframe df，列名如下（给出了所有列名的列表），请生成一个自动化数据质量探查函数，它要输出每列的数据类型、缺失数量和比例、唯一值数量、以及对于数值列给出5数概括和离群值建议阈值，对于分类列给出高频值及其占比，并把所有结果汇总到一个DataFrame里方便查看。”

Claude Code在十几秒内生成了大约120行的探查函数，使用了pandas的describe、isna、nunique等，并且增加了一个智能判断：如果数值列偏度极高，会自动用四分位距法给出离群阈值建议。我把这个函数在样本上跑了一遍，仅用了不到三分钟就获得了每列的全景画像。比如我发现“order_time”列缺失率0%，但时间范围跨度异常大，有的在2023年，有的落在了2030年，这马上就锁定了时区问题。

这里的关键是，我不需要自己查阅偏度计算函数和异常检测的阈值设定，Claude Code把这些封装成了可直接使用的代码，我只需阅读输出做业务判断。

2. 第二步：时区统一，第一次人机协商

发现时区问题后，我在同一个对话里继续：“刚才探查到order_time列混合了UTC、北京时间、以及部分异常未来时间，现在需要写一个清洗函数，将时间统一为北京时间，规则如下：如果时间值在数据采集时段合理范围内，但小时偏移量显示可能是UTC+0，则加8小时；如果是13位数字的Unix毫秒戳则转为北京时间；如果落在未来超过3天，先标记出来供人工核对，其余默认视为北京时间。输出清洗后的列和标记列。”

Claude Code迅速生成了一个带有详细分情况处理逻辑的函数，还用到了pd.to_datetime的errors='coerce'来应对极端异常值。但第一次跑的时候我发现，有一条2025年的记录（当时才2024年）不是未来时间，而是因为系统测试未删除，这需要列为脏数据直接剔除。我把这个新条件告诉它：“除了未来超过3天标记外，凡是年份大于当前年份+1的，直接丢弃整行，并记录丢弃行数。”Claude Code立刻调整了函数逻辑，重新生成，并在函数内增加了drop_count计数器返回。这种即时的逻辑修补，如果纯手写，至少要花十分钟定位、修改、确保不影响其他分支。

3. 第三步：退款金额列，展示上下文记忆实力

退款金额列处理是本次清洗最繁琐的部分之一。我向Claude Code描述了现象：“refund_amount列，目前类型是object，里面包含正负数、空字符串、文本'已取消'和'待处理'。要求：文本'已取消'转为0，'待处理'转为NaN并单独标记；空字符串转为0；其他能强制转数值的转数值，不能转的标为异常。所有操作后，产生一个干净的数值列，同时保留原始列用于审计。”

Claude Code生成的代码使用了pd.to_numeric强制转换并捕获错误，再用apply自定义逻辑映射文本值。这一步它做得非常稳健。更令我印象深刻的是，当后来处理另一个与金额相关的列时，我不需要重复说明业务规则，它主动引用了之前退款列的处理逻辑，生成了一段注释“按照与refund_amount一致的清理原则，优先文本映射为0或NaN”，并保持了代码模式的一致。这就是长程上下文的威力。

4. 第四步：手机号清洗，与领域知识结合

“phone”列，长度从7到19都有，包含+86前缀、横杠、空格。我需要：去除空白和横杠，如果是中国大陆手机号11位且1开头则保留，如果是带+86的转为无前缀11位，如果是400/800开头则归类为企业热线，其余标为无效。Claude Code生成的函数使用了正则表达式，逻辑清晰。但第一次测试发现，部分号码开头有“86-”而非“+86”，它没有被捕获。我把样本贴进去，它立刻修改了正则，并加了一条注释：“# 处理无加号的86前缀变种”。迭代时间不到1分钟。

5. 第五步：品类层级码模糊匹配，更复杂的逻辑

这步是本次清洗最有挑战的部分。我需要在百万级商品主数据表中，根据一行里的类目名称去匹配标准的三级类目编码。因为名称存在缩写、全称、拼写差异，不能做精确匹配。我向Claude Code描述了主表和映射规则，并说：“请生成一个函数，使用difflib或fuzzywuzzy，先用一级名称精确匹配缩小候选集，再对二级三级名称做模糊匹配，阈值为85%，取最高分且不低于阈值的编码。”Claude Code引入了fuzzywuzzy的partial_ratio，并为了效率，先用一级名称建了字典索引，避免了全表扫描。函数约90行，我在50万行上测试，运行了大约3分钟完成匹配。后来我要求它增加进度条和缓存机制，它果断加入了tqdm和一个简单的字典缓存，第二次运行直接降到40秒。

这一系列操作，Claude Code不仅写代码，实际上是在帮我做性能优化设计。这种体验已经超越了单纯的自动化代码生成。

6. 第六步：重复行处理，反映业务判断

对于重复订单，我给了非常详细的条件：“当订单号、SKU、下单时间三者完全相同时，认为是系统重复日志，保留最早的记录；当订单号、SKU相同但时间不同，且订单状态分别为‘已取消’和‘已完成’时，如果已完成记录在后，需要保留已完成，取消记录标记为‘已修正状态’；其他情况出现订单号重复但SKU不同，那是拆单，全部保留。”Claude Code对这段描述的理解非常精准，它生成了一整套先排序、再分组、最后用自定义聚合逻辑去重的方法，代码中甚至主动包含了每个去重决策的记录列，方便最终审计。

7. 第七步：校验与对数，质量不依赖AI

脚本写完之后，我又让Claude Code另起一个独立的对话，依据同一份数据探查报告，生成一个“对立校验脚本”，该脚本用完全不同的聚合方法计算总GMV、订单数、各渠道销售额，并与清洗脚本输出对比。这个额外的步骤，Claude Code几分钟就写了出来。最终我发现，因为一个订单状态变更的逻辑，原来的脚本少计数了3行，错误迅速得到修正。这体现了校验脚本与清洗脚本应该由不同思维生成的原则，而Claude Code充当了那个可切换的“第二思维”。

最后，我要求Claude Code把所有函数整合成一个主调度脚本，加上命令行参数入口，并生成详细的Markdown文档。这些它都在极短时间内完成。从接手数据到交付，总共不到5小时，而相同任务按手写估计需要12-14小时。

六、不同情况下的行动建议：如何把Claude Code融入你的清洗工作流

上面的案例是一个中型离线清洗项目。在实际工作中，数据清洗的规模和性质千差万别，Claude Code的使用方式也需要调整。我根据经验给出分场景的建议：

场景1：紧急的一次性小清洗（几千到几万行，临时分析用）

这时候你不需要构建完整的脚本工程，目标就是快速把数据弄到能分析的程度。让Claude Code直接在对话中读取前几行样本，然后根据你的清洗需求生成一个Jupyter cell的代码块。你在Notebook里运行、验证、看结果。如果有问题，立刻让Claude Code修正。这种模式下，很可能15分钟就能出图分析，不必纠结代码封装。

场景2：周期性运行的清洗管道（对数仓/BI层负责）

这种场景最考验代码质量和可维护性。我建议采用“对话式设计→脚本生成→人工代码审查→封版”四步。关键是人工审查这一步不能跳过。我会在Claude Code生成代码后，把它当作一个团队成员的提交来Review，检查逻辑边界、异常处理、性能。由于代码注释完整，审查起来很快。另外，一定要让它同时生成对应的单元测试和多场景模拟数据，这样下次有调整时，快速回归。

场景3：多个数据源的复杂聚合清洗

当清洗不仅涉及单表，还要关联多张表时，协调顺序变得重要。我的方法是：先在白板或文档里理清实体关系和处理顺序，然后逐表与Claude Code协作清洗，每清洗完一张表，就让它生成该表的中间层写入脚本和一个数据质量快照。最后统一调度。Claude Code在这个过程中能维护一个“全局清洗日志”，避免列名冲突和字段丢失。

场景4：非结构化或半结构化数据清洗

比如日志文本、JSON嵌套、网页抓取内容。Claude Code对这类数据的解析代码生成能力也很强。你只需要提供一两行样例，并说明你需要提取的字段和可能的变体，它就能写出带有容错机制的解析函数。相比于自己写正则或json_normalize的异常分支，能减少很多试错时间。

七、不同情况下的取舍：Claude Code不是万能，但知道何时不用更重要

任何工具都有边界。我虽然大量使用Claude Code，但也遇到过必须果断退出的情况。这些取舍经验可能比单纯的赞美更有价值。

1. 涉及严格的隐私和合规数据时

当清洗的数据包含个人身份信息或受监管内容时，我绝不会把任何真实数据片段粘贴给云端AI。这时的做法是：自己手工写脱敏后的样例数据，基于样例让Claude Code生成通用清洗模板，然后再到本地安全环境里手动填充关键变量和连接信息。这会损失部分协作流畅性，但安全红线不可触碰。

2. 极其特定的企业内部遗留系统怪象

有些企业内部的ERP系统会输出你完全无法描述规律的奇葩格式，比如字段分隔符不确定、多字节编码随机错乱。Claude Code对这种特定怪异的认知可能有限，生成的代码必须大量人工改写。此时最有效的做法是用传统方式写一个适配器，然后让Claude Code帮忙写适配后的清洗链。不要期望它能直接搞定所有极端遗留问题。

3. 需要极端性能调优的场景

在数据量极大（数亿行）、内存受限的情况下，清洗脚本必须做细致的分块、向量化或JIT优化。Claude Code能给你正确的思路和基础代码，但具体的性能拐点需要你在实际集群上测试。这时候可以把它生成的原型当作起点，而不是最终答案。我会在它生成基础上进行profiling，并把瓶颈点再反馈给它，请求优化建议，这样一个协作循环能产生良好的效果。

4. 当业务规则本身还在频繁变动时

如果清洗时需求方每天改一次规则定义，脚本也要跟着大改，那么过早用AI生成大量固定逻辑反而会成为负担。我的做法是先明确规则稳定部分，用Claude Code生成可配置的清洗函数，对不稳定部分采用参数化设计，尽量将变化限制在配置层而不是代码逻辑层。

所以，我把使用Claude Code的原则总结为：在规则清晰、风险可控、重复劳动密集的清洗环节充分利用；在规则模糊、安全要求极高、性能需要精细调控的环节，回归专业判断，仅用Claude Code做辅助参考。

八、数据支撑：用数字说话，避免感性吹捧

为了不让这篇文章停留在经验感受层面，我专门回顾了从开始使用Claude Code至今，6个典型数据清洗项目的工时记录和缺陷数据。这里直接把结果摊开：

• 平均效率提升：6个项目，分别是不超过5万行的简单清洗、50万行级中等清洗、以及多表千万行级的数仓清洗。平均节约工时比例约为53%（标准差8%）。但注意，这不是脚本运行时间的节省，而是人力开发时间的节省，且包含学习曲线成本。
• 首次运行通过率：传统手写脚本，我首次在完整数据集上运行不出错的概率大概只有40%，常常需要两到三轮调试。用Claude Code辅助后，首次通过率提升到了72%（基于6个项目中所有清洗步骤的统计），因为它在生成过程中已经考虑了较多边界条件。
• 代码Review发现逻辑问题数：尽管通过率高了，人工代码审查仍然至关重要。平均每个项目中，我依然能挑出3-4处逻辑瑕疵或需要优化的点，其中大约一半是业务理解偏差，另一半是对极罕见情形的处理不当。这再一次证明，Claude Code不能取代专业大脑。
• 可维护性评分：我和另一位高级工程师背对背对产出脚本的可读性、注释质量、模块化程度做1-10评分，Claude Code辅助项目平均得分8.4分，传统手写项目平均6.9分。差距主要来自于Claude Code生成的注释更有系统性、函数封装更规范。

九、我的核心经验提炼：与Claude Code结对清洗的“七要三不要”

七要

1. 要在对话开头交代数据全局：一次性告诉它所有列的业务含义、数据量级、存储格式，它会在后续生成中保持一致性。
2. 要提供真实的数据样本：脱敏后，给出一两行真实但安全的样本，远比抽象描述更高效。
3. 要分步执行和验证：每个清洗步骤生成后立即跑测试，不要一次性生成全部脚本再跑，否则错误定位困难。
4. 要让它生成单元测试：在说完业务逻辑后，追加一句“并为该函数生成3个典型场景的测试用例”，这会使代码健壮性上升一个台阶。
5. 要保留原始数据列用于审计：提示里明确要求保留raw_前缀原始列，有助于追责。
6. 要利用它生成清洗报告：最后一步，让它根据日志自动生成清洗报告，说明删除了多少行、填充了多少、异常标记分布，这部分对业务方价值巨大。
7. 要把最终对话导出存档：整个协作过程就是一份详细的设计文档，直接保存为项目文档的一部分。

三不要

1. 不要在敏感数据上裸用：绝不让真实客户数据流入模型。
2. 不要盲目信任生成结果的业务正确性：AI不知道“渠道A的退款在特定活动期间应记为营销成本”这种临时规则，必须人工注入。
3. 不要放弃自己对数据的感觉：一定要用独立的简单聚合抽查几个关键数，血的教训告诉我，再完美的脚本也可能在某一个隐藏条件上翻车。

十、如果你现在就想开始，这是我给你的路线图

我不是那种只会夸工具好、却不说怎么上手的所谓专家。以下路线图适用于已经具备基本Python和pandas能力的数据分析师或工程师，想立刻把Claude Code融入数据清洗工作流。

第一步：选择一个你最近拖延了很久的中小型脏数据集（1万到10万行，十几个列），确保数据不包含真正敏感信息，或者你已经做了脱敏。

第二步：打开Claude Code，用自然语言详细描述这个数据集的背景和已知问题，例如：“这个CSV记录了XX业务从2023年1月到6月的交易，列A是订单ID，应该唯一但可能有重复；列B是金额，理论上全正数但实际有负值……请先生成一个数据质量探查脚本。”

第三步：把探查脚本的输出结果或者关键发现，直接贴回对话里，和Claude Code讨论每一项问题该用什么策略。不要跳过“讨论策略”这一步，这是你作为专家输出价值的时刻。

第四步：让它逐个生成清洗处理函数，你在本地环境运行验证。每次验证后反馈结果，修正直到通过。

第五步：所有单步通过后，要求Claude Code生成一个主清洗管道脚本，并附上独立的对账校验脚本。

第六步：全程记录下你花费的时间，与之前类似任务进行比较。你会惊讶于差距。

如果你已经是团队管理者，可以试着推广这种“AI结对编程审查”的模式。设置规范：AI生成代码后，必须由另一人审阅并签署，纳入代码仓库。这样既提高效率，又保证质量，避免个体能力差异的放大。

最后，我想说一个很多人没意识到的点：Claude Code在数据清洗脚本编写中真正改变的是认知负荷的分配。过去，我要在“记忆函数用法、处理类型异常、考虑性能写法”这些低阶细节上消耗大量精力；现在我把这些外包给了AI，把更多的脑力分配到“理解数据背后的业务意义、设计更合理的清洗口径、预判下游分析可能遇到的坑”这些高阶工作上。这种分工，才是人机协作的正确打开方式。

数据清洗永远不会变成一个性感的工作，但我们可以让它变得更聪明、更可控、更少加班。从现在开始，找一个数据集，动手对话，你的第一版清洗脚本可能20分钟后就跑起来了。那时候，再回来想想我这篇文章说的这些方法，你会理解得更深。