85 lines
3.9 KiB
Markdown
85 lines
3.9 KiB
Markdown
# 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 集成
|