40万播放的 Anthropic 价值$300的官方提示词课

发过不少关于写好提示词的文章：Claude Fable 5 的系统提示词是怎么写的？

我从顶级的提示词工程团队（Anthropic）那里学到了什么

谷歌提示工程白皮书｜Google Prompt Engineering White-paper

不过遇到一些具体场景时，我们还是有个问题，怎么写能让大模型发挥得更好呢？

这篇文章就介绍一篇 Anthropic 的应用 AI 团队的提示词最佳实践，并通过一个真实场景来一起构建提示词。

课程通过一个动手实操场景来学习，使用了一个受真实客户案例启发的例子（已做修改），这是一个分析图像、提取事实信息并让 Claude 对内容做出判断的案例。

场景：车险事故分析

设定场景：想象你在一家瑞典汽车保险公司工作，每天处理车险理赔。现在有两条信息：

1. 1. 一份车祸报告表格 —— 17个复选框，记录事故发生前的情况，分为车辆A和车辆B两列
2. 2. 一份手绘事故示意图 —— 人类手绘的事故经过草图

V1：简单提示词（无上下文）

我们先用一个非常简单的提示词试试，只告诉 Claude"审查事故报告表格，判断事故经过和谁的过错"。

结果： Claude 认为这是一起滑雪事故（发生在瑞典常见的 Chappangan 街）。

这是一个"无辜的错误"——因为我们没有告诉 Claude 这是什么场景。

教训： 提示工程是一门迭代的实验科学。

Claude 不知道你没告诉它的事。

优秀的提示词结构

Hannah：推荐的提示词结构包含五个关键部分。

首先需要明确任务描述，即告诉Claude它扮演什么角色、今天要完成的具体任务是什么。

接着是内容部分，用于提供图片、表单、从其他系统获取的数据等动态信息。

然后是详细指令，要分步骤告诉Claude如何处理任务、如何进行推理。

接下来可以给出示例，向Claude展示当收到特定内容时应该怎样回复。

最后是重复重点，再次强调对Claude来说最重要的信息，重申关键点，然后让它开始工作。

V2：添加任务上下文和语气

任务上下文（Task Context）

Christian：我们在第二版中补充了关键信息：

• • 明确这是一个 AI 助手帮助人类理赔审核员审查瑞典语车祸报告表格
• • 明确那张图是人类手绘的事故示意图
• • 强调如果不确定，不要做出判断——这非常关键

结果： Claude 现在正确识别出这是车祸事故（不再是滑雪事故），并能正确读出车辆A勾选了第1项、车辆B勾选了第12项。

但由于缺少表格的详细说明，Claude 仍然无法做出完全确定的过错判断。

V3：背景数据

Hannah：我们对这个表格其实了解很多——表格的结构每次都一样，永远不会变。

这类信息非常适合放在系统提示（System Prompt）中。

我们在系统提示中告诉 Claude：

• • 这是一份瑞典语车祸表格
• • 表格有两列，代表不同车辆
• • 详细解释每一行（17行）的含义
• • 表格的填写方式——人类填写不会完美，可能画圈、涂鸦、不一定在框里画X
• • 这份表格的用途和意义

💡 提示： 固定不变的信息放入系统提示，还可以利用提示缓存（Prompt Caching）来优化性能。

信息组织方式

Claude 非常喜欢结构化和组织化。推荐使用：

• • XML 标签（首选）—— 可以指定标签内的内容类型，如 <user_preferences>、<form_data>
• • Markdown —— 也对 Claude 有帮助
• • XML 标签的好处是让 Claude 能在后续引用前面的信息

结果： Claude 不再花时间解释表格是什么，而是直接给出发现的事实。

更重要的是，Claude 现在有信心做出判断：车辆B有过错。

给出示范（Few-Shot）

Christian：示例是引导 Claude 最强大的机制之一。

想象你有一些棘手的真实案例：Claude 可能搞错，但凭借你的人类直觉和标注数据，你能得出正确结论。

你可以把这些案例放进系统提示：

• • 视觉示例：Base64 编码图片作为数据传入
• • 推理描述：如何分解和理解这个案例

这就是提示工程的"实验科学"，不断发现 Claude 出错的地方，把正确答案加入系统提示。

下次遇到类似案例时，Claude 就能参考示例集做出正确判断。

💡 如果为保险公司构建真实应用，你可能会有几十甚至上百个"灰色地带"的示例。

与给出示范一样，如果你在构建面向用户的对话式应用，长对话历史也是系统提示中的重要上下文来源。

V4：详细任务指令 + 分析顺序

Hannah：我们给 Claude 添加了一份详细的分析步骤清单。一个关键发现：

Claude 分析信息的顺序非常重要。

就像人类一样：你不会先看草图（那是一堆框和线，没有上下文根本看不懂），而是先看表格，理解这是车祸、有哪些勾选项，然后再结合草图理解。

所以我们指示 Claude：

1. 1. 先仔细检查表格 —— 逐个确认哪些框被勾选，不要遗漏
2. 2. 然后查看草图 —— 基于从表格获得的信息来理解草图
3. 3. 综合分析 —— 将表格信息与草图匹配，得出最终判断

结果： Claude 详细展示了它的推理过程——逐个检查复选框，分析表格，分析草图，然后做出判断。

这种分步思考对复杂案例的正确判断至关重要。

防幻觉

Hannah：在最后的提醒中，我们强调：

• • 只在非常确定时才回答
• • 如果看不清哪个框被勾选，不要猜测
• • 如果草图无法辨认，直接说明（人类画得太差，连人都看不懂）
• • 每个事实声明都要引用依据 —— 比如"车辆B右转"要说"我判断的依据是第2个框明显被勾选了"

输出格式化

Christian：作为数据工程师，你最终需要的是一条可以存入 SQL 数据库的信息，而不是 Claude 的长篇大论。

我们指示 Claude：

• • 用 XML 标签包裹最终判断结果
• • 保持摘要清晰、简洁、准确
• • 排除与数据分析无关的内容

成果： 从"滑雪事故"到"不确定的车祸判断"，再到格式化、有信心的结构化输出，终于可以应用于实际车险公司系统。

预填充响应（Pre-filled Responses）

Hannah：另一种控制输出的方式是"替 Claude 说话的开头"，在 API 调用中预设 Claude 的回复开头：

• • 比如以 [ 开头 → 强制 JSON 数组输出
• • 比如以 <final_verdict> 开头 → 强制 XML 标签输出

这样可以跳过前言，直接得到结构化数据。

这个技巧我记得非常有用，在对接一些软件系统时，不需要文字，需要格式化数据的时刻，否则后续代码还要处理非格式化情况。

扩展思考（Extended Thinking）

Christian：Claude 3.7 和 Claude 4 都支持扩展思考（Extended Thinking）模式：

• • 启用扩展思考让 Claude 有时间"深度思考"
• • Claude 会生成思考标签和草稿纸
• • 你可以分析这些思考过程，了解 Claude 如何处理你提供的数据

你能看到模型是如何一步步推理的，对于理解和优化系统提示都很有用。

我也经常在大模型工作的时候，看它深度思考 think 部分的内容。

昨天看到小米Mimo 模型居然输出了“目录莫名消失了“，有点想笑出声，像不像一个犯了错慌张的实习生？

总结

最后，再总结一下官方的提示词课十个要点：

首先是任务上下文——明确告诉 Claude 它扮演什么角色、处于什么场景、需要完成什么目标，这是一切提示词的起点。

与此紧密相关的是语气设定：要求模型基于事实作答，有把握才说，不确定时不猜测，从源头降低错误风险。

在信息组织上，将固定不变的背景数据放入系统提示，并用 XML 标签加以结构化，可以让上下文清晰、可复用。

进一步地，详细指令应当分步骤引导 Claude 的推理过程，明确指定分析顺序，避免模型自由发挥走偏。

当规则难以用语言穷举时，Few-Shot 示范例子是最有效的补充——用真实案例教会模型如何正确判断，尤其是那些规则模糊的"灰色地带"。

对于对话式应用，还需要将对话历史纳入系统提示，确保模型始终持有完整语境。

在可靠性保障方面，防幻觉提醒要求模型引用依据、不确定时主动声明，而非编造答案。

输出格式化则通过 XML 标签或 JSON 结构约束返回内容，方便下游系统直接使用。

最后两项进阶技巧：在 API 中通过预填充响应预设回复开头，可强制模型按指定格式输出；

而扩展思考（Extended Thinking）则能让你看到 Claude 完整的推理链路，用于分析和调优复杂任务的判断过程。

原文：https://x.com/ai_rohitt/status/2064943347215839454

-END-