在 Cursor 中使用 OpenSpec，本质上是将 规范驱动开发 的理念与 AI 编程助手的能力结合起来。它通过结构化的文档（规范、任务清单等）让 AI 在执行任务时有明确的"施工图纸"，从而减少理解偏差和返工。

整个过程可以简单概括为：装个插件，说句话，AI 就能照着图纸干活。

🚀 第一步：环境准备

在开始之前，确保你的电脑上已经安装了 Node.js 20.19.0 或更高版本。

1. 全局安装 OpenSpec CLI
   打开你的终端（在 Cursor 中可以用 `Ctrl + ` 打开内置终端），运行以下命令：

   npm install -g @fission-ai/openspec@latest
   

2. 在项目中初始化 OpenSpec
   使用终端进入你的项目根目录，然后运行初始化命令：

   openspec init
   

   ⚠️ 重要提醒：在初始化过程中，CLI 会提示你选择使用的 AI 工具，请务必选择 Cursor。 完成后，请重启 Cursor，这样才能加载新安装的斜杠命令。

🎮 第二步：核心工作流（四个斜杠命令）

OpenSpec 的核心是一个四步工作流，而 Cursor 通过四个专属的斜杠命令（Slash Commands）将它们无缝集成到了你的聊天面板中。

你只需要在 Cursor 的聊天输入框中输入以下命令，AI 就会自动接管。

命令	阶段说明	核心作用	对话示例
/opsx:propose	1. 创建提案	告诉 AI 你想做什么，它会自动生成一份结构化的变更提案（包含提案、规范、任务清单等）。	/opsx:propose 我想给项目增加一个用户登录功能，包含账号密码登录和 Google 第三方登录。
/opsx:explore	2. 探索对齐	在你和 AI 之间反复沟通，一起完善提案和规范，直到你对方案完全满意为止。	（在提案生成后）/opsx:explore 请把"记住我"这个需求也加入到规范中。
/opsx:apply	3. 执行任务	方案锁定后，执行此命令。AI 会严格对照 tasks.md 里的清单，逐项实现代码。	/opsx:apply 开始实现。
/opsx:archive	**4. 归档变更``	功能开发完成并测试通过后，执行此命令。它会将本次变更合并到主规范中，保持项目文档整洁。	/opsx:archive 登录功能已完成，请归档。

🗂️ 第三步：它究竟在管理什么？

执行上述命令后，OpenSpec 会在你的项目根目录下创建一个 openspec/ 文件夹。你可以把它理解为这个项目的"宪法库"，里面主要包含两部分：

• specs/ 目录：存放所有已完成的正式规范，是项目的"单一事实来源"，代表系统当前的状态。
• changes/ 目录：存放所有正在进行中的变更提案。当你执行 /opsx:propose 时，这里会生成一个新的变更文件夹，包含 proposal.md（提案）、tasks.md（任务清单）和 specs/（本次变更的规范增量）。

这种设计的好处是，你可以并行处理多个互不干扰的功能开发，每个功能都有自己独立的"提案-任务-规范"文档。

💎 第四步：核心优势与最佳实践

• 为何不用普通聊天？ 普通聊天时，AI 容易丢失上下文或偏离最初的需求。OpenSpec 的规范文件就像一份可执行的合同，强约束 AI 的行为，让产出更可控、更可预测。
• 和 .cursorrules 有何不同？ 两者是互补关系。.cursorrules 用于定义项目通用的编码风格、命名规范等全局规则；而 OpenSpec 用于管理具体功能需求的实现流程。
• 从小处着手：不必一开始就在整个项目中全面推行。可以从一个简单、独立的功能开始（比如创建一个新组件），体验完整的流程后再逐步推广。
• 及时归档：完成一个功能后，记得用 /opsx:archive 命令归档，避免 changes 目录下堆积过多过时的提案文件夹。

OpenSpec 为 Cursor 提供了一套从模糊想法到具体代码的工程化桥梁。虽然前期需要多写几步文档，但它能有效减少后期"改来改去"的痛苦，尤其适合中大型项目或多人协作场景。

与OpenSpec类似的工具还有哪些？

与 OpenSpec 处于同一赛道的工具已经形成了一个相当丰富的生态。它们都致力于解决同一个核心问题：如何让 AI 不只是一个随性的聊天对象，而是一个遵循工程规范、产出可靠的“结对程序员”。

这些工具的核心思想类似，但在工作流的严格程度、适用的项目阶段（新建项目 vs. 维护老项目）以及具体的使用体验上各有侧重。为了让你能更清晰地做选择，这里将主流的工具分成了几个流派来介绍。

🧭 主流工具速览与对比

工具名称	核心定位与特点	适用场景	与 OpenSpec 的异同
OpenSpec	规范驱动开发的标杆。流程清晰（提案→探索→执行→归档），社区非常活跃。	功能迭代、中大型项目，尤其适合需要在已有代码库上（棕地开发）清晰管理变更的场景。	基准。它是这个理念的开创者之一。
LightSpec	OpenSpec 的轻量化分支。流程更简化，对新手更友好。	希望体验 SDD 但觉得 OpenSpec 稍显复杂的个人开发者或小团队。	更轻量、上手更快，但生态和社区规模相对较小。
GitHub Spec-Kit	GitHub 官方出品，开源参考实现。工作流更严谨，分“宪章→指定→计划→任务”四步。	严格遵循规范的企业级项目，尤其是希望与 GitHub 生态深度集成的团队。	流程更厚重，规范性更强；OpenSpec 相对更灵活。
Kiro	亚马逊云科技 (AWS) 推出，三阶段工作流（需求→设计→任务）。	AWS 用户，或需要一个步骤极其清晰、引导性强的规范流程的团队。	流程固定，类似向导，易于上手；OpenSpec 的工作流更自由。
Superpowers	一个“代理技能框架”，强调让 AI 默认遵循工程纪律。不是单一流程，而是一套技能包。	希望全面提升 AI 代码质量、进行代码审查、保持架构整洁的严肃开发者。	更像一个 “纪律强化” 插件，可与 OpenSpec 等流程工具配合使用。
CoStrict (严肃编程模式)	深信服开源，专为企业级内网开发设计。严格遵循“项目反推→需求澄清→设计→任务拆解→测试自修复”流程。	对代码安全、私有化部署和代码质量有极高要求的企业。	企业级定位，内置安全与质量卡点，支持私有化部署。

🌟 值得关注的新选手

除了上述主流工具，还有一些新兴工具也很有特色：

• cc-sdd：这是一款日本开发的工具，最大的特点是完美兼容 Kiro 的工作流逻辑，并对日语环境有极佳支持。如果你的团队偏好 Kiro 式的严谨步骤，又希望有更好的本地化体验，可以关注它。
• Trellis / OMC (Oh-My-OpenCode)：社区讨论中高频出现的“体系型方案”。
  • Trellis 更像一个长期的工作流骨架，将规范、任务、工作空间统一管理。
  • OMC 则致力于将 Claude Code 组织成一个团队式的执行系统。
  • 它们代表了比单一流程更宏大的构想，目前处于社区活跃演进中。

🤔 如何选择适合你的那一款？

选择哪种工具，取决于你的具体需求和团队的“气质”：

1. 追求轻量与快速上手：如果你觉得 OpenSpec 稍显复杂，或者只想先简单体验一下 SDD 的理念，可以从 LightSpec 开始。

2. 需要最强规范与确定性：如果你的项目非常庞大、严谨，并且已经深度使用 GitHub 或 AWS，那么 GitHub Spec-Kit 或 Kiro 是值得考虑的选项。它们提供了更“重”但更确定的流程。

3. 用于企业内网，安全第一：如果你身处金融、政务等对代码和数据安全要求极高的行业，CoStrict 的私有化部署和“严肃编程”模式可能是唯一的选择。

4. 想优化 AI 的工程纪律：如果你已经有了一套工作流，但觉得 AI 生成的代码质量还不够“专业”，可以尝试将 Superpowers 作为补充，为你的 AI Agent 注入“工程师思维”。

5. 拥抱社区与未来：如果你喜欢尝鲜，不介意工具仍在快速演进，那么可以关注 Trellis、OMC 等社区驱动的新兴方案，它们往往代表了下一代 Harness 的发展方向。

💎 总结：不是选择题，而是组合题

最后想分享一点社区中的普遍看法：这些工具并不是非此即彼的选择题，而更像是一道组合题。

• 你可以用 OpenSpec 或 Spec-Kit 来管理工作流和规范。
• 同时，用 Superpowers 来强化 AI 在每个环节的“工程素养”。
• 甚至，参考 CoStrict 的思路，在你的 CI 流程中加入自动化的质量卡点。

另外需要留意的是，这些工具发展非常迅速，有些还在快速迭代中，建议在正式采用前先在小项目中试用，找到最适合团队节奏的组合。

你是主要用于个人项目，还是需要引入团队协作？告诉我你的具体场景，我可以帮你推荐最适合上手的那一款。