AI 交付里最危险的一句话是：“已经完成。”

因为这句话本身没有证据。AI 可以写得很自信，summary 可以很完整，PR 描述也可以很漂亮，但这些都不等于真实完成。

项目专用 AI 交付流水线必须把“完成”改写成一个证据问题：每条验收标准，分别有什么可复核证据？

这就是 evidence contract。

测试很重要，但不是全部

测试是最重要的证据之一，但不是所有证据。

一个后端函数修复，单元测试和集成测试可能足够。一个前端交互变化，测试之外还需要截图或录屏。一个数据链路修复，可能需要 API 输出、日志、只读 SQL 或队列观察。一个 SketchUp 建模工具，可能需要 design_model diff、bridge trace、top-view screenshot 和 live bridge smoke。

所以问题不应该是“有没有跑测试”，而是“这次交付需要哪些证据”。

证据必须映射到验收标准

很多项目的 evidence gate 只按文件类型检查。例如改了前端就要截图，改了服务就要 data proof。

这已经比没有证据强很多。但更进一步，证据应该映射到 acceptance criteria。

如果验收标准有三条，证据也应该能回答：

  • 第一条由哪个测试或截图证明；
  • 第二条由哪个 API 输出或日志证明；
  • 第三条有没有未覆盖，如果未覆盖，原因是什么。

这样 reviewer 才能判断 AI 是否解决了用户问题，而不只是跑了一些命令。

evidence manifest 应该文件化

证据不应该只留在聊天里。

一个 evidence manifest 可以包含：

  • 任务 ID 或 PR；
  • 变更摘要；
  • 验收标准列表；
  • 每条验收对应的证据；
  • 测试命令和结果；
  • 截图或数据证明路径；
  • 未运行检查及原因；
  • 残余风险；
  • 生成时间；
  • worker 或工具版本。

manifest 不保证正确性，但它保证 reviewer 有东西可查。

不同项目需要不同证据

证据合同必须项目专用。

在 TidalFi 这类系统里，涉及 API、服务、数据库、队列、Redis 或事件流的修改，不能只靠单元测试。它需要 data proof。涉及前端流程的修改，需要截图。涉及发布的修改，需要 release boundary 和 production verification。

在 SketchUp Agent Harness 里，“看起来有模型”不够。需要知道模型从哪里来、结构化 design model 是否一致、bridge trace 是否可解释、SketchUp scene 是否由干净 replay 生成、视觉审阅是否支持 source evidence。

在知识库发布里，“文章生成了”不够。需要 source trace、双语 sibling、series metadata、language switch、site build 和 publication ownership。

没有证据，就不能叫 done

这条规则会改变 AI 的行为。

如果没有证据门禁，AI 会倾向于用自然语言总结完成。如果有 evidence contract，AI 必须在执行过程中主动收集测试结果、截图、日志、trace 和风险说明。

它会更像工程 worker，而不是聊天助手。

结论

AI 交付的完成标准不应该是“AI 认为完成”。

完成应该意味着：任务合同里的验收条件，有对应的证据；没有证据的地方，有明确的未覆盖说明；高风险边界没有被偷偷跨过。

这就是 evidence contract 的价值。