文章的核心内容是对比了当前AI辅助编程领域中规范驱动开发SDD的三种主流实现框架OpenSpec、Spec Kit和BMAD并基于此提出了提升AI编码质量的通用实践准则。一、 主流SDD框架横向对比博客通过一个结构化的对比表格清晰地展示了三种框架在设计哲学、适用场景和流程上的核心差异。维度OpenSpec (Fission AI)Spec Kit (GitHub)BMAD设计哲学轻量、实用强调对现有代码库的演进。严谨、流程化强调规范是工程的核心。重型、架构先行适合大模型代理协作。技术栈TypeScript / npm (安装简单)Python / CLI (配置稍复杂)理论框架 / 模版核心流程Proposal - Apply - ArchiveSpecify - Plan - Tasks - ImplementAnalyze - Design - Implement适用阶段存量项目Brownfield迭代优于从零开始。新项目Greenfield或复杂功能设计。企业级复杂系统重构。Git集成规范存在于代码库目录中随代码提交。倾向于为每个Spec创建独立分支。强依赖版本管理。优点极其简洁Token消耗低开发速度快。逻辑极其严密适合新手或严谨的架构。覆盖了极深层的架构决策。缺点缺少一些强制性的验证门槛。过于冗长Verbosity对老手来说略显啰嗦。学习成本和维护成本极高。二、 框架选择指南基于上述对比博客给出了明确的选型建议OpenSpec开发者的“效率工具”适用场景适用于维护成熟的现有项目需要频繁添加小功能或修复Bug。核心优势不强制改变现有Git工作流。其Archive步骤能将零散的变更记录合并进“主规范”使代码库始终拥有一份AI可读的最新“说明书”。Spec Kit架构师的“设计手册”适用场景适用于从零开始搭建复杂系统如微服务架构或团队中有较多需要明确指令的初级开发者。核心优势引入了“宪法Constitution”概念用于规定项目的技术边界。其四阶段网格化管理能有效防止AI偏离既定目标。三、 提升AI编码质量的通用准则无论选择何种框架遵循以下五项“规范驱动”准则能极大提升AI编码质量原则一先达成共识后生成代码实践在AI编写代码文件如.js、.py之前必须先输出任务规划文档如tasks.md或proposal.md。人类必须通过勾选[x]或明确回复“Approved”后才允许AI执行后续的Apply操作。原则二模块化变更实践一个规范变更对应的代码逻辑量建议不超过200行。对于复杂需求应拆分为多个子规范如feat-auth-01、feat-auth-02。这有助于节省AI的Token消耗并防止其在处理长文件时丢失上下文。原则三维护“单一真理源”实践每次完成任务后必须执行Archive归档操作。让AI将本次变更的逻辑同步更新到全局的project.md或specs/目录下的主规范中确保文档与代码同步避免知识过时。原则四在规范中定义“边界条件”实践在提案模板中固定一个名为## Edge Cases的模块。强制要求AI必须列出并考虑各种异常场景如网络中断、输入为空、并发冲突等从而在编码前就思考系统的健壮性。原则五利用任务清单进行断点续传实践当AI编码任务中断如对话结束或开发者下班后续恢复时可直接指示AI“根据tasks.md中未完成的任务继续”。这比重新解释需求更加高效。四、 小结与行动建议博客最后给出了总结性建议若追求开发速度且主要维护现有系统首选 OpenSpec。若正在构建大型新系统且对规范性有极高要求选择 Spec Kit。若仅希望改善现有IDE如Cursor的体验可以尝试在其规则目录.cursor/rules/中建立一套类似OpenSpec的简易流程。参考来源谈谈规范驱动编程 SDD
三款SDD框架对比与实践指南
发布时间：2026/6/1 3:23:05
文章的核心内容是对比了当前AI辅助编程领域中规范驱动开发SDD的三种主流实现框架OpenSpec、Spec Kit和BMAD并基于此提出了提升AI编码质量的通用实践准则。一、 主流SDD框架横向对比博客通过一个结构化的对比表格清晰地展示了三种框架在设计哲学、适用场景和流程上的核心差异。维度OpenSpec (Fission AI)Spec Kit (GitHub)BMAD设计哲学轻量、实用强调对现有代码库的演进。严谨、流程化强调规范是工程的核心。重型、架构先行适合大模型代理协作。技术栈TypeScript / npm (安装简单)Python / CLI (配置稍复杂)理论框架 / 模版核心流程Proposal - Apply - ArchiveSpecify - Plan - Tasks - ImplementAnalyze - Design - Implement适用阶段存量项目Brownfield迭代优于从零开始。新项目Greenfield或复杂功能设计。企业级复杂系统重构。Git集成规范存在于代码库目录中随代码提交。倾向于为每个Spec创建独立分支。强依赖版本管理。优点极其简洁Token消耗低开发速度快。逻辑极其严密适合新手或严谨的架构。覆盖了极深层的架构决策。缺点缺少一些强制性的验证门槛。过于冗长Verbosity对老手来说略显啰嗦。学习成本和维护成本极高。二、 框架选择指南基于上述对比博客给出了明确的选型建议OpenSpec开发者的“效率工具”适用场景适用于维护成熟的现有项目需要频繁添加小功能或修复Bug。核心优势不强制改变现有Git工作流。其Archive步骤能将零散的变更记录合并进“主规范”使代码库始终拥有一份AI可读的最新“说明书”。Spec Kit架构师的“设计手册”适用场景适用于从零开始搭建复杂系统如微服务架构或团队中有较多需要明确指令的初级开发者。核心优势引入了“宪法Constitution”概念用于规定项目的技术边界。其四阶段网格化管理能有效防止AI偏离既定目标。三、 提升AI编码质量的通用准则无论选择何种框架遵循以下五项“规范驱动”准则能极大提升AI编码质量原则一先达成共识后生成代码实践在AI编写代码文件如.js、.py之前必须先输出任务规划文档如tasks.md或proposal.md。人类必须通过勾选[x]或明确回复“Approved”后才允许AI执行后续的Apply操作。原则二模块化变更实践一个规范变更对应的代码逻辑量建议不超过200行。对于复杂需求应拆分为多个子规范如feat-auth-01、feat-auth-02。这有助于节省AI的Token消耗并防止其在处理长文件时丢失上下文。原则三维护“单一真理源”实践每次完成任务后必须执行Archive归档操作。让AI将本次变更的逻辑同步更新到全局的project.md或specs/目录下的主规范中确保文档与代码同步避免知识过时。原则四在规范中定义“边界条件”实践在提案模板中固定一个名为## Edge Cases的模块。强制要求AI必须列出并考虑各种异常场景如网络中断、输入为空、并发冲突等从而在编码前就思考系统的健壮性。原则五利用任务清单进行断点续传实践当AI编码任务中断如对话结束或开发者下班后续恢复时可直接指示AI“根据tasks.md中未完成的任务继续”。这比重新解释需求更加高效。四、 小结与行动建议博客最后给出了总结性建议若追求开发速度且主要维护现有系统首选 OpenSpec。若正在构建大型新系统且对规范性有极高要求选择 Spec Kit。若仅希望改善现有IDE如Cursor的体验可以尝试在其规则目录.cursor/rules/中建立一套类似OpenSpec的简易流程。参考来源谈谈规范驱动编程 SDD
