一句话看懂：开源工具 OpenSpec 提出用 Markdown 规约让 AI 编程“先对齐、再写码”，试图解决存量工程中 AI 改完代码无人敢验收的问题。它不绑定具体 AI 编程工具，对开发者更友好。
事件核心：发生了什么
2026 年 11 月，技术社区出现一篇关于 OpenSpec 的实践分享。OpenSpec 是 Fission-AI 开源的轻量级规约驱动开发框架，采用 MIT 协议，支持 Claude Code、Cursor、CodeBuddy、Codex、Copilot 等 30 多种 AI 编程工具。核心做法是在项目中维护 openspec/specs/ 描述系统当前行为，openspec/changes/ 存放进行中的变更提案，并用五步闭环——探索、提案、评审、实施、归档——让代码出现之前先由人审阅文字计划。所有产物均为纯 Markdown，无私有语法、无数据库、无服务端。
为什么重要
在几十万行的老工程里，AI 改代码本身不是最难的部分，难的是没人说得清“改成什么样算完成”。没有可验收的契约，Review 容易退化为“看起来没报错”，需求也会随着聊天记录被压缩或会话更换而流失，形成规约漂移。OpenSpec 的价值在于把“系统应该表现出什么行为”写成可评审、可进 Git 的结构化文档，让规约追赶代码，而非停留在某次群聊或某个人的记忆里。它面向已有项目设计，允许团队逐步沉淀当前行为，不需要一次性补全文档。
对用户/开发者/创作者的影响
对开发者而言，OpenSpec 上手成本较低，支持独立二进制、npm、Homebrew 安装，执行 openspec init 后即可用 slash command 走完工作流。实施阶段建议新开会话、按 tasks.md 复选框推进，中断后可从第一个未勾选任务继续。评审环节修改文字的成本远低于改代码，适合在存量工程中先控制变更范围。需要留意的是，工具不强制阶段门禁，产物随时可回改，因此团队仍需自行约定评审纪律；命令写法因 AI 工具而异，应以 openspec init 的实际输出为准。目前公开信息显示，这是社区实践文章，不代表大规模生产验证结论。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 OpenSpec 能否从个人项目扩展到团队协作，特别是变更评审和归档流程的实际使用反馈；二是与代码地图、技能包等工具组合后，能否真正覆盖“看得见、说得清、验得了”的完整链条；三是同类规约框架是否跟进，形成更统一的 AI 编程验收标准。
来源：juejin
