【AI小知识】一张采购对账表,怎么变成 AI 小工具

我现在看这类表，会先把问题问得细一点。不是简单问“这个表有什么字段”，而是先把三类东西分开。第一类，是每个月都会重新导出的原始输入。

比如SAP侧有哪些sheet，SRM侧有哪些sheet；每张sheet里哪些字段来自系统原表；采购订单号、行号、物料、数量、交货单号、物料凭证号分别叫什么。字段名字可以不一样，但业务含义要对上。

这里最怕的是只看列名。

有些字段名字看起来接近，但业务含义不一样；有些字段名字不一样，但实际指向同一件事。这个时候要让业务同事把“我平时到底用哪两列拼编码”说出来，而不是让工具自己从列名里推。

第二类，是人工处理过程中加出来的东西。

比如把采购订单号和行号拼成一个编码，把交货单号和行号拼成另一个编码，再用这些编码去查另一张表。还有数量差异、是否开票、异常原因，这些很多时候不是原始输入，而是人处理过程中一步步算出来的。

这些列不是不能用。

恰恰相反，它们很重要。因为它们暴露了业务同事平时怎么判断。

但做工具时要多问一句：下次原始表里有没有这一列？如果没有，工具能不能自己生成？生成规则是什么？用哪两列拼？行号要不要补零？空值怎么处理？

第三类，是最后要交付出去的结果。

是只要一张可开票明细，还是要同时输出异常明细、汇总表、对不上原因？字段顺序要不要固定？表头和格式要不要保留？文件名有没有命名规则？结果要给采购看，还是要给财务复核？

这三个问题问完，需求才从“帮我对一下”变成一件具体的事：

从SAP和SRM的原始明细里，自动生成必要的辅助编码，按采购订单号和行号匹配，再核数量。能确认的进入可开票明细，不能确认的进入异常明细。

这一步我不会让 AI 先写代码。

这一步看起来慢，其实能少很多返工。

如果一开始就把结果表当成输入表，把公式列当成原始列，后面页面做得再漂亮，也只是把错误包装得更好看。

这个案例里，辅助列很关键。

它们不是系统原始字段，但能看出业务同事平时怎么对账。比如采购订单号和行号怎么拼、数量差异怎么来、是否开票这一列到底是谁算出来的。

所以第二步，我会让AI专门把这些列拆出来，而不是把整张表当成一堆普通字段处理。

这一段提示词很适合给业务同事看。

因为很多时候，业务同事并不是不知道规则，而是没有意识到“我后来加的这几列”也要写进需求里。

很多业务同事不是不会讲。

他每天都在做这件事，手上很熟。

真正麻烦的是：让他一口气写成需求文档，他可能没耐心，也不知道该从哪里写。

这时候我反而建议先别写，先说。

用Typeless、闪电书这类语音输入工具，把自己平时怎么对账从头到尾说一遍：我先打开哪张表，我会看哪几列，这两列要拼成什么编码，拼完以后去另一张表查什么，数量一致时怎么处理，数量不一致时怎么处理，碰到重复、缺失、空值时怎么办，最后要生成哪几张表、给谁看。

类似这样一段口语，其实就已经很有用：

SAP这边有采购凭证和采购凭证项目号，这两个要拼成采购订单号加行号；SRM这边用采购订单号和采购订单行号拼成同样的编码。两边编码能对应上以后，再看数量差异。数量一致的进入可开票明细；数量不一致、缺失、重复匹配的，不要自动放进结果表，要放到异常里让人复核。

这段话如果靠打字，很多人嫌麻烦。

但用语音说出来，反而很自然。

说完以后，再让AI帮你整理成结构化规则。

业务人员负责把真实动作讲出来， AI 负责把这些话整理成能继续往下做的说明。

这比让业务同事憋半天写一段“请帮我实现采购对账自动化”要现实得多。

采购对账里，有一条边界要守住：AI不能替业务拍板。

能开票还是不能开票，不能让模型看着两行数据说“我觉得可以”。

它能做的是按你说清楚的规则执行。

比如这次对账，关键就落在“采购订单号+行号”上。

两边系统字段名可能不一样，一边叫采购凭证和项目号，另一边叫采购订单号和订单行号。名字不一样没关系，业务含义能对上就行。

工具要先从两边原始字段里拼出同一类关键编码，再拿这个编码去匹配。

匹配上以后，再看数量。

数量一致，而且没有重复、缺失、冲突，就可以进入可开票明细。

一边有一边没有、数量不一致、同一个编码匹配到多行，或者出现人都需要停下来看的情况，就不要硬判，直接放到异常明细里。

这一步看起来保守，但对业务更安全。

工具不是为了显得聪明，而是为了把确定的事情按固定规则处理完，把不确定的事情摆在明处。

所以需求里不能只写“判断是否开票”。

我会把它写成两条很硬的规则：采购订单号加行号在两边都存在，并且数量一致，才进入可开票明细；只在一边存在、数量不一致、重复匹配或无法唯一确认，就进入异常明细，并写明异常原因。

写到这一步，后面才好验收。

因为你可以拿旧样例去对：哪些应该进可开票明细，哪些应该进异常明细，数量合计对不对，异常原因有没有写清楚。

人工动作说完以后，我会让AI先生成一份规则说明，而不是直接写页面。

这份规则说明后面可以交给WorkBuddy、Trae、CodeBuddy这类工具继续用。

有了这份文档，后面做工具才不是一边写一边补口径。

如果你手上也有类似的对账表，可以先不用想工具怎么做。

先把需求写成下面这个顺序：

1. 我现在手工在做什么：现在每次对账从哪张表开始，依次做哪些动作。

2. 输入文件是什么：所有输入文件、子表名、关键字段，哪些字段是系统原始导出的。

3. 人工辅助列有哪些：平时自己新增的编码列、公式列、判断列，每一列怎么生成。

4.匹配规则是什么：按哪个字段或组合字段匹配，字段名不一致时业务含义怎么对应。

5. 可开票规则是什么：什么情况进入可开票明细，比如两边都存在、唯一匹配、数量一致。

6. 异常情况怎么处理：数量不一致、一边缺失、重复匹配、空值、无法判断时，分别放到哪里。

7. 输出结果是什么：可开票明细、异常明细、汇总表等，每张表需要哪些字段和格式。

8. 验收样例是什么：提供一份人工处理过的正确结果，对比行数、数量合计、开票状态、异常原因和输出格式。

这个模板不复杂，但它能把需求拉回到具体动作上。

如果第2、3、4、5、6 条讲不清楚，工具先别急着做。否则做完以后还会反复改。

很多人做AI小工具，容易一上来就说：做一个网页，上传Excel，然后下载结果。

页面当然重要，但不是第一步。

第一步应该是验证规则。

在这个采购对账案例里，我更愿意先让AI写测试脚本。旧样例、新样例、删除辅助列后的样例，都要对一遍。

这一步的意义是：先证明工具算得对。

如果没有测试，页面做得再好看，也可能只是看上去能用。

采购对账工具做完以后，不能只看界面好不好看。

也不能只看它生成了一张结果表，就觉得完成了。

我更愿意用旧样例验收。

找一份以前人工处理过、结果已经确认的样例。把里面人工新增的辅助列先拿掉，只保留新月份也会导出的原始字段。

然后让工具执行一次。

它能不能自动生成编码？

能不能按规则匹配？

可开票明细对不对？

异常明细有没有漏？

数量合计、行数、开票状态、异常原因，能不能和人工结果对上？

这些都对得上，才说明工具真的读懂了规则。

我这次工具执行完以后，结果区没有做花哨展示，只放了几类最该看的东西：两边可开票行数、两边可开票数量、编码来源，还有被跳过的行。

这些数字不是为了给文章凑“战绩”，而是为了让业务同事能复核。

比如看到两边数量一致，心里会踏实一点；看到有多少行被跳过，也知道后面要不要回头查原表。这里的数字留在截图里，正文不展开成公开结论；真实sheet名里的敏感字眼已经打码处理。

如果对不上，就先回去看需求说明。

是不是某个辅助列没说清楚？

是不是字段名对应错了？

是不是异常边界漏了一种情况？

是不是验收口径变了，但没有同步写进规则？

对账工具最怕的不是一开始做得慢，而是规则没写清楚就上线，后面每个月都靠人盯着补锅。

规则说明和测试都过了，再让AI做网页工具。

这时提示词就可以写得很具体：页面上传什么文件，内部先做哪些预处理，最后生成哪些明细和汇总，界面上显示哪些复核指标，下载结果时不要覆盖原始文件。

这个提示词可以直接用。

在WorkBuddy、Trae、CodeBuddy这类工具里，也可以按同样思路使用。差别只是工具界面不同，核心输入仍然是这些规则。

这个采购对账案例给我最大的提醒是：很多业务部门的Excel工作，并不是没有规则。

相反，它们规则很明确。

只是这些规则长期藏在人工筛选里、Excel公式里、老员工经验里，也藏在每个月重复做的动作里。

AI真正能帮上的地方，不是替业务人员做开票判断，而是帮业务人员把这些规则摊开、写清楚，变成测试，再变成一个可以反复使用的小工具。

这件事不要求业务人员一开始就会编程。

第一步只需要做一件事：把你每天怎么处理这张表讲清楚。

可以打字。

也可以用Typeless、闪电书这样的语音输入说出来。

然后让AI帮你整理规则、生成测试、实现工具。

下次再遇到一张采购对账表，不要先问：AI 能不能帮我做个工具？

可以先问一个更具体的问题：

如果今天来一个新同事，我能不能把这张表怎么对、怎么判断、怎么验收，讲到他照着做也不容易出错？

如果能讲到这个程度，AI 才真的有机会把它做顺。