新西兰 AI 技术落地实践案例：一家建筑公司发票自动分流 91% 的三个月实录

原来每个月初，发票是怎么处理的？

客户的系统很典型：发票进 Outlook，文件存 OneDrive，审批走 ApprovalMax，记账在 Xero。每月 26 日到次月 3 日是跨月窗口，月初两三天可能压着 600 到 700 张，QS 要逐张判断工地、项目类型、采购单和审批人。审批人和工地的对应关系不在任何文档里，在几个人的经验里。

我们接进了什么？

原则是连接而不是替换：一个系统都没换。Agent 跑在客户办公室的一台 Mac mini 上，用 OpenClaw 调度，通过只读邮件权限监听专用发票邮箱，识别、归档、匹配 PO、提交审批、每小时回写状态。人留在三个地方：QS 处理人工队列，项目经理在 ApprovalMax 里审批，财务在 Xero 里付款和锁账。AI 不批、不付、不改账。

第一个月：问题不在识别率，在规则

7 月 21 日第一次量化：407 张候选发票只有 63 张进入审批，完成率 15.5%。拆开看，真正识别失败只有 12 张，不到 3%；卡住的是 173 张规则不完善和 132 张信息缺失。模型读发票读得很好，读完不知道该交给谁。7 月 27 日我们把 111 张问题发票归成 7 类，请客户逐类书面确认处理方式，工作流恢复自动运行。

发票到底有多少张？

8 月初，发票总数这个最朴素的数字对不上了：7 月记录从 369 张变成 460、815，最后确认标准发票 517 张。根因是识别、拆分、去重混在一条流水线里，加上一次“清理已处理的 6 月发票”指令被 Agent 按发票日期而非接收日期执行，误清了部分 7 月发票（有备份，当天找回）。改法是把总账做成逐层可对账的审计链，仪表盘从此分成“上一周期正式结果”和“当前周期进行中”两块。

8 月 4 日的转向：先保证不断流

8 月初我们意识到方向偏了：工程师一直在优化识别规则让更多发票自动通过，而客户要的是业务先不断流。AI 判断不了的发票，哪怕信息不全，也要有序分到对应的人手里，而不是堆进一个 Manual Review 黑箱。这是整个项目最重要的一次转向，之后的设计都围绕“剩下的那部分怎么交给人”。

8 月：全量校准

8 月下旬收口，人工复核队列从 300 多份降到 181、110、81。8 月 30 日交付口径：自然月 775 份，694 份自动分流，89.55%。9 月 1 日按客户会计周期（7 月 26 日到 8 月 25 日）重算：798 份，730 份自动分流，人工复核 68 份，91.48%。两个口径都写在这里，因为客户看会计月，我们内部看自然月。

谁能看金额，谁不能？

仪表盘做了两版：Admin 版给老板和财务，含金额；审批人版只看自己名下待办，不含金额。多维表格里建了 Approver、Admin、AI Master 三个角色，Agent 用 AI Master 身份写数据，看不到不该看的。

平台的边界，AI 不越

9 月 1 日客户需要把一批 7 月发票的日期改到 8 月。ApprovalMax 允许改日期，但改完审批流程重置，而 API 没有 approve 接口。我们对 37 份执行：19 份成功，9 份权限冲突跳过，9 份已 rejected 不再动。重置后的审批由有权限的人手动点。这条后来写进交付规则：凡是审批、付款、对外承诺，AI 准备、AI 核对，人最后一按。

三个月留下的四条教训

回头看，最贵的不是技术，是这四个判断。

• 只看识别率会走错方向：识别失败不到 3%，完成率却只有 15.5%。真正的工作量在规则和映射，问不出来的要设计成人工路径。
• 总账要有独立的审计链：“到底收到多少张”答不上来，信任会立刻回到零。识别、去重、统计分层，每层能对账。
• AI 按字面执行指令：涉及删除的指令要先试跑、有备份、有第二个数据源交叉。
• 把过程讲给客户听：从“功能做完”转向“业务跑通”，少用开放式提问，多用固定步骤和选择题，主动发现并闭环问题。

现在怎样了？

8 月 30 日技术阶段交付，9 月进入优化期：修审批提醒重复、供应商归类误判、锁账后的日期调整。最好的验收不是数字：9 月初客户把我们介绍给了他们合作的建筑保险经纪，另一个“文档重、合规重”的行业。

证据边界：本文所有数字来自项目群聊记录与 9 月 2 日项目复盘文档，日期均已标注；91.48% 按客户会计周期统计，89.55% 按自然月统计，两者分母都包含非发票类文件。客户为新西兰建筑总承包商，已匿名；截图中的公司名与人名已裁除或遮盖，含金额的仪表盘未采用。