在 AI 辅助编程时代，我们常常面临一个痛点：当你让 AI 开发一个复杂功能时，它一开始表现得很聪明，但随着对话轮数的增加，它开始遗忘上下文、偏离需求，最终陷入胡乱猜测的**“直觉编程” (Vibe Coding)** 陷阱。

为了解决这个问题，Fission-AI 推出了轻量级的规范驱动开发工具 —— OpenSpec。它可以在你写下第一行代码前，通过规范（Specs）让人类与 AI 达成共识。

今天，我们将基于官方最新的 workflows.md 文档，为你深度解析 OpenSpec 的核心理念与实战工作流。👇

---

🧠 核心哲学：行动而非阶段 (Actions, not phases)

传统软件工程的工作流往往是死板的瀑布流：规划 ➡️ 实施 ➡️ 完成。你被困在僵化的“阶段”里，一旦进入开发阶段，想回头改需求就变得无比沉重。

OpenSpec 采取了截然不同的敏捷哲学：

• 行动而非阶段：诸如 /opsx:propose 或 /opsx:apply 的斜杠命令，是你随时可以执行的行动，而不是困住你的阶段限制。
• 依赖是赋能者：文档间的依赖关系只是告诉你“下一步可能做什么”，而不是限制你“必须做什么”。你可以在实施的过程中随时退回去修改设计，工作流是极度流动的。

---

🗺️ 核心工作流：从探索到归档

OpenSpec 的核心工作流（Core Profile）主要由四个强大的斜杠指令组成。

1. 💡 探索问题空间 (/opsx:explore)

适用场景：当你有一个想法，但具体需求或技术路线还不明确时。

在要求 AI 提交变更之前，先让它为你做调研：

🧑 你: /opsx:explore 我们应该如何处理 API 的速率限制？
🤖 AI: 你想探索什么？让我调查你当前的设置...
[研究代码库后...] 我看到我们可以采用三种方法：
1. 基于中间件（简单，按端点）
2. Redis 支持（可扩展，适合多节点）
根据你的堆栈，推荐方案 1。你的系统目前规模如何？

通过这种对话，你可以在生成任何代码或文档前，彻底理清思路。

2. 📝 提出变更方案 (/opsx:propose)

当思路明确后，就可以让 AI 将想法转化为严谨的规范制品 (Artifacts)。

🧑 你: /opsx:propose add-rate-limiting
🤖 AI: 正在创建所有规划制品...
✓ proposal.md （动机与目标）
✓ specs/ （核心需求与验收场景）
✓ design.md （技术架构与决策）
✓ tasks.md （实施任务的原子化清单）
准备实施！

🔍 制品生成的严格依赖链：
在 OpenSpec 的设计中，制品的生成是有严格逻辑顺序的：

注：AI 必须先理解动机 (proposal)，再确立需求 (specs)，接着构思技术实现 (design)，最后才能拆解出代码编写清单 (tasks)。

3. 🛠️ 逐步实施 (/opsx:apply)

这是 AI 真正开始写代码的阶段。此时，AI 不再是依靠不可靠的对话记忆，而是严格按照上一步生成的 tasks.md 逐行打勾。

🧑 你: /opsx:apply
🤖 AI: 正在处理任务...
✓ 1.1 添加速率限制中间件
✓ 1.2 配置 Redis 连接逻辑
✓ 2.1 编写单元测试
所有任务完成！

4. 📦 验收与归档 (/opsx:archive)

代码编写完成并测试通过后，你需要进行归档操作。这类似于 Git 的 Merge 操作，但它是针对项目规范的合并。

🧑 你: /opsx:archive
🤖 AI: ✓ 已将增量规范同步到全局的 openspec/specs/ 目录中
✓ 已将变更移至 openspec/changes/archive/2026-xxx/
变更已成功归档。

归档操作确保了项目的“真理之源 (Source of Truth)”永远是最新的。未来的 AI 在处理新需求时，会读取这份全局 Spec，从而完美理解现有的项目架构。

---

👑 工作流最佳实践

在 workflows.md 中，OpenSpec 官方强烈推荐了以下实战技巧：

📌 每个变更一个逻辑工作单元

如果你打算“添加认证功能 X” 并且 “重构页面 Y”，请务必使用两次 /opsx:propose 创建两个独立的变更。

• 为什么重要？ 这样更易于审查，历史记录更清晰。如果你发现“功能 X”有 Bug，你可以轻松回滚，而不必牵连“页面 Y”的重构工作。

🔄 何时“更新” vs 何时“重新开始”？

很多人常常困惑：我是该修改现有的变更，还是新开一个变更？

• 🟢 更新现有变更（直接修改 Markdown 文件）：
  • 核心意图相同，但需要优化技术执行（比如换了个第三方库）。
  • 范围缩小（决定先做一个 MVP 版本，剩下的以后再做）。
  • 在实施阶段 (apply) 发现了预期外的代码库限制，必须调整设计。
• 🔴 重新开始（Archive 后开启新 Propose）：
  • 业务意图发生了根本性变化。

---

⚡ 扩展工作流：为进阶团队准备 (Expanded Workflows)

为了不占用过多大模型的上下文 Token，OpenSpec 默认只加载上述四个核心指令。如果你使用的是 OpenSpec v1.2.0+ 并且在配置中开启了 profile: custom，你将解锁更强大的扩展工作流：

• 🛡️ /opsx:verify (验证)：在 apply 完成后，让 AI 结合生成的 spec.md 主动运行验证脚本，确保每一行代码都符合当初设定的验收标准。
• ⏭️ /opsx:ff (Fast-forward)：一次性快速推进从提案到任务拆解的流程。
• 📂 /opsx:bulk-archive (批量归档)：当你同时推进了多个无冲突的小变更时，可以一次性批量同步合并所有规范。

---

结语：让 AI 成为真正的“工程师”

OpenSpec 就像是一个敏捷的脚手架。它通过轻量级的规范文档，取代了过去我们在 Notion 或碎纸片上记录的需求，把它们直接喂给了 AI。

使用 OpenSpec，AI 不再是那个“你推一下它动一下、还老容易跑偏”的代码补全器，而是一个会先思考、会写方案、会拆分任务、并且每做完一步还会“打钩”的成熟工程师队友。

💡 准备好体验规范驱动开发了吗？
在你的终端运行：npm install -g @fission-ai/openspec@latest，然后在项目中 openspec init，即刻开启你的 SDD 编程之旅吧！

---

版权声明：本文基于 Fission-AI/OpenSpec - docs/workflows.md 创作，图片通过 Markdown 流程图实现排版优化。