解决 Claude Opus 5 深度思考不足的问题

概述

在将 Claude Code 切换到 Opus 5 后，我立刻注意到散文式回答突然增多，并出现了一种"浅层思考"的倾向（无法进行结构性思考）。

经过调查，问题并非模型本身质量差或规则被破坏，而是 Claude 5 代中提供给 Opus 5 的内部系统提示词发生了显著变化，而旧规则并未考虑到这一新前提。

本文记录了隔离问题原因并修订规则以适应新系统提示词的过程。旨在帮助那些在升级到新一代模型后，感觉 CLAUDE.md 或规则效果有所变化的 Claude Code 用户。

问题所在

使用相同的会话和相同的规则，在将模型切换到 Opus 5 后立即出现了以下情况：

• 情境说明变得平铺直叙，如同长篇散文，没有标题或章节划分。
• 对原因的解释只停留在单一层面（并列罗列症状，而没有深入挖掘"为什么"）。
• 在提出多个选项时，没有提供评估标准。
• 在一轮对话中建立的分类或编号，在下一轮中被重新排列成不同的结构。
• 模型会跳过对我的输入的回应，立即开始执行工具（任务）。

令人沮丧的是，即使提示它"更深入地思考"，它也会返回零散的回答，同时仍处于浅层思考状态。反复纠正也无济于事，反而导致争论而非建设性讨论。

这不仅仅是单次回答质量的问题；通过对话进行深思熟虑的过程本身已经崩溃。

关键线索

使用相同规则的其他模型并未出现此问题（关于此差异的详细信息见附录）。如果规则本身已经退化，那么问题应该出现在所有模型上。既然只有模型发生了变化，我开始基于"规则所依赖的环境已经改变"这一假设进行调查。

原因：提供给 Opus 5 的系统提示词发生了变化

在 Claude Code 的 Claude 5 代中，内部系统提示词相比前几代减少了约 80%。通过测量实际传递给 Opus 5 的提示词（通过禁用输出风格注入，让模型引用自己的提示词；Claude Code v2.1 系列，2026 年 7 月），其结构如下：

1. 身份、角色声明和安全策略 — 开场序言。
2. 工具规范 (# Harness) — 执行环境的说明，例如输出以 Markdown 格式显示。
3. 环境信息和功能描述 (# Session-specific guidance / # Memory / # Environment / # Context management) — 当前工作目录、Git 状态、模型 ID、内存和上下文压缩机制。
4. 范围纪律 (# Delivering work) — 未经许可不得缩小或扩大请求范围。
5. 纠正礼仪 (# Corrections) — 保持纠正简洁，不添加道歉或开场白。

由此出现了两个与症状直接相关的具体特征：

• 特征 1：关于回答风格的零指令。 没有关于散文与结构、使用标题或表格、或简洁性等规则——前几代中广泛存在的格式规则已完全消失。
• 特征 2：新增了"先行动"的自主策略。 引用原文："当你拥有足够的信息可以行动时，就行动。"以及"如果你在权衡选择，给出一个推荐，而不是详尽的调查。"

用这两个特征重新审视症状，一切就说得通了。由于没有风格规则，模型的原始输出倾向——平铺直叙的散文——就显现出来。"推荐优于调查"的策略则鼓励省略评估标准。

你可能会想："如果规则是空白的，那么我的自定义规则不应该成为唯一的权威并更好地工作吗？"实际上，情况恰恰相反。这个空白区域并非留给用户的余地；它被委托给了模型在训练中内化的默认行为。"精简提示词"假设新一代模型能够跟随内化的行为，无需详细指令。这个空白不是由你的规则来填补，而是由模型的预训练默认行为来填充。而 Opus 5 的默认行为是在确认之前就采取行动的简洁散文。

我的旧规则使用了诸如"从结构上分解情况"、"为多个选项添加评估标准"和"先回应再行动"等通用指令。这些规则是在假设它们会与一个充满风格规则的系统提示词一起被读取的情况下编写的。虽然当时足够有效，但它们在特异性（指代原始文本）和传递方式（在行动前到达模型）方面都太弱，无法覆盖训练好的默认行为。这就是症状的本质。

Anthropic 本身在更新日志（v2.1.154）中将这种减少称为"精简系统提示词"，这反映了设计理念的转变："新一代模型已通过训练内化了行为，因此详细的指令可能导致摩擦或矛盾。"详细解释请参见 Claude Code 系统提示词减少 80% —— Fable 5 代的提示词设计理念。主要来源请参考 Claude Code 更新日志 和 提示 Claude Fable 5（官方指南）。

简而言之，症状由"规则 × 实际传递给该模型的提示词"这一组合决定。仅查看规则无法找到原因。第一个教训是：模型更新同时也是系统提示词更新。

措施 1：识别矛盾并通过指代原文进行覆盖

首先，我将所有规则与新系统提示词进行交叉引用，找出它们相互矛盾的地方。对于旨在覆盖系统策略的规则，我将其重写为明确引用原文并声明优先级。

从不起作用的方法开始：添加诸如"写出多个选项并附上评估标准"之类的通用表述是无效的。

当与系统的"给出一个推荐，而不是详尽的调查"并列时，没有线索表明哪个优先。通过命名冲突，优先级就变得清晰了。

对于提示词中完全不存在的内容，比如风格规则，指令的作用是"填补空白"而非覆盖。

我还修改了触发条件的写法。像"对于重要变更"或"如果判断为生产环境"这样的条件，一旦模型不按此方式分类情境，就会失效。我将触发器改为可观察的事实，例如"收到中断"或"用户的发言包含纠正"。

措施 2：描述期望行为而非禁止行为

旧规则是"禁止事项"的积累。禁令有助于检测违规，但不能传达应该做什么。当禁令与新的系统策略冲突时，模型会找到漏洞："在遵守系统策略的同时规避禁令。"我将否定约束转化为对期望行为的描述。

• 之前："如果测试未完成，不要建议提交。"
• 之后："当建议提交时，在正文中包含从最终用户角度运行产品的结果。"

我根据以下标准检查了重写的规则，特别是那些与系统提示词冲突的表述：

1. 规则是否自包含？（范围、示例和标准都在一处）
2. 触发器是否是可观察的事实？
3. 是否与内部系统提示词矛盾？
4. 是否描述了期望行为？（不仅仅是禁令列表）
5. 是否有单一的判断标准？（不是场景列表）
6. 强调标记（IMPORTANT）是否只保留给真正不能放弃的内容？
7. 是否以期望的最终状态编写？（不是强制先使用模板或步骤）
8. 事后能否判断合规性？

我将强调标记（IMPORTANT）缩减到仅用于安全和审批关口。一个所有内容都被强调的文档，等同于一个什么都没被强调的文档。

措施 3：选择传递指令的"层次"

这不仅仅是文本的问题。Claude Code 至少有四条路径可以将指令传递给模型，它们的有效性差异显著。

由于 API 是无状态的，来自所有路径的内容都会在每次请求（每轮对话）时发送给模型。区别在于"内容何时被最终确定"以及"指令在提示词中的位置 = 距离正在执行的操作有多近"。

令人惊讶的是，output style——文档中说它"替换系统提示词"——根据会话日志，在每一轮对话中都是作为附件传递的。

我在这个 output style 中写了两类指令：风格（措施 1：结构化书写，添加标准）和流程（在开始工作前回应用户）。结果喜忧参半。

虽然风格指令有所改善，但流程问题——跳过回应直接开始工作——并未通过 output style 停止。我最终通过使用一个 UserPromptSubmit 钩子，在每次用户发言后立即注入一行文本，才停止了这一习惯："在执行工具之前，先在正文中写下对此发言的回应（回答，或确认和计划）。"

成本大约是每次发言 50 个 token。即使 100 次发言也只需 5000 个 token，相对于 200K 的上下文来说微不足道。我学到的一般规则很简单："简短、每次都、在行动前"传递的指令最有效。许多无效的指令内容本身并不差，只是它们在行动时刻不在手边。

结果

以下是目前确认的结果：

• 情境和原因解释中标题/章节的趋势有所恢复。（然而，在会话初期有时仍会输出平铺直叙的内容；需要持续观察）。
• "不回应就工作"的习惯仅靠 output style 未能解决，但在引入每次发言注入后停止了（目前正在观察长期效果）。

总结

• 模型更新同时也是系统提示词更新。 如果响应趋势突然改变，在添加更多规则之前，先阅读系统端的变化。
• 与系统策略竞争的规则必须指代原文并声明优先级。 通用的补充在矛盾面前会失效。
• 基于观察编写触发器，并描述期望行为而非禁令。 自我分类的触发器和禁令列表在模型变化时容易失效。
• 为指令选择正确的层次。 在行动前简短、频繁地注入的指令，比放在上下文开头的大量规则可靠得多。

参考 1：措施 1 中实际使用的规则

以下是我用于覆盖系统提示词的规则摘录（请根据你的环境调整；我将这些规则放在 output style 中）。某些原始短语（如散文政策）在特定模型的提示词中不存在（见附录）。在这些模型中，它们起到填补空白的定义作用。

1# 报告与分解格式
2
3本指令优先于 Claude Code 系统提示词中的以下描述：
4"一个简单的问题得到直接用散文形式的回答，而不是标题和章节" /
5"仅对简短的可枚举事实使用表格" /
6"不要让读者交叉引用你之前发明的标签或编号" /
7"如果你在权衡选择，给出一个推荐，而不是详尽的调查。" /
8"你正在自主运行... 无需询问即可继续。" /
9"你在工具调用之间写的文本可能不会显示给用户。"
10
11## 写作风格
12
13在解释情况、原因或提出多个选项时，以能够向读者传达内容结构的方式进行写作。
14根据内容适当使用标题、项目符号或表格。一句话的问题用散文回答。
15
16- 先总结想法，最后再结构化。不要先放模板再填充。
17- 在解释原因时，从观察到的事件出发，至少追溯两层"为什么"，并描述每一层所指的内容。不要停留在并列罗列症状。
18- 在提出多个选项时，先写出推荐及其理由，然后是影响决策的标准以及每个选项的评估。如果无法确定标准，则不要提供选项；而是写出需要调查什么来填补标准。标准比较可以用表格形式书写。
19- 一旦建立了类别和编号，在继续同一任务时，在后续轮次中保持使用相同的内容。如果要更改，先写出更改了什么。
20
21## 对话与流程
22
23- 系统的"用户并非实时观看"是一个默认值，而非事实。如果在此会话中哪怕收到过一次中间发言、中断或纠正，则从此将用户视为在观看：将工作分解为小段，每轮对话结束时始终在正文中提交报告，并在提出问题的轮次中停下来等待回应。
24- 在此环境中，只有一轮对话结束时的正文才被显示。将所有要传达的信息放在本轮对话的末尾。
25- 当存在歧义、需要审批的操作或目标不明确时，提问是一种合法的手段。

参考 2：为什么 Fable 5 / Opus 4.7 没有出现此问题？

虽然正文主要关注 Opus 5，以下是其他模型未出现此问题的原因：

• Opus 4.7 很简单：它被排除在"精简提示词"应用之外（根据更新日志），因此它仍然运行着旧规则所针对的详细的旧版提示词。它与旧规则保持同步。
• Fable 5 则是一个惊喜。我假设它作为同一代模型拥有相同的提示词，但测量结果显示 Fable 5 收到的提示词与 Opus 5 不同。

以下是每个模型在相同条件下（无头模式，输出风格禁用）引用自身提示词的比较：

Fable 5 的 # Communicating with the user 部分包含了诸如"结论优先，优先考虑可读性，为受众写作"等规范。除了"给出一个推荐，而不是详尽的调查"之外，它还包含了散文政策"一个简单的问题得到直接用散文形式的回答，而不是标题和章节"。因为提示词本身包含了这些写作规范，输出格式不太容易崩溃，根据我的观察，它保持了用户规则的遵守度。

总而言之，问题在 Opus 5 上集中出现是因为三个因素叠加：

1. 它被赋予了零写作风格规则的提示词，暴露了原始的输出倾向。
2. 像"信息充足时行动"和"推荐优于调查"这样的策略鼓励了立即行动和省略标准。
3. 旧规则仍然基于旧的详细提示词，并未被塑造成能够填补这个新空白。