octopus-workflow/examples/review-round-budget.md

评审轮次预算的演化：从马拉松到掐尾

组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见 core/rules/compact.md（轮次边界压缩）与共享评审管线的 MAX_ROUNDS 绑定（core/skills/_shared/review-pipeline-phases.md）。

早期：无上限的马拉松评审

共享评审管线最初没有轮次上限。少数评审进入"修订 → 复审 → 新发现 → 再修订"的循环，最长的评审拖到 8 轮以上才收敛——每多一轮都是一轮 评审者 + 修订者 + 编排者的全成本，而第 6 轮之后的新发现大多是低severity 的格式与措辞问题。

第一版：一刀切轮次上限

引入 MAX_ROUNDS=3 作为共享默认。马拉杷消失了，但出现了新问题： 真正复杂的工件（大型 DAG、争议设计）在第 3 轮被硬停时尚未收敛， 只能靠人工介入善后——上限把"马拉松"变成了"截肢"。

现行：预算化 + 分级 + 掐尾

演化后的形态是三层：

1. 默认预算：普通评审 default 2 轮；high_risk 路线 3 轮。
2. 分级覆盖：特定评审类型按自身风险面声明轮次预算（如最深的 DAG 评审深度可达 4 轮），进入更高轮次需要用户显式选择—— "继续进入第 4 轮"是一个门，不是默认路径。
3. 轮次守卫：第 3 轮未收敛时强制升级选项（人工介入 / 带病接受 / 继续一轮），把"要不要继续"从评审者的默会判断变成显式决策点； 每轮 ≥2 的轮次边界压缩防编排上下文溢出。

教训

• 轮次预算的价值不在"省轮次"，而在把不收敛暴露为显式决策： 马拉松的问题不是慢，是没有人被要求说"到此为止"。
• 预算必须分级：一条统一上限同时伤害两类评审——简单的被浪费， 复杂的被截断。
• 轮次数据（p50/p95/封顶率）应持续回收：若 p95 远低于预算且从未 封顶，预算本身就该下调——预算是校准对象，不是信仰。