3条命令、4个节点：多AI编程助手的规范驱动开发协作-编程实验室

3条命令、4个节点：多AI编程助手的规范驱动开发协作

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

OpenSpec 是一个面向多个 AI 编程助手的规范驱动开发工具：它把团队认可的规范沉淀成纯 Markdown 文件，让 Claude Code、Cursor、Copilot 里不同的 AI 基于同一份文件干活，变更有迹可循，进度一眼可见。下面用一个真实需求——"给搜索结果页加一个过滤器"——把它走一遍。

🔍 节点一：提出。/opsx:propose 让AI先交计划书，再碰代码

让AI直接写代码的风险，是它"自信地"朝你想的反方向跑——而你在聊天框里只能事后发现。OpenSpec 的做法是把"要做什么"提前落成文件，评审通过前一行代码都不写。

上手只需要两条命令：全局安装后在项目里初始化，它会自动识别你在用哪些 AI 工具并生成对应的斜杠命令与代理指令（如 AGENTS.md），各家的 AI 从此读同一套规则。

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

然后你在 AI 聊天框里输入/opsx:propose add-search-filter。AI 不会打开编辑器，而是建好 openspec/changes/add-search-filter/ 这个文件夹，里面四样东西：proposal.md 讲为什么做、范围到哪，specs/ 里是"delta 规范"（用 ADDED/MODIFIED 标记相对现状改了什么行为），design.md 讲技术方案，tasks.md 是带勾选框的实现清单。你翻完这堆文件、确认无误，才算点头。

💬 节点二：评审。delta 规范和代码一起进PR，先看意图再看实现

评审最容易翻车的时刻，是开了四十分钟才有人问"这功能到底要干什么"。OpenSpec 把这个问题提前到看任何一行 diff 之前——因为一个变更就是一个普通文件夹，OpenSpec 本身不碰 git，你完全按现有流程走分支和 PR。

具体做法：变更文件夹和代码放在同一个分支，PR 里既有 spec delta 又有代码。评审顺序建议是——

读 proposal.md：问题选对了吗，范围对吗；
读 specs/ 下的 delta："完成"的定义对吗；
最后读代码 diff：实现恰好交付了这些需求吗。

对方案有异议的同事可以直接对着 proposal 提，不用在三百行代码里翻烧饼。半年后回头看，归档的规范还能解释代码为什么长这样。

🛠️ 节点三：实现。/opsx:apply 照任务清单干活，tasks.md 就是进度条

"做完了吗"在没有共享清单时永远是薛定谔问题。tasks.md 里的勾选框就是这个问题的答案：/opsx:apply时 AI 逐条执行并回填勾选状态，谁在哪个工具里干活，进度都写在同一个文件里。

它省掉的麻烦是：不用在群里问进度，也不用担心 AI 做到一半跑偏——CLI 负责确定性的脚手架和状态，AI 只负责执行。而且流程是流动的，不是锁死的阶段门：实现中发现当初的假设错了，随时回头改 plan 里的任何一份文件，再回来继续。

🗂️ 节点四：归档。/opsx:archive 把批准的更新合回主规范

两个人各自归档同一个需求，谁的版本会留下来？这是多人协作里最疼的漏洞，OpenSpec 分两层堵。

第一层是隔离：不同的变更是不同的文件夹、不同的分支，互不打架；约定一个变更只留一个负责人。第二层是校验：变更在验证阶段会记录它基于的主规范内容指纹，归档时重新比对——如果别人已经改过同一条需求，规范出现分歧，归档会被拦下来，而不是静默覆盖；两个变更真的改了同一条需求时，第二个归档会在 openspec/specs/ 里产生像 git 冲突一样的合并冲突，留着能反映真实行为的那条。specs/ 目录是全团队唯一的事实来源，/opsx:archive会先确认任务做完、必要时先 sync，再把 delta 合进去，把变更文件夹移进 openspec/changes/archive/ 并带上日期——历史全部留档，可追溯。