本指南提供了针对 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 预算限制时，在上下文窗口刷新之前，将你当前的进度和状态保存到内存中。始终尽可能保持持久和自主，并完全完成任务，即使你的预算即将结束。无论剩余上下文如何，永远不要人为地提前停止任何任务。
记忆工具与上下文感知自然配对，可实现无缝的上下文转换。
对于跨越多个上下文窗口的任务：
为第一个上下文窗口使用不同的提示词：使用第一个上下文窗口来设置框架（编写测试、创建设置脚本），然后使用未来的上下文窗口在待办事项列表上进行迭代。
让模型以结构化格式编写测试：要求 Claude 在开始工作之前创建测试，并以结构化格式（例如tests.json）跟踪它们。这导致更好的长期迭代能力。提醒 Claude 测试的重要性："删除或编辑测试是不可接受的，因为这可能导致功能缺失或错误。"
设置生活质量工具：鼓励 Claude 创建设置脚本（例如init.sh）以优雅地启动服务器、运行测试套件和 linter。这可以防止从新的上下文窗口继续时重复工作。
全新开始 vs 压缩：当上下文窗口被清除时，考虑使用全新的上下文窗口而不是使用压缩。Claude 4.5 模型在从本地文件系统发现状态方面非常有效。在某些情况下，你可能希望利用这一点而不是压缩。明确规定它应该如何开始：
提供验证工具：随着自主任务长度的增长，Claude 需要在不持续人工反馈的情况下验证正确性。像 Playwright MCP 服务器或用于测试 UI 的计算机使用功能等工具很有帮助。
鼓励充分利用上下文：提示 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 模型的输出格式方面特别有效：
告诉 Claude 要做什么，而不是不要做什么
使用 XML 格式指示符
将你的提示词风格与期望的输出匹配
你在提示词中使用的格式风格可能会影响 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 模型展示了卓越的代理搜索能力，可以有效地从多个来源查找和综合信息。为了获得最佳研究结果：
提供明确的成功标准：定义什么构成你研究问题的成功答案
鼓励来源验证：要求 Claude 在多个来源中验证信息
对于复杂的研究任务，使用结构化方法：
以结构化的方式搜索此信息。当你收集数据时，发展几个相互竞争的假设。在你的进度笔记中跟踪你的置信水平，以改善校准。定期自我批判你的方法和计划。更新假设树或研究笔记文件以持久化信息并提供透明度。系统地分解这个复杂的研究任务。
这种结构化方法允许 Claude 查找和综合几乎任何信息，并迭代地批判其发现，无论语料库的大小如何。
Claude 4.5 模型展示了显著改进的原生子代理编排能力。这些模型可以识别任务何时会从将工作委托给专门的子代理中受益，并在不需要明确指令的情况下主动这样做。
要利用这种行为：
只有当任务明显受益于具有新上下文窗口的独立代理时，才委托给子代理。
如果你希望 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 模型将：
这种行为很容易引导。虽然模型在没有提示的情况下并行工具调用成功率很高，但你可以将其提升到约 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 模型时：
明确期望的行为：考虑准确描述你希望在输出中看到的内容。
用修饰符构建你的指令：添加鼓励 Claude 提高输出质量和细节的修饰符可以帮助更好地塑造 Claude 的性能。例如，不要使用"创建分析仪表板"，而是使用"创建分析仪表板。包含尽可能多的相关功能和交互。超越基础，创建功能完整的实现。"
明确请求特定功能：动画和交互元素在需要时应明确请求。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |