📌 项目地址：Fission-AI/OpenSpec | ⭐ 51,582 颗星 | 🔧 TypeScript | 📜 MIT
五万多个star，README第一句说“The most loved spec framework.”——打开 Fission-AI/OpenSpec 的首页，你会发现它压根不是又一个代码生成器，而是一套让AI按团队规矩干活的规范框架。
为什么需要它
AI写代码越来越快，但它在你的项目里永远是新人。它不知道：
- 为什么你们选了Vue而不是React
- 异常处理统一用try-catch还是error boundary
- 团队已经封装好的工具函数它却自己再造一遍
结果就是AI生成的东西经常“自由发挥”——跟现有架构冲突、绕过约定、引入不一致。我见过团队review时发现六成AI代码要改，一半原因是AI没读过项目历史。
OpenSpec的解法很直接：不让AI直接写代码，而是先写规范文档。所有AI输出必须基于项目已有的规范和团队决策，才能开始实现。
它的设计哲学五句话：
→ fluid not rigid
→ iterative not waterfall
→ easy not complex
→ built for brownfield not just greenfield
→ scalable from personal projects to enterprises
最有价值的我看来是第四句——“不仅为绿地项目（从零开始），更为棕地项目（存量项目）”。大多数团队有几十万行存量代码，AI在这些项目上最容易出问题。OpenSpec把“规范”固化成文档，AI每次都能读到项目约定，而不是靠模型自己猜。
三段式工作流：先方案，再执行，后归档
OpenSpec定义了三组核心斜杠命令。你需要在AI工具（Cursor、Claude、GitHub Copilot等25+工具）里输入这些命令。注意，所有命令都是真实存在的，下面直接引用README里的用法。
第一阶段：/opsx:propose —— 只写方案，不动代码
你想加暗黑模式。输入 /opsx:propose "add-dark-mode"，AI不会改代码，而是在项目根目录下创建：
openspec/changes/add-dark-mode/
├── proposal.md # why we're doing this, what's changing
├── specs/ # requirements and scenarios
├── design.md # technical approach
└── tasks.md # implementation checklist全部是Markdown文件。团队成员可以review、批注、驳回。改动成本为零——代码还没写。我有次在proposal阶段被人指出“Provider没考虑SSR”，改了一行markdown就过了，不用等bug出现。
第二阶段：/opsx:apply —— 按清单逐条执行
方案确认后，输入 /opsx:apply，AI打开tasks.md，逐项执行。README里的输出示例：
✓ 1.1 Add theme context provider
✓ 1.2 Create toggle component
✓ 2.1 Add CSS variables
✓ 2.2 Wire up localStorageAI不能改方案、不能自由发挥。每个task对应一个commit，CI可以强制要求每次提交关联设计文档。
第三阶段：/opsx:archive —— 归档，保持项目目录整洁
完成后，输入 /opsx:archive。目录从 openspec/changes/add-dark-mode/ 移到 openspec/changes/archive/2025-01-23-add-dark-mode/。项目主目录恢复干净，所有历史按日期存档。翻Code Review或问题回溯时直接看归档目录。
如果需要更丰富的流程（/opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard），先运行 openspec config profile 选择扩展模式，再 openspec update 生效。
README还提到一个细节：运行/opsx:propose "your idea"即可开始，然后AI会自动创建上面那套结构。如果提示“Workflow not active”，需要先执行初始化。
快速上手
要求Node.js 20.19.0或更高。
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init然后在AI工具里输入 /opsx:propose "你的想法"。支持pnpm、yarn、bun和nix，更多安装方式见安装文档。支持的工具列表在 Supported Tools，目前25+并持续增长。
实际感受：值不值？
写proposal比直接给prompt多花五到十分钟。省下的时间更值——每次review少说十分钟争吵，归档目录让新人看二十个历史变更就能搞懂过去三个月所有设计决策。
有一次我们设计遗漏了浏览器存储的版本兼容性——proposal阶段就被指了出来。如果直接让AI写，这个问题要跑出bug才能发现。
归档后的目录在团队Code Review时很有用。每次PR都能链接到对应设计文档，新人不需要追着问“为什么这样写”。团队老人也不用重复解释。
缺点也有：不适合个人练手项目、一次性脚本、改动少于三个文件的小变更。这些场景直接写prompt更快。OpenSpec的价值不在“AI能帮你做什么”，在“AI怎么能按团队标准做事”。
社区已经有第三方schema bundle，把React、Django等特定技术栈的规范封装成可复用模板。如果你在几个项目里反复遇到相同风格的问题，可以去文档里找community bundles。
总结
OpenSpec不是一个“让AI写代码更快”的工具，而是一个“让AI写代码更靠谱”的工作流程。它把AI从自由发挥的“副驾驶”变成了按标准作业的“施工队”。对有历史包袱的团队来说，这个价值比代码生成速度大得多。