基于SSD的OpenSpec工作流

2026年02月15日

理解设计思想，真正发挥SSD的威力。

一全局文件结构
二简单需求的开发流程
三复杂需求的开发流程
四并行开发的流程
五扩展工作流
六命令详细解析
七注入规范
八 Superpower与OpenSpec混用
九需求颗粒度的定义
十定制schema
- 仅仅UI的修改

一全局文件结构

openspec/specs，主spec，是系统如何工作的真相源，描述系统的行为，首次配置的时候它是空的，即使是迭代了很多年的一个项目。

openspec/changes，每次修改的文件夹，包含artifacts和deltas。
当archive归档一个change的时候，deltas会迁移到主spec。所以，在这个change影响面经过充分的review之后，再迁移到主spec（毕竟其作为真理唯一源，会影响后续的判断）。

二简单需求的开发流程

2025年的流程命令
/opsx:propose <description>
一次性生成所有产物：

proposal（为什么做）
design（技术方案）
spec（系统行为变化）
task（实施计划）

如果用/opsx:new, continue，其生成顺序如上，即：proposal->design->spec->tasks

然后执行：
/opsx:apply
/opsx:archive <description>

2026年v1.0版本之后新增加的流程命令
/opsx:new→/opsx:ff→/opsx:apply→/opsx:verify→/opsx:archive
其可以依次生成产物，避免一次性生成过多产物（proposal, design, spec, tasks）

三复杂需求的开发流程

不太明确的技术方案、架构设计、问题调试、优化瓶颈。通过先探索，再逐步确认。
/opsx:explore→/opsx:new→/opsx:continue→…→/opsx:apply

continue的过程，可以看到执行的过程：
spec-driven Progress: 1/4 Artifacts complete

4个Artifact分别是proposal，spec，design，tasks。

第一个要完成的是proposal，spec和design都是”ready to create”阶段。他们是可以并行进行的。
最后tasks是blocked by : design, spec，即task需要前3个proposal，spec，design都完成。

以上这些可以是默认的流程，可以根据自己的业务需求，定制Schemas，设置其顺序与依赖。

四并行开发的流程

开发A需求的时候，突然有一个紧急需要修复的bug，此时我们可以通过/opsx:new BFeature，切换到B需求，/opsx:ff创建spec, proposal, design, task之后，使用/opsx:apply BBug来指定完成B的开发。/opsx:archive BBug之后，再回到A，执行/opsx:apply AFeature

Change AFeature: /opsx:new → /opsx:ff → /opsx:apply（进行中）
↓ 上下文切换
Change BBug: /opsx:new → /opsx:ff → /opsx:apply

五扩展工作流

安装OpenSpec之后，默认是没有new, ff, continue这些高级命令的，如果使用需要拓展工作流。

拓展工作流
openspec config profile

可以自定义种类

Propose change
Explore ideas
New change
Continue change
Apply tasks
Fast-forward
Sync specs
Archive change
Bulk archive
Verify change
Onboard

在一个项目中配置之后，在其他项目中通过命令可以更新这些命令
openspec update

六命令详细解析

proposal

/opsx:propose

一步创建变更 + 生成全部规划产物

1	/opsx:propose [change-name-or-description]

这里输入问题描述、需要修改的内容。但是生成change文件夹的名字，是AI生成的。
如果想要自己指定change文件夹的名字，先输入名字，接着再补充详细问题的细节。

Change name must be lowercase (use kebab-case)
注意变更名是纯小写，用“-”分隔单词。当然如果用驼峰，AI也会自动纠正名字

opsx:new

1	/opsx:new <change-name>

1	openspec new change <change-name>

创建变更脚手架，仅初始化变更目录结构，不创建任何文档；适合配合 /opsx:continue 逐步手动生成文档时使用。按照依赖图DAG，一次只生成一个文档，以便于每一步都进行review。
也可以用 /opsx:ff 一次性生成。

/opsx:new之后，生成了文件夹名字，接着输入具体的问题描述，AI会生成”artifactId”: “proposal”。AI Coding过程详细信息如下：

h(openspec instructions proposal --change "add-new-ui-type-mx" --json)
  ⎿  {
       "changeName": "add-new-ui-type-mx",
       "artifactId": "proposal",
       "schemaName": "spec-driven",
       "changeDir": "/Users/kkk/Desktop/code/project/CLFinanze/openspec/changes/add-new-ui-type-mx",
       "outputPath": "proposal.md",
       "description": "Initial proposal document outlining the change",
       "instruction": "Create the proposal document that establishes WHY this
     change is needed.\n\nSections:\n- Why: 1-2 sentences on the problem or
     opportunity. What problem does this solve? Why now?\n- What Changes:
     Bullet list of changes. Be specific about new capabilities, modifications, or
      removals. ..tasks all build on this.\n",

       "dependencies": [],
       "unlocks": [
         "design",
     "specs"
       ]
     }

完成之后提示如下：
Run /opsx:continue to create the next artifact.
即通过continue可以继续生成下一个artifact（design）

opsx:sync

/opsx:sync作用是合并增量规范到主分支。即将正在开发中openspec/changes/临时工作上下文，合并到/openspec/spec全局主规范中。这样spec就成为了全局规范，描述当前系统真实、稳定的架构现状，供后续项目参考。

七注入规范

v1.0.0版本起，项目增加了openspec/config.yaml文件，这里包含了项目背景，技术栈，约束条件的配置，以及每类文档的规则注入。
可以注入到每次AI规划请求中。

八 Superpower与OpenSpec混用

openspec注重交付的规范，superpower注重过程、行为标准的一致性。在执行具体计划的时候，superpower更详细，因此可以混合使用。
在openspec的proposal, design, spec都完成之后，可以使用writing-plans生成task

不过这适合比较复杂的需求，如果是简单的需求，AI会提示如下，意思是杀鸡焉用牛刀。

For a change this small, a separate implementation plan would be redundant. The
  OpenSpec workflow already captured:
  - proposal.md - Why we're doing this
  - design.md - Technical decisions (naming, position)
  - specs/ - Requirements
  - tasks.md - Implementation steps

  Would you like me to:

  1. Execute directly - Implement the enum change now (use /opsx:apply)
  2. Create a formal plan anyway - Write a full docs/superpowers/plans/ plan document
  (overkill for this change)

如果选2，确定要这样做，则会在/docs/superpowers/plans生成详细的计划

如果用/opsx:ff快速生成所有文档（包括tasks.md)，这个时候直接用 /executing-plans 可以替代/apply

九需求颗粒度的定义

一个change 应该保持最小可交付单元。一方面这样也保持了敏捷迭代的思想，另一方面也是LLM上下文有限。
如果一个特别大的需求，比如按照常规排期需要1个月，那如何拆分呢？可以使用brainstorm产出功能清单，以及粗略的优先级，这样可以每个功能都保持较小颗粒度。

十定制schema

仅仅UI的修改

如果通过proposal创建了spec，proposal，design，task。那对于改一个UI，或一个埋点显得过重。所以可以通过定制schema来修改适合自己的工作流。

基于SSD的OpenSpec工作流

一 全局文件结构

二 简单需求的开发流程

三 复杂需求的开发流程

四 并行开发的流程

五 扩展工作流

六 命令详细解析