1. 目的

本文发布了1个工具包openspecx，扩展了openspec工具元范式，将一类需求规则知识沉淀到规则中，更好的使用SDD开发同类需求，通过openspecx，可以大幅度的提升同类需求的开发效率。（开源代码库及安装方式在文末）

本文将从SDD->openspec->openspecx循序介绍SDD。

2 理解SDD

2.1 SDD 不是“颠覆式革命”，而是“演进式升级”

SDD 是软件工程的“针对性升级”，来解决 AI 时代的新痛点。软件工程的本质目标是“用系统化方法解决软件危机（如需求模糊、质量不可控、维护成本高）”。随着 AI 编程工具（如 Copilot、Claude Code）的普及，传统软件工程暴露出新的适配性问题，而 SDD 正是针对这些问题的升级方案：

• 解决“AI 生成代码的可控性缺失”问题：传统软件工程依赖“人工编写+人工审查”确保代码符合规范，但 AI 编程的“快速生成”特性导致自然语言 prompt 模糊，生成代码缺乏规范约束。 SDD 的升级逻辑：将“规范”前置为 AI 生成的“输入标准”
• 解决“规范与实现的同步断层”问题：传统软件工程中，规范文档（如 PRD、设计文档）常因“写完即弃”导致“规范与代码两张皮”，尤其在 AI 快速迭代场景下，代码频繁变更进一步加剧同步难度。 SDD 的升级逻辑：让规范“可执行、可同步”。
• 解决“多角色协作的信息差扩大”问题: AI 时代的开发团队中，产品、开发、QA 与 AI 工具的协作更频繁，但传统规范文档（如 PRD）因“技术门槛高、更新不及时”，导致非技术角色无法参与 AI 生成过程的监督。 SDD 的升级逻辑：让规范成为“跨角色通用契约”

SDD 是软件工程在 AI 时代的“精准升级”, 软件工程的核心框架是“过程、方法、工具”三要素，SDD 完全嵌套在这一框架内，同时针对 AI 辅助开发的痛点做了聚焦优化，具体对应关系如下：

SDD没有脱离软件工程的核心框架，而是强化了“规范”在软件工程三要素（过程、方法、工具）中的核心地位；

• 它针对性解决了 AI 编程带来的“可控性、同步性、协作性”新痛点，让软件工程方法论能适配“AI+人类”协同开发的新场景；
• 它的本质是“用 AI 工具赋能规范管理”，让软件工程从“人工驱动的系统化”升级为“AI 辅助的自动化系统化”，是软件工程发展的必然阶段，而非颠覆式革命

2.2 观点和推论

观点：SDD的方法的思考对象是Agent，其过程是规范→自动化执行→验证→同步，遵循结构化规范+AI 自动化的方法，并且有工具支撑，在开发领域是openspec(spec kit等）+ AI IDE。基于此观点
推论1：如果只满足过程、方法，而没有工具支撑的，是泛SDD。泛SDD和狭义SDD最终产生的效果可能差距很大。
推论2：工具Agent隐含的要求是，底层的大模型需要具备，完整串接SDD过程的提示词链（准确生成spec规格），精准调用工具的能力。能否顺畅使用SDD成为大模型能力的评价标准。
推论3：SDD的思考核心是Agent，在软件开发的各个环节，都运用SDD的规范→自动化执行→验证→同步来思考问题。例如在代码开发这个环节，围绕SDD自动化执行去改进以及增加各种技巧。

• 技巧1（自动调用工具执行）生成SPEC知识不足，则提供方案MCP工具，让大模型主动调用工具获取充足知识，减少人手工干预。
• 技巧2（对抗验证）编写代码和单元测试，让openspec按规则生成任务，进行代码和测试的对抗，生成正确性较高的代码。
• 技巧3（对抗验证）将AI ADE中的编译环境放入spec，让openspec按规则生成任务，进行编译对抗，生成编译通过的前后端代码。

3 openspec是什么

openspec是什么：OpenSpec 是一款专为 AI 编码助手设计的开源免费的规范驱动开发工具，本质为命令行工具，核心作用是让开发者在 AI 编写代码前，与 AI 就需求规范达成明确共识，以此减少返工、让 AI 编程更可控，同时适配多数主流开发场景与 AI 编程工具。
openspec有三层：

• 命令层：操作openspec init，会生成三个标准命令（按执行顺序）：openspec-proposal、openspec-apply、openspec-archive
• 规则层：同步生成agent.md，这是openspec对agent如何工作制定的规格文档；project.md，官方术语consitution(宪法)，本质是一类特殊的规则，全局规则，所有的通过命令执行的AI生成都必须遵守这个文件的规则。
• 驱动层：也就是命令执行的时候，工作流的驱动过程，例如openspec-proposal（生成spec，包括proposal.md、task.md，并通过openspec validate自动校验），openspec-apply(自动执行task.md)、openspec-archive(归档+同步)

工具和知识角度看openspec

• 工具角度：openspec对于不同的工具（对于cursor等各种AI IDE）的命令层和规则层，都做了适配，可参见openspec init的选择工具过程。驱动层是openspec的核心，不管对于什么工具，永远不变。
• 知识角度：知识是openspec的产物，对于命令和规则md文件，在代码库中会不断累积沉淀，属于固定量；对于驱动层产生的md(openspec/change下的md)，是随某个具体的需求开发创删改，是变化量。

4 openspecx是什么

openspec的问题：

• 对于需求的开发，特别是同类需求，其spec最终都归档在opensec/archive中，这些spec都与具体的需求甚至代码相关，是作为变化量处理。而我认为同类需求的spec，应该抽取公共要素，沉淀为规则。
• 如果要这样做，就需要手工编写命令以及规则，并且去编写并调试prompt链的串接，额外增加了知识负担。

为了解决这样的问题，我在openspec的基础上，严格遵守openspec的风格以及使用习惯，完成了openspecx。

openspecx是什么：openspecx在openspec扩展了工具元范式，是与openspec一脉相承的工具。如图绿色部分，通过openspec自动生成范式命令和规则，从使用方式上和openspec保持完全一致。

openspecx

操作过程：openspecx是要和openspec配套使用的，其中技巧见2.2章节
步骤1（openspec原生支持）：使用openspec init创建命令(.cursor/commands目录，openspec-proposal.md、openspec-apply.md、openspec-archive.md) + openspec目录宪法(project.md) -> 使用openspec示意提示词大模型执行补充project.md(openspec目录)规则 -> 人工评审补全
步骤2（openspecx扩展）：使用openspecx init {模块目录} {规则名} 创建命令 openspec-{规则名}-proposal.md + 模块目录/{规则名}-RULE.md -> 使用openspecx示意提示词大模型执行执行分析模块代码，根据命令意图补全模块目录/{规则名}-RULE.md -> 人工评审并补全增加该功能关联模块的修改点
步骤3： 执行命令 openspec-{规则名}-proposal.md，openspec-apply.md 实现第1个范式需求 -> 反复迭代并调整 模块目录/{规则名}-RULE.md（动作包括模块规则、关系模块的修改规则）
步骤4：执行命令 openspec-{规则名}-proposal.md，openspec-apply.md 实现同类需求

openspecx命令

Usage: openspecx [options] [command]

OpenSpec Extensions - Module Rules Management

Options:
  -V, --version                           output the version number
  --no-color                              Disable color output
  -h, --help                              display help for command

Commands:
  init [options] <modulePath> <ruleName>  Initialize a new module rule
  validate [options] <ruleFile>           Validate a RULE.md file
  help [command]                          display help for command

5. openspecx安装说明

注意：首先参照openspec官网安装openspec，然后安装openspecx
代码库地址：https://github.com/GoodMood2008/openspecx
安装：npm install -g @goodmood2008/openspecx@latest
说明：codebasex目前只支持cursor