Claude Opus 4.7 不是 4.6 的直接替代品

新的 xhigh 努力级别、自适应思考和 1M 上下文窗口，将如何改变你与 Claude 最强模型的提示方式、任务委派方式以及会话管理方式。

你刚升级到 Claude Opus 4.7。提示词没变，框架没变，但 token 账单翻了一倍，代码审查的召回率却下降了。这是为什么？

Opus 4.7 不是 4.6 的直接替代品。它的思考方式不同，遵循指令更字面化，生成子智能体更少，并且在每次用户发言后都会进行更积极的推理。之前有效的模式，现在只会白白消耗 token，却不会带来相应的质量提升。

解决方法并不复杂，但需要你理解发生了什么变化，并相应调整工作流程。我们来逐一梳理。

委派思维

使用 Opus 4.7 最大的转变在于如何定位自己的角色。把 Claude 当成一位你委派任务的能干工程师，而不是你一行一行手把手指导的结对编程伙伴。

在交互式会话中，每一次用户发言都会触发推理开销。使用 4.6 时，你可以把指令分散在多个对话轮次中，代价不大。但在 4.7 中，这种模式会膨胀 token 用量，因为模型在收到你每条消息后都会进行深度推理。无论这条消息是否值得，你都要为推理买单。

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

• 第一，在第一轮对话中就明确任务。 包含意图、约束条件、验收标准以及相关文件路径。含糊的提示词分散在多个轮次中，既降低 token 效率，也降低输出质量。
• 第二，批量提问。 每条用户消息都会增加推理开销，所以要给模型足够的上下文，让它能持续推进，无需频繁确认。
• 第三，对可信任的任务使用自动模式。 对于已经提供完整上下文的长期任务，自动模式（Shift+Tab）可以通过减少不必要的确认环节来缩短循环时间。该功能目前在 Claude Code Max 用户的研究预览版中提供。

你也可以让 Claude 在完成任务时播放一个声音提示。它会自行创建基于钩子的通知，你不必一直盯着它干活。

5 个努力级别，以及为何 xhigh 成为新默认值

Opus 4.7 引入了 xhigh，这是一个介于 high 和 max 之间的新努力级别，现在是 Claude Code 的默认设置。如果你是从未手动设置过努力级别的老用户，你已经被自动升级到 xhigh。

以下是五个档位的说明：

• low 适用于对延迟敏感、范围严格限定的工作。模型不会过度发挥，但在相同努力级别下仍优于 Opus 4.6。
• medium 适合成本敏感型任务，你愿意以智能换速度。
• high 在智能与成本之间取得平衡。适合并发会话或预算有限但不想有大幅质量损失的工作。
• xhigh 是默认值，也是编码和智能体任务的最佳选择。你能获得强大的自主性和智能，同时不会像 max 那样产生失控的 token 用量。
• max 能在真正困难的问题上榨取更多性能，但边际收益递减。它更容易过度思考，因此要有针对性地用于测评上限测试或对智能要求极高的工作。

一个实用建议：你可以在任务进行中途切换努力级别。复杂的设计阶段从 xhigh 开始，直接的实现阶段降到 high，棘手的调试阶段再提到 max。这让你能对 token 支出进行精细控制。

Opus 4.7 比 4.6 更严格地遵守努力级别设置。如果某个任务在 low 或 medium 下感觉思考不足，请提高努力级别，而不是绕着弯子改提示词。

自适应思考取代固定预算

如果你在 Opus 4.6 上使用了带 budget_tokens 的 Extended Thinking，这个功能已经没有了。Opus 4.7 改用自适应思考。

这个区别很重要。固定预算模式下，你预先分配固定数量的思考 token，模型不管需不需要都会用掉。自适应思考模式下，模型自己决定在每个步骤中何时思考、思考多少。简单的查询得到快速响应，复杂的推理步骤获得深度思考，不需要思考的步骤则直接跳过。

在一次长时间的智能体运行中，与一刀切的思考预算相比，这会带来更快的响应速度和更低的 token 用量。

迁移方式很直接：将 thinking: {type: "enabled", budget_tokens: N} 替换为 thinking: {type: "adaptive"}。

你仍然可以通过提示词来引导思考程度。想获得更多思考，可以试试：“在回答前请仔细逐步思考，这个问题比看起来更难。“想减少思考，可以用：“优先快速响应而不是深度思考。如有疑问，直接回答。”

如果你在 max 或 xhigh 努力级别下运行，请设置一个较大的最大输出 token 预算（从 64k 开始），让模型有足够的空间在子智能体和工具调用之间进行思考和行动。

会让你踩坑的行为变化

Opus 4.7 附带了几项默认行为变化，如果你为 4.6 调优过提示词或框架，这些变化会让你猝不及防。我们逐一过一遍。

响应长度

Opus 4.7 会根据任务复杂度来校准响应长度。简单的查找给出简短答案，开放式分析给出详尽答案。如果你的使用场景依赖特定的长度或风格，请明确说明。正面示例（你想要的风格）比负面的“不要这样做“指令效果更好。

更少的工具调用

模型调用工具的频率降低，推理更多。在很多情况下这能带来更好的结果。但如果你需要更积极地使用工具进行搜索或文件读取，请提供关于何时及为何应该使用工具的明确指导。将努力级别提高到 high 或 xhigh 也会增加工具使用频率。

更少的子智能体

Opus 4.7 在委派子智能体方面更加审慎。如果你的工作流依赖并行扇出，请明确说明：

“对于你能在单次响应中直接完成的工作，不要生成子智能体。当需要跨多个条目扇出或读取多个文件时，在同一轮次中生成多个子智能体。”

更字面化的指令遵循

这是最可能破坏现有设置的变化。Opus 4.7 对提示词的解释更加字面化，尤其是在较低努力级别下。它不会默默地将一条指令从一个条目泛化到另一个，也不会推断你没有明确提出的请求。

好处是精确、少折腾。坏处是如果你需要将某条指令广泛应用，必须明确说明范围。例如：“将此格式应用于每个章节，而不仅仅是第一个。”

语气变化

Opus 4.7 比 4.6 更直接、更有主见，减少了认可性措辞，emoji 也比 4.6 温暖风格少了很多。如果你的产品依赖特定的语态风格，请根据新基准重新评估你的风格提示词。

代码审查

Opus 4.7 在发现 bug 方面有显著提升。根据 Anthropic 基于真实 PR 的最难 bug 查找测评，它的召回率提高了 11 个百分点，精确率也更高。

但问题在于：如果你的审查框架说“只报告高严重性问题“或“保守一点“，Opus 4.7 会比 4.6 更忠实地遵守这条指令。它可能同样彻底地检查了代码、识别出了 bug，却不报告它认为低于你设定标准的发现。精确率上升，但测量到的召回率下降。

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

报告你发现的每一个问题，包括你不确定的或认为低严重性的。在这个阶段不要根据重要性或置信度进行过滤。你的目标是覆盖率：发现一个后来被过滤掉的问题，好过悄悄漏掉一个真实的 bug。对于每个发现，请注明你的置信度和预估严重性，以便下游过滤器对其排序。

如果你需要单次过滤，请具体说明标准，而不是使用定性描述。例如：“报告任何可能导致行为错误、测试失败或误导性结果的 bug；仅省略纯粹的代码风格或命名偏好问题。”

使用 1M 上下文进行会话管理

Claude Code 现在拥有 100 万 token 的上下文窗口，足以在单次会话中从头构建一个全栈应用。但更多上下文并不总意味着更好的结果。

上下文腐化是真实存在的。 随着上下文增长，注意力分散在更多 token 上。较早的、不相关的内容开始干扰当前任务，随着上下文窗口填满，模型的智能程度会下降。

“迷失在中间“效应： 你在每个轮次都有五个选项。

• 继续（Continue） 意味着发送下一条消息。当窗口中的所有内容仍然相关时使用。
• 回退（Rewind）（双击 Esc）跳回到之前的某条消息，从那里重新提示。失败的尝试会从上下文中删除，这通常比输入“那个不行，试试 X“更好，因为你保留了有用的文件读取记录，同时去掉了失败的方案。
• /compact 加提示 会汇总会话并继续运行。这是有损的，但操作简便，你可以通过指令引导它，例如 /compact 专注于 auth 重构，去掉测试调试的部分。
• /clear 开始全新会话。你自己记录重要的内容，零腐化，完全可控。
• 子智能体（Subagents） 将会产生大量中间输出的工作委派出去。子智能体有自己全新的上下文窗口，只有最终结果会返回。

判断标准很简单：你之后还需要工具输出内容本身，还是只需要结论？如果只需要结论，就用子智能体。

什么导致糟糕的自动压缩

当你接近上下文限制时，自动压缩会触发。问题在于，这恰恰是模型因上下文腐化而智能程度最低的时候。

一个常见的失败场景：在漫长的调试会话后，autocompact 触发并汇总了整个调查过程。你的下一条消息引用了被汇总时丢掉的某些内容。

有了 100 万上下文，你有更充裕的时间主动压缩，并说明哪些内容重要。不要等到自动压缩触发。

仍然有效的提示技巧

一些基础提示技巧在 Opus 4.7 中依然有效，不要因为模型更聪明就放弃它们。

• 使用 XML 标签来结构化复杂提示词。将指令、上下文、示例和输入分别包裹在各自的标签中（<instructions>、<context>、<examples>），以减少误解。
• 在系统提示中给 Claude 一个角色。哪怕只是一句话，也能聚焦行为和语气。
• 使用 3-5 个包裹在标签中的示例，覆盖边缘案例，并保持足够的多样性，避免模型学到非预期的模式。
• 将长篇数据放在提示词顶部，在查询内容之前。在复杂的多文档输入中，将查询放在末尾可将响应质量提高多达 30%。
• 用引用来锚定响应。对于长文档任务，让 Claude 在执行任务前先引用相关部分。

控制工具调用

Opus 4.7 默认调用工具的频率较低。要增加工具使用，请提高努力级别或添加明确指导：“当使用 [工具] 有助于你理解问题时，请使用它。”

并行工具调用是值得善加利用的优势。模型会同时运行多个搜索、一次读取多个文件、并行执行 bash 命令。你可以通过在 XML 标签中提供明确指导，将并行执行率提升到接近 100%。

缓解过度思考

在较高努力级别下，Opus 4.7 可能会进行大量思考，导致思考 token 膨胀。添加以下提示词以保持专注：

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

智能体系统：状态、安全性与多窗口工作流

对于长时程智能体工作，Opus 4.7 在跨扩展会话的状态追踪方面表现出色。以下几种模式可以让它更加高效。

多上下文窗口工作流 让你用第一个上下文窗口搭建框架（编写测试、创建配置脚本），再用后续窗口迭代处理待办列表。让模型以结构化格式（如 tests.json）创建测试，以 init.sh 等脚本创建配置，以便新的上下文窗口能接续上一个的工作。

状态管理 最好的做法是将格式与数据匹配。结构化数据（如测试结果和任务状态）使用 JSON，进度记录使用自由文本，可以还原的检查点使用 git。

平衡自主性与安全性 需要一些引导。没有引导，Opus 4.7 可能会采取难以撤销的操作，比如删除文件或强制推送。添加可逆性提示来加以约束：

“鼓励你采取本地的、可逆的操作，如编辑文件或运行测试；但对于难以撤销或影响共享系统的操作，请在执行前询问用户。”

减少过度工程化 也值得明确要求。Opus 4.7 可能会创建多余的文件、添加不必要的抽象，或构建你未曾要求的灵活性。添加如下指导：“只进行直接被要求或明确必要的修改。修复一个 bug 不需要顺手清理周围的代码。”

减少幻觉 的关键在于强制要求先调查再回答：“绝不对你未打开过的代码进行推测。如果用户引用了某个具体文件，你必须先读取该文件再回答。”

迁移清单

如果你正在从 Opus 4.6 迁移到 4.7，以下是需要更新的内容：

• 切换到自适应思考，将 thinking: {type: "enabled", budget_tokens: N} 替换为 thinking: {type: "adaptive"}。
• 将努力级别设置为 xhigh（这是编码工作的新默认值），并在 xhigh 或 max 努力级别下将最大输出 token 设置为 64k。
• 更新代码审查提示词，将“发现“与“过滤“分离，以保留召回率。
• 通过将上下文前置到第一条消息中来减少用户发言轮次，并添加明确的子智能体指导，让模型知道何时进行扇出。
• 具体说明设计偏好，而不是依赖通用指令来覆盖默认风格。
• 弃用预填充响应的用法。从 Claude 4.6 模型开始，最后一个 assistant 轮次的预填充响应已被废弃，在 Mythos Preview 中会返回 400 错误。

计算机使用

计算机使用现在支持最高 2576px 或 3.75MP 的分辨率。以 1080p 发送图像可在性能和成本之间取得最佳平衡。对于成本敏感型工作负载，720p 或 1366x768 是不错的低成本选项。

总结

Opus 4.7 奖励前置规范，惩罚逐步、多轮的提示方式。这个模型比 4.6 更有能力、更字面化、更自主。给它一个规范明确的任务，设置努力级别为 xhigh，然后让它运行。

能从这个模型中获益最多的开发者，是那些停止一步步手把手引导它、转而像对待高级工程师一样进行委派的人。

今天就试试：把你下一个编码任务，写成一条包含意图、约束条件和验收标准的详细提示词，在 xhigh 模式下一次性发出。将结果和 token 用量与你原来的多轮模式进行对比，差距会不言自明。

参考资料：

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

就这些！如果你喜欢这篇文章，欢迎关注 → @akshay_pachaar ✔️ 我每天分享 AI、机器学习以及 vibe coding 最佳实践的教程与见解。