指南 · 安全地让 AI 交付
AI 写的 PR，怎样才能放心让它自己合并
让 agent 开 PR 很容易；让它自己合并，需要一道不只看测试是否变绿的闸。这页按 Orbi 的实际工作流，拆开 AI 写的 PR 合并前要过的四道门。
问题在哪里
为什么不能只说「CI 绿了，合并」
agent 可以开出一个测试通过、却漏掉验收细节的 PR。如果唯一的决定依据是绿色 CI，就没人核对 diff 是否满足 Issue、是否经过独立评审，也没人确认分支是不是基于最新代码。
真正安全的问题不是「agent 跑测试了吗」，而是「哪个精确、审过的 head 过了所有门」。
合并闸
AI 的 PR 合并前要过四道门
规则来自 Orbi workflow；评审对照的是 Issue 里写的验收项：
- 01 · 独立结论另开的评审会话给出 clean verdict
结论绑定 PR 当前 head。verdict 里的 head 不是 PR head，就没有合并授权。
- 02 · 最新 BASE审过的 head 包含最新 base
审一个过时分支，不等于审现在要落地的代码；分支必须含最新 base branch。
- 03 · CI 已结束CI 已经有结论
CI 还在 pending，就等下一轮。检查仍在运行时，不能提前当成通过。
- 04 · HEAD 未变化PR 可合并，远端 head 没变
Orbi 读取 mergeability 和远端 head，然后只合刚刚核验过的那个 head。
公开证据
一个真实 PR 被拦了两轮
Issue #1018 产生了 PR #1023，后来进入 v0.5.17。独立评审拦了两轮：第一轮发现发版顺序的补偿问题——tag 已发布时可能没有对应的 docs 页面；第二轮发现当前 head 的 CI diff coverage 门禁失败，因为新增的 promotion、resume、deduplication 和 tag-push compensation 分支没有覆盖。修复并通过 CI 后才进入发版。
门禁之所以有用，正因为「PR 存在」和「PR 变绿」都不够。
策略说不的时候
保护规则不会被绕过
如果评审和检查都通过，但仓库策略仍阻止合并，Orbi 会停在 ai-awaiting-merge。Issue 评论会写明维护者要做的那一个动作；维护者改完策略或补上所需 approval 后，Orbi 继续合并指定的 PR head。
想先人工看一眼？
ai-human-review 是默认关闭的人工验收闸。打开后，由人确认交付的验收清单，独立评审和合并才继续。
合并之后
合并结果仍然可识别
交付之后，release Issue 会冻结一个 SHA 并打 tag。这一页就讲到这里：重要的是，发出去的是一个已经标识、已经过门禁的结果，而不是 agent 还在变化的分支。
一句话
自动化合并，不要自动化信任
只给 agent 一条这样的合并路径：独立评审、最新 base、CI 已结束、可合并且 head 未变化。AI 才能自己合并 PR，而不会让一个绿色 check 变成全部的安全故事。