从 Vibe Coding 到 SDD：AI 编程的工程化演进

当 AI 开始成为主要的代码生产者，软件开发里最稀缺的能力正在发生变化。
过去，我们常说优秀工程师的价值在于"把想法翻译成代码"。但在 AI 编程工具越来越成熟之后，翻译这件事正在被机器接手。真正决定产出质量的，变成了另一件事：你能不能把问题、边界、约束和验收标准说清楚。
这正是 SDD（Spec-Driven Development，规范驱动开发）重新受到关注的原因。
它不是一个全新的概念，也不是把瀑布模型重新包装一遍。更准确地说，SDD 是 AI 编程时代的一种协作协议：人类负责定义意图，AI 负责生成实现，规范负责承接两者之间的契约。

1. 为什么 AI 编程需要 SDD

很多人第一次使用 AI 编程工具时，体验都很像 Vibe Coding：告诉 AI 一个大概想法，它很快生成代码；跑一下，报错；继续让它修；再报错；再继续。

这种方式非常适合原型验证，也非常容易让人上头。因为它快，反馈即时，而且经常能在几分钟内做出过去要半天才能搭起来的东西。

但当项目从 Demo 走向生产，问题会逐渐暴露出来。

1.1 上下文会丢失

AI 的工作记忆通常围绕一次会话展开。你在今天的对话里告诉它"我们统一用业务错误码，不直接抛 HTTP 异常"，它能记住；但一周后换一个窗口、换一个同事、换一个任务，它就未必知道这条规则了。

更麻烦的是，很多关键决策并不在代码里，而是在钉钉、会议、外部知识库、群聊和临时文档里。人类团队可能还记得这些背景，但 AI 不会天然知道。

于是就会出现一种常见断层：AI 生成的代码在局部看很合理，却违背了项目过去已经达成的约定。

1.2 自然语言提示太容易歧义

"帮我实现用户登录"听起来很明确，但对 AI 来说里面有大量隐含问题：

登录失败返回什么？
是否限制失败次数？
是否需要刷新 token？
是否要兼容旧账号体系？
是否记录审计日志？
是否区分业务错误和系统错误？

如果这些问题没有被写出来，AI 就只能猜。它猜得可能不错，也可能完全偏离你的业务预期。

AI 编程最危险的地方往往不是"代码不能运行"，而是"代码能运行，但行为不是你真正想要的"。

1.3 代码生成很快，返工也会变快

AI 提升了生成速度，也放大了错误扩散速度。

在没有规范约束的情况下，一个模糊需求可能被 AI 展开成十几个文件的修改。等你发现方向错了，已经不是改一行提示词的问题，而是要重新理解一整片生成代码。

这也是很多开发者的真实体验：AI 写代码很快，但我审 AI 的代码、修 AI 的偏差、解释项目上下文，也花了不少时间。

SDD 解决的正是这个问题：在生成代码之前，先把意图和边界固定下来。

2. 什么是面向 AI 的 SDD

SDD 的核心很简单：

在让 AI 写代码之前，先让人和 AI 对"要做什么、为什么做、做到什么程度"达成明确共识。

这里的 Spec 不一定是厚重的需求文档。它可以是一页 Markdown，可以是一组验收标准，可以是一份任务拆解，也可以是一套团队长期维护的规则。

关键不在于文档有多长，而在于它是否能回答几个问题：

这个功能解决什么问题？
哪些行为必须发生？
哪些行为明确不做？
有哪些边界条件？
怎样证明它完成了？
有没有项目级约束必须遵守？

如果这些问题没有被写清楚，AI 生成代码时就会用自己的默认假设补齐空白。

2.1 Spec 是人机协作的契约层

Spec 不再是"写给人看的说明书"，而是"写给 AI 执行的契约"。它同时服务两类对象：

对人类：帮助你在动手前澄清思路，避免需求漂移。
对 AI：提供稳定、可引用、可验证的上下文。

当 AI 生成代码时，它不是自由发挥，而是在履行 Spec。当人类审查代码时，也不是凭感觉判断"看起来还行"，而是对照 Spec 检查是否满足约定。

这就是 SDD 和普通 Prompt 编程最大的区别：Prompt 往往是一次性的，Spec 是可沉淀、可复用、可追踪的。

2.2 SDD 和 TDD、BDD 的关系

SDD 并不是要替代 TDD 或 BDD。

更合理的理解是：

TDD 关注"代码是否按测试预期工作"。
BDD 关注"系统行为是否符合业务场景"。
SDD 关注"在 AI 开始实现前，人类意图是否被清楚表达"。

也就是说，SDD 更靠前。它决定要构建什么，再派生出测试、任务和实现。

一个完整的 AI 时代开发链路可以是：

text 复制代码

Spec -> Plan -> Tasks -> Tests -> Code -> Verify

其中 Spec 定义方向，Plan 定义方案，Tasks 定义执行颗粒度，Tests 定义验证方式，Code 由 AI 生成或辅助生成，Verify 负责把结果拉回到规范。

2.3 SDD 的三种实践强度

SDD 不是非黑即白的流程。不同团队、不同项目、不同任务，可以采用不同强度。

2.3.1 轻量级：Spec-first

这是最容易开始的一层。

在写代码前，先写一个短 Spec，明确目标、边界和验收标准。任务完成后，这份 Spec 可以保留，也可以归档。

适合：

小功能开发
原型验证后的工程化
个人项目
临时但有一定复杂度的改动

示例：

md 复制代码

## 目标
为用户登录增加失败次数限制。

## 范围
- 连续 5 次密码错误后锁定账号 15 分钟。
- 锁定期间禁止密码登录。
- 成功登录后清空失败计数。

## 不做
- 不引入短信验证。
- 不修改 OAuth 登录流程。

## 验收标准
- 密码错误 5 次后返回明确的锁定提示。
- 锁定时间结束后可以重新尝试登录。
- 单元测试覆盖失败计数、锁定、解锁三个路径。

这类 Spec 不复杂，但已经足够防止 AI 自己发挥出"顺手加个短信验证""改掉整个认证模块"之类的行为。

2.3.2 中量级：Spec-anchored

这一层适合团队协作。Spec 不再是一次性计划，而是进入版本库，成为长期资产。

每个重要功能都有对应规范，每次行为变更都先修改规范，再修改代码。这样做的好处是：项目知识不会只存在于聊天记录和某个工程师脑子里，而是沉淀在仓库中。

适合：

中长期产品
多人协作项目
需要持续迭代的业务系统
AI Agent 经常参与开发的代码库

这一层的挑战是 Spec Drift：代码改了，Spec 没改。解决方式也很朴素：把 Spec 更新纳入 MR 检查和代码审查，像检查测试一样检查规范。

2.3.3 高强度：Spec-as-source

这是最激进的一层：人类主要维护规范，代码更多被视为由 AI 生成的派生产物。

在这种模式下，理论上只要 Spec 足够完整，就可以让 AI 重新生成大部分实现。它适合高度标准化、规则明确、变化频繁但边界清晰的系统。

不过对大多数团队来说，这还不是最现实的默认选择。复杂系统里仍然有大量性能、架构、调试和历史兼容问题，需要人类深入理解代码。

所以更务实的路径是：从 Spec-first 开始，在关键模块逐步升级到 Spec-anchored。

3. 主流工具怎么选

不同工具都在往"先规划、再实现"的方向演进，但它们解决的问题并不完全一样。

有些工具强调规范治理，适合把 Spec 当作长期资产；有些工具强调编码流畅性，只在复杂任务前加一层 Plan；还有一些工具更关注存量项目里的变更管理，让每次需求变化都有提案、任务和归档记录。

所以选 SDD 工具，不是选"哪个最强"，而是选"哪种规范强度最适合当前团队"。

3.1 判断维度

我建议从四个维度判断：

规范强制程度：工具是强制先写 Spec，还是只提供可选的 Plan Mode？
规范是否沉淀：产物会进入仓库长期维护，还是只作为一次性计划？
是否适配存量项目：更适合新项目从零建立规范，还是适合在已有系统上做增量变更？
人类介入位置：人是在需求、设计、任务阶段逐步审核，还是只在代码生成后审查？

这四个问题比"哪个工具更智能"更重要。因为 SDD 的核心不是模型能力展示，而是把 AI 的生成能力放进一个可控的工程流程里。

3.2 重规范路线：GitHub Spec Kit 和 Amazon Kiro

GitHub Spec Kit 和 Amazon Kiro 更接近"重规范"路线。

这类工具的特点是：在编码之前，先产生相对完整的需求、设计和任务产物。它们不是只让 AI 写一个计划，而是试图把一次功能开发拆成一条可审阅的规格链路。

GitHub Spec Kit 更像一套工具链和治理框架。它适合那些希望把 Spec 放进仓库、和不同 AI 编码代理协作、并逐步建立团队规范的项目。它的优势是开放、可组合，缺点是流程感更强，需要团队愿意维护规范资产。

Amazon Kiro 则更像一个把 SDD 内置进开发环境的产品。它强调从提示词生成详细规格，再推进到代码、文档和测试。对于已经在 AWS 生态内、希望获得更完整 IDE 体验的团队，它的上手路径会更清晰。但它也意味着团队要接受它的工作流和产品边界。

重规范路线适合错误成本高、协作链路长、需要审计和沉淀的项目。它不适合所有小任务，但适合那些"前面多想十分钟，后面少返工半天"的需求。

3.3 渐进规划路线：Cursor 和 Claude Code

Cursor 和 Claude Code 更接近"渐进规划"路线。

它们不会强制每个需求都进入完整 SDD 流程，而是在复杂任务前提供 Plan Mode。也就是说，你仍然可以保持日常编码的流畅性，只在需要时让 AI 先阅读代码、提出计划、列出将要修改的文件，再进入实现。

Cursor 的优势是 IDE 体验顺滑，适合高频编码、快速迭代和原型推进。它的 Plan Mode 更像是在 Agent 编码前加一个协作式"刹车"：先让 AI 想清楚，再让人确认。

Claude Code 的优势是终端原生、自动化能力强，适合多步骤任务、脚本化工作流和团队自定义规则。它的 Plan Mode 会先探索并提出方案，在确认前不直接修改源码，这一点很符合 SDD 中"先共识、后实现"的思想。

渐进规划路线适合大多数日常研发团队。它不会一开始就引入重流程，但能显著减少 AI 在复杂任务中直接开写带来的偏差。

3.4 轻规范路线：OpenSpec 这类变更驱动工具

OpenSpec 代表的是更轻量的规范路线。

它关注的不是为整个系统一次性建立完整规格，而是围绕一次变更生成提案、任务、技术决策和 spec delta。换句话说，它更关心"这次改动相对当前系统改变了什么"。

这类工具对存量项目更友好。因为真实团队很少有机会从零开始写完整规范，大多数时候是在一个已有系统上持续改功能、修问题、补边界。轻规范工具的价值就在于：不要求你先补齐整个系统文档，而是让每次变更都留下可审阅、可归档的规格痕迹。

如果说重规范路线适合"从项目一开始就建立秩序"，轻规范路线更适合"在已有混乱中逐步建立秩序"。

3.5 对比与建议

你可以按下面的方式理解：

工具/方法	更适合的场景	特点
GitHub Spec Kit	新项目、规范治理、团队约束	偏重流程和治理，适合把 Spec 作为工程资产
Amazon Kiro	生产级功能、AWS 生态、结构化交付	强调需求、设计、任务的连续产物
Cursor Plan Mode	快速迭代、日常开发	保留流畅编码体验，在复杂任务前增加计划层
Claude Code	终端工作流、自动化、多步骤任务	适合把探索、计划、实现、验证串起来
OpenSpec / 类似轻规范工具	存量项目、渐进式引入	更重视变更记录和规范增量

如果读者还没有实践经验，建议不要先纠结工具。先用一个 Markdown 文件把流程跑通。等团队确认 Spec 确实减少了返工，再考虑引入更完整的工具链。

笔者的建议是：

个人项目：先用轻量 Markdown Spec。
小团队：把 Spec 放进仓库，跟 PR 绑定。
中大型团队：为核心模块建立长期规范，普通小改动保持轻量。
高风险系统：引入更严格的验收标准、测试策略和审计链路。

还有一个经验是：不要试图用工具替代团队共识。工具只能帮你保存规范、组织流程、约束 AI，但它不能替团队决定什么是好需求、什么是好设计、什么是可接受的风险。

SDD 的真正门槛不在工具，而在团队是否愿意把"想清楚"变成流程的一部分。

4. 实践：用 zeromoss 落地 SDD

看完外部工具之后，再回到真实研发场景，我们更关心一个问题：如果不只是选一个工具，而是把 SDD 变成团队每天的交付流程，应该怎么做？

zeromoss 是笔者团队内部沉淀出来的一个 SDD 工具。它的目标不是再造一个 IDE，也不是让 AI "更会聊天"，而是把 AI 编码从一次性对话，推进到一个有中间产物、有阶段边界、有验证依据的研发流程。

4.1 AI 编码需要稳定上下文

在部门内部使用 AI 编码的过程中，我们发现，AI 真正难的不是"写不出代码"，而是缺少稳定上下文和可追踪过程。

直接把需求丢给 AI 生成代码，短期效率确实很高。但当需求发生变化、多人协作、需要代码评审或后续维护时，问题会逐渐出现：

实现依据不清楚，只能回头翻聊天记录。
上下文散落在需求文档、会议讨论和临时代码里。
AI 每次接手都像重新冷启动。
需求变化后，不知道哪些设计、测试和任务需要同步调整。
代码评审时很难判断"这是偏离需求，还是需求本身变了"。

所以我们希望把 AI 编码从"对话式提效"改造成"流程化交付"：每一步都有产物，每个产物都能被审阅、追踪和复用。

4.2 把需求交付拆成规格流水线

zeromoss 的核心思路，是用 SDD 的方式约束 AI 编码过程。一次需求不直接进入编码，而是被拆成固定阶段：

text 复制代码

需求输入 -> 需求规格 -> 设计方案 -> 测试用例 -> 任务拆分 -> 编码实现 -> 验证 -> 归档

每个阶段都会产生结构化的 Markdown 文档。上游文档是下游工作的输入：需求驱动设计，设计驱动测试和任务，任务再驱动编码。

这样做之后，AI 不再是根据一次提示词自由发挥，而是在明确的 spec 和 task 约束下执行。人类也不必只在代码生成之后被动审查，而可以在需求、设计、测试和任务阶段逐步校准方向。

这里有一个很关键的变化：编码不再是流程的起点，而是规格流水线的下游结果。

4.3 CLI 做确定性，AI 做生成式

在工程设计上，zeromoss 把确定性工作和生成式工作分开。

CLI 负责那些规则明确、结果可预期的动作：

创建需求目录和阶段文件。
维护阶段状态。
组装当前阶段需要的上下文。
检查必要文档是否存在。
记录上游文档基线。
归档已完成需求。

AI Agent 负责那些需要理解、组织和生成的工作：

整理需求。
生成设计方案。
编写测试用例。
拆分实现任务。
根据任务进行编码。
根据验证结果修正实现。

这种分工的好处是，流程本身不依赖模型发挥。模型可以生成内容，但不能随意改变流程；CLI 保证阶段边界和文件结构稳定，AI 只在被明确约束的阶段内工作。

换句话说，zeromoss 并不把所有事情都交给 AI，而是让程序负责确定性，让模型负责生成性。

4.4 让过程可追踪、可增量、可沉淀

zeromoss 通过 .zero/ 目录保存每个需求的过程产物。一个典型需求会包含：

text 复制代码

.zero/
  changes/
    <feature-id>/
      input.md
      requirement.md
      design.md
      testcase.md
      tasks.md
      verify.md
      change.json

这些文件本身就是阶段状态。例如 design.md 存在，表示设计阶段已经完成；tasks.md 存在，表示需求已经被拆解为可执行任务。相比只保留聊天记录，这种文件化过程更容易进入版本管理，也更容易被团队审阅。

另一个重要机制是基线记录。zeromoss 会记录上游文档的基线。当需求发生变化时，可以基于 diff 增量更新设计、测试和任务，而不是让 AI 重新生成全部内容。

这一点对真实研发很重要。因为需求变更是常态，而已有设计、测试和编码进度不能轻易被覆盖。增量更新能让 AI 明确知道"变化发生在哪里"，也能让人类审查变更影响，而不是重新判断一整份文档。

需求完成后，相关规格可以归档，并沉淀为项目级长期上下文。后续再修改同一模块时，AI 可以基于已有项目 spec 理解背景，而不是每次从零开始读代码、猜约定。

4.5 实践效果与后续方向

从部门实践看，zeromoss 带来的主要变化不是简单地"让 AI 写得更快"，而是让 AI 编码过程变得更可控。

需求、设计、测试、任务和代码之间有了明确映射。代码评审时，团队可以回到 spec 中确认实现是否偏离目标；需求调整时，也可以沿着规格流水线判断哪些下游产物需要更新。

当然，这种方式也有成本。相比直接让 AI 写代码，SDD 要求前期先补齐规格文档，对团队规范意识有要求。Spec 的质量也会直接影响 AI 的产出质量：需求写得模糊，后面的设计、测试和任务仍然会跟着模糊。

目前 zeromoss 更侧重前后端交付流程标准化，对于线上问题治理、运行时反馈、自动回归和自动自愈等能力还在探索中。后续我们希望把生产反馈与自动化测试也纳入规格循环，让线上问题不只是一次修复，而能反向沉淀为新的约束、测试和项目知识。

整体来看，zeromoss 是我们在部门内把 AI 编码从"对话式提效"推进到"流程化交付"的一次实践。它让 AI 不只是写代码，而是参与到一个可审阅、可追踪、可沉淀的研发流程中。

5. SDD 不是银弹

SDD 有价值，但它不应该被滥用。它解决的是 AI 编码中的上下文、约束和追踪问题，不是所有开发问题的万能答案。

5.1 SDD 的成本

SDD 最大的成本，是把原本隐含在脑子里的东西写出来。

这件事听起来简单，实际并不轻松。很多需求在没有落笔之前，看起来都很清楚；一旦要写成 Spec，就会暴露出大量模糊点：边界没定、异常路径没想、验收标准没统一、非目标没说清。

这些成本是真实存在的。它会让开发节奏在前期变慢，也会要求团队形成新的协作习惯。

但这并不一定是坏事。因为很多所谓"AI 写歪了"的问题，本质上不是模型能力不足，而是人类自己也没有把需求想清楚。SDD 只是把这种模糊提前暴露出来。

5.2 SDD 的反模式

实践中最容易踩的坑，是把 SDD 变成另一种形式主义。

第一种反模式是"为了写 Spec 而写 Spec"。文档看起来很完整，但里面都是空泛描述，无法约束实现，也无法指导验收。这种 Spec 只是多了一层包装，并没有真正降低不确定性。

第二种反模式是"Spec 写完就不管了"。如果代码变化后规范不更新，Spec 很快会变成误导 AI 的过期上下文。对 AI 来说，错误的上下文比没有上下文更危险。

第三种反模式是"一刀切流程"。所有任务都强制走完整 SDD，会让团队觉得这是负担，而不是帮助。越是轻量的任务，越应该允许轻量处理；越是关键的模块，越值得投入完整规范。

5.3 更务实的采用方式

对多数团队来说，最好的路径不是一口气重塑流程，而是渐进引入。

可以先从三类需求开始：

需求经常变、返工多的功能。
多人协作时容易理解不一致的功能。
曾经因为边界没说清而出过问题的模块。

这些地方最容易体现 SDD 的价值。等团队看到它确实减少返工，再逐步把 Spec 纳入 MR、测试和归档流程。

所以，SDD 不是让团队回到"文档先行、流程至上"的旧时代。它真正想解决的是：当 AI 可以快速生成实现时，我们如何保证它生成的是正确方向上的实现。

6. 结语：未来研发角色的核心能力是定义问题

AI 编程工具会继续变强。它们会更理解代码库，更擅长多文件修改，也会越来越多地参与测试、重构和部署。

但这并不意味着工程师的价值会消失。相反，工程师的价值会从"亲手写每一行代码"转向"判断什么是正确的软件"。

当实现成本下降，意图表达就变得更重要。

你越能清楚描述目标、边界、约束和验收标准，AI 的产出越接近一个可靠的工程伙伴。你越只是给出模糊愿望，AI 就越容易变成一个速度很快但方向不稳的执行者。

SDD 的本质，不是多写文档，而是重新建立一种工程纪律：

先定义意图，再生成代码；先达成共识，再追求速度。

AI 可以帮我们写代码，但它不能替我们决定什么值得被构建，也不能替我们承担错误决策的后果。

这也会带来一个更大的变化：研发和产品的边界可能会越来越模糊。

过去，产品经理负责定义需求，研发负责技术实现，两者之间通过 PRD、评审会和排期协作。这个分工建立在一个前提上：实现成本很高，需求表达和技术实现需要明显分离。

但当 AI 能够承担越来越多实现工作之后，真正稀缺的环节会前移到"问题定义"和"结果验证"。谁能把业务目标、用户场景、系统约束和验收标准表达清楚，谁就能更直接地驱动 AI 产出软件。

这意味着未来的研发需要更懂产品：理解用户目标，识别真实问题，而不是只接收需求。未来的产品也需要更懂工程：知道什么样的约束能被实现，什么样的验收标准能被验证，什么样的 Spec 能驱动 AI 稳定产出。

也许未来不会简单地保留"产品写需求、研发写代码"的分工，而是出现一种更统一的角色：围绕问题定义、规格设计、AI 协作和结果验证来交付软件。名字可能还是产品、研发或工程师，但核心能力会越来越接近。

未来优秀工程师和普通工程师的差距，可能不再主要体现在谁写代码更快，而在于谁更能把复杂问题表达成清晰、可执行、可验证的规范。未来优秀产品和普通产品的差距，也可能不只是谁更会写 PRD，而是谁更能把需求转化为 AI 可以执行、团队可以审阅、系统可以验证的规格。

这就是 SDD 在 AI 时代真正值得讨论的地方。

从 Vibe Coding 到 SDD：AI 编程的工程化演进