AI worker 很容易写出一句听起来完整的话：“已修复，测试通过。”

但对 reviewer 来说，这句话几乎没有审计价值。

测试是什么？在哪个环境跑的？改了哪些文件？覆盖了用户问题吗？有哪些检查没有跑？风险还剩什么？如果是 UI 问题，有截图吗？如果是数据链路问题，有数据证明吗？

这就是 evidence gate 的意义：AI PR 不能只交付代码，还必须交付证据包。

Evidence 是 review 输入，不是自我证明

Evidence gate 不是让 AI 证明“我一定对”。

它的目标更务实：让 reviewer 知道 AI 实际做了什么、验证了什么、没有验证什么。

一个最小 evidence bundle 应该包括：

  • linked issue；
  • 变更摘要；
  • 变更文件；
  • 测试命令和结果；
  • 静态检查命令和结果；
  • 手工验证；
  • 未运行检查及原因；
  • 残余风险；
  • 触发过的停工条件；
  • release 或 production verification 是否还需要 human。

这些信息可以放在 PR body，也可以放在单独的 evidence manifest。关键是它必须持久、可复制、可被 reviewer 引用，而不是只存在于聊天窗口。

不同类型的变更需要不同证据

不是所有 PR 都需要同一种 evidence。

纯文档修改，也许只需要说明影响范围和链接检查。

前端行为修改，通常需要截图或录屏，至少覆盖关键状态和重要 viewport。

API 或服务逻辑修改，需要测试输出、curl 示例、日志片段或 contract 说明。

数据库、队列、缓存、事件流相关修改，需要数据链路证明，而不是只说“单测通过”。

安全、权限、支付、交易、风控、合规相关修改，通常不应该只靠 AI evidence 进入合并，而应该升级为 human review required。

Evidence gate 的核心不是“证据越多越好”，而是证据类型要匹配风险类型。

Evidence 应该记录没有做的事

优秀的 AI evidence 不应该只列通过项。

它也要列没有做的检查。

例如：

Skipped: browser screenshot
Reason: this change only updates backend validation copy

Skipped: e2e suite
Reason: not available locally; unit coverage added instead

Remaining risk: production data shape not verified
Next human action: verify against staging data before release

这类信息对 reviewer 很重要。

没有做的检查并不一定意味着 PR 不能合并。但如果它被隐藏，reviewer 会误以为验证更充分。

Evidence gate 会改变 AI 的行为

如果 worker 知道最后必须提交 evidence，它在实现时会更克制。

它会倾向于做更小的 patch，因为小 patch 更容易验证。它会更愿意补测试，因为 evidence 需要可复核命令。它也会在风险扩大时停下来，因为无法提供足够 evidence。

这就是 gate 的实际价值：它不只是 review 阶段的检查表，它会反向约束 AI 的实现方式。

最小模板

第一版 evidence manifest 可以很简单：

issue:
  number:
  automation_mode:
  branch:

changes:
  summary:
  files_changed:

verification:
  tests_run:
  static_checks:
  manual_checks:
  skipped_checks:

risk:
  risk_notes:
  release_required:
  production_verification_required:

review:
  pr_url:
  final_state:

这个模板不复杂，但它迫使 AI 把“我做完了”拆成可审计事实。

AI PR 的质量，不应该只看 diff。还要看 evidence 是否足以让 human 判断：这个 PR 是否真的覆盖了 issue contract，以及哪里还需要人接手。