Specs 是 Agent 时代的底层基础设施
在传统软件开发中，Specs（规范文档）通常被视为规划蓝图。一旦编码启动，随着系统现实的浮现，这些文档往往迅速过时。
然而，在AI-native workflows（AI 原生工作流）中，这种关系发生了根本性逆转。Specs 不再是静态的规划文件，而是成为living contracts（活体契约），Agent 在构建过程中会持续回溯并参考它们。
为什么传统流程存在瓶颈？
传统的 RFC（Request for Comments）流程存在一个核心逻辑：因为探索实现成本高昂，团队被迫将设计前置到文档中，然后再编写代码。
这一约束在 AI 时代已不再成立。Agent 消除了设计与实现之间的鸿沟，使两者能够实时相互影响。取而代之的是，Specs 不再是易耗品，而是成为指导与评估实施的durable infrastructure（持久基础设施）。
从序列式到并行的 AI 原生工作流
即使在拥有严格 RFC 流程的组织中，设计与实现通常仍是sequential（序列式）的：先写、再评审、后批准，最后才构建。设计在代码存在前仍是理论性的，直到 API 边界或数据模型的问题被暴露，此时修正代价巨大。
AI 工具虽然能辅助探索边缘案例，但并未改变根本的工作流：设计依然先于实现。
在真正的 AI 原生环境中，设计与实现停止序列化。实现者可以在起草 Specs 的同时，利用像 Intent 的 Coordinator agent 这样的工具进行探索、原型开发（甚至并行构建多个设计），甚至部署到测试环境。Specs 与实现共同演进。
Specs 如何指导 Agent？
当 Agent 负责大量实现工作时，它们常面临模糊决策：
- 是否扩展范围以支持新功能 X？
- 是否可以绕过某个接口？
- 是否需要在此处引入新的抽象层？
如果没有 Specs 作为锚点，Agent 只有两个选择：询问可能缺乏上下文的人类，或者猜测。正是猜测，让 Agent 在没有授权的情况下悄悄决定了范围和边界。
Well-written specs（编写精良的 Specs） 为 Agent 提供了参照系。当疑问产生时，Agent 可查阅 Specs 以确保符合预期架构。
关键转变：在传统工程中，Specs 指导人类；在 AI 原生工程中，它们也指导编写代码的 Agent。
实战案例：用户群组系统
Augment 在为企业租户构建用户群组系统时展示了这一模式。该功能涉及新的数据库架构、API 定义及分阶段发布计划。
- 同步演进：工程师在编写全面 Specs 两天后，第一个 PR 落地，包含服务脚手架和 CRUD 端点。该 PR 同时也更新了 Specs。在构建存根代码时，工程师发现原计划引入了不必要的依赖，从而调整了 Specs 中的实施计划，并随代码一同发布。
- 实时验证：几天后，第二个 PR 落地，数据库层在真实模拟器上运行，并通过了九个方法的端到端测试。此时评审者讨论 Specs 的设计决策时，核心实现已得到验证并运行——这在传统模式下通常需要数周。
- 持续治理：后续的 PR 遵循了 Specs 的分阶段计划。当后期重构改变了数据访问模式时，Specs 中定义的架构边界使得该变更成为简单的替换，无需修改逻辑。
风险与责任
Specs 的作用是一把双刃剑：
- 如果 Specs 错误，Agent 会比人类更快、更自信地实现错误的功能。
- 如果 Specs 过于模糊，Agent 会用看似自信的决定填补空白。
Specs 提高了基准线，但并未消除对资深评审的需求。责任始终在于编写和批准 Specs 的人类，而非遵循它的 Agent。
编写能指导 Agent 的 Specs 需要更高的清晰度，而非更低。
