我们用一支 AI 编程智能体队伍来构建 Ulyssify。在繁忙的一天里，这支队伍会在我们的后端、网页、iOS、macOS、Windows 和 Android 各个平台上开启并合入数十个拉取请求。人类负责指挥和批准，智能体负责实现。这篇文章要讲的，是没有人事先提醒你的那部分：当你的智能体几乎无所不能之后，真正的难题就不再是能力，而是判断力。

一个能力强大的智能体会怎样失控

一个技术上什么都会做、却分不清哪些操作可以撤销的初级工程师，并不是财富。智能体也一样。一个乐于重构文件的智能体，只要有机会，也会强制推送一个共享分支、对真实数据跑一次破坏性迁移，或者仅仅因为测试通过就部署到生产环境。测试通过只说明没有东西失败，并不说明这次改动可以安全上线。所以我们做的第一件事，不是打造一个更聪明的智能体，而是找到一种方式，告诉智能体哪些决定该由它自己来做。

三个层级：自动、告知、询问

我们的智能体面对的每一个反复出现的决定，都会被归入三个层级之一。

自动，用于任何可撤销、影响面又小的操作：从主干拉出分支、跑测试、开一个拉取请求。智能体直接去做。

告知，用于那些可以挽回、但值得被看见的操作：智能体先把事情做了，然后在运行小结里列出来，让人可以否决一个错误的判断。告知这一层有一条严格的门槛：只有当撤销只需一条便宜的命令时才算数。如果撤销含糊或代价高昂，那它从一开始就不属于告知。

询问，用于那些单向的门：升级到生产环境、一次破坏性迁移、任何触及金钱、强制或公开承诺的事。智能体会停下来，等一个人来定夺。

有两条规则凌驾于这三层之上。单向的门，永远要问。以及，当智能体没有十足把握时，就要问。一个澄清的问题，永远比一次自信满满的错误构建更便宜。

一个改变了我们写规则方式的发现

我们把智能体的操作规则写成文字说明，有一阵子我们只是不停地往上加。后来我们审计了这支队伍一个月里真实的行为，结果让人不安：由真正的机制托底的规则，比如一个拒绝提交的 git 钩子、一个拦住合并的 CI 任务、一道权限闸门，违规率基本为零。而只以文字形式存在的规则，被遵守的比例大约在四分之三，而且随着文字越加越多，遵守度是变差，而不是变好。

我们从中得到的教训是：对指令的遵从是一份预算，而不是一种保证。你写下的每一条文字规则，都在和其他所有规则争夺模型的注意力，而这堆文字只会越来越多。所以，一条你真正绝不希望被违反的规则，根本就不该待在文字里，它应该待在一个能让错误操作从一开始就无法发生的机制里。如今，我们把一条绝不容违反的规则从文字提升为一个钩子或一道闸门，视为真正的修复，而把再加一段文字，视为要避免的事。

验证机制，而不是来历

还有一个屡屡帮到我们的习惯。当一个智能体，或一个人，推荐某种保护措施时，我们很容易因为它论证充分、又有过往依据就去相信它。但推荐只是一种主张，唯一要紧的问题是这个机制是否真的成立。对任何一项保护，我们只用一句话来检验：它所依赖的那个值，是执行方已知的，还是由它想要约束的那一方主动提供的？一道被约束方只要闭口不言就能绕过的限制，无论论证多么漂亮，都不是保护。找到那行真正执行它的代码，比任何关于这个想法是否高明的争论都更快给出答案。

这一切都还没有完成。它是一套活的系统，我们每周都会以新的方式把它做错。但方向一直很一致：让智能体对哪些决定属于自己拥有真正的判断力，并把最要紧的那些决定交给机制，而不是交给文字。我们会在往后继续分享这支队伍是如何运转的。