3.9 KiB
3.9 KiB
OpenSpec + Superpowers workflow orchestrator（OpenFlow）：连接需求与工程的工作流编排器
来源： 微信公众号 - 幽人 作者： 幽人 日期： 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
解决的问题
- 需求模糊：用户说"做一个贪吃蛇游戏"，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 个），把用户脑子里的需求变成可执行的变更描述：
- 做什么 — 想实现什么功能/变更？
- 为什么 — 解决什么问题？给谁用的？
- 成功标准 — 怎样算做完了？验收条件？
- 边界 — 什么不在范围内？
- 现有约束 — 技术栈、兼容性、时间上的限制？
输出格式：proposal.md
Spec 阶段：从 proposal 到可执行规格
将 proposal 升级为完整的规格文档，包含详细的功能描述、数据结构、API 设计、组件树等。最终产出包括：
design.md— 完整设计文档specs/目录 — 规格细节（包含详细的 spec 和plan-ready.md）tasks.md— 任务清单（含依赖关系和验收标准）
Build 阶段：自动执行实现
关键概念是任务沙箱（task sandbox）：
- 每个 task 从 tasks.md 中被抽取到一个独立的
.snapshot/沙箱 - 沙箱内包含：任务描述、相关规格、类/方法骨架、依赖说明
- 为每个 task 生成独立的 context（LLM 上下文隔离，避免信息过载）
Close 阶段：验证与归档
verify子命令：对照 tasks.md 验证每个任务的实现状态和格式一致性close归档：将 changes 目录中的内容归档到当前项目的changes/
编排 vs 工具绑定
OpenFlow 与其他方案的区别：
- 不是将 Cursor/Claude Code/Codex 等工具与工作流深度绑定
- 而是在每个阶段生成描述性的 prompt 和产出，让各阶段的 AI Agent 可以看懂指令并产出对接产物
- 靠文件格式（统一的 markdown 规范）打通各阶段，而不是靠 API 集成