那个整理 Excel 的小工具,我改了三回

起因很小。内部有个整理表格的活，每周都要来一遍：几张采购台账合到一张表里，列名对齐、空值标出来、按供应商汇总一遍，规则固定，人工做容易漏。我估摸着用 AI 辅助写个小工具，Python 里 pandas 读表、openpyxl 写回 Excel，一晚上应该能收工。

工具最后确实跑起来了。可那晚真正花掉的时间，几乎都不在代码上。

出发前我信了三条。头一条，需求我能一次说清楚。真写下来才发现，我说清的只有主流程：某一列为空是跳过还是标红、同名文件要不要覆盖、上周有人把日期写成文本格式算不算错、汇总时同一供应商的两个名称要不要合并——这些例外一条都没提前想过。费时间的是把它们一条条列出来，不是写合并逻辑。pandas 里一句 merge 就完的事，前面得先想明白用哪列做键、重复行怎么处置。

第二条也塌了。能跑和能交付差着一截：异常提示别人看不看得懂、换个人能不能改、下次规则变了要动哪一处，第一次输出里全没有。我第一版把文件路径写死在脚本里，报错时只丢一行 traceback，同事根本不知道该改哪里。后来把规则抽成一张配置表，报错改成「第 3 张表第 12 行日期格式不对，已跳过并记入日志」，才算能交出去。

最后一条最意外。我本来想先搭个通用框架，以后好扩展，结果框架带来一堆当时根本用不上的分支，验收反而变难。把范围收回到「就干这一件事」，反倒稳了。

被推翻之后，顺序变了：先把例外情况列成一张清单，再让它按清单生成；把「换个人能改」当成明确要求提，别留到交付后补；范围宁可收窄，不用「以后也许用得上」给复杂度找理由。第三回改完，代码比第一版还短，跑起来的结果倒更让人放心。

第三回改完，我给自己留了三样东西：一张例外清单、一份配置表、一个会写日志的运行结果。例外清单决定它会不会漏，配置表决定别人能不能改，日志决定出问题时能不能查。AI 在这三样里帮得上忙的是把分支骨架快速摆出来，比如按几种格式各生成一段处理代码；判断哪些例外真会发生、哪些可以不管，还是得自己拿上一周的表翻一遍。顺带把文件名和路径改成启动时传入的参数，别再写死在脚本里。

后来我拿这套顺序去看别的小工具，发现大差不差：真正决定能不能用起来的，是例外想没想全、出错时说不说人话，而不是框架搭得漂不漂亮。AI 压低的是试错轮次，判断责任还在人这边。

每周省下的那半小时不算什么，这套顺序我留下来了。