提示词工程最佳实践

针对 Claude 最新模型的提示词工程技术综合指南，涵盖清晰度、示例、XML 结构化、思考和智能体系统。

本文是使用 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 会根据其判断的任务复杂度来校准响应长度，而不是默认使用固定的详细程度。这通常意味着简单查询的响应更短，而开放式分析的响应更长。

如果您的产品依赖于特定的输出风格或详细程度，您可能需要调优提示词。例如，要降低详细程度，您可以添加：

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

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

校准努力程度和思考深度

努力参数允许您调优 Claude 的智能与 token 消耗之间的平衡，以能力换取更快的速度和更低的成本。对于编码和智能体用例，从新的 xhigh 努力级别开始，对于大多数对智能敏感的用例，至少使用 high 努力级别。尝试其他努力级别以进一步调优 token 使用和智能：

• max： 最大努力在某些用例中可以带来性能提升，但可能会因 token 使用增加而出现边际收益递减。此设置有时也可能导致过度思考。我们建议对需要高智能的任务测试最大努力。
• xhigh（新增）： 超高努力是大多数编码和智能体用例的最佳设置。
• high： 此设置平衡了 token 使用和智能。对于大多数对智能敏感的用例，我们建议至少使用 high 努力。
• medium： 适用于需要降低 token 使用同时牺牲智能的成本敏感用例。
• low： 保留用于短期、范围明确的任务和对延迟敏感但对智能不敏感的工作负载。

与 Claude Opus 4.6 有显著不同的是，Claude Opus 4.7 严格遵守努力级别，特别是在低端。在 low 和 medium 下，模型会将其工作范围限制在被要求的范围内，而不是超额完成。这对延迟和成本有利，但在中等复杂任务上以 low 努力运行时，存在思考不足的风险。

如果您观察到复杂问题上的浅层推理，请将努力提高到 high 或 xhigh，而不是通过提示词来绕过。如果您因延迟原因需要保持 low 努力，请添加有针对性的指导：

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

我们预计努力参数对这个模型比对任何之前的 Opus 都更重要，建议在升级时积极进行实验。

自适应思考的触发行为是可控的。如果您发现模型思考的频率超出预期——这在大型或复杂的系统提示中可能会发生——请添加指导来引导它。与往常一样，衡量任何提示词变更对性能的影响。示例：

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 下运行高难度工作负载并发现思考不足，首要手段是提高努力。如果需要更精细的控制，可以直接通过提示词来实现。

工具使用触发

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 更温暖的风格更少使用验证性措辞和表情符号。如果您的产品依赖于特定的声音，请根据新基线重新评估风格提示词。

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

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

控制子代理生成

Claude Opus 4.7 默认倾向于生成更少的子代理。然而，这种行为可以通过提示词来引导；给 Claude Opus 4.7 关于何时需要子代理的明确指导。以下是编码用例的简单示例：

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.7 比 Claude Opus 4.6 有更强的设计直觉，具有一致的默认房屋风格：温暖的米色/灰白色背景（~#F4F1EA）、衬线展示字体（Georgia、Fraunces、Playfair）、斜体词强调和赤陶/琥珀色点缀。这对编辑、酒店和作品集简介阅读效果良好，但对仪表板、开发工具、金融科技、医疗保健或企业应用程序会显得不合适——它在幻灯片和 Web 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.7 与之前的模型相比，需要更少的前端设计提示词来避免用户称之为"AI 涂鸦"美学的通用模式。对于早期模型，我们在前端设计技能中推荐了更长的提示片段。然而，Claude Opus 4.7 使用更简洁的提示指导就能生成独特、有创意的前端。此提示片段与上述多样性提示建议配合使用效果良好：

<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.7 的 token 使用和行为在具有单个用户轮次的自主、异步编码代理与具有多个用户轮次的交互式、同步编码代理之间可能有所不同。具体来说，它倾向于在交互式设置中使用更多 token，主要是因为它在用户轮次后进行更多推理。这可以改善长期连贯性、指令遵循和长交互式编码会话中的编码能力，但也会带来更多的 token 使用。为了在编码产品中同时最大化性能和 token 效率，我们建议使用 xhigh 或 high 努力，添加自动模式等自主功能，并减少用户所需的人机交互次数。

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

代码审查工具

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

一些推荐的提示词语言：

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.

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

如果您确实希望模型在单次传递中自我过滤，请具体说明标准在哪里，而不是使用"重要"等定性术语——例如，"报告任何可能导致不正确行为、测试失败或误导结果的错误；只省略纯样式或命名偏好等细枝末节"。

我们建议针对评估或测试用例的子集迭代提示词，以验证召回率或 F1 分数的提升。

计算机使用

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

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

通用原则

清晰直接

Claude 对清晰、明确的指令反应良好。明确说明您的期望输出可以帮助提升结果。如果您想要"超出预期"的行为，请明确请求，而不是依赖模型从模糊的提示词中推断。

将 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.

添加上下文以提高性能

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

示例：格式偏好

效果较差：

NEVER use ellipses

效果更好：

Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.

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+ token）时，请仔细构建提示词以获得最佳结果：

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

  ℹ️

  Note

  在测试中，将查询放在末尾可以将响应质量提高多达 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>

Analyze the annual report and competitor analysis. Identify strategic advantages and recommend Q3 focus areas.

• 基于引用进行响应： 对于长文档任务，要求 Claude 在执行任务之前先引用文档的相关部分。这有助于 Claude 穿透文档其余内容的噪音。

示例引用提取

You are an AI physician's assistant. Your task is to help doctors diagnose possible patient illnesses.

<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>

Find quotes from the patient records and appointment history that are relevant to diagnosing the patient's reported symptoms. Place these in <quotes> tags. Then, based on these quotes, list all information that would help the doctor diagnose the patient's symptoms. Place your diagnostic information in <info> tags.

模型自我认知

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

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

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

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

输出和格式化

沟通风格和详细程度

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

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

这意味着 Claude 可能在工具调用后跳过口头总结，直接跳到下一个操作。如果您希望更多地了解其推理过程：

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

控制响应格式

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

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

   • 不要这样说："不要在响应中使用 markdown"
   • 试试这样说："您的响应应该由流畅的散文段落组成。"

2. 使用 XML 格式指示器

   • 试试这样说："将您响应的散文部分写在 <smoothly_flowing_prose_paragraphs> 标签中。"

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 错误。模型智能和指令遵循能力已经进步，使得大多数预填充用例不再需要它。早期模型继续支持预填充，并且在对话的其他地方添加助手消息不受影响。

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

控制输出格式

预填充已被用于强制特定输出格式，如 JSON/YAML、分类和类似模式，其中预填充将 Claude 约束到特定结构。

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

消除开场白

像 Here is the requested summary:\n 这样的预填充被用来跳过介绍性文本。

迁移： 在系统提示中使用直接指令："直接响应，不要开场白。不要以'Here is...'、'Based on...'等短语开头。"或者，指示模型在 XML 标签内输出，使用结构化输出，或使用工具调用。如果有偶尔的开场白漏出，请在后处理中去除。

避免不当拒绝

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

迁移： Claude 现在在适当拒绝方面做得好多了。在 user 消息中使用清晰的提示词，不使用预填充应该就足够了。

续写

预填充被用来继续部分完成、恢复中断的响应或从上一次生成中断的地方继续。

迁移： 将续写移至用户消息，并包含中断响应的最终文本："Your previous response was interrupted and ended with `[previous_response]`. Continue from where you left off."如果这是错误处理或不完整响应处理的一部分，并且没有用户体验惩罚，请重试请求。

上下文注入和角色一致性

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

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

工具使用

工具使用方式

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

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

示例：明确指令

效果较差（Claude 只会建议）：

Can you suggest some changes to improve this function?

效果更好（Claude 会进行更改）：

Change this function to improve its performance.

或者：

Make these edits to the authentication flow.

要让 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 也比之前的模型对系统提示更敏感。如果您的提示词旨在减少工具或技能的触发不足，这些模型现在可能会过度触发。解决方法是减少任何过于激进的语言。当您之前可能会说"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 调优该指导：

• 用更有针对性的指令替换一揽子默认值。 不要说"默认使用 [工具]"，而是添加指导，如"当 [工具] 能增强您对问题的理解时使用它。"
• 删除过度提示。 在之前模型中触发不足的工具现在可能会适当触发。"如有疑问，使用 [工具]"这样的指令会导致过度触发。
• 将努力作为后备。 如果 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 上仍然可用但已被弃用。优先降低 努力设置或使用 max_tokens 作为自适应思考的硬性限制。

利用思考和交错思考能力

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

Claude Opus 4.6 和 Claude Sonnet 4.6 使用自适应思考（thinking: {type: "adaptive"}），Claude 动态决定何时以及思考多少。Claude 根据两个因素校准其思考：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-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 自我检查。 附加类似"在完成之前，根据 [测试标准] 验证您的答案"的内容。这可以可靠地捕获错误，特别是对于编码和数学。

智能体系统

长期推理和状态跟踪

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 测试的重要性："删除或编辑测试是不可接受的，因为这可能导致功能缺失或错误。"

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

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

   • "Call pwd; you can only read and write files in this directory."
   • "Review progress.txt, tests.json, and the git logs."
   • "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 理解模式要求
• 对进度笔记使用非结构化文本： 自由格式的进度笔记适合跟踪一般进度和上下文
• 使用 git 进行状态跟踪： git 提供了已完成工作的日志和可恢复的检查点。Claude 的最新模型在使用 git 跨多个会话跟踪状态方面表现特别出色
• 强调增量进展： 明确要求 Claude 跟踪其进度并专注于增量工作

示例：状态跟踪

// Structured state file (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 notes (progress.txt)
Session 3 progress:
- Fixed authentication token validation
- Updated user model to handle edge cases
- Next: investigate user_management test failures (test #2)
- Note: Do not remove tests as this could lead to missing functionality

平衡自主性和安全性

在没有指导的情况下，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 Opus 4.5 和 Claude Opus 4.6 与之前的 Claude 模型相比，视觉能力有所改进。它们在图像处理和数据提取任务上表现更好，特别是当上下文中存在多个图像时。这些改进延续到计算机使用，模型可以更可靠地解释屏幕截图和 UI 元素。您还可以使用这些模型通过将视频分解为帧来分析视频。

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

前端设计

Claude Opus 4.5 和 Claude Opus 4.6 擅长构建具有强大前端设计的复杂、真实世界的 Web 应用程序。然而，在没有指导的情况下，模型可能默认使用通用模式，创造出用户称之为"AI 涂鸦"美学的内容。要创建令人惊喜和愉悦的独特、有创意的前端：

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

<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>

您还可以参考完整技能定义。

迁移注意事项

从早期版本迁移到 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 的手动思考。使用努力参数来控制思考深度。

5. 迁移离开预填充响应： 从 Claude 4.6 模型开始，不再支持在最后一个助手轮次上使用预填充响应。有关替代方案的详细指导，请参阅迁移离开预填充响应。

6. 调优反懒惰提示词： 如果您的提示词之前鼓励模型更彻底或更激进地使用工具，请减少该指导。Claude 4.6 模型明显更主动，可能会在之前模型需要的指令上过度触发。

有关详细的迁移步骤，请参阅迁移指南。

从 Claude Sonnet 4.5 迁移到 Claude Sonnet 4.6

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

推荐的努力设置：

• Medium 适用于大多数应用程序
• Low 适用于高容量或延迟敏感的工作负载
• 在中等或高努力下设置较大的最大输出 token 预算（推荐 64k token）以给模型思考和操作的空间

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

如果您没有使用扩展思考

如果您在 Claude Sonnet 4.5 上没有使用扩展思考，可以在 Claude Sonnet 4.6 上继续不使用它。您应该明确地将努力设置为适合您用例的级别。在禁用思考的 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 上仍然可用但已被弃用。请迁移到带有努力参数的自适应思考。

迁移到自适应思考

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

• 自主多步骤代理： 将需求转化为可工作软件的编码代理、数据分析管道和错误查找，模型在许多步骤中独立运行。自适应思考让模型可以按步骤校准其推理，在较长的轨迹上保持正轨。对于这些工作负载，从 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": "..."}],
)