提示词最佳实践

本指南提供了针对 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 模型具有上下文感知功能，使模型能够在整个对话中跟踪其剩余的上下文窗口（即"token 预算"）。这使 Claude 能够通过了解有多少工作空间来更有效地执行任务和管理上下文。

管理上下文限制：

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

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

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

多上下文窗口工作流

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

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

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

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

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

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

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

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

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

状态管理最佳实践

• 对状态数据使用结构化格式：跟踪结构化信息（如测试结果或任务状态）时，使用 JSON 或其他结构化格式帮助 Claude 理解模式要求
• 对进度笔记使用非结构化文本：自由格式的进度笔记在跟踪一般进度和上下文方面效果很好
• 使用 git 进行状态跟踪：Git 提供了已完成工作的日志和可以恢复的检查点。Claude 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 4.5 模型与之前的模型相比，具有更简洁和自然的沟通风格：

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

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

特定情况的指导

平衡详细程度

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

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

完成涉及工具使用的任务后，提供你已完成工作的简要摘要。

工具使用模式

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

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

控制响应格式

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

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

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

• 使用 XML 格式指示符

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

• 将你的提示词风格与期望的输出匹配

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

• 使用详细的提示词来获得特定的格式偏好

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

<avoid_excessive_markdown_and_bullet_points>
在编写报告、文档、技术解释、分析或任何长篇幅内容时，使用完整的段落和句子，以清晰、流畅的散文形式写作。使用标准段落分隔来组织内容，主要将 markdown 保留用于 `inline code`、代码块（```...```）和简单标题（###, 和 ###）。避免使用 **粗体** 和 *斜体*。

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

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

你的目标是可读的、流畅的文本，自然地引导读者理解想法，而不是将信息分割成孤立的点。
</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 Opus 4.5 对"think"一词及其变体特别敏感。我们建议用传达相似含义的替代词替换"think"，例如"consider"、"believe"和"evaluate"。

利用思考和交错思考能力

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

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

文档创建

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

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

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

改进的视觉能力

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 垃圾"美学的东西。要创建令人惊喜和愉悦的独特、创意前端：

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

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

专注于：
- 排版：选择美观、独特和有趣的字体。避免像 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. 明确请求特定功能：动画和交互元素在需要时应明确请求。