# OpenSpec + Superpowers workflow orchestrator（OpenFlow）：连接需求与工程的工作流编排器

**来源：** [微信公众号 - 幽人](https://mp.weixin.qq.com/s/8PT7nlj-Jcu8Xa6lwyApYQ)
**作者：** 幽人
**日期：** 2026年5月15日 11:12
**标签：** #OpenFlow #OpenSpec #Superpowers #工作流编排 #AI编码

---

## 核心定位

> OpenSpec + Superpowers workflow orchestrator — bridging requirements specs and engineering execution, eliminating the format gap.

**OpenFlow 是连接需求规格与工程执行的工作流编排器**，消除两者之间的格式鸿沟。它是一个 npm 全局包（`@lininn/openflow`），纯粹作为一个独立的**编排层**，不嵌入 OpenSpec 或 Superpowers 的代码。

GitHub: [lininn/openflow](https://github.com/lininn/openflow)

### 解决的问题
- **需求模糊**：用户说"做一个贪吃蛇游戏"，AI 需要自行猜测技术栈、复杂度、边界条件
- **规格缺失**：没有结构化的设计文档，代码写到一半发现需求变了
- **进度不明**：做到哪里了？哪些功能已完成？哪些待验证？
- **验收困难**：如何确认代码实现了设计？设计变更是否同步到代码？

---

## 核心架构

- **技术栈**：TypeScript（98.6%），npm 全局包
- **核心依赖**：OpenSpec（结构化规格生成）+ Superpowers（实现规划与执行）
- **目录结构**：CLI 优先 + 模板驱动 + 平台兼容（.claude/ 技能 + .omc/ 会话存储）

### 双层依赖检测机制
**优雅降级策略** — 不强制依赖 OpenSpec 或 Superpowers：
- Init 时检测：检测缺失 → 引导安装，但技能文件仍然生成
- 运行时检测：Build 阶段发现缺失时自动降级为手动步骤执行

核心理念：**让工具先能用，再逐步完善。**

---

## 五阶段工作流

| 命令 | 阶段 | 描述 |
|------|------|------|
| `/openflow proposal` | proposal | 轻量需求捕获 — 3-5 个问题快速收敛需求 |
| `/openflow brainstorming` | brainstorming | 深度设计 — 多轮权衡探索 |
| `/openflow spec` | spec | 生成规格 + 自动翻译为 plan-ready.md |
| `/openflow build` | build | 执行实现（调用 Superpowers） |
| `/openflow close` | close | 验证一致性 + 归档 |

### Proposal 阶段：需求的起点
用最少的提问（3-5 个），把用户脑子里的需求变成可执行的变更描述：
1. **做什么** — 想实现什么功能/变更？
2. **为什么** — 解决什么问题？给谁用的？
3. **成功标准** — 怎样算做完了？验收条件？
4. **边界** — 什么不在范围内？
5. **现有约束** — 技术栈、兼容性、时间上的限制？

输出格式：proposal.md

### Spec 阶段：从 proposal 到可执行规格
将 proposal 升级为完整的规格文档，包含详细的功能描述、数据结构、API 设计、组件树等。最终产出包括：
- `design.md` — 完整设计文档
- `specs/` 目录 — 规格细节（包含详细的 spec 和 `plan-ready.md`）
- `tasks.md` — 任务清单（含依赖关系和验收标准）

### Build 阶段：自动执行实现
关键概念是**任务沙箱**（task sandbox）：
1. 每个 task 从 tasks.md 中被抽取到一个独立的 `.snapshot/` 沙箱
2. 沙箱内包含：任务描述、相关规格、类/方法骨架、依赖说明
3. 为每个 task 生成独立的 context（LLM 上下文隔离，避免信息过载）

### Close 阶段：验证与归档
- `verify` 子命令：对照 tasks.md 验证每个任务的实现状态和格式一致性
- `close` 归档：将 changes 目录中的内容归档到当前项目的 `changes/`

---

## 编排 vs 工具绑定

OpenFlow 与其他方案的区别：
- **不是**将 Cursor/Claude Code/Codex 等工具与工作流深度绑定
- **而是**在每个阶段生成描述性的 prompt 和产出，让各阶段的 AI Agent 可以看懂指令并产出对接产物
- 靠**文件格式**（统一的 markdown 规范）打通各阶段，而不是靠 API 集成