Review the Spec, Not the Code: Augment Code 的架构演进
"Writing code is the cheap part now. But most teams are still organized around the old bottleneck: Staring at diffs."
在 AI 编程助手（AI Agents）深度介入软件开发流程的今天，软件交付的瓶颈发生了根本性转移。过去制约软件发布的核心是‘编写代码’，而现在，这一环节已变得极其廉价。然而，大多数团队仍沿用旧有的工作流，试图通过逐行审查 AI 生成的 Pull Request (PR) 来保证质量。这种模式正在失效：AI 生成的 PR 积压严重，一旦进入审查队列，通过率却急剧下降，近 70% 的 AI PR 被直接拒绝。
核心痛点：代码审查的数学困境
Augment Code 指出，当前的审查模式存在两个致命缺陷：
- 注意力稀缺与概率失效：审查本质上是一个概率过滤器，永远无法完美。当 PR 数量呈指数级增长时，人类审查员的注意力成为稀缺资源。AI 生成的代码往往能通过其自身生成的测试（因为测试代码也是由同一模型生成的，旨在匹配实现而非验证规范），导致传统审查机制失效。
- 架构意图的丢失：审查代码只能捕捉到表面的语法错误或逻辑漏洞，却难以发现架构层面的错误（如错误的抽象层、解决错误的问题、违反业务约束的依赖）。这些关键问题往往隐藏在数百行的代码 diff 中，极易被忽视。
新范式：审查规范，批准计划
Augment Code 提出了一种结构性的转变：从审查代码转向审查规范 (Spec)。
1. 契约驱动的开发 (Contract-Driven Development)
在这种模式下，开发流程的重心前移：
- 定义契约：在代码生成之前，团队需编写精确的规范文档。这包括数据类型约束（如所有金额必须使用
Money类型）、API 行为契约（禁止返回原始错误消息）以及状态流转的不变量（Invariants）。 - 确定性验证：将验证工作交给机器。通过类型系统、静态分析器和自动化测试来强制执行这些规范。如果代码违反了预先定义的契约，验证层会在代码合并前自动拦截。
2. 分层信任架构 (Stacked Verification Layers)
既然无法阅读每一行代码，就必须构建多层防御体系，确保单一层的失败不会导致灾难：
- 测试层：运行自动化测试套件。
- 类型系统：在编译期捕获契约违规。
- 自定义 Linter：强制执行组织特定的业务规则。
- 对抗性测试代理：部署专门的 Agent 尝试破坏其他 Agent 构建的代码。
这种‘堆叠’策略利用不同验证手段的互补性，填补彼此的漏洞，从而在不依赖人类全量阅读的情况下建立信任。
实际应用场景：服务迁移
想象一个涉及四个 Agent 并行工作的服务迁移任务：
- 传统模式：审查员面对一个 500 行的 PR，可能在第 340 行发现了一个不该引入的新运行时依赖，或者完全漏掉了架构设计上的重大缺陷。
- 新范式：审查员只需阅读 10 分钟的规范文档，确认‘不允许引入未经批准的新运行时依赖’这一约束。验证报告随即显示所有约束均满足。Agent 在尝试引入违规依赖时，会被规范检查机制立即驳回并修正。
结论：工程工作的本质转变
Augment Code 强调，这并非关于如何编写更好的提示词（Prompts），而是关于编写可被验证的规范。未来的工程工作将更多地聚焦于定义清晰的边界条件、约束条件和验收标准。这些规则不应存在于代码 diff 中，而应存在于‘意图与实现之间的契约’中。
通过这一转变，团队将不再被代码审查的洪流淹没，而是能够专注于架构决策与业务逻辑的正确性，真正释放 AI 在代码生成上的效率优势。
