如何用 Codex 清洗一份混乱的 Excel 数据:从原表到复核清单的完整教程

客户名单里，同一家公司可能同时写成全称和简称；日期有的用短横线，有的用斜杠；手机号里夹着空格。更麻烦的是，两条看起来一样的记录，可能是重复导入，也可能是同一客户的两次咨询。直接点“删除重复项”，很容易把业务事实删掉。

这篇教程用12 条虚构客户咨询记录，实际走一遍“备份原表→明确规则→预览问题→生成清洗结果→人工复核→审计”的过程。案例文件位于 examples/52-excel-cleaning。文中的公司、联系人和手机号都是演示数据；图片1到图片9均取自该案例实际运行的工作簿或报告。

一、先写清楚清洗边界

在案例目录里，我先写 brief.md，告诉 Codex 哪些可以自动处理，哪些必须停下来：

1. 原始工作簿独立保存，不能覆盖。
2. 日期只接受能通过日历校验的 YYYY-MM-DD、YYYY/M/D、YYYY.M.D三类写法。
3. 公司简称只按明确维护的别名表转换，不做模糊猜测。
4. 手机号只去掉空格和连字符；空值保持空值。
5. “公司＋联系人＋咨询日期”相同的后续记录进入复核表，不自动删除。
6. 每条输出必须带原始行号和记录 ID。

可以把这段话直接交给 Codex：

请读取 brief.md、source-records.csv 和 company-aliases.csv。先制作原始 Excel，再生成预览；预览中列出可用记录和待人工确认记录。不要覆盖原始 Excel，不要猜测无效日期，不要因为公司名称相同就删除咨询。输出清洗后的 Excel，并保留原始行号、记录 ID 和校验结果。  

案例脚本 cli.mjs 使用 Codex 工作区可用的 @oai/artifact-tool 读写 .xlsx。下面的命令是在已连接该依赖的案例目录中运行的；换到普通 Node 环境时，先让 Codex 为当前项目配置这个依赖，或将工作簿读写部分改为本机已安装的 Excel 库。

二、生成原始 Excel，先看见问题

源数据在 source-records.csv，保留 12 行和 7 个字段。运行：

node cli.mjs seed

脚本生成 outputs/article-52-excel-cleaning-20260929/raw-customers.xlsx，并把原始表渲染出来。你能直接看到三种日期写法、手机号中的空格与连字符、两条空手机号，以及 L012 的 2026-08-32。这一天不存在，不能仅靠改格式修好。

这里的 raw-customers.xlsx 就是后面所有核对的基准。清洗结果会写入另一个工作簿，绝不回写这份原表。

三、先复现一次错误：只按公司名去重

运行预览：

node cli.mjs preview

我先让脚本算了一次错误口径：把公司名标准化以后，如果仍只按公司去重，12 条咨询最终只剩5 家公司。但“公司数”和“咨询记录数”不是同一个指标。L001、L002、L010 都属于北岸咨询，日期和需求却不同，应保留为三条咨询。

这一步要先做，因为 Codex 可能给出一段能运行的去重代码，却没有先问“重复”的业务定义。让反例出现在预览里，后面的规则才有依据。

四、建立公司别名表，不凭感觉合并

company-aliases.csv 只有三列：原公司名、标准公司名、核对依据。案例里明确写了：

原公司名,标准公司名,核对依据北岸咨询,北岸咨询有限公司,演示样本预设的简称映射星桥设计,星桥设计工作室,演示样本预设的简称映射云衡科技,云衡科技有限公司,演示样本预设的简称映射 

映射表只统一写法，不合并事件。比如 L002 的公司名转成“北岸咨询有限公司”后，仍因为日期与 L001 不同而单独保留。真实业务中，别名关系应由数据负责人核对；没有依据的相似名称不要交给 AI 自行合并。

五、查看预览：10 条可用，2 条待确认

预览脚本先转换别名和日期，再按“标准公司名＋联系人＋有效日期”找疑似重复；遇到无效日期则直接进入复核。实际输出是：

预览完成：原始 12 行，保留 10 行，待确认 2 行；实际删除 0。

两条待确认的原因不同：L011 与 L002 的标准公司名、联系人、日期相同，脚本只把它标为“疑似再次导入”；L012 的日期无效，脚本不猜它本来要写哪一天。两个空手机号在 L006、L007，但咨询日期有效，因此记录仍保留，只标记“缺手机号”。

六、生成清洗工作簿，先看概览

确认预览规则以后运行：

node cli.mjs build

脚本会先比较原始 Excel 的 SHA-256 哈希。如果它在预览后被改动，就停止生成，要求重新预览。检查通过后，脚本生成 cleaned-customers.xlsx，其中有“清洗概览”“可用记录”“待人工确认”“公司别名”四张表。

概览不是宣称 12 行已经全部处理完。这里明确写着：待确认记录暂不计入可用记录，但保存在另一张表里；两个手机号缺失也没有被自动补造。

七、抽查可用记录：日期、公司名和来源行

“可用记录”表有 10 行，每行都带原始行号、记录 ID、标准公司名、原公司名、清洗后的手机号和日期。日期是 Excel 中可排序的日期值，统一显示为 yyyy-mm-dd；手机号按文本保留，避免把标识符当数字运算。

抽查时，我重点看 L001 和 L002：两条的标准公司名相同，但日期分别是 2026-08-03 和 2026-08-15，都还在。再看 L006、L007，手机号仍为空，状态显示“缺手机号”。这比只看“清洗成功”四个字更能发现误删或编造。

八、打开复核表，留下人工判断入口

“待人工确认”表有两行：L011 关联 L002，原因是疑似重复；L012 的原始日期仍显示 2026-08-32，原因是日期无效。两条都保留原始字段和来源行号，方便回到原表核对。

这一步要交给熟悉业务的人：确认 L011 是重复导入还是一次独立咨询；向录入人核实 L012 的实际日期。在结论到来之前，不要把它们悄悄并入可用表，也不要直接删除。

九、最后做一次审计

运行：

node cli.mjs verify

校验同时检查原始工作簿哈希、清洗工作簿中的行数、12 个来源 ID 是否都有去向、空手机号是否仍为两条、以及 L001 和 L002 是否都被保留。本案例的实际输出是：

校验通过：12 个来源 ID 全部可追溯；原始工作簿哈希未变。

到这里，技术清洗完成，业务复核尚未完成。迁移到自己的 Excel 时，先用一小份获授权的副本测试，把字段含义和去重依据写进规则文件；让 Codex 生成预览与复核清单，再由负责人处理有歧义的行。这样得到的结果不仅整齐，还能回答每一行从哪里来、为什么被保留或暂停。