Claude Code effort 实战指南：什么时候用 Low，什么时候该升档
先弄清 effort 改变了哪些工作，再看三组开发实测，最后用需求访谈、快速实现、人工评审和深入验证四步选档。
Claude 的新模型 Opus 5.5 能根据 effort 设置调整投入，并且在 Claude Code 中切换时不会破坏提示词缓存。从原文给出的测试看，它还可能用更低的档位达到接近的表现：Opus 5.5 在 High 档的通过率，与 Fable 5.1 在 Max 档相近。但用户仍经常问：effort 到底是什么，为什么需要它，又该如何选档？Anthropic 的 Thariq Shihipar 为此写了一篇文章，详细介绍 effort 到底该怎么用。
为回答这些问题，Thariq Shihipar 既做了日常开发实验，也深入查看了 Terminal-Bench 3.0 的内部运行。他关心的是：额外投入究竟增加了哪些自主决策、验证和边界测试。下面沿着“理解机制 → 看实测 → 用到研发流程”的顺序，把原文整理成一份选档指南。
effort 是什么，实际改变了什么
这里的 effort 是告诉模型：这项任务大致值得投入多少计算资源。它不是严格的时间限制，也不是只控制最终回复字数的开关。同样要完成任务，低档位会倾向于尽快给出满足要求的版本；高档位则更可能继续查资料、试不同路径、审自己的实现，并检查那些提示词没有逐项列出的边界情况。作者用一个人的工作时间打比方：给一小时，先做出可讨论的版本；给十二小时，便有空间独立打磨和验证。
这也解释了为什么“更高”不必然等于“更合适”。如果任务还没想清楚，更多努力可能被花在替你做产品决定上；如果任务是安全过滤器、存储引擎故障这类容易漏掉特殊情况的工作，多做验证反而是价值所在。选择档位前，先想清楚现在需要的是一轮反馈，还是一个尽量自足的交付。
同一项任务，调整投入方式
换一个档位，Claude 的工作重心如何变化？
Low · 先给出便于反馈的起点
- 模型推进什么
- 尽快做出满足当前要求的初版，方便你判断方向。
- 验证侧重点
- 适合轻量改动和快速迭代；重要边界测试可另设验证阶段。
- 你如何配合
- 及时审阅并给反馈，明确下一轮要改什么。
取舍：更快进入下一轮讨论，自主打磨通常较少。
依据原文整理的行为示意，不代表固定时间、token 预算或质量保证。实际行为仍取决于任务和提示词；低档也会尝试合理完成任务，高档仍可能选错方向。
三组实测：需求清晰度如何改变选档
作者用三个小型开发任务观察 effort 带来的行为差异。以下耗时是展示运行的记录，用来理解取舍，不是每次任务都能复现的时间表。
需求模糊：低档先给底子，高档替你补更多决定
作者先让 Opus 5.5 从一句话“做一个个人健身和训练记录应用”开始。在这组单次演示中，low 用约 1.5 分钟做出记录和简单图表；medium 约 4 分钟，high 约 11 分钟；max 则用了约 67 分钟，做出更完整的应用，加入热力图等细节。图 A 的互动对照显示，low 版本主要围绕记录、每周训练量和历史，max 版本还有更完整的导航、训练流程等。多出来的不仅是功能，也包括 Claude 自行决定哪些功能和界面值得做。
怎么选： 要一个底子并准备马上反馈，可以选 Low；想看模型一次自主完善到什么程度，可以提高档位，但要接受它替你做更多选择。
探索设计：先看方向，还是直接看高保真原型
换一个任务：重新设计 Claude Code 的 /config 菜单。各档位的基本想法差不多，都是用子菜单和更好的搜索；low 约 1 分钟给出能看出方向的交互草图，却不太像现有的 Claude Code；max 约 28 分钟给出更贴近产品的样稿，还走查了不同操作路径。作者在这个任务里反而偏向 low，因为他想先看方向、再自己反馈。若只想要一次交付就尽量完整，max 的成品程度才更有吸引力。
怎么选： 早期探索先用 Low；方向确定后，才值得为更完整的细节和操作流投入时间。