Claude的推理effort怎么选

发布日期：2026 年 9 月 26 日 · MetaChat 编辑整理

用 Claude Code 写代码时，很容易把 effort 固定在 high：既然要做事，多花点功夫总归更稳妥。

但如果你只是想看一个交互草图，等模型反复打磨半小时，可能还不如一分钟拿到初稿，再告诉它哪里要改。反过来，修一个难以复现的崩溃问题，只求尽快改完代码，又可能把真正的故障留在原地。

Anthropic Claude Code 团队的 Thariq Shihipar 在 《Using Claude Code: Spending your effort》 中，分享了他对不同 effort 档位的实测。一个很实用的判断是：选档位时，既要看任务有多难，也要看你准备参与多少，以及结果需要验证到什么程度。

先选一个适合当前任务的档位

下面四档的使用建议来自 Thariq 的经验；xhigh 则根据官方档位说明补充，方便理解后面的实验结果。

档位	适合的任务	使用时的侧重点
low	头脑风暴、交互草图、范围明确的小改动	尽快拿到结果，你随时查看、纠正方向
medium	大部分日常开发，例如实现新功能	在投入和完成质量之间取得日常平衡
high	老代码库修 bug、复杂逻辑检查、需要充分验证的工作	给模型更多时间复现问题、检查边界和测试
xhigh	需要比 high 更深入推理和排查的复杂任务	愿意进一步增加投入，再观察是否改善结果
max	自主完成并验证一个 App、关键软件的安全审查等难题	你较少介入，让模型独立推进较长的工作过程

这些建议不能代替对结果的检查。官方文档也提醒，max 可能出现收益递减或过度思考；不同模型的同名档位，底层投入并不相同。当前 Opus 5.5 的默认档位是 medium，不必把旧模型上的 high 设置原样搬过来。设置细节见 Claude Code 模型配置文档。

effort 决定模型愿意在这件事上花多少功夫

可以把 effort 理解为你给模型的投入意愿：愿意让它为当前任务花多少算力、多少时间。

同样一项工作，给人一小时，他往往会先交一个能用的版本，等反馈后再改；给他十二小时，他更可能自行比较方案、补齐细节，再反复检查。这个类比解释的是工作方式，不是说某一档对应固定的执行时长。

Thariq 观察到，调高 effort 后，Claude 会增加验证和边界测试，也会更频繁地运用自己的判断。你没有交代清楚的部分，它可能直接替你决定。

因此，高档位的价值要结合当前阶段判断。如果需求还在变化，你最需要的可能是快速看到一个版本；如果方案已经确定，接下来要确认它经得住异常输入和真实使用，就值得给验证留出更多投入。

需求越模糊，高低档位的差别越明显

Thariq 给 Opus 5.5 的一个任务很简单：“做一个健身记录 App。”

low 做出了记录表和简单图表。随着档位升高，App 的功能和细节逐渐增加，max 还加入了热力图。它确实做得更多，但这些新增功能也包含了模型对用户需求的猜测。

另一个任务是重新设计 Claude Code 的 /config 菜单。low 大约一分钟就交出一个能表达思路的交互草图；max 花了约 28 分钟，做出了更接近真实界面的样稿，还附带多种操作流程的演示。

如果你准备马上给反馈，一分钟的草图就足够开启下一轮讨论。如果你希望离开一会儿，回来看到一个较完整的方案，更多投入才更符合你的预期。

他还做了一个对照：先让 Claude 详细采访自己，把健身 App 的需求整理完整，再交给不同模型、不同档位实现。这一次，各版本的设计和实现明显接近了。

这给日常开发一个直接的启发：先把关键需求说清楚，往往比直接调高 effort 更有用。 比如做健身记录工具，是否需要账号、数据存在哪里、手机上怎么用，都值得先确认。否则你可能花了更多时间，得到一个功能更全、却偏离预期的版本。

高档位最值得花在验证和边界情况上

原文还分析了 Terminal-Bench 3.0 中的困难任务。与界面草图相比，这些任务更能体现“做出来”与“通过验证”之间的距离。

HTML 过滤器：手测一个页面还不够

html-js-filter 要求实现一个 HTML 过滤器，清理各种夹带 JavaScript 的写法。Fable 5.1 在 low 档的五次尝试中通过一次，在 xhigh 档五次全部通过。

低档位的典型过程约两分钟：写出过滤器，用一个手写页面测一下，然后结束。作者追踪的一次 high 运行则花了约 33 分钟，检查初稿漏洞、阅读解析器源码、运行标准 XSS 测试集，最后还编写了随机生成网页的模糊测试程序。

这里的区别体现在测试覆盖了多少种失败方式。注意，33 分钟来自一次 high 运行，而五次全通过的统计对应 xhigh，两者不能混为同一组结果。

存储引擎崩溃：先复现，再证明修复有效

在 mvcc-lsm-compaction 任务中，Opus 5.5 的通过次数从 low 的 0/5，提升到 xhigh 的 4/5。

low 每次约一分钟，往往没先构建项目或运行复现程序，就开始修改代码，也没检查新增测试能否抓住原始 bug。

xhigh 约花 11 分钟，先复现崩溃，再写随机测试，并确认测试能够拦住只修到一半的版本。对维护旧系统来说，这种检查很有价值：测试不但要在修复后通过，也要能说明原来的问题确实存在。

数据分析：看起来合理的方法，也需要比较

gsea-proteomics 要求分析蛋白质组学数据，判断八种处理方式中哪些接近目标组织。Opus 5.5 在 low 下五次全错，在 high 下五次答对四次。

低档位选了一种听起来合理的预处理方法，跑完就报告结果。高档位试了两种方法，发现结论不同，于是继续查明原因，再作选择。

有人在场时，这类设定问题可以通过追问解决。无人介入时，模型愿不愿意主动比较方法、检查假设，就会直接影响结果。

以上案例与数字均出自 Thariq 的原文。它们是每项任务五次尝试的内部实验，运行条件与线上产品不同；其中 Fable 5.1 关闭了生产环境的安全干预，安全任务也没有联网。单次耗时和小样本通过次数适合用来观察行为差异，不能当作你的项目必然达到的成功率。

高档位也有能力边界。作者发现，增加投入有助于减少遗漏边界情况导致的失败，但模型一开始选错解题思路时，仅靠加档位未必能解决问题。

把档位切换放进开发流程

Thariq 给普通开发的默认建议是 medium，但在自己密切参与的新功能开发中，他更喜欢先用 low 快速迭代，最后切到 high 验证。这两种用法对应了不同的参与程度。

下面将他的流程整理成一套可直接尝试的操作。提示词是本文给出的使用示例，可按项目调整。

开始前，让 Claude 找出需求缺口

先写出目标，再让它追问那些会影响实现的细节：

我想实现这个功能：[描述目标]。
请先阅读相关代码，找出需求中会影响实现的缺口并向我提问。
重点确认用户流程、数据存储方式和验收条件，确认后再开始实现。

这一步的目的，是尽早确认那些一旦猜错就会返工的决定。

用 low 做出可检查的版本

需求确认后，在 Claude Code 中切到 low：

/effort low

接着给出范围明确的任务：

按已确认的需求实现第一版，优先完成主流程。
完成后说明改动位置，以及我应该怎样检查效果。

检查时，先看流程和交互是否符合预期。方向需要调整，就继续快速迭代。若任务需要模型一次处理更多实现细节，也可以从 medium 开始。

方向确认后，切 high 做验证

/effort high

验证任务也要有明确对象。例如：

请验证刚才完成的功能，依据需求检查边界情况和回归风险。
运行相关测试，修复发现的问题，并说明验证结果与尚未验证的部分。
如果这是 bug 修复，请确认测试能够在修复前复现问题、在修复后通过。

这样分配投入，你可以在探索阶段尽早纠正方向，再把更多时间用在已确认方案的可靠性上。

中途换档位，注意缓存条件

在 Claude Code 中输入 /effort 可以打开选择界面，也可以直接输入 /effort medium 这样的命令。会话中途可以调整档位；具体可用选项取决于模型和环境，见 官方配置说明。

截至本文发布时，官方说明：Opus 5.5 和 Fable 5.1 在支持的 Claude Code 版本中，通过 Anthropic API Key 或 Claude 订阅使用时，中途调整 effort 可以保留提示词缓存。旧模型通常会因切换档位而重新处理已有上下文。

这项能力有接入条件。Amazon Bedrock、Google Cloud 的 Agent Platform、Claude apps gateway，以及部分特殊配置不适用；Fable 5.1 在 Claude Code v2.1.260 之前也会失效。如果通过 MetaChat 等第三方网关接入，还要以网关实际支持情况为准，不能仅凭模型名称判断缓存一定保留。详见 Claude Code 缓存说明。

缓存保留意味着可以继续复用已处理的上下文。调高 effort 后新增的推理和验证工作，依然会消耗时间与 Token。

下次开始任务时，可以先判断：你是否会盯着过程给反馈，以及结果遗漏一个边界情况会带来多大影响。快速探索时选 low，常规开发从 medium 起步，需要扎实验证时再提高档位。任务阶段变了，effort 也可以跟着变。

---

继续阅读：编程辅助提示词 · MetaChat API 接入指南