提示工程最佳实践

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

一般原则

清晰直接

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-6",
    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.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>
在编写报告、文档、技术解释、分析或任何长格式内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落换行符进行组织，并主要为 `inline code`、代码块 (```...```) 和简单标题 (###, and ###) 保留 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 参数和查询复杂性。更高的努力会引发更多思考，更复杂的查询也是如此。在不需要思考的更简单查询上，模型直接响应。在内部评估中，自适应思考可靠地驱动比扩展思考更好的性能。考虑迁移到自适应思考以获得最聪明的响应。

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

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

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

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

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

如果您从 extended thinking 与 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"},  # or max, 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 模型具有上下文感知功能，使模型能够在整个对话中跟踪其剩余的上下文窗口（即"令牌预算"）。这使 Claude 能够通过理解它有多少空间来更有效地执行任务和管理上下文。

管理上下文限制：

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

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

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

多上下文窗口工作流

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

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 调用更快且足够时，模型可能会为代码探索生成子代理。

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

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

链接复杂提示词

通过自适应思考和子代理编排，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 一个裁剪工具或技能。测试表明，当 Claude 能够"放大"图像的相关区域时，图像评估会获得一致的提升。Anthropic 创建了裁剪工具的 cookbook。

前端设计

Claude Opus 4.5 和 Claude Opus 4.6 擅长构建具有强大前端设计的复杂、真实世界的网络应用程序。但是，没有指导的情况下，模型可能会默认为通用模式，创建用户称之为"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 的手动思考。使用努力参数来控制思考深度。

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 用于高容量或延迟敏感的工作负载
• 在中等或高努力下设置大的最大输出令牌预算（推荐 64k 令牌）以给模型思考和行动的空间

何时改用 Opus 4.6： 对于最难、最长期的问题（大规模代码迁移、深度研究、扩展自主工作），Opus 4.6 仍然是正确的选择。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 努力开始。如果延迟或令牌使用是一个问题，缩小到 medium。
• 计算机使用代理： Claude Sonnet 4.6 在使用自适应模式的计算机使用评估中实现了同类最佳的准确性。
• 双模态工作负载： 简单和困难任务的混合，其中自适应在简单查询上跳过思考，在复杂查询上深入推理。

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

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 努力开始：

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