规范驱动开发（SDD）#

规范驱动开发并不是一个因为 AI 时代才突然出现的新概念。它早就存在了。

过去可能叫它工程规范、架构设计、文档驱动、接口契约，只是现在，在 AI 编程的背景下，它被重新推到了舞台中央

因为 AI 把所有"不规范"的问题都放大了

围绕"规范驱动开发"的工具和方法开始出现，比如 OpenSpec、Spec Kit、BMad

open spec#

https://github.com/github/spec-kit

这里有一个中文版，但是star 不多

https://github.com/888888888881/spec-kit-chinese

Spec 驱动开发（Spec-Driven Development）中，我们将流程变为“需求 -> 规范（Spec）-> 代码”

OpenSpec：让 SDD 落地#

OpenSpec 是一个轻量级的框架，它通过一套标准的文件结构和工作流，让 SDD 变得简单易行。它主要包含两个核心概念：

Specs (openspec/specs/)：当前系统的真实状态。这里存放着系统现有的功能规范。
Changes (openspec/changes/)：对未来的提案。当你想要修改系统时，你不是直接改代码，而是先创建一个 Change Proposal（变更提案）

工作流：从提案到归档#

OpenSpec 强制执行一个严谨的“三步走”流程：

起草（Draft）：创建一个新的 Change 文件夹（例如 openspec/changes/add-login），在里面写下 proposal.md（为什么改、改什么）和 tasks.md（怎么改），以及该变更涉及到的 Spec 增量（openspec/changes/add-login/specs/**/spec.md）。
实施（Implement）：AI 根据通过审核的 Proposal 和 Spec 增量（Delta）来编写代码，并按 tasks.md 的清单逐项完成。
归档（Archive）：功能上线后，将 Change 归档。此时，Change 中的 Spec 增量会被合并到主 Specs 中，成为新的“真实来源”，历史提案则被移入 openspec/changes/archive/

GitHub Spec Kit#

SDD 的四大关键词#

SDD 的理念可以概括为四个关键词：

Intent first：明确要「做什么/为什么」，再谈实现细节；
Rich specs：用结构化的规格与检查清单约束 AI；
Multi-step refinement：多阶段收敛替代一次性大Prompt；
Model-agnostic control：与多种代理协同但不绑定技术栈。

SDD 的六大核心原则#

这套思想进一步具化为六大核心原则，它们共同构成了 Spec Kit 的「方法论骨架」：

规格是主要产物：代码只是规格的一种实现。这彻底扭转了「代码为王」的传统观念。
可执行的规范：规范必须足够精确，能够生成可工作的系统，杜绝模棱两可。
持续细化：开发是一个持续验证和调整的过程，而不是一次性活动。
研究驱动的背景：在动手前，通过专门的「研究代理」收集足够的技术和业务背景信息。
双向反馈：生产环境的实际表现（如性能指标、用户行为）应反向驱动规格的演进。
分支探索：支持从同一份规格探索多种技术实现路径（如追求性能、追求低成本等），方便做出最优决策。

Spec Kit 完整工作流七步详解#

# 推荐使用 uv (一个极速的 Python 包管理器)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
``

1. 制定宪法 (/constitution)
这是项目启动的第一步，也是最重要的一步。

目的：为项目建立一套最高准则，包括技术原则、代码规范、安全要求、质量标准等。这份「宪法」将成为后续所有技术决策的基石。
产出：生成 .specify/memory/constitution.md 文件。
实践者贴士：我通常会把团队的技术栈偏好、部署环境要求、甚至对第三方库的选用原则都写入「宪法」。这样，AI 在后续规划技术方案时，就不会天马行空。
2. 创建功能规范 (/specify)
这是定义「做什么」的关键环节。

目的：用自然语言清晰、完整地描述你要构建的功能、用户故事和验收标准。注意，此阶段完全不涉及技术实现。
产出：在 specs/ 目录下创建一个以功能命名的文件夹，并生成核心的 spec.md 文件。
实践者贴士：写 spec 时，把自己当成产品经理。描述越具体越好，例如「用户点击完成按钮后，任务项应变为灰色，并移动到列表底部」，而不是「用户可以完成任务」。
3. 澄清需求 (/clarify)（可选）
这是在制定技术方案前，消除模糊地带的关键一步。

目的：让 AI 角色扮演一位挑剔的测试人员或产品经理，对你写的 spec.md 提出问题，帮助你发现其中描述不清或有歧义的地方。
产出：对 spec.md 的补充和修正。
实践者贴士：这是我最喜欢的一个环节。它强制我在编码前，就把所有可能的边界情况和异常流程想清楚，能有效减少后期返工。
4. 生成技术方案 (/plan)
AI 从「产品经理」切换为「架构师」角色，开始设计「怎么做」。

目的：基于 spec.md 和 constitution.md，制定一份详细的技术实现计划，包括技术选型、架构设计、数据模型、API 契约等。
产出：生成 plan.md、data-model.md 等一系列设计文档。
实践者贴士：如果 AI 给出的技术方案不符合你的预期（例如，选了一个你不熟悉的库），可以直接让它修改。整个过程你始终拥有最终决策权。
5. 分析计划 (/analyze)（可选）
在分派任务前，进行最后一次「沙盘推演」。

目的：让 AI 检查所有已生成的工件（spec, plan 等），分析是否存在矛盾、遗漏或不一致的地方，确保计划的完备性和可行性。
产出：一份分析报告，指出潜在的问题。
实践者贴士：这一步虽然不是强制的，但我强烈建议不要跳过。它就像代码审查（Code Review）一样，能在早期发现许多高成本的错误。
6. 生成任务列表 (/tasks)
将宏伟的蓝图分解为具体的施工步骤。

目的：将 plan.md 中的技术方案，自动分解为一张详细、可执行、有依赖关系的任务清单。
产出：生成 tasks.md 文件，其中每个任务都清晰明了。
实践者贴士：tasks.md 文件是与 AI 协作的核心界面。你可以随时介入，手动调整任务的优先级，或者将某些任务标记为自己完成。
7. 执行实现 (/implement)
万事俱备，AI 开始化身「程序员」，将任务逐一实现。

目的：根据 tasks.md，按顺序、有条不紊地执行所有开发任务，生成最终的代码。
产出：可运行的应用程序代码。
实践者贴士：你可以让 AI 一次性执行所有任务，也可以一个一个地执行。对于复杂任务，我更喜欢后者，这样可以随时检查每一步的产出，确保一切尽在掌握。
通过这七个步骤，Spec Kit 将一个模糊的「想法」，逐步精炼成一套结构清晰、文档齐全、代码可靠的软件项目。

实战：用 Spec-Kit + Claude Code 开发「任务管理器」应用
接下来，我将演示如何一步步使用 spec-kit 开发「任务管理器」应用


https://zhuanlan.zhihu.com/p/1981659360842249886