当 AI 说「完成」之后：我如何用契约与独立验证交付真实业务

AI 告诉我「全部通过」时，我真正关心的问题往往才刚开始：

谁定义了完成？谁检查过它？如果换一个不了解实现过程的人，还能不能得到同样的结论？

过去几个月，我在一个创业团队的真实业务中使用多智能体参与需求分析、编码、复审和交付。它们确实提高了生成速度，但也让另一个问题变得更加明显：产出越多，验证就越容易成为瓶颈。

我逐渐形成一个判断：AI 可以参与执行，但可靠交付不能建立在生成者的自述之上。任务契约、独立复审和可复现证据，必须一起工作。

一、开发者自测很必要，但还不够

实施者最了解自己的代码，也最接近运行环境，因此自测是不可省略的责任。但实施者同时也有一个天然盲区：他知道「自己打算做什么」，很容易把「实现符合意图」误认为「实现满足需求」。

多智能体协作并不会自动消除这个盲区。一个智能体生成代码，另一个智能体根据它的总结做检查，如果后者只是复述前者的结论，就等于把同一份未经验证的自述复制了一遍。

我需要的不是更多「看起来已经完成」的报告，而是三种不同的证据：

在一项真实的数据治理与分析任务中，我先把验收条件写成可执行断言，再允许实施开始。

契约制作大约用了 25 分钟。针对旧基线运行后，五项断言按预期失败，分别暴露数据范围、极端值、统计口径等问题；另一项守护基线保持通过，用来证明不应变化的行为没有被误伤。

这里的「红」很重要。如果一份检查在旧问题上也能通过，它就无法证明新实现真的修复了问题。先红后绿，证明的是断言具有区分能力，而不只是会输出成功。

契约随后被冻结。施工过程中如果需求或验收口径需要变化，必须明确修订，而不是悄悄修改检查器去迎合已经写好的实现。

验证流程示意图：冻结契约、施工、全绿、独立复审发现漏项、补强契约与实现、新眼复现六个环节

图 1：从冻结契约到新眼复现的六环节验证流程；橙色标出复审发现的契约外漏项。

这一步的代价很直接：要写契约、准备环境、保存证据。但它把「我觉得我完成了」变成了「这些事先约定的条件现在可以重复检查」。

这项任务的契约和回归测试后来全部转绿，但独立复审并没有就此停止。

复审者发现，漏斗行为均值在一条 Java 累加器路径上漏掉了上限处理。原有检查主要覆盖 XML 中的查询逻辑，没有覆盖 Java 代码里的第二条计算路径。此外，还有一处例外注记指向了错误的查询。

这个发现很有价值，因为它不是因为契约写得不认真，而是因为真实系统总会存在契约尚未覆盖的实现路径。

修复时，我构造极端配对数据做红绿对照，修正实现并补充漏斗面的断言，再由独立复试验证。最终形成的结论不是「下次只要契约写得更全就行」，而是：

契约负责让已知要求可重复检查，独立复审负责发现契约之外的盲区。两者是互补关系，不能相互替代。

这也是我不把多智能体验证理解成「多找几个角色点头」的原因。只有角色能够带来不同的检查视角，分工才有意义。

后来，在一个后台导出验证任务中，我把证据角色进一步拆成 builder、reviewer 和 new-eye，并为冻结契约计算哈希。

独立新眼没有依赖原作者的解释，只拿到一个明确的 commit 和冻结契约哈希，就复现了 11/11 项检查。导出预览数量也与独立 SQL 的结果一致。

证据格式同时记录契约哈希是否匹配，以及全绿以后是否还有新发现。历史证据拒绝被同名覆盖，避免用后来的结果悄悄改写过去。

协作拓扑示意图：planner、builder、reviewer、new-eye 四个角色及职责边界

图 2：planner、builder、reviewer 与 new-eye 的职责、禁止项与证据流向。

这里最重要的不是「11/11」这个数字，而是验证结论开始脱离原作者的上下文：

我不愿意把这段经历写成一套成熟得不得了的「AI 工程神话」。

前置契约有制作成本，独立复审有沟通与复测成本，新眼复现也要求文档、版本和证据保持可携带。小改动可以采用更轻的路径，但涉及生产、数据或多文件变化时，这些成本通常是在为防止返工和事故付费。

我也没有通过严格对照实验证明自己获得了固定的效率提升。不同任务的难度不同，契约制作、环境准备和复审成本还没有完全统一计量。契约全绿以后依然可能漏检，新眼复现也不代表需求本身一定正确。

所以，对这套体系最准确的评价是：它值得继续使用和修正，而不是它已经解决了所有交付问题。

AI 可以帮我写代码、整理方案、跑检查，但它不能替我决定什么叫真实完成，也不能替我承担交付责任。

我在这几个月里学到的，不是怎样让智能体更自信地宣布成功，而是怎样建立一个允许它被证明错了的工作方式：

这就是我理解的多智能体协作：不是让 AI 参与得越多越好，而是让每一份产出都经得起验证，让最后承担责任的人仍然说得清为什么可以交付。