MMaoHomeArchivesTags思所读书关于相册GTD
FlowKit - Flow-Deep 深度管道

Flow-Deep 是 FlowKit 的全量深度引擎，所有质量关卡不可跳过，适用于复杂/重要/高风险任务。
本文是 FlowKit 系列教程第五篇（最终篇）。

GitHub: FrizzleFur/flowkit | 系列导航

目录

与 Flow 的核心差异

Flow-Deep 定位为高风险任务的”保险模式”。与 /flow 相比，核心区别在于不可跳过：

维度 /flow /flow-deep
前置检查 无 强制 — 能力发现 + 环境检查
深度思考 可选 (--think) 强制 — ST + Mermaid + 三角色讨论
Plan Mode 默认开，可关闭 不可关闭
Plan Review 可选 强制 — 独立 Agent 审查
多角色面板 无 强制 — 3-5 角色并行评审
TDD 注入 可选 自动注入
完成验证 可跳过 不可跳过
Ralph Loop 手动触发 迭代用完自动触发

没有 –quick 预设。Flow-Deep 不允许快速跳过任何阶段。

Stage 0: Superpowers 前置检查

为什么需要前置检查？ 复杂任务需要完整的工具链。在开始之前确认所有能力可用，比执行到一半发现缺少依赖要好得多。

能力发现

扫描 ~/.claude/skills/ 目录，与已知能力索引交叉比对，生成”可用能力矩阵”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
能力矩阵:
  必需依赖:
    /prompt           ✓
    planning-with-files ✓
    /multi-agent       ✓
    using-superpowers  ✓

  Superpowers 技能:
    TDD               ✓ (自动注入)
    writing-plans     ✓
    code-review       ✓
    parallel-dispatch ✓
    verification      ✓ (强制)

  迭代增强:
    auto-iterate      ✓ (Stage 5.5)
    ralph-loop        ✗ (未安装，Stage 5.7 降级)

Stage 2: 强制深度思考

Flow-Deep 中 Stage 2 默认全开，包含三个组件：

Sequential Thinking（结构化思考）

覆盖 6 个维度：

  1. 任务分解 — 拆分为可管理的子任务
  2. 依赖分析 — 识别子任务间的依赖和阻塞
  3. 风险评估 — 技术风险、时间风险、集成风险
  4. 资源需求 — 需要哪些工具、文件、API
  5. 执行策略 — 并行/串行、分阶段、回退计划
  6. 能力规划 — 匹配可用能力到每个 Phase

Mermaid 可视化

生成任务结构的可视化图表。

三角色讨论

根据任务类型自动选择三个最相关角色，两轮讨论后综合最佳方案。

Stage 3.5: 强制 Plan Review

独立 Agent 审查，消除沉没成本偏差。

审查以 Staff Engineer 角色进行 6 个维度：

  1. 架构合理性
  2. 遗漏边界情况
  3. 安全风险
  4. 性能影响
  5. Plan 假设验证
  6. 可执行性

返回 APPROVED / APPROVED_WITH_NOTES / NEEDS_REVISION，用户最终决策。

Stage 3.6: 多角色面板评审

“Design Review Board” — 多视角交叉验证，消除单角色盲区。

工作流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1. 角色选择（根据任务类型自动匹配 3 个角色）
      │
      ▼
2. 并行评审（3 个角色同时审查 Plan）
      │
      ▼
3. 综合分析
   - 识别重叠问题（2+ Agent 提到 → 高优先级）
   - 识别角色间分歧（标记为 Taste Decision）
      │
      ▼
4. Auto-Decide Layer（6 原则自动分类）
      │
      ▼
5. Final Approval Gate（只展示需要用户决策的内容）

Auto-Decide Layer — 6 原则

1
2
3
4
5
6
7
8
P1 · 行业标准     → 违反 → 自动修复 (AUTO_FIX)
P2 · 风险阈值     → 高风险修复 / 低风险通过
P3 · 一致性       → 与已有一致 → 自动通过 (AUTO_APPROVE)
P4 · YAGNI        → 过度设计 → 上浮给用户 ⚖️
P5 · 安全优先     → 安全相关 → 自动修复
P6 · 不可逆性     → 不可逆 → 上浮给用户 ⚖️

结果: 80% 自动处理（静默），只有 < 5 条 Taste Decision 需要人工

为什么这很重要？ 传统代码审查面板产生 20+ 条发现，全部人工判断会淹没用户。Auto-Decide 把 80% 的常规发现自动处理，只上浮真正需要品味决策的内容。

STATE.md 跨会话恢复

这是社区框架中均未出现的原创能力。

问题

长任务（5+ 阶段）中，Claude Code 会话可能因上下文溢出等原因中断。传统做法是从头开始。

解决方案

管道内置崩溃恢复机制。每个阶段完成后，写入 .plan/STATE.md：

1
2
3
4
5
6
7
8
9
# STATE.md 活记忆
current_stage: 4
current_phase: 2
completed_phases: [1, 2]
progress: 65%
next_action: "Stage 5 完成验证"
key_decisions:
  - "选择 JWT 而非 Session（无状态，易扩展）"
  - "分两阶段执行（core+gateway 并行 → test 串行）"

恢复流程

1
2
3
4
5
6
7
8
9
10
11
12
13
会话在 Stage 4 Phase 2 中断
        │
        ▼
新会话读取 .plan/STATE.md
        │
        ▼
展示: "上次停在 Stage 4 Phase 2 (65%)"
        │
        ▼
用户选择: 恢复 / 重新开始
        │
        ▼
从断点精确恢复，继续执行

Stage 5.5: 自主迭代引擎

触发条件: --iterate N 参数 或 Stage 5 验证未达标

核心协议: keep/revert

1
2
3
4
5
6
7
8
每轮迭代:
  1. 分析失败原因
  2. 做一个最小变更
  3. commit 变更
  4. 运行验证
  5. 通过 → keep（保留变更）
     失败 → revert（撤销变更，回到上一轮）
  6. 记录 TSV 历史（追踪每次迭代的结果）

关键纪律: 每次只改一个东西。不是”大改”，而是”最小变更”。

渐进式 Guard 策略

1
2
3
4
5
早期（1-3 轮）: 冒烟测试（快速验证基本功能）
中期（4-6 轮）: 集成测试（验证模块间交互）
后期（7+ 轮）: 全量测试（完整回归测试）

为什么？全量 guard 太早会扼杀创新方向探索。

Stage 5.7: Ralph Loop 强制持续

触发条件: Stage 5.5 迭代用完仍未达标 + Ralph Loop 插件已安装

与 auto-iterate 的关系

1
2
3
4
5
6
7
8
9
auto-iterate: "怎么迭代" — 应用逻辑层
  - 结构化 keep/revert 循环
  - TSV 历史追踪
  - stuck strategy

Ralph Loop: "不让你停" — 会话控制层
  - Stop Hook 拦截会话退出
  - 注入固定 prompt
  - 强制持续直到达标

两者是互补而非替代。Ralph Loop 在 auto-iterate 外层包裹”不达目的不罢休”的强制机制。每轮 Ralph 迭代内部调用的还是 auto-iterate 的 keep/revert 协议。

工作流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Stage 5.5 迭代 N 轮仍未达标
        │
        ▼
Ralph Loop 通过 Stop Hook 拦截退出
        │
        ▼
注入固定 prompt（含历史摘要）
        │
        ▼
每轮 Ralph 迭代:
  1. 从 progress.md 读取最新状态
  2. 执行 auto-iterate 的 keep/revert
  3. 运行 Stage 5 验证
  4. 达标 → 输出 <FLOW_DEEP_COMPLETE> 退出
     未达标 → 继续下一轮

降级方案: Ralph Loop 插件未安装时，提示用户手动重启 auto-iterate。

完整使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/flow-deep 重新设计支付系统，支持多币种

→ Stage 0: Superpowers 前置检查
   /prompt ✓ | planning-with-files ✓ | /multi-agent ✓
   TDD ✓ | code-review ✓ | auto-iterate ✓ | ralph-loop ✗

→ Stage 1: Prompt 优化
   原始评分: 6.5/10 → 优化后: 8.2/10

→ Stage 2: 深度思考（强制）
   ST 6维度分析 + Mermaid 架构图 + 三角色讨论（架构师/支付专家/SRE）

→ Stage 3: Plan Mode（不可跳过）
   Phase 1: 核心模块重构（支付核心 + 多币种转换）
   Phase 2: 网关集成（Stripe/PayPal/支付宝）
   Phase 3: 测试 + 安全审计

→ Stage 3.5: Plan Review（强制）
   独立 Agent 审查 → APPROVED_WITH_NOTES
   建议: 增加 Phase 2.5（灰度发布方案）→ 用户采纳

→ Stage 3.6: 多角色面板评审
   3 角色（支付专家、安全工程师、架构师）并行评审
   Auto-Decide: 15 项发现 → 12 项自动处理 + 3 项 Taste Decision
   用户确认 → 采纳 2 项，驳回 1 项

→ Stage 4: 并发执行（TDD 注入）
   Phase 1: core Agent + gateway Agent 并行（TDD 模式）
   Phase 2: security Agent 审查
   Phase 3: test Agent + docs Agent 并行

→ Stage 5: 完成验证（不可跳过）
   128 个测试全部通过 ✓
   覆盖率 87% ✓
   性能基准: P99 < 150ms ✓

→ Stage 5.5: 迭代优化
   Stage 5 全部达标 → 跳过

→ 完成

系列导航

FlowKit 系列教程

# 文章 内容
1 总览：AI 原生工作流编排的设计哲学 动机、架构、Iron Laws、社区对比
2 Prompt 量化评分：乔哈里视窗 x 3S 原则 四象限、3S、7维评分、第四象限陷阱
3 Multi-Agent 协作：tmux 分屏并行引擎 角色匹配、文件隔离、Phase复用
4 Flow 轻量编排：5 阶段管道按需启用 Stage流程、Plan Mode、Fallback协议
5 Flow-Deep 深度管道：全量质量保障引擎 Plan Review、Auto-Decide、STATE.md、Ralph Loop

FlowKit 使用 MIT 协议开源。如果对 AI Agent 工作流编排感兴趣，欢迎 Star 和交流。

文章作者: MichaelMao
文章链接: http://michaelmaomao.github.io/2026/06/02/FlowKit-Flow-Deep%E6%B7%B1%E5%BA%A6%E7%AE%A1%E9%81%93/
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 MMao！
AIAgentClaude Code开源
我要吐槽下