effort 管的是验证与判断的力度，不是聪明程度；边界用例多、又没人盯着时才值得开高档
effort 调节的主要是验证、边界测试和自主判断的力度，而不是基础能力。
作者在多个任务上对比各档位后发现，高档多出来的算力主要花在两件事上：对草稿做对抗式复查、写测试，以及在规格空白处自己拿主意。所以高档收益集中在 hardware、code review、security 这类验证价值高的领域。
“effort was a great way of modulating how much verification and edgecase testing” ¶3
关键证据都在图里（effort 曲线、失败归因图、分领域收益细分），正文没有给出各档位具体的 token 倍数和分领域数值。¶1 说切换 effort 不会打破 prompt cache，但没有解释机制和前提条件。
effort 可以理解成告诉模型「你打算给这件事多少时间」，模型会据此调整做法，而不只是调整用力程度。
作者用时间预算来类比：给的时间长，对方会认为你要的是一次做到最好的成品；给的时间短，对方会先交一个够用的版本等你反馈，也可能反过来告诉你这件事至少要多久。模型把 effort 当成对任务难度和期望的信号，档位越高，独立判断和验证的行动越多。
“effort gives the model an approximation of how much compute you want” ¶5
作者代表模型厂商，¶9 称这两个模型的 effort 曲线是「our best yet」，全文也在引导读者多用高档位，而高档会直接带来更多 token 计费。文中没有给出任何关于成本与收益比的讨论。
规格越完整，effort 对产出的影响越小；规格越模糊，effort 越会放大模型替你做的选择。
在「健身 app」这个需求模糊的任务里，low 只做出日志加简单图表，max 还加了热力图；配置菜单重设计这个任务中，low 用了 1 分钟出草图，max 用了 28 分钟出高保真稿和流程演示。但先访谈拿到详细规格之后，各档位做出的设计和实现相近，差别只剩细节。原因是模糊需求里留给模型发挥的空间更大，高档会把这些空间填满，也就替你做了更多假设。
“given this spec, the models behaved much more similarly” ¶19
这一点暂无对应的审视。
提高 effort 主要减少「漏掉边界用例」导致的失败，对「方法本身选错」无效。
按作者对 Terminal-Bench 3.0 全部结果的失败归类，effort 升高后，边界用例遗漏类失败减少，方法错误类失败不受影响。原因是额外的算力被用来测试和修补当前方案，而不会推翻已经选定的思路。
“does not fix when the model has the wrong approach” ¶42
文章推荐「low 实现、high 验证」，但同时承认 effort 修不了方法错误。这意味着低档实现的方向性错误不能指望靠高档验证来发现，只能依靠中间那一步人工 review。文章没有讨论这一步漏检的代价，也没有说明高档会「替你做更多假设」时，在无人值守场景下怎么约束。
高档成功的具体做法是一套可以学来的验证纪律：先复现问题，用参考实现做随机对照，再检查测试本身能不能抓到 bug。
mvcc-lsm-compaction 任务中，low 档先改代码、不跑复现脚本，结果是 0/5。xhigh 档先复现崩溃，拿一个从不做 compaction 的参考实现写随机测试，再确认这些测试在修复只做一半时会失败，结果是 4/5。cli-2ph-simplex 任务中，high 档拿暴力求解器做随机对照，并给大规模问题计时，从 0/5 提升到 5/5。
“reproduced the crash first, wrote a randomized test against a reference that never compacts” ¶47
Terminal-Bench 3.0 的任务是公开的，文中点名的 html-js-filter、cli-2ph-simplex、mvcc-lsm-compaction 等任务都可以在 Claude Code 里配合 /effort 自己复跑。可以复现的不只是通过率，还有「高档会先复现问题、做随机对照」这类行为差异。
人在环里的程度决定该用哪档：人在环里用低档快速迭代，无人值守用高档替代人的判断。
gsea-proteomics 任务中，high 档尝试了两种数据预处理，发现显著结果随之改变，追查原因后选对了方法，从 0/5 提升到 4/5。作者指出，如果有人在环里，模型可能会直接问用户该怎么设定问题。因此高 effort 本质上是在用模型的自我核查替代人的审阅，这也是作者把 max 留给「完全自主」场景的原因。
“without a user in the loop, high effort does better” ¶54
这一点暂无对应的审视。
作者没有直接谈到这一点。
通过率只基于每个任务 5 次尝试，1/5 到 5/5 这类差距在小样本下置信区间很宽。脚注还说明 Fable 5.1 关闭了生产安全干预、安全类任务没有联网，因此与公开榜单和发布文章都对不上。示例轨迹来自单次运行，有些用的还是中间档位。
高档多出来的不是智力，而是先复现、随机对照、检验测试本身的验证纪律
effort 调节的主要是验证、边界测试和自主判断的力度，而不是基础能力。
作者在多个任务上对比各档位后发现，高档多出来的算力主要花在两件事上：对草稿做对抗式复查、写测试，以及在规格空白处自己拿主意。所以高档收益集中在 hardware、code review、security 这类验证价值高的领域。
effort was a great way of modulating how much verification and edgecase testing
¶3 ↗
effort 可以理解成告诉模型「你打算给这件事多少时间」，模型会据此调整做法，而不只是调整用力程度。
作者用时间预算来类比：给的时间长，对方会认为你要的是一次做到最好的成品；给的时间短，对方会先交一个够用的版本等你反馈，也可能反过来告诉你这件事至少要多久。模型把 effort 当成对任务难度和期望的信号，档位越高，独立判断和验证的行动越多。
effort gives the model an approximation of how much compute you want
¶5 ↗
规格越完整，effort 对产出的影响越小；规格越模糊，effort 越会放大模型替你做的选择。
在「健身 app」这个需求模糊的任务里，low 只做出日志加简单图表，max 还加了热力图；配置菜单重设计这个任务中，low 用了 1 分钟出草图，max 用了 28 分钟出高保真稿和流程演示。但先访谈拿到详细规格之后，各档位做出的设计和实现相近，差别只剩细节。原因是模糊需求里留给模型发挥的空间更大，高档会把这些空间填满，也就替你做了更多假设。
given this spec, the models behaved much more similarly
¶19 ↗
提高 effort 主要减少「漏掉边界用例」导致的失败，对「方法本身选错」无效。
按作者对 Terminal-Bench 3.0 全部结果的失败归类，effort 升高后，边界用例遗漏类失败减少，方法错误类失败不受影响。原因是额外的算力被用来测试和修补当前方案，而不会推翻已经选定的思路。
does not fix when the model has the wrong approach
¶42 ↗
高档成功的具体做法是一套可以学来的验证纪律：先复现问题，用参考实现做随机对照，再检查测试本身能不能抓到 bug。
mvcc-lsm-compaction 任务中，low 档先改代码、不跑复现脚本，结果是 0/5。xhigh 档先复现崩溃，拿一个从不做 compaction 的参考实现写随机测试，再确认这些测试在修复只做一半时会失败，结果是 4/5。cli-2ph-simplex 任务中，high 档拿暴力求解器做随机对照，并给大规模问题计时，从 0/5 提升到 5/5。
reproduced the crash first, wrote a randomized test against a reference that never compacts
¶47 ↗
人在环里的程度决定该用哪档：人在环里用低档快速迭代，无人值守用高档替代人的判断。
gsea-proteomics 任务中，high 档尝试了两种数据预处理，发现显著结果随之改变，追查原因后选对了方法，从 0/5 提升到 4/5。作者指出，如果有人在环里，模型可能会直接问用户该怎么设定问题。因此高 effort 本质上是在用模型的自我核查替代人的审阅，这也是作者把 max 留给「完全自主」场景的原因。
without a user in the loop, high effort does better
¶54 ↗
作者代表模型厂商，¶9 称这两个模型的 effort 曲线是「our best yet」，全文也在引导读者多用高档位，而高档会直接带来更多 token 计费。文中没有给出任何关于成本与收益比的讨论。
通过率只基于每个任务 5 次尝试，1/5 到 5/5 这类差距在小样本下置信区间很宽。脚注还说明 Fable 5.1 关闭了生产安全干预、安全类任务没有联网，因此与公开榜单和发布文章都对不上。示例轨迹来自单次运行，有些用的还是中间档位。
Terminal-Bench 3.0 的任务是公开的，文中点名的 html-js-filter、cli-2ph-simplex、mvcc-lsm-compaction 等任务都可以在 Claude Code 里配合 /effort 自己复跑。可以复现的不只是通过率，还有「高档会先复现问题、做随机对照」这类行为差异。
文章推荐「low 实现、high 验证」，但同时承认 effort 修不了方法错误。这意味着低档实现的方向性错误不能指望靠高档验证来发现，只能依靠中间那一步人工 review。文章没有讨论这一步漏检的代价，也没有说明高档会「替你做更多假设」时，在无人值守场景下怎么约束。
关键证据都在图里（effort 曲线、失败归因图、分领域收益细分），正文没有给出各档位具体的 token 倍数和分领域数值。¶1 说切换 effort 不会打破 prompt cache，但没有解释机制和前提条件。