AI编码
x.com ·
@宝玉 (@dotey)
Claude Code effort 档位怎么选：来自 Anthropic 团队成员的实测经验
内容转述 Anthropic Claude Code 团队成员 Thariq Shihipar 关于 effort 档位用法的经验：low 适合头脑风暴、草图和小改动，medium 用于日常功能开发，high 用于验证和边界情况多的任务，max 用于让模型自主攻克难题。文中称在 Claude Code 中输入 /effort 可切换档位，且只有较新的 Opus 5.5 和 Fable 5.1 在对话中途切换不会使 prompt cache 失效。作者引用实测称，需求越模糊，档位差异越大；在 Terminal-Bench 3.0 的 html-js-filter 题中，Fable 5.1 在 low 档 5 次仅过 1 次，xhigh 档 5 次全过；Opus 5.5 修存储引擎崩溃 bug 时 low 档 0/5、xhigh 档 4/5。结论是边界情况越多的任务越值得开高档位，但模型初始思路错误时提高档位也无法挽救。
AI推荐理由
内容转述 Anthropic Claude Code 团队成员 Thariq Shihipar 关于 effort 档位（low/medium/high/max）的用法经验，并给出具体实测对比：同一模糊需求在不同档位下产出差异、Terminal-Bench 3.0 中 html-js-filter 与存储引擎崩溃修复题在 low 与 xhigh 档的通过率差异（如 1/5 对 5/5、0/5 对 4/5）、以及高档位耗时（约 33 分钟、11 分钟）等。这些是输入中给出的具体新信息，对使用 Claude Code 的开发者有直接参考价值。局限在于：这是二手转述，未提供原文链接或可独立核验的原始数据；文中提到的 Opus 5.5、Fable 5.1 等模型名称与缓存不失效等说法无法在输入中验证；X 互动量仅作传播信号，不构成质量背书。
78
浏览 33,357
点赞 184
评论 22
转发 27
正文
Anthropic Claude Code 团队的 Thariq Shihipar 的这篇文章讲 Claude Code 里的 effort 设置（可以理解为投入档位）该怎么用。我想很多人都不是很清楚 Claude Code 的 effort 档位怎么选，我在看这篇文章之前也有些模糊，一般默认就是 high，现在看还是有些讲究的。
Thariq 的经验是：low 用于头脑风暴、画草图、小改动，要的是快，随时能插手；medium 用于大部分日常开发，比如实现新功能；high 用于需要验证、边界情况多的活，比如在老代码库里修 bug；max 用于让 Claude 完全自主攻克难题，比如从头到尾搭一个 App 并验证，或者给关键软件找安全漏洞。
在 Claude Code 里输入 /effort 就能切换档位，对话中途也可以换。注意只有最新的 Opus 5.5 和 Fable 5.1 不会让缓存失效，早期模型会让缓存失效。
Thariq 通过实测发现，effort 主要决定 Claude 在一个任务上花多少功夫做验证、测边界情况，以及替你拿多少主意。
effort 从 low 到 max 分几档，本质是告诉模型你愿意让它在这件事上花多少算力。同一件事，给你 1 小时，你会先交一个能用的版本，等对方反馈再改；给你 12 小时，你会自己反复打磨、检查。
最新的 Opus 5.5 和 Fable 5.1 可以在对话中途切换档位，而且不会让提示词缓存（prompt cache）失效，前面对话积累的缓存照样能用。能随时切了，很多用户就来问他到底什么时候该用哪一档。
【日常开发：需求越模糊，档位差别越大】
Thariq 让 Opus 5.5 用不同档位做同一个模糊需求：“做一个健身记录 App”。low 档只做出一个记录表和一张简单图表，档位越高功能越多，max 档还加了一张热力图。另一个任务是重新设计 Claude Code 的 /config 菜单，low 档 1 分钟交出一个能看懂思路的交互草图；max 档用了 28 分钟，样稿跟 Claude Code 真实界面很像，还附了几种操作流程的演示。
如果先让 Claude 详细采访他、整理出完整需求再动手，不同模型、不同档位的产出就很接近了。
换句话说，档位越高，Claude 替你做的假设越多。想自己掌控细节，就用低档位快速出初稿，边看边改。
他现在开发新功能的流程是：把需求交给 Claude，让它反过来问你还漏了哪些细节；用 low 档实现，检查大方向对不对，不对就继续用 low 档改；最后切到 high 档做验证和测试。
【难题：高档位用来补边界情况】
更难的任务，他去翻了 Terminal-Bench 3.0 的结果。这是一个社区出题的基准测试，题目比日常开发难得多，比如用 Verilog 写一台能装进小型 FPGA（可编程芯片）的 8 位游戏机，或者在定理证明工具 Lean 4 里完整证明一条数学定理。
他的主要结论是：边界情况越多的任务，越值得开高档位。
html-js-filter 这道题要求写一个 HTML 过滤器，把所有往网页里夹带 JavaScript 的写法都清理干净。Fable 5.1 在 low 档跑 5 次只过了 1 次，到 xhigh 档 5 次全过。low 档每次两分钟左右，写一遍过滤器，拿一个手写页面测一下就结束了。他追踪的一次 high 档运行花了约 33 分钟：先挑自己初稿的毛病，再去读解析器源码找 bug，跑了一套标准的 XSS（跨站脚本攻击）测试集，最后还写了一个随机生成网页的模糊测试程序。
Opus 5.5 修存储引擎崩溃 bug 的题也类似，low 档 0/5，xhigh 档 4/5。low 档一分钟左右就直接改代码，没先复现崩溃；xhigh 档花 11 分钟，先复现，再写随机测试，还专门确认修到一半的代码会被测试拦下来。
按领域看，硬件、代码审查、安全这类题目从高档位受益最多。但档位也有管不到的地方：加档位能减少因漏掉边界情况导致的失败，模型一开始思路就错了的话，档位开再高也救不回来。
还有一道题能看出人在不在场的区别。gsea-proteomics 要求分析一组蛋白质组学数据，判断八种处理方式里哪些效果接近目标组织。low 档的 Opus 5.5 挑了一种听起来合理的数据预处理方法，跑一遍就报结果，5 次全错；high 档试了两种预处理方法，发现得出的结论不一样，先查清原因再选定方法，5 次对了 4 次。Thariq 说，如果有人在场，Claude 可能会先问一句这个问题该怎么设定；没人在场，高档位的效果更好。
所以档位怎么选，很大程度上看你打算在这个任务里参与多少。一直默认开 high，等于每次都让 Claude 替你多拿主意，也每次都多花时间和 Token。