Claude Opus 4.7 深度迁移指南：掌握自适应思考与长上下文优化

Claude Opus 4.7 不是 4.6 的即插即用替代品

新的 xhigh effort level、adaptive thinking 和 1M 上下文窗口，如何改变你与 Claude 最强模型的提示方式、委派方式和会话管理方式。

你刚刚升级到了 Claude Opus 4.7。你的 prompts 还是一样，harness 也还是一样。

但你的 token 账单翻倍了，代码审查的 recall 下降了。发生了什么？

Opus 4.7 不是 4.6 的即插即用替代品。它的思考方式不同，更严格地遵循指令，生成的 subagents 更少，并且在每次用户轮次之后都会更积极地进行推理。

之前有效的模式现在会消耗你的 token，却没有带来成比例的质量提升。修复并不复杂，但需要你理解发生了什么，并相应调整你的工作流。

我们来看看。

委派心态

Opus 4.7 最大的变化，是你如何界定自己的角色。把 Claude 当成一个你可以委派任务的能干工程师，而不是一个需要你逐行指导的结对编程伙伴。

交互式会话中的每个用户轮次都会触发推理开销。对于 4.6，你可以把指令分散到多个轮次中，而不会有太大代价。

对于 4.7，这种模式会推高 token 使用，因为模型会在你发送的每条消息之后进行深度推理。无论这一轮是否值得，它都会为每一轮推理付费。

下面三个具体改变可以解决这个问题。

• 首先，在第一轮就把任务说明白。包括意图、约束、验收标准以及相关文件路径。把含糊的提示分散到多个轮次中，会同时降低 token 效率和输出质量。
• 其次，把你的问题批量提出。每条用户消息都会增加推理开销，所以要给模型足够的上下文，让它可以持续推进，而不必频繁确认。
• 第三，对可信任务使用 auto mode。对于长时间运行、且你已经提供完整上下文的工作，auto mode（Shift+Tab）通过去掉不必要的确认步骤来缩短循环时间。它目前在 Claude Code Max 用户的 research preview 中可用。

你也可以让 Claude 在任务完成时播放声音。它会创建自己的基于 hook 的通知，这样你就不必一直盯着它工作。

5 个 Effort Level 以及为什么 xhigh 是新的默认值

Opus 4.7 引入了 xhigh，这是位于 high 和 max 之间的新 effort level。现在它是 Claude Code 的默认值。

如果你是现有用户，并且从未手动设置 effort level，你已经被自动升级到 xhigh。

下面是五个层级的划分方式。

• low 适用于对延迟敏感、范围很窄的工作。模型不会超出预期做太多，但它在相同 effort level 下仍然优于 Opus 4.6。
• medium 适合对成本敏感、愿意用智能换速度的任务。
• high 在智能和成本之间取得平衡。对于并发会话或预算敏感、但又不想明显牺牲质量的工作来说，这是不错的选择。
• xhigh 是默认值，也是编码和 agentic 任务的最佳平衡点。你能获得强大的自主性和智能，同时不会出现 max 可能带来的失控 token 使用。
• max 会在真正困难的问题上挤出额外性能，但边际收益递减。它更容易过度思考，因此应有意识地用于 eval ceiling 测试或对智能极其敏感的工作。

一个实用建议：你可以在任务中途切换 effort。复杂设计阶段从 xhigh 开始，简单实现阶段降到 high，而在棘手的调试会话中提升到 max。这样你就能对 token 支出进行更精细的控制。

Opus 4.7 对 effort level 的遵守比 4.6 更严格，所以如果某个在 low 或 medium 下的任务感觉思考不足，不要绕着提示词打转，而是直接提高 effort。

Adaptive Thinking 取代固定预算

如果你在 Opus 4.6 上使用带有 budget_tokens 的 Extended Thinking，那么这已经不再适用。Opus 4.7 改用了 adaptive thinking。

这个差异很重要。使用固定预算时，你会预先分配一组固定数量的 thinking tokens，模型会不管需不需要都使用它们。

使用 adaptive thinking 时，模型会在每一步决定何时以及思考多少。

简单查询会得到快速回复，复杂推理步骤会进行深度思考，而那些不需要思考的步骤则会跳过。

在长时间的 agentic 运行中，与统一的 thinking budget 相比，这会带来更快的响应和更低的 token 使用量。

迁移很直接：

## 之前（Opus 4.6 使用 extended thinking）
client.messages.create(
    model="claude-opus-4-6",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

## 之后（Opus 4.7 使用 adaptive thinking）
client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

你仍然可以通过 prompts 引导思考速度。若想让它多思考，可以尝试类似 “Think carefully and step-by-step before responding; this problem is harder than it looks.” 这样的提示。

若想让它少思考，可以使用 “Prioritize responding quickly rather than thinking deeply. When in doubt, respond directly.”

如果你在 max 或 xhigh effort 下运行，请设置较大的 max output token budget（先从 64k 开始），这样模型才有足够空间在 subagents 和 tool calls 之间进行思考和行动。

会让你踩坑的行为变化

Opus 4.7 带来了一些默认行为变化，如果你已经针对 4.6 调整过 prompts 或 harnesses，这些变化会让你措手不及。我们来逐项看看。

Response length

Opus 4.7 会根据任务复杂度校准 response length。简单查询得到简短答案，开放式分析则得到更长答案。

如果你的用例依赖特定长度或风格，请明确说明。用你想要的语气的正面示例，比“不要这样做”之类的负面指令更有效。

更少的 tool calls

模型调用 tools 的频率更低，但会进行更多推理。很多情况下这会产生更好的结果。

但如果你需要更激进的 tool 使用来进行搜索或文件读取，请明确说明何时以及为什么应该使用 tools。把 effort 提高到 high 或 xhigh 也会增加 tool 使用。

更少的 subagents

Opus 4.7 在委派给 subagents 方面更为审慎。如果你的工作流受益于并行展开，请清楚地写出来：

“不要为你能在单次响应中直接完成的工作 spawn subagent。当需要跨多个条目展开或读取多个文件时，在同一轮中 spawn 多个 subagents。”

更字面化的指令遵循

这是最可能破坏现有设置的变化。Opus 4.7 对 prompts 的理解更字面化，尤其是在较低 effort level 下。

它不会悄悄把某一项的指令泛化到另一项，也不会推断你没有明确提出的请求。好处是更精确、减少来回折腾。

坏处是，如果你希望某条指令广泛适用，必须明确说明范围。例如：“将这种格式应用到每个部分，而不只是第一部分。”

语气变化

Opus 4.7 更直接、更有主见，较少使用偏验证式的措辞，也比 4.6 更少 emoji，风格更温和的部分也更少。如果你的产品依赖特定语气，请针对新的基线重新评估你的 style prompts。

Code Review

Opus 4.7 在发现 bug 方面明显更强。根据 Anthropic 基于真实 PR 的最难 bug-finding eval，它的 recall 高了 11 个百分点，precision 也更高。

但问题在这里。如果你的 review harness 写的是“只报告高严重性问题”或“保持保守”，Opus 4.7 会比 4.6 更忠实地执行这一指令。

它可能会像以前一样彻底检查代码，识别出 bug，然后却不报告那些它判断低于你设定门槛的发现。precision 上升了，但测得的 recall 下降了。

解决方法是把“发现”与“过滤”分开：

报告你发现的每一个问题，包括你不太确定或认为严重性较低的那些。在这个阶段不要按重要性或置信度过滤。你在这里的目标是覆盖率：先暴露一个之后可能被过滤掉的发现，也比悄悄漏掉一个真实 bug 更好。对于每个发现，给出你的置信度和一个估计的严重性，以便下游过滤器进行排序。

如果你需要单次通过的过滤，请明确说明门槛，而不要使用模糊表述。例如：“报告任何可能导致错误行为、测试失败或误导性结果的 bug；只省略纯粹的风格或命名偏好问题。”

1M 上下文下的会话管理

Claude Code 现在拥有 100 万 token 的上下文窗口。这足以在单个会话中从零构建一个全栈应用。

但更多上下文并不总意味着更好的结果。context rot 是真实存在的。

随着上下文增长，注意力会分散到更多 token 上。较旧、无关的内容会开始干扰当前任务，而当上下文窗口被填满时，模型会变得不那么聪明。

中间丢失效应：

每一轮你有五种选择。

• Continue 表示再发送一条消息。当窗口中的所有内容仍然相关时使用它。
• Rewind（双击 Esc）会把你跳回到之前的一条消息，从那里重新发起提示。失败的尝试会从上下文中移除，这通常比输入“那个没用，改成 X 再试”更好，因为你保留了有用的文件读取结果，同时丢掉了失败路径。
• 带提示的 /compact 会总结会话并继续进行。它会丢失一些信息，但 effort 较低，而且你可以用类似 /compact focus on the auth refactor, drop the test debugging 的指令来引导它。
• /clear 会开启一个新会话。你自己写下重要内容，从而获得零 rot 和完全控制。
• Subagents 负责委派那些会产生大量中间输出的工作。Subagent 会获得它自己的新鲜上下文窗口，只有最终结果会返回回来。

这个思维测试很简单：你之后还会需要 tool 输出，还是只需要结论？如果只需要结论，就使用 subagent。

什么会导致不好的 auto-compaction

当你接近上下文限制时，auto-compaction 会触发。问题在于，这恰恰是模型因为 context rot 而最不聪明的时候。

一个常见失败是这样的：在一段漫长的调试会话之后，autocompact 触发并总结了调查过程。你的下一条消息引用了摘要中被丢掉的内容。

有了一百万上下文，你就有更多时间主动进行 compact，并附上对重要内容的描述。不要等到 auto-compaction 自动启动。

仍然重要的 Prompting 技术

有几种基础 prompting 技术在 Opus 4.7 上仍然有效，你不应该因为模型更聪明了就放弃它们。

• 使用 XML tags 来组织复杂 prompts。将指令、上下文、示例和输入分别放在自己的标签中（<instructions>、<context>、<input>），以减少误解。
• 在 system prompt 中给 Claude 一个角色。哪怕只是一句话，也能聚焦行为和语气。
• 使用 3-5 个包裹在 <example> tags 中的示例，覆盖边界情况，并保持足够多样，以免模型学到非预期模式。
• 将长文本数据放在 prompt 顶部，放在你的查询之上。把查询放在末尾，在复杂、多文档输入上，响应质量最高可提升 30%。
• 用引用来锚定响应。对于长文档任务，先让 Claude 引用相关部分，再执行任务。

控制 tool 使用

Opus 4.7 默认调用 tools 的频率更低。若要增加 tool 使用，可提高 effort 或添加明确指导：“在有助于你理解问题时使用 [tool]。”

并行 tool 调用是一个值得利用的强项。模型会并行运行多个搜索、一次读取多个文件，并并行执行 bash commands。

你可以通过 XML tags 中的明确指导，将并行执行提升到接近 100%。

过度思考的缓解

在较高 effort level 下，Opus 4.7 可能会思考得非常多，从而抬高 thinking tokens。添加下面这条 prompt 以保持聚焦：

“当你决定如何处理一个问题时，选择一个方法并坚持下去。除非你遇到直接与你推理相矛盾的新信息，否则不要反复推翻决定。”

Agentic Systems：状态、安全性与多窗口工作流

对于长周期的 agentic 工作，Opus 4.7 在跨扩展会话的状态跟踪方面表现出色。几个模式可以让它更有效。

多上下文窗口工作流允许你在第一个上下文窗口中搭建框架（编写测试、创建 setup scripts），然后在后续窗口中围绕 todo list 迭代。让模型以结构化格式创建测试，比如 tests.json，以及像 init.sh 这样的 setup scripts，这样新的上下文窗口就能接上上一个窗口的工作。

状态管理在数据格式与内容匹配时效果最好。对测试结果和任务状态等结构化数据使用 JSON，对进度记录使用自由文本，对需要恢复的检查点使用 git。

平衡自主性与安全性需要一些指导。没有这些指导时，Opus 4.7 可能会采取难以逆转的动作，比如删除文件或强制 push。

添加一个可逆性提示来约束它：

“我们鼓励你采取本地的、可逆的动作，比如编辑文件或运行测试，但对于那些难以逆转或会影响共享系统的动作，在继续之前请先询问用户。”

明确减少过度工程化也很值得做。Opus 4.7 可能会创建额外文件、添加不必要的抽象，或者构建并未被要求的灵活性。

加入类似这样的指导：“只进行被直接要求或明显必要的更改。修复 bug 不需要顺带清理周边代码。”

减少幻觉的关键在于强制在回答前进行调查：“不要对你没有打开过的代码进行猜测。如果用户提到了某个具体文件，你必须在回答前阅读该文件。”

迁移清单

如果你要从 Opus 4.6 迁移到 4.7，以下内容需要更新。

1. 通过将 thinking: {type: "enabled", budget_tokens: N} 替换为 thinking: {type: "adaptive"} 来切换到 adaptive thinking。
2. 将 effort 设为 xhigh，这是编码工作的新默认值，并在 xhigh 或 max effort 下将 max output tokens 设为 64k。
3. 更新 code review prompts，将发现与过滤分开，以保留 recall。
4. 通过把上下文前置到第一条消息中来减少用户轮次，并添加明确的 subagent 指导，让模型知道何时展开。
5. 具体说明设计偏好，而不是依赖泛泛的指令去覆盖 house style。
6. 迁移掉 prefilled responses。从 Claude 4.6 模型开始，最后一个 assistant 轮次上的 prefilled responses 已被弃用，在 Mythos Preview 上它们会返回 400 error。

Computer use

Computer use 可在最高 2576px 或 3.75MP 的新上限范围内跨分辨率工作。发送 1080p 图像在性能和成本之间提供了最佳平衡。

对于对成本敏感的工作负载，720p 或 1366x768 是很强的低成本选项。

Bottom Line

Opus 4.7 奖励前置式说明，惩罚增量式、多轮次提示。这个模型比 4.6 更强大、更字面化，也更自主。

给它一个定义明确的任务，将 effort 设为 xhigh，然后让它运行。最能充分发挥这个模型价值的开发者，是那些不再逐步指导它，而是开始像委派给一位高级工程师那样去委派任务的人。

今天就试试：拿下一个编码任务，写一条包含意图、约束和验收标准的详细 prompt，然后在 xhigh 下用一轮发出去。把结果和 token 使用量与你原来的多轮模式比较一下。

差异会不言自明。

References:

• https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7
• https://x.com/trq212/status/2044548257058328723?s=20

• 原文链接： x.com/akshay_pachaar/sta...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～