文章目录[隐藏]
背景介绍
随着大语言模型（LLM）深度融入软件开发流程，传统的“代码为王”范式正在被“意图优先”的新模式所颠覆。code is cheap, show me your prompt 对 talk is cheap, show me your code 的取代也标志着软件开发正迈向一个以自然语言为媒介、以规范为核心的新时代。
在这一背景下，规范驱动开发（Spec-Driven Development, SDD） 应运而生，旨在解决“氛围编程”（Vibe Coding）中的提示词工程化、结构化、当前任务完结后续的可演进可维护等核心痛点，也可以理解为面向 AI 智能体的服务整个软件生命周期的云效系统。
它的核心是 Spec，Spec 可以激进点理解成一种自然语言的编程语言，以今天的视角回望当年，真正完全版的 易语言 正在成为现实，从汇编到面向对象的发展轨迹，下一个节点很有可能就是自然语言编程，未来的程序员不需要理解 Java 正如现在的程序员不需要理解汇编。由智能体将 Spec 稳定 “编译” 为开发语言，再由各种 Compiler “编译” 为机器语言。
Spec 具体落地是什么
Spec 从提出到现在唯一确认的就是它是个规范，是个开发或者产品的需求描述。更具体的文件格式存储、目录规划以至生效工作流程模式都没有形成完善的最佳实践，各家都在进行相关的尝试。但是有一点可以确认，Spec 是整个项目的核心，工程代码应该是可基于规范重建的。
计划模式
最简单的 、用的最多的 SDD 就是各种 IDE 里的计划模式，如在 cursor 中当用户提交的任务比较复杂时，cursor 也会自动切换为 plan 模式，来回询问确认几个问题后生成一个 plan 文档，一般存储在用户目录下的 .cursor/plans 中，每个计划中包含完善的项目设计、任务规划等。
GitHub Spec-Kit
Spec-Kit 是由 GitHub 开源的一套高度结构化、可审计的 SDD 开发工具包，一般安装为 CLI 命令，也可以嵌入 Cursor、ClaudeCode、Gemini、QwenCode 等。
它的定位是一套企业级治理工具，强调流程、标准和可审计性，整体的工作流程是：
Constitution → Specify → Plan → Tasks → Implement
宪法 → 需求 → 计划 → 任务 → 实现
Constitution中定义“不可更改”的通用标准原则，例如当前的开发语言、技术栈选型、代码风格、覆盖率、安全策略等具体需求无关的描述。AI 会在后续所有步骤中遵循此文件，这是其治理能力的核心。Specify是一组产品需求描述，重点在于讲清业务逻辑、验收标准等，不涉及具体代码设计。Plan是对应Specify的开发实现计划，包含架构、数据模型、API 设计、代码框架设计等。Tasks是Plan的原子化任务拆解，到这一步就是完善的任务列表了。如果需要生成测试用例也是基于这步产出。Implement代码落地，任选 IDE 基于前面的文档生成最终代码交付。
Spec-Kit 相对最适合从零开始的全新项目 或对规范严谨性、可追溯性要求极高的中大型企业团队。其局限在于学习曲线较陡，完整的 8 步流程（初始化 → 宪法制定 → 规格定义 → 澄清 → 规划 → 任务生成 → 实现 → 验证与迭代）对于小型改动或快速原型显得繁琐。
OpenSpec
号称最受欢迎的 SDD 框架，由 Fission AI 团队推出，其设计哲学与 Spec-Kit 有显著不同，相对轻量级、可审查、可追溯、变更隔离，更侧重于对现有系统的安全、可控迭代。这套规范有两个版本，旧版的整体流程是：
Proposal → Spec Definition → Apply → Archive
提案 → 生成规范 → 实现 → 存档合并
OpenSpec 采用双层隔离架构。 openspec/specs/ 记录系统当前状态的规范，是当前系统运行中的实际 spec， openspec/changes/<change-id>/ 则存放每次变更的提案、任务以及以“增量”格式描述的规范变更（如ADDED/MODIFIED/REMOVED）。这种设计的最大优势是 审计追踪极其简单，变更差异如同 Git diff 一目了然，非常适合维护和重构遗留系统。
官方觉得这套单向固定的开发流程太死板，所以推出了新版本 OSPX 新模式，新版本是一套灵活、基于 Action 的可定制工作流
/opsx:explore 探索想法
/opsx:new 创建变更提案
/opsx:continue 执行下一步，配合 config.yaml 可以实现自定义开发流程
/opsx:apply 执行任务编写代码
/opsx:archive 同步、归档，将所有文档合并到主 spec
横向比较
| Spec-Kit | OpenSpec | BMAD-METHOD | |
|---|---|---|---|
| 核心理念 | 可执行、可重复 | 轻量级变更隔离 | 智能敏捷 |
| 背景策略 | 清晰的边界/检查点文档 | 隔离并跟踪与基线的差异 | 角色模拟 |
| 适用场景 | 全新的企业级项目 最理想的工程化大型项目 |
成熟复杂的老项目 对现有代码友好 支持 AI 定制化 |
复杂的全新领域项目 多智能体协作 领域专家模拟 |
| GitHub 星数 |
最高 (67.4k ⭐) | 高 (22.1k ⭐) | 高 (34k ⭐) |
总结
SDD 的兴起并非偶然，它是 AI 生产力变革过程中出现的当前阶段的一种相对更好的解决方案。
- 解决了 AI 的幻觉和上下文管理：通过结构化的规范文档，为 AI 提供了稳定、完整的项目级上下文，大幅减少了因对话历史限制导致的“遗忘”和“幻觉”问题，大大简化交互过程。
- 重塑团队协作与知识沉淀：规范文档成为团队对齐需求新共识点，避免了“你以为我以为”的沟通成本。所有需求、设计都随着规范文档版本化，形成了可审计的“证据链”。
- 适应开发全生命周期：这是一套完善的软件开发流程，是瀑布模型、敏捷模型适配 AI 智能体后的一种尝试。
- 迈向真正的自然语言编程：SDD 不一定是最终答案，但自然语言编程一定是。
发表回复