Flow-Next是一款面向编码智能体（Claude Code、Codex、Cursor 等）的工作流插件：给它一个 bug、想法或工单，它会一路走到经过验证的 Pull Request。它内置了跨模型审查、Live QA、追踪器同步等能力层——但这些层全部可选。本指南帮你搞清每一层的"结构性成本"，按需开启，避免为用不上的功能持续付费。

先搞清"成本"结构：你在为什么付费

Flow-Next 本身是 MIT 许可的本地插件，不需要账号或托管服务。真正的开销来自你的智能体使用量：

关键认知（官方文档称之为"可选性警告"）：当你坐在键盘前时，你就是审查者、追踪者和 QA——此时开启这些层买的是"便利"，只有便利值回票价才值得；而无人值守运行时，这些层就是"未审查代码"与"合并"之间唯一的屏障，关掉它们才是风险。

💡 完整定义见官方文档：running-lean.md

三个可选层速查：默认值与手动调用

以下默认值来自已发布的配置模式 flow-config.schema.json，可用flowctl config get <key>查看自己的配置：

原则一句话：默认精简运行，哪层缺了再开哪层；或者干脆保持关闭、需要时手动调用。

跨模型审查层：只在风险配得上时开启

review.backend未设置时，审查在宿主智能体内进行。设置后端后，你会拿到一个没有写过这份 diff 的模型家族的裁决——审查者的盲区与作者不相关，这正是自主运行最需要它的原因。

成本是结构性的：每轮审查是一条流水线都要等待的串行通道。官方实测中，大/高风险范围的首轮审查会扇出 3 个并行的"轴抽取"（correctness / contracts / integration），再合并成一次修复通过——用并行审查换串行修复轮次。

两档"拧旋钮"设置，对应不同画像：

• flowctl config set review.backend host：保留全部门控，但审查者改为宿主原生的"新上下文子智能体"，无需安装/认证第二个 CLI。
• review.backend none：直接关掉审查门控。每个后端驱动的审查都会干净跳过。适合"我自己逐行读 diff"的人；对无人值守循环是错误设置。

小 diff 省成本还有更细的旋钮：在调用时说明"只用 1 个审查者而不是 3 个"，即可把首轮收敛为单次抽取（这是 prose 指令，不是配置项）。详见 orchestration.md。

何时值回票价：diff 由智能体编写、且将在没有人逐行阅读的情况下合并——即自主画像的定义场景。

Live QA 层：跑起来的应用换"有据可查的发现"

pipeline.qa默认off，但 skill 始终可用，用flowctl config set pipeline.qa <off|on|auto>设置。

• 它自动化了什么：像真实用户一样驱动运行中的应用，对照 spec 验收标准，在人类打开 PR 之前就归档"有证据的发现"。
• 成本：每个 spec 一次实跑驱动 + 一个可供指向的部署 + 一个需要持续维护的驱动器。设为on且作为flow --auto的阶段时，它位于"全部任务完成"与 make-pr 之间——每个 spec 都要付这笔钱。
• 值回票价时：没有人会在合并前手动验证应用（自主运行的常态），或变更是 UI/运行时形态、测试根本看不到该失效模式。
• 精简调用：/flow-next:qa <spec>。如果你刚构建完功能、应用已在本地跑着，你自己就是那次 Live QA——skill 的价值在于把发现写成证据，而不是"注意到就忘了"。

细节见 flow-next-qa 技能文档。

追踪器同步层：团队在 Linear/GitHub/Jira 里生活时才开

tracker.enabled默认off。开启后，spec 会双向同步到 Linear / GitHub / GitLab / Jira 的 issue——正文、状态、评论都在追踪器里实时可见，PM 和同事无需切换工具。

• 成本：每个启用的生命周期事件一次双向往返；一条你必须表态的冲突策略（tracker.conflictTiebreak）；以及"状态可能在第二个地方出错"。每多开一个tracker.perEvent.*键，就给每个 spec 的生命多一个同步点。
• 值回票价时：仓库外的人（PM、干系人）需要在他们的工作地读写状态；或追踪器键是你并行智能体的分布式 ID 分配器。
• 精简调用：/flow-next:tracker-sync按需推送一次——需要别人看到的那一刻推到追踪器，其余时间桥保持关闭。"仅 spec"模式是一等公民，不是降级模式：spec 始终是事实源。

⚠️ 注意区分：/flow-next:tracker-sync（外部追踪器桥）≠/flow-next:sync（plan-sync，更新下游任务 spec）。详见 tracker-sync.md。

顺手了解：Plan-sync 层（4.5.1 起默认关闭）

planSync.enabled在每个任务完成后跑一次"对账"，让下游任务锚定真实情况而非当初的假设——但它通常什么都发现不了，所以官方干脆改为默认关闭。多个相互依赖的任务、实现确实偏离计划时，再用flowctl config set planSync.enabled true开启，或手动跑/flow-next:sync保留完整能力。

精简运行依然留痕：收据让"没跑"可审计

关闭某层不等于"无声消失"。每个编排阶段都会把结果记为ran、skipped(原因)或failed(原因)，写入收据：

flowctl usage --stages <spec-id> # 人类可读 flowctl usage --stages <spec-id> --json # 机器可读

"QA 关闭因为这是无实时界面的 CLI 变更"和"QA 从没跑过、没人知道为什么"——两者的差别在收据里一目了然，而不是靠记忆重构。PR 正文同样会展示每条验收标准（R-ID）的覆盖表与证据链接：

两种操作画像：选对你的姿态

两者都不是"真正的模式"——它们只是同一个问题的两个答案：每次交接时，谁来行使判断？画像按运行选择，不按团队或仓库：同一个仓库可以昨晚自主清空积压，今早做一笔精简的人工驱动变更。

快速清单：3 个决定，按需开启

1. 审查：自己逐行读 diff →none；要独立裁决但零安装 →host；智能体写码无人逐行读 → 完整后端。
2. QA：合并前没人手动验证应用，或测试看不到 UI/运行时失效 → 开；否则用/flow-next:qa <spec>按需跑。
3. 追踪同步：仓库外的人需要在 Linear/GitHub/Jira 看状态 → 开；否则/flow-next:tracker-sync手动推。

更多路线选择（Epic、无计划路线、Bug、重构、性能……）见 pipeline-variations.md；各模型分工与路由见 orchestration.md。

一句话总结：Flow-Next 的每个能力层都有明确的结构化成本，默认值已经替你想好了"精简姿态"——把配置当菜单而不是清单，只为真正需要的判断力付费。