SDD(规范驱动开发)正在让 Vibe Coding 走在正确的方向上
一场静默的范式革命
SDD的诞生背景：从“氛围编码”的狂欢到工程化的必然
代码是需要严谨的, 所以需要严谨的规范来约束失控的 vibe coding。 SDD的核心在于权力的反转：规范映射需求，代码只是规范的实现。
你有没有遇到过这种情况？满怀期待地让AI助手写代码，结果它理解错了需求，写了一堆你不想要的功能；或者你想让它改个小地方，结果它把整个文件都改乱了；又或者几轮对话后，AI完全忘了你最初想要什么，代码越改越偏...
AI编码助手确实强大。给它一个提示，几秒钟就能生成一大段代码。但这种"快"背后，藏着一个很大的问题：当需求只存在于聊天记录里时，AI会变得非常不可预测。
尽管市面上的 AI 工具提供了像 Rules、Indexes、MCP 等配置项，但是这些配置项解决的代码本身规范、质量问题，距离通过需求生成适合的代码还有很大的距离。
SDD的兴起，直接源于对当前主流AI编程模式——“氛围编码”（Vibe Coding）的深刻反思与纠偏。
更深层次的背景，是传统“代码为王”开发模式的固有困境。在传统模式中，产品需求文档（PRD）、技术方案等规范文档，往往在编码开始后便被束之高阁，甚至被丢弃。代码成为了唯一的“真理来源”，而规范则沦为临时的“脚手架”。这导致文档与实现严重脱节，知识难以传承，团队协作效率低下。当需求变更时，手动将变更同步到代码、文档和所有相关方的成本极高，要么导致迭代缓慢，要么积累下沉重的技术债务。
SDD 的核心理念是进行一场“权力的反转”：让规范（Specification）成为软件开发过程中的核心产物和“单一真相来源”，而代码则降级为规范在特定语言和框架下的具体表达。开发团队维护和演进的不再是代码，而是规范；调试意味着修复生成了错误代码的规范；重构意味着为了更清晰地表达意图而重组规范。这场变革之所以在当下成为可能，是因为现代AI已经具备了理解复杂业务需求、技术规范并据此生成结构化代码的能力。SDD旨在为这种强大的、但略显“随意”的AI能力，套上“工程化”的缰绳。
SDD带来的根本性改变：工作流、协作与质量的重塑
SDD不仅仅是一种新工具，它带来的是软件开发全流程的范式变革。
1. 工作流：从“混乱编码”到“规范驱动”
从线性迭代到结构化多阶段
传统敏捷开发在需求、设计、编码间快速迭代，但容易导致意图走样(一个看似微小的需求变更，往往会引发代码层面的连锁反应)。
SDD引入了一个严谨的、多阶段的结构化流程。以GitHub Spec-Kit为例，其典型工作流包括： 制定项目宪法（Constitution）→ 编写功能规范（Specify）→ 澄清需求（Clarify）→ 制定技术计划（Plan）→ 分解任务（Tasks）→ 执行实现（Implement）
2. 开发者角色的升维
从“编码者”到“架构师与规格设计师”
在传统的开发模式中，开发人员只需要编写代码。但是，由于需求文档往往不完整，开发人员需要根据经验进行猜测，这导致了代码的混乱和质量的下降。
SDD将开发者从繁重的、重复性的“代码”编写中解放出来。他们的核心职责前移，转变为“意图定义者”和“规格设计师”。开发者需要投入主要精力，用精确、无歧义的结构化语言（如Markdown）来定义业务需求、用户场景和验收标准。他们还需要为项目制定“宪法”，定义不可违背的架构原则、代码质量标准和协作规则。编码本身，则交由AI在既定框架内自动化完成，开发者转变为AI生成成果的“验证者”和“集成者”。
3. 团队协作的透明化
从“技术黑盒”到“开放规约”
结构化的规范文档成为了产品经理、业务分析师、开发者和测试人员之间的“通用语言”和“共同参考点”。业务需求被直接写入可执行的规格，技术方案基于此生成并接受审核。这种透明化打破了部门墙，使业务意图与技术实现能够高度对齐，大幅减少了因沟通不畅导致的需求偏差和返工。
4. 质量保障的左移与内化
从“事后测试”到“事前约束”
质量保障的范式从依赖开发后的测试，转变为开发前通过“宪法”设立不可违背的原则，和开发中通过模板与流程强制生成高质量代码。AI在实现阶段被强制要求先编写失败的测试，再编写实现代码（遵循TDD）。这种内嵌的最佳实践，使得生成的代码从诞生之初就具备高测试覆盖率和一致性。
SDD的主流解决方案
目前，SDD的实践主要通过一系列工具落地，它们各自代表了不同的设计哲学和适用场景。
1. GitHub Spec-Kit
企业级治理与全流程自动化
由GitHub推出的开源CLI工具包，强调“规范即代码工件”和全流程治理。其核心特征是引入了“宪法”（Constitution）机制，一个定义项目高层原则的记忆库文件，确保AI在所有阶段都遵循统一标准。它提供从宪法制定、规范定义、计划生成到任务拆解、代码实现的全套结构化命令，流程严谨，适合对标准化、可审计性要求高的大型团队和项目。
2. Amazon Kiro
轻量灵活的代理式集成开发环境（Agentic IDE）
Kiro定位为个人开发者或小团队的快速原型与开发加速器。它采用固定的“需求（Requirements）→ 设计（Design）→ 任务（Tasks）”三步工作流，每个步骤对应独立的Markdown文档。Kiro强调高度的自动化，内置了“代理钩子”（Agent Hooks）功能，可以在文件保存等事件发生时自动运行任务，交互自然，上手门槛低，适合追求开发速度和敏捷迭代的场景。
3. Tessl Framework
探索“规范即源码”的前沿框架
目前仍处于探索阶段，是唯一明确追求“规范锚定”（Spec-anchored）并探索“规范即源码”（Spec-as-source）这一SDD最高层级的工具。其核心理念是让规范成为项目的核心维护对象，人类只编辑规范，AI负责代码生成，甚至生成的代码文件会标注禁止人工修改。它独特地支持规范与代码的双向映射，对在已有代码库上进行增量开发尤其有价值。
4. OpenSpec
专为“增量开发”而生的轻量框架
由Fission AI团队开源，其设计哲学专为解决在已有代码库（棕地项目）上进行安全、可审计的迭代。它采用了独特的“双文件夹架构”，将项目的“当前真实状态”（specs/目录）与“拟议的变更”（changes/目录）进行物理和逻辑上的分离，确保变更不会污染稳定规范。其工作流围绕“变更提案”展开，强调团队对齐和风险控制，非常适合维护遗留系统的团队。
未来对开发者的影响：挑战、机遇与角色重塑
SDD的普及将对开发者群体产生深远而复杂的影响。
1. 核心技能的迁移与升级
未来的顶尖开发者，其核心竞争力将从“编写代码的技艺”转向“定义问题和设计解决方案的能力”。这要求他们具备更强的抽象思维、业务理解能力，以及用结构化语言精确表达意图的“规格工程”技能。同时，与AI进行高效协作、引导和审核的能力变得至关重要。开发者需要学习如何撰写高质量的规范，如何制定有效的项目“宪法”，以及如何审阅AI生成的技术方案和代码。
2. 团队协作与组织文化的演进
SDD将促进更加透明和高效的跨职能协作。规范文档成为团队共享的知识资产，便于新成员融入和知识传承。企业可以将内部的编码规范、安全策略等固化到“宪法”和模板中，实现企业级知识的编码与复用，确保无论团队成员使用何种AI助手，产出都能符合统一标准。
3. 潜在的“Verschlimmbesserung”风险
德语中有一个词叫“Verschlimmbesserung”，意指试图改进某事却使其变得更糟。SDD是否可能将现有的工作流过于字面地“喂”给AI，最终放大了现有的挑战，如审查过载和AI幻觉。关键在于，SDD应在提供结构的同时，保持足够的灵活性，适应不同规模和类型的开发任务。
结论
SDD是一场静默的范式革命, 在 AI 的加持下，它正在让 Vibe Coding 变得更加严谨，更加工程化，更加符合AI 时代的开发范式。
后续继续更新 SDD 的实践案例，规划中会包括但不限于：
- OpenSpec 的实践案例（现有代码中进行增量规范驱动开发）
- GitHub Spec-Kit 的实践案例
- SDD 工程化实践案例
公众号会持续输出，欢迎关注。 如果对你有帮助，欢迎点赞、收藏、关注。 