最近在刷海外开发者分享时，看到一个特别戳中团队痛点的观察：在传统开发里，规格文档（Spec）写完基本就“过时”了；但到了 AI Agent 主导的工作流，Spec 反而成了最核心的“活基础设施”。设计不再是纸上谈兵，Agent 随时回头查 Spec 做决策，整个过程像有了“实时导航”。

这个转变让我这个老开发者直呼“终于等到你”——很多团队现在都在纠结：引入 AI 后，RFC 还要不要写？怎么写才能真正发挥作用？今天就基于这个思路，跟大家聊聊 Spec 在 Agent 时代的真实进化。

传统开发的经典鸿沟：为什么 Spec 总是“说一套做一套”

过去我们为什么那么依赖 RFC？因为手动试错成本太高。团队必须先把架构、API 边界、数据模型全想清楚，写成文档，review 通过后再动手 coding。结果呢？代码一写，现实情况立刻打脸：API 不够用、模型不 scale、依赖关系藏着坑……改起来动辄重构，整个过程又慢又贵。

这个“先设计后实现”的顺序，对新人打击最大。写强 RFC 需要预判你根本没踩过的坑，这纯靠经验积累。AI 工具虽然能帮你跑跑 edge case，但工作流本质没变——还是设计先、实现后，Spec 始终是“理论文件”。

AI 原生工作流：设计和实现不再排队

真正牛的 AI 原生环境里，设计和实现直接并行了。你一边起草 Spec，一边就可以喊 Agent（比如 Intent 的 Coordinator 这种角色）去并行原型、压力测试、甚至直接推到 staging。Spec 和代码像一对搭档，互相喂信息、共同进化。

以前要等三周才发现“这个接口根本走不通”，现在 Spec 还在 review 阶段，Agent 已经帮你把坑踩出来了。Reviewers 看到的不再是纯理论架构，而是已经跟真实数据库、真实场景“干过一架”的半成品。这时候的反馈，才叫真正有价值。

更关键的转变是：Spec 不再只是“描述系统长啥样”，而是变成了“治理系统怎么建”的运营基础设施。Agent 负责大段实现时，每天都会遇到无数模糊决策：

• 要不要顺手扩展支持 X 功能？
• 这个抽象要不要再加一层？
• 当前实现还符合最初的架构意图吗？

没 Spec，Agent 要么跑去问人（人可能也没全 context），要么自己“自信”猜。猜的结果就是：一堆没人授权的 scope creep 和边界破坏悄悄发生。有了清晰的 Spec，Agent 就像有了锚点，随时回头对齐，人类只需要把控最终审批。

传统时代 Spec 只指导人，现在它还要指导写代码的 Agent——这对文档清晰度要求高多了，责任也始终在人类身上。

真实案例拆解：Augment 团队的用户组系统是怎么玩的

Augment 团队最近做企业租户的用户组功能，完美演示了这个流程。他们需要新数据库 schema、API 定义、设置解析模型，还得支持分阶段上线，所以工程师先写了一份覆盖全链路的详细 Spec。

第一天：Spec 刚写完。
两天后：第一个 PR 就来了——服务脚手架 + CRUD 接口。同一份 PR 里还顺手更新了 Spec！原来在搭桩子的时候，工程师发现原计划的 phasing 依赖会卡住上线进度，直接把实现计划改了，代码和 Spec 一起 merge。

又过几天：第二个 PR 把完整数据库层怼上真实 emulator，9 个方法端到端测试全部跑通。这时 Reviewers 讨论 Spec 设计的时候，核心实现已经跑起来了——传统流程里这得等好几周。

后续 PR 严格按 Spec 里的分阶段计划走，后来一次重构要换数据访问模式，Spec 里定义的架构边界让替换变得异常简单，业务逻辑一行没改。

Spec 在这个项目里根本不是“审批完就归档”的死文件，而是全程陪跑的合约，随时保持最新，随时被 Agent 和人类共同引用。

关键洞察：Spec 到底在解决什么问题

这里其实有一个很核心的设计思想：Agent 时代，Spec 成了防止“并发设计”变成“并发混乱”的唯一护栏。

它让新人也能在架构边界内安全施工（以前这得靠多年经验才能预判），让 Senior 的 review 效率翻倍（因为桌上已经有能跑的代码），更重要的是——它把“猜”这个最危险的操作，从 Agent 手里夺了回来。

当然，Spec 也不是万能的：

• 写错了 → Agent 会更快、更自信地把错的东西做出来；
• 写得太模糊 → Agent 会用听起来很合理的决策偷偷改 scope；
• 并行原型没控好 → 大家会因为“代码已经能跑”而舍不得丢，提前锁定错误路线。

所以 Spec 只是把地板抬高了，Senior review 依然不可或缺，只是现在他们的精力能花在更有价值的地方。

对开发者的实际启发与应用场景

1. 企业级功能开发（权限、计费、多租户等）：先写 Spec，再让 Agent 并行原型，review 时已经带真实数据，交付周期能砍掉 50% 以上。
2. 新人快速上手：给新人一份写给 Agent 看的 Spec + Coordinator Agent，他就能在架构安全边界内推进，Senior 只需做最终把关。
3. 团队规范升级：以后写 Spec 时要多问自己一句——“这段话 Agent 能读懂吗？它会不会猜错我的意图？”

未来趋势很明显：能被 Agent 消费的 Spec，才是真正的生产力基础设施。你的团队还在把 Spec 当 Word 文档写吗？是时候升级了。

总结

Agent 时代，Spec 不再是“规划文件”，而是设计与实现实时协同的合约。它给 Agent 提供架构护栏，给 Reviewers 提供接地气的依据，让新人也能站在巨人肩膀上快速交付。

核心就一句话：别再问“要不要写 Spec”，而是要问“你的 Spec，是写给人看，还是写给 Agent 用的？”

我是紫微AI，我们下期见。
（完）