做数据分析的人都熟悉一个说法：大部分时间花在清洗数据上，真正跑模型的时间反而零碎。麻烦通常不在不会写代码，而在分不清哪些问题该合并、哪些异常值其实是真实订单。AI 在这件事上的位置很明确：帮你把问题列全、把规则写细、把脚本生成出来，但“这条数据该怎么处理”要你自己拍板。
先分类，再动手
拿到一份数据，先别急着写处理规则。让 AI 做首轮核查，把问题分成四类：格式不一致、缺失值、重复记录、异常值。分类的意义在于处理方式完全不同——格式问题统一写法就行，缺失值要区分“真的没有”和“漏填”，异常值要先判断是错误还是极端真实。混在一起处理，是最常见的翻车原因。
实操顺序建议是：先备份原表，然后按“去重 → 统一格式 → 处理缺失 → 核查异常”四步走。去重放在最前，因为重复行会影响后面所有统计；缺失值放中间，因为去重和格式统一之后，缺失的分布才看得准。DeepSeek、Kimi 这类工具都能直接读粘贴进来的表格样本，一轮就能列出问题清单，比人眼扫一遍全表快得多。
质量问题对照表
| 问题类型 | 典型表现 | AI 能做什么 | 你要拍板什么 |
|---|---|---|---|
| 格式不一致 | 日期混用 2026-01-05 和 2026/1/5 两种写法 | 列出所有格式变体，给出统一规则 | 统一成哪种，历史数据要不要回溯 |
| 缺失值 | 某列三成以上为空 | 区分空值、未录入和漏填，统计缺失比例 | 删除、留空还是单独标记，会不会扭曲结论 |
| 重复记录 | 同一用户出现多行 | 找出主键冲突的行，给出保留策略 | 按时间最新还是按金额最大去重 |
| 异常值 | 年龄 200 岁、金额为负 | 标出离群行，列出可能原因 | 是错误、退款还是真实大单 |
| 命名混乱 | “北京”和“北京市”被当成两个地方 | 生成映射表，列出所有需合并的写法 | 映射关系是否符合业务口径 |
这张表的用法是：右列永远留给自己。凡是 AI 给出的处理建议，先过一遍“这是格式问题还是业务问题”——格式问题它可以定，业务问题必须你定。
提示词里必须写清的四件事
一段能用的清洗提示词，要把四件事交代清楚：数据样本和字段说明、每列的预期含义、你的处理边界、输出格式。比如“不要填充缺失值，只标记”这句话，能避免它好心把空值补成 0——后者会直接改变均值。
输出格式建议固定成“问题清单、处理建议、风险提示”三段式，并要求它对每个建议说明为什么。理由一写出来，你就能看出它是不是在瞎猜。另外明确告诉它：哪些处理可能改变数据含义，需要你确认后才能执行——这句话能挡掉大部分自作主张。
清洗后的复核不能省。让它再扫一遍处理后的数据，列出仍存在的问题。这一步听起来多余，实际上经常能捞回漏网的格式变体。脚本建议按 pandas 或 SQL 生成，取决于你后面在什么环境里跑，具体写法以你的环境为准。
清洗协作速查
- 先备份原表，再动手；规则写成脚本，别停在一次性对话
- 顺序：去重 → 统一格式 → 处理缺失 → 核查异常
- 提示词加两句：只标记不填充；改含义的先问我
- 业务口径问题不交给 AI，离群值先问是不是真的
它替不了你的地方
AI 对业务口径是无知的。金额异常可能是系统重复记账，也可能是真碰上一个大客户；用户注册时间集中在凌晨三点，可能是活动生效，也可能是刷量。这些判断依赖你对业务的了解，它只能列可能性，不能替你下结论。
第二个边界是数据安全。含个人信息、经营数据的表，粘贴给工具之前先脱敏，字段名改成“手机号”而不是真实号码。公司有规定的，按公司规定来，别绕。
第三个边界是长尾一致性。它能在样本行上把规则定对，但一张 5 万行的表里，第 3 万行可能藏着一个没见过的写法。规则要写成可复跑的脚本，而不是一次性对话——同样的脚本跑三遍，结果才敢拿去用。
清洗完的数据怎么接着用，可以参考用 AI 分析退货原因的归因思路，也可以按年度复盘的总结方法把一年的数据串起来看；如果你是给店铺做经营口径的汇总，给合伙人的经营总结版本里有一套从原始表到结论表的整理路径。
三个常被问到的问题
表有几十万行，还能用 AI 吗？只贴样本。让它基于前 200 行归纳规则，再把规则写成脚本跑全表，别指望它一次读完全量。
它给的规则互相冲突怎么办？以可追溯优先：选那条能说清依据、跑完后能验证行数变化的，说不清依据的规则先放一边。
清洗记录要留到什么程度？留三样就够：原始文件、处理脚本、处理后文件。脚本本身就是记录，比写十页文档都清楚。
