先删：所有让它自己验一遍的话

这是整份文档里最该先做的一件事。要删的句子分两类，长得都很眼熟。

第一类是任务级的验证要求，典型写法是「任何不简单的任务都要包含一个最终验证步骤」「用一个子代理来验证」。第二类是回答级的自查要求，典型写法是「再检查一遍你的答案」「回答之前重新确认」。两类的处置一样：删。

要删的不止提示词里的句子。文档特意点了一句：那些为了老模型搭的流程脚手架（harness），如果里面有一个单独的验证环节，也要一起拆掉。提示词是你对模型说的话，脚手架是你写在外面的流程代码，管什么时候调模型、调几次、每次给什么。两层都得清。

审查提示写「只报严重的」，它会真的少报

这一条最反直觉，也最容易在自己那套自动化流程里踩到。

先看前提：Opus 5 审代码的准确率和覆盖率都高，每一轮能捞出真 bug 的比例很高，而且它多报出来的那些，大部分也是真问题，不是误报凑数。更实用的一点是，这个准确率在思考力度调低时也保持得住，所以审查时可以先用便宜的档位快扫一轮，之后再细审一轮。

问题出在你怎么写筛选条件。如果提示词里有「只报告高严重度的问题」或者「保守一点」，Opus 5 可能按字面执行，于是报得更少。文档给的解法是把筛选从提示词里挪出来：让它全都报，另外开一轮去筛。

两种写法的差别，说到最实处是一句话：谁来定什么算严重。写进提示词，就等于把这个判断交给模型在你看不见的地方做完；单独开一轮，这个判断才在你手上。

它变啰嗦的三个地方，要分开按

Opus 5 默认给用户看的回答，比上一代的 Opus 长。很多人的第一反应是调低档位省点字，这条路走不通，得先弄清 effort 这个参数到底管什么。

effort（思考力度）管的是模型这次愿意花多少 token 去想，不是它最后说多少。调低它，思考量会下来，可见回答的长度却不一定跟着短。想让它说得短，只能明着要求。

第一处：给用户看的回答

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>

第二处：写到磁盘上的文件

这一处跟对话里的啰嗦是两码事，需要单独按。Opus 5 写出来的报告、Markdown 文档、总结文件，篇幅也比上一代长。如果你的产品会让它生成文档交给用户，得给一条明确的长度校准。

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.

第三处：干活时的播报

Opus 5 在放手让它自己跑（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.

想让它多播报，或者换一种播报风格，用的是同一个杠杆的反方向。这里还带出一条通用的手艺：给出你想要的沟通风格的正面例子，比列一堆「不许这样」有效。

它派子代理比以前积极，小活也派

子代理（subagent）是主模型把一块工作拆出去，交给一个新开的分身独立干完再交回来。每个分身自己读一遍上下文、自己生成一遍，各烧各的 token。

Opus 5 派活比上一代积极。这在真正独立、体量够大的任务上是划算的，比如一次要横跨很多文件的调查；但用在小任务上，成本和时间都是乘出来的。

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.

这段里有一句跟上面第二节咬合上了：不要用子代理来复核自己的工作。同一个毛病在两个地方各堵一次，一次堵在验证行为本身，一次堵在派活习惯上。

还有一条更硬的办法：如果你的外层流程支持，直接在代码里写死能开几个分身。提示词是劝，脚手架里的上限是拦。成本敏感的场景两样一起上。

它会自己给任务加戏

除了验证得过头，Opus 5 还会自行扩大任务的范围：加上没被要求的步骤，或者用自己的判断去重新定义这个任务应该是什么。对于范围明确的窄任务，需要把边界写死。

文档给的这段是八段里最长也最讲究的一段。它同时要防四个方向的跑偏，拆开看每一句在管什么：

这段措辞跟 Claude Code 默认系统提示里那几段的写法高度接近（这是本站的观察，文档没有交代两者的关系）。如果你在自己的项目里写过类似的边界约束，可以直接对照着补齐缺的那几句。

思考默认开着，关掉会出两种毛病

Opus 5 和上一代之间有一个真正的机制变更：在 Opus 4.8 上，请求里不写 thinking 字段就是不思考；在 Opus 5 上，同样的请求会带着思考跑。想回到旧行为，得自己手动加一句 thinking: {"type": "disabled"}。

而且这个开关是有条件的：只有 effort 在 high 及以下才允许关思考。配上 xhigh 或 max 会直接返回 400 错误，每个请求单独校验（报错码和每请求校验这两点来自 Anthropic 的迁移指南，档位上限本身在这页提示指南里就写了）。

真关掉之后，有两种毛病偶尔会冒出来。第一种更贵，因为它是静默的。

这种情况在工具用得密的场景里最常见，比如搜索类的活。第二种毛病相对好认：模型把 <thinking> 之类的内部标签吐进了用户能看见的回答里。

第二种毛病连着一个反直觉的坑：如果你的系统提示里有一条规则，叫模型「不要思考」或者「不要推理」，把它删掉，这类指令会让标签漏得更多。同理，点名 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.

三句话各自对着一个成因：第一句给它「调工具之前可以先说话」的许可，它就不必把话挤进调用里；第二句给它一条没有合适工具时的退路，免得硬凑一个；第三句是通用的标签禁令，不点名任何一种标签。

五档 effort 怎么挑，以及一个会报 400 的组合

提示指南本身只用一段话带过档位建议，完整的档位表在 Anthropic 的 Effort 文档里。这一节的材料主要来自那一页和迁移指南，不是从提示指南里抄的。

Opus 5 的推荐是：从默认的 high 起步，然后按你自己那套评测往两边调，硬的编码和 agentic 工作往上到 xhigh，值得不计成本的任务再上 max；而 low 和 medium 应该放开用，只要评测显示质量守得住，就把它们当成控制 token 成本和响应时间的首选杠杆。

这个起步点跟上一代不一样，值得单独拎出来。Opus 4.8 的官方推荐是「编码和 agentic 从 xhigh 起步」，到 Opus 5 改成了「从 high 起步」。同一份能力清单里还写着一条：low 和 medium 现在能用高档位一小部分的 token 和延迟，跑出很不错的质量。

提示缓存是把提示词里重复不变的那部分存起来，下次再发同样的开头就不用重新算钱、也不用重新等。门槛从 1024 降到 512，意味着以前太短进不了缓存的提示，现在也能省下这笔。

三个配套动作，做自动化流程都会碰到。一是从旧模型迁过来时，别把旧的档位设置直接抄过来，拿你平时最常跑的那些真实任务凑一组，新旧档位各跑一遍比对结果。二是那些原来在 Opus 4.8 上不带思考跑的任务，换过来之后会带着思考跑，而 max_tokens 管的是思考加回答的总量，这个值要回头再看一眼。三是改档位会让提示缓存失效，一个依赖缓存的长会话里，开头选定一档就别中途换，要换也是跨任务换。

一页纸：老提示词删什么、加什么

把上面八节压回一张可执行的清单。删的三条放在最前面，因为它们不花钱、立刻见效。

还有一段没在正文单列

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.

这份文档没给的东西

「回答更长」「播报更多」「更爱派子代理」，这几条全是定性描述，一个百分比都没有。到底比上一代长多少、多多少，读者没法预期，只能自己跑一轮对照。同样，「删掉验证指令能省 token 且质量不掉」是给出的结论，没有附对照数据；「开着思考跑低档比关掉思考更好」也一样，是判断，不是实测数字。

能确定的是那八段提示词本身：它们是可以原样复制的材料，改与不改，拿自己常跑的任务前后各试一轮就知道。

要删的句子分两类，长得都很眼熟：任务级的「最后加一步验证」「用子代理复核」，和回答级的「再检查一遍你的答案」。

要清的不止提示词。为老模型搭的外层流程代码（harness，包在模型外面管什么时候调、调几次的那层）里如果挂着一个单独的验证环节，也要一起拆。

Opus 5 审代码的准确率和覆盖率都高，思考力度调低也守得住，所以适合先快扫一轮再细审一轮。出事的地方在于筛选条件写在哪。

Opus 5 比上一代话多，也更爱把活派出去。第一反应通常是把 effort（思考力度，管它这次愿意花多少 token 去想的那个旋钮）调低，这条路走不通。

• 给用户看的回答 ， 要求它写短；系统提示很长的话，末尾再补一句短提醒
• 写到磁盘的文档 ， 报告和文件的篇幅是另一层，单独校准
• 干活时的播报 ， 描述你要的节奏，正面例子比列一堆禁令有效
• 派子代理（把一块活交给新开的分身独立干完，各烧各的 token）， 只有真能拆开并行的大活才派；小活派三个分身，账单和等待都是乘出来的
• 任务范围 ， 允许它提一句意见，但要求它按原样做完，别悄悄缩小、放大或改成别的

连上「少念叨自己刚才说错了」和「必须关思考时」那两段，文档一共给了八段可以原样复制进系统提示的英文提示词，全文里逐段附了中译。

Opus 4.8 上不写 thinking 字段就是不思考；Opus 5 上同样的请求会带着思考跑。想关掉得手动写一句，而且只有 effort 在 high 及以下才允许关。

上面三个数出自 Anthropic 的 Effort 文档与迁移指南，不在这页提示指南里。至于「回答更长」「更爱派子代理」，Anthropic 一个百分比也没给，差多少得自己跑一轮对照。