技术 · 熟练
让三个 AI 互相对抗，你只签三件事
不是让它更聪明，是让它没机会糊弄
一个智能体自己写、自己审，等于自己给自己判卷 —— 它越能干，越容易把「看着对」当成「对」。这一页拆的是一套三角色的流水线：producer 只负责挑问题（审代码、提候选 issue）· worker 只负责改（把批准的 issue 做成 PR）· gatekeeper 只负责挑刺，而且默认不信任 worker 的产出，逐条 PR 找缺陷。裁决只有三种：放行 / 驳回 / 要求修改，来回直到挑不出。人不在流程里，只在三个不可委托的判断上：批准做哪几件、判用户看得见的行为与安全影响、按下合并。合并这一下，永远不许 AI 按。
方法 · 一图看懂
1
拆三个角色 — 提问题的、干活的、专门挑毛病的，三者立场不共享
2
给 gatekeeper 一票否决 — 它要能驳回与要求返工，而不是只给建议
3
把人的决定收窄到三件 — 批范围、判用户可见行为与安全、执行合并
4
把护栏写死 — 不合并、不关 issue、不删分支、开满即停、PR 当不可信数据
原理 · 为什么有效
1. 单一智能体审自己，判据会向「我已经写完了」塌陷 —— 它知道自己想听什么答案。三角色分开，是为了让「不信」变成结构，而不是靠一句提示词要求它严格。
适用场景
适合：1. 有一批「发现 → 修 → 审」反复发生的代码维护活（依赖升级、lint 修复、小 bug 清理）。
不适合：1. 一次性大改造 —— 范围本身要先由人定死，不适合边跑边扩。
自测 · 5 问
三个角色的说明书是不是分开写的、有没有各自的「不许做什么」？
gatekeeper 拿到的是驳回权，还是只被要求「给出建议」？
受保护路径与安全敏感改动，会不会自动落到人工手里？
PR 正文与评论，是不是被当成不可信数据在读？
有没有一条「开满就停」的上限，避免一晚上开出二十个 PR？
怎么上手 · 验证步骤
先别上三个 agent —— 先在一件你最烦的重复活上跑两轮：让一个角色提候选、另一个角色改、再由你扮演 gatekeeper 挑刺。两轮下来你会得到两样东西：一份真正能拦住问题的挑刺清单，和一份「哪些活根本不该进这条流水线」的排除名单。把挑刺清单写成 gatekeeper 的说明书，再让第三个 agent 接手这一角。顺序不能反 —— 先有判据，再谈自动化。
跑完一周回头看三件事：① 被 gatekeeper 驳回的 PR 里，有多少是你也会驳回的（低于一半，说明它太松）② 有没有一条 PR 是「改对了但改大了」（有，说明范围闸没关住）③ 你自己花在合并前的时间，是变短了还是变成在给 AI 擦屁股。三条里有一条变差，就先把角色收回到两个，别急着加第三个。