与SpecKit的区别

两者都是SDD的实现方案，解决的都是先对齐意图，再写代码的问题。但是两者的设计哲学截然不同。

SpecKit对于开发过程有着严格的规范，必须：定义->计划->任务->实施。有着严格的阶段门控。每个阶段都得严格完成后，才能进入到下一阶段。有序、严谨，但是缺乏灵活性。

OpenSpec的流动式工作流，更适合真实项目中的不确定性。

安装

  • 全局安装
1
2
3
pnpm add -g openspec
# 验证
openspec -V

初始化项目

1
2
# 先进入项目目录，再init
openspec init

回车，选择用到的编程Agent，可以选择多个

比如我选择了 claude 和 codex，就会生成 .codex 或 .claude 两个文件夹。里面包含了openspec要用到的各种skill

还会生成 openspec 文件夹，里面包括了 specs 文件夹，保存已经完成的功能，以及 changes 文件夹，保存正在开发的功能

提案 /opsx:propose

1
/opsx:propose  使用纯前端技术，不使用前端框架，开发一个待办清单管理，不对接后端，数据存储在浏览器。UI风格采用苹果科技风

这个命令会生成一个 proposal.md 文件。该文件描述 为什么要做这个变更，变更的范围是什么

我们审查该文件中对于需求的描述，是否符合我们的实际要求

生成 specs 目录，包含功能需求和场景描述

我们审查需求描述是否符合完整的场景覆盖

生成 design.md 文件，这是技术设计方案

我们审查技术方案设计是否合理

生成 tasks.md 文件，这是一组按照依赖顺序的实现任务列表

我们审查任务分解是否足够清晰，依赖顺序是否正确
Pasted image 20260504232426

在审查过程中，发现有任何的问题，告诉claude code，让它去修改

Pasted image 20260531152500

实现 /opsx:apply

1
/opsx:apply

就会根据文档，进行任务的实现。过程中可以随时打断。claude code要是觉得哪里不确定，也会问我们

由于我安装了 playwright mcp，claude code直接打开我的浏览器了。

测试了一下，基本没问题

Pasted image 20260504233949

检查实现

这就得是我们自己运行项目，测试效果了

归档，知识沉淀 /opsx:archive

1
/opsx:archive

做三件事情
1、合并规范增量
2、移动规范目录
3、更新主规范

小意外

  • 代码生成到了 openspec 目录，而不是项目根目录
  • 归档后， openspec/specs 目录仍旧是空的
    Pasted image 20260504235948

阶段小结

提案->实现->归档，就是 openspec的基本工作流

大多数场景下，开发已经够用了

拓展工作流

开启拓展工作流：openspec config profile

1
2
3
openspec config profile
# 运行更新命令后，新的配置才会在项目中生效
openspec update

Pasted image 20260505001058
这个命令 openspec config profile 是 OpenSpec 提供的可视化工作流配置工具，你可以在这里：

  • 选择开启 / 关闭哪些命令（workflows）
  • 控制这些命令在 Claude Code 里的呈现方式

拓展工作流介绍

序号 命令 作用 关键特点
1 /opsx:new 新建变更，创建独立工作区 代码、文档全隔离，不碰项目根目录
2 /opsx:propose 生成需求提案，明确 “做什么 / 不做什么” 对齐目标，避免 AI 跑偏
3 /opsx:spec 编写功能规范（接口 / 数据 / 逻辑） SDD 核心，后续所有开发都以它为标准
4 /opsx:design 制定技术方案，定义实现路径 明确技术栈、目录结构、依赖关系
5 /opsx:task 拆分成可执行的任务清单 复杂功能拆解，降低开发难度
6 /opsx:apply 根据任务生成代码 代码先写入 openspec/changes/，不污染项目
7 /opsx:verify 验证变更（运行测试 / 检查规范） 自动发现 bug、不符合规范的问题
8 /opsx:archive 归档变更，合并代码到项目根目录 真正写入项目，同步更新 specs/ 文档
- /openspec-explore 调研、分析现有项目 探索技术方案、了解项目结构
- /opsx:continue 继续上次中断的变更 避免重复输入，快速恢复工作