从 Vibe Coding 到 Spec Driven Development：用规格把 Agentic Coding 拉回工程化

从 Vibe Coding 到 Spec Driven Development：用规格把 Agentic Coding 拉回工程化

核心结论：Vibe Coding 依赖高层 prompt 快速得到结果，但会产生可丢弃代码和技术债；Spec Driven Development 通过把“做什么、为什么”的规格与“怎么做”的实现解耦，形成人与 agent 的契约，从而在大型持续项目中控制变更、消除上下文衰减并提升意图保真度。

术语与背景说明

• 原文开头把 “gentic coding”（按上下文疑似指 agentic coding）与 Vibe Coding 联系起来，并提出：通过重新引入工程实践，让开发获得更好的结果。
• 原文多次出现 “spectrum and development”“Sd”“std approach” 等写法，后文则明确使用 “Spec driven development”。结合上下文，这些疑似为语音转写或拼写误差，本文按 Spec Driven Development 统一理解，并保留原文中的关键英文术语。
• 原文的核心背景是：AI 编码代理速度极快，但无监督的 AI 生成会带来混乱；Spec Driven Development 被视为对这种混乱的专业回应。

问题起点：Vibe Coding 的工作流

Vibe Coding 的典型过程如下：

1. 你写一个 prompt 描述想要什么，例如 “create me a button”，然后期待得到好结果。
2. 你查看结果。
3. 结果可能是一个大按钮，看起来有点接近，但在一些重要细节上不对。
4. 你向 agent 指出错误，agent 再试一次，如此循环，直到你满意。
5. 最终，你会留下与 agent 的很长对话，而这个历史甚至不会被保存。

这种方法的优点是快速。对于按钮这样的小任务，它“可以工作”。但它无法扩展到一个大型、持续进行的项目。高层 prompt 虽然快，却会导致可丢弃代码和不断累积的技术债。

Spec Driven Development 是什么

Spec Driven Development 是专业应对无监督 AI 生成混乱的方式。它是一种范式转变：

• 解释“做什么、为什么”的规格，与“怎么做”的实现被解耦。
• 规格不仅是人与人之间的契约，也是人与 agent 之间的契约。
• 人的主要任务发生转变：学习如何把自己的意图转换成清晰的 spec。
• spec 是永久性的技术工件，而不是一次性的对话历史。

原文强调：我们要的是工程，是一份维护良好的 specification，它创建出永久的技术工件。

范式转变：从写 prompt 到写规格

在 Vibe Coding 中，人的主要工作是与 agent 进行长对话，不断指出错误，直到结果可接受。问题在于：

• 对话历史往往不保存。
• 高层 prompt 很快，但难以复用、难以审计、难以支撑长期项目。
• 代码容易变成一次性的，技术债不断累积。

在 Spec Driven Development 中：

• 规格解释 what 和 why。
• 实现处理 how。
• spec 成为人类与 agent 共同遵守的 contract。
• 人的核心任务不再是“让 agent 改到满意”，而是“把意图转化为清晰规格”。

三大收益

1. 用小规格变更控制大代码变更

Spec Driven Development 配合 agentic coding assistance 的第一个好处，是能够用 spec 中的小改动控制大范围的代码变更。

原文给出的例子是：spec 中几句话概述应用的外观和感觉，可能转化为数百行 CSS。规格驱动的方法降低了与超快编码 agent 协作时所需的认知负担。

2. 消除多轮会话中的上下文衰减

第二个好处是 spec 消除了会破坏多轮 agent 会话的 context decay 问题。

原文机制如下：

• 当你与 coding agent 一起工作时，它的 context window 会被填满。
• 当 agent 试图应对已满的 working memory 时，往往会犯更多错误。
• spec 可以在 session 之间、甚至 agent 之间持久存在。
• spec 把 agent 锚定到在代码库中工作和实现功能所需的核心上下文上。

3. 提升意图保真度

第三个好处是提升 intent fidelity，也就是 agent 更可能生成与你的目标匹配的代码。

原因是：spec 迫使你在 agent 开始生成代码之前，先定义：

• 问题
• 成功标准
• 约束
• 用户流
• 等等

因此，spec 是区分 Vibe Coding 产生的 “some slop” 和工程化可行软件产品的关键差异化因素。

与 compiler 的类比

原文用 compiler 作类比：

• compiler 把人类可理解的 source code 转换成 machine code。
• Spec Driven Development 引导 agent 和 prompt，把 spec 转换成 source code。
• 甚至更好的是，spec 使用人类语言，因此便于 stakeholders 理解。

也就是说，spec 在 SDD 流程中扮演的是类似“源代码”的角色，而 agent 和 prompt 则承担类似“编译器”的转换职责。

使用对象：Coding Agent 不是简单 Chatbot

原文明确区分了 chatbot 和 coding agent：

• Chatbot 可以谈论代码，但无法访问你的项目代码，也无法访问你安装的工具。它只是响应你的 prompt。
• Agent 不同。它接收你的 prompt，制定计划，并在过程中使用 reasoning 引导自己得到结果。
• 重要的是，agent 可以访问你的 code base 和 development tools。

在 Spec Driven Development 工作流中，这些 agent 被视为高度有能力的结对程序员。它们提供技术知识和速度；而你作为高级架构师，提供蓝图。

原文的金句是：the agent is the muscle, but the spec is the brain。通过练习，你能确保产出的软件不仅有功能，而且与长期目标保持一致。

适用场景与趋势

Spec Driven Development 适用于：

• 从零开始的新项目。
• 已经运行多年的项目，并希望引入 SDD 方法。
• 帮助解决 drift 和 productivity 问题。

原文还指出，Spec Driven Development 最近作为对生产力担忧的解决方案而兴起。相关现象包括：

• 多个 SDD 项目。
• 围绕 spec authoring 构建的工具。
• 关于 capturing intent 的会议演讲。
• 这是更广泛推动的一部分：把软件开发生命周期中积累的工程经验带入 agentic coding。

对比表：Vibe Coding 与 Spec Driven Development

限制与待确认问题

原文没有提供以下信息，因此无法从原文确认：

• 具体的数据、日期或量化收益。
• 具体的 spec 模板、格式、评审流程或维护成本。
• 具体工具名称、命令或操作步骤。
• SDD 可能存在的失败条件或额外成本。
• 原文中的拼写/转写误差需要确认，例如 “gentic coding”“spectrum and development”“Sd”“std approach”等，本文已按上下文理解为 agentic coding 与 Spec Driven Development，但这些并非原文明确更正。

可以确认的局限是：Vibe Coding 对按钮等小任务“works okay”，但无法扩展到大项目；高层 prompt 虽快，却导致可丢弃代码和不断累积的技术债。

行动清单

基于原文，可以采取以下行动：

• 把主要任务从“写 prompt 并反复纠错”转向“把 intentions 转换成 clear specifications”。
• 在 agent 开始生成代码前，先定义问题、成功标准、约束、用户流等。
• 维护一份 well maintained specification，使其成为 permanent technical artifact。
• 用 spec 中的小变更控制大代码变更，例如用几句话描述应用 look and feel，从而影响数百行 CSS。
• 让 spec 跨 session、跨 agent 持久保存，以对抗 context decay。
• 将 coding agents 视为 highly capable pair programmers：它们提供技术知识和速度。
• 让自己承担 senior architect 角色，提供 blueprints。
• 记住：agent 是 muscle，spec 是 brain。
• 对新项目或已有多年项目，评估引入 Spec Driven Development 来解决 drift 和 productivity 问题。

总结

Vibe Coding 的优势是快，适合小任务，但它的高层 prompt、试错式对话、不保存的历史和缺乏持久规格，使它难以支撑大型持续项目，并带来技术债。Spec Driven Development 则把 what 和 why 的规格与 how 的实现解耦，让 spec 成为人与 agent 的契约、永久技术工件和核心上下文锚点。它带来三大收益：用小规格变更控制大代码变更、消除 context decay、提升 intent fidelity。最终，agent 是 muscle，spec 是 brain；只有通过练习把意图转化为清晰规格，软件产出才不仅 functional，而且与长期目标一致。