Claude Opus 5.5 官方提示词指南：别再教它“仔细思考”了

Anthropic 在 9 月 22 日发布了 Claude Opus 5.5，同一天上线的还有一篇 官方提示词指南《Prompting Claude Opus 5.5》。

有意思的是，官方开头就把话说得很直白：你用在 Opus 5 上的提示词，直接搬过来基本不会差。这篇指南真正在意的，是哪些地方改了会更好、哪些地方不改会直接报错。

它的组织方式也和以往不同，是按“你遇到的问题”来分节的。开头先甩了一张问题清单：不知道该用哪档 effort、之前在 Opus 5 上关掉了 thinking、无人值守的 Agent 汇报完就停在了中途、读密集图表漏掉细节、做出来的前端太千篇一律……遇到哪个，就去翻对应的那节。

下面我把自己认为最核心的几个点整理出来，分享给你。

先说能力：它最擅长“一口气干完”长活

Opus 5.5 最明显的长进，是在真实代码库里完成多步骤任务。比如把一个改动一路推进到测试全绿，或者开着多个并行 subagent、基本没人盯着，跑几个小时做大型代码库审计和迁移。

早期测试者说，它做代码审查能抓出更多 bug，误报更少，改完还会用大白话解释自己动了什么。Opus 5.5 用默认的 medium effort，就能打平甚至超过 Opus 5 的 high effort，步数更少、token 也更少。

知识工作也稳了：说错数字、引错出处的概率大幅下降，财务建模、在估值表里挑错都更强。读图方面更夸张，最低档 effort 读密集图表里数值的准确率，都比 Opus 5 最高档还高，而输出的 token 只有一小部分。

effort：从 medium 开始，显式设，自己测

因为 Opus 5.5 的 thinking 始终开着，effort 就成了控制它“想多少”的主旋钮。官方建议从 medium 开始，这是 Opus 5.5 的默认值，Opus 5 是 high。同时要在请求里显式写出来，再用自己的评测集把几个档位都跑一遍，别直接沿用 Opus 5 的老设置。

想让模型少思考，优先降 effort，这比在提示词里写“别想太多”可靠得多。

还有两个容易忽略的点：max_tokens 要留够空间同时装下 thinking 和回复，长回合任务实测 128,000 效果较好；xhigh 和 max 只用在实测确实有提升的任务上。

另外，在请求之间改顶层 effort 会让 prompt cache 失效，只想个别回合换档就用 per-message effort。

thinking 关不掉：传 disabled 直接 400

这是会直接报错的一处变化。Opus 5 上 effort 为 high 及以下时，可以传 thinking: {"type": "disabled"} 关掉思考；到了 Opus 5.5，传 disabled 或者手动设 budget_tokens 都会返回 400。正确做法是不传这个字段，或者传 {"type": "adaptive"}，两者等价。

如果你之前是关着 thinking 跑的，还有四处要一起调：从 low 开始测延迟和质量；首 token 延迟还吃紧的话，系统提示里加一句 "Answer directly without deliberating."；删掉“让模型在正文写推理过程”的指令，现在这种请求可能被 reasoning_extraction 类别拒绝；按类型读响应块，别假定第一个 content block 就是 text。

Agent 中途停下：把“汇报”当“完成”就翻车

在长任务里，Opus 5.5 会一边做一边向你汇报进度，其中有些汇报是以纯文本结束当前回合，stop_reason: "end_turn"，不带任何工具调用。如果一个无人值守的 Agent 循环把这种回合当成任务完成，它就会停在那儿干等。

官方给了几个 harness 层面的解法：把纯文本回合当一次汇报，而不是完成的依据；把任务拆成清单让模型自己更新；回合结束清单还有未完成的项，就发一条简短消息把剩下的列出来续跑。

他们还写了一段很长的“长期有效指令”塞进系统提示，专门点名四种不想要的结束方式，比如长总结宣布下一步却不调用工具、抛个“除非你另有想法否则我继续”来等一个不会来的回答。

说白了：把“什么情况下该停”写死，比事后救火强。

几个容易踩的小坑

粘贴内容要分清你的指令和粘贴或检索进来的文本，别让模型把粘进来的文字当成命令执行，这本质上就是防 prompt injection。

读图表、截图直接把图贴上去，别手抄里面的数据，Opus 5.5 读空间关系比老模型准得多。

前端生成别说“避免千篇一律的 AI 风”就完事，要点名你具体不想要的样式，比如奶油色背景、标题里的斜体强调词、01/02/03 编号、药丸形按钮。

还有：别让它把内部推理过程复述到回复里，这本身可能触发拒绝；想要解释就直接问“为什么选这个方案”。

跨多个应用干活时，明说去哪找上下文，别假设用户把每个相关来源都点名了。

把验证做成单独一步

官方的意思是，验证不该是顺手带过，而是工作流里独立的一环。让 Opus 5.5 在人工 review 之前先自查改动，研究类任务要求它标出“无法确认”的东西并说明在哪找的。

评估你自己的提示词也要量：任务通过率、正确率、token 用量、延迟、成本，以及 Agent 的轨迹——它查对证据了吗、选对工具了吗、顺序对吗、该停的时候停了吗。

验证要当成工作流里单独的一步，而不是顺手带过。

写在最后

说实话，我看到“删掉 think carefully”这条时第一反应是：这不对吧，我所有常用提示词里都塞了“仔细想想”“一步步来”。

但官方自己的测试数据是，去掉之后回复更早开始，质量没肉眼可见地掉。所以我打算干的第一件事，就是把我那几份保存的提示词全翻出来，把这些口令清掉，改成显式设 effort。

它最反直觉、也最该记住的一点：别再手把手教它思考，把“做完长什么样”定义清楚，然后让它自己跑。