针对 Claude 模型的专业提示词工程技术，涵盖 Sonnet 4.5, Sonnet 4, Haiku 4.5, Opus 4.1, 和 Opus 4 等型号，以助你在各类应用中获得卓越性能。相较于前代 Claude 模型，新一代模型经过专门训练，能够更精确地遵循指令。
Anthropic 于周三发布了 Claude Haiku 4.5，这是一款紧凑型 AI 模型，其编码性能与 5 月份的 Sonnet 4 相当，运行速度是其两倍多，成本约为三分之一。
该模型输入令牌每百万美元 1 美元，输出令牌每百万美元 5 美元。并向所有用户免费提供 Haiku 4.5。
https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
一、通用核心原则
1. 指令需明确具体 (Be Explicit)
Claude 4 模型对清晰、明确的指令响应极佳。具体说明你期望的输出，有助于显著提升结果质量。
如果用户期望获得前代模型中那种“超越期待”的主动发挥行为，在 Claude 4 中可能需要更明确地提出此类要求。
示例：创建数据分析页面
低效案例：
创建一个数据分析页面高效案例：
创建一个数据分析页面。请包含尽可能多的相关功能和交互特性。超越基础功能，实现一个全功能的版本。2. 补充上下文以提升性能 (Add Context)
提供指令背后的上下文或动机，例如向 Claude 解释为何某个行为至关重要，能帮助 Claude 4 模型更好地理解你的目标，并给出更具针对性的回应。Claude 足够智能，能够从你的解释中进行泛化。
示例：格式化偏好
低效案例：
绝不要使用省略号高效案例：
你的回答将被文本转语音（TTS）引擎朗读，因此绝不要使用省略号，因为 TTS 引擎不知道如何发音。3. 审慎对待示例与细节 (Be Vigilant with Examples)
作为其精确指令遵循能力的一部分，Claude 4 模型会密切关注你提供的细节和示例。
请确保你的示例与你希望鼓励的行为保持一致，并尽量减少你希望避免的行为。
二、长期推理与状态追踪
Claude Sonnet 4.5 在需要长期推理的任务中表现卓越，具备出色的状态追踪能力。它通过专注于增量进展（一次稳步推进几件事，而非一次性尝试所有事）来在扩展会话中保持方向感。
此能力在跨越多个上下文窗口或任务迭代时尤为突出，Claude 可以在一个复杂任务上工作，保存其状态，然后在新的上下文窗口中继续。
1. 上下文感知 (Context Awareness) 与多窗口工作流
Claude Sonnet 4.5 具备上下文感知能力，使其能在整个对话中追踪剩余的上下文窗口（即“token 预算”）。这使得 Claude 能够通过了解其可用空间来更有效地执行任务和管理上下文。
上下文限制
如果你在代理框架（Agent Harness）中使用 Claude，且该框架会压缩上下文或允许将上下文保存到外部文件（如 Claude Code），建议你将此信息添加到提示词中，以便 Claude 采取相应行动。否则，Claude 在接近上下文限制时，有时会自然地尝试结束工作。
示例提示词：
当你的上下文窗口接近极限时，系统会自动进行压缩，让你能从中断的地方无限期地继续工作。因此，不要因为 token 预算的顾虑而提前中止任务。在接近 token 预算极限时，请在上下文窗口刷新前，将你当前的进展和状态保存到记忆工具中。务必尽可能地保持持久和自主，并完整地完成任务，即使预算即将耗尽。无论剩余上下文如何，绝不要人为地提前停止任何任务。- 与上下文能力天然匹配的 记忆工具 (memory tool)，它可以实现无缝的上下文转换。
2. 跨上下文窗口的工作流策略
对于跨越多个上下文窗口的复杂任务，请遵循以下策略：
- 为首次上下文窗口使用不同提示：利用第一个窗口建立框架（编写测试、创建设置脚本），然后在后续窗口中迭代处理一个待办事项列表。
- 让模型以结构化格式编写测试：要求 Claude 在开始工作前创建测试，并以结构化格式（如
tests.json）进行追踪。这有助于提升长期迭代能力。同时提醒 Claude 测试的重要性：“移除或编辑测试是不可接受的，因为这可能导致功能缺失或错误。” - 设置便捷工具：鼓励 Claude 创建设置脚本（如
init.sh）来优雅地启动服务、运行测试套件和代码检查工具。这可以避免在新的上下文窗口中重复工作。
- 从零开始 vs. 上下文压缩：当上下文窗口被清空时，可以考虑从一个全新的窗口开始，而不是使用压缩。Sonnet 4.5 非常擅长从本地文件系统中发现状态。在某些情况下，利用这一点可能比压缩更有效。请明确指示它应如何开始：
- “调用
pwd；你只能读写此目录下的文件。” - “回顾
progress.txt,tests.json, 和git logs。” - “在实现新功能前，手动运行一个基础的集成测试。”
- 提供验证工具：随着自主任务长度的增加，Claude 需要在没有持续人类反馈的情况下验证正确性。诸如 Playwright MCP 服务器或用于测试 UI 的计算机使用能力等工具会很有帮助。
- 鼓励充分利用上下文：提示 Claude 在转向下一个组件前，高效地完成当前组件。
- 示例提示词：
这是一个非常长的任务，因此清晰地规划你的工作会很有益处。鼓励你用尽整个输出上下文来处理任务，只需确保不要在有大量未提交工作的情况下耗尽上下文。请系统地持续工作，直到你完成这个任务。3. 状态管理的最佳实践
- 结构化数据使用 JSON 等格式：在追踪测试结果或任务状态等结构化信息时，使用 JSON 或其他结构化格式，以帮助 Claude 理解 schema 要求。
- 非结构化文本用于进度笔记：自由格式的进度笔记非常适合追踪总体进展和上下文。
- 使用 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)
第三次会话进展：
- 修复了认证令牌验证问题
- 更新了用户模型以处理边缘情况
- 下一步：调查 user_management 测试失败
原因 (测试 #2)
- 注意：不要移除测试，因为这可能导致功能缺失4. 沟通风格
与前代模型相比，Claude Sonnet 4.5 的沟通风格更为简洁和自然：
- 更直接、更接地气：提供基于事实的进度报告，而非自我表扬式的更新。
- 更具对话感：语言更流畅、更口语化，减少了机器感。
- 更少冗余：为了效率，除非被提示，否则可能会跳过详细的摘要。
这种沟通风格能准确反映已完成的工作，而无不必要的赘述。
三、特定场景实践
1. 平衡输出的详细程度
Claude Sonnet 4.5 倾向于高效，可能会在调用工具后跳过口头总结，直接进入下一步行动。虽然这创造了流畅的工作流，但你可能希望更多地了解其推理过程。
- 若希望 Claude 在工作时提供更新，可使用以下提示：
在完成一个涉及工具使用的任务后，请简要总结你所做的工作。2. 引导工具使用模式
Claude Sonnet 4.5 经过训练，能精确遵循指令，因此明确指示其使用特定工具会带来更好的效果。如果你说“你能建议一些修改吗？”，它有时只会提供建议而不是实施它们，即使你的意图是让它直接修改。
- 要让 Claude 采取行动，指令需要更明确：
低效案例 (Claude 只会建议)：
你能对这个函数提出一些改进建议吗？高效案例 (Claude 会直接修改)：
修改这个函数以提升其性能。或者对认证流程进行这些编辑。- 若要让 Claude 默认更主动地采取行动，可将以下内容添加到你的系统提示中：
<default_to_action>
默认情况下，直接实施变更而不是仅仅提出建议。如果用户的意图不明确，请推断出最有可能有用的行动并继续，使用工具来发现任何缺失的细节而
不是猜测。尝试推断用户是否意图进行工具调用（例如，文件编辑或读取），并据此行动。
</default_to_action>- 相反，若希望模型默认更保守，可使用以下提示：
<do_not_act_before_instructions>
在没有明确指示要进行更改之前，不要立即开始实施或修改文件。当用户意图模糊时，默认提供信息、进行研究并给出建议，而不是采取行动。只有在用户明确要求时，才进行编辑、修改或实施。
</do_not_act_before_instructions>3. 控制响应的格式
以下几种方法在 Claude 4 模型中被证明对引导输出格式特别有效：
- 告知应该做什么，而不是不能做什么
- ❌：“不要在你的回应中使用 markdown”
- ✔：“你的回应应该由流畅的散文段落组成。”
- 使用 XML 格式指示符
- ✔：“请将你回应中的散文部分写在
<smoothly_flowing_prose_paragraphs>标签内。”
- 使提示词风格与期望输出匹配
你在提示中使用的格式风格可能会影响 Claude 的回应风格。若在输出格式引导方面仍有问题，建议你尽可能使提示词的风格与期望输出的风格相匹配。
例如，从提示词中移除 markdown 可以减少输出中 markdown 的数量。 - 使用详细提示来满足特定格式偏好
- 示例提示词（最小化 Markdown 使用）：
<avoid_excessive_markdown_and_bullet_points>
在撰写报告、文档、技术解释、分析或任何长篇内容时，请使用清晰、流畅的散文，构成完整的段落和句子。使用标准的段落分隔来组织内容，并将 markdown 主要保留用于 `行内代码`、代码块 (```...```) 和简单的标题 (##, ###)。避免使用 **粗体** 和 *斜体*。
不要使用有序列表 (1. ...) 或无序列表 (*) ，除非：a) 你在呈现真正离散的项目，列表是最佳选择；或 b) 用户明确要求列表或排名。
与其用项目符号或数字列出项目，不如将它们自然地融入句子中。这一指导尤其适用于技术写作。使用散文而非过多的格式化将提高用户满意度。绝不要输出一系列过短的项目符号点。
你的目标是创造可读、流畅的文本，自然地引导读者理解思想，而不是将信息分割成孤立的点。
</avoid_excessive_markdown_and_bullet_points>4. 优化研究与信息搜集
Claude Sonnet 4.5 展示了卓越的代理搜索能力，能有效地从多个来源查找和综合信息。为获得最佳研究结果：
- 提供明确的成功标准：定义什么构成对你研究问题的成功回答。
- 鼓励来源验证：要求 Claude 交叉验证来自多个来源的信息。
- 对于复杂研究任务，采用结构化方法：
- 示例提示词：
请以结构化的方式搜索此信息。在收集数据的同时，发展出几个相互竞争的假设。在你的进度笔记中追踪你对这些假设的置信度，以提高校准能力。定期自我批判你的方法和计划。更新一个假设树或研究笔记文件，以持久化信息并提供透明度。系统地分解这个复杂的研究任务。5. 子代理编排 (Subagent Orchestration)
Claude Sonnet 4.5 在原生子代理编排能力上有了显著提升。模型能够识别出哪些任务可以从委托给专门的子代理中受益，并主动这样做，无需明确指示。
- 要利用此行为：
- 确保子代理工具定义良好：提供可用的子代理工具，并在工具定义中清晰描述。
- 让 Claude 自然编排：无需明确指示，Claude 会适当地进行任务委托。
- 如有需要，调整保守性：
只有当任务能从一个拥有新上下文窗口的独立代理中明确受益时，才委托给子代理。6. 模型自我认知
若希望 Claude 在你的应用中正确地识别自己或使用特定的 API 字符串：
- 模型身份提示：
这个助手是 Claude，由 Anthropic 创建。当前模型是 Claude Sonnet 4.5。- 指定模型字符串提示：
当需要一个 LLM 时，请默认使用 Claude Sonnet 4.5，除非用户另有要求。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。7. 善用思考 (Thinking) 与交错思考 (Interleaved Thinking)
Claude 4 提供的“思考”能力，对于需要在工具使用后进行反思或进行复杂多步推理的任务特别有帮助。
你可以引导其初始思考或交错思考以获得更好的结果。
- 示例提示词：
在收到工具结果后，仔细反思其质量，并在继续前确定最佳的后续步骤。利用你的思考来基于新信息进行规划和迭代，然后采取最佳的下一步行动。8. 文档与视觉内容创作
Claude Sonnet 4.5 擅长创作演示文稿、动画和视觉文档，其表现与 Claude Opus 4.1 相当甚至更优，具有令人印象深刻的创造力和更强的指令遵循能力。在大多数情况下，该模型能一次性产出精良、可用的成果。
- 文档创作最佳实践提示：
就 [主题] 创建一个专业的演示文稿。请包含深思熟虑的设计元素、视觉层次结构，并在适当之处加入引人入胜的动画。9. 优化并行工具调用 (Parallel Tool Calling)
Claude 4 模型擅长并行执行工具，其中 Sonnet 4.5 在同时启动多个操作方面尤为积极。模型会：
- 在研究期间运行多个推测性搜索。
- 一次性读取多个文件以更快地建立上下文。
- 并行执行 bash 命令（甚至可能导致系统性能瓶颈）。
这种行为是可引导的。虽然模型在没有提示的情况下并行调用工具的成功率很高，但你可以通过提示将其提升至接近 100% 或调整其积极程度。
- 最大化并行效率的提示：
<use_parallel_tool_calls>
如果你打算调用多个工具，并且这些工具调用之间没有依赖关系，请并行进行所有独立的工具调用。只要操作可以并行完成，就优先同时调用工具，而不是顺序调用。例如，当读取 3 个文件时，并行运行 3 个工具调用，以同时将所有 3 个文件读入上下文。尽可能最大化使用并行工具调用，以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来获取参数等依赖值，请不要并行调用这些工具，而应顺序调用。绝不要在工具调用中使用占位符或猜测缺失的参数。</use_parallel_tool_calls>- 减少并行执行的提示：
请顺序执行操作，并在每步之间稍作停顿，以确保稳定性。10. 减少代理编码中的文件创建
Claude 4 模型有时会为测试和迭代目的创建新文件，尤其是在处理代码时。这种方法允许 Claude 将文件（特别是 python 脚本）用作“临时草稿”，然后再保存最终输出。使用临时文件可以改善代理编码用例的结果。
- 若希望尽量减少净增新文件，可以指示 Claude 自行清理：
如果你为迭代创建了任何临时的新文件、脚本或辅助文件，请在任务结束时通过删除它们来进行清理。11. 增强视觉与前端代码生成
Claude 4 模型能生成高质量、视觉独特且功能齐全的用户界面。然而，若无引导，前端代码可能默认为缺乏视觉趣味的通用模式。为获得卓越的 UI 结果：
- 明确鼓励创造力：
不要保留实力。全力以赴。创建一个令人印象深刻的演示，展示你的 Web 开发能力。- 指定美学方向和设计约束：
使用深蓝色和青色的调色板，现代无衬线字体（例如，标题使用 Inter，正文使用系统字体），以及带有微妙阴影的卡片式布局，创建一个专业的数据展示界面。包含悬停状态、过渡和微交互等贴心细节。应用设计原则：层次、对比、平衡和动感。- 鼓励设计多样性与融合美学：
提供多种设计选项。通过融合不同来源的元素来创造融合美学，一种配色方案，不同的字体，另一种布局原则。避免通用的居中布局、简单的渐变和统一的样式。- 明确要求特定功能：
- “包含尽可能多的相关功能和交互。”
- “添加动画和交互元素。”
- “实现一个超越基础的全功能版本。”
12. 避免为通过测试而硬编码
Claude 4 模型有时可能过分专注于让测试通过，而牺牲了更通用的解决方案，或者可能使用辅助脚本等变通方法进行复杂重构，而不是直接使用标准工具。
为防止此行为并确保解决方案的健壮性和通用性：
- 示例提示词：
请使用可用的标准工具编写一个高质量、通用的解决方案。不要为了更高效地完成任务而创建辅助脚本或变通方法。实现一个对所有有效输入都正确的解决方案，而不仅仅是测试用例。不要硬编码值或创建只对特定测试输入有效的解决方案。相反，请实现能通用解决问题的实际逻辑。
专注于理解问题需求并实现正确的算法。测试是为了验证正确性，而不是定义解决方案。请提供一个遵循最佳实践和软件设计原则的、有原则的实现。
如果任务不合理或不可行，或者任何测试不确，请告知我，而不是绕过它们。解决方案应该是健壮、可维护和可扩展的。13. 最小化代理编码中的幻觉
Claude 4 模型更不易产生幻觉，能基于代码给出更准确、有根据、智能的答案。为进一步鼓励此行为并最小化幻觉：
- 示例提示词：
<investigate_before_answering>
绝不要对你没有打开过的代码进行推测。如果用户引用了特定的文件，你必须在回答前阅读该文件。确保在回答有关代码库的问题之前，调查并阅读相关文件。除非你确定正确答案，否则在调查之前绝不对代码做任何断言，给出有根据且无幻觉的答案。
</investigate_before_answering>
