OpenSpec 实现 SDD 开发：从入门到精通

前言：一个让所有程序员都头疼的场景

你有没有遇到过这样的情况？

你兴致勃勃地对 AI 助手说：“帮我加个用户登录功能。”AI 刷刷刷写了一大堆代码，你一看——它用了 Redis 缓存，但你的项目根本没有 Redis；它用了 MongoDB，但你的数据库是 MySQL。

你反复沟通、反复修改，三轮之后代码已经完全失控，最后只能自己重写。

这不是 AI 不够聪明，而是我们与 AI 的协作方式出了问题——需求只存在聊天记录里，上下文随时丢失，AI 在“自由发挥”。

OpenSpec 就是专门解决这个问题的工具。

---

第一章：初识 OpenSpec

1.1 什么是规范驱动开发（SDD）？

先来看一个生活中的例子：

传统开发就像“你说我画” ——你告诉画家“画一只猫”，画家凭想象画了一只橘猫，但你要的是黑猫。反复修改，费时费力。

规范驱动开发就像“先画草图再上色” ——你先和画家一起画好草图（规范），确认“这就是我们要的猫”，然后再上色（编码）。一次搞定。

传统开发流程是：需求 → 直接编码 → 测试 → 交付。

规范驱动开发（SDD）的流程是：需求 → 编写规范 → 验证规范 → 编码实现。

SDD 和传统文档的核心区别在于：传统文档写给人看的，而 SDD 规范写给 AI 看的。规范的结构化程度足够高，让 AI 模型能够在生成代码时引用它、对照它检查输出、在会话中断后借此恢复上下文。

1.2 什么是 OpenSpec？

OpenSpec 是由 Fission-AI 开源的规范驱动开发（Spec-Driven Development, SDD）框架，专为 AI 编程助手设计。它通过在编写代码之前先定义规范，确保人与 AI 对需求达成一致。

核心理念：先想清楚要做什么（Spec），再让 AI 去实现（Code）。

截至 2026 年初，OpenSpec 在 AI 编程社区迅速走红，已成为该领域最受关注的规范驱动开发工具之一。它支持 20+ 种 AI 编程助手，包括 Claude Code、Cursor、Copilot、Cline 等。

1.3 OpenSpec 的核心哲学

OpenSpec 的设计哲学可以用五句话概括：

哲学	含义
Fluid not rigid（流动而非僵化）	文档可以随时更新，没有严格的阶段门槛
Iterative not waterfall（迭代而非瀑布）	支持增量添加需求，逐步完善
Easy not complex（简单而非复杂）	只需要 Markdown 文件，无复杂工具链
Built for brownfield（兼顾存量项目）	既适用于已有代码库，也适用于全新项目
Scalable（可扩展）	从个人项目到企业级都可以使用

术语解释：

• Brownfield（存量项目）：指已经存在的、有历史代码的项目。OpenSpec 可以逐步引入，不必重构现有代码。
• Greenfield（新建项目）：指从零开始的新项目。OpenSpec 可以从一开始就建立规范体系。

1.4 OpenSpec vs 传统开发

对比维度	传统开发	OpenSpec + SDD
需求传递	聊天记录、口头沟通	结构化的 Markdown 规范文件
AI 行为	自由发挥，容易跑偏	按规范执行，可追溯可验证
变更追溯	难以追踪“为什么这么写”	每个变更独立文件夹，完整上下文
返工成本	高（代码写完才发现问题）	低（规范阶段发现问题，改几行 Markdown 即可）
团队协作	信息不透明，规范漂移	单一事实来源（Single Source of Truth）

---

第二章：安装与初始化

2.1 环境准备

OpenSpec 需要 Node.js 20.19.0 或更高版本。

# 检查 Node.js 版本
node --version

如果版本过低，建议使用 nvm 或 fnm 管理 Node.js 版本。

2.2 安装 OpenSpec CLI

使用 npm 全局安装：

npm install -g @fission-ai/openspec@latest

也可以使用其他包管理器：

# pnpm（推荐，速度更快）
pnpm add -g @fission-ai/openspec@latest

# yarn
yarn global add @fission-ai/openspec@latest

# bun
bun install -g @fission-ai/openspec@latest

2.3 验证安装

# 查看版本号
openspec --version

# 查看帮助信息
openspec --help

安装成功后，你将看到类似 1.5.0 的版本号输出。

2.4 初始化项目

进入你的项目目录，执行初始化命令：

cd your-project
openspec init

初始化过程会：

• 询问你使用的 AI 工具（Claude Code、Cursor、Copilot 等）
• 自动配置相应的斜杠命令
• 创建 openspec/ 目录结构
• 生成 AGENTS.md 文件（AI 助手规则）

初始化完成后，项目会生成以下目录结构：

your-project/
├── openspec/
│   ├── specs/          # 当前真理源规范（已完成的规范）
│   └── changes/        # 变更提案（进行中的变更）
├── AGENTS.md           # AI 助手规则
└── config.yaml         # 可选配置

验证设置：

openspec list

如果你使用的 AI 助手没有立即显示新的斜杠命令，请重启它。

---

第三章：核心概念详解

在开始使用 OpenSpec 之前，必须先搞懂四个核心概念。

3.1 变更（Change）

生活类比：就像一次“装修工程”——你要给家里装一个新书架，这就是一个“变更”。从设计到施工到验收，整个过程都在一个文件夹里管理。

技术定义：一次独立的开发任务，放在 openspec/changes/ 目录下。一次需求一个文件夹。

openspec/changes/add-user-login/   # 这是一个"变更"

3.2 工件（Artifact）

生活类比：装修工程中的“设计图”、“材料清单”、“施工进度表”——这些都是工件。

技术定义：变更全流程的产出物，包括四个核心文件：

工件	文件名	回答的问题
提案（Proposal）	proposal.md	为什么要做？（业务背景、价值）
规范（Specs）	specs/	做什么？（API 定义、数据模型、验收场景）
设计（Design）	design.md	怎么做？（架构决策、技术选型）
任务（Tasks）	tasks.md	做哪些？（任务分解、依赖关系）

3.3 规范（Specs）

生活类比：装修的“最终效果图”——它描述了“书架应该长什么样、多大尺寸、什么颜色”。

技术定义：项目全局或模块的通用设计约定，存放在 openspec/specs/ 中，可被多个变更共享。

3.4 同步与归档（Sync & Archive）

生活类比：装修完成后，把“最终设计图”存入家庭档案，以后装修其他房间可以参考。

技术定义：变更做完后，规范合并进主库（openspec/specs/），整个变更文件夹归档封存。

---

第四章：OPSX 工作流——从入门到实战

OpenSpec 最核心的是 OPSX 工作流。OPSX 的核心主张是 “Actions, Not Phases”（动作，而非阶段）。

通俗理解：传统开发像“坐地铁”——必须一站一站走，错过了就得绕回来。OPSX 像“开车”——你可以随时掉头、随时转弯，想怎么走就怎么走。

4.1 两种运行模式

OpenSpec 分为两种模式：

1. 默认快速模式（Core Profile）

适合简单开发场景，提供 4 个核心命令：

• /opsx:explore — 梳理思路
• /opsx:propose — 创建变更 + 规划工件
• /opsx:apply — 实现任务
• /opsx:archive — 完成变更归档

2. 扩展全量模式（Extended Profile）

适合复杂开发、团队协作场景。开启方式：

openspec config profile
openspec update

新增命令包括：/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive 等。

4.2 三种工作流模式

扩展模式下，OpenSpec 提供了三种高频工作流模式：

模式	适用场景	命令链路
Quick Feature（快速功能）	需求明确的小功能、Bug 修复	/opsx:new → /opsx:ff → /opsx:apply → /opsx:verify → /opsx:archive
Explore First（先探索）	需求模糊、需要先理清思路	/opsx:explore → /opsx:propose → /opsx:apply → /opsx:archive
Full Spec（完整规范）	大型功能、团队协作	/opsx:propose → 审阅 → /opsx:apply → /opsx:verify → /opsx:archive

4.3 完整实战：从 Propose 到 Archive

下面通过一个 Spring Boot 用户登录功能 的实战案例，展示完整流程。

第一步：Propose（提出变更）

在 AI 工具中输入：

/opsx:propose "为 Spring Boot 项目添加用户登录功能，支持 JWT 认证"

AI 会读取现有的 openspec/specs/（了解当前系统），然后生成一个新文件夹：

openspec/changes/add-user-login/
├── proposal.md
├── specs/
│   └── user-auth/
│       └── spec.md
├── design.md
└── tasks.md

proposal.md 示例（回答“为什么”）：

# Proposal: 添加用户登录功能

## Why（为什么要做）
当前系统缺乏身份认证机制，所有 API 均公开可访问。
需要增加用户登录功能，保护敏感接口。

## What Changes（会有什么变化）
- ADDED: 用户登录 API `/api/auth/login`
- ADDED: JWT Token 生成与验证
- ADDED: 登录拦截器 `JwtInterceptor`
- ADDED: 用户实体 `User` 和 `UserRepository`

## What Not Changing（什么不变）
- 现有业务 API 逻辑不变
- 数据库表结构仅新增 `user` 表

## Risks（风险）
- JWT 密钥需要妥善管理 → 使用环境变量配置
- Token 过期策略需要明确 → 设置 7 天有效期

spec.md 示例（回答“做什么”，用 GIVEN/WHEN/THEN 格式）：

# Specification: 用户认证

## ADDED Requirements

### Requirement: 用户登录
系统应接受用户名和密码，验证通过后返回 JWT Token。

#### Scenario: 登录成功
- **GIVEN** 数据库中存在用户 "admin"，密码为 "123456"
- **WHEN** 用户调用 `/api/auth/login` 并传入正确的用户名和密码
- **THEN** 系统返回 HTTP 200 和包含 JWT Token 的响应体

#### Scenario: 密码错误
- **GIVEN** 数据库中存在用户 "admin"，密码为 "123456"
- **WHEN** 用户调用 `/api/auth/login` 并传入正确的用户名但错误的密码
- **THEN** 系统返回 HTTP 401 和错误信息 "用户名或密码错误"

#### Scenario: 用户不存在
- **WHEN** 用户调用 `/api/auth/login` 并传入不存在的用户名
- **THEN** 系统返回 HTTP 401 和错误信息 "用户名或密码错误"

关键提示：ADDED/MODIFIED/REMOVED 这几个增量标记非常有用——它们迫使你明确说清楚“现在存在什么”和“之后会存在什么”，能在很多“哦等等，那个模块已经这么做了”的时刻变成技术债之前把它们揪出来。

design.md 示例（回答“怎么做”）：

# Design: 用户登录功能

## Context（背景）
Spring Boot 3.x 项目，使用 Spring Security 作为安全框架。

## Goals（目标）
- 实现基于 JWT 的无状态认证
- 密码使用 BCrypt 加密存储
- 登录接口响应时间 < 200ms

## Non-Goals（非目标）
- 不实现 OAuth2 第三方登录
- 不实现 refresh token

## Decisions（决策）
- 使用 `jjwt` 库生成和验证 JWT（0.12.x 版本）
- 使用 `BCryptPasswordEncoder` 加密密码
- Token 存储在 HTTP Header `Authorization: Bearer <token>`

## Risks / Trade-offs（风险与权衡）
- [风险] JWT 无法主动失效 → 设置较短有效期（7天）+ 提供登出接口（客户端丢弃 Token）
- [风险] 密钥泄露 → 使用环境变量 `JWT_SECRET`，定期轮换

tasks.md 示例（回答“做哪些”）：

# Tasks: 用户登录功能

## 1. 数据库与实体层
- [ ] 1.1 创建 `User` 实体类（id, username, password, createdAt）
- [ ] 1.2 创建 `UserRepository` 接口（继承 JpaRepository）
- [ ] 1.3 编写数据库迁移脚本（创建 user 表）

## 2. 安全配置
- [ ] 2.1 配置 `SecurityConfig`，关闭 CSRF，设置无状态会话
- [ ] 2.2 配置 `BCryptPasswordEncoder` Bean
- [ ] 2.3 配置 `JwtAuthenticationFilter` 拦截器

## 3. JWT 工具类
- [ ] 3.1 实现 `JwtUtil` 工具类（生成 Token、解析 Token、验证 Token）
- [ ] 3.2 实现 `JwtAuthenticationToken` 认证对象

## 4. 登录接口
- [ ] 4.1 实现 `AuthController` 中的 `/api/auth/login` 接口
- [ ] 4.2 实现 `AuthService` 中的 `login()` 业务逻辑
- [ ] 4.3 实现全局异常处理（用户名不存在、密码错误）

## 5. 测试
- [ ] 5.1 编写单元测试：`JwtUtilTest`
- [ ] 5.2 编写集成测试：`AuthControllerTest`（覆盖成功/失败场景）

第二步：审阅（Review）

生成完成后，人工审阅所有文件：

• 需求是否完整、准确？
• 设计决策是否合理？
• 边界情况是否覆盖？

关键原则：在写下任何一行实现代码之前完成审阅。提议有问题，就在这里纠正，不能等到实现之后再回来纠正。在这个阶段修改成本最低——改几行 Markdown 比改代码快得多。

第三步：Apply（执行变更）

审阅通过后，执行：

/opsx:apply

AI 会逐一处理 tasks.md 里的任务，每一步都读取规范文件，而不是凭记忆。

这是 OpenSpec 和无结构 AI 编码的关键区别：每个任务足够小，可以独立测试；哪个任务失败了，能准确看到违反了哪条规范场景。

AI 执行任务时，会生成实际的 Java 代码，例如：

// 根据 tasks.md 的 3.1 任务，AI 生成 JwtUtil.java
@Component
public class JwtUtil {
    
    @Value("${jwt.secret}")
    private String secret;
    
    @Value("${jwt.expiration}")
    private Long expiration;
    
    public String generateToken(String username) {
        return Jwts.builder()
            .setSubject(username)
            .setIssuedAt(new Date())
            .setExpiration(new Date(System.currentTimeMillis() + expiration))
            .signWith(getSignKey(), SignatureAlgorithm.HS256)
            .compact();
    }
    
    public String extractUsername(String token) {
        return Jwts.parser()
            .verifyWith(getSignKey())
            .build()
            .parseSignedClaims(token)
            .getPayload()
            .getSubject();
    }
    
    private SecretKey getSignKey() {
        return Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8));
    }
}

第四步：Verify（验证）

Apply 完成后，执行：

/opsx:verify

这一步对照规范检查实现——不只是跑测试，而是验证代码的行为是否符合 GIVEN/WHEN/THEN 场景。

实战经验：在大约三十个功能上跑过 verify，大约三分之一会发现问题——总是一些小地方：一个缺失的错误状态，tasks 里没覆盖到的边界情况。能在合并之前把这些揪出来，是 OpenSpec 真正的价值所在。

第五步：Archive（归档）

验证通过后，执行：

/opsx:archive

变更文件夹移动到 openspec/changes/archive/，增量规范合并进主 openspec/specs/。

openspec/changes/archive/2026-08-15-add-user-login/   # 归档
openspec/specs/user-auth/spec.md                       # 规范已更新

4.4 一张图看懂完整工作流

┌─────────────────────────────────────────────────────────────────┐
│                    OpenSpec 完整工作流                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  /opsx:propose  ──→  审阅规范  ──→  /opsx:apply  ──→  /opsx:verify  ──→  /opsx:archive
│       │                  │              │               │                │
│       ▼                  ▼              ▼               ▼                ▼
│  生成4个工件        人工确认      AI逐任务实现    对照规范检查    归档+合并规范
│  (proposal/        方向和范围     (每个任务        (GIVEN/WHEN/     (变更进入
│   specs/           是否正确      独立可测)         THEN场景)       历史档案)
│   design/
│   tasks/)
│
└─────────────────────────────────────────────────────────────────┘

---

第五章：在存量项目中引入 OpenSpec

5.1 核心理念：只为你即将修改的部分写规范

在已有项目中采用 OpenSpec，最重要的原则是：只为你即将修改的部分写规范。

不需要为整个项目写规范——OpenSpec 是 “棕地优先”（brownfield-first） 设计的，可以逐步引入。

5.2 三步引入法

Step 1：初始化

cd your-existing-project
openspec init

Step 2：从一个小变更开始

选择一个小的、明确的功能或 Bug 修复作为第一个变更：

/opsx:propose "修复用户资料更新接口的校验逻辑"

Step 3：逐步扩大范围

随着你和团队对 OpenSpec 工作流越来越熟悉，逐步扩大规范覆盖的范围。

关键建议：早期的变更尽量小。先跑通流程，再扩大规模。

5.3 存量项目 vs 新建项目的策略差异

	存量项目（Brownfield）	新建项目（Greenfield）
规范覆盖范围	仅覆盖正在修改的部分	可以从头建立完整规范体系
引入方式	逐步引入，从一个小功能开始	项目初始化时直接启用
规范编写	使用 Delta（增量） 方式	从头编写完整规范
风险	低（不影响现有代码）	低（从零开始，无历史包袱）

---

第六章：高阶技巧与最佳实践

6.1 规范编写技巧

技巧 1：场景覆盖要全面

每个需求至少包含三个场景：

• 正常路径（Happy Path）：一切正常时
• 异常路径（Sad Path）：出错时
• 边界情况（Edge Case）：极端输入时

#### Scenario: 正常登录（Happy Path）
- **GIVEN** 正确的用户名和密码
- **WHEN** 调用登录接口
- **THEN** 返回 JWT Token

#### Scenario: 密码错误（Sad Path）
- **GIVEN** 正确的用户名但错误的密码
- **WHEN** 调用登录接口
- **THEN** 返回 401 错误

#### Scenario: 用户名超长（Edge Case）
- **GIVEN** 用户名为 256 个字符
- **WHEN** 调用登录接口
- **THEN** 返回 400 错误 "用户名长度不能超过 50"

技巧 2：增量标记使用规范

修改规范时，使用正确的增量标记：

标记	含义	使用场景
ADDED	新增需求	添加全新功能
MODIFIED	修改需求	调整现有功能的行为
REMOVED	删除需求	移除废弃功能
RENAMED	重命名	仅改变名称

操作顺序是：RENAMED → REMOVED → MODIFIED → ADDED。

6.2 上下文管理技巧

技巧 1：保持上下文窗口清洁

OpenSpec 受益于干净的上下文窗口。在开始实现之前清理上下文，并在整个会话中保持良好的上下文卫生。

技巧 2：使用 planning-with-files 模式

对于复杂变更，可以使用 planning-with-files 模式来持久化 AI 代理的上下文：

openspec/changes/{change-id}/
├── task_plan.md      # 阶段进度、目标、任务清单
├── findings.md       # 技术发现、架构决策记录（ADR）
├── progress.md       # 会话进度日志
└── delta-log.md      # Delta 规范变更记录

这样 AI 代理始终能回答：

• 我在哪？ → 读 task_plan.md
• 我做了什么？ → 读 progress.md
• 我为什么做这个决定？ → 读 findings.md
• 下一步做什么？ → Schema 驱动流程

6.3 与 AI 工具的协作技巧

技巧 1：明确指定技术栈

在 proposal 中明确说明技术栈，避免 AI 选错：

project:
  name: user-service
  language: Java
  framework: Spring Boot 3.x
  rules:
    - 禁止直接操作数据库，必须通过 Repository
    - Controller 只做参数校验和转发
    - 所有接口必须返回统一 Result<T>

技巧 2：使用高推理能力的模型

OpenSpec 在高推理能力的模型上效果最好。推荐使用 Codex 5.5 和 Opus 4.7 进行规划和实现。

技巧 3：善用 /opsx:explore

当需求不明确时，先用 /opsx:explore 探索：

/opsx:explore "我想做一个用户积分系统，但不确定怎么设计更合理"

AI 会帮助你理清思路，然后再用 /opsx:propose 正式提案。

6.4 团队协作最佳实践

技巧 1：使用 Stores 进行跨仓库规划

当一个功能涉及多个代码仓库时，使用 OpenSpec Stores——在独立仓库中规划，通过 git push 共享。

技巧 2：规范审查代替代码审查

结构化的文档使得代码审查转变为 “规范审查”（Spec Review） ——团队成员可以更早、更有效地介入。

技巧 3：规范即文档

规范本身可以作为项目文档。团队成员可以直接阅读 openspec/specs/ 了解系统功能，新人 onboarding 效率大幅提升。

6.5 性能与规模考虑

• 50KB 上下文限制：OpenSpec 对每份规范有硬性的 50KB 上下文限制，这促使你将规范写得精炼、聚焦。
• 变更独立：每个变更独立文件夹，避免规范文件过大。
• 按需归档：完成的变更及时归档，保持 changes/ 目录清爽。

---

第七章：常见问题与避坑指南

7.1 常见问题

Q1：我在终端输入 /opsx:propose 没反应？

最可能的原因是在终端而不是 AI 聊天中输入的，或者命令还没安装。在项目里运行 openspec update，重启助手，然后在聊天中输入 /opsx，留意自动补全。

Q2：OpenSpec 和 Spec-Kit 有什么区别？

	OpenSpec	Spec-Kit
定位	轻量级、AI 原生	GitHub 官方出品
适用场景	小项目、现有项目迭代	企业合规场景
核心机制	Delta Spec 增量变更	Constitution 模型强制执行规则
学习成本	低	较高

Q3：OpenSpec 适合多大的项目？

从个人项目到企业级都可以。但如果是超大型项目，需要配合 Stores 进行跨仓库管理。

Q4：OpenSpec 需要 API Key 吗？

不需要。OpenSpec 是 CLI 工具，无需 API 密钥。

7.2 避坑指南

坑 1：跳过审阅直接 Apply

❌ 错误做法：Propose 完直接 Apply，不审阅规范。

✅ 正确做法：Propose 后必须人工审阅所有工件。在规范阶段发现问题，改几行 Markdown；在代码阶段发现问题，改几十行代码。

坑 2：规范写得太模糊

❌ 错误做法：

### Requirement: 用户登录
系统应该能让用户登录。

✅ 正确做法：

### Requirement: 用户登录
系统 SHALL 接受用户名和密码，验证通过后返回 JWT Token。

#### Scenario: 登录成功
- **GIVEN** 正确的用户名和密码
- **WHEN** 调用 /api/auth/login
- **THEN** 返回 HTTP 200 和 JWT Token

坑 3：一次变更太大

❌ 错误做法：一个变更包含“用户登录 + 用户注册 + 密码重置 + 邮箱验证”。

✅ 正确做法：拆分成 4 个独立变更，每个变更聚焦一个功能。

坑 4：忽略 Verify 步骤

❌ 错误做法：Apply 完就直接 Archive。

✅ 正确做法：Apply 后执行 /opsx:verify，对照规范检查实现。

坑 5：在存量项目中试图一次性写完整规范

❌ 错误做法：在已有项目中，试图为整个系统写完整规范。

✅ 正确做法：只为你即将修改的部分写规范。逐步引入，从小变更开始。

---

第八章：总结与展望

8.1 OpenSpec 的核心价值

OpenSpec 不是让 AI 变得更聪明，而是给 AI 编程助手套上 “规范的笼头”。它的核心价值在于：

1. 共识优先：人和 AI 在编写代码前先就规范达成一致
2. 组织有序：每个变更独立文件夹，完整的上下文
3. 灵活迭代：随时更新任何工件，没有僵化的流程
4. 工具无关：支持 20+ 种 AI 编程助手
5. 可追溯：每个变更提案都有完整的历史记录（Git 友好）

8.2 什么时候该用 OpenSpec？

场景	是否推荐	原因
个人项目，功能简单	✅ 推荐	习惯养成，后期收益大
团队协作开发	✅ 强烈推荐	规范统一，减少沟通成本
存量项目迭代	✅ 推荐	增量引入，风险低
大型复杂功能	✅ 强烈推荐	需求明确，减少返工
一次性脚本/PoC	⚠️ 可选	规范成本可能大于收益

8.3 下一步学习路径

1. 入门：完成本文的安装和第一个 Demo
2. 进阶：在实际项目中应用，积累规范编写经验
3. 精通：掌握自定义 Schema、Stores 跨仓库规划等高级功能
4. 布道：在团队中推广 SDD 实践，建立规范文化

8.4 写在最后

AI 编程时代最贵的成本，不是生成，而是返工。而返工的根，几乎都在 “没约定” 三个字。

OpenSpec 的价值不在于让 AI 写得更快，而在于让 AI 写得更对。它把软件工程的最佳实践固化成一套轻量级的工作流，让 AI 编程助手从 “容易遗忘的对话者” 转变为 “严谨可靠的协作者”。

从一个简单的 /opsx:propose 开始，让你的 AI 编程从“艺术创作”升级为“规范工程”。

---

附录：快速命令参考

命令	用途
openspec --version	查看版本
openspec init	初始化项目
openspec list	查看当前变更
/opsx:propose "描述"	创建变更提案
/opsx:explore "话题"	探索模式，理清思路
/opsx:apply	执行变更
/opsx:verify	验证实现是否符合规范
/opsx:archive	归档变更
openspec config profile	切换运行模式
openspec update	更新配置

注：非原创，来源于网络。