69,338 颗星、v1.13.1 刚发：OpenSpec 想在 AI 动手之前，先让它把需求读懂

智源·AI 开源观察 技术创作者 2026-09-19 235 阅读

Claude Code 们写代码越来越快，但有一个问题始终没解决：AI 拿到需求就开始写，写完才发现理解歪了。等到你发现的时候，要么接受一个不符合预期的功能，要么花大量时间返工。

OpenSpec 想解决的就是这个”需求对齐”的问题——在 AI 真正动手之前，先把”做什么”和”怎么做”写成一份小型规格文档，AI 和你都确认清楚了，再动代码。

它到底做什么

OpenSpec 是一个 Spec-Driven Development（SDD，规范驱动开发）框架，核心理念很简单：AI 编程助手在写任何代码之前，必须先理解规格。规格用纯 Markdown 写，不需要学特殊语法，但格式是结构化的——每条需求写清楚触发条件（WHEN）和预期结果（THEN），AI 读得懂，你也能审查。

安装方式是 npm 全局安装：

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

初始化完成后，你就可以用 slash 命令和 AI 对话了，主流工具（Cursor、GitHub Copilot、Amazon Q、Codex）都支持。v1.13.1（最新版本）新增了 profile-aware skills，生成的命令能匹配自然语言表述，比如你说”do an openspec apply”而不是记精确的命令格式。

工作流长什么样

标准流程是四个阶段：Explore → Propose → Apply → Archive。

第一步 /opsx:explore：你有个模糊的想法但不确定怎么做，跟 AI 说”I want dark mode but I’m not sure how to do it cleanly”，AI 会先读你的代码，分析现有架构，然后给出一个方向建议，这一步完全不做任何修改，是”零风险探索”。

第二步 /opsx:propose：方向确定后，Propose 会自动生成一个变更包，包含 proposal.md（为什么做这个改动）、specs/（具体需求和场景）、design.md（技术方案）、tasks.md（实现清单）。这个包在 openspec/changes/your-change-name/ 目录下，以 Git commit 的方式管理版本。你和 AI 一起 review 这个计划，确认无误再往下走。

第三步 /opsx:apply：按任务清单逐项实现，AI 报告进度，你随时中断或调整。

第四步 /opsx:archive：完成后归档到 openspec/changes/archive/，规格文档保留，作为后续维护的依据。

v1.13.1 还加入了”下一步提示”功能——openspec status 结束后会显示 Next: <具体命令>，你不需要记住完整工作流也知道下一步干什么。

真实使用场景

适合的场景：

  • 团队多人协作时对齐预期：一个需求涉及 API 服务端、Web 前端和共享库三个代码库，以往靠口口相传或 Notion 文档，AI 根本读不到。OpenSpec 的 Stores 功能（Beta）允许在一个独立仓库里管理规格，其他项目通过 git push 引用，同一个规格文档所有 AI 和人类都能读到。
  • 给 AI 划边界：当你需要 AI 做一个会影响多个模块的改动时，AI 容易”只管自己那块”而忽略连锁反应。规格文档把影响面明确写出来，AI 就没法装作没看见。
  • 降低代码审查门槛：reviewer 不需要跑通代码，只需要对照 specs/ 目录里的场景清单验证功能是否达成。

不太适合的场景：

  • 快速原型验证：如果你只是想快速跑一个想法是否成立，加一层规格文档会拖慢速度。
  • 个人小型项目：自己一个人维护、需求完全在自己脑子里，OpenSpec 的仪式感可能大于实用价值。
  • 需要强流程管控的团队：OpenSpec 强调 fluid 和 iterative，它不是 Jira，不做任务追踪、截止日期管理这类事。

和同类工具怎么选

GitHub Spec-Kit 是 GitHub 官方出的方案，定位更偏”大型团队严格需求管理”，适合 PRD 驱动的开发流程，OpenSpec 比它轻，npm 安装即可，不需要额外服务。

BMAD 走的是”完整敏捷生命周期 + 多 Agent persona”路线，方法论更重，适合愿意遵循严格流程的团队。OpenSpec 强调 iterative not waterfall，更灵活。

还有一个竞争维度是 Vibe Coding——让 AI 自己推断意图直接写，OpenSpec 的立场是：对于 brownfield 项目（已有大量存量代码），直接推断意图容易出错，规格文档是 AI 和人类之间的”契约”，减少理解偏差。

最新动态

v1.13.1（2026年9月）主要改进：安全加固（防止恶意配置注入）、任务进度计数更准确（支持 +、. 序号和 [~] 标记的检查项）、Nix 环境支持 bash/zsh/fish 补全，以及 Stores 功能的多项修复。v1.13.0 则改进了 archive 的 delta parser，告别”静默丢弃内容”的坑。

目前 OpenSpec 已有 69,338 颗 GitHub 星、4,750 个 Fork，MIT 许可证，TypeScript 编写，Node.js 20.19.0 以上可用。

下一步建议

如果你用 Cursor、Claude Code 或 GitHub Copilot，花 5 分钟在现有项目里跑一遍 openspec init，然后用 /opsx:explore 问一个你目前正在纠结的实现问题，感受一下 AI 在”动手”之前给的那个方向建议值不值这一步。

想深入可以读官方文档中的 How Commands Work 和 Existing Projects，后者专门讲了怎么在一个 brownfield 代码库里引入 OpenSpec 而不是从头项目开始。

评论区

0 条评论

登录后可评论。

智源·AI 开源观察 235 阅读