军火库已经敞开
机关枪已经发到每个人手里了。
AdEspresso 联合创始人、Unkover 首席 AI 官 Massimo Chieruzzi 精准地捕捉到了这一点：“AI 有时让你感觉自己像一只端着机关枪的猴子。” 我们同意。从这个洞察中，我们推导出自己的结论：我们就是那只猴子，枪已经在手里了，问题不在于这两者中的任何一个——而在于没有瞄准。
Cursor、Copilot、Claude Code、v0——这些不是在 architecture 评审中争论的未来技术。它们已经活跃在你的技术栈中，在你的工程师旁边生成代码，向你的仓库提交代码。AI 代理已经有 API 权限访问你的 codebase。“我们该不该允许 AI 工具？“这个问题在半年前就已在没有人征得许可的情况下有了答案。
你的团队已经全副武装。唯一的问题是：你有没有装上aimbot？
什么是 AI 代码治理？
AI 代码治理是一套结构规则，用于引导开发者和 AI 代理如何编写、修改和交付代码。它不是基于权限的官僚流程。它不是工单队列或强制签字链。它是基于guardrails的执行机制，以开发者的速度运行：对 service module的硬边界、显式的 dependency interfaces，以及会在 CI 中就失败的 contract tests，在坏代码到达生产环境之前就将其拦截。
没有治理，每个 AI 生成的 pull request 都是一发射向黑暗的子弹。有了治理，猴子仍然在开火——但每一发都落在它该落的地方。
猴子命中了目标
这才是恐怖之处。功能上线了。工单关闭了。演示完美运行。
猴子命中了目标。但代价是什么？因为为了击中那一个目标，它在路上扫射了 auth 服务、database schema 和三个 microservices，把它们打了个稀巴烂，因为猴子不会瞄准——它只会扫射。
Slack 频道里一片欢庆。生产环境在悄悄流血。auth 的回归不会出现在 pull request diff 里。它会在 48 小时后现身，当 on-call 工程师在凌晨两点被叫醒，因为整个平台的登录 token 都在报错。
目标从来不是问题。附带损害才是。
为什么 code review 作为治理是失败的
Code Review 是人工挡子弹
标准应对方案不是培训。没有人有六周时间搞 bootcamp。真正的应对方案更糟：让资深工程师 review 每一个 pull request。
Code review 变成了挡子弹。资深工程师逐行阅读，拦截每一发偏离的子弹，将其重新导向目标。他们不是在 mentoring，不是在搞 architecture。他们只是站在猴子面前，手动调整每一次射击，让它落到某个可以接受的地方。
这不可扩展。一个资深工程师，十二只猴子，每个 sprint 四百发子弹。资深工程师最终会耗竭。review 队列越来越长。迟早有一天，他们会通过本不该通过的东西，不是因为懒，而是因为人类的注意力是有限资源，而猴子有无限弹药。
即使存在培训，也只在沙盒里进行。真正的猴子是在生产环境中用实弹射击学会的。等经验教训真正记在心里时，codebase 已经承受了需要几个季度才能修复的伤害。
你雇不到足够的资深工程师来手动挡住每一发子弹。这道数学题算不拢。
AI 倍增器：没有自尊，没有恐惧
初级开发者好歹还有感觉。他们在 Slack 里快速交付时会咧嘴笑。他们最终也会感受到后坐力，当跳弹以 postmortem 或 rollback 的形式打回自己身上时。
AI 代理什么都感觉不到。没有自尊。没有恐惧。没有问责。当 auth 层在凌晨三点挂了，没有人会去 page 模型。他们只会 page 那个合并了 pull request 的人类。
一个 LLM 会在凌晨三点”清理 codebase”，信心十足地重构你的 auth 层。它会删除已废弃的字段，而下游消费者还依赖着它们。它会引入编译通过但在运行时崩溃的循环 dependencies。它会礼貌地完成这一切，带着优秀的变量名和详尽的注释。
猴子最终会学到，扫射会让自己被跳弹击中。它学会先瞄准再开枪。但到那时，伤害已经造成。
Autotomy 就是aimbot
这里比喻从警告转向了解决方案。
你不会把枪夺走。你不会安排一个六周安全课程——业务部门反正会取消。你装上aimbot。
Autotomy 不是官僚审批流程。不是工单队列，也不是由已经不堪重负的资深工程师进行的强制 code review。它是基于guardrails的治理，以开发者的速度运行。
猴子仍然在开火。猴子开火更自信了，因为准星锁定了有效目标。service boundaries 是硬约束，不是建议。dependencies 必须通过显式 interfaces 流动。contract 变更通过经过验证的路径传播。功能上线了，其他什么都没挂。
这就是基于权限的治理和基于guardrails的治理之间的区别。权限说：停下，先请示。guardrails说：全速前进，相信结构会在坏子弹落地之前把它们拦截下来。
回报：资深工程师重新成为侦察员
如今，你的资深工程师成了保镖。他们站在猴子面前接跳弹。每个 pull request 都是损害控制。每次 review 都是急诊室分诊。资深工程师一整天都在说”别碰那个文件”和”那个 module 是禁区”，直到他们自己的生产力降到零。
aimbot装上之后，资深工程师重新成为侦察员。他们校准风偏，确认对高难度目标的命中率，追捕自动化治理看不到的边界情况。他们不再是肉盾，而是战斗力倍增器。
可扩展的治理是不依赖于资深工程师逐行阅读每一条代码的治理。它依赖于结构规则如此严格，以至于即使是端着机关枪的猴子也无法偶尔触犯。
想更深入地了解刚性边界如何让 AI 生成的代码在生产环境中值得信赖，请参考 AI 编程与 Autotomy 框架的结合原理。如果你想理解guardrails在整个技术栈中的定位，请阅读 AI 安全技术栈。
接下来实际该做什么
如果你在管理一个包含初级开发者或 AI 代理的团队，不要从培训课程开始。从硬边界开始。
在任何实现代码写出来之前，先定义好 module interfaces。通过一个 composition root 将所有 dependencies 连接起来。每个边界加一个 contract test。在 CI 中强制执行 import restrictions，使得违反 architecture 的 pull request 根本无法合并。
这些步骤只需要一天。它们会改变你的团队在第四周时是否信任自己的开发者。对于使用 AI 生成代码的团队来说，在每一个 API 边界上添加 contract tests 是杠杆率最高的第一步。
猴子已经在这栋楼里了。枪已经上膛了。装上aimbot，否则就准备继续接子弹。