夜雨聆风
先说个数据：一个叫 OpenSpec 的开源工具，上线不到一年，GitHub 上已经攒了 6.5 万 star，今年 5 月一度冲上 GitHub Trending 第 3。在 AI 编程圈，这个增长速度快得反常。
为什么火？因为它解决了一个我用 AI 写代码以来最头疼的问题：需求只存在于聊天记录里，AI 写着写着就跑偏了。
上周我让 Claude Code 给科研笔记加个"标签自动补全"，它答得痛快，写出来的代码也能跑。但我一检查发现：它自己加了三个我根本没提的功能，还改了原来的目录结构。问它为什么，它说"我觉得这样更合理"。
问题就出在这——需求写在聊天里，等于没写。对话一长，AI 对"到底要什么"的记忆就开始漂移，漂移到最后，实现的和想要的根本不是一回事。
OpenSpec 的思路：把需求变成文件
OpenSpec 是个轻量的规范层，放在你的项目和 AI 助手之间。核心思想一句话：先对齐，再编码（agree before you build）。
它管"规范驱动开发"（Spec-Driven Development，SDD），但和那些重流程的老方法不一样。官方自己给的理念是：
• 灵活而非僵化（fluid not rigid）——没有强制门禁，随时可以迭代
• 面向存量项目（built for brownfield）——老项目也能渐进式接入，不用推倒重来
• 简单而非复杂——三招跑通：proposal → apply → archive
装它不需要 API Key，不需要 MCP，甚至不需要它自己的服务。就是一个 npm 包加一堆斜杠命令，支持 20+ 种 AI 工具（Claude Code、Cursor、Codex、GitHub Copilot、Kimi 都行）。
装一下：一条命令 + 一次初始化
前提：Node.js 20+（先 node -v 确认）。然后全局安装：
进入你的项目目录，初始化：
它会生成一个 openspec/ 目录，里面是两个区域：
• specs/ — 系统的"真相源头"，描述系统当前实际的行为，随功能归档逐步演化
• changes/ — 正在做的变更，每个功能一个文件夹，装四个工件
三招跑通一个功能
在 Claude Code 里，整个流程就三个斜杠命令：
• /opsx:propose "想法" — 建变更，AI 一次性生成四个工件：proposal.md（为什么做、做什么）、design.md（技术方案）、tasks.md（任务清单）、specs/（需求差异）
• /opsx:apply — 让 AI 按 tasks 一条一条实现，完成一项勾一项
• /opsx:archive — 功能完成，把需求差异合并回 specs/，变更归档，系统规范同步更新
我的实测：改参考文献格式，三步跑通
拿我自己的项目试了一次。我的科研笔记导出的参考文献一直用的 APA 格式，但组里要求 GB/T 7714。以前这种需求我直接丢给 AI，结果它改了导出函数，连带把论文模板样式也动了一堆。
这次我改用 OpenSpec：
第一步 /opsx:propose "把参考文献导出格式从 APA 改成 GB/T 7714"。AI 没有直接写代码，而是先产出四个工件。我看 proposal.md 时发现了关键信息：它写的是"调整导出函数的格式化逻辑，不影响论文模板"，范围锁得死死的。这就把上次"乱改样式"的问题扼杀在动手前。
第二步 /opsx:apply。它照着 tasks.md 逐项实现，每完成一项勾掉一项。做完我抽查，全部在任务清单范围内，一个多余动作都没有。
第三步 /opsx:archive。变更归档，"参考文献导出遵循 GB/T 7714"写进了系统的 specs。以后任何 AI 再碰这个项目，都会先读到这条规范。
最大的变化不是"AI 不乱写了"，而是"需求变得可见、可审、可追溯"。以前需求在我脑子里、在聊天记录里，现在它们躺在文件里，谁都能看，AI 每次开工前都得读。
它和 gstack、superpowers 什么关系
最近这两兄弟也火，我干脆一起说清楚：
• superpowers — 管"AI 的行为"。自动触发技能，写完自己测、自己审，约束的是过程
• gstack — 管"AI 的身份"。23 个斜杠命令切换专家角色，CEO、架构师、QA 分头把关，约束的是角色
• OpenSpec — 管"AI 的目标"。把需求变成文件，让 AI 先对齐再动手，约束的是范围
三个可以叠着用：gstack 的 /plan-eng-review 定架构方向，OpenSpec 把方向落成规范文件，superpowers 保证实现过程不偷懒。我现在的用法是 OpenSpec 打底——毕竟方向错了，过程再规范也是白费。
四个坑，先说清楚
① 需要 Node 20+。 版本不够会装不上或报错，先 node -v 确认。
② 弱模型会"配合"你写废话。 生成工件这一步吃模型能力，弱模型容易写出泛泛而谈的 proposal，反而增加负担。配个强推理模型（比如 Claude、GPT-5 系）体验完全不同。
③ 小脚本别用。 一次性代码、临时测试，不值得走完整流程。它面向的是"会持续迭代的正式功能"。
④ 不同工具的斜杠命令写法不一样。 Claude Code 用 /opsx:propose，Cursor/Windsurf 用 /opsx-propose，Kimi 用 /skill:openspec-propose。换工具时别照抄。
它到底适合谁
如果你符合下面任意一条，值得一试：
• 被"AI 自己加功能"坑过，想让 AI 只做你让它做的事
• 存量项目想引入规范，但又不想推倒重来、搞重流程
• 换了好几个 AI 工具，希望需求文档跟着项目走，而不是锁死在某个工具里
说到底，OpenSpec 教给 AI 的不是"怎么写代码"，而是"先证明你听懂了，再动手"。这一课，对 AI 和对我自己都挺值钱的。
需求写进文件里的那一刻，AI 的跑偏就从"必然"变成了"可防"。
💬 你让 AI 写代码，最怕它自作主张加什么？或者你有自己的"防跑偏"招数？评论区聊聊。
如果觉得这篇文章有用，欢迎关注「AI 阿砚」，一个科研爱好者的 AI 探索笔记。