企业官网建设流程全解析

OpenSpec 规范驱动开发完整指南：让不同 AI 工具共享同一套规范

【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec

上周，同事 A 用 Claude Code 给"个人资料搜索"写了份新规范，第二天同事 B 用 Cursor 对同一需求出了另一套方案，两个变更一合并，前者的实现被悄悄覆盖——没有告警，没有冲突提示，谁都没发现。OpenSpec 就是为这种场面准备的：它是一个规范驱动开发工具，把"要做什么"落成一组 Markdown 规范文件，你换用哪个 AI 编程助手，读的都是同一套东西。

🧭 三十秒看懂：它替你管住什么

定位很简单：在 AI 动手写代码之前，先让你和 AI 就"做什么是完成的"达成一致，并且这份一致被写进文件、可评审、可追溯。

它支持 30 多种主流工具：Claude Code、Cursor、GitHub Copilot、Codex、Kilo Code 等直接通过斜杠命令调用，其余工具靠读取生成的指令文件接入。命令名会随工具变化——同一个提案命令，在 Claude Code 里是/opsx:propose，在 Cursor 里写作/opsx-propose——但背后指向的是同一份规范。更多细节可以查 docs/。

🚀 四步装好，跑通第一条变更

前提是需要 Node.js 20.19.0 以上版本。

1. 全局安装 CLI：

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

跑完之后你会看到终端里多了openspec命令，--version能正常输出版本号。

2. 进入项目目录初始化：

openspec init

初始化会提示你勾选要接入的 AI 工具，结束后它会打印每个工具对应的斜杠命令写法——记住这张清单，它是后面试水时的"路标"。

3. 打开你的 AI 助手，输入第一条提案命令：

/opsx:propose "add-profile-search-filter"

几秒后你会看到openspec/changes/add-profile-search-filter/文件夹诞生，里面有proposal.md（为什么做、范围多大）、specs/（需求与场景）、tasks.md（实施清单）——一份完整的变更提案。

4. 终端里敲openspec view，交互式仪表盘会打开，左边是新变更的进度，右边是现有规范清单。你会直观看到"规划"从聊天框里的无形状态，变成了仓库里可 diff、可评审的文件。

🔄 一个变更的完整生命周期：从提案到归档

提案：让 AI 先交底稿

提案阶段，AI 不写代码，只写文件。proposal.md记录意图和范围，specs/下的增量规范用"需求 + 场景"的格式写清楚完成后系统应当如何表现，tasks.md是可逐条勾选的清单。别急着改，先花两分钟通读。

评审：在代码出现之前

顺序很重要：先读提案（是不是我问的那个问题、范围有没有悄悄变大），再读增量规范（"完成"是否被正确定义、我最在意的场景有没有覆盖到），最后看任务清单是否和已接受的需求一一对应。发现不对的地方，直接编辑 Markdown，或者一句话让 AI 重改——"把认证相关的改动删掉，超范围了"。在一段话的层面纠偏几乎是零成本，在 300 行代码层面纠偏则不便宜，这就是评审存在的意义。

实施：apply 之后还有 verify 兜底

确认方案后，/opsx:apply让 AI 按tasks.md逐条实施，跑完你会看到清单被打钩、任务与需求一一对应。实施完成不等于收工：/opsx:verify会重读规范和代码，从完整性（每个需求都有对应实现）、正确性（边界情况是否处理）、一致性（设计决策是否真的落进代码）三个维度交叉检查，输出 CRITICAL、WARNING、SUGGESTION 三级提示。它不阻断你，但"AI 写了代码"和"AI 做了我们商量的事"之间的差距，就是它替你挑出来的。

归档：把规范合并回真相源

/opsx:archive会先检查任务是否全部完成（有未完成的会警告），然后提议把增量规范同步进主规范openspec/specs/，最后把整个变更文件夹挪进带日期的archive/目录。跑完之后你会看到变更从"活跃"变成"已归档"，而六个月后任何人翻到归档记录，都能明白当时为什么这么改。这里还有个设计值得注意：OpenSpec 从不碰 git——变更就是文件，由你像提交代码一样提交它，它只是恰好和 git 的分支、PR、合并冲突流程严丝合缝。

🎬 实战走读：两人、两个工具、一份规范

需求：给个人资料页加搜索过滤器。

第 1 步：成员 A 用 Claude Code 发起/opsx:propose add-profile-search-filter，提案、规范、任务清单落进openspec/changes/，随分支一起提交。

第 2 步：PR 里同时包含规范增量和代码 diff。成员 B 用 Cursor 打开 PR，按提案 → 增量规范 → 代码的顺序评审——他先确认"做什么是完成"的定义没问题，再看代码是否恰好交付了这些需求。B 不认同方案时，直接在提案段落上提出异议，而不是对着几百行 diff 逐行拉扯。

第 3 步：PR 合并后，任一成员运行/opsx:archive，规范增量合并回主规范，变更进归档。任何人运行openspec view，仪表盘立刻反映最新状态。

整条链路里，A 和 B 用的是不同工具、命令拼法还不一样，但读写的始终是同一份规范。两个人各自推进的add-dark-mode和rate-limit-login这类不同变更也不会相撞——每个变更是独立文件夹，唯一会冲突的地方是主规范本身：当两个变更改动同一条需求时，第二个归档会在specs/里触发一次普通的 git 合并冲突。听起来像麻烦，其实是特性——这是系统在明确告诉你："两个变更对系统该怎么表现产生了分歧"，解掉它，保留反映真实行为的那条需求即可。

⚠️ 踩坑前先看这三条

• 别两个人改同一个变更，换成一人一个变更。变更文件夹就是协作单元，两人同时编辑同一变更等价于同时改一个文件；与其约定分工，不如把它拆成两个变更。
• 别跳过评审直接 apply，换成花两分钟读底稿。在一段话的提案里发现理解偏了几乎免费，在代码里发现则要重写——评审就是用来收这笔利息的。
• 别把openspec/文件夹留在本地不提交，换成像源码一样提交它。规范、活跃变更和归档都是项目历史的一部分；切换 AI 工具后记得跑一次openspec update，刷新指令文件，保证最新斜杠命令激活。

渐进式采用同样省力：从新功能开始走变更提案，存量代码的修改逐步纳入，规范库会在日常使用中自己长出来。

规范是团队的公共语言，工具只是各自的方言。

【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec