Claude Opus 5.5 提示词实战指南
做法与步骤
- 先按你观察到的现象定位章节：成本变高查 effort 校准，被拒查 safeguard，静默查进度更新，多应用漏信息查上下文探索。
- Effort 是主要控制项，且思考始终开启；默认从 medium 起步并显式设置，用自家评测测多个档位，不要照搬 Opus 5 的设置。
- 同一档位下 5.5 每轮思考更多，尤其 xhigh 和 max；需把 max_tokens 调高（如 128,000）给思考留空间，否则回复会被截断。
- 想减少思考优先降 effort 档位，比写提示词指令更可靠；跨请求改顶层 effort 会失效提示缓存，单轮调整应用 per-message effort（beta）。
- 若原集成关闭了思考：从 low 起步实测，删掉代替思考的“写出推理”指令，改用 summarized thinking blocks 读取推理，并重测旧缓解措施。
- 按 block 类型读取响应，不要假设第一个内容块就是文本；思考内容即使不返回也计入 max_tokens。
对实践的启示
做 AI 应用的人应把 effort 当作首要调参旋钮，用自家评测重新标定而非沿用 Opus 5 配置；同时检查 max_tokens 是否给思考留足空间，并针对静默、拒绝、多应用漏信息等具体症状逐项改提示词。
作者承认的反方与局限
作者指出，降低思考的提示词指令不如直接降 effort 可靠；且加“直接回答”这类指令可能降低质量，需自行测量。
原文摘引
Effort is the main control for how much Claude Opus 5.5 thinks, and because thinking is always on, it's the first setting to adjust when trading off intelligence, latency, and cost.
To get less thinking, lower the effort level first. Lowering effort reduces thinking, and with it cost and latency, more reliably than prompt instructions do.
Changing the top-level effort value between requests invalidates the prompt cache.
▸ 展开原文全文（34 段，抓取自 Hacker News）
Prompting Claude Opus 5.5
Behavioral differences from Claude Opus 5 and the prompting and harness patterns that address them: effort calibration, thinking behavior in API integrations and chat, progress updates, unattended and multiagent tasks, safeguard refusals, frontend design, complex visual inputs, multi-app workflows, and pasted text in user messages.
This guide covers the prompting patterns specific to Claude Opus 5.5. For the model's capabilities and API changes, see What's new in Claude Opus 5.5. For techniques that apply across all current Claude models, see Prompting best practices.
Claude Opus 5.5 generates output tokens more than 30 percent faster than Claude Opus 5 and tends to finish the same task with fewer tokens. Existing Claude Opus 5 prompts should perform well without changes, and the patterns in Prompting Claude Opus 5 remain a reasonable starting point. Start with the section that matches what you observe:
- Unsure which effort level to run, or turns run longer and cost more than they did on Claude Opus 5: Calibrate effort
- Your Claude Opus 5 integration ran with thinking disabled: Prompts written for thinking disabled
- An unattended agent stops partway through a long task after reporting progress: Unattended agentic runs
- Requests return stop_reason: "refusal" : Safeguard refusals
- Long agentic turns look silent, or you want updates at predictable points: User-facing progress updates
- An agent that works across several connected apps misses information the task didn't point to: Explore context in multi-app workflows
- You run a team of agents and want it to finish sooner: Time signals for multiagent harnesses
- Replies in a chat application start slowly because the model thinks at length first: Thinking instructions in chat system prompts
- The model follows instructions that arrived inside text a user pasted: Mark pasted text in user messages
- Answers about dense charts, diagrams, or screenshots miss detail: Tools for complex visual inputs
- Frontend output looks generic: Frontend design defaults
Capabilities relevant to prompting
The capabilities that matter most for prompting are:
- Agentic coding and code review: The model is strongest on multistep work in a real repository, such as carrying a change through a large code base until its tests pass. In Anthropic's testing, at its default medium effort the model matched or beat Claude Opus 5 athigh effort on such tasks, in fewer steps and with fewer tokens. It also sustains long-running autonomous work better than Claude Opus 5, such as multi-hour audits and migrations of large code bases run end to end with parallel subagents and little oversight. Early testers also reported stronger code review, with more bugs caught than on Claude Opus 5 and fewer false alarms, and it explains its changes in plain language.
- Knowledge work: The model is much less likely to state an incorrect figure or cite the wrong source. It's better at financial modeling tasks, such as building a financial model and one-page summary for a transaction or finding and fixing errors in a valuation workbook, and it catches details that are easy to miss in large inputs, such as a date in a long planning thread that falls on the wrong weekday or a chart in a slide deck that doesn't match the underlying figures. The spreadsheets, slides, and documents it produces need less editing before you share them.
- Communication: Its reports on agentic work, both the updates while it works and the summary when it finishes, say plainly what it did, what it found, and what it needs from you. See User-facing progress updates.
- Charts, diagrams, screenshots, and computer use: The model reads visual material more accurately than Claude Opus 5 without extra tooling: in Anthropic's testing, even at its lowest effort setting it read values off dense charts more accurately than Claude Opus 5 did at its highest, using a small fraction of the output tokens. It is better, too, where meaning depends on position rather than text: which boxes an arrow connects in a flowchart, what changed between two versions of a diagram, or exactly when a meeting starts and ends in a calendar screenshot. It's also more reliable at computer use, where it operates applications from screenshots over many steps: at its default effort it matched the success rate that Claude Opus 5 reached only at a much higher effort setting. See Tools for complex visual inputs.
Calibrate effort
Effort is the main control for how much Claude Opus 5.5 thinks, and because thinking is always on, it's the first setting to adjust when trading off intelligence, latency, and cost. Start at medium, the default on Claude Opus 5.5 (Claude Opus 5 defaults to high), set it explicitly, and test several levels against your own evals rather than carrying over the setting you used on Claude Opus 5. Effort level names don't correspond to the same amount of thinking across models: in Anthropic's testing, Claude Opus 5.5 at medium matches or exceeds Claude Opus 5 at high on coding and knowledge-work evaluations, and on several coding evaluations low comes close to it at much lower cost. See Recommended effort levels for Claude Opus 5.5.
At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max. If you keep the effort value you set for Claude Opus 5, expect longer turns and more output tokens. Three adjustments help:
- Set max_tokens high enough to leave room for the model's thinking tokens and the reply. Thinking counts towardmax_tokens even when thinking content isn't returned to you, so a limit sized for Claude Opus 5 with thinking off can cut replies off. For the long turns that agentic coding can produce, amax_tokens of 128,000, the model's maximum, has worked well in Anthropic's testing.
- Reserve xhigh andmax for work where you've measured a quality gain.
- To get less thinking, lower the effort level first. Lowering effort reduces thinking, and with it cost and latency, more reliably than prompt instructions do.
Changing the top-level effort value between requests invalidates the prompt cache. To run individual turns at a different level, use a per-message effort change (beta) instead, which keeps the cache.
Prompts written for thinking disabled
Claude Opus 5 accepts thinking: {"type": "disabled"} at high effort or below; Claude Opus 5.5 doesn't, and the migration guide covers the request change. If your Claude Opus 5 integration ran with thinking disabled, four changes go with it:
- Start at low effort and measure. Atlow the model keeps its thinking short. How often it skips thinking altogether depends on your prompts, so measure latency and quality on your own traffic and move tomedium if quality drops. If time to first token still matters after that, a system prompt line such as "Answer directly without deliberating." can reduce thinking further; measure quality when you add it, because less thinking can lower it.
- Remove instructions that stood in for thinking. If your prompt asked the model to write out its reasoning in the response as a substitute for thinking, remove that instruction and read the reasoning from summarized thinking blocks instead (display: "summarized" ); a prompt that pushes the model to reproduce its reasoning in the response text can be declined with thereasoning_extraction refusal category.
- Re-test the thinking-disabled mitigations. Running with thinking disabled recommends a combined instruction (permission to speak before a tool call, what to do when no tool fits, no internal tags) and removing any rule that tells the model not to think. Both address artifacts that appear on Claude Opus 5 only when thinking is disabled. With thinking always on, check whether you still need the instruction, and remove the no-thinking rule either way.
- Read the response by block type. Check each block's type instead of assuming the first content block is text: a response may