核心思想
Claude Opus 5 面向复杂的智能体式编码与企业工作，开箱即可较好承接既有 Opus 4.8 提示；但它默认更「勤快」——用户可见回复更长、过程旁白更多，并会主动自验证与委派子智能体。调优主轴不是堆叠旧护栏，而是用短指令约束冗长度、旁白节奏、任务范围与委派门槛，并删掉已冗余的验证/再检查指令。关闭思考（thinking）时偶有工具调用文本化或内部 XML 泄漏：优先用「开启思考 + 较低努力度」替代硬关。
本指南介绍专门针对 Claude Opus 5 的提示模式。关于模型能力与 API 变更，请参阅 Claude Opus 5 的新特性。关于适用于所有当前 Claude 模型的通用技巧，请参阅提示最佳实践。
Claude Opus 5 面向复杂的智能体式（agentic）编码与企业工作而构建，在长程（long-horizon）智能体任务上尤为擅长。它在既有的 Claude Opus 4.8 提示上开箱表现良好。下文模式覆盖了最常需要调优的那些行为。
从 Claude Opus 4.8 迁移时的 API 变更（默认开启思考；关闭思考时努力度最高仅到 high），请参阅迁移指南。
能力提升
与 Claude Opus 4.8 相比，与提示最相关的提升包括：
- 智能体式编码： Claude Opus 5 在困难编码任务上最强：多文件功能、较大规模重构，以及端到端的功能交付。它会把完整任务做完，而不是留下桩代码（stub）或占位（placeholder）；在一开始就给出完整任务规格并让它自行推进时表现最佳。在单轮编辑等较简单任务上同样可靠，与前代模型的差距更小。
- 代码审查与找缺陷： Claude Opus 5 审查代码时精确率（precision）与召回率（recall）都高：每一遍都能以很高的真实缺陷发现率找到问题，额外发现也大多是真问题而非误报。在较低努力度（effort）下准确率依然站得住，因此适合审查时先做快速一遍、稍后再做更彻底的一遍。若审查提示写着「只报告高严重度问题」或「保守一些」，模型可能字面遵循而少报；应要求它报告全部发现，再另开一遍过滤。
- 较低努力度下的效率：
low与medium努力度（effort）能以更高设置几分之一的 token 与延迟产出扎实质量。从默认（high）起步，再按你的评测（evals）调整：凡质量站得住，就大胆把low/medium当作控制 token 成本与响应时间的主旋钮；对高要求的编码与智能体工作再升到xhigh。若努力度默认是从前代模型沿用的，请在自己的评测上重新扫一遍努力度。完整建议见 Effort。 - 视觉： Claude Opus 5 擅长图表、文档与示意图理解，以及 UI/前端视觉复刻。请重新验证你为前代模型调过、写在提示里的视觉变通做法——它们可能已不再需要。当模型有工具可迭代分析、裁剪并视觉校验自己的工作时，视觉表现最强；工具使用往往比单靠思考更划算。
- 长上下文工作： Claude Opus 5 的上下文窗口默认与上限均为 100 万 token，且指令遵循、工具调用与推理在整个窗口内保持稳定。
- 办公与文档任务： Claude Opus 5 能生成并处理含非平凡公式的复杂多工作表电子表格，也能产出结构良好的幻灯片。请在提示中写明需要遵循的具体样式或模板。
- 多智能体协调： Claude Opus 5 能良好协调子智能体（subagent）团队，有效运用 writer-verifier（写作者-验证者）模式，智能体互相覆盖彼此工作的情况也很少。对成本敏感的负载，请限制委派规模；见控制子智能体生成。
回复长度与冗长度
Claude Opus 5 默认的用户可见回复比此前的 Opus 模型更长。[努力度参数](：降低努力度可以减少思考量，但并不总能可靠地缩短可见回复。要控制回复长度，请在提示中明确要求。
一段简短的简洁性指令就有效。例如，面向用户的多轮产品：
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.
在较长的系统提示中，把该指令与提示末尾附近的一句短提醒一起使用：
<tone_preference>
Keep outputs reasonably concise.
</tone_preference>
面向用户的进度更新
在智能体式工作中，Claude Opus 5 很愿意做过程叙述（narration）：它倾向于预告接下来要做什么，且智能体会话中每条消息的输出往往比前代更长。它受益于关于任务进行中如何与用户沟通的明确指引。要压低旁白，请描述你想要的节奏与形态：
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.
要抬高旁白或改变其风格，同一杠杆反向使用：明确描述更新应是什么样的，并给出示例。你希望的沟通风格的正面示例，通常比「不要怎样」的禁令更有效。
书面交付物长度
与对话中的冗长度是另一回事：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 无需被告知就会验证自己的工作。若提示中含有显式验证指令（「对任何非平凡任务包含最终验证步骤」「用子智能体验证」），请删掉它们：在 Claude Opus 5 上，这类指令会引发过度验证（over-verification），去掉后能减少浪费的 token 且不损质量。在 harness（编排/脚手架）里额外插入独立验证步骤的旧脚手架（scaffolding）同理。
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.
控制子智能体生成
Claude Opus 5 比前代模型更愿意把工作委派给子智能体。委派在真正独立、体量可观的并行工作线上划算，但用在小任务上会成倍放大成本与时间。若你的 harness 支持子智能体，请明确哪些场景才值得委派，或对可启动的智能体数量设确定性上限。例如：
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.
自我纠正
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.
在关闭思考的情况下运行
Claude Opus 5 默认开启思考（thinking），且仅在努力度为 high 或以下时可关闭思考；见迁移指南。关闭思考时，模型的可见输出中偶尔会出现两类产物。对二者的首要缓解都是：保持思考开启，用更低努力度控制 token 成本，而不是关闭思考——对大多数任务，开启思考且努力度为 low，比在相近成本下关闭思考表现更好。
把工具调用写成文本。 关闭思考时，模型偶尔会把工具调用写进面向用户的文本，而不是发出结构化的 tool_use 块。该回合会正常结束，但调用从未执行；在智能体循环中，泄漏的文本还会留在对话历史里，影响后续回合。这在搜索等工具密集型负载上最常见。
输出中的内部 XML 标签。 关闭思考时，模型可能把 <thinking> 标签或其他内部 XML 标签写进可见回复。若系统提示中有「不要思考」或「不要推理」一类规则，请删除；这类指令会加重标签泄漏。
对必须保持关闭思考的集成，一条合并指令可同时缓解两类产物：它明确允许在工具调用前先说一句、在无合适工具时给出替代说法，并给出针对内部标签的一般规则：
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 标签的指令，效果不如上述一般形式，因此不要具体点名这些标签。
相关笔记
- 为 Claude Fable 5 编写提示词 —— 姊妹篇：Fable 5 / Mythos 5 的长程自主、effort 与脚手架调优
- Claude 提示工程最佳实践 —— 全模型通用提示技巧
- Claude 5 模型的上下文工程新规则 —— Claude 5 代上下文与系统提示瘦身
- 用 Fable 5 设计循环：自我修正与记忆 —— 循环设计视角下的自我修正与记忆
- Skill 编写最佳实践 —— 技能文件写法，可与模型专属提示配合