Claude Opus 5 提示词指南

核心要点

• effort 只控制思考量、不控制输出长度：想让回复变短，必须在提示词里显式要求简洁，而非单纯调低 effort。
• 删掉遗留的"自我校验/复查"指令：Opus 5 会自发验证并纠错，保留旧的 verification 脚手架反而导致过度验证、浪费 token 且不提升质量。
• 主动约束任务边界：Opus 5 倾向自行扩大 scope、增加未被要求的步骤，窄任务要明确界定"只交付所要求的内容"。
• 给 subagent 委派设闸：它比旧模型更爱拆分 subagent，成本敏感场景应明确委派条件或设确定性上限。
• effort 分层用起来：low/medium 以极小 token 与延迟即可拿到高质量，作为成本主控；xhigh 留给高难 coding/agentic；换模型后务必用自己的 evals 重跑 effort sweep。
• 尽量别关 thinking：关闭 thinking 会偶发"工具调用被写成正文文本"和"内部 XML 标签泄漏"两类问题；多数任务下 low effort + 开启 thinking 比同等成本下关闭 thinking 表现更好。

原文 英文原文：Prompting Claude Opus 5

Claude Opus 5 提示词指南

针对 Claude Opus 5 的行为差异与提示词模式，涵盖回复冗长度、agentic 过程叙述、任务范围界定、subagent 委派、self-correction，以及关闭 thinking 时的输出产物问题。

本指南介绍 Claude Opus 5 特有的提示词模式。关于该模型的能力与 API 变更，参见 Claude Opus 5 新特性。关于适用于所有当前 Claude 模型的通用技巧，参见 提示词最佳实践。

Claude Opus 5 面向复杂的 agentic coding 与企业级工作而构建，尤其擅长长周期（long-horizon）的 agentic 任务。它在既有的 Claude Opus 4.8 提示词上开箱即用、表现良好。以下模式覆盖的是最常需要调优的那些行为。

> 从 Claude Opus 4.8 迁移时的 API 变更（thinking 默认开启，且关闭 thinking 时 effort 最高只能到 high），参见 迁移指南。

能力提升

与 Claude Opus 4.8 相比，与提示词最相关的提升有：

• Agentic coding： Claude Opus 5 在高难度 coding 任务上最为强劲——多文件特性、较大规模的重构、端到端的功能开发。它会完成整个任务，而不是留下桩代码或占位符；当你把完整的任务规格一次性给足、然后让它自行跑完时，它表现最好。它在单轮编辑这类较简单任务上也表现良好，只是相比旧模型的差距没那么大。
• 代码审查与找 bug： Claude Opus 5 审查代码时兼具高精确率（precision）与高召回率（recall）：单次 pass 就能以很高比例找到真实 bug，且它额外报出的问题大多是真问题而非误报（false positive）。在较低的 effort 设置下准确率依然保持，因此可以在审查时先跑一遍快审、之后再跑一遍更彻底的审查。如果你的审查提示词写着"只报告高危问题"或"保守一些"，模型可能会按字面执行、少报问题；应改为让它报告全部、再用单独的一遍来做过滤。
• 低 effort 下的效率： low 与 medium effort 能以更高设置零头的 token 与延迟产出高质量结果。从默认值（high）起步，再依据你的 evals 调整：只要质量不掉，就大胆把 low 和 medium 作为控制 token 成本和响应时间的主要手段；遇到高强度的 coding 与 agentic 工作再上调到 xhigh。如果你是从旧模型沿用了 effort 默认值，请在你自己的 evals 上重跑一轮 effort sweep。完整建议见 Effort。
• 视觉（Vision）： Claude Opus 5 在图表、文档、示意图理解，以及 UI 与前端的视觉复刻上都很强。请重新验证你为旧模型调过的任何提示词侧视觉 workaround，它们可能已经不再需要。当模型拥有工具来迭代地分析、裁剪并对自己的产出做视觉核验时，视觉表现最佳——而且相比单靠 thinking，tool use 是更划算的杠杆。
• 长上下文工作： Claude Opus 5 的 1M token 上下文窗口 既是默认值也是最大值，其指令遵循、工具调用与推理在整个窗口范围内都保持一致。
• 办公与文档任务： Claude Opus 5 能生成并处理包含复杂公式的多工作表（multi-sheet）电子表格，并能产出结构良好的幻灯片。若有需要遵循的特定样式或模板，请在提示词里给出。
• 多智能体协同： Claude Opus 5 能很好地协调一队 subagent，writer-verifier（撰写者—校验者）模式效果好，且很少出现智能体互相覆盖彼此工作的情况。对成本敏感的负载，应给委派设上限；参见 控制 subagent 的派生。

回复长度与冗长度

Claude Opus 5 面向用户的默认回复比旧版 Opus 模型更长。effort 参数 控制的是模型思考多少，而非说多少：调低 effort 可以减少思考量，但并不能可靠地缩短可见回复。要控制回复长度，请在提示词里明确要求。

一条简短的"简洁"指令就很有效。例如，对于面向用户的多轮产品：

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

在较长的 system prompt 中，把这条指令与提示词靠近末尾处的一句简短提醒搭配使用：

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

面向用户的进度更新

Claude Opus 5 在 agentic 工作中很爱做过程叙述（narrate）：它倾向于宣告自己接下来要做什么，且在 agentic 会话中每条消息的输出往往比旧模型更长。它能从"任务过程中该如何与用户沟通"的明确指引中获益。要把叙述调少，就描述你想要的节奏与形态：

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

要把叙述调多、或改变其风格，同一杠杆反向使用即可：明确描述更新应该长什么样，并给出示例。相比"不要做什么"的指令，给出你想要的沟通风格的正面示例（positive examples）往往更有效。

书面交付物的长度

除了对话式的冗长度之外，Claude Opus 5 写到磁盘上的文件（报告、Markdown 文档、摘要）往往也比旧模型更长。如果你的产品包含由 Claude 撰写的文档，请加上明确的长度校准：

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

任务范围与过度验证

Claude Opus 5 不用你叮嘱就会验证自己的工作。如果你的提示词里含有显式的验证指令（"对任何非平凡任务都加入最终验证步骤"、"用一个 subagent 来验证"），请删掉它们：这类指令会让 Claude Opus 5 过度验证，而删除它们能在不损失质量的前提下减少浪费的 token。对于那些额外加入独立验证步骤的遗留 harness 脚手架，同理处理。

Claude Opus 5 也可能扩大任务范围——加入没被要求的步骤，或按自己的判断改变任务本应是什么。对于窄任务，请明确约束 scope：

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

控制 subagent 的派生

Claude Opus 5 比旧模型更爱委派给 subagent。委派在真正独立、体量较大的工作分支上很划算，但用在小任务上就会成倍放大成本与耗时。如果你的 harness 支持 subagent，请明确指引哪些场景值得委派，或对可启动的智能体数量设确定性上限。例如：

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

Self-correction（自我纠错）

Claude Opus 5 无需提示就能很好地发现并修正自己的错误。请避免叮嘱它去做它本已在做的复查（"复核你的答案"、"回复前再验证一遍"）；和验证指令一样，这些会与模型自身的行为叠加，徒增成本却不改善结果。

该模型也比旧模型更频繁地对自己先前的表述做纠错叙述，这在面向用户的产品里可能并不理想。要把纠错叙述限定在真正重要的那些纠错上：

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

关闭 thinking 运行

Claude Opus 5 默认开启 thinking 运行，且只有在 effort 为 high 或更低时才能关闭 thinking；参见 迁移指南。关闭 thinking 后，模型的可见输出里偶尔会出现两类产物。对二者的首要缓解办法都是：保持 thinking 开启，改用较低的 effort 来控制 token 成本、而不是关闭 thinking——对多数任务而言，在相近成本下"开启 thinking + low effort"比"关闭 thinking"表现更好。

工具调用被当成文本输出。 关闭 thinking 后，模型偶尔会把一个工具调用写进面向用户的正文里，而不是发出一个结构化的 tool_use 块。这一轮会正常结束、而那个调用永远不会执行；在 agentic 循环里，泄漏出来的文本还会留在对话历史中，从而连带影响后续轮次。这在搜索这类工具密集型负载上最常见。

输出中出现内部 XML 标签。 关闭 thinking 后，模型可能会把 <thinking> 标签或其他内部 XML 标签发到它的可见回复里。如果你的 system prompt 含有一条"不要思考/不要推理"的规则，请删掉它；这类指令会加剧标签泄漏。

对于那些必须保持关闭 thinking 的集成场景，一条合并指令即可同时缓解这两类产物：它明确允许模型在工具调用前先说一句话、在没有合适工具时给出一个替代做法而非硬凑一个调用、以及一条禁止内部标签的通用规则：

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

按名字点出 thinking 标签的指令不如上面这种通用写法有效，因此避免专门去点它们的名。

Related Documents

• AI 技术博客索引
• Claude 5 代模型的上下文工程新规则
• 英文原文：Original