拿到一份 10 万行的运营数据，打开一看：日期列有"2024/1/1"、"2024-01-01"、"1月1日"三种写法；手机号混着"+86 138..."、"138-xxxx-xxxx"和空值；城市字段一半填"北京"一半填"北京市"；还有几行 GMV 是负数和 0 的测试数据。清洗这活儿，纯靠 Excel 筛选做到天亮，纯靠大模型一把梭又贵又慢还不可复现。这条 SOP 给你一套"LLM 当侦察兵和判官、Python 当执行手"的 6 步法，把脏表格洗到能进分析模型的状态，每一步留可复跑的脚本和可追溯的血缘。
一、为什么是"LLM + Python 脚本"双轨，不是一头
先说清楚两种极端为什么都不行。纯 LLM 改全量数据：10 万行逐行喂给模型，token 费用够买半年会员，跑一晚上还不一定跑完，最要命的是不可复现--下次数据更新你还得再来一遍，规则全凭模型当次心情。纯 Python 脚本：规则你得自己一条条写，遇到"北京XX科技有限公司"和"北京 XX 有限公司"是不是同一家这种模糊判断，正则写到崩溃也覆盖不全。
正确的姿势是分工：LLM 负责它擅长的"理解+判断"--探查脏点、生成规则草案、做模糊匹配和语义去重；Python/pandas 负责"批量执行"--把确定规则代码化，一次写好反复跑。LLM 出脑子，脚本出体力，两者咬合成一条可复现的流水线。下面 6 步就是这么咬合的。
二、第 1 步 探查：让 LLM 当脏数据侦察兵
不要一上来就写清洗代码。先抽样喂给 LLM，让它告诉你这份数据"脏在哪"。抽样而不是全量，是为了快和省--随机抽 200 行通常足够暴露主要脏点。把抽样数据转成 CSV 或 JSON 片段，配下面这个探查 Prompt：
你是数据质量审查员。下面是一份表格数据的随机抽样（CSV）。
请逐列检查并报告以下脏点：
1. 缺失值：哪些列有空值、空字符串、NULL、NaN？给出大致占比。
2. 格式不一致：日期/电话/金额/枚举字段是否存在多种写法？各举一例。
3. 异常值：数值列是否有明显离群（负数、超大、全零）？举例。
4. 重复记录：是否有疑似重复行？依据哪些字段判断？
按列输出 JSON：{"列名": {"问题类型": ["具体样本"]}}。
只报告样本中真实存在的问题，不要编造，不要泛泛而谈。
数据样本：
{粘贴 200 行 CSV}跑完你会拿到一份结构化的脏点清单，比如"date 列存在 3 种格式""phone 列有 +86 前缀和空值混用""GMV 列出现 2 行负数"。这份清单就是下一步定规则的输入。注意：LLM 给的是"脏点描述"不是"清洗动作"，别让它顺手就把数据改了--改了就不可控了。
三、第 2 步 定清洗规则：LLM 出草案，人拍板
拿着脏点清单，让 LLM 生成可执行的清洗规则草案，但最终拍板的是你。LLM 不懂你的业务口径--比如 GMV 为 0 到底是测试数据要删，还是真实退款要保留，它判断不了。
清洗规则生成 Prompt：
基于以下脏点报告和业务背景，生成可执行的清洗规则清单。
要求：
- 每条规则注明：适用列、判定条件、处理动作（填充/删除/标准化/拆分）、异常回退策略。
- 规则按执行顺序编号，彼此不冲突。
- 输出格式：序号 | 列 | 条件 | 动作 | 回退
- 不要直接修改数据，只输出规则。
业务背景：电商直播日报，GMV<=0 为测试数据需删除。
脏点报告：
{粘贴第 1 步的 JSON 结果}LLM 会吐出类似"规则 1 | date | 多种格式 | to_datetime 标准化 | 解析失败的行 date 置 NaT 后删除"这样的清单。你逐条审：业务上对不对？有没有过度清洗？改完定稿，这份规则表就是下一步脚本化的蓝本。留好这份文档，它就是你的清洗契约。
四、第 3 步 脚本化执行：pandas 代码化，可复现
把定稿规则翻译成 pandas 代码。这一步的核心原则：每条规则对应一段代码，代码就是规则的唯一真相。下次数据更新，跑一遍脚本就完事，不用重新跟 LLM 对话。
import pandas as pd
df = pd.read_csv("dirty.csv")
raw_count = len(df) # 留底，校验用
# 规则1：删除 GMV<=0 的测试行
df = df[df['GMV'] > 0]
# 规则2：日期标准化，解析失败置 NaT 后删
df['date'] = pd.to_datetime(df['date'], errors='coerce')
df = df.dropna(subset=['date'])
# 规则3：手机号只留数字
df['phone'] = df['phone'].astype(str).str.replace(r'\D', '', regex=True)
df.loc[df['phone'] == '', 'phone'] = None
# 规则4：城市去掉"市"后缀统一
df['city'] = df['city'].astype(str).str.replace('市$', '', regex=True)
df.to_csv("cleaned.csv", index=False)
print(f"原始 {raw_count} 行，清洗后 {len(df)} 行")每条规则都加了注释编号，和第 2 步的规则表一一对应。pandas 的 to_datetime 用 errors='coerce' 把解析失败的转成 NaT 而不是直接报错--这是处理脏数据的标准姿势，别让一行坏数据炸掉整个脚本。
五、第 4 步 LLM 补难规则：模糊匹配 / 语义去重 / 字段抽取
到这一步，能写成确定规则的脏点都洗完了。剩下的硬骨头--模糊匹配、语义去重、非结构化字段抽取--正则覆盖不了，得让 LLM 来判。但判的方式不是让它改全量，而是"LLM 逐对判定 + 脚本批量执行"。
以"疑似重复公司名去重"为例，先用脚本筛出候选对（名称相似度高的），再让 LLM 逐对判：
模糊匹配判定 Prompt：
你是数据去重判定员。下面是待判定的记录对（字段已对齐）。
对每一对判断是否为同一实体，输出 JSON 数组：
[{"pair_id": 1, "same": true/false, "confidence": 0.0-1.0, "reason": "依据哪些字段"}]
判定标准：名称相似（容忍拼写差异、缩写、别名）+ 地址/电话/编号佐证。
confidence 低于 0.6 的标记 reason 为"需人工复核"。
不要只看名称完全相等，要处理"北京XX公司"与"北京 XX 有限公司"这类变体。
记录对：
{粘贴候选对 JSON}LLM 判完输出 JSON，你用脚本解析结果：confidence 高的直接合并，低的进人工复核队列。字段抽取同理--把"地址"列里混着的省市区让 LLM 拆成三列，批量喂、批量收，脚本落库。关键纪律：LLM 只输出判定结果，不碰原始数据，所有写库操作由脚本完成。
六、第 5 步 校验：清洗前后对比 + 异常复盘
洗完不校验等于没洗。校验分两块：数量对账和质量抽查。
数量对账--清洗前后行数、关键字段非空率、枚举值分布有没有突变。比如城市列清洗前 50 个枚举值，清洗后应该收敛到 30 个以内；GMV 总额清洗前后差额应该等于被删的异常行 GMV 之和。写个对比脚本自动跑：
raw = pd.read_csv("dirty.csv")
clean = pd.read_csv("cleaned.csv")
print(f"行数：{len(raw)} -> {len(clean)}（删 {len(raw)-len(clean)} 行）")
print(f"GMV 总额：{raw['GMV'].sum():.2f} -> {clean['GMV'].sum():.2f}")
print(f"城市枚举数：{raw['city'].nunique()} -> {clean['city'].nunique()}")质量抽查--随机抽 50 行清洗后的数据肉眼扫一遍，重点看有没有"洗过头"：不该删的删了、该标准化搞成空值了、模糊合并把两家不同公司并成一家了。发现异常记下来，回溯是哪条规则的问题，改规则重跑。这一步是防止过度清洗的最后一道闸。
七、第 6 步 留痕：规则可复跑，数据血缘
清洗做完，要保证一个月后新来一批数据，你能一键复现整个清洗过程。两件事必须留：
一是可复跑的脚本仓库。 把探查、清洗、校验的脚本按顺序编号放进一个目录（01_profile.py、02_clean.py、03_validate.py），配一个 run_all.sh 一键串起来。规则变了就改脚本，别在 Excel 里手动调。
二是数据血缘记录。 每次清洗保留三个版本：raw/（原始数据按日期归档）、cleaned/（清洗后）、log/（清洗日志，含行数变化、删了哪些行、规则版本号）。这样任何人问"这行数据怎么来的"，你能回溯到原始行和当时跑的规则。一张清洗前后的对比表写进日志：
清洗时间：2026-07-29
规则版本：v1.2
原始行数：10234 -> 清洗后行数：9876（删 358 行）
删除原因分布：GMV<=0 删 210 行，日期解析失败删 89 行，重复删 59 行八、五个踩坑实录
1. 直接让 LLM 改全量数据。 图省事把 10 万行全喂给模型让它直接输出清洗后的数据，结果 token 费三位数、跑了 4 小时、还不可复现。正确做法：LLM 只做探查和判定，执行交给脚本。能写成确定规则的坚决不交给模型跑。
2. LLM 模糊判定不稳定不加校验。 同一对公司名，问两次 LLM 给出不同结论（一次判同一次判异）。对策：confidence 低于 0.6 的强制走人工复核，高置信度的也抽 10% 人工校验，别全信模型。
3. 隐私数据外送不脱敏。 客户姓名、手机号、身份证直接喂给云端 LLM，踩合规红线。敏感字段先在脚本里脱敏（哈希或掩码）再喂 LLM 判定，或者用本地模型--Ollama 跑 qwen2.5 这类开源模型做模糊判定，数据不出域。
4. 清洗规则成了黑盒。 规则散落在十几次和 LLM 的对话里，没人记得全。下次数据来了不知道怎么洗。对策：所有定稿规则必须落在脚本和文档里，脚本即文档，对话记录不作为规则的唯一来源。
5. 过度清洗丢信息。 为了"干净"把所有缺失值一行删、所有异常值一刀切，结果把真实退款、测试订单、边缘 case 全删了，分析时发现数据对不上。对策：原始数据永远保留，清洗后的单独存一版，删行记录可回溯，宁可多留不可乱删。
参考来源