「人在回路」被问反了。它不是一个「要不要人、放多大比例」的问题，而是一个预算问题：注意力是消耗品，每个审核点都在扣预算，大多数团队却把审核点当成免费的。按我现在看，值得卡人的只有两处——计划确认之后、不可逆动作之前——其余靠日志和回滚兜底。本周 Meta 和 OpenAI 的两个事故，恰好都是卡错位置的注脚。
最后一道审核，人手里只剩全盘否决权
最常见的接法是把人放在流水线末端，面前摆一件做完的东西：补丁打好了、测试过了、演示录好了。这时候决策是不对称的——同意，零成本；推翻，全部重来。人怎么选，不用我教。
SWE-Gate 提供了一个值得借的视角：仓库级基准几乎只在验证补丁能不能过功能测试，而真实世界里补丁能不能被合入，还取决于一堆评审约束——可读性、边界情况、跟既有架构是否对味——这些几乎写不进测试。我的读法是：把审核全压在最后一环、只给人一个二值开关，等于把大量无法编码的约束塞进一次点击。那个开关大多数时候只会被按下「同意」。
值得放人的位置，其实只有两处
一处是动手之前的计划确认。方向错了在计划阶段改还便宜，而且人这时真的会看——审计划是在省事，不是在给成品盖章。
另一处是动作不可逆之前。本周的两个事故都长在这一条上。Meta 安全研究员的 agent 删掉了她的邮件——邮件系统里删信大多不弹第二次确认，等发现时恢复成本已经很高。之前未披露的一起事件里，OpenAI 的 agent 接管了一家真实的德国网站，对外部世界发出去的动作、改掉的配置，都不是点撤销能收回的。共同点：做错的那一刻没有后悔药，前面也没有闸。
反方我认一半：卡点越多，注意力越稀
审核点往上加，agent 会退化成一张很慢的表单，这种系统我们见过：第一个星期人还逐条看，之后就是条件反射。不是用户懒，是注意力不够分。审核点越密，单个点分到的注意力越少，最终危险动作和普通动作共用同一个「确定」按钮——最不可逆的那一步，恰恰没人看。
我不信「再补一道人工审核」能解决这个问题。人每天拨给审核的注意力基本是定值，把它切碎撒进几十个弹窗，结果趋近于零，只多出一层虚假的安全感。
判据是能不能撤销，不是要不要审
所以我的判据就一条：这一步做错了，能撤销吗。能撤销——哪怕撤起来有点疼，比如一段不合心意的代码——交给工具：版本控制、快照、审计日志，事后复盘。不能撤销，才值得放一个人进去。
顺着这条判据，真正该做的功课是拼命把「不可撤销」改造成「可撤销」。DoltLite 给 SQLite 塞进了 git 式版本控制，按官方说法建设过程用了约两千个 agent PR——数据层每步都可回滚，agent 干错活就没那么吓人。Cal Paterson 主张把 agent 记忆当文件格式存，也是同一股味道：记忆可 diff、可回滚，人就不用守在每次写操作旁边。方向搞反的人，才会一上来就加审核点。
顺序应该是：先用工具把所有能撤销的事变得可撤销，剩下来的少数不可逆点，在每个点之前放一次人。审核点数量不是 KPI，回滚成本才是。这套办法我不敢打包票——也许半年后回头看会发现自己天真——但至少本周两起事故，都属于撤销成本无穷大的那一类，而它们都没卡在正确的位置上。