规格驱动开发(Specification-Driven Development,简称SDD)是一种将"规格"置于开发流程核心的AI编程范式。它的核心思想很简单:先写清楚"做什么",再让AI去实现"怎么做"。
这种方式能有效解决"Vibe Coding"(凭感觉编程)中常见的需求偏离和AI"幻觉"问题。在这个领域,spec-kit和openspec是目前最具代表性的两个工具,它们各有侧重。为了方便你理解,我做了一个对比表格:
| 维度 | SpecKit (GitHub) | OpenSpec (Fission-AI) |
|---|---|---|
| 一句话定位 | 从0到1的新项目"开荒神器" | 从1到n的现有项目"手术刀" |
| 适用场景 | 绿地项目 (Greenfield):没有历史包袱,一切从零开始 | 棕地项目 (Brownfield):有大量现有代码,需在不破坏原有结构的前提下添加新功能 |
| 核心哲学 | 构建一个完整的、结构化的规范框架,然后让AI一次性生成代码 | 通过"提案-审查-归档"的增量变更流程,原子化地修改规范,防止规范"腐烂" |
| 工作流 | 固化流程:宪章 → 规范 → 澄清 → 计划 → 任务 → 实现 | 轻量流程:起草提案 → 审查对齐 → AI实施 → 归档更新 |
| 变更管理 | 每个功能对应一个独立分支,变更记录较分散 | 每个变更对应changes/下的独立文件夹,所有提案、任务、规范增量都在一起,归档后合并进主规范 |
| 上手难度 | 标准化,但流程较重,适合团队级应用 | 更轻量,更灵活,对个人开发者和现有项目非常友好 |
下面是更详细的说明:
🎯 核心理念对比:为什么它们不同?
两者都是SDD思想的优秀实践,但解决的核心矛盾不同:
-
SpecKit:为混乱的AI开发建立"宪法"
- 它源自GitHub,旨在为AI辅助开发提供一种标准化的工程实践。它的核心理念是"意图驱动开发 ",即通过一个项目级、不可动摇的"宪法(Constitution)"来约束后续所有的AI行为。这个"宪法"定义了项目的技术栈、代码风格、架构原则等,是所有后续开发活动的最高准则。
- 当接到一个新需求时,SpecKit会严格遵循"规范 → 计划 → 任务 → 实现"的四步法。这种结构化的流程能确保在编写任何代码之前,需求和实现方案都已被充分定义和审查,非常适合需要稳定架构和长期维护的企业级项目。
-
OpenSpec:为演进中的系统提供"手术方案"
- 它由Fission-AI团队开发,最核心的设计目标是解决现有项目(棕地项目)的AI开发难题。
- 它最大的亮点是变更管理 。对于现有系统,我们无法推倒重来,只能增量修改。OpenSpec通过一个非常清晰的文件夹结构来实现这一点:
openspec/specs/:存放当前系统已实现的"真相源"(Truth Source),代表系统的当前状态。openspec/changes/<变更名>/:每个新功能或修改都是一个独立的"变更"。这个文件夹里包含了:proposal.md:提案,说明为什么要改、改什么。tasks.md:任务清单,是AI的实施步骤。specs/:规范增量,这是一个"补丁"文件,清晰描述了相对于当前specs/目录,哪些规范是新增(ADDED) 、**修改(MODIFIED)或删除(REMOVED)**的。
- 这个机制让每一次变更都有独立的审计轨迹,AI可以专注于实现当前变更,同时保证主线规范的稳定。
⚙️ 工作流实战:一个厨房定时器App
为了让你更直观地感受差异,我们以"开发一个厨房定时器App"为例,看看两个工具的工作流:
使用 SpecKit 的新项目(0→1)
SpecKit的流程像一个流水线,一步步从想法生成最终代码。
- 初始化与定"宪法" :执行
specify init my-timer,然后通过/speckit.constitution命令定义项目"宪法",例如:"使用React + TypeScript,所有组件必须是函数式组件,测试覆盖率不低于80%"。 - 描述需求(WHAT) :执行
/speckit.specify,描述需求:"需要一个厨房定时器App,包含1、3、5分钟的按钮,倒计时过程中再次按下按钮会重置计时器,并以大号字体显示剩余时间。" AI会根据你的描述生成一份详细的spec.md功能规范。 - AI澄清与规划(HOW) :
- 执行
/speckit.clarify,AI会主动提问,比如:"计时结束时是否需要声音或视觉提示?在手机和电脑上布局是否需要响应式?"你需要和AI交互,澄清这些细节。 - 执行
/speckit.plan,AI会生成技术实现方案plan.md,确定用什么状态管理、如何组织组件等。
- 执行
- 拆解任务与实现 :
- 执行
/speckit.tasks,AI会将计划拆解成一个个具体的、可勾选的小任务tasks.md,例如"创建TimerDisplay组件"、"实现useTimerHook"等。 - 最后,执行
/speckit.implement,AI会按照任务清单,一步步生成所有代码,完成整个应用。
- 执行
使用 OpenSpec 的现有项目(1→n)
现在假设这个定时器App项目已经存在,你想为它增加一个"秒表"功能。OpenSpec会像外科手术一样精确地完成这个任务。
-
起草变更提案 :在聊天框中输入
/openspec:proposal add-stopwatch。AI会在openspec/changes/add-stopwatch/目录下为你创建所有必要的文件。 -
审查与对齐 :打开生成的
proposal.md和specs/下的增量规范文件,检查AI对需求的理解。例如,spec.md的增量文件会清晰标明:markdown## ADDED Requirements ### Requirement: 秒表功能 系统应提供秒表模式,允许用户开始、暂停和重置计时。你可以直接编辑这些Markdown文件来修正,确保规范准确无误。
-
AI实施 :执行
/openspec:apply add-stopwatch命令。AI会读取changes/add-stopwatch/下的提案和任务,仅仅在这个变更的上下文中工作,生成实现秒表功能所需的代码。 -
归档与更新 :秒表功能开发完成并测试通过后,执行
/openspec:archive add-stopwatch。这个命令会将add-stopwatch变更中的规范"补丁"合并到主specs/目录下,更新系统的"真相源"。add-stopwatch文件夹则作为历史归档。现在,整个项目既有了秒表功能,其规范文档也始终与代码保持同步。
💎 如何选择?
总的来说,你的选择取决于具体场景:
- 想从一个想法快速启动一个干净、符合规范的新项目,并希望流程标准化? → 选择 SpecKit。
- 你面对的是一个已有大量代码的复杂项目,需要在保证稳定性的前提下,用AI可靠地添加新功能或进行重构? → 选择 OpenSpec。
- 想寻求一种更轻量、更灵活的方式来管理你的AI开发过程? → OpenSpec 是更好的起点。
规格驱动开发并不是要替代开发者的思考,而是将思考的重心从"如何编码"转移到"如何精确地定义问题"上。在这个过程中,开发者更像是一个架构师或产品经理,核心工作是定义意图、审查方案、把控质量,而具体的代码实现则放心地交给AI去完成。