本指南提供了针对 Claude 4 模型（Sonnet 4.5、Sonnet 4、Haiku 4.5、Opus 4.1 和 Opus 4）的具体提示工程技术，帮助您在应用程序中获得最佳结果。这些模型经过训练，在指令遵循方面比之前几代 Claude 模型更加精确。
有关 Claude 4.5 新功能的概述，请参阅 Claude 4.5 的新功能。有关从之前模型迁移的指导，请参阅 迁移到 Claude 4。

​
一般原则

​
明确您的指令

Claude 4 模型对清晰、明确的指令响应良好。对您期望的输出具体说明可以帮助提升结果。希望获得之前 Claude 模型”超越期望”行为的客户可能需要在 Claude 4 中更明确地请求这些行为。
效果较差：
创建一个分析仪表板
效果更好：
创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能齐全的实现。

​
添加上下文以提高性能

提供指令背后的上下文或动机，例如向 Claude 解释为什么这种行为很重要，可以帮助 Claude 4 模型更好地理解您的目标并提供更有针对性的响应。
效果较差：
永远不要使用省略号
效果更好：
您的回复将由文本转语音引擎朗读，所以永远不要使用省略号，因为文本转语音引擎不知道如何发音。
Claude 足够聪明，能够从解释中进行概括。

​
对示例和细节保持警惕

Claude 4 模型作为其精确指令遵循能力的一部分，会密切关注细节和示例。确保您的示例与您想要鼓励的行为一致，并最小化您想要避免的行为。

​
长期推理和状态跟踪

Claude Sonnet 4.5 在长期推理任务方面表现出色，具有卓越的状态跟踪能力。它通过专注于渐进式进展——一次在少数几件事上取得稳定进展，而不是试图同时处理所有事情——来在扩展会话中保持方向。这种能力特别在多个上下文窗口或任务迭代中显现，Claude 可以处理复杂任务，保存状态，并在新的上下文窗口中继续。

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

Claude Sonnet 4.5 具有上下文感知功能，使模型能够在整个对话过程中跟踪其剩余的上下文窗口（即”令牌预算”）。这使 Claude 能够通过了解它有多少工作空间来更有效地执行任务和管理上下文。 管理上下文限制： 如果您在代理框架中使用 Claude，该框架会压缩上下文或允许将上下文保存到外部文件（如在 Claude Code 中），我们建议将此信息添加到您的提示中，以便 Claude 能够相应地行为。否则，Claude 有时可能会在接近上下文限制时自然地尝试结束工作。以下是一个示例提示：
示例提示
您的上下文窗口将在接近其限制时自动压缩，允许您从中断的地方无限期地继续工作。因此，不要因为令牌预算担忧而提前停止任务。当您接近令牌预算限制时，在上下文窗口刷新之前将您的当前进度和状态保存到内存中。始终尽可能持久和自主，完全完成任务，即使预算结束即将到来。无论剩余上下文如何，永远不要人为地提前停止任何任务。
内存工具与上下文感知自然配对，实现无缝的上下文转换。

​
多上下文窗口工作流

对于跨越多个上下文窗口的任务：
  1. 为第一个上下文窗口使用不同的提示：使用第一个上下文窗口建立框架（编写测试，创建设置脚本），然后使用未来的上下文窗口在待办事项列表上迭代。
  2. 让模型以结构化格式编写测试：要求 Claude 在开始工作之前创建测试，并以结构化格式（例如 tests.json）跟踪它们。这导致更好的长期迭代能力。提醒 Claude 测试的重要性：“删除或编辑测试是不可接受的，因为这可能导致功能缺失或错误。”
  3. 设置生活质量工具：鼓励 Claude 创建设置脚本（例如 init.sh）来优雅地启动服务器、运行测试套件和代码检查器。这防止了在从新的上下文窗口继续时重复工作。
  4. 重新开始与压缩：当上下文窗口被清除时，考虑使用全新的上下文窗口开始，而不是使用压缩。Sonnet 4.5 在从本地文件系统发现状态方面极其有效。在某些情况下，您可能希望利用这一点而不是压缩。对它应该如何开始要有规定性：
    • “调用 pwd；您只能在此目录中读取和写入文件。”
    • “查看 progress.txt、tests.json 和 git 日志。”
    • “在继续实现新功能之前，手动运行基本集成测试。”
  5. 提供验证工具：随着自主任务长度的增长，Claude 需要在没有持续人工反馈的情况下验证正确性。像 Playwright MCP 服务器或用于测试 UI 的计算机使用功能等工具很有帮助。
  6. 鼓励完全使用上下文：提示 Claude 在继续之前有效地完成组件：
示例提示
这是一个非常长的任务，所以清楚地规划您的工作可能是有益的。鼓励您花费整个输出上下文来处理任务 - 只要确保您不会在有重要未提交工作的情况下耗尽上下文。系统地继续工作，直到您完成此任务。

​
状态管理最佳实践

  • 对状态数据使用结构化格式：在跟踪结构化信息（如测试结果或任务状态）时，使用 JSON 或其他结构化格式来帮助 Claude 理解模式要求
  • 对进度笔记使用非结构化文本：自由形式的进度笔记适用于跟踪一般进度和上下文
  • 使用 git 进行状态跟踪：Git 提供了已完成工作的日志和可以恢复的检查点。Claude Sonnet 4.5 在使用 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 Sonnet 4.5 与之前的模型相比具有更简洁和自然的沟通风格：
  • 更直接和基于事实：提供基于事实的进度报告，而不是自我庆祝的更新
  • 更对话化：稍微更流畅和口语化，不那么机械化
  • 不那么冗长：为了效率可能跳过详细摘要，除非另有提示
这种沟通风格准确反映了已完成的工作，没有不必要的详细说明。

​
特定情况指导

​
平衡冗长度

Claude Sonnet 4.5 倾向于效率，可能在工具调用后跳过口头摘要，直接跳到下一个动作。虽然这创造了流线型工作流，但您可能更喜欢对其推理过程有更多的可见性。 如果您希望 Claude 在工作时提供更新：
示例提示
在完成涉及工具使用的任务后，提供您已完成工作的快速摘要。

​
工具使用模式

Claude Sonnet 4.5 经过训练以进行精确的指令遵循，并受益于明确指导使用特定工具。如果您说”您能建议一些更改吗”，它有时会提供建议而不是实施它们——即使进行更改可能是您的意图。 要让 Claude 采取行动，要更明确：
效果较差（Claude 只会建议）：
您能建议一些更改来改进这个函数吗？
效果更好（Claude 会进行更改）：
更改此函数以提高其性能。
或者：
对身份验证流程进行这些编辑。
要让 Claude 默认更主动地采取行动，您可以将此添加到您的系统提示中：
主动行动的示例提示
<default_to_action>
默认情况下，实施更改而不是仅仅建议它们。如果用户的意图不清楚，推断最有用的可能行动并继续，使用工具发现任何缺失的细节而不是猜测。尝试推断用户关于是否打算进行工具调用（例如，文件编辑或读取）的意图，并相应地行动。
</default_to_action>
另一方面，如果您希望模型默认更谨慎，不太容易直接跳入实现，并且只有在被要求时才采取行动，您可以使用如下提示来引导这种行为：
保守行动的示例提示
<do_not_act_before_instructions>
除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图模糊时，默认提供信息、进行研究和提供建议，而不是采取行动。只有当用户明确请求时，才继续进行编辑、修改或实现。
</do_not_act_before_instructions>

​
控制响应格式

我们发现在 Claude 4 模型中引导输出格式特别有效的几种方法：
  1. 告诉 Claude 要做什么，而不是不要做什么
    • 不要说：“不要在您的回复中使用 markdown”
    • 尝试：“您的回复应该由流畅的散文段落组成。”
  2. 使用 XML 格式指示器
    • 尝试：“在 <smoothly_flowing_prose_paragraphs> 标签中编写您回复的散文部分。”
  3. 将您的提示风格与期望的输出匹配 您提示中使用的格式风格可能会影响 Claude 的回复风格。如果您在输出格式的可控性方面仍然遇到问题，我们建议尽可能将您的提示风格与您期望的输出风格匹配。例如，从您的提示中删除 markdown 可以减少输出中 markdown 的数量。
  4. 对特定格式偏好使用详细提示 为了更好地控制 markdown 和格式使用，提供明确的指导：
最小化 markdown 的示例提示
<avoid_excessive_markdown_and_bullet_points>
在编写报告、文档、技术解释、分析或任何长篇内容时，使用完整的段落和句子编写清晰、流畅的散文。使用标准段落分隔进行组织，主要将 markdown 保留用于 `内联代码`、代码块（```...```）和简单标题（### 和 ###）。避免使用 **粗体** 和 *斜体*。

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

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

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

​
研究和信息收集

Claude Sonnet 4.5 展示了卓越的代理搜索能力，可以有效地从多个来源查找和综合信息。为了获得最佳研究结果：
  1. 提供明确的成功标准：定义什么构成对您研究问题的成功答案
  2. 鼓励来源验证：要求 Claude 跨多个来源验证信息
  3. 对于复杂的研究任务，使用结构化方法：
复杂研究的示例提示
以结构化方式搜索此信息。在收集数据时，制定几个竞争假设。在您的进度笔记中跟踪您的信心水平以改进校准。定期自我批评您的方法和计划。更新假设树或研究笔记文件以持久化信息并提供透明度。系统地分解这个复杂的研究任务。
这种结构化方法允许 Claude 查找和综合几乎任何信息片段，并迭代地批评其发现，无论语料库的大小如何。

​
子代理编排

Claude Sonnet 4.5 展示了显著改进的原生子代理编排能力。该模型可以识别何时任务将受益于将工作委托给专门的子代理，并主动这样做，无需明确指令。 要利用这种行为：
  1. 确保定义良好的子代理工具：在工具定义中提供并描述子代理工具
  2. 让 Claude 自然编排：Claude 将在没有明确指令的情况下适当委托
  3. 如果需要，调整保守性：
保守子代理使用的示例提示
只有当任务明显受益于具有新上下文窗口的单独代理时，才委托给子代理。

​
模型自我认知

如果您希望 Claude 在您的应用程序中正确识别自己或使用特定的 API 字符串：
模型身份的示例提示
助手是 Claude，由 Anthropic 创建。当前模型是 Claude Sonnet 4.5。
对于需要指定模型字符串的 LLM 驱动应用程序：
模型字符串的示例提示
当需要 LLM 时，除非用户另有要求，否则请默认使用 Claude Sonnet 4.5。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。

​
利用思考和交错思考能力

Claude 4 提供思考能力，这对涉及工具使用后反思或复杂多步推理的任务特别有帮助。您可以指导其初始或交错思考以获得更好的结果。
示例提示
在收到工具结果后，仔细反思其质量并确定最佳下一步，然后再继续。使用您的思考基于这些新信息进行规划和迭代，然后采取最佳下一步行动。
有关思考能力的更多信息，请参阅 扩展思考。

​
文档创建

Claude Sonnet 4.5 在创建演示文稿、动画和视觉文档方面表现出色。它在这个领域匹配或超越了 Claude Opus 4.1，具有令人印象深刻的创意天赋和更强的指令遵循能力。该模型在大多数情况下第一次就能产生精美、可用的输出。 为了在文档创建方面获得最佳结果：
示例提示
创建一个关于 [主题] 的专业演示文稿。包括深思熟虑的设计元素、视觉层次结构，以及适当的引人入胜的动画。

​
优化并行工具调用

Claude 4 模型在并行工具执行方面表现出色，Sonnet 4.5 在同时触发多个操作方面特别积极。该模型将：
  • 在研究期间运行多个推测性搜索
  • 同时读取多个文件以更快地构建上下文
  • 并行执行 bash 命令（这甚至可能使系统性能成为瓶颈）
这种行为很容易引导。虽然模型在没有提示的情况下在并行工具调用方面有很高的成功率，但您可以将其提升到约100%或调整积极程度：
最大并行效率的示例提示
<use_parallel_tool_calls>
如果您打算调用多个工具，并且工具调用之间没有依赖关系，请并行进行所有独立的工具调用。在可以并行而不是顺序执行操作时，优先同时调用工具。例如，在读取3个文件时，并行运行3个工具调用，同时将所有3个文件读入上下文。在可能的情况下最大化使用并行工具调用以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来通知依赖值（如参数），请不要并行调用这些工具，而是顺序调用它们。永远不要在工具调用中使用占位符或猜测缺失的参数。
</use_parallel_tool_calls>
减少并行执行的示例提示
顺序执行操作，每步之间有短暂暂停以确保稳定性。

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

Claude 4 模型有时可能会为测试和迭代目的创建新文件，特别是在处理代码时。这种方法允许 Claude 使用文件，特别是 python 脚本，作为”临时草稿本”，然后保存其最终输出。使用临时文件可以改善结果，特别是对于代理编码用例。 如果您希望最小化净新文件创建，您可以指示 Claude 在完成后清理：
示例提示
如果您为迭代创建任何临时新文件、脚本或辅助文件，请在任务结束时通过删除这些文件来清理它们。

​
增强视觉和前端代码生成

Claude 4 模型可以生成高质量、视觉上独特、功能性的用户界面。但是，如果没有指导，前端代码可能默认为缺乏视觉趣味的通用模式。要获得卓越的 UI 结果：
  1. 为创造力提供明确的鼓励：
示例提示
不要退缩。全力以赴。创建一个令人印象深刻的演示，展示网络开发能力。
  1. 指定美学方向和设计约束：
示例提示
使用深蓝色和青色调色板、现代无衬线字体（例如，标题使用 Inter，正文使用系统字体）和带有微妙阴影的基于卡片的布局创建专业仪表板。包括深思熟虑的细节，如悬停状态、过渡和微交互。应用设计原则：层次结构、对比度、平衡和运动。
  1. 鼓励设计多样性和融合美学：
示例提示
提供多种设计选项。通过结合来自不同来源的元素创建融合美学——一种配色方案、不同的排版、另一种布局原则。避免通用的居中布局、简单的渐变和统一的样式。
  1. 明确请求特定功能：
  • “包含尽可能多的相关功能和交互”
  • “添加动画和交互元素”
  • “创建超越基础的功能齐全的实现”

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

Claude 4 模型有时可能过于专注于使测试通过，而牺牲更通用的解决方案，或者可能使用变通方法，如辅助脚本进行复杂重构，而不是直接使用标准工具。为了防止这种行为并确保健壮、可概括的解决方案：
示例提示
请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或变通方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。

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

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

​
最小化代理编码中的幻觉

Claude 4 模型不太容易产生幻觉，并基于代码给出更准确、基于事实、智能的答案。为了更多地鼓励这种行为并最小化幻觉：
示例提示
<investigate_before_answering>
永远不要推测您没有打开的代码。如果用户引用特定文件，您必须在回答之前读取该文件。确保在回答有关代码库的问题之前调查和读取相关文件。除非您确定正确答案，否则永远不要在调查之前对代码做出任何声明 - 给出基于事实且无幻觉的答案。
</investigate_before_answering>

​
迁移考虑

从 Sonnet 3.7 迁移到 Claude 4（包括 Sonnet 4.5）时：
  1. 对期望的行为要具体：考虑准确描述您希望在输出中看到的内容。
  2. 用修饰符框定您的指令：添加鼓励 Claude 提高其输出质量和细节的修饰符可以帮助更好地塑造 Claude 的性能。例如，不要说”创建一个分析仪表板”，而是使用”创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能齐全的实现。”
  3. 明确请求特定功能：当需要时，应明确请求动画和交互元素。