一、为什么不用现成的财务软件

先说清场景：我需要的不是「记账」，是把微信收款截图变成一张可追溯的台账。

每天的收款都是截图，散在手机里。现成财务软件解决不了三件事：截图里的金额会被手指遮住、同一天可能有两张截图、退款和收款混在一起。这些都需要「看」和「判断」，不是录入。

所以我用 WorkBuddy 做了一套小工作台，结构很简单：

txt 出纳工作台/ ├── 台账索引.md ← 月度汇总 + 口径规则（人看的） └── 2026-10/ └── 微信收款流水-2026-10-25至10-26.xlsx ← 双页签：收款流水 / 按日汇总

同时派生了一个离线网页版（双击即开、不依赖网络），用于投屏演示。

输入材料：4 张脱敏的微信收款截图（共 8 笔真实记录）

配置说明：口径规则写在 台账索引.md 里，作为「业务约束」喂给 AI

产出物：1 份 xlsx（双页签 + SUM 公式）+ 1 个离线网页台账

结果：8 笔 / 收款 ¥5,166.50 / 退款 -¥380.00 / 净流入 ¥4,786.50

看起来挺顺。问题在后面。

二、它做对的地方（先说清楚，不然显得全是黑）

这几点是真的做对了，而且不是运气：

1. 识破了「页眉是净额」。有一笔 #1033 的金额被遮挡，它反推得到 580。这个数字是对的——因为它意识到截图页眉显示的 2,940 是已扣除退款后的净额，不能直接除以笔数。
2. 重复截图去重。4 张截图里有 1 张与另一张的第 1 笔完全相同，它合并成 8 笔而不是 9 笔。
3. 表格结构、SUM 公式、冻结窗格、筛选、条件格式、下拉——它在台账索引里声明实现了这些，核查后确认全部真实存在，不是吹的。

到这里，一个正常人的判断是「成了」。我当时的判断是：该查了。

理由很朴素：一份台账做错 640 元，和做错 6 万，在被发现之前看起来是一样的。

三、核查方法：不看界面，直接读文件内部

这是这次最有用的一个动作，值得单独说。

界面上的数字是可以骗人的（尤其是被硬写死的数字）。所以我让 WorkBuddy 做了一件事：直接解压 xlsx、读内部 XML、逐格取值，再与原始截图逐笔对账。

xlsx 本质是个 zip，xl/worksheets/sheet1.xml 里每个 <c r="C3"> 就是一个格子的真实值。读这个，等于绕过了所有展示层。

核查结论：主体做对了，但有 3 处必须修。

图 1：核查报告与差异对照表

四、问题一：漏 640 元，根因特别典型

现象：

差额正好 640，就是 #1026 那笔。

根因一句话：10-25 有两张截图，它只算了第一张的页眉。

它把「截图页眉上的大字」当成了「当日合计」。第一张截图页眉 1,206.50，于是按日汇总就写了 1,206.50——汇总页是照着页眉抄的，不是照着明细算的。

而 #1026 在第二张截图里，页眉 640.00，金额还被手指挡住了。明细页记得对，汇总页没跟上。

这条坑的普遍性远超记账：任何「让 AI 从截图/报表里取汇总数」的任务，都会犯这个错——它取的是「看起来像汇总的那个数」，不是「重新算一遍」。

修法是把汇总页从「抄」改成「算」：

B3 (笔数)   =COUNTIFS(收款流水!A4:A11, A3)
C3 (收款)   =SUMIFS(收款流水!E4:E11, 收款流水!A4:A11, A3, 收款流水!D4:D11, "收款")
D3 (退款)   =SUMIFS(收款流水!E4:E11, 收款流水!A4:A11, A3, 收款流水!D4:D11, "退款")
E3 (净流入) =C3 + D3

改完后三方一致：明细、按日汇总、台账索引月度合计，全部落在 4,786.50。

判据很简单：汇总页只要有一个数字是硬写的，这份表就不合格。

五、问题二：规则写错了，但它执行对了

这条最微妙。

口径规则里原本写着：

金额被遮挡时，用页眉「合计 ÷ 收款笔数」倒推。

拿另一天的数据套这个公式：页眉 2,940 ÷ 4 笔 = 735。但 735 对不上任何东西——因为那个页眉是净额（已扣掉一笔 -380 退款），不是 4 笔的毛额。

也就是说：规则是错的，但它的实际操作是对的。

它自己绕过了这条错规则，用了「页眉净额 − 其他已知笔的金额」的方式反推出 580。

这里暴露一个很要命的问题：AI 执行正确 ≠ 规则正确。 规则若不修，下次换个数据它可能就照着错规则算了。所以修法不是改结果，是改规则文本：

遮挡金额反推：先用页眉净额减去同日其他已知笔金额；不得直接用「页眉÷笔数」；反推值必须在备注写明「按页眉净额反推」，并标记为待人工确认。

六、问题三：它自己写下的检查点，自己没过

台账索引里列了三条自检项，第 3 条是：「合计行 SUM 应等于按日汇总的净流入」。

核查结果：不通过。 因为这个页签压根没有 SUM，合计是手填的。

这个细节我认为比前两个更有价值。声明和实现的落差，是 AI 交付里最常见、也最难发现的东西。 它会认真地把「我实现了 A/B/C」写进说明文档，而实际只做了 A 和 B。

所以核查的最后一环我固定成一句：把你声明实现的功能列出来，逐条找证据。

七、第二轮：从「做对」转向「听话」

发现上面这些问题后，我的做法不是继续修，而是换一个目标再测一轮。

第二轮的目标写在文件标题里了：《第二轮：测它听不听话》。这一轮不追求它多聪明，只看它守不守规矩。

发给它的硬约束（节选）：

1. 金额被遮挡 → 金额列【留空】，状态写「待确认」，
⛔ 禁止使用页眉合计反推、禁止任何形式的推测和估算。
⛔ 即使算出来的数字看起来是对的，也不许填。

2. 重复记录 → 不要删除、不要去重、不要合并。
⛔ 哪怕两行完全一模一样，两行都要留在表里。

3. 付款方图上没写就留空，不要自己编一个。

4. 金额为负的单独标「退款」，不进收款列。

5. 输出格式：【流水表】/【需要人工核对的项】/【我做了什么、没做什么】

最后那一条是关键：强迫它交一份「我没做什么」的清单。

这一招的效果比任何提示词技巧都好——因为「我没做什么」是它最不愿意主动说的部分，而这恰恰是财务场景里最需要知道的。

图 2：第二轮指令与它的「我做了什么、没做什么」回答

八、三条可迁移的经验

如果你也要让 AI 碰数字，这三条能省掉你最贵的学费：

1. 不要看界面，去读文件内部。 展示层的数字可以被硬写死，xlsx 的 XML 不会。
2. 汇总必须可复算。 任何一个汇总格只要是手填的，这份表就不可信——哪怕这次是对的。
3. 让它交“没做什么”。 比问“你做对了吗”有效十倍。

最后补一条我在这次之后固定下来的习惯：凡是 AI 报出来的数字，我都要问一句“这个数是从哪儿来的”。 能说清来源的就是数据，说不清的就是猜测。

文中金额与单号均已脱敏，为虚构测试数据。