OpenSpec 是面向 AI 编码助手的「规格驱动开发」（Spec-Driven Development，SDD）工具。它的核心主张是：在写任何代码之前，先让人类和 AI 就「要做什么」达成一致——把需求沉淀为结构化的规格文件，而不是散落在聊天记录里。OpenSpec 以一个轻量的 CLI（npm 包 @fission-ai/openspec）和一组 slash 命令的形式工作，为每个变更建立独立的文件夹，包含 proposal（为什么做、改什么）、specs（需求与场景）、design（技术方案）和 tasks（实现清单）。其设计哲学强调流动而非僵化、迭代而非瀑布、面向已有代码库（brownfield）而非只服务新项目。
来源：README.md（顶部哲学段落、Why OpenSpec、See it in action）；GitHub 仓库描述 查看 GitHub 仓库 →2025–2026 年「规格驱动开发」成为 AI 编程领域的热点方法论：当需求只存在于对话历史里时，AI 编码助手的产出难以预测，业界开始用规格层来约束。OpenSpec 在这一赛道里以「轻」取胜——相比 GitHub 的 Spec Kit（流程重、阶段门多、需要 Python）和 AWS 的 Kiro（绑定自家 IDE 和模型），OpenSpec 主打跨工具、可自由迭代、无繁琐仪式，宣称支持 25+ 种 AI 工具。截至数据采集，仓库约 50,276 stars，热度很高；项目还推出了基于产物引导（artifact-guided）的新工作流 /opsx，并有活跃的 Discord 社区。
来源：README.md（Why OpenSpec、How we compare、Supported Tools 段落）；GitHub 仓库元数据（stars=50276）每个功能变更生成独立目录，含 proposal.md（动机与改动）、specs/（需求与场景）、design.md（技术方案）、tasks.md（实现清单），让人和 AI 在编码前对齐。
来源：README.md（See it in action：/opsx:propose 输出结构）通过 /opsx:propose 创建提案、/opsx:apply 按 tasks 实现、/opsx:archive 归档并更新规格；扩展工作流还提供 /opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard 等。
来源：README.md（See it in action、Quick Start 扩展工作流段落）声称支持 25+ 种 AI 编码助手，通过 command-generation 的多个 adapter 把命令适配到不同工具；openspec update 可在每个项目内重新生成 AI 指引和最新 slash 命令。
来源：README.md（Supported Tools 提示、Updating OpenSpec）；git tree（command-generation/adapters/）强调可随时更新任意产物、无僵硬的阶段门，定位为 brownfield 友好、从个人项目到企业均可扩展。
来源：README.md（哲学段落、Why OpenSpec）支持第三方 schema 包以标准化、可分发的方式集成其它工具的工作流，并提供 customization 文档让用户自定义。
来源：README.md（Community schemas、Docs → Customization）OpenSpec 是一个 TypeScript 编写的 CLI 工具，入口在 bin/openspec.js，源码组织在 src/ 下。命令层（src/commands/）按功能拆分为 change、spec、validate、show、config、workflow、workspace 等模块；核心逻辑在 src/core/，其中 artifact-graph/ 子模块（graph、resolver、instruction-loader、state、schema 等）是新工作流的关键——它把 proposal/specs/design/tasks 等产物建模为一张有依赖关系的图，并据此驱动生成与归档。command-generation/ 下有大量 adapters（如 amazon-q 等），用于把 OpenSpec 的 slash 命令适配到 25+ 种不同的 AI 编码工具。规格本身以 Markdown 存储在项目的 openspec/changes/ 目录，每个变更一个文件夹，归档后进入 archive/。
来源：git tree（bin/、src/commands/、src/core/artifact-graph/、src/core/command-generation/adapters/、openspec/changes/ 结构）；README.md（See it in action 示例）中心为项目本体，内环 = 核心功能模块，外环 = 关键技术依赖；按 deep.json 中的 core_features 与 tech_stack.key_deps 自动生成
以 npm 包 @fission-ai/openspec 分发兼容 pnpm/yarn/bun/nixPostHog（匿名遥测，可关闭）适合希望在用 AI 编码助手时引入「先对齐规格、再写代码」纪律的团队和个人：把模糊的聊天式需求转为结构化提案，减少 AI 产出的不可预测性；在已有代码库上做功能迭代时为每个变更留下可追溯的提案/规格/设计/任务记录；在多种 AI 工具之间统一工作流（同一套 slash 命令适配 25+ 工具）；以及通过社区 schema 把规格流程与其它工具链集成。项目定位从个人项目可扩展到企业级使用。
来源：README.md（Why OpenSpec、哲学段落、Community schemas）最新发布为 v1.3.1（2026-04-21），主题是工作流产物的路径解析与遥测可靠性修复。主要修复包括：工作流产物路径改为经原生 realpath 解析，避免软链接和大小写不敏感文件系统在 apply/archive 阶段出现不匹配；修正 glob 产物输出的解析；校验现在能检测藏在代码块里的隐藏规格需求；传入 --json 时进度条不再泄漏到 stderr，便于 Agent 解析；在受限网络下吞掉 PostHog 遥测错误（1 秒超时、禁用重试/远程配置），避免 PostHogFetchNetworkError；遥测配置在 Linux 尊重 XDG_CONFIG_HOME、Windows 尊重 %APPDATA%；以及对含 glob 元字符的路径做转义。
来源：GitHub releases/latest（v1.3.1 release notes，Fixed 段落）OpenSpec 在「规格驱动开发」这一新兴方法论里选择了轻量、跨工具、可迭代的路线，相对 Spec Kit 和 Kiro 更不绑定、更易上手，加上很高的社区热度，对想给 AI 编码加一层需求约束的团队是值得尝试的选项。它的价值更多取决于团队能否真正坚持「先对齐规格再写代码」的习惯，以及搭配足够强的模型；作为工具本身，它的工程化和文档都相对完善。需要注意新旧工作流并存带来的选型成本，以及默认开启但可关闭的匿名遥测。
来源：综合 README.md（How we compare、Usage Notes）与 release notes、git tree 工程结构