很多人第一次用 AI 写代码时，都会先经历一段很顺手的阶段。
脑子里有个想法，丢一句 prompt，模型很快吐出一版能跑的东西。改几句提示词，再来一版。做原型、搭脚手架、试一个小功能，这套方式经常快得惊人。
但只要任务稍微变复杂，问题也会很快冒出来：同一个需求，每次生成结果都不太一样；模型为什么会这样设计，说不清；你明明知道“不是这个意思”，却很难一次把意思讲透。到最后，花掉的时间不一定比自己写更少，挫败感反而更强。
最近在整理关于 Spec-Driven Development (SDD) 的分享时，我最有感触的一点是：在 AI 参与编码之后，难点正在从“怎么写代码”向更上游移动。 真正开始影响结果的，不再是你敲实现的熟练度，而是你能不能把系统应该做什么、不能做什么、边界在哪、怎样算完成，写成一份足够清楚的规格（Specification）。
这也是为什么 Spec-Driven Development 这类方法会在 AI coding 的语境里重新变得重要。
先看对照组：什么是 Vibe Coding
讨论 SDD 之前，先要看它想解决的是什么。GitHub 曾提过一个词叫 Vibe Coding。它代表的是一种现在很常见的 AI 辅助开发方式：开发者先给模型一个 prompt，描述要做什么应用或功能，模型直接生成一版代码。你运行、观察、继续补 prompt，再让它改。
Vibe Coding 是一种“感性驱动”的开发状态：开发者给出模糊描述，模型凭训练中的“常见写法”补齐逻辑空白。它在原型阶段极快，但在复杂系统中容易让产出进入“不可追溯”的随机状态。
这种方式的问题在于，开发者给出的通常不是完整约束，而是一段“意图描述”。模型需要自己补齐大量空白：接口设计、状态组织、错误处理、目录规范。
这就是 Vibe Coding 最典型的失控点：它不是不能产出，而是产出不够稳定，也不够可追溯。 你改了一个词，模型可能换掉一整套实现路径；你保留了结构，模型又可能在下一轮丢失关键细节。
它跳过的，不只是文档，而是整段工程约束
Vibe Coding 的问题不只是“模型偶尔写错”，而是它经常跳过了传统软件开发里那些本来就用于降低歧义的环节。
正常的软件开发通常会有需求澄清、设计、实现、测试、QA 等环节。PRD 之所以存在，是为了锁定目标和边界；TDD 之所以强调先写测试，是在把行为约束前移。12
AI agent 并不会天然绕开这些问题。相反，当你把任务交给模型时，这些显式信息变得更重要了。人类工程师能在上下文中补全隐含约束，但模型往往只能根据输入内容和训练经验去猜。你不写，它就自己补；而一旦让它补，输出就开始漂。
SDD 的关键变化：把第一工件换成规格
Spec-Driven Development 的关键，不是多写一份文档，而是把“第一可见结果”从代码换成规格。在这种方式里，prompt 不再直接描述实现，而是定义合约（Contract）：
- 系统应该做什么（Behavior）
- 期望行为是什么（Expected Outcomes）
- 有哪些约束（Constraints）
- 什么情况算成功/失败
目前的工具链（如 Kiro、spec-kit 或 Tessl）大多遵循这一逻辑。34 它们将流程拆分为：
- Requirements: 锁定原始需求。
- Design: 将需求转为技术架构和数据结构。
- Tasks: 拆解为可追踪的原子任务。
- Implementation: 最后才由 AI 生成代码并验证。
这一步带来的变化很朴素：方向不对时，我们可以先改规格，而不是等代码生成了一大堆，再回头追问“为什么会变成这样”。
从一个 /login 例子看差异
如果按 Vibe Coding 的方式，你可能会说：“帮我做一个 /login 页面，用于用户认证。”
这句话留给模型猜的空间太大了。它可以猜这是前端页面还是后端接口，用表单还是 JSON，返回 session 还是 JWT，甚至自行决定错误码策略。
- 功能: 用户认证
- Endpoint:
/login(POST) - 输入:
user和pass - 异常处理: 缺少用户名返回 400，认证失败返回 401
- 成功行为: 返回 HTTP 200 及 JWT Token
只要写到这里，你已经不是在“让模型自由发挥”，而是在给它一个带边界的行为定义。
但规格不是“万灵药”：Spec 不完整，流程照样失真
这里也正好能看到 SDD 的另一个现实面：Spec 不完整，流程照样会漂移。
上面的 /login 例子适合演示，但离上线还远。真实工程中还有更多问题没写清楚：
- 缺字段时返回 400 还是 422？
- 用户名不存在和密码错误是否区分？是否有 Rate Limit？
- 成功后的 JWT 存在哪里？过期时间多少？
如果规格写得太笼统，AI 依然会在代码层大肆猜测，导致 SDD 倒退回 Vibe Coding。 Exit: 不要追求文档的长短，而要追求决策的覆盖面。如果一个设计决策（如错误码定义）影响实现，请务必写进 Spec。
这种模式到底提升了什么？
这类方法最容易被误解成“重新崇拜文档”。但 SDD 真正强调的是控制力：将那些会影响实现决策的约束尽量前移，并写成 AI 能据此执行的东西。
什么时候该切到 SDD？
- 任务偏探索（原型/脚本）: 继续 Vibe Coding，成本最低。
- 任务偏交付（团队/维护/测试）: 必须切到 SDD。此时 Spec 的价值远高于 Prompt 的调优。
结语
开发者的价值没有消失，只是往更上游移动了。
AI 把那些本来就该明确、但常常被人类工程师用经验默默补掉的东西，全都逼着你写出来了。从“写代码”转向“写规格”，本质上是在适应一种以 AI 为执行引擎的新型协作模型。
对 AI coding 来说，这条规格链不是负担，而是控制力的唯一来源。先把你真正想要的东西说清楚，再让模型动手。