跳转至

OpenSpec

概述

OpenSpec 是一个开源、轻量级的规范驱动开发（SDD）框架，专为 AI 编程助手而设计，由 Fission AI 开发。它不再将需求散落在转瞬即逝的对话历史中，而是引入结构化的规范层，让人与 AI 在实现开始前先就需求达成共识。该框架的设计理念是流动、迭代而非僵化、瀑布式，适用于任何规模的存量（brownfield）和新建（greenfield）项目。截至 2026 年 4 月，该项目在 GitHub 上已获得 50,100 颗星，并在 MIT 许可证下持续维护。

（更新说明：本页此前将 OpenSpec 描述为"即将推出"且处于"早期开发阶段"；截至 v1.3.1，它已是拥有庞大社区的生产级工具。）

核心设计理念

OpenSpec 的三条基本原则：

  • 先达成共识，再动手构建 — 规范在实现开始前完成撰写与评审，减少反复修改。
  • 保持有序 — 每个变更提案都存放在专属文件夹中，具有一致的制品结构，将上下文从对话历史中分离出来。
  • 灵活工作 — 任何制品随时可更新，规范与实现阶段之间没有僵硬的阶段门控。

其维护者将这一理念概括为："流动而非僵化，迭代而非瀑布，简单而非复杂，为存量项目而生而不仅仅针对新建项目，可从个人项目扩展至企业级。"

制品结构

每个变更提案都会创建一个专属目录，包含四类制品：

制品 文件 用途
提案 proposal.md 变更的动机、范围与概览
规范 specs/ 目录 需求与场景驱动的验收标准
设计 design.md 技术方案与架构决策
任务 tasks.md 供 AI 智能体执行的编号实现清单

已完成的提案通过 /opsx:archive 命令移至带时间戳的归档文件夹，保持工作目录整洁。

主要工作流：/opsx 命令

OpenSpec 以斜杠命令作为制品引导开发的主要交互界面：

命令 操作
/opsx:propose <idea> 生成完整的变更文件夹（提案、规范、设计、任务）
/opsx:apply 系统化地执行所有任务——组件创建、样式处理、集成
/opsx:archive 将已完成的变更移至归档；更新规范以供后续迭代使用
/opsx:new 开启一个新的变更提案
/opsx:continue 继续处理现有提案
/opsx:ff 快速推进多个任务
/opsx:verify 对照规范验证实现结果
/opsx:bulk-archive 批量归档多个已完成的变更
/opsx:onboard 将现有项目接入 OpenSpec

安装与要求

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init
  • Node.js：需要 20.19.0 或更高版本
  • 包管理器：支持 npm、pnpm、yarn、bun 和 nix
  • 语言：TypeScript（占代码库 99.1%）
  • 最新版本：v1.3.1（2026 年 4 月 21 日）
  • 更新：openspec update 可重新生成智能体指令并激活最新斜杠命令

遥测数据：匿名遥测仅收集命令名称和版本号；在 CI 环境中自动禁用；可通过 OPENSPEC_TELEMETRY=0 退出。

工具集成

OpenSpec 兼容 25+ 款 AI 助手和开发工具，包括 Claude、GitHub Copilot、VS Code、Cursor 等。这种工具无关性是有意为之的设计选择——不将用户锁定在特定 IDE 或模型厂商。

社区 Schema 扩展了基础框架：第三方有主见的工作流包以独立仓库形式分发，支持团队在 OpenSpec 原语之上共享并版本化各自的工作惯例。

与同类工具的对比

维度 OpenSpec GitHub Spec Kit AWS Kiro
重量级 轻量，最小化配置 较重，依赖 Python 专有，以 IDE 为中心
阶段门控 无——全程可随时更新 严格的阶段结构 遵循 Kiro 工作流结构
工具范围 25+ AI 助手，工具无关 GitHub 原生 Kiro IDE / AWS 工具链
项目类型 存量 + 新建项目 主要面向新建项目 AWS 集成项目
开源 MIT 不适用 专有
安装方式 npm install -g Python 安装 IDE 插件

OpenSpec 的核心差异化在于：它解决了需求仅存在于对话历史时带来的不可预测性，同时不引入繁重的流程。Thoughtworks 技术雷达（第 34 期）将其列为"New"，并指出它"聚焦于规范增量而非完整的前期规范，非常适合存量系统"。

最佳实践

挑战 / 领域 说明 解决方案 / 建议
模型选择 并非所有模型都能同等水平地处理规范生成 使用高推理能力的模型；推荐 Claude Opus 4.7 和 Codex 5.5
上下文管理 过长的对话历史会降低 AI 规范质量 在执行 /opsx:apply 前使用干净的上下文窗口
架构变更 对架构进行随意的 AI 编辑会导致偏离 在实现任何架构变更前先提交 OpenSpec 提案
存量项目接入 已有项目缺乏规范基线 使用 /opsx:onboard 从现有代码库生成初始规范
规范健康度 若不维护，制品会变得过时 归档已完成的提案；在每次迭代前更新规范，再重新提案

应用场景

  • 功能开发：提案、规范、实现完整闭环，留有完整制品记录
  • 存量代码重构：接入已有代码库，为变更区域逐步建立规范
  • API 设计：为接口撰写规范，让 AI 根据规范生成实现
  • 多会话工作：制品跨会话持久化，为 AI 智能体提供可恢复的上下文
  • 团队协作：版本控制中的共享规范文件夹为需求提供单一事实来源

参见

参考资料