夜雨聆风上一篇文章我写到，行政部门很多 AI 场景，其实藏在每天重复处理的 Excel 里。
那篇文章里提到过一个采购对账的例子，但只是点到为止。今天我想把这个场景单独拆开讲一讲。
采购对账这个活很典型。
它不是让 AI 帮忙写一段话，也不是让 AI 总结一个文件。它牵扯到两边系统的明细、采购订单、行号、数量、开票状态，还要决定哪些可以直接进入结果表，哪些必须拿出来让人复核。
如果业务同事只说一句：“帮我做个采购对账工具。”
AI Agent 也许能很快搭出一个页面，但字段取错、辅助列当成原始列、异常边界漏掉，后面一定会反复返工。
这不是代码写得快不快的问题。
问题在于：你每天坐在电脑前怎么对这张表，AI 一开始并不知道。
你先看哪张表，哪几列是原始字段，哪几列是后来加的辅助列，用什么字段拼编码，数量差多少要单独拎出来，哪些情况可以进可开票明细，哪些情况必须让人再看一眼。
这些不说清楚，工具就会按它理解的一套处理，和你手上真正的对账动作对不上。
后来这个工具真的做出来以后，我反而觉得首屏不用设计得很复杂。
它只要把三件事摆清楚：业务同事上传哪张表，旁边能看到这张表会按哪些规则处理，结果区能看到最后生成哪些明细和汇总。
所以页面上最显眼的那句话就是：上传一张表，自动生成两张可开票明细。
右边也不写大而全的功能介绍，就把规则执行顺序摆出来：先按采购订单号和行号分组，再过滤数量差异，最后输出结果工作簿。
这比在需求文档里写一堆“自动对账”“自动识别”更实在。人一看就知道，这个工具不是靠模型自己判断，而是在执行一套已经说清楚的对账规则。
不是“帮我对一下”
采购对账这类表，表面上看就是两份明细互相核一核：这边有没有，那边有没有，数量对不对，最后能不能开票。
但一打开文件就能看到，麻烦不在“看一眼”。
麻烦在字段名不一样，系统口径不一样，有些列是系统原始导出来的，有些列是业务同事为了方便核对后来加的。表里还会混着公式列、备注列、历史判断列，外人第一次打开，很难马上分清哪些能作为输入，哪些只是这一次处理留下来的痕迹。
AI 也是一样。
你把一份已经处理过的 Excel 给它，它会看到很多列，但它不知道这些列是系统导出来的，还是你为了对账手工加的。
比如对账时常见的辅助列：采购订单号+行号、交货单号+行号、物料凭证号+行号、数量差异、是否开票。
这些列对人工对账很有用，但它们不一定存在于下一次重新导出的原始明细里。
如果工具把这些列当成原始输入，下次只拿到未加工的表，关键列就找不到，结果也会跟着偏。
所以做采购对账小工具，第一步不是生成页面，也不是急着写代码。
第一步是把表拆清楚。
先把三类东西拆开
我现在看这类表，会先把问题问得细一点。不是简单问“这个表有什么字段”，而是先把三类东西分开。
第一类，是每个月都会重新导出的原始输入。
比如 SAP 侧有哪些 sheet，SRM 侧有哪些 sheet；每张 sheet 里哪些字段来自系统原表；采购订单号、行号、物料、数量、交货单号、物料凭证号分别叫什么。字段名字可以不一样，但业务含义要对上。
这里最怕的是只看列名。
有些字段名字看起来接近，但业务含义不一样；有些字段名字不一样，但实际指向同一件事。这个时候要让业务同事把“我平时到底用哪两列拼编码”说出来，而不是让工具自己从列名里推。
第二类，是人工处理过程中加出来的东西。
比如把采购订单号和行号拼成一个编码，把交货单号和行号拼成另一个编码，再用这些编码去查另一张表。还有数量差异、是否开票、异常原因，这些很多时候不是原始输入，而是人处理过程中一步步算出来的。
这些列不是不能用。
恰恰相反，它们很重要。因为它们暴露了业务同事平时怎么判断。
但做工具时要多问一句：下次原始表里有没有这一列？如果没有，工具能不能自己生成？生成规则是什么？用哪两列拼？行号要不要补零？空值怎么处理？
第三类，是最后要交付出去的结果。
是只要一张可开票明细，还是要同时输出异常明细、汇总表、对不上原因？字段顺序要不要固定？表头和格式要不要保留？文件名有没有命名规则？结果要给采购看，还是要给财务复核？
这三个问题问完，需求才从“帮我对一下”变成一件具体的事：
从 SAP 和 SRM 的原始明细里，自动生成必要的辅助编码，按采购订单号和行号匹配，再核数量。能确认的进入可开票明细，不能确认的进入异常明细。
提示词 1：先让 AI 看懂表
这一步我不会让 AI 先写代码。
先让它把工作簿看明白，尤其要分清输入表、结果表、原始字段和人工辅助字段。
正文里不再铺大段代码块，我把可直接参考的提示词做成了卡片：
这一步看起来慢，其实能少很多返工。
如果一开始就把结果表当成输入表，把公式列当成原始列，后面页面做得再漂亮，也只是把错误包装得更好看。
提示词 2：把辅助列拆出来
这个案例里，辅助列很关键。
它们不是系统原始字段，但能看出业务同事平时怎么对账。比如采购订单号和行号怎么拼、数量差异怎么来、是否开票这一列到底是谁算出来的。
所以第二步，我会让 AI 专门把这些列拆出来，而不是把整张表当成一堆普通字段处理。
这一段提示词很适合给业务同事看。
因为很多时候，业务同事并不是不知道规则，而是没有意识到“我后来加的这几列”也要写进需求里。
把人工动作说出来
很多业务同事不是不会讲。
他每天都在做这件事，手上很熟。
真正麻烦的是：让他一口气写成需求文档，他可能没耐心，也不知道该从哪里写。
这时候我反而建议先别写，先说。
用 Typeless、闪电书这类语音输入工具，把自己平时怎么对账从头到尾说一遍：我先打开哪张表，我会看哪几列，这两列要拼成什么编码，拼完以后去另一张表查什么，数量一致时怎么处理，数量不一致时怎么处理，碰到重复、缺失、空值时怎么办，最后要生成哪几张表、给谁看。
类似这样一段口语，其实就已经很有用：
SAP 这边有采购凭证和采购凭证项目号，这两个要拼成采购订单号加行号；SRM 这边用采购订单号和采购订单行号拼成同样的编码。两边编码能对应上以后，再看数量差异。数量一致的进入可开票明细；数量不一致、缺失、重复匹配的，不要自动放进结果表，要放到异常里让人复核。
这段话如果靠打字，很多人嫌麻烦。
但用语音说出来，反而很自然。
说完以后，再让 AI 帮你整理成结构化规则。
业务人员负责把真实动作讲出来，AI 负责把这些话整理成能继续往下做的说明。
这比让业务同事憋半天写一段“请帮我实现采购对账自动化”要现实得多。
对账规则要写到能验收
采购对账里，有一条边界要守住：AI 不能替业务拍板。
能开票还是不能开票，不能让模型看着两行数据说“我觉得可以”。
它能做的是按你说清楚的规则执行。
比如这次对账，关键就落在“采购订单号 + 行号”上。
两边系统字段名可能不一样，一边叫采购凭证和项目号，另一边叫采购订单号和订单行号。名字不一样没关系，业务含义能对上就行。
工具要先从两边原始字段里拼出同一类关键编码，再拿这个编码去匹配。
匹配上以后，再看数量。
数量一致，而且没有重复、缺失、冲突，就可以进入可开票明细。
一边有一边没有、数量不一致、同一个编码匹配到多行，或者出现人都需要停下来看的情况，就不要硬判，直接放到异常明细里。
这一步看起来保守，但对业务更安全。
工具不是为了显得聪明，而是为了把确定的事情按固定规则处理完，把不确定的事情摆在明处。
所以需求里不能只写“判断是否开票”。
我会把它写成两条很硬的规则：采购订单号加行号在两边都存在，并且数量一致，才进入可开票明细；只在一边存在、数量不一致、重复匹配或无法唯一确认，就进入异常明细，并写明异常原因。
写到这一步，后面才好验收。
因为你可以拿旧样例去对：哪些应该进可开票明细，哪些应该进异常明细，数量合计对不对，异常原因有没有写清楚。
提示词 4：整理成规则说明
人工动作说完以后，我会让 AI 先生成一份规则说明，而不是直接写页面。
这份规则说明后面可以交给 Codex、WorkBuddy、Trae、CodeBuddy 这类工具继续用。
有了这份文档，后面做工具才不是一边写一边补口径。
可以直接按这个模板写
如果你手上也有类似的对账表，可以先不用想工具怎么做。
先把需求写成下面这个顺序：
我现在手工在做什么：现在每次对账从哪张表开始，依次做哪些动作。 输入文件是什么：所有输入文件、子表名、关键字段，哪些字段是系统原始导出的。 人工辅助列有哪些：平时自己新增的编码列、公式列、判断列，每一列怎么生成。 匹配规则是什么：按哪个字段或组合字段匹配，字段名不一致时业务含义怎么对应。 可开票规则是什么：什么情况进入可开票明细，比如两边都存在、唯一匹配、数量一致。 异常情况怎么处理：数量不一致、一边缺失、重复匹配、空值、无法判断时，分别放到哪里。 输出结果是什么：可开票明细、异常明细、汇总表等，每张表需要哪些字段和格式。 验收样例是什么：提供一份人工处理过的正确结果，对比行数、数量合计、开票状态、异常原因和输出格式。
这个模板不复杂，但它能把需求拉回到具体动作上。
如果第 2、3、4、5、6 条讲不清楚，工具先别急着做。否则做完以后还会反复改。
提示词 5：先做测试，不要先做页面
很多人做 AI 小工具，容易一上来就说：做一个网页，上传 Excel，然后下载结果。
页面当然重要，但不是第一步。
第一步应该是验证规则。
在这个采购对账案例里，我更愿意先让 AI 写测试脚本。旧样例、新样例、删除辅助列后的样例，都要对一遍。
这一步的意义是：先证明工具算得对。
如果没有测试，页面做得再好看，也可能只是看上去能用。
用旧样例验收
采购对账工具做完以后，不能只看界面好不好看。
也不能只看它生成了一张结果表，就觉得完成了。
我更愿意用旧样例验收。
找一份以前人工处理过、结果已经确认的样例。把里面人工新增的辅助列先拿掉，只保留新月份也会导出的原始字段。
然后让工具执行一次。
它能不能自动生成编码？
能不能按规则匹配？
可开票明细对不对？
异常明细有没有漏？
数量合计、行数、开票状态、异常原因，能不能和人工结果对上？
这些都对得上，才说明工具真的读懂了规则。
我这次工具执行完以后，结果区没有做花哨展示，只放了几类最该看的东西：两边可开票行数、两边可开票数量、编码来源，还有被跳过的行。
这些数字不是为了给文章凑“战绩”，而是为了让业务同事能复核。
比如看到两边数量一致，心里会踏实一点；看到有多少行被跳过，也知道后面要不要回头查原表。这里的数字留在截图里，正文不展开成公开结论；真实 sheet 名里的敏感字眼已经打码处理。
如果对不上，就先回去看需求说明。
是不是某个辅助列没说清楚？
是不是字段名对应错了？
是不是异常边界漏了一种情况？
是不是验收口径变了，但没有同步写进规则？
对账工具最怕的不是一开始做得慢，而是规则没写清楚就上线，后面每个月都靠人盯着补锅。
提示词 6：测试通过后，再做网页工具
规则说明和测试都过了，再让 AI 做网页工具。
这时提示词就可以写得很具体：页面上传什么文件，内部先做哪些预处理，最后生成哪些明细和汇总，界面上显示哪些复核指标，下载结果时不要覆盖原始文件。
这个提示词在 Codex 里可以直接用。
在 WorkBuddy、Trae、CodeBuddy 这类工具里，也可以按同样思路使用。差别只是工具界面不同，核心输入仍然是这些规则。
先把手上的规则讲明白
这个采购对账案例给我最大的提醒是：很多业务部门的 Excel 工作，并不是没有规则。
相反，它们规则很明确。
只是这些规则长期藏在人工筛选里、Excel 公式里、老员工经验里，也藏在每个月重复做的动作里。
AI 真正能帮上的地方，不是替业务人员做开票判断，而是帮业务人员把这些规则摊开、写清楚，变成测试，再变成一个可以反复使用的小工具。
这件事不要求业务人员一开始就会编程。
第一步只需要做一件事：把你每天怎么处理这张表讲清楚。
可以打字。
也可以用 Typeless、闪电书这样的语音输入说出来。
然后让 AI 帮你整理规则、生成测试、实现工具。
下次再遇到一张采购对账表，不要先问：AI 能不能帮我做个工具？
可以先问一个更具体的问题：
如果今天来一个新同事，我能不能把这张表怎么对、怎么判断、怎么验收，讲到他照着做也不容易出错？
如果能讲到这个程度，AI 才真的有机会把它做顺。
附上今日运动打卡🏃我是活人：
