提示词最佳实践

本指南提供了针对Claude 4.x模型的具体提示词工程技术，并为Sonnet 4.5和Haiku 4.5提供了特定指导。这些模型经过训练，相比之前的Claude模型代数，能够更精确地遵循指令。

通用原则

明确您的指令

Claude 4.x模型对清晰、明确的指令反应良好。具体说明您期望的输出可以帮助增强结果。希望从之前的Claude模型获得"超越预期"行为的客户可能需要更明确地向新模型请求这些行为。

添加上下文以改进性能

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

Claude足够聪明，可以从解释中进行泛化。

对示例和细节保持警惕

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

长期推理和状态跟踪

Claude 4.5模型在具有异常状态跟踪能力的长期推理任务中表现出色。它通过关注增量进展来维持跨越扩展会话的方向——一次在几件事上稳步推进，而不是试图一次完成所有事情。这种能力特别在多个上下文窗口或任务迭代中出现，Claude可以处理复杂任务、保存状态，并使用新的上下文窗口继续。

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

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

管理上下文限制：

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

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

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

多上下文窗口工作流

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

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

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

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

4. 从头开始与压缩：当上下文窗口被清除时，考虑使用全新的上下文窗口而不是使用压缩。Claude 4.5模型在从本地文件系统发现状态方面非常有效。在某些情况下，您可能想利用这一点而不是压缩。对其应该如何开始要有规范性：

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

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

6. 鼓励完整使用上下文：提示Claude在继续之前有效地完成组件：

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

状态管理最佳实践

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

通信风格

Claude 4.5模型与之前的模型相比具有更简洁和自然的通信风格：

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

这种通信风格准确反映了所取得的成就，没有不必要的详细说明。

特定情况的指导

平衡冗长性

Claude 4.5模型倾向于效率，可能在工具调用后跳过口头摘要，直接跳到下一个操作。虽然这创建了一个流线型的工作流，但您可能更希望看到其推理过程的可见性。

如果您希望Claude在工作时提供更新：

完成涉及工具使用的任务后，提供您所做工作的快速摘要。

工具使用模式

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

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

为了让Claude默认更主动地采取行动，您可以将其添加到您的系统提示中：

<default_to_action>
默认情况下，实现更改而不仅仅是建议它们。如果用户的意图不清楚，推断最有用的可能操作并继续，使用工具发现任何缺失的细节而不是猜测。尝试推断用户关于是否打算进行工具调用（例如文件编辑或读取）的意图，并相应地采取行动。
</default_to_action>

另一方面，如果您希望模型默认更犹豫，不太容易直接跳入实现，并且仅在请求时采取行动，您可以使用如下提示来引导此行为：

<do_not_act_before_instructions>
除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图不明确时，默认提供信息、进行研究和提供建议，而不是采取行动。仅当用户明确请求时才继续进行编辑、修改或实现。
</do_not_act_before_instructions>

控制响应格式

我们发现以下几种方式在引导Claude 4.x模型的输出格式方面特别有效：

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

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

2. 使用XML格式指示符

   • 尝试："在<smoothly_flowing_prose_paragraphs>标签中编写响应的散文部分。"

3. 将您的提示风格与期望的输出相匹配

   您的提示中使用的格式风格可能会影响Claude的响应风格。如果您仍然遇到输出格式的可操纵性问题，我们建议尽可能将您的提示风格与您期望的输出风格相匹配。例如，从您的提示中删除markdown可以减少输出中的markdown数量。

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

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

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

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

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

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

研究和信息收集

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

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

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

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

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

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

子代理编排

Claude 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.x模型提供思考能力，对于涉及工具使用后反思或复杂多步推理的任务特别有帮助。您可以指导其初始或交错思考以获得更好的结果。

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

文档创建

Claude 4.5模型在创建演示文稿、动画和视觉文档方面表现出色。这些模型在此领域与Claude Opus 4.1相当或超过，具有令人印象深刻的创意风采和更强的指令遵循能力。这些模型在大多数情况下在第一次尝试时就产生了精美、可用的输出。

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

创建关于[主题]的专业演示文稿。包括深思熟虑的设计元素、视觉层次和适当的引人入胜的动画。

优化并行工具调用

Claude 4.x模型在并行工具执行方面表现出色，Sonnet 4.5特别积极地同时触发多个操作。Claude 4.x模型将：

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

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

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

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

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

Claude 4.x模型有时可能会创建新文件用于测试和迭代目的，特别是在处理代码时。这种方法允许Claude使用文件，特别是python脚本，作为在保存最终输出之前的"临时便签纸"。使用临时文件可以改进结果，特别是对于代理编码用例。

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

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

增强视觉和前端代码生成

Claude 4.x模型可以生成高质量、视觉上独特、功能性的用户界面。但是，在没有指导的情况下，前端代码可能会默认为缺乏视觉兴趣的通用模式。为了获得异常的UI结果：

1. 提供明确的创意鼓励：

不要保留。尽力而为。创建一个令人印象深刻的演示，展示网络开发能力。

1. 指定美学方向和设计约束：

使用深蓝色和青色调色板、现代无衬线字体（例如标题使用Inter，正文使用系统字体）和带有细微阴影的卡片式布局创建专业仪表板。包括周到的细节，如悬停状态、过渡和微交互。应用设计原则：层次、对比、平衡和运动。

1. 鼓励设计多样性和融合美学：

提供多个设计选项。通过组合来自不同来源的元素来创建融合美学——一种配色方案、不同的排版、另一种布局原则。避免通用的居中布局、简单的渐变和统一的样式。

1. 明确请求特定功能：

• "包括尽可能多的相关功能和交互"
• "添加动画和交互元素"
• "创建一个超越基础的功能完整的实现"

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

Claude 4.x模型有时可能过度关注通过测试，而牺牲更通用的解决方案，或者可能使用解决方法，如用于复杂重构的辅助脚本，而不是直接使用标准工具。为了防止这种行为并确保健壮、可泛化的解决方案：

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

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

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

最小化代理编码中的幻觉

Claude 4.x模型不太容易产生幻觉，并根据代码提供更准确、扎根、智能的答案。为了进一步鼓励这种行为并最小化幻觉：

<investigate_before_answering>
永远不要推测您没有打开的代码。如果用户引用特定文件，您必须在回答前读取该文件。确保在回答有关代码库的问题之前进行调查和读取相关文件。在调查之前，永远不要对代码进行任何声称，除非您确定正确答案——提供扎根的、无幻觉的答案。
</investigate_before_answering>

迁移考虑

迁移到Claude 4.5模型时：

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

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

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