为什么大多数团队在几周后就放弃了 AI 编程

大多数尝试 AI 编程的团队都遵循相同的轨迹。

他们一开始充满热情。模型在几分钟内生成了功能，他们把它发布了。QA 发现了一个 bug，于是他们发布了修复。QA 又发现了一个 bug，这次在一个本应毫无关联的 module 里。修复涉及十四个文件，QA 又发现了三个新问题。

团队被吓到了，得出结论：模型还没准备好用于生产环境，于是回到手工编写代码。AI 沦为自动补全玩具。

这是 AI 编程在生产环境中最常见的结果。不是更快的交付。不是 10 倍效率的工程师。只是一场以撤退告终的短暂实验。

模型不是问题。问题是模型被要求把代码生成到了什么样的系统里。

生产环境代码库在 AI 出现之前就已经很脆弱

没有护栏的生产代码库一直都混乱不堪。没有 unit test。没有架构 enforcement。没有 module 边界。只有一堆以人类无法完全理解的方式互相 import 的文件，全靠乐观主义维系。

在 AI 出现之前，这种混乱以人类的速度增长。工程师慢慢写代码。bug 慢慢被引入。QA 慢慢发现。系统逐渐退化。你有时间注意到腐化的过程。

代价依然是真实的。脆弱的代码库会耗尽人才，因为工程师整天都在意大利面条式代码中摸索，而不是解决问题。士气下降。离职率上升。最优秀的工程师最先离开。

但破坏被人类的速度所限制。

为什么 AI 编程速度会摧毁没有防护的系统

AI 改变了一个变量：速度。模型编写代码的速度比人类快十倍。它在几分钟内生成功能、endpoint 和数据迁移。代码库以机器的速度增长。

但它生长进的代码库仍然是那个脆弱、没有防护的系统。同样的隐式依赖。同样的缺乏边界。同样的无法扩展的手动 QA 流程。

于是模式加速展开。更多代码。更多耦合。更多 bug。更多 QA 失败。更多手动修复。更多恐惧。直到团队放弃，将 AI 标记为「不适合我们的用例」。

QA 失败如何摧毁对 AI 生成代码的信任

当 AI 生成的代码未通过 QA 时，工程师不会让模型去修复。他们手动修复。

他们已经学会了不能信任模型。第一个 bug 在功能本身里。第二个 bug 在模型间接触及的 module 里。第三个 bug 是模型在修复第二个 bug 时引入的回归。到第四次 QA 失败时，工程师已经在手动调试了。

这才是真正的瓶颈。不是生成速度。是信任。团队无法利用 AI 的速度，因为他们无法信任 AI 生成的内容。而他们无法信任生成内容的原因，是没有结构性框架来防止模型制造跨 module 的混乱。

没有护栏，每一次 AI 生成的改动都是一场赌博。大多数团队不是赌徒。

为什么护栏现在比手动修复更便宜

这才是真正改变的地方。在 AI 之前，编写全面的 contract test、建立架构 enforcement 和构建 module 边界成本高昂。需要耗费人力工时。团队跳过护栏是因为没有时间。

现在模型在几分钟内就能生成测试脚手架。它能编写 Semgrep 规则。它能产出适配器样板代码。它能搭建 CI pipeline 检查。模型构建护栏的速度和构建功能一样快。

瓶颈从「我们承担不起护栏」变成了「我们不知道先建哪个护栏」。

弄清这一点的团队不再赌博。他们开始持续交付。

什么是 AI 编程护栏？

AI 编程护栏是让生成的代码保持边界约束的结构性规则。它们不是 lint 规则或风格指南。它们是架构 contract：明确的 module interface、通过 composition root 进行依赖注入、为外部服务构建的适配器层，以及拒绝违反这些边界的代码的 CI enforcement。

没有护栏，AI 模型就没有一张标明允许触碰范围的地图。它跨 module import，在业务逻辑中实例化依赖，将供应商 SDK 深埋在领域代码中。每次生成会话都变成了审查工程师的大海捞针。有了护栏，模型在写任何一行代码之前就知道系统的轮廓，编译器或 CI pipeline 会在违规代码到达 QA 之前将其拒绝。

让 AI 代码可信任的五个护栏

如果你希望 AI 生成的代码持续通过 QA，以下这些不是可选项。它们是信任层：

  • 每个 module 都有明确的 interface。没有例外。
  • 每个依赖都通过 composition root 注入。业务逻辑中不允许直接实例化。
  • 每个外部服务都封装在应用程序拥有的适配器中。领域代码中不允许供应商 SDK。
  • 每个边界都在 CI 中强制执行。警告不算 enforcement。
  • 每个 contract 都有验证行为而不仅仅是类型签名的测试。

这些规则不是建议。它们是区分两种代码库的分界线：一种是 AI 生成的改动保持局部的代码库，另一种是每次改动都变成大海捞针的代码库。

当 AI 生成了跨越边界的代码，人类审查者在规模面前无法捕获。唯一可扩展的防御是让违规代码无法合并。

Autotomy 对 AI 编程落地生产环境意味着什么

Autotomy 是运行原则：构建能够舍弃故障部分而不导致整个有机体死亡的系统。

在实践中，这意味着一个 module 中的 bug 无需理解整个系统即可诊断。一次集成失败指向单一边界。一个回归被隔离在发生了变更的表面上。

Autotomy 不承诺零 bug。模型会产生幻觉。边界情况潜伏其中。集成面会表现出训练数据未曾捕获的行为。总有一些 bug 会漏过去。

但 Autotomy 消除了代价高昂的 bug。代价高昂的 bug 不是单个 module 内部的逻辑错误。而是因为没有人强制执行 module 之间可以触碰和不可以触碰的范围，导致故障跨边界蔓延。它们是由结构性疏忽而非逻辑错误造成的 bug。

当你消除了攻击面，你也就防止了导致团队对 AI 失去信任的那一类 bug。有边界的故障是模型可以修复的。分散式的故障只会被模型越修越糟。

信任测试：你的团队能自信地交付 AI 代码吗？

衡量一个生产系统的不在于其缺陷数量。而是团队是否足够信任这个系统以继续使用 AI。

一个具有刚性边界的系统可以安全地吸收 AI 生成的代码。当认证适配器出问题时，你修复认证适配器。模型可以重新生成它，因为边界清晰，contract 明确。QA 通过。团队再次交付。

一个没有边界的系统则做不到。当某个地方出问题时，故障分散在隐式依赖之间。模型无法修复，因为它无法对没有结构的系统进行推理。QA 失败。工程师手动修复。信任被侵蚀。

这才是真正的测试。不是 AI 能不能写代码。而是 AI 能不能写出团队足够信任、敢于上线的代码。

抉择：功能速度还是结构安全

使用 AI 编程工具的团队面临一个二元选择。

他们可以用速度在同一个脆弱的系统中生成更多功能。更多代码。更多耦合。更多 QA 失败。直到团队放弃，退回人类速度。

或者他们可以先用速度构建护栏。刚性边界。全面的 contract。确定性的 CI enforcement。然后在使违规成为不可能的系统中用 AI 生成功能。

显而易见的替代方案是增加 QA 人力或花更多时间做 prompt engineering。这些手段在边际上有所帮助，但解决不了结构性问题。手动 QA 线性扩展，而 AI 输出指数级扩展。更好的 prompt 降低了 module 内部的错误率，但不能阻止模型跨越它不知道存在的边界。唯一可扩展的防御是让违规无法合并。

第一条路感觉像是进展，直到 QA 把代码打回来。第二条路只在第一周感觉像是额外负担。

区别在于团队在第三个月是否仍然信任 AI。

如果你想要一个已经内置这些护栏的生产就绪基础，请从 Autotomy Expo starter kit 开始。