Claude 提示工程最佳实践

核心思想

这是 Anthropic 官方关于 Claude 最新一代模型(Opus 4.8/4.7/4.6、Sonnet 4.6、Haiku 4.5)提示工程的唯一权威参考。它系统讲解了从基础技巧、输出控制、工具使用,到思考调优与智能体系统编排的完整方法论,并附有大量可直接复用的英文提示词片段与 API 代码示例。对使用 Claude API 做提示工程的开发者而言,这是一份兼具操作性与权威性的调优手册。

本文档是与 Claude 最新一代模型——包括 Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5——做提示工程的唯一权威参考。它涵盖基础技巧、输出控制、工具使用、思考以及智能体系统。直接跳到与你处境相符的章节即可。

想了解各模型的能力概览,参见模型总览。想了解 Claude Opus 4.8 的新变化,参见 Claude Opus 4.8 有哪些新特性。需要迁移指引,参见迁移指南。

为 Claude Opus 4.8 编写提示词

Claude Opus 4.8 在长程智能体工作、知识工作、视觉和记忆任务上尤为擅长。在已有的 Claude Opus 4.7 提示词上,它开箱即用、表现良好。下面这些模式,覆盖的正是最常需要调优的那些行为。

从 Claude Opus 4.7 迁移时涉及的 API 参数变化(采样参数、effort 默认值、默认 1M 上下文窗口(Microsoft Foundry 上为 200k)、对话中途的系统消息,以及拒答停止的细节),参见迁移指南。

响应长度与冗长度

Claude Opus 4.8 会根据它判断的任务复杂度来校准响应长度,而不是默认一个固定的冗长度。这通常意味着:简单查询的回答更短,而开放式分析的回答会长得多。

如果你的产品依赖某种特定的输出风格或冗长度,你可能需要调优提示词。举个例子,要降低冗长度,你可以加上:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

如果你看到某些具体的冗长表现(比如过度解释),可以在提示词里追加额外指令来阻止它们。展示 Claude 如何以恰当的简洁程度沟通的正面示例,往往比负面示例或”告诉模型不要做什么”的指令更有效。

校准 effort 与思考深度

effort 参数让你能在 Claude 的智能水平与 token 花费之间权衡——以能力换取更快的速度和更低的成本。编码与智能体场景从 xhigh 档起步,大多数对智能敏感的场景至少用 high 档。再尝试其他档位,以进一步调优 token 用量与智能水平:

• max: Max 档在某些场景下能带来性能提升,但随着 token 用量增加,收益可能递减。这一档有时还容易过度思考。在对智能要求高的任务上测试 max 档。
• xhigh: 对大多数编码和智能体场景,xhigh(超高)是最佳档位。
• high: 这一档在 token 用量与智能之间取得平衡。对大多数对智能敏感的场景,至少用 high 档。
• medium: 适合对成本敏感、需要减少 token 用量并愿意以此换取部分智能的场景。
• low: 留给短小、范围明确的任务,以及对延迟敏感、但对智能不敏感的工作负载。

Claude Opus 4.8 会严格遵守 effort 档位,尤其是在低端档位。在 low 和 medium 档,模型会把工作范围严格限定在被要求的事情上,而不会”超额发挥”。这对延迟和成本是好事,但在中等复杂度的任务上以 low 档运行时,存在一定的思考不足风险。

如果你在复杂问题上观察到推理浅尝辄止,应该把 effort 提到 high 或 xhigh,而不是靠提示词绕过去。如果出于延迟考虑必须把 effort 保持在 low,就加上有针对性的引导:

This task involves multi-step reasoning. Think carefully through the problem before responding.

effort 对这个模型的重要性,很可能超过此前任何一代 Opus,所以升级后要主动用它做实验。

在 Claude Opus 4.8 上,除非你显式设置 thinking: {type: "adaptive"},否则思考是关闭的。自适应思考的触发行为是可引导的。如果你发现模型思考的频率超出预期——在系统提示词又大又复杂时尤其容易发生——就加上引导来调整它。一如既往,要测量任何提示词改动对性能的影响。示例:

Thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multi-step reasoning. When in doubt, respond directly.

反过来,如果你在 medium 档跑高强度工作负载并看到思考不足,第一个该动的杠杆是提高 effort。如果需要更精细的控制,就直接用提示词来要求。

如果你在 max 或 xhigh 档运行 Claude Opus 4.8,要设一个较大的最大输出 token 预算,好让模型在它的各个子智能体和工具调用之间有思考和行动的空间。从 64k token 起步,再据此调优。

工具使用的触发

Claude Opus 4.8 有一种倾向:偏好推理而非调用工具。这在大多数情况下能产出更好的结果。不过,提高 effort 档位是增加工具使用程度的一个有用杠杆,在知识工作中尤其如此。high 或 xhigh 档在智能体搜索和编码中会展现出明显更多的工具使用。对于那些你希望模型多用工具的场景,你也可以调整提示词,明确指示模型何时以及如何正确使用它的工具。比如,如果你发现模型没有使用你的网络搜索工具,就清楚地说明它为什么、应当如何使用。

面向用户的进度更新

Claude Opus 4.8 会在漫长的智能体执行轨迹中,向用户提供更规律、质量更高的更新。如果你之前加了脚手架来强制产生中途状态消息(“每 3 次工具调用后,总结一下进度”),不妨试着把它移除。如果你发现 Claude Opus 4.8 面向用户的更新在长度或内容上与你的场景不太匹配,就在提示词里明确描述这些更新应该是什么样子,并提供示例。

Claude Opus 4.8 会按字面、按明示来理解提示词,在较低 effort 档位时尤为如此。它不会悄悄地把一条针对某一项的指令推广到另一项,也不会推断你没有提出的请求。这种字面主义的好处是精确、少反复,对于精心调优过的提示词、结构化抽取,以及那些你希望行为可预测的流水线等 API 场景,它通常表现更好。如果你需要 Claude 把某条指令广泛应用,就明确说明适用范围(例如,“把这个格式应用到每一个章节,而不只是第一个”)。

语气与写作风格

和任何新模型一样,长篇写作的文风可能会发生变化。Claude Opus 4.8 倾向于一种直接、有主见的风格,很少使用迎合式的措辞,emoji 也用得克制。如果你的产品依赖某种特定的”声音”,就拿新的基线重新评估你的风格提示词。

举例来说,如果你的产品声音更温暖或更具对话感,可以加上:

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

控制子智能体的派生

Claude Opus 4.8 默认倾向于派生更少的子智能体。不过,这一行为可以通过提示词来引导;给 Claude Opus 4.8 明确的指引,告诉它什么时候适合用子智能体。下面是一个编码场景的简化示例:

Do not spawn a subagent for work you can complete directly in a single response (e.g. refactoring a function you can already see).

Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.

设计与前端默认风格

Claude Opus 4.8 有很强的设计直觉,带着一套一致的默认”家族风格”:温暖的米色 / 灰白色背景(约 #F4F1EA)、衬线展示字体(Georgia、Fraunces、Playfair)、斜体的词语强调,以及陶土色 / 琥珀色的点缀色。这套风格用在编辑类、酒店类和作品集类需求上很好看,但用在仪表盘、开发者工具、金融科技、医疗健康或企业应用上就会显得格格不入。这套默认风格不仅出现在网页 UI 中,也会出现在幻灯片里。

这套默认风格很顽固。泛泛的指令(“别用米色""做得干净、极简一点”)往往只会把模型推向另一套固定的配色,而不是产生多样性。有两种方法可靠地奏效:

1. 指定一个具体的替代方案。 模型会精确地遵循明确的规格说明:

Design a desktop landing page for a supplement brand called AEFRM.

The visual direction should come from a cold monochrome atmosphere using pale silver-gray tones that gradually deepen into blue-gray and near-black, similar to a misted metallic surface.

The page should feel sharp and controlled, with a strong sense of structure and restraint.

Use this tonal system across the full page instead of introducing bright accent colors.

Use the uploaded image on the hero design in black and white.

The layout should be built with clear horizontal sections and a centered max-width container. Use 4px corner radius consistently across cards, buttons, inputs, and media frames. Margins should feel generous, with enough empty space around each section so the page breathes.

Typography should use a square, angular sans-serif with wider letter spacing than usual, especially in headings and navigation, so the text feels more engineered and less compressed. Headline text can be large and uppercase, while supporting copy remains short and sparse. The sub texts should be written with Alumni Sans SC in 4-6px like tiny little texts on corners bottom centre like that.

For the structure, start with a hero section containing a strong product statement, one short supporting paragraph, and a clean product placeholder or packshot frame. Below that, add a benefit grid with three or four blocks, then a formulation or ingredients section, and finally a cta.

Buttons should be flat and precise, with subtle hover changes using transition: all 160ms ease out where brightness and border contrast shift slightly rather than using dramatic motion.

Color palette should stay within this range:
#E9ECEC, #C9D2D4, #8C9A9E, #44545B, #11171B.

2. 让模型在动手之前先提出几个方案。 这能打破默认风格,并把控制权交给用户。如果你以前靠 temperature 来获得设计上的多样性,改用这种方法;它能在多次运行之间产出真正不同的方向。示例提示词:

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface — one-line rationale). Ask the user to pick one, then implement only that direction.

此外,相比以往的模型,Claude Opus 4.8 需要的前端设计提示更少,就能避开那些被用户称为”AI 味”产出(AI slop)的通用套路。在更早的模型上,Anthropic 推荐在 frontend-design skill 里使用一段更长的提示词片段。然而,Claude Opus 4.8 只需更精简的提示引导,就能生成独特、有创意的前端。下面这段提示词片段,配合上面关于多样性的提示建议,效果很好:

<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>

交互式编码产品

Claude Opus 4.8 的 token 用量和行为,在两类场景之间会有差异:一类是只有单个用户回合的自主、异步编码智能体,另一类是有多个用户回合的交互、同步编码智能体。具体来说,它在交互式场景下倾向于使用更多 token,主要是因为它在用户回合之后会做更多推理。在长时间的交互式编码会话中,这能提升长程连贯性、指令遵循和编码能力,但也伴随着更高的 token 用量。要在编码产品中同时最大化性能和 token 效率,就使用 xhigh 或 high 档,加入诸如自动模式之类的自主特性,并减少需要用户参与的人工交互次数。

当然,在限制必需的用户交互次数时,关键是要在第一个人工回合里就把任务、意图和相关约束说清楚。在一开始就提供界定清楚、明确、准确的任务描述,有助于最大化自主性和智能,同时把用户回合之后的额外 token 用量降到最低。由于 Claude Opus 4.8 比以往的模型更自主,这种用法模式有助于把性能拉满。相比之下,通过多个用户回合一点点透露的模糊或界定不清的提示词,往往会相对降低 token 效率,有时还会降低性能。

代码审查框架

在找 bug 这件事上,Claude Opus 4.8 比以往的模型明显更强,在内部评测中召回率和精确率都更高。然而,如果你的代码审查框架(harness)是为更早的模型调优的,你一开始可能会看到召回率反而更低。这很可能是框架层面的效应,而非能力的退化。当审查提示词里写着”只报告高严重度问题""保守一些""别吹毛求疵”这类话时,Claude Opus 4.8 可能会比早期模型更忠实地遵守这条指令:它可能同样彻底地审查代码、同样把 bug 找出来,然后不去报告那些它判断低于你设定门槛的发现。表现出来就是:模型做了同样深度的调查,却把其中更少的调查转化为上报的发现,在低严重度 bug 上尤其如此。精确率通常会上升,但即便模型底层的找 bug 能力其实已经提升,测得的召回率也可能下降。

一些推荐的提示词措辞:

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

这段提示词即便没有真正的第二步也能用,不过把置信度过滤从”发现”环节里移出去,往往会有帮助。如果你的框架有单独的验证、去重或排序阶段,就明确告诉模型:它在发现阶段的任务是覆盖,而不是过滤。

如果你确实希望模型在单趟里自我过滤,那就把门槛说具体,而不要用”重要”这类定性词。比如:“报告任何可能导致错误行为、测试失败或误导性结果的 bug;只省略诸如纯粹风格或命名偏好之类的细枝末节。”

拿你的一部分评测或测试用例来反复打磨提示词,以验证召回率或 F1 分数的提升。

计算机操作(computer use)

计算机操作能力可跨分辨率工作,最高支持 2576px / 3.75MP。内部的计算机操作测试表明,以 1080p 发送图像能在性能和成本之间取得很好的平衡。

对于特别在意成本的工作负载,720p 或 1366×768 是成本更低、性能依然强劲的选项。请自行测试,为你的场景找到理想设置;调整 effort 档位也有助于调优模型的行为。

通用原则

清晰且直接

Claude 对清晰、明确的指令反应很好。把你想要的输出说具体,有助于提升结果。如果你想要”超额发挥”的行为,就明确提出来,而不要指望模型从含糊的提示词里推断出这一点。

把 Claude 想象成一位才华横溢、但刚入职的新员工——他还不了解你的规范和工作流。你越精确地解释你想要什么,结果就越好。

黄金法则: 把你的提示词拿给一位对任务背景知之甚少的同事看,请他照着做。如果他会感到困惑,Claude 也会。

• 把想要的输出格式和约束说具体。
• 当步骤的顺序或完整性很重要时,用编号列表或要点把指令写成依次执行的步骤。

加上下文以提升性能

提供指令背后的上下文或动机——比如向 Claude 解释为什么这种行为很重要——能帮助 Claude 更好地理解你的目标,给出更有的放矢的回应。

Claude 足够聪明,能从你的解释中举一反三。

有效使用示例

示例是引导 Claude 输出格式、语气和结构最可靠的方式之一。几个精心设计的示例(即少样本或多样本提示)就能大幅提升准确性和一致性。

添加示例时,要让它们做到:

• 相关: 紧贴你真实的使用场景。
• 多样: 覆盖边界情况,并且变化足够多,好让 Claude 不会学到你不想要的模式。
• 结构化: 把示例包在 <example> 标签里(多个示例放在 <examples> 标签里),好让 Claude 把它们和指令区分开。

包含 3–5 个示例效果最好。你也可以让 Claude 评估你的示例在相关性和多样性上如何,或者基于你最初那组示例再生成一些。

用 XML 标签组织提示词

XML 标签能帮助 Claude 无歧义地解析复杂的提示词,在你的提示词混合了指令、上下文、示例和可变输入时尤其有用。把每一类内容包在各自的标签里(例如 <instructions>、<context>、<input>),能减少误解。

最佳实践:

• 在你的各个提示词里使用一致、有描述性的标签名。
• 当内容有天然的层级时,嵌套标签(文档放在 <documents> 里,每个文档放在 <document index="n"> 里)。

给 Claude 一个角色

在系统提示词里设定一个角色,能为你的场景聚焦 Claude 的行为和语气。哪怕只是一句话也能带来差别:

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)
print(message.content)

长上下文提示

当你处理大型文档或数据密集的输入(2 万 token 以上)时,要精心组织提示词以获得最佳结果:

• 把长篇数据放在顶部: 把你的长文档和输入放在提示词靠近顶部的位置,置于查询、指令和示例之上。这能在所有模型上显著提升性能。
  在测试中,把查询放在末尾最多能把响应质量提升 30%,在面对复杂的多文档输入时尤其明显。
• 用 XML 标签组织文档内容和元数据: 使用多个文档时,把每个文档包在 <document> 标签里,并配上 <document_content> 和 <source>(以及其他元数据)子标签,以求清晰。
• 让回应基于引文: 对于长文档任务,先让 Claude 引用文档中相关的部分,再去执行它的任务。这能帮助 Claude 穿透文档其余内容的噪声。

模型的自我认知

如果你希望 Claude 在你的应用里正确地表明自己的身份,或使用特定的 API 字符串:

The assistant is Claude, created by Anthropic. The current model is Claude Opus 4.8.

对于需要指定模型字符串的、由 LLM 驱动的应用:

When an LLM is needed, please default to Claude Opus 4.8 unless the user requests otherwise. The exact model string for Claude Opus 4.8 is claude-opus-4-8.

输出与格式

沟通风格与冗长度

相比以往的模型,Claude 最新一代模型的沟通风格更简洁、更自然:

• 更直接、更有依据: 提供基于事实的进度汇报,而不是自我表扬式的更新
• 更具对话感: 略微更流畅、更口语化,不那么机械
• 更不冗长: 为了效率,除非另有要求,否则可能略去详细的总结

这意味着 Claude 可能会在工具调用之后略去口头总结,直接跳到下一个动作。如果你更希望看到它的推理过程:

After completing a task that involves tool use, provide a quick summary of the work you've done.

有几种特别有效的方式可以引导输出格式:

1. 告诉 Claude 该做什么,而不是不该做什么
   • 不要说:“Do not use markdown in your response”
     • 试试:“Your response should be composed of smoothly flowing prose paragraphs.”
2. 使用 XML 格式标识符
   • 试试:“Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags.”
3. 让你的提示词风格与期望的输出相匹配
   你提示词里所用的格式风格,可能会影响 Claude 的回应风格。如果你在输出格式的可引导性上仍有问题,试着让你的提示词风格尽可能贴近你期望的输出风格。比如,从提示词里去掉 markdown,可以减少输出中的 markdown 用量。
4. 对特定格式偏好使用详尽的提示词
   要对 markdown 和格式的使用有更强的控制,就提供明确的指引:

<avoid_excessive_markdown_and_bullet_points>
When writing reports, documents, technical explanations, analyses, or any long-form content, write in clear, flowing prose using complete paragraphs and sentences. Use standard paragraph breaks for organization and reserve markdown primarily for \`inline code\`, code blocks (\`\`\`...\`\`\`), and simple headings (###, and ###). Avoid using **bold** and *italics*.

DO NOT use ordered lists (1. ...) or unordered lists (*) unless : a) you're presenting truly discrete items where a list format is the best option, or b) the user explicitly requests a list or ranking

Instead of listing items with bullets or numbers, incorporate them naturally into sentences. This guidance applies especially to technical writing. Using prose instead of excessive formatting will improve user satisfaction. NEVER output a series of overly short bullet points.

Your goal is readable, flowing text that guides the reader naturally through ideas rather than fragmenting information into isolated points.
</avoid_excessive_markdown_and_bullet_points>

LaTeX 输出

Claude 最新一代模型对于数学表达式、方程和技术说明,默认使用 LaTeX。如果你偏好纯文本,在提示词里加上下面的指令:

Format your response in plain text only. Do not use LaTeX, MathJax, or any markup notation such as \( \), $, or \frac{}{}. Write all math expressions using standard text characters (e.g., "/" for division, "*" for multiplication, and "^" for exponents).

文档生成

Claude 最新一代模型擅长创建演示文稿、动画和视觉化文档,有着令人印象深刻的创意表现力和很强的指令遵循能力。在大多数情况下,这些模型第一次尝试就能产出精致、可用的成果。

要在文档生成上获得最佳结果:

Create a professional presentation on [topic]. Include thoughtful design elements, visual hierarchy, and engaging animations where appropriate.

从 Claude 4.6 系列模型和 Claude Mythos Preview 开始,最后一个助手回合上的预填充回复不再被支持。向这些模型发送带有预填充助手消息的请求会返回 400 错误。模型的智能和指令遵循已经进步到这种程度:大多数预填充的使用场景如今都不再需要它了。更早的模型仍然支持预填充,而在对话中其他位置添加助手消息不受影响。

下面是常见的预填充场景,以及如何迁移、不再依赖它们:

工具使用

工具使用

Claude 最新一代模型经过训练能精确遵循指令,并且能从”明确指示使用特定工具”中获益。如果你说”你能建议一些改动吗”,Claude 有时会只给出建议而不去实施,哪怕做出改动可能正是你的本意。

要让 Claude 采取行动,就说得更明确些:

要让模型默认更主动地采取行动,你可以把下面这段加进系统提示词:

<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is unclear, infer the most useful likely action and proceed, using tools to discover any missing details instead of guessing. Try to infer the user's intent about whether a tool call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>

另一方面,如果你想让模型默认更谨慎些、不那么容易一头扎进实现、只在被要求时才行动,你可以用类似下面的提示词来引导这种行为:

<do_not_act_before_instructions>
Do not jump into implementation or change files unless clearly instructed to make changes. When the user's intent is ambiguous, default to providing information, doing research, and providing recommendations rather than taking action. Only proceed with edits, modifications, or implementations when the user explicitly requests them.
</do_not_act_before_instructions>

Claude Opus 4.5 和 Claude Opus 4.6 对系统提示词的响应也比以往的模型更强。如果你的提示词当初是为了减少工具或 skill 的触发不足而设计的,那么在这些模型上现在可能会过度触发。解决办法是把那些激烈的措辞收一收。原本你可能写的是”CRITICAL: You MUST use this tool when…“,现在可以改用更平常的提示词,比如”Use this tool when…”。

优化并行工具调用

Claude 最新一代模型擅长并行执行工具。这些模型会:

• 在研究过程中同时跑多个推测性搜索
• 一次读取多个文件,以更快地建立上下文
• 并行执行 bash 命令(这甚至可能让系统性能成为瓶颈)

这种行为很容易引导。虽然模型在没有提示的情况下并行工具调用的成功率就很高,你仍可以把它提升到约 100%,或调整其激进程度:

用于最大化并行效率的示例提示词

<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool calls, make all of the independent tool calls in parallel. Prioritize calling tools simultaneously whenever the actions can be done in parallel rather than sequentially. For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time. Maximize use of parallel tool calls where possible to increase speed and efficiency. However, if some tool calls depend on previous calls to inform dependent values like the parameters, do NOT call these tools in parallel and instead call them sequentially. Never use placeholders or guess missing parameters in tool calls.
</use_parallel_tool_calls>

用于减少并行执行的示例提示词

Execute operations sequentially with brief pauses between each step to ensure stability.

思考与推理

过度思考与过度周全

相比以往的模型,Claude Opus 4.6 会做明显更多的前期探索,在较高的 effort 档位时尤为如此。这种前期工作往往有助于优化最终结果,但模型可能会在没被提示的情况下大量搜集上下文,或同时追查多条研究线索。如果你的提示词以前是鼓励模型更周全的,那你应该为 Claude Opus 4.6 调整那段引导:

• 用更有针对性的指令替换一揽子的默认设定。 不要写”Default to using [tool]“,而是加上类似”Use [tool] when it would enhance your understanding of the problem”这样的引导。
• 去掉过度提示。 在以往模型中触发不足的工具,现在很可能会恰当地触发。像”If in doubt, use [tool]“这样的指令会导致过度触发。
• 把 effort 当作兜底。 如果 Claude 依然过于激进,就给 effort 用一个更低的档位。

在某些情况下,Claude Opus 4.6 可能会大量思考,这会让思考 token 膨胀并拖慢响应。如果这种行为不是你想要的,你可以加上明确的指令来约束它的推理,或者降低 effort 档位以减少总体的思考和 token 用量。

When you're deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you're weighing two approaches, pick one and see it through. You can always course-correct later if the chosen approach fails.

如果你需要给思考成本设一个硬上限,带 budget_tokens 上限的扩展思考在 Opus 4.6 和 Sonnet 4.6 上仍然可用,但已被弃用。更推荐降低 effort 档位,或配合自适应思考用 max_tokens 作为硬性上限。

善用思考与交错思考能力

Claude 最新一代模型提供的思考能力,对于那些涉及工具使用后反思、或复杂多步推理的任务尤其有帮助。你可以引导它的初始思考或交错思考,以获得更好的结果。

Claude Opus 4.6 和 Claude Sonnet 4.6 使用自适应思考(thinking: {type: "adaptive"}),由 Claude 动态决定何时思考、思考多少。Claude 基于两个因素来校准它的思考:effort 参数和查询的复杂度。更高的 effort 会引出更多思考,更复杂的查询同样如此。对于不需要思考的简单查询,模型会直接回应。在内部评测中,自适应思考可靠地比扩展思考带来更好的性能。考虑切换到自适应思考,以获得最智能的回应。

对于需要智能体行为的工作负载——比如多步工具使用、复杂的编码任务和长程智能体循环——请使用自适应思考。更旧的模型则使用带 budget_tokens 的手动思考模式。

你可以引导 Claude 的思考行为:

After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding. Use your thinking to plan and iterate based on this new information, and then take the best next action.

自适应思考的触发行为是可提示的。如果你发现模型思考的频率超出预期——这在系统提示词又大又复杂时可能发生——就加上引导来调整它:

Extended thinking adds latency and should only be used when it will meaningfully improve answer quality - typically for problems that require multi-step reasoning. When in doubt, respond directly.

如果你正在从带 budget_tokens 的扩展思考迁移过来,替换掉你的思考配置,并把预算控制挪到 effort 上:

迁移前(扩展思考,更旧的模型):

client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

迁移后(自适应思考):

client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

如果你没有使用扩展思考,则无需任何改动。当你省略 thinking 参数时,思考默认是关闭的。

• 优先用一般性指令,而非规定性的步骤。 像”think thoroughly”(彻底思考)这样的提示词,往往比手写的逐步计划产出更好的推理。Claude 的推理常常超出一个人会规定的范围。
• 多样本示例对思考也适用。 在你的少样本示例里使用 <thinking> 标签,把推理模式展示给 Claude 看。它会把这种风格推广到自己的扩展思考块中。
• 手动 CoT 作为兜底。 当思考关闭时,你仍然可以通过让 Claude 把问题想一遍来鼓励逐步推理。使用 <thinking> 和 <answer> 这样的结构化标签,把推理和最终输出干净地分开。
• 让 Claude 自我检查。 追加一句类似”Before you finish, verify your answer against [test criteria]“(在收尾之前,对照[测试标准]核验你的答案)的话。这能可靠地捕捉错误,在编码和数学上尤其有效。

当扩展思考被禁用时,Claude Opus 4.5 对”think”这个词及其各种变体特别敏感。这种情况下,可以考虑用”consider”(考虑)、“evaluate”(评估)或”reason through”(推敲)之类的替代说法。

想了解更多关于思考能力的信息,参见扩展思考和自适应思考。

智能体系统

长程推理与状态追踪

Claude 最新一代模型擅长长程推理任务,有着出色的状态追踪能力。Claude 通过聚焦于增量进展来在漫长的会话中保持方向感——它一次只在少数几件事上稳步推进,而不是试图一口气把所有事情都做完。这种能力在跨越多个上下文窗口或多轮任务迭代时尤其凸显:Claude 可以处理一个复杂任务,保存状态,然后用一个全新的上下文窗口继续。

上下文感知与多窗口工作流

Claude 4.6 和 Claude 4.5 系列模型具备上下文感知能力,使模型能在整个对话过程中追踪自己剩余的上下文窗口(即”token 预算”)。通过了解自己还有多少空间可用,Claude 得以更有效地执行任务和管理上下文。

管理上下文上限:

如果你在一个会压缩上下文、或允许把上下文保存到外部文件的智能体框架里使用 Claude(比如在 Claude Code 中),不妨把这一信息加进你的提示词,好让 Claude 据此行事。否则,Claude 有时会在接近上下文上限时自然地试图把工作收尾。下面是一个示例提示词:

Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Therefore, do not stop tasks early due to token budget concerns. As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully, even if the end of your budget is approaching. Never artificially stop any task early regardless of the context remaining.

记忆工具与上下文感知天然搭配,可实现无缝的上下文过渡。

多上下文窗口工作流

对于跨越多个上下文窗口的任务:

1. 为第一个上下文窗口使用一个不同的提示词: 用第一个上下文窗口来搭建框架(编写测试、创建配置脚本),然后用后续的上下文窗口在一份待办清单上迭代。
2. 让模型以结构化格式编写测试: 让 Claude 在开始工作前先创建测试,并以结构化格式(例如 tests.json)记录它们。这能带来更好的长期迭代能力。提醒 Claude 测试的重要性:“It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality.”(删除或修改测试是不可接受的,因为这可能导致功能缺失或有 bug。)
3. 搭建提升体验的工具: 鼓励 Claude 创建配置脚本(例如 init.sh),以便顺畅地启动服务器、运行测试套件和 linter。这能在从一个全新的上下文窗口继续工作时,避免重复劳动。
4. 重新开始还是压缩: 当一个上下文窗口被清空时,可以考虑用一个全新的上下文窗口重新开始,而不是使用压缩。Claude 最新一代模型极其擅长从本地文件系统中发现状态。在某些情况下,你可能想利用这一点来替代压缩。要对它该如何开始给出明确的规定:
   • “Call pwd; you can only read and write files in this directory.”(调用 pwd;你只能在这个目录里读写文件。)
   • “Review progress.txt, tests.json, and the git logs.”(查看 progress.txt、tests.json 和 git 日志。)
   • “Manually run through a fundamental integration test before moving on to implementing new features.”(在着手实现新功能之前,手动跑一遍基础的集成测试。)
5. 提供验证工具: 随着自主任务的时长增长,Claude 需要在没有持续人工反馈的情况下验证正确性。诸如 Playwright MCP 服务器或用于测试 UI 的计算机操作能力等工具会很有帮助。
6. 鼓励充分利用上下文: 提示 Claude 在转向下一部分之前,先高效地完成各个组件:

This is a very long task, so it may be beneficial to plan out your work clearly. It's encouraged to spend your entire output context working on the task - just make sure you don't run out of context with significant uncommitted work. Continue working systematically until you have completed this task.

状态管理最佳实践

• 对状态数据使用结构化格式: 在追踪结构化信息(如测试结果或任务状态)时,使用 JSON 或其他结构化格式,以帮助 Claude 理解 schema 要求
• 对进度笔记使用非结构化文本: 自由格式的进度笔记很适合追踪总体进展和上下文
• 用 git 来追踪状态: Git 提供了一份”做了什么”的日志,以及可以恢复的检查点。Claude 最新一代模型在用 git 跨多个会话追踪状态这件事上表现尤其出色。
• 强调增量进展: 明确要求 Claude 持续追踪自己的进度,并专注于增量工作

平衡自主性与安全

没有引导的话,Claude Opus 4.6 可能会采取一些难以撤销、或会影响共享系统的行动,比如删除文件、强制推送或向外部服务发帖。如果你希望 Claude Opus 4.6 在采取可能有风险的行动之前先确认,就在你的提示词里加上引导:

Consider the reversibility and potential impact of your actions. You are encouraged to take local, reversible actions like editing files or running tests, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding.

Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending messages, modifying shared infrastructure

When encountering obstacles, do not use destructive actions as a shortcut. For example, don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be in-progress work.

研究与信息搜集

Claude 最新一代模型展现出卓越的智能体搜索能力,能有效地从多个来源查找并综合信息。要获得最佳的研究结果:

1. 提供清晰的成功标准: 界定什么样的答案才算成功回答了你的研究问题
2. 鼓励来源核实: 让 Claude 跨多个来源核实信息
3. 对于复杂的研究任务,采用结构化的方法:

Search for this information in a structured way. As you gather data, develop several competing hypotheses. Track your confidence levels in your progress notes to improve calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or research notes file to persist information and provide transparency. Break down this complex research task systematically.

这种结构化的方法让 Claude 能够查找并综合几乎任何一条信息,并对自己的发现做迭代式的自我批评,无论语料规模有多大。

子智能体编排

Claude 最新一代模型展现出显著增强的原生子智能体编排能力。这些模型能够识别出哪些任务适合把工作委派给专门的子智能体,并主动这么做,无需明确指示。

要利用好这一行为:

1. 确保子智能体工具定义清晰: 让子智能体工具可用,并在工具定义中加以描述
2. 让 Claude 自然地编排: Claude 会在无需明确指示的情况下恰当地委派
3. 留意过度使用: Claude Opus 4.6 对子智能体有很强的偏好,可能会在一个更简单、更直接的做法就足够的场合下派生它们。比如,当一次直接的 grep 调用更快也足够用时,模型却可能为了探索代码而派生子智能体。

如果你看到子智能体被过度使用,就加上明确的引导,说明什么时候适合、什么时候不适合用子智能体:

Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state. For simple tasks, sequential operations, single-file edits, or tasks where you need to maintain context across steps, work directly rather than delegating.

串联复杂的提示词

有了自适应思考和子智能体编排,Claude 在内部就能处理大多数多步推理。当你需要检查中间输出、或强制实施某种特定的流水线结构时,显式的提示链(把一个任务拆成依次进行的多个 API 调用)依然有用。

最常见的链式模式是自我纠正: 生成一份初稿 → 让 Claude 对照标准审查它 → 让 Claude 基于审查来修订。每一步都是一次独立的 API 调用,这样你就能在任何节点记录、评估或分支。

减少智能体编码中的文件创建

Claude 最新一代模型有时可能会为了测试和迭代而创建新文件,在处理代码时尤其如此。这种做法让 Claude 能把文件——尤其是 python 脚本——当作”临时草稿纸”,再保存它的最终输出。使用临时文件能改善结果,在智能体编码场景中尤为明显。

如果你更希望尽量减少净新增的文件创建,可以指示 Claude 自己善后:

If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task.

过度积极

Claude Opus 4.5 和 Claude Opus 4.6 有一种倾向,会通过创建额外文件、添加不必要的抽象、或构建未被要求的灵活性来过度工程化。如果你看到这种不想要的行为,就加上具体的引导,让方案保持精简。

例如:

Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused:

- Scope: Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.

- Documentation: Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).

- Abstractions: Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task.

避免一味追求测试通过和硬编码

Claude 有时会过于侧重于让测试通过,从而牺牲了更通用的方案;或者会用一些变通手段,比如为复杂的重构写辅助脚本,而不是直接使用标准工具。要防止这种行为、确保方案稳健且可泛化:

Please write a high-quality, general-purpose solution using the standard tools available. Do not create helper scripts or workarounds to accomplish the task more efficiently. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs. Instead, implement the actual logic that solves the problem generally.

Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution. Provide a principled implementation that follows best practices and software design principles.

If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them. The solution should be robust, maintainable, and extendable.

在智能体编码中尽量减少幻觉

Claude 最新一代模型更不容易产生幻觉,会基于代码给出更准确、更有依据、更智能的答案。要进一步鼓励这种行为并尽量减少幻觉:

<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. Never make any claims about code before investigating unless you are certain of the correct answer - give grounded and hallucination-free answers.
</investigate_before_answering>

能力专项提示

增强的视觉能力

相比以往的 Claude 模型,Claude Opus 4.5 和 Claude Opus 4.6 拥有增强的视觉能力。它们在图像处理和数据抽取任务上表现更好,尤其是在上下文中存在多张图像时。这些提升也延续到了计算机操作上——模型能更可靠地解读截图和 UI 元素。你还可以把视频拆成帧,用这些模型来分析视频。

有一种已被证明有效、能进一步提升性能的技巧:给 Claude 一个裁剪工具或 skill。测试表明,当 Claude 能够”放大”图像中的相关区域时,图像评测上会有持续的提升。Anthropic 已经为裁剪工具创建了一份 cookbook。

前端设计

Claude Opus 4.5 和 Claude Opus 4.6 擅长构建复杂的、真实世界的 Web 应用,前端设计能力很强。然而,在没有引导的情况下,模型可能会退回到通用套路,造出被用户称为”AI 味”产出(AI slop)的那种东西。要创造独特、有创意、令人惊喜又愉悦的前端:

关于改进前端设计的详细指南,参见博客文章通过 skill 改进前端设计。

下面是一段你可以用来鼓励更好前端设计的系统提示词片段:

<frontend_aesthetics>
You tend to converge toward generic, "on distribution" outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.

Focus on:
- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.

Avoid generic AI-generated aesthetics:
- Overused font families (Inter, Roboto, Arial, system fonts)
- Clichéd color schemes (particularly purple gradients on white backgrounds)
- Predictable layouts and component patterns
- Cookie-cutter design that lacks context-specific character

Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!
</frontend_aesthetics>

你也可以参阅完整的 skill 定义。

迁移注意事项

从更早一代迁移到 Claude 4.6 系列模型时:

1. 把想要的行为说具体: 考虑准确描述你希望在输出中看到什么。
2. 用修饰语来框定你的指令: 添加一些鼓励 Claude 提升输出质量和细节的修饰语,有助于更好地塑造 Claude 的表现。比如,不要写”Create an analytics dashboard”,而是用”Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.”。
3. 明确请求特定的功能: 想要动画和交互元素时,应当明确提出。
4. 更新思考配置: Claude 4.6 系列模型使用自适应思考(thinking: {type: "adaptive"}),而非带 budget_tokens 的手动思考。用 effort 参数来控制思考深度。
5. 迁移、不再使用预填充回复: 从 Claude 4.6 系列模型开始,最后一个助手回合上的预填充回复不再被支持。关于替代方案的详细指引,参见迁移、不再使用预填充回复。
6. 调优反偷懒提示: 如果你的提示词以前是鼓励模型更周全、或更激进地使用工具的,就把那段引导收一收。Claude 4.6 系列模型要主动得多,可能会在那些为以往模型所需要的指令上过度触发。

详细的迁移步骤,参见迁移指南。

从 Claude Sonnet 4.5 迁移到 Claude Sonnet 4.6

Claude Sonnet 4.6 默认的 effort 档位是 high,而 Claude Sonnet 4.5 没有 effort 参数。从 Claude Sonnet 4.5 迁移到 Claude Sonnet 4.6 时,考虑调整 effort 参数。如果不显式设置,你可能会因为默认的 effort 档位而遇到更高的延迟。

推荐的 effort 设置:

• 大多数应用用 Medium
• 大流量或对延迟敏感的工作负载用 Low
• 在 medium 或 high 档,设一个较大的最大输出 token 预算(推荐 64k token),给模型留出思考和行动的空间

何时改用 Opus 4.8: 对于最难、最长程的问题(大规模代码迁移、深度研究、长时间的自主工作),Opus 4.8 仍是正确的选择。Sonnet 4.6 则针对那些最看重快速周转和成本效率的工作负载做了优化。

如果你没有使用扩展思考

如果你在 Claude Sonnet 4.5 上没有使用扩展思考,那么在 Claude Sonnet 4.6 上也可以继续不用。你应当把 effort 显式设置到适合你场景的档位。在禁用思考的 low 档下,相比不带扩展思考的 Claude Sonnet 4.5,你可以预期获得相近或更好的性能。

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "disabled"},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

如果你正在使用扩展思考

如果你在 Claude Sonnet 4.5 上使用带 budget_tokens 的扩展思考,它在 Claude Sonnet 4.6 上仍然可用,但已被弃用。请迁移到带 effort 参数的自适应思考。

迁移到自适应思考

自适应思考特别适合以下几种工作负载模式:

• 自主的多步智能体: 把需求转化为可工作软件的编码智能体、数据分析流水线,以及模型跨许多步骤独立运行的 bug 查找。自适应思考让模型能逐步校准自己的推理,在更长的轨迹上保持正轨。对于这些工作负载,从 high 档起步。如果在意延迟或 token 用量,就降到 medium。
• 计算机操作智能体: Claude Sonnet 4.6 使用自适应模式,在计算机操作评测上达到了同类最佳的准确率。
• 双峰工作负载: 简单任务和困难任务混杂的场景——自适应思考会在简单查询上跳过思考,在复杂查询上深入推理。

使用自适应思考时,在你的任务上评估 medium 和 high 档。合适的档位取决于你的工作负载在质量、延迟和 token 用量之间的取舍。

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

迁移期间保留 budget_tokens

如果你在迁移期间需要临时保留 budget_tokens,16k token 左右的预算能为较难的问题留出余量,同时又不至于有 token 用量失控的风险。这种配置已被弃用,并将在未来某个模型版本中移除。

对于编码场景(智能体编码、工具密集型工作流、代码生成),从 medium 档起步:

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=16384,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

对于聊天和非编码场景(聊天、内容生成、搜索、分类),从 low 档起步:

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    thinking={"type": "enabled", "budget_tokens": 16384},
    output_config={"effort": "low"},
    messages=[{"role": "user", "content": "..."}],
)

相关笔记

• 不碰模型与提示词，让编程智能体更聪明 —— 提示词之外提升智能体表现的另一视角
• Skill 编写最佳实践 —— 把提示工程经验固化进 Skill
• 解剖智能体Harness —— 提示工程如何嵌入智能体 harness
• 用动态工作流大规模编排子智能体 —— 对应文中”子智能体编排”一节
• 我们如何在各款产品中围堵 Claude —— 对应文中”提示注入”与环境层防护