作者声明：我是ThumbGate的开发者，这是一款为编程智能体设计的审批门禁。本文很大一部分是对我自己产品所在的这个品类的批评。

如果你经历过on-call轮值，你大概已经知道这种失败是什么形状了。一开始，所有警报都开着，因为每一条都可能重要。一个月之内，寻呼机每晚响四十次，其中三十九次是噪音，值班工程师也养成了一种反射：瞄一眼、关掉、回去睡觉。然后真正的事故穿着和噪音一样的衣服来了，也被关掉了。

没有人因此得出结论说值班工程师粗心大意。大约十五年前，我们正确认识到：信噪比差的警报通道不会优雅降级，它会反转。超过一定数量，增加警报反而会让你更难捕捉到你本要提醒的事情。这个洞察催生了警报预算、基于症状的寻呼、警报正文里的runbook链接，以及一条通用原则：如果人类无法据此采取行动，它就不该触发寻呼。

现在，我们正在AI智能体的审批提示里，从零开始重建一模一样的失败。而且有数据支撑。

一项发布于2026年8月6日的权限游戏研究，将大约4万次游戏、约40.9万个独立的批准/拒绝决定摆到人面前，事先明确告知其中混有危险命令，然后测量什么被放了过去。结果：大约每三个真实威胁中就有一个被批准。

关于这项研究的HN讨论毫不意外地分成了两派。一派攻击方法论——有些提示本身对“是否真的高风险”表述模糊，这个批评有道理。另一派则更直白：这个批准点击从来就不是安全控制，它只是一次责任转移——出问题时，供应商可以指着你点下的那个“允许”来撇清自己。

我自己就做这种门禁。我认为第二派比我愿意承认的更接近事实，而寻呼机类比恰好解释了为什么。

审批提示和警报一样，正在陷入同样的“噪声淹没信号”陷阱。起初，每个提示都值得仔细看，因为每个都可能致命。但智能体请求批准的频率远高于人类能认真处理的上限，于是一次次跳过确认，偶尔扫一眼，直到习惯性批准成为默认动作。更糟的是，警告的严重程度没有分级，“只读文件操作”和“删除整个生产数据库”共用同一个按钮，那种一致性反而剥夺了人的警觉。

警报领域我们学会了“预算”：如果某个警报需要人响应，但响应后没有行动，就把它砍掉。审批提示也需要类似的纪律——不是所有操作都要过门禁，只有那些真正不可逆、有破坏性的动作才值得打断人类。否则，我们只是在制造一个现代版的寻呼机，让它在AI时代每晚响四十次，然后依然漏掉那一声真正要紧的。