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 就做什么是完成的达成一致并且这份一致被写进文件、可评审、可追溯。你担心的事纯手动管理有 OpenSpec需求只在聊天记录里换个 AI 工具就丢上下文需求落在openspec/下的 Markdown 文件任何工具都能读改动前没对齐写完 300 行代码才发现理解错了先出变更提案和规范评审通过再实施多个变更互相覆盖靠人肉记住谁改了哪每个变更一个文件夹归档时合并回主规范进度不透明得问一句现在到哪了仪表盘实时显示活跃变更和任务进度它支持 30 多种主流工具Claude Code、Cursor、GitHub Copilot、Codex、Kilo Code 等直接通过斜杠命令调用其余工具靠读取生成的指令文件接入。命令名会随工具变化——同一个提案命令在 Claude Code 里是/opsx:propose在 Cursor 里写作/opsx-propose——但背后指向的是同一份规范。更多细节可以查 docs/。 四步装好跑通第一条变更前提是需要 Node.js 20.19.0 以上版本。全局安装 CLInpm install -g fission-ai/openspeclatest跑完之后你会看到终端里多了openspec命令--version能正常输出版本号。进入项目目录初始化openspec init初始化会提示你勾选要接入的 AI 工具结束后它会打印每个工具对应的斜杠命令写法——记住这张清单它是后面试水时的路标。打开你的 AI 助手输入第一条提案命令/opsx:propose add-profile-search-filter几秒后你会看到openspec/changes/add-profile-search-filter/文件夹诞生里面有proposal.md为什么做、范围多大、specs/需求与场景、tasks.md实施清单——一份完整的变更提案。终端里敲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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考