本文翻译自Claude官方Blog：https://claude.com/blog/best-practices-for-using-claude-opus-4-7-with-claude-code
了解如何利用重新校准的effort级别、自适应思考以及新的默认设置,优化你在 Claude Code 中使用 Opus 4.7 的体验。
- 类别:Claude Code
- 产品:Claude Code
- 日期:2026 年 4 月 16 日
- 阅读时长:5 分钟
Opus 4.7 是我们目前正式发布的最强模型,适用于编码、企业工作流以及长时间运行的智能体(agentic)任务。它比 Opus 4.6 更善于处理模糊性,在查找 bug 和代码评审方面能力大幅提升,跨会话保留上下文更可靠,并且能够在更少指引下推理出含糊任务的解决方案。
在我们的发布公告中,我们提到两个变化会影响 token 用量:更新后的分词器(tokenizer),以及在更高 effort 级别下(尤其是较长会话的后续轮次)更倾向于深入思考的特性。因此,从 Opus 4.6 切换到 Opus 4.7 时,可能需要做一些调优才能达到最佳性能。对提示词(prompt)和编排框架(harness)进行少量调整,就能带来显著差异。
本文将介绍这些变化,以及如何在 Claude Code 中最有效地使用 Opus 4.7。
组织交互式编码会话
Opus 4.7 的 token 用量和行为表现,会因部署形式不同而有所差异:是部署为单轮用户输入的、更自主的异步编码 agent;还是部署为多轮用户输入的、更交互的同步编码 agent。在交互式场景中,它会在用户每轮输入后投入更多推理:这能在长会话中提升其连贯性、指令遵循度和编码质量,但同时也倾向于消耗更多 token。
要在 Claude Code 中充分发挥 Opus 4.7 的能力,我们建议把 Claude 当作一位你正在委派任务的能干工程师,而不是一位需要你逐行指导的结对编程伙伴:
- 首轮就把任务说清楚。 明确的任务描述应包含意图、约束、验收标准和相关文件路径,这能为 Opus 4.7 提供产出高质量结果所需的上下文。在多轮中逐步抛出含糊的提示,往往会降低 token 效率,有时也会影响整体质量。
- 减少必要的用户交互次数。 每一轮用户输入都会增加推理开销。把问题集中起来一次问完,并提供足够上下文让模型能持续推进。
- 在合适场景下使用 auto 模式。 对于你信任模型可以安全执行、不需频繁确认的任务,auto 模式可以缩短周转时间。它特别适合那些你已经在前期提供了完整上下文的长时间任务。Auto 模式现已在 Claude Code Max 用户的研究预览中开放,可通过 Shift+Tab 切换开启。
- 为已完成任务设置通知。 你可以让 Claude 在任务完成时播放提示音,它能基于钩子(hook)机制创建自己的通知。
Opus 4.7 推荐的 effort 设置
Claude Code 中 Opus 4.7 的默认 effort 级别现在是 xhigh。这是一个介于 high 和 max 之间的新级别,让用户在难题上能更精细地权衡推理深度和延迟。我们建议大多数智能体编码工作使用 xhigh,尤其是对智能要求高的任务,例如设计 API 和 schema、迁移遗留代码、评审大型代码库。
各 effort 级别的进一步指引如下:
medium和low:适用于对成本敏感、对延迟敏感或范围明确的工作。模型在更难的任务上能力会比高级别时弱,但仍优于同 effort 级别下的 Opus 4.6——有时还会消耗更少 token。high:在智能与成本之间取得平衡。如果你在并发运行多个会话,或想在质量没有大幅下降的前提下节约开销,可选择 high。xhigh(默认,推荐):大多数编码和智能体使用场景的最佳设置。它具备强自主性和高智能,又不会像 max 那样在长 agent 运行中产生失控的 token 消耗。max:在真正困难的问题上能再榨出一些性能,但回报递减,且更容易出现过度思考。建议有意识地用于例如:在 evals 中测试模型能力上限、对智能极度敏感且不计成本的任务等。
如果你正在升级到新模型,我们建议你尝试不同 effort 级别,而不是简单沿用旧设置。同一任务期间也可以在不同 effort 级别间切换,以更高效地管理 token 用量和推理深度。
我们之所以将 Opus 4.7 的默认 effort 设为 xhigh,是因为我们认为这是绝大多数编码任务的最佳设置。如果你是已有的 Claude Code 用户但没有手动设置 effort 级别,系统会自动将你升级到 xhigh。你仍然可以手动调整。
适应自适应思考(Adaptive Thinking)
Opus 4.7 不支持带固定思考预算的 Extended Thinking。 取而代之的是自适应思考(adaptive thinking)。它让”思考”在每一步都成为可选项,模型可以根据上下文自行决定何时投入更多思考。它能快速回应简单查询、在某一步用不上思考时跳过思考,并把思考 token 投入到最可能产生价值的地方。在一次完整的 agent 运行中,这能积累成更快的响应速度和更好的用户体验。
本次版本中,自适应思考有显著改进——尤其是 Opus 4.7 不再那么容易过度思考。
如果你想更精细地控制思考频率,可以直接在 prompt 中明确要求:
- 想要更多思考时,可以这样写:”在回答前请仔细、按步骤思考;这个问题比看上去更难。”
- 想要更少思考时,可以这样写:”优先快速作答,而不是深入思考。拿不准时直接给出答复。”这样能节省 token,但在更难的步骤上可能损失一些准确性。
值得了解的行为变化
Opus 4.6 与 4.7 之间有一些默认行为发生了变化。如果你为旧模型精心调校过 prompt 或编排框架,这些变化值得关注。
回复长度会按任务复杂度校准。 Opus 4.7 不像 Opus 4.6 那样默认啰嗦。简单查询会得到更短的答案,开放式分析则会得到更长的回应。如果你的使用场景依赖特定的长度或风格,请在 prompt 中明确说明。我们发现,提供你想要的语气的正面示例,比”不要这样做”的负面指令效果更好。
模型调用工具的次数变少,推理变多。 在很多情况下这反而带来更好的结果。如果你想要更多的工具使用(比如在 agent 工作中更激进地搜索或读取文件),请明确说明何时以及为何应该使用该工具。
默认情况下,它派生子 agent 的次数变少。 Opus 4.7 在何时把工作委派给子 agent 这件事上更加审慎。如果你的使用场景能从并行子 agent 中受益(例如对多个文件或独立条目并行处理),建议明确写出来。例如:
不要为单次响应中可以直接完成的工作派生子 agent(例如重构一个你已经能看到的函数)。当需要并行处理多个条目或读取多个文件时,在同一轮中派生多个子 agent。
接下来可以尝试什么
Opus 4.7 在长时间运行的任务上比此前模型表现更好。这让它非常适合那些过去因为需要持续监督而成为瓶颈的任务,比如复杂的多文件改动、含糊的调试问题、跨服务的代码评审,以及多步骤的智能体工作。
我们建议把 effort 保持在 xhigh,看看你的第一轮输入能把任务推进到多远。
更多内容请参阅我们的 Opus 4.7 提示词指南,以及关于 Claude Code 中上下文与会话管理的文章。