Claude 4.6 提示工程最佳实践指南

本文译自 Anthropic 官方文档 Prompting best practices，是 Claude 最新模型（包括 Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5）提示工程的权威参考。

这是 Claude 最新模型提示工程的唯一权威参考，涵盖 Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Haiku 4.5。内容包括基础技术、输出控制、工具使用、思考能力以及智能体系统。跳转到与你情况匹配的部分。

有关模型能力的概述，请参阅模型概述。有关 Claude 4.6 新特性的详细信息，请参阅 Claude 4.6 新特性。迁移指南请参阅迁移指南。

通用原则

清晰直接

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-6",
    max_tokens=1024,
    system="你是一位专注于 Python 的有帮助的编程助手。",
    messages=[
        {"role": "user", "content": "如何按键对字典列表进行排序？"}
    ],
)
print(message.content)

长上下文提示

在处理大型文档或数据丰富的输入（20K+ tokens）时，仔细构建提示以获得最佳结果：

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

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

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

  示例多文档结构

  <documents>
    <document index="1">
      <source>annual_report_2023.pdf</source>
      <document_content>
        {{ANNUAL_REPORT}}
      </document_content>
    </document>
    <document index="2">
      <source>competitor_analysis_q2.xlsx</source>
      <document_content>
        {{COMPETITOR_ANALYSIS}}
      </document_content>
    </document>
  </documents>
  
  分析年度报告和竞争对手分析。确定战略优势并推荐 Q3 重点领域。

• 在引用中扎根响应：对于长文档任务，要求 Claude 在执行任务之前先引用文档的相关部分。这有助于 Claude 过滤掉文档其余内容的噪音。

  示例引用提取

  你是一位 AI 医生助手。你的任务是帮助医生诊断可能的患者疾病。
  
  <documents>
    <document index="1">
      <source>patient_symptoms.txt</source>
      <document_content>
        {{PATIENT_SYMPTOMS}}
      </document_content>
    </document>
    <document index="2">
      <source>patient_records.txt</source>
      <document_content>
        {{PATIENT_RECORDS}}
      </document_content>
    </document>
    <document index="3">
      <source>patient01_appt_history.txt</source>
      <document_content>
        {{PATIENT01_APPOINTMENT_HISTORY}}
      </document_content>
    </document>
  </documents>
  
  从患者记录和预约历史中找到与诊断患者报告症状相关的引用。将这些放在 <quotes> 标签中。然后，基于这些引用，列出所有有助于医生诊断患者症状的信息。将你的诊断信息放在 <info> 标签中。

模型自我认知

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

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

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

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

输出和格式化

沟通风格和详细程度

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

• 更直接和有根有据： 提供基于事实的进度报告，而不是自我庆祝式的更新
• 更对话化： 稍微更流畅和口语化，少了一些机器感
• 更简洁： 为了效率，可能会跳过详细摘要，除非另有提示

这意味着 Claude 可能会在工具调用后跳过口头摘要，直接跳到下一个操作。如果你希望更清楚地看到它的推理过程：

在完成涉及工具使用的任务后，请简要总结你所做的工作。

控制响应格式

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

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

   • 而不是：“不要在你的响应中使用 markdown”
   • 尝试：“你的响应应由流畅的散文段落组成。”

2. 使用 XML 格式指示器

   • 尝试：“将你响应的散文部分写在 <smoothly_flowing_prose_paragraphs> 标签中。”

3. 让你的提示风格与期望的输出匹配

   你提示中使用的格式化风格可能会影响 Claude 的响应风格。如果你在控制输出格式化方面仍然遇到问题，尝试尽可能让你的提示风格与你期望的输出风格相匹配。例如，从你的提示中移除 markdown 可以减少输出中的 markdown 数量。

4. 使用详细提示来指定特定的格式偏好

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

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

除非：a) 你呈现的是真正离散的项目，列表格式是最佳选择，或者 b) 用户明确要求列表或排名，否则不要使用有序列表（1. ...）或无序列表（*）。

与其用项目符号或数字列出项目，不如将它们自然地融入句子中。本指南尤其适用于技术写作。使用散文而不是过多的格式化将提高用户满意度。永远不要输出一系列过短的项目符号点。

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

LaTeX 输出

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

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

文档创建

Claude 的最新模型擅长创建演示文稿、动画和可视化文档，具有令人印象深刻的创意天赋和强大的指令遵循能力。在大多数情况下，模型可以在第一次尝试时生成精美、可用的输出。

要在文档创建方面获得最佳结果：

创建一个关于 [主题] 的专业演示文稿。包含深思熟虑的设计元素、视觉层次结构，并在适当的地方包含引人入胜的动画。

从预填充响应迁移

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

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

控制输出格式化

预填充曾被用来强制特定的输出格式，如 JSON/YAML、分类以及预填充将 Claude 约束到特定结构的类似模式。

迁移： 结构化输出 功能专门设计用于约束 Claude 的响应遵循给定的模式。尝试先简单地要求模型符合你的输出结构，因为较新的模型在被告知时可以可靠地匹配复杂模式，特别是在使用重试实现时。对于分类任务，使用带有包含有效标签的枚举字段的工具或结构化输出。

消除开场白

诸如 以下是请求的摘要：\n 之类的预填充曾被用来跳过介绍性文本。

迁移： 在系统提示中使用直接指令：“直接响应，不要开场白。不要以’以下是…’、‘基于…’等开头。” 或者，指示模型在 XML 标签内输出，使用结构化输出，或使用工具调用。如果偶尔有开场白漏过，在后处理中剥离它。

避免糟糕的拒绝

预填充曾被用来引导绕过不必要的拒绝。

迁移： Claude 现在在适当拒绝方面做得更好。在没有预填充的情况下，在 user 消息中进行清晰提示应该就足够了。

续接

预填充曾被用来继续部分完成、恢复中断的响应，或从之前的生成中断的地方继续。

迁移： 将续接移动到用户消息，并包含来自中断响应的最终文本：“你之前的响应被打断了，结尾是 `[previous_response]`。从你中断的地方继续。” 如果这是错误处理或不完整响应处理的一部分，并且没有 UX 惩罚，则重试该请求。

上下文补充和角色一致性

预填充曾被用来定期确保刷新或注入的上下文。

迁移： 对于非常长的对话，将以前作为预填充助手提醒的内容注入到用户轮次中。如果上下文补充是更复杂的智能体系统的一部分，考虑通过工具进行补充（根据轮次数量等启发式方法暴露或鼓励使用包含上下文的工具）或在上下文压缩期间进行。

工具使用

工具使用模式

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

要让 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 调整该指导：

• 用更有针对性的指令替换 blanket 默认值。 不要”默认使用 [工具]“，而是添加诸如”当 [工具] 会增强你对问题的理解时使用它”之类的指导。
• 移除过度提示。 在以前模型中触发不足的工具现在可能会适当触发。诸如”如果有疑问，使用 [工具]“之类的指令会导致过度触发。
• 使用 effort 作为后备。 如果 Claude 仍然过于激进，使用较低的 effort 设置。

在某些情况下，Claude Opus 4.6 可能会进行大量思考，这可能会膨胀思考 tokens 并减慢响应速度。如果这种行为不可取，你可以添加明确的指令来约束其推理，或者你可以降低 effort 设置以减少整体思考和 token 使用。

当你决定如何处理问题时，选择一种方法并致力于它。避免重新审视决定，除非你遇到直接与你推理相矛盾的新信息。如果你在权衡两种方法，选择一种并坚持下去。如果所选方法失败，你总是可以稍后调整路线。

对于 Claude Sonnet 4.6 特别而言，从自适应思考切换到带有 budget_tokens 上限的扩展思考，提供了思考成本的硬上限，同时保持了质量。

利用思考和交错思考能力

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

Claude Opus 4.6 使用自适应思考（thinking: {type: "adaptive"}），其中 Claude 动态决定何时思考以及思考多少。Claude Sonnet 4.6 支持自适应思考和带有交错模式的手动扩展思考。Claude 基于两个因素校准其思考：effort 参数和查询复杂度。更高的 effort 会引出更多思考，更复杂的查询也是如此。在不需要思考的更简单查询上，模型直接响应。在内部评估中，自适应思考可靠地推动了比扩展思考更好的性能。考虑转向自适应思考以获得最智能的响应。

对于 Sonnet 4.6，考虑尝试自适应思考用于需要智能体行为的工作负载，例如多步工具使用、复杂编码任务和长期智能体循环。如果自适应思考不适合你的用例，带有交错模式的手动扩展思考仍然受支持。较旧的模型使用带有 budget_tokens 的手动思考模式。

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

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

自适应思考的触发行为是可提示的。如果你发现模型思考的频率比你想要的更高（这可能发生在大型或复杂的系统提示中），添加指导来引导它：

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

如果你正在从带有 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-6",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # 或 max, medium, low
    messages=[{"role": "user", "content": "..."}],
)

如果你没有使用扩展思考，则不需要进行任何更改。当你省略 thinking 参数时，思考默认是关闭的。

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

当扩展思考禁用时，Claude Opus 4.5 对”思考”一词及其变体特别敏感。在这些情况下考虑使用替代词，如”考虑”、“评估”或”推理”。

有关思考能力的更多信息，请参阅扩展思考和自适应思考。

智能体系统

长期推理和状态跟踪

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

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

Claude 4.6 和 Claude 4.5 模型具有上下文感知，使模型能够在整个对话中跟踪其剩余的上下文窗口（即 “token 预算”）。这使 Claude 能够通过理解它有多少工作空间来更有效地执行任务和管理上下文。

管理上下文限制：

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

当接近其限制时，你的上下文窗口将被自动压缩，允许你从中断的地方无限期地继续工作。因此，不要因为 token 预算担忧而提前停止任务。当你接近 token 预算限制时，在上下文窗口刷新之前将当前进度和状态保存到内存中。请始终尽可能持久和自主，并完全完成任务，即使预算的终点正在接近。永远不要人为地提前停止任何任务，无论剩余多少上下文。

内存工具与上下文感知自然配对，实现无缝的上下文转换。

多上下文窗口工作流

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

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

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

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

4. 从头开始 vs 压缩：当上下文窗口被清除时，考虑以全新的上下文窗口开始，而不是使用压缩。Claude 的最新模型非常擅长从本地文件系统发现状态。在某些情况下，你可能希望利用这一点而不是压缩。明确规定它应该如何开始：

   • “调用 pwd；你只能在这个目录中读写文件。”
   • “查阅 progress.txt、tests.json 和 git 日志。”
   • “在继续实现新功能之前，手动运行一个基本的集成测试。”

5. 提供验证工具：随着自主任务长度的增长，Claude 需要能够在没有持续人工反馈的情况下验证正确性。诸如 Playwright MCP 服务器或用于测试 UI 的计算机使用能力之类的工具会很有帮助。

6. 鼓励充分利用上下文：提示 Claude 在继续之前高效地完成组件：

这是一项非常长的任务，因此清楚地规划你的工作可能会有所帮助。鼓励你花费整个输出上下文来处理任务——只要确保不要在有大量未提交工作的情况下耗尽上下文。继续系统地工作，直到完成这项任务。

状态管理最佳实践

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

示例：状态跟踪

// 结构化状态文件 (tests.json)
{
  "tests": [
    { "id": 1, "name": "authentication_flow", "status": "passing" },
    { "id": 2, "name": "user_management", "status": "failing" },
    { "id": 3, "name": "api_endpoints", "status": "not_started" }
  ],
  "total": 200,
  "passing": 150,
  "failing": 25,
  "not_started": 25
}

// 进度笔记 (progress.txt)
会话 3 进度：
- 修复了身份验证令牌验证
- 更新了用户模型以处理边缘情况
- 下一步：调查 user_management 测试失败（测试 #2）
- 注意：不要删除测试，因为这可能导致功能缺失

平衡自主性和安全性

在没有指导的情况下，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 调用更快且足够。

如果你看到过度的子智能体使用，添加关于子智能体何时有保证何时没有保证的明确指导：

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

链接复杂提示

通过自适应思考和子智能体编排，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 模型相比，Claude Opus 4.5 和 Claude Opus 4.6 具有改进的视觉能力。它们在图像处理和数据提取任务上表现更好，特别是当上下文中存在多个图像时。这些改进延续到计算机使用，模型可以更可靠地解释截图和 UI 元素。你也可以使用这些模型通过将视频分解为帧来分析视频。

一种已被证明可以进一步提升性能的技术是给 Claude 一个裁剪工具或技能。测试表明，当 Claude 能够”放大”图像的相关区域时，图像评估会持续提升。Anthropic 创建了一个裁剪工具食谱。

前端设计

Claude Opus 4.5 和 Claude Opus 4.6 擅长构建具有强大前端设计的复杂、真实的 Web 应用程序。然而，在没有指导的情况下，模型可能会默认使用通用模式，创建用户称之为”AI 垃圾”的美学。要创建独特、创意的前端来惊喜和取悦：

有关改进前端设计的详细指南，请参阅关于通过技能改进前端设计的博客文章。

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

<frontend_aesthetics>
你倾向于收敛到通用的、"在分布上"的输出。在前端设计中，这创造了用户称之为"AI 垃圾"的美学。避免这种情况：制作创意、独特的前端来惊喜和取悦。

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

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

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

你也可以参考完整技能定义。

迁移注意事项

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

1. 具体说明期望的行为：考虑准确描述你希望在输出中看到什么。

2. 用修饰语构建你的指令：添加鼓励 Claude 提升输出质量和细节的修饰语可以帮助更好地塑造 Claude 的性能。例如，不要”创建一个分析仪表板”，而是使用”创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础，创建一个功能完备的实现。”

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 effort 下设置较大的最大输出 token 预算（推荐 64k tokens），以给模型思考和行动的空间

何时改用 Opus 4.6： 对于最困难、长期的问题（大规模代码迁移、深度研究、扩展自主工作），Opus 4.6 仍然是正确的选择。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 上使用扩展思考，它在 Claude Sonnet 4.6 上继续受支持，无需对你的思考配置进行任何更改。考虑保持约 16k tokens 的思考预算。实际上，大多数任务不会使用那么多，但它为更困难的问题提供了空间，而不会出现失控 token 使用的风险。

对于编码用例（智能体编码、工具密集型工作流、代码生成）：

从 medium effort 开始。如果你发现延迟太高，考虑将 effort 降低到 low。如果你需要更高的智能，考虑将 effort 增加到 high 或迁移到 Opus 4.6。

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 与扩展思考开始。如果你需要更多深度，将 effort 增加到 medium。

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

何时尝试自适应思考

上面的扩展思考路径使用 budget_tokens 来实现可预测的 token 使用。如果你的工作负载符合以下模式之一，考虑尝试自适应思考：

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

使用自适应思考时，在你的任务上评估 medium 和 high effort。正确的级别取决于你的工作负载在质量、延迟和 token 使用之间的权衡。

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