用 AI 写代码，最常见的流程是：在对话框里描述需求，AI 直接开写，不满意再改，改着改着需求就散落在几十条聊天记录里。过两天再回来，你和 AI 都说不清当初到底约定了什么。
开源项目 OpenSpec（Fission-AI/OpenSpec，MIT 协议，GitHub 上超过 7 万 Star）想解决的就是这个问题。它在 AI 编程助手和代码之间加了一层轻量的"规范"：动手写代码之前，先让 AI 把要做什么、为什么做、怎么做写成几份 Markdown 文件，你确认之后再进入实现。这种做法通常叫规范驱动开发（Spec-Driven Development）。
OpenSpec 的设计思路
项目 README 里写了五条理念：灵活而不僵化，迭代而不是瀑布式，简单而不复杂，不只适合新项目、也适合已有代码的老项目，从个人项目到企业都能用。
落到具体做法上，有四个特点：
- 先对齐再动手：人和 AI 在写代码前先就规范达成一致；
- 每个改动一个文件夹：每次改动都有自己的目录，里面放提案、规范、设计和任务清单；
- 随时可改：任何一份文件都能随时更新，没有死板的阶段关卡；
- 沿用现有工具：通过斜杠命令支持 30 多种 AI 编程助手，不需要换 IDE。
安装和初始化
OpenSpec 是一个命令行工具。用包管理器安装最直接，npm 和 Homebrew 二选一：
# npm（需要 Node.js 22.12.0 或更高版本）
npm install -g @fission-ai/openspec@latest
# 或者 Homebrew
brew install openspec
官方也提供了 macOS、Linux 和 Windows 的一键安装脚本，以及 pnpm、yarn、bun、Nix 等安装方式，具体可以看 openspec.dev 的安装文档。
装好后进入项目目录初始化：
cd your-project
openspec init
openspec init 会让你选择正在用的 AI 编程工具，然后把对应的指令和斜杠命令装进项目，并打印出这个工具里命令的正确写法。
一次完整的改动：从想法到归档
OpenSpec 的核心流程由四个命令组成。README 里用"给应用加暗色模式"做了演示，整个过程是这样的。
1. 探索：/opsx:explore
还没想清楚怎么做时，先用 explore。它像一个没有压力的讨论伙伴，会读你的代码、比较几种方案，在写任何代码之前把计划理出来。在演示里，AI 看完样式配置后建议用 CSS 变量加一个轻量的主题上下文，并检测系统偏好，不引入新依赖。
2. 提案：/opsx:propose
方向定了，用 propose 生成一次改动。比如运行 /opsx:propose add-dark-mode，OpenSpec 会创建 openspec/changes/add-dark-mode/ 目录，里面有四样东西：
| 文件 | 内容 |
|---|---|
| proposal.md | 为什么做、改什么 |
| specs/ | 需求和具体场景 |
| design.md | 技术方案 |
| tasks.md | 实现任务清单 |
如果已经很清楚要做什么，可以跳过 explore，直接从 propose 开始。
3. 实现：/opsx:apply
你审完这几份文件、确认没问题后，运行 apply，AI 会按 tasks.md 里的清单逐项实现，比如添加主题上下文、创建切换组件、加 CSS 变量、接入本地存储，完成一项勾一项。
4. 归档：/opsx:archive
做完以后运行 archive，这次改动会被移到 openspec/changes/archive/ 下，目录名带上日期，同时把规范更新进项目的长期规范库，准备开始下一个功能。
规范文件长什么样
规范就是普通的 Markdown，不用学特殊语法。每条需求配上具体场景，用 WHEN 和 THEN 描述触发条件和预期结果。以暗色模式为例：
## ADDED Requirements
### Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.
#### Scenario: User toggles dark mode
- **WHEN** the user clicks the theme toggle
- **THEN** the app switches to dark mode and persists the choice
这些内容由 AI 来写，你要做的是在写代码之前审一遍计划。OpenSpec 自己的仓库就是用 OpenSpec 开发的，仓库里的 openspec/specs 和 openspec/changes 目录可以当作真实项目的参考样例。
不同工具里的命令写法
/opsx:propose 是标准名称，但在不同工具里的写法不太一样：Cursor 和 GitHub Copilot 里是 /opsx-propose，Amazon Q 里是 @opsx-propose，Codex 里则以美元符号开头，写作 openspec-propose 这样的技能名。不用死记，openspec init 会按你选的工具打印正确写法。
在 Codex 里用 OpenSpec 时，规范文件和 AGENTS.md 可以配合使用：AGENTS.md 放项目的长期规则，OpenSpec 管每一次具体改动的需求和任务。AGENTS.md 的写法可以参考 AGENTS.md，把项目规范写给 Codex。
默认流程和扩展流程
explore 和 propose 都包含在默认配置里。需要更细的流程控制时，可以切换到扩展配置，它会额外提供 /opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive 和 /opsx:onboard 这几个命令，适合想把一次改动拆成更多步骤、或者在归档前做一次校验的场景。
切换方式是先运行 openspec config profile 选择配置，再运行 openspec update 让它生效。
团队协作：Stores
一个人用时，OpenSpec 管的是单个仓库。到了团队里，难点会变：一个功能可能同时涉及 API 服务、Web 应用和共享库，需求由一个团队负责、多个团队使用，规划甚至要在代码存在之前就开始。
为此 OpenSpec 推出了 Stores（目前是 beta）：把规划放进一个独立的仓库，沿用同样的 openspec/ 结构，通过 git push 共享。跨仓库的功能可以用一份改动、一份计划来管理；平台团队维护规范，产品团队以只读方式引用，各自的 AI 编程助手都能直接读到。
和 Spec Kit、Kiro 的区别
README 里给了 OpenSpec 自己的对比：
- 对比 GitHub 的 Spec Kit：Spec Kit 很全面，但比较重，阶段关卡严格，Markdown 文件多，还需要 Python 环境。OpenSpec 更轻，可以自由迭代。
- 对比 AWS 的 Kiro：Kiro 功能强，但要绑定它自己的 IDE，可选模型也有限制。OpenSpec 可以在你已经在用的工具里工作。
- 对比什么都不用：不写规范的 AI 编程，提示词含糊，结果难以预测。OpenSpec 想在不增加繁琐流程的前提下，带来可预期的结果。
简单说，想要一套完整严格的流程，可以看 Spec Kit；只用一个 IDE、不在意绑定，可以看 Kiro；想在现有工具里低成本地加一层规范，OpenSpec 更合适。
使用建议
- 用推理能力强的模型：官方建议规划和实现都用高推理能力的模型。
- 保持上下文干净：开始实现前先清空上下文，整个会话里也尽量保持上下文整洁。
- 及时升级：升级 CLI 后，在每个项目里运行一次
openspec update，重新生成 AI 指令，确保用上最新的斜杠命令。 - 注意遥测：OpenSpec 会收集匿名使用统计，只包括命令名和版本号，不含参数、路径和内容，在 CI 环境里自动关闭。不想上报的话，运行
openspec config set telemetry.enabled false即可。
如果你喜欢"先定规格再动手"的思路，还可以看看 mattpocock/skills 安装教程 里的 to-spec 用法。准备在 Claude Code 或 Codex 里试 OpenSpec 的话，可以先到 AIGoCode 模型页 选好对应工具的分组和模型，再从一个小功能开始，跑一遍 explore 到 archive 的完整流程。