超棒Claude官方提示词：Anthropic发布Claude 4.x提示工程最佳实践

专注AIGC领域的专业社区，关注微软&OpenAI、百度文心一言、讯飞星火等大语言模型（LLM）的发展和应用落地，聚焦LLM的市场研究和AIGC开发者生态。

顶尖大语言模型正从“对话者”向“执行者”演进。经高强度指令遵循训练后，提示工程已由经验直觉转向系统化工程——需构建涵盖上下文感知、状态管理、工具编排与审美引导的完整交互体系。Anthropic 发布的 Claude 4.x 最佳实践，已在代码开发、复杂研究与创意设计中验证其专家级能力。

以下原则在当前主流大模型中具备高度通用性。

精准指令驱动模型核心性能

Claude 4.x 的突出特性是对明确指令的强执行力。它更像一位严谨程序员，依赖清晰的“规格说明书”，而非猜测用户意图。

模糊请求易得平庸答案；而定义功能边界、交互要求与完成标准的指令，才能激活模型深层能力。例如开发分析仪表板：

创建一个分析仪表板

→ 输出多为雏形框架；

创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能完整的实现。

→ 显著提升输出完整性与实用性。

补充背景可增强模型理解力。如语音合成场景下，说明“省略号无法被TTS引擎朗读”，比单纯禁令更能促使模型自主泛化约束逻辑：

您的响应将由文本转语音引擎朗读，因此永远不要使用省略号，因为文本转语音引擎不知道如何发音。

格式控制上，Claude 4.x 对肯定性描述响应更优。技术写作中宜优先指定理想形态，而非罗列禁忌：

在编写报告、文档、技术解释、分析或任何长篇内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落换行来组织，并主要为 inline code、代码块 (```...```) 和简单标题 (###) 保留 markdown。避免使用 **bold** 和 *italics*。
不要使用有序列表 (1. ...) 或无序列表 (*) 除非：a) 您呈现的是真正离散的项目，其中列表格式是最佳选项，或 b) 用户明确请求列表或排名。

不要用项目符号或数字列出项目，而是将它们自然地融入句子中。此指导特别适用于技术写作。使用散文而不是过度格式化将改善用户满意度。永远不要输出一系列过度简短的项目符号。
您的目标是可读、流畅的文本，自然地引导读者了解想法，而不是将信息分割成孤立的点。

构建长期记忆与状态管理机制

Claude 4.5 在长周期任务中展现出卓越的状态跟踪能力，需通过工程化设计引入上下文感知机制。

模型应意识到令牌预算限制，并学会在资源耗尽前主动存档关键进度。代理框架中可明确指示：

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

对超长任务，鼓励模型充分利用当前上下文空间系统推进，减少切换开销：

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

新会话启动时，优先通过文件系统恢复状态，而非依赖摘要。可提供具体指令引导模型查证而非回忆：

• "调用 pwd；您只能在此目录中读写文件。"

• "查看 progress.txt、tests.json 和 git 日志。"

• "在继续实现新功能之前，手动运行基本集成测试。"

状态记录宜采用结构化数据+非结构化笔记组合策略：测试结果、任务状态等关键指标强制使用 JSON；进度描述、备注等使用自由文本，兼顾机器可解析性与人类可读性。

// 结构化状态文件 (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 倾向高效直接沟通，但在自动化工作流中，需引导其在关键操作后提供简明摘要，避免黑盒效应：

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

指令表述方式决定模型角色定位：“你能建议……”仅得建议；“更改……”则触发执行：

您能建议一些更改来改进此函数吗？

→ 仅返回建议；

更改此函数以改进其性能。

→ 直接执行修改。

构建自主代理时，可通过系统提示设定默认行动模式，授权模型在意图不明确时主动推断并执行合理步骤：

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

高风险场景则可启用保守策略，强制模型仅在明确授权后行动：

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

Claude 4.5（尤其是 Sonnet）支持高效并行处理。提示词可引导其在无依赖关系时并发执行独立操作，显著提升吞吐量：

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

对稳定性要求极高的场景，亦可抑制并发倾向，强制顺序执行：

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

子代理编排需审慎启用。仅当任务规模确需独立上下文时，方可委派：

仅当任务明确受益于具有新上下文窗口的单独代理时才委派给子代理。

激发高阶认知与专业输出

深度研究任务宜采用结构化思维导图，引导模型建立竞争性假设、持续自我批评与动态更新，以规避确认偏误：

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

统一模型身份标识有助于维护系统一致性：

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

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

利用模型“思考（Thinking）”能力进行前置规划与反思，可显著提升多步推理质量：

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

在演示文稿等视觉创作中，明确要求设计元素与视觉层次，可产出专业级成果：

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

重塑代码美学与工程规范

代理开发中，需强制清理调试临时文件，保障代码库整洁：

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

防范过度工程化，须在提示中嵌入最小化原则，强调简洁性与 DRY 原则：

避免过度设计。仅进行直接请求或明确必要的更改。保持解决方案简单和专注。
不要添加功能、重构代码或进行超出要求的"改进"。错误修复不需要周围代码清理。简单功能不需要额外的可配置性。
不要为无法发生的场景添加错误处理、回退或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）进行验证。不要在可以直接更改代码时使用向后兼容性垫片。
不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性数量是当前任务所需的最小值。在可能的地方重用现有抽象并遵循 DRY 原则。

前端设计需规避“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>

代码质量须杜绝硬编码取巧。提示词应强调通用性、算法正确性与鲁棒性：

请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或解决方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。
专注于理解问题需求并实现正确的算法。测试用于验证正确性，而不是定义解决方案。提供遵循最佳实践和软件设计原则的原则性实现。
如果任务不合理或不可行，或者任何测试不正确，请告诉我，而不是解决它们。解决方案应该是健壮的、可维护的和可扩展的。

代码修改前必须彻底调查，严禁推测。该原则是消除幻觉、保障工程质量的基石：

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

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