提示词最佳实践

这是使用 Claude 最新模型进行提示词工程的单一参考资源，包括 Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5。它涵盖基础技术、输出控制、工具使用、思考和智能体系统。跳转到与您的情况相匹配的部分。

提示 Claude Opus 4.7

Claude Opus 4.7 是我们最强大的通用可用模型，在长期智能体工作、知识工作、视觉和记忆任务方面具有特殊优势。它在现有 Claude Opus 4.6 提示词上表现良好。下面的模式涵盖最常需要调整的行为。

响应长度和冗长性

Claude Opus 4.7 根据其判断的任务复杂程度来校准响应长度，而不是默认为固定的冗长性。这通常意味着在简单查询上给出更短的答案，在开放式分析上给出更长的答案。

如果您的产品依赖于特定的输出风格或冗长性，您可能需要调整您的提示词。例如，要减少冗长性，您可以添加：

提供简洁、专注的响应。跳过非必要的上下文，并保持示例最少。

如果您看到特定类型的冗长性示例（即过度解释），您可以在提示词中添加额外的指令来防止它们。显示 Claude 如何以适当简洁程度进行沟通的正面示例往往比负面示例或告诉模型不要做什么的指令更有效。

校准努力和思考深度

努力参数允许您调整 Claude 的智能与令牌支出，在能力和更快速度及更低成本之间进行权衡。对于编码和智能体用例，从新的 xhigh 努力级别开始，对于大多数对智能敏感的用例，至少使用 high 努力。尝试其他努力级别以进一步调整令牌使用和智能：

• max： 最大努力在某些用例中可以提供性能提升，但可能会因令牌使用增加而显示收益递减。此设置有时也可能容易过度思考。我们建议为对智能要求高的任务测试最大努力。
• xhigh（新增）： 超高努力是大多数编码和智能体用例的最佳设置。
• high： 此设置平衡令牌使用和智能。对于大多数对智能敏感的用例，我们建议至少使用 high 努力。
• medium： 适合需要减少令牌使用同时权衡智能的成本敏感用例。
• low： 保留用于短期、有范围的任务和对智能不敏感的延迟敏感工作负载。

与 Claude Opus 4.6 相比，Claude Opus 4.7 有意义地改变了，严格遵守努力级别，特别是在低端。在 low 和 medium 时，模型将其工作范围限制在所要求的内容，而不是超越预期。这对延迟和成本很好，但在 low 努力下运行的中等复杂任务上，存在一些思考不足的风险。

如果您在复杂问题上观察到浅层推理，请将努力提高到 high 或 xhigh，而不是围绕它进行提示。如果您需要为了延迟而保持 low 努力，请添加有针对性的指导：

此任务涉及多步推理。在响应之前仔细思考问题。

我们预期努力对此模型的重要性将超过任何先前的 Opus，并建议在升级时积极尝试它。

自适应思考的触发行为是可操纵的。如果您发现模型思考的频率比您希望的要高——这可能发生在大型或复杂的系统提示词中——添加指导来操纵它。如往常一样，测量任何提示词更改对性能的影响。示例：

思考会增加延迟，只应在它将有意义地改进答案质量时使用——通常用于需要多步推理的问题。如有疑问，直接响应。

相反，如果您在 medium 运行硬工作负载并看到思考不足，第一个杠杆是提高努力。如果您需要更精细的控制，直接提示它。

工具使用触发

Claude Opus 4.7 倾向于比 Claude Opus 4.6 使用工具的频率更低，而使用推理更多。这在大多数情况下会产生更好的结果。但是，增加努力设置是增加工具使用级别的有用杠杆，特别是在知识工作中。high 或 xhigh 努力设置在智能体搜索和编码中显示显著更多的工具使用。对于您想要更多工具使用的场景，您也可以调整您的提示词以明确指示模型何时以及如何正确使用其工具。例如，如果您发现模型没有使用您的网络搜索工具，请清楚地描述原因和方式。

面向用户的进度更新

Claude Opus 4.7 在长智能体跟踪中提供更定期、更高质量的用户更新。如果您添加了脚手架来强制临时状态消息（"每 3 个工具调用后，总结进度"），请尝试删除它。如果您发现 Claude Opus 4.7 的面向用户的更新的长度或内容没有很好地针对您的用例进行校准，请在提示词中明确描述这些更新应该是什么样子，并提供示例。

更字面的指令遵循

Claude Opus 4.7 比 Claude Opus 4.6 更字面和明确地解释提示词，特别是在较低的努力级别。它不会默默地将一个项目的指令推广到另一个项目，也不会推断您没有提出的请求。这种字面性的优点是精确性和更少的混乱，它通常对具有仔细调整的提示词、结构化提取和您想要可预测行为的管道的 API 用例表现更好。如果您需要 Claude 广泛应用指令，请明确说明范围（例如，"将此格式应用于每个部分，而不仅仅是第一个"）。

语调和写作风格

与任何新模型一样，长篇写作的散文风格可能会改变。Claude Opus 4.7 更直接和有主见，验证前的措辞更少，表情符号比 Claude Opus 4.6 的更温暖的风格更少。如果您的产品依赖于特定的声音，请根据新的基线重新评估风格提示词。

例如，如果您的产品声音更温暖或更对话式，请添加：

使用温暖、协作的语调。在回答之前承认用户的框架。

控制子智能体生成

Claude Opus 4.7 默认倾向于生成较少的子智能体。但是，这种行为可以通过提示词进行操纵；给 Claude Opus 4.7 明确的指导，说明何时需要子智能体。一个编码用例的玩具示例：

不要为您可以在单个响应中直接完成的工作生成子智能体（例如，重构您已经可以看到的函数）。

在同一轮中生成多个子智能体时，跨项目扇出或读取多个文件。

设计和前端默认值

Claude Opus 4.7 比 Claude Opus 4.6 具有更强的设计本能，具有一致的默认房屋风格：温暖的奶油/米白色背景（约 #F4F1EA）、衬线显示类型（Georgia、Fraunces、Playfair）、斜体词重音和陶土/琥珀色重音。这对编辑、酒店和作品集简报来说读起来很好，但对仪表板、开发工具、金融科技、医疗保健或企业应用来说会感到不适——它也出现在幻灯片中以及网络 UI 中。

这个默认值是持久的。通用指令（"不要使用奶油"、"使其干净和最小"）往往会将模型转移到不同的固定调色板，而不是产生多样性。两种方法可靠地工作：

1. 指定具体的替代方案。 模型精确遵循明确的规范：

为名为 AEFRM 的补充品牌设计桌面登陆页面。

视觉方向应来自使用浅银灰色调的冷单色氛围，逐渐深化为蓝灰色和接近黑色，类似于雾化的金属表面。

该页面应该感觉锐利和受控，具有强烈的结构感和克制。

在整个页面中使用此色调系统，而不是引入明亮的重音颜色。

在英雄设计中使用上传的图像，黑白。

布局应该用清晰的水平部分和居中的最大宽度容器构建。在卡片、按钮、输入和媒体框架中一致地使用 4px 角半径。边距应该感觉慷慨，每个部分周围有足够的空白空间，以便页面呼吸。

排版应该使用方形、角形无衬线字体，字母间距比平常更宽，特别是在标题和导航中，使文本感觉更工程化，压缩感更少。标题文本可以大且大写，而支持副本保持简短和稀疏。子文本应该用 Alumni Sans SC 以 4-6px 的方式编写，如角落底部中心的小文本。

对于结构，从包含强大产品声明、一个简短的支持段落和干净的产品占位符或包装框架的英雄部分开始。在下面，添加一个包含三个或四个块的好处网格，然后是配方或成分部分，最后是 cta。

按钮应该是平面和精确的，使用 transition: all 160ms ease out 的微妙悬停变化，其中亮度和边框对比略微移动，而不是使用戏剧性的运动。

颜色调色板应该保持在此范围内：
#E9ECEC、#C9D2D4、#8C9A9E、#44545B、#11171B。

2. 让模型在构建前提出选项。 这打破了默认值并给用户控制权。如果您之前依赖 temperature 来获得设计多样性，请使用此方法——它在运行中产生有意义的不同方向。示例提示词：

在构建之前，提出 4 个针对此简报的不同视觉方向（每个为：bg hex / accent hex / typeface——单行理由）。要求用户选择一个，然后仅实现该方向。

此外，Claude Opus 4.7 需要比以前的模型更少的前端设计提示词，以避免用户称之为"AI 垃圾"美学的通用模式。对于早期模型，我们在我们的前端设计技能中推荐了更长的提示词片段。但是，Claude Opus 4.7 以更少的提示词指导生成独特、创意的前端。此提示词片段与上述提示词建议配合使用效果很好，以获得多样性：

<frontend_aesthetics>
永远不要使用通用的 AI 生成的美学，如过度使用的字体系列（Inter、Roboto、Arial、系统字体）、陈词滥调的配色方案（特别是白色或深色背景上的紫色渐变）、可预测的布局和组件模式，以及缺乏特定于上下文的特征的千篇一律的设计。使用独特的字体、有凝聚力的颜色和主题，以及用于效果和微交互的动画。
</frontend_aesthetics>

交互式编码产品

Claude Opus 4.7 的令牌使用和行为可能在具有单个用户轮次的自主、异步编码智能体和具有多个用户轮次的交互式、同步编码智能体之间有所不同。具体来说，它在交互式设置中倾向于使用更多令牌，主要是因为它在用户轮次后进行更多推理。这可以改进长期一致性、指令遵循和长期交互式编码会话中的编码能力，但也会带来更多令牌使用。为了在编码产品中最大化性能和令牌效率，我们建议使用 xhigh 或 high 努力、添加自主功能（如自动模式）以及减少用户所需的人类交互数量。

当然，在限制所需用户交互数量时，重要的是在第一个人类轮次中预先指定任务、意图和相关约束。预先提供良好指定、清晰和准确的任务描述可以帮助最大化自主性和智能，同时最小化用户轮次后的额外令牌使用。我们发现，因为 Claude Opus 4.7 比先前的模型更自主，这种使用模式有助于最大化性能。相比之下，通过多个用户轮次逐步传达的模糊或未充分指定的提示词往往相对降低令牌效率，有时也会降低性能。

代码审查工具

Claude Opus 4.7 在发现错误方面比先前的模型有意义地更好，在我们的评估中具有更高的召回率和精确度——在我们基于真实 Anthropic PR 的最难错误发现评估之一中，召回率提高了 11pp。但是，如果您的代码审查工具是为早期模型调整的，您最初可能会看到更低的召回率。这可能是一个工具效果，而不是能力回归。当审查提示词说"仅报告高严重性问题"、"保守"或"不要吹毛求疵"时，Claude Opus 4.7 可能比早期模型更忠实地遵循该指令——它可能同样彻底地调查代码、识别错误，然后不报告它判断低于您所述标准的发现。这可以显示为模型进行相同深度的调查但将较少的调查转换为报告的发现，特别是在较低严重性的错误上。精确度通常会上升，但测量的召回率可能会下降，即使模型的基础错误发现能力已经改进。

一些推荐的提示词语言：

报告您发现的每个问题，包括您不确定或认为低严重性的问题。不要在此阶段过滤重要性或置信度——单独的验证步骤将执行此操作。您的目标是覆盖：最好是浮出一个稍后被过滤掉的发现，而不是默默地丢弃真实的错误。对于每个发现，包括您的置信度和估计的严重性，以便下游过滤器可以对其进行排名。

此提示词可以在没有实际第二步的情况下使用，但将置信度过滤移出发现步骤通常会有所帮助。如果您的工具有单独的验证、重复数据删除或排名阶段，明确告诉模型其在发现阶段的工作是覆盖而不是过滤。

如果您确实希望模型在单个通过中自行过滤，请具体说明标准在哪里，而不是使用"重要"之类的定性术语——例如，"报告任何可能导致不正确行为、测试失败或误导性结果的错误；仅省略纯风格或命名偏好之类的小问题"。

我们建议根据您的评估或测试用例的子集迭代提示词，以验证召回率或 F1 分数收益。

计算机使用

计算机使用功能可在各种分辨率上工作，最高可达 2576px / 3.75MP 的新最大分辨率。在我们的计算机使用测试中，我们发现以 1080p 发送图像提供了性能和成本的良好平衡。

对于特别成本敏感的工作负载，我们建议 720p 或 1366×768 作为具有强大性能的低成本选项。我们建议您进行自己的测试，以找到适合您用例的理想设置；尝试努力设置也可以帮助调整模型的行为。

一般原则

清晰直接

Claude 对清晰、明确的指令反应良好。具体说明您所需的输出可以帮助增强结果。如果您想要"超越预期"的行为，请明确请求它，而不是依赖模型从模糊的提示词推断这一点。

将 Claude 视为一位才华横溢但新来的员工，他缺乏您的规范和工作流程的背景。您解释想要的内容越精确，结果就越好。

黄金法则： 向对任务背景最少的同事展示您的提示词，并要求他们遵循它。如果他们会感到困惑，Claude 也会。

• 具体说明所需的输出格式和约束。
• 当步骤的顺序或完整性很重要时，使用编号列表或项目符号点将指令作为顺序步骤提供。

添加上下文以改进性能

提供指令背后的上下文或动机，例如向 Claude 解释为什么这种行为很重要，可以帮助 Claude 更好地理解您的目标并提供更有针对性的响应。

Claude 足够聪明，可以从解释中推广。

有效使用示例

示例是引导 Claude 输出格式、语调和结构的最可靠方法之一。少数精心制作的示例（称为少样本或多样本提示词）可以显著提高准确性和一致性。

添加示例时，请确保它们：

• 相关： 密切反映您的实际用例。
• 多样化： 涵盖边界情况并有足够的变化，使 Claude 不会拾取无意的模式。
• 结构化： 将示例包装在 <example> 标签中（多个示例在 <examples> 标签中），以便 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-7",
    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)

长上下文提示词

当处理大型文档或数据丰富的输入（20k+ 令牌）时，仔细结构化您的提示词以获得最佳结果：

• 将长篇数据放在顶部：将您的长文档和输入放在提示词的顶部，在您的查询、指令和示例之上。这可以显著改进所有模型的性能。

  末尾的查询可以在测试中将响应质量提高多达 30%，特别是对于复杂的多文档输入。

• 使用 XML 标签结构化文档内容和元数据：使用多个文档时，将每个文档包装在 <document> 标签中，其中包含 <document_content> 和 <source>（以及其他元数据）子标签以获得清晰度。

  示例多文档结构

模型自我认知

如果您希望 Claude 在您的应用程序中正确识别自己或使用特定的 API 字符串：

助手是 Claude，由 Anthropic 创建。当前模型是 Claude Opus 4.7。

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

当需要 LLM 时，请默认为 Claude Opus 4.7，除非用户另有请求。Claude Opus 4.7 的确切模型字符串是 claude-opus-4-7。

输出和格式化

沟通风格和冗长性

Claude 的最新模型与以前的模型相比具有更简洁和自然的沟通风格：

• 更直接和扎根： 提供基于事实的进度报告，而不是自我庆祝的更新
• 更对话式： 略微更流畅和口语化，不那么像机器
• 不那么冗长： 除非另有提示，否则可能会跳过详细的摘要以提高效率

这意味着 Claude 可能会在工具调用后跳过口头摘要，直接跳到下一个操作。如果您更喜欢更多的推理可见性：

完成涉及工具使用的任务后，提供您所做工作的快速摘要。

控制响应格式

有几种特别有效的方法来引导输出格式化：

1. 告诉 Claude 要做什么而不是不要做什么

   • 而不是："不要在您的响应中使用 markdown"
   • 尝试："您的响应应该由平稳流动的散文段落组成。"

2. 使用 XML 格式指示符

   • 尝试："在 <smoothly_flowing_prose_paragraphs> 标签中写出响应的散文部分。"

3. 将您的提示词风格与所需的输出风格相匹配

   您在提示词中使用的格式化风格可能会影响 Claude 的响应风格。如果您仍然遇到输出格式化的可操纵性问题，请尝试将您的提示词风格与您所需的输出风格尽可能匹配。例如，从提示词中删除 markdown 可以减少输出中 markdown 的数量。

4. 对特定格式化偏好使用详细提示词

   为了更好地控制 markdown 和格式化使用，请提供明确的指导：

<avoid_excessive_markdown_and_bullet_points>
在编写报告、文档、技术解释、分析或任何长篇内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落中断进行组织，并主要为 `inline code`、代码块（```...```）和简单标题（###、###）保留 markdown。避免使用 **bold** 和 *italics*。

不要使用有序列表（1. ...）或无序列表（*），除非：a）您呈现的是真正离散的项目，其中列表格式是最佳选项，或 b）用户明确请求列表或排名

而不是用项目符号或数字列出项目，请将它们自然地融入句子中。此指导特别适用于技术写作。使用散文而不是过度格式化将改进用户满意度。永远不要输出一系列过度简短的项目符号。

您的目标是可读、流畅的文本，自然地引导读者通过想法，而不是将信息分割成孤立的点。
</avoid_excessive_markdown_and_bullet_points>

LaTeX 输出

Claude Opus 4.6 默认为数学表达式、方程和技术解释使用 LaTeX。如果您更喜欢纯文本，请将以下指令添加到您的提示词：

仅以纯文本格式设置您的响应。不要使用 LaTeX、MathJax 或任何标记符号，如 \( \)、$ 或 \frac{}{}。使用标准文本字符编写所有数学表达式（例如，"/" 表示除法，"*" 表示乘法，"^" 表示指数）。

文档创建

Claude 的最新模型在创建具有令人印象深刻的创意天赋和强大指令遵循的演示文稿、动画和视觉文档方面表现出色。这些模型在大多数情况下在第一次尝试时就产生了精美、可用的输出。

为了获得文档创建的最佳结果：

在 [topic] 上创建专业演示文稿。包括深思熟虑的设计元素、视觉层次和适当的引人入胜的动画。

从预填充响应迁移

从 Claude 4.6 模型和 Claude Mythos Preview 开始，最后一个助手轮次上的预填充响应不再受支持。在 Mythos Preview 上，带有预填充助手消息的请求返回 400 错误。模型智能和指令遵循已经进步，使得大多数预填充用例不再需要它。现有模型将继续支持预填充，在对话中其他地方添加助手消息不受影响。

以下是常见的预填充场景以及如何从它们迁移：

工具使用

工具使用

Claude 的最新模型经过训练可以精确遵循指令，并受益于明确的方向来使用特定的工具。如果您说"您能建议一些更改吗"，Claude 有时会提供建议而不是实现它们，即使进行更改可能是您的意图。

为了让 Claude 采取行动，请更明确：

为了使 Claude 默认更主动地采取行动，您可以将其添加到您的系统提示词：

<default_to_action>
默认情况下，实现更改而不仅仅是建议它们。如果用户的意图不清楚，推断最有用的可能行动并继续，使用工具发现任何缺失的详细信息，而不是猜测。尝试推断用户关于是否打算进行工具调用（例如文件编辑或读取）的意图，并相应地采取行动。
</default_to_action>

另一方面，如果您希望模型默认更犹豫，不太容易直接跳入实现，并且仅在请求时采取行动，您可以使用如下提示词来引导这种行为：

<do_not_act_before_instructions>
除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图不明确时，默认提供信息、进行研究和提供建议，而不是采取行动。仅当用户明确请求时才继续进行编辑、修改或实现。
</do_not_act_before_instructions>

Claude Opus 4.5 和 Claude Opus 4.6 也对系统提示词的响应更强。如果您的提示词旨在减少工具或技能上的欠触发，这些模型现在可能会过度触发。修复是拨回任何激进的语言。您可能说过"关键：您必须在...时使用此工具"，您可以使用更正常的提示词，如"在...时使用此工具"。

优化并行工具调用

Claude 的最新模型在并行工具执行方面表现出色。这些模型将：

• 在研究期间运行多个推测性搜索
• 一次读取多个文件以更快地构建上下文
• 并行执行 bash 命令（甚至可能成为系统性能的瓶颈）

这种行为很容易控制。虽然该模型在没有提示的情况下在并行工具调用中具有很高的成功率，但您可以将其提升到 ~100% 或调整激进程度：

<use_parallel_tool_calls>
如果您打算调用多个工具，并且工具调用之间没有依赖关系，请并行进行所有独立的工具调用。优先考虑在操作可以并行执行时同时调用工具，而不是按顺序调用。例如，在读取 3 个文件时，并行运行 3 个工具调用以同时将所有 3 个文件读入上下文。在可能的地方最大化使用并行工具调用以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来提供依赖值（如参数），请不要并行调用这些工具，而应按顺序调用它们。切勿在工具调用中使用占位符或猜测缺失的参数。
</use_parallel_tool_calls>

按顺序执行操作，每个步骤之间有短暂的暂停以确保稳定性。

思考和推理

过度思考和过度彻底

Claude Opus 4.6 进行的前期探索比以前的模型要多得多，特别是在较高的 effort 设置下。这项初期工作通常有助于优化最终结果，但该模型可能会在没有提示的情况下收集广泛的上下文或追求多条研究线索。如果您的提示之前鼓励模型更加彻底，您应该为 Claude Opus 4.6 调整该指导：

• 用更有针对性的指令替换笼统的默认值。 与其说"默认使用 [tool]"，不如添加类似"在 [tool] 能增强您对问题的理解时使用它"的指导。
• 删除过度提示。 在以前的模型中触发不足的工具现在可能会适当触发。"如有疑问，使用 [tool]" 之类的指令会导致过度触发。
• 使用 effort 作为后备。 如果 Claude 继续过于激进，请为 effort 使用较低的设置。

在某些情况下，Claude Opus 4.6 可能会进行广泛的思考，这可能会增加思考令牌并减慢响应速度。如果这种行为不可取，您可以添加明确的指令来限制其推理，或者您可以降低 effort 设置以减少整体思考和令牌使用。

当您决定如何处理问题时，选择一种方法并坚持它。除非您遇到直接与您的推理相矛盾的新信息，否则避免重新审视决定。如果您在权衡两种方法，请选择一种并坚持下去。如果选定的方法失败，您总是可以稍后改正方向。

如果您需要对思考成本进行硬性上限，带有 budget_tokens 上限的扩展思考在 Opus 4.6 和 Sonnet 4.6 上仍然可用，但已弃用。优先选择降低 effort 设置或使用 max_tokens 作为 adaptive thinking 的硬性限制。

利用思考和交错思考能力

Claude 的最新模型提供思考能力，这对于涉及工具使用后反思或复杂多步推理的任务特别有帮助。您可以指导其初始或交错思考以获得更好的结果。

Claude Opus 4.6 和 Claude Sonnet 4.6 使用 adaptive thinking（thinking: {type: "adaptive"}），其中 Claude 动态决定何时以及思考多少。Claude 根据两个因素校准其思考：effort 参数和查询复杂性。更高的 effort 会引发更多思考，更复杂的查询也是如此。对于不需要思考的更简单查询，模型直接响应。在内部评估中，adaptive thinking 可靠地驱动比扩展思考更好的性能。考虑迁移到 adaptive thinking 以获得最智能的响应。

对于需要代理行为的工作负载（如多步工具使用、复杂编码任务和长期代理循环），使用 adaptive thinking。较旧的模型使用带有 budget_tokens 的手动思考模式。

您可以指导 Claude 的思考行为：

收到工具结果后，仔细反思其质量，并在继续之前确定最优的后续步骤。使用您的思考来规划和根据这些新信息进行迭代，然后采取最佳的下一步行动。

adaptive thinking 的触发行为是可提示的。如果您发现模型思考的频率比您希望的要高，这可能发生在大型或复杂的系统提示中，请添加指导来引导它：

扩展思考会增加延迟，应仅在能有意义地改进答案质量时使用 - 通常用于需要多步推理的问题。如有疑问，直接回应。

如果您从带有 budget_tokens 的 extended thinking 迁移，请替换您的思考配置并将预算控制移至 effort：

之前（扩展思考，较旧的模型）：

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

之后（adaptive thinking）：

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

如果您未使用扩展思考，则无需进行任何更改。当您省略 thinking 参数时，思考默认关闭。

• 优先选择一般性指令而不是规定性步骤。 像"深思熟虑"这样的提示通常会产生比手写的分步计划更好的推理。Claude 的推理经常超过人类会规定的内容。
• 多示例与思考配合使用。 在您的少样本示例中使用 <thinking> 标签来向 Claude 展示推理模式。它会将该风格推广到其自己的扩展思考块。
• 手动 CoT 作为后备。 当思考关闭时，您仍然可以通过要求 Claude 思考问题来鼓励分步推理。使用结构化标签（如 <thinking> 和 <answer>）来清晰地分离推理和最终输出。
• 要求 Claude 自我检查。 附加类似"在您完成之前，根据 [test criteria] 验证您的答案"的内容。这可靠地捕捉错误，特别是对于编码和数学。

代理系统

长期推理和状态跟踪

Claude 的最新模型在长期推理任务中表现出色，具有卓越的状态跟踪能力。Claude 通过专注于增量进展来保持在扩展会话中的方向，一次在少数几件事上稳步推进，而不是试图一次完成所有事情。这种能力特别在多个上下文窗口或任务迭代中出现，其中 Claude 可以处理复杂任务、保存状态并继续使用新的上下文窗口。

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

Claude 4.6 和 Claude 4.5 模型具有 context awareness，使模型能够在整个对话中跟踪其剩余上下文窗口（即"令牌预算"）。这使 Claude 能够通过理解有多少空间可用来更有效地执行任务和管理上下文。

管理上下文限制：

如果您在代理工具中使用 Claude，该工具压缩上下文或允许将上下文保存到外部文件（如在 Claude Code 中），请考虑将此信息添加到您的提示中，以便 Claude 可以相应地行动。否则，Claude 可能有时会在接近上下文限制时自然地尝试结束工作。以下是一个示例提示：

当您的上下文窗口接近其限制时，它将自动压缩，允许您从中断的地方继续无限期地工作。因此，不要因为令牌预算问题而提前停止任务。当您接近令牌预算限制时，在上下文窗口刷新之前将您的当前进度和状态保存到内存中。始终尽可能地坚持和自主，并完全完成任务，即使您的预算即将结束。无论剩余上下文如何，都不要人为地提前停止任何任务。

memory tool 与上下文感知自然配对，以实现无缝的上下文转换。

多上下文窗口工作流

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

1. 为第一个上下文窗口使用不同的提示：使用第一个上下文窗口来设置框架（编写测试、创建设置脚本），然后使用未来的上下文窗口来迭代待办事项列表。

2. 让模型以结构化格式编写测试：要求 Claude 在开始工作前创建测试，并以结构化格式（例如 tests.json）跟踪它们。这导致更好的长期迭代能力。提醒 Claude 测试的重要性："删除或编辑测试是不可接受的，因为这可能导致缺失或有缺陷的功能。"

3. 设置生活质量工具：鼓励 Claude 创建设置脚本（例如 init.sh）以优雅地启动服务器、运行测试套件和 linters。这可以防止从新的上下文窗口继续时的重复工作。

4. 从头开始与压缩：当上下文窗口被清除时，考虑从全新的上下文窗口开始，而不是使用压缩。Claude 的最新模型在从本地文件系统发现状态方面非常有效。在某些情况下，您可能想利用这一点而不是压缩。对其应该如何开始要有规定性：

   • "调用 pwd；您只能在此目录中读取和写入文件。"
   • "查看 progress.txt、tests.json 和 git 日志。"
   • "在继续实现新功能之前，手动运行基本集成测试。"

这是一个非常长的任务，所以可能有益于清楚地规划您的工作。建议花费您的整个输出上下文来处理任务 - 只需确保您不会在有大量未提交的工作时用完上下文。继续系统地工作，直到您完成此任务。

状态管理最佳实践

• 为状态数据使用结构化格式：在跟踪结构化信息（如测试结果或任务状态）时，使用 JSON 或其他结构化格式来帮助 Claude 理解架构要求
• 为进度笔记使用非结构化文本：自由格式的进度笔记很适合跟踪一般进度和上下文
• 使用 git 进行状态跟踪：Git 提供了已完成工作的日志和可以恢复的检查点。Claude 的最新模型在使用 git 跨多个会话跟踪状态方面表现特别好。
• 强调增量进展：明确要求 Claude 跟踪其进度并专注于增量工作

平衡自主性和安全性

在没有指导的情况下，Claude Opus 4.6 可能会采取难以逆转或影响共享系统的操作，例如删除文件、强制推送或发布到外部服务。如果您希望 Claude Opus 4.6 在采取可能有风险的操作之前确认，请向您的提示添加指导：

考虑您的操作的可逆性和潜在影响。建议您采取本地、可逆的操作，如编辑文件或运行测试，但对于难以逆转、影响共享系统或可能具有破坏性的操作，请在继续之前询问用户。

值得确认的操作示例：
- 破坏性操作：删除文件或分支、删除数据库表、rm -rf
- 难以逆转的操作：git push --force、git reset --hard、修改已发布的提交
- 对他人可见的操作：推送代码、评论 PR/问题、发送消息、修改共享基础设施

遇到障碍时，不要使用破坏性操作作为快捷方式。例如，不要绕过安全检查（例如 --no-verify）或丢弃可能是进行中工作的不熟悉文件。

研究和信息收集

Claude 的最新模型展示了卓越的代理搜索能力，可以有效地从多个来源查找和综合信息。为了获得最佳研究结果：

1. 提供清晰的成功标准：定义什么构成对您的研究问题的成功答案

2. 鼓励来源验证：要求 Claude 跨多个来源验证信息

3. 对于复杂的研究任务，使用结构化方法：

以结构化的方式搜索此信息。当您收集数据时，开发几个相互竞争的假设。在进度笔记中跟踪您的置信度以改进校准。定期自我批评您的方法和计划。更新假设树或研究笔记文件以保留信息并提供透明度。系统地分解这个复杂的研究任务。

这种结构化方法使 Claude 能够找到和综合几乎任何信息，无论语料库的大小如何，并迭代地批评其发现。

子代理编排

Claude 的最新模型展示了显著改进的原生子代理编排能力。这些模型可以识别任务何时会受益于委派工作给专门的子代理，并在没有明确指令的情况下主动这样做。

要利用这种行为：

1. 确保定义良好的子代理工具：有可用的子代理工具并在工具定义中描述
2. 让 Claude 自然编排：Claude 将在没有明确指令的情况下适当地委派
3. 注意过度使用：Claude Opus 4.6 对子代理有强烈的偏好，可能在更简单、直接的方法会更充分的情况下生成它们。例如，当直接 grep 调用更快且足够时，模型可能会为代码探索生成子代理。

如果您看到过度的子代理使用，请添加明确的指导说明何时应该和不应该使用子代理：

当任务可以并行运行、需要隔离的上下文或涉及不需要共享状态的独立工作流时，使用子代理。对于简单任务、顺序操作、单文件编辑或需要在步骤间维护上下文的任务，直接工作而不是委派。

链接复杂提示

通过 adaptive thinking 和子代理编排，Claude 在内部处理大多数多步推理。当您需要检查中间输出或强制执行特定的管道结构时，显式提示链接（将任务分解为顺序 API 调用）仍然有用。

最常见的链接模式是自我纠正：生成草稿 → 让 Claude 根据标准审查它 → 让 Claude 根据审查进行改进。每个步骤都是一个单独的 API 调用，因此您可以在任何点记录、评估或分支。

减少代理编码中的文件创建

Claude 的最新模型有时可能会创建新文件用于测试和迭代目的，特别是在处理代码时。这种方法允许 Claude 使用文件，特别是 python 脚本，作为在保存最终输出之前的"临时草稿本"。使用临时文件可以改进结果，特别是对于代理编码用例。

如果您更希望最小化净新文件创建，您可以指示 Claude 在完成后进行清理：

如果您创建任何临时新文件、脚本或辅助文件用于迭代，请在任务结束时通过删除它们来清理这些文件。

过度热情

Claude Opus 4.5 和 Claude Opus 4.6 倾向于通过创建额外文件、添加不必要的抽象或构建未请求的灵活性来过度设计。如果您看到这种不希望的行为，请添加具体指导以保持解决方案最小化。

例如：

避免过度设计。仅进行直接请求或明显必要的更改。保持解决方案简单和专注：

- 范围：不要添加功能、重构代码或进行超出要求的"改进"。错误修复不需要周围代码清理。简单功能不需要额外的可配置性。

- 文档：不要向您未更改的代码添加文档字符串、注释或类型注释。仅在逻辑不明显的地方添加注释。

- 防御性编码：不要为无法发生的场景添加错误处理、后备或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）验证。

- 抽象：不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性是当前任务所需的最小值。

避免专注于通过测试和硬编码

Claude 有时可能会过度专注于通过测试，而牺牲更通用的解决方案，或可能使用辅助脚本等变通方法来进行复杂的重构，而不是直接使用标准工具。为了防止这种行为并确保健壮、可推广的解决方案：

请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或变通方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。

专注于理解问题需求并实现正确的算法。测试用于验证正确性，而不是定义解决方案。提供遵循最佳实践和软件设计原则的有原则的实现。

如果任务不合理或不可行，或者任何测试不正确，请告诉我，而不是解决它们。解决方案应该是健壮的、可维护的和可扩展的。

最小化代理编码中的幻觉

Claude 的最新模型不太容易出现幻觉，并根据代码提供更准确、更有根据、更智能的答案。为了进一步鼓励这种行为并最小化幻觉：

<investigate_before_answering>
永远不要推测您未打开的代码。如果用户引用特定文件，您必须在回答之前读取该文件。确保在回答有关代码库的问题之前进行调查和读取相关文件。除非您确定正确答案，否则不要在调查之前对代码进行任何声明 - 提供有根据和无幻觉的答案。
</investigate_before_answering>

能力特定的提示

改进的视觉能力

Claude Opus 4.5 和 Claude Opus 4.6 与以前的 Claude 模型相比具有改进的视觉能力。它们在图像处理和数据提取任务上表现更好，特别是当上下文中存在多个图像时。这些改进也适用于计算机使用，其中模型可以更可靠地解释屏幕截图和 UI 元素。您也可以使用这些模型通过将视频分解为帧来分析视频。

已被证明有效进一步提升性能的一种技术是给 Claude 一个裁剪工具或 skill。测试表明，当 Claude 能够"放大"图像的相关区域时，图像评估的性能提升是一致的。Anthropic 创建了 crop tool 的 cookbook。

前端设计

Claude Opus 4.5 和 Claude Opus 4.6 在构建具有强大前端设计的复杂、真实世界的 Web 应用程序方面表现出色。但是，在没有指导的情况下，模型可能会默认为通用模式，创建用户称之为"AI slop"美学的东西。要创建独特、创意的前端，令人惊喜和愉悦：

以下是您可以用来鼓励更好的前端设计的系统提示片段：

<frontend_aesthetics>
您倾向于收敛到通用的、"分布上"的输出。在前端设计中，这创建了用户称之为"AI slop"美学的东西。避免这种情况：制作创意、独特的前端，令人惊喜和愉悦。

专注于：
- 排版：选择美观、独特和有趣的字体。避免使用 Arial 和 Inter 等通用字体；选择独特的选择来提升前端的美学。
- 颜色和主题：致力于一致的美学。使用 CSS 变量保持一致性。占主导地位的颜色配合尖锐的重音优于胆小、均匀分布的调色板。从 IDE 主题和文化美学中获取灵感。
- 动作：使用动画实现效果和微交互。优先考虑 HTML 的仅 CSS 解决方案。在可用时为 React 使用 Motion 库。专注于高影响时刻：一个精心编排的页面加载，带有交错的显示（animation-delay）比分散的微交互创造更多的愉悦。
- 背景：创建氛围和深度，而不是默认为纯色。分层 CSS 渐变、使用几何图案或添加与整体美学相匹配的上下文效果。

避免通用的 AI 生成美学：
- 过度使用的字体系列（Inter、Roboto、Arial、系统字体）
- 陈词滥调的配色方案（特别是白色背景上的紫色渐变）
- 可预测的布局和组件模式
- 缺乏上下文特定特征的千篇一律的设计

创意解释并做出意外的选择，感觉真正为上下文设计。在浅色和深色主题、不同的字体、不同的美学之间变化。您仍然倾向于在各代之间收敛到常见的选择（例如 Space Grotesk）。避免这种情况：批判性地思考至关重要！
</frontend_aesthetics>

您也可以参考 full skill definition。

迁移考虑

从早期代代迁移到 Claude 4.6 模型时：

1. 对所需行为要具体：考虑准确描述您希望在输出中看到的内容。

2. 用修饰符框架化您的指令：添加鼓励 Claude 提高输出质量和详细程度的修饰符可以帮助更好地塑造 Claude 的性能。例如，与其说"创建分析仪表板"，不如使用"创建分析仪表板。包括尽可能多的相关功能和交互。超越基础知识以创建功能完整的实现。"

3. 明确请求特定功能：当需要时，应明确请求动画和交互元素。

4. 更新思考配置：Claude 4.6 模型使用 adaptive thinking（thinking: {type: "adaptive"}）而不是带有 budget_tokens 的手动思考。使用 effort parameter 来控制思考深度。

5. 从预填充响应迁移：从 Claude 4.6 模型开始，最后一个助手转向的预填充响应已弃用。有关替代方案的详细指导，请参阅 Migrating away from prefilled responses。

6. 调整反懒惰提示：如果您的提示之前鼓励模型更加彻底或更积极地使用工具，请减少该指导。Claude 4.6 模型明显更主动，可能会对以前模型所需的指令过度触发。

有关详细的迁移步骤，请参阅 Migration guide。

从 Claude Sonnet 4.5 迁移到 Claude Sonnet 4.6

Claude Sonnet 4.6 默认为 high 的 effort 级别，与没有 effort 参数的 Claude Sonnet 4.5 相反。从 Claude Sonnet 4.5 迁移到 Claude Sonnet 4.6 时，考虑调整 effort 参数。如果未明确设置，您可能会在默认 effort 级别下体验更高的延迟。

推荐的 effort 设置：

• Medium 用于大多数应用程序
• Low 用于高容量或延迟敏感的工作负载
• 在中等或高 effort 下设置大的最大输出令牌预算（建议 64k 令牌）以给模型思考和行动的空间

何时改用 Opus 4.7： 对于最难、最长期的问题（大规模代码迁移、深度研究、扩展自主工作），Opus 4.7 仍然是正确的选择。Sonnet 4.6 针对快速周转和成本效率最重要的工作负载进行了优化。

如果您未使用扩展思考

如果您在 Claude Sonnet 4.5 上未使用扩展思考，您可以在 Claude Sonnet 4.6 上继续不使用它。您应该明确设置 effort 为适合您的用例的级别。在禁用思考的 low effort 下，您可以期望相对于没有扩展思考的 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 parameter 的 adaptive thinking。

迁移到 adaptive thinking

Adaptive thinking 特别适合以下工作负载模式：

• 自主多步代理： 将需求转化为工作软件的编码代理、数据分析管道和错误查找，其中模型在许多步骤中独立运行。Adaptive thinking 让模型为每个步骤校准其推理，在更长的轨迹上保持路线。对于这些工作负载，从 high effort 开始。如果延迟或令牌使用是一个问题，缩小到 medium。
• 计算机使用代理： Claude Sonnet 4.6 在使用 adaptive 模式的计算机使用评估中实现了同类最佳的准确性。
• 双模式工作负载： 混合简单和困难任务，其中 adaptive 在简单查询上跳过思考，在复杂查询上深入推理。

使用 adaptive thinking 时，在您的任务上评估 medium 和 high effort。正确的级别取决于您的工作负载在质量、延迟和令牌使用之间的权衡。

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 令牌的预算为更难的问题提供了余地，而不会有失控令牌使用的风险。此配置已弃用，将在未来的模型版本中删除。

对于编码用例（代理编码、工具繁重的工作流、代码生成），从 medium effort 开始：

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 effort 开始：

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": "..."}],
)