提示词最佳实践

本指南提供了适用于 Claude 最新模型的提示工程技巧，包括 Claude Opus 4.6、Claude Sonnet 4.5 和 Claude Haiku 4.5。与前几代 Claude 模型相比，这些模型经过训练，能够更精确地遵循指令。

通用原则

明确表达你的指令

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

添加上下文以提升性能

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

Claude 足够智能，能够从解释中进行泛化。

注意示例和细节

作为精确指令遵循能力的一部分，Claude 会密切关注细节和示例。确保你的示例与你想要鼓励的行为一致，并尽量减少你想要避免的行为。

长程推理和状态跟踪

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

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

Claude Opus 4.6 和 Claude 4.5 模型具有上下文感知功能，使模型能够在对话过程中跟踪其剩余的上下文窗口（即"token 预算"）。这使 Claude 能够通过了解可用空间来更有效地执行任务和管理上下文。

管理上下文限制：

如果你在一个能够压缩上下文或允许将上下文保存到外部文件的代理框架中使用 Claude（如在 Claude Code 中），我们建议将此信息添加到你的提示中，以便 Claude 能够相应地行动。否则，Claude 有时可能会在接近上下文限制时自然地尝试收尾工作。以下是一个示例提示：

你的上下文窗口将在接近限制时自动压缩，允许你从上次停止的地方无限期地继续工作。因此，不要因为 token 预算问题而提前停止任务。当你接近 token 预算限制时，在上下文窗口刷新之前将当前进度和状态保存到记忆中。始终尽可能保持持久性和自主性，完整地完成任务，即使预算即将耗尽。无论剩余上下文如何，都不要人为地提前停止任何任务。

记忆工具与上下文感知自然配合，实现无缝的上下文转换。

多上下文窗口工作流

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

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

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

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

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

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

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

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

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

状态管理最佳实践

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

沟通风格

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

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

这种沟通风格准确反映了已完成的工作，没有不必要的赘述。

特定场景的指导

平衡详细程度

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 Opus 4.6 可能会采取难以撤销或影响共享系统的操作，例如删除文件、强制推送或发布到外部服务。如果你希望 Claude Opus 4.6 在采取潜在风险操作之前进行确认，请在提示中添加指导：

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

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

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

过度思考和过度彻底

Claude Opus 4.6 比之前的模型进行了明显更多的前期探索，尤其是在较高的 effort 设置下。这种初始工作通常有助于优化最终结果，但模型可能会在没有提示的情况下收集大量上下文或追求多个研究线索。如果你之前的提示鼓励模型更加彻底，你应该为 Claude Opus 4.6 调整该指导：

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

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

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

控制响应格式

我们发现以下几种方式在引导输出格式方面特别有效：

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

   • 不要说："不要在你的回复中使用 markdown"
   • 尝试："你的回复应该由流畅的散文段落组成。"

2. 使用 XML 格式指示器

   • 尝试："将你回复的散文部分写在 <smoothly_flowing_prose_paragraphs> 标签中。"

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

   提示中使用的格式风格可能会影响 Claude 的回复风格。如果你仍然遇到输出格式的可控性问题，我们建议尽可能使你的提示风格与期望的输出风格匹配。例如，从提示中移除 markdown 可以减少输出中 markdown 的数量。

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

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

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

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

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

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

研究和信息收集

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

1. 提供明确的成功标准：定义什么构成你研究问题的成功答案

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

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

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

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

子代理编排

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

要利用这种行为：

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

如果你发现子代理使用过多，请添加关于何时应该和不应该使用子代理的明确指导：

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

模型自我认知

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

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

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

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

思考敏感性

当扩展思考被禁用时，Claude Opus 4.5 对"think"一词及其变体特别敏感。我们建议用传达类似含义的替代词替换"think"，例如"consider"、"believe"和"evaluate"。

利用思考和交错思考能力

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

Claude Opus 4.6 使用自适应思考（thinking: {type: "adaptive"}），Claude 动态决定何时以及思考多少。Claude 根据两个因素校准其思考：effort 参数和查询复杂度。更高的 effort 会引发更多思考，更复杂的查询也是如此。对于不需要思考的简单查询，模型直接响应。在内部评估中，自适应思考可靠地比扩展思考带来更好的性能，我们建议转向自适应思考以获得最智能的响应。较旧的模型使用带有 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 的最新模型在创建演示文稿、动画和视觉文档方面表现出色，具有令人印象深刻的创意天赋和强大的指令遵循能力。在大多数情况下，模型在第一次尝试时就能产生精美、可用的输出。

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

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

改进的视觉能力

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

我们发现一种有效的技术是给 Claude 一个裁剪工具或技能来进一步提升性能。当 Claude 能够"放大"图像的相关区域时，我们在图像评估中看到了一致的提升。我们在这里整理了一个裁剪工具的 cookbook。

优化并行工具调用

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

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

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

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

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

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

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

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

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

过度热心

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

例如：

避免过度工程化。只进行直接要求的或明显必要的更改。保持解决方案简单和专注：

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

- 文档：不要为你没有更改的代码添加文档字符串、注释或类型注解。只在逻辑不自明的地方添加注释。

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

- 抽象：不要为一次性操作创建辅助函数、工具或抽象。不要为假设的未来需求进行设计。正确的复杂度是当前任务所需的最小量。

前端设计

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 有时可能过于专注于使测试通过而忽略更通用的解决方案，或者可能使用辅助脚本等变通方法进行复杂重构，而不是直接使用标准工具。为防止这种行为并确保健壮的、可泛化的解决方案：

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

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

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

最小化代理编码中的幻觉

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

<investigate_before_answering>
绝不要对你没有打开的代码进行推测。如果用户引用了特定文件，你必须在回答之前读取该文件。确保在回答有关代码库的问题之前调查和读取相关文件。除非你确定正确答案，否则在调查之前绝不要对代码做出任何声明——给出有根据的、无幻觉的答案。
</investigate_before_answering>

从预填充响应迁移

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

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

LaTeX 输出

Claude Opus 4.6 默认使用 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 4.6 模型时：

1. 明确期望的行为：考虑准确描述您希望在输出中看到的内容。

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

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

4. 更新思考配置：Claude Opus 4.6 使用自适应思考（thinking: {type: "adaptive"}）而不是使用 budget_tokens 的手动思考。使用 effort 参数来控制思考深度。

5. 从预填充响应迁移：从 Claude Opus 4.6 开始，最后一个助手轮次上的预填充响应已被弃用。请参阅从预填充响应迁移获取替代方案的详细指导。

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

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