Appearance
与竞品对比
诚实的声明
OpenFlow 不是最快的 AI 工作流，也不是最轻量的。它不会把"5 分钟开始写代码"作为第一目标。
它解决的是另一类问题：让 AI 写的每一行代码都有据可查——改了什么、为什么改、怎么证明改对了、改完之后知识保存在哪里。
如果你的目标是一次性 Demo，OpenFlow 可能显得过重；如果你希望 AI 不只是写代码，还能留下设计记录、验证证据和可追溯的历史，OpenFlow 的治理成本才有意义。
OpenFlow 适合什么场景
很多人以为 OpenFlow 只适合老项目维护，其实不是。只要你的项目需要"AI 改了什么，必须说得清楚"，OpenFlow 就有用武之地。
从零到一的新项目
新项目不代表可以随便写。需求模糊、方案未定、边界不清——这些问题在新项目里一样存在。OpenFlow 的头脑风暴和需求澄清阶段，正好帮你在写代码之前把问题想清楚。
而且新项目的早期决策往往影响深远。OpenFlow 的架构决策记录（docs/decisions/）和归档追溯，让项目从一开始就有清晰的设计历史，而不是三个月后没人知道"当时为什么选了这个方案"。
多人协同开发
多人使用 AI 开发时，最怕的不是代码冲突，而是上下文丢失——A 昨天让 AI 改了某个模块，B 今天完全不知道这回事，又让 AI 改了一版。
OpenFlow 用文档结构解决这个问题：所有人的变更都记录在 docs/changes/ 里，完成后的设计事实沉淀在 docs/current/ 里，决策依据保存在 docs/decisions/ 里。换人、换 Agent、换窗口，项目知识不会丢。
存量项目维护
这是 OpenFlow 最初设计的场景。存量项目有历史包袱、生产约束、遗留行为，AI 稍不注意就会改错东西。OpenFlow 用文档契约约束 AI 的可行动范围，用质量门确保改动可验证，用漂移检测防止实现偏离设计。
一人多项目
一个人维护多个项目时，上下文切换是最大的成本。OpenFlow 的文档结构让每个项目都有独立的"记忆体"——docs/current/ 保存当前状态，docs/archive/ 保存历史决策。切到任何一个项目，AI 都能快速了解系统现状和约束边界。
与 OpenSpec 的关系
OpenFlow 的工作流深受 OpenSpec 启发——文档治理、归档追溯、行为约束这些核心理念，OpenSpec 已经提出了很好的方案。可以说，OpenFlow 是在 OpenSpec 的思路基础上，选择了不同的实现路线。
OpenSpec 是一个纯 Skill：它把工作流规则写进 AI 的指令中，靠 AI 自觉遵守。如果 AI 跳过了某个步骤、忽略了某条约束，系统本身无法阻止。它的优势是适配范围广——几乎支持所有 AI 编辑器，不依赖特定平台。
OpenFlow 是一个可执行的 Node.js 程序：它在 AI 的外部设立程序级门禁——质量门、漂移检测、归档拦截、合约扫描——这些检查由代码强制执行，AI 想跳也跳不过。代价是更垂直——深度依赖 OpenCode 平台。
简单来说：OpenSpec 信任 AI 会遵守规则，追求广度；OpenFlow 用程序确保 AI 必须遵守，追求深度。
定位差异表
| 维度 | OpenSpec（纯 Skill） | OpenFlow（Node.js 程序） |
|---|---|---|
| 实现方式 | AI 指令层，靠提示词和 Skill 约束行为 | 程序级门禁，由代码强制执行规则 |
| 规则严格度 | AI 自觉遵守，跳过时无强制拦截 | 质量门、归档拦截、漂移检测由程序强制，更严格 |
| 平台适配 | 几乎支持所有 AI 编辑器，广度优先 | 深度依赖 OpenCode 平台，垂直优先 |
| 深度能力 | 规格驱动执行，核心工作流完整 | 在核心工作流基础上，增加了 AI 反思、金字塔原理编程、设计模式、文档漂移检测、BDD、TDD、代码地图等深度机制 |
| 完成定义 | AI 判断完成 | 质量门通过并完成归档 |
更准确的说法不是"OpenFlow 替代 OpenSpec"，而是：
- OpenSpec 适合追求轻量接入、使用多种 AI 编辑器、信任 AI 自治的团队。
- OpenFlow 适合使用 OpenCode、需要程序级强制保障、追求更严格治理深度的项目。
总结
选择工具的关键不是"哪个更先进"，而是你需要多深的治理。
- 如果你需要广度——在多种编辑器中使用、快速接入、信任 AI 自治——OpenSpec 更合适。
- 如果你需要深度——程序级强制门禁、AI 反思、漂移检测、TDD/BDD 等深度机制——OpenFlow 更适合。
OpenFlow 用垂直深度换取更强的工程确定性。它适合那些"写代码不是最难，确保 AI 按规矩办事才最难"的项目。