前言
SDD是近期备受关注的一个概念。随着AI极大提升了代码生成的速度，一度流行的“vibe coding”逐渐暴露出问题：开发者用“帮我加个分享功能”这类模糊提示词让AI写代码，结果往往充满不确定性，返工成本居高不下。AI虽然难以猜透人的真实意图，却能精准执行明确的规范。而LLM与Coding Agent的发展，恰好为SDD从学术概念走向工程实践提供了有力支撑。如今，SDD已成为AI编程领域绕不开的话题。
目前在编程领域，有非常多优秀的工具在支撑SDD的工作流程，比如Spec Kit、OpenSpec、Kiro等等。其中OpenSpec以其开源、基于变更、轻量、通用等诸多优势，成为众多开发者喜爱的SDD实践工具。本文将深入拆解OpenSpec的各项功能特性，帮助大家理解：当我们使用OpenSpec进行SDD进行实践时，我们每一步在做什么，以及为什么要这么做。
本文默认读者已经具备SDD的基本概念和知识，不对这部分概念展开讨论。
OpenSpec功能详解
OpenSpec的安装可以参考官网。
本文的所有指令和功能基于目前最新版本的OpenSpec（1.3.0）
OpenSpec包含两类指令功能，第一类是cli命令，第二类是开发过程的Agent指令。
Cli命令
日常开发（高频）
| 命令 | 场景 | |——|——| | init | 新项目首次接入 OpenSpec | | update | 升级 CLI 包后，刷新 AI 工具配置 | | list | 查看当前有哪些活跃变更或规格 | | show | 查看某个变更或规格的详细内容 | | status | 查看变更的 artifact 完成进度 | | archive | 终端中直接归档已完成的变更 | | validate | 检查变更或规格的结构是否合规 |
工作流调试（中频）
| 命令 | 场景 | |——|——| | instructions | 调试 agent 行为，查看某个 artifact 的生成指令 | | templates | 确认 schema 模板文件的实际路径 | | schemas | 列出所有可用 schema 及其来源 | | view | 交互式仪表盘，总览项目状态 |
自定义 Schema（低频）
| 命令 | 场景 | |——|——| | schema init | 从零创建自定义工作流 | | schema fork | 基于内置 schema 定制自己的版本 | | schema validate | 验证自定义 schema 结构是否正确 | | schema which | 排查 schema 解析优先级问题 |
配置管理（低频）
| 命令 | 场景 | |——|——| | config profile | 切换 core/expanded 工作流模式 | | config list | 查看当前所有配置项 | | config get/set | 读取或修改单个配置值 | | config edit | 用编辑器直接编辑配置文件 | | config path | 找到配置文件位置 | | config unset | 删除某个自定义配置项 | | config reset | 恢复默认配置 |
一次性的
| 命令 | 场景 | |——|——| | completion | 安装 shell 自动补全 | | feedback | 提交反馈，自动创建 GitHub issue |
第二类是开发过程使用的Agent指令：
| 命令 | 用途 | |——|——| | /opsx:propose | 一步创建变更并生成所有规划制品 | | /opsx:explore | 探索想法、调研问题，不创建制品 | | /opsx:apply | 执行 tasks.md 中的实现任务 | | /opsx:archive | 归档已完成的变更，合并 delta specs | | /opsx:new | 仅创建变更脚手架，等待后续指令 | | /opsx:continue | 按依赖顺序逐个创建 artifact | | /opsx:ff | 一次性创建所有规划制品 | | /opsx:verify | 校验实现与规格的一致性 | | /opsx:sync | 将 delta specs 合并到主规格 | | /opsx:bulk-archive | 批量归档多个变更，自动处理冲突 | | /opsx:onboard | 引导式教程，用真实代码走一遍完整流程 |
还有三个已废弃的指令不做讨论：/openspec:proposal、/openspec:apply、/openspec:archive
基础功能
快速流程
官方提供的快速流程只有三步：
/opsx:propose ──► /opsx:apply ──► /opsx:archive
这个流程非常适合一个修改方案很明确的小变更，比如：修改锁接口的实现类，从内存锁改为分布式锁，这类变更技术方案完全是确定的，只是将一个接口的实现类实用另一种方案重新实现一次，并替换实现类而已，无需过多的思考和探索。
扩展流程
扩展流程是官方提供的一个更详细的流程，它的本质是把/opsx:propose的环节，拆分为变更创建 -> 制品编写的过程，其中制品编写一般分四个制品：提案，规范，设计，任务。
官方给出的标准扩展流程为：
/opsx:new ──► /opsx:ff or /opsx:continue ──► /opsx:apply ──► /opsx:verify ──► /opsx:archive
说明：这里
/opsx:ff含义是Fast Forward（快进），表示的是一次性完成所有制品，相当于/opsx:continue * 4实际上快速流程里的
/opsx:propose想当于/opsx:new ──► /opsx:ff，所谓的快速流程本质上只是通过一个指令同时完成多个步骤而已。
概念理解
了解OpenSpec的基本流程之后，现在我们来真正深入的了解，它每一步到底在做什么，为什么要这么做。
首先我们知道，OpenSpec的核心是变更（change），也就是每一次新的变更都是一个小的SDD过程，因此会包含SDD的所有环节。
在前面的两个标准流程中，其实可以分为三个环节：
- 文档编写（从
/opsx:new到/opsx:apply之前） - 技术实现：
/opsx:apply - 收尾工作：
/opsx:verify到/opsx:archive
这里并不是按照SDD流程来划分的环节的，而是将所有的文档编写统一到一个环节，如果按照SDD流程拆分应该是如下：
- 需求沟通：
/opsx:new - prd文档：
/opsx:continue* 2 - 制定计划：
/opsx:continue* 2 - 技术实现：
/opsx:apply - 收尾工作：
/opsx:verify到/opsx:archive（扩展步骤）
在OpenSpec中，虽然遵循SDD的开发流程，但是也通过/opsx:propose和/opsx:ff的方式来简化流程，提高需求落地的效率，这些相对好理解，但是最后的收尾工作环节，是为了什么？
/opsx:verify的作用是检查本次变更的所有工作是否按照规范完成，所有任务是否完成，并不是必选的，只有较大的复杂变更，才有必要在技术实现完成后进行一次验证，所以OpenSpec并没有将这个环节放在技术实现阶段。
我们重点看归档指令：/opsx:archive
- openspec/config.yaml优化配置
高级功能
- 自定义shema
- 配置验证
- 配置实现自动归档
最佳实践
- 扩展加入自己的编码规范
- 制品完成后应该new一个对话来apply
未来发展
- 集成superpower
- 并行变更自动合并
- 变更依赖图