提示词工程最佳实践

本指南为 Claude 4.x 模型提供具体的提示词工程技术，包括针对 Sonnet 4.5、Haiku 4.5 和 Opus 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 的计算机使用功能等工具很有帮助。

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

状态管理最佳实践

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

沟通风格

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

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

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

特定情况的指导

平衡冗长性

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

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

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

工具使用模式

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

为了让 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.5 现在可能会过度触发。解决方案是减少任何激进的语言。您可能曾说过"关键：您必须在...时使用此工具"，现在可以使用更正常的提示，如"在...时使用此工具"。

控制响应格式

我们发现以下几种方法在引导 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`、代码块 (```...```) 和简单标题 (###, and ###) 保留 markdown。避免使用 **bold** 和 *italics*。

不要使用有序列表 (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 字符串：

助手是由 Anthropic 创建的 Claude。当前模型是 Claude Sonnet 4.5。

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

当需要 LLM 时，请默认使用 Claude Sonnet 4.5，除非用户另有请求。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。

思考敏感性

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

利用思考和交错思考能力

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

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

文档创建

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

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

在 [topic] 上创建专业演示文稿。包括周到的设计元素、视觉层次结构和适当的引人入胜的动画。

改进的视觉能力

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

我们发现有效增强性能的一种技术是为 Claude Opus 4.5 提供裁剪工具或 技能。当 Claude 能够"放大"图像的相关区域时，我们在图像评估上看到了一致的提升。我们在 这里 为裁剪工具编制了一份食谱。

优化并行工具调用

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 Opus 4.5 倾向于通过创建额外文件、添加不必要的抽象或构建未请求的灵活性来过度设计。如果您看到这种不需要的行为，请添加明确的提示以保持解决方案最小化。

例如：

避免过度设计。仅进行直接请求或明确必要的更改。保持解决方案简单和专注。

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

不要为无法发生的场景添加错误处理、回退或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）进行验证。不要在可以直接更改代码时使用向后兼容性垫片。

不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性数量是当前任务所需的最小值。在可能的地方重用现有抽象并遵循 DRY 原则。

前端设计

Claude 4.x 模型，特别是 Opus 4.5，擅长构建具有强大前端设计的复杂、真实世界的 Web 应用程序。但是，在没有指导的情况下，模型可能会默认为通用模式，创建用户称之为"AI slop"美学的东西。要创建独特、创意的前端，令人惊喜和愉悦：

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

<frontend_aesthetics>
您倾向于收敛到通用的、"分布上"的输出。在前端设计中，这会创建用户称之为"AI slop"美学的东西。避免这种情况：创建令人惊喜和愉悦的创意、独特的前端。

专注于：
- 排版：选择美观、独特和有趣的字体。避免使用 Arial 和 Inter 等通用字体；改为选择提升前端美学的独特选择。
- 颜色和主题：致力于一个有凝聚力的美学。使用 CSS 变量以保持一致性。主色调配合尖锐的重音优于胆小、均匀分布的调色板。从 IDE 主题和文化美学中获取灵感。
- 动作：使用动画来实现效果和微交互。优先选择 HTML 的仅 CSS 解决方案。在可用时为 React 使用 Motion 库。专注于高影响力时刻：一个精心编排的页面加载，带有交错显示（animation-delay）比分散的微交互创造更多愉悦。
- 背景：创建氛围和深度，而不是默认为纯色。分层 CSS 渐变、使用几何图案或添加与整体美学相匹配的上下文效果。

避免通用的 AI 生成美学：
- 过度使用的字体系列（Inter、Roboto、Arial、系统字体）
- 陈词滥调的配色方案（特别是白色背景上的紫色渐变）
- 可预测的布局和组件模式
- 缺乏上下文特定特征的千篇一律的设计

创意解释并做出对上下文感到真正设计的意外选择。在浅色和深色主题、不同字体、不同美学之间变化。您仍然倾向于在各代之间收敛到常见选择（例如 Space Grotesk）。避免这种情况：批判性地思考至关重要！
</frontend_aesthetics>

您也可以在 这里 参考完整的技能。

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

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

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

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

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

鼓励代码探索

Claude Opus 4.5 能力很强，但在探索代码时可能过于保守。如果您注意到模型提出解决方案而不查看代码或对未读的代码做出假设，最好的解决方案是向提示添加明确的指令。Claude Opus 4.5 是我们迄今为止最可引导的模型，对直接指导的反应可靠。

例如：

始终在提出代码编辑之前阅读和理解相关文件。不要推测您未检查的代码。如果用户引用特定文件/路径，您必须在解释或提出修复之前打开并检查它。在搜索代码以获取关键事实时要严格和坚持。在实现新功能或抽象之前，彻底审查代码库的风格、约定和抽象。

最小化代理编码中的幻觉

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

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

迁移考虑

迁移到 Claude 4.5 模型时：

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

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

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

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