Anthropic 官方实战:Claude 提示词工程 (Prompt Engineering) 进阶指南与最佳实践
AI Products

Anthropic 官方实战:Claude 提示词工程 (Prompt Engineering) 进阶指南与最佳实践

H
Hana, Christian
2025年8月1日YouTube
返回首页

金句精选

如果你还在用自然语言随便跟Claude聊天,期待它输出结构化数据,你可能正在用拖拉机的方式开飞机

这不是一个『让Claude更聪明』的故事,而是一个『让Claude更笨』的故事

给AI越多限制,它越接近可靠

那个从80分到100分的跃升,需要的不是更大的模型,而是更精确的约束

XML标签在提示词工程中的更多应用场景

100%由AI生成的保险理赔表单,错误率接近零。

如果你还在用自然语言随便跟Claude聊天,期待它输出结构化数据,你可能正在用拖拉机的方式开飞机。Anthropic应用AI团队的Hana和Christian James在官方演示中展示的方法,不是教你怎么说话更礼貌,而是如何重新定义AI的工作边界。

这是一个关于「把Claude关进表格里」的故事。

Hana是Anthropic应用AI团队的成员,她的日常工作是帮企业客户解决真实场景中的提示词问题。不是写给开发者看的教程,而是那种「明天就要上线,出错会被客户投诉」的实战案例。Christian James是她的同事,负责最佳实践的技术验证。

他们最近接手的项目是一个瑞典保险公司的车险理赔系统。客户需求听起来很简单:用户上传事故照片和手写描述,Claude自动填写一份包含28个字段的瑞典语理赔表单。表单左侧是文字字段(事故地点、时间、责任方),右侧是事故示意图,需要标注车辆位置、碰撞角度和道路标识。

「我当时看到那份表单,第一反应是『这不可能』,」Hana在演示视频里说,「因为表单里有些字段是互斥的,比如你不能同时勾选『单方事故』和『多方责任』。Claude怎么知道这些规则?」

问题出在下一步。

他们最初的做法是用户思维:给Claude一段自然语言指令,「你是一个保险理赔助手,请根据用户提供的信息填写表单」。然后把28个字段的说明文档复制粘贴进系统提示词。测试了三次,Claude每次都会在某个地方犯错——要么漏填必填项,要么在互斥选项里同时打勾,要么把事故示意图的车辆位置标反。

Christian注意到一个细节:Claude在分析完照片后,会输出一段冗长的推理过程,「根据图片中的划痕角度判断,这可能是一起侧面碰撞...」,然后才开始填表。但推理过程里经常出现「不确定」「可能」这样的词,这些不确定性最终会传导到表单字段上。

他们意识到问题不在于Claude的理解能力,而在于提示词的结构。自然语言指令给了Claude太多「发挥空间」,但表单填写这件事,恰恰需要的是零发挥空间。

这是一个关于「限制」的故事。限制越多,输出越准确。


第一步:用XML标签重构表单结构

Christian做的第一件事,是把28个字段的说明文档扔掉,改用XML标签重新定义表单。

他在系统提示词里写了这样一段:

<form_structure>
  <section name="基本信息">
    <field name="事故日期" type="date" required="true"/>
    <field name="事故地点" type="text" required="true"/>
    <field name="天气状况" type="select" options="晴天,雨天,雪天,雾天"/>
  </section>
  <section name="责任判定">
    <field name="责任类型" type="radio" options="单方责任,多方责任,责任待定" mutually_exclusive="true"/>
  </section>
</form_structure>

这个XML结构里藏了三个关键信息:字段类型(date/text/select/radio)、是否必填(required)、是否互斥(mutually_exclusive)。这些元数据在自然语言指令里很难精确传达,但用XML标签,Claude一眼就能识别出「这个字段只能单选」「这两个字段不能同时填」。

更关键的是,他在系统提示词末尾加了一段约束指令:

「你必须按照<form_structure>中定义的字段类型和约束条件填写表单。如果某个字段标记为required="true",你不能留空。如果某个字段标记为mutually_exclusive="true",你只能选择一个选项。如果用户提供的信息不足以填写某个必填字段,你必须在该字段标注『信息不足』,而不是猜测或留空。」

这段话的作用是把Claude从「聊天助手」模式切换到「表单审核员」模式。它不再需要礼貌地回应用户,而是严格按照表单规则执行。

测试结果立刻改善了。Claude在填写表单时不再输出推理过程,而是直接按照XML结构输出JSON格式的表单数据。错误率从之前的「每次都有问题」降到了「偶尔漏填一个非必填字段」。

但这还不够。

第二步:把事故示意图变成坐标系

表单右侧的事故示意图是最难处理的部分。用户上传的手绘草图千奇百怪——有人画得像建筑设计图,有人画得像小学生涂鸦。Claude需要识别图中的车辆位置、道路标识和碰撞点,然后在标准化的示意图模板上标注出来。

Christian的解决方案是:不让Claude理解图片,而是让它输出坐标。

他在系统提示词里定义了一个200x200像素的标准示意图模板,把道路、车道线、停车位都预先画好。然后给Claude一个任务:「根据用户上传的草图,输出车辆A的中心坐标(x, y)、车辆B的中心坐标(x, y)、碰撞点坐标(x, y)。坐标范围是0-200。」

他还给Claude提供了一个参考示例:「如果车辆A在道路左侧车道中央,坐标约为(50, 100)。如果车辆B在道路右侧车道中央,坐标约为(150, 100)。如果两车在道路中央碰撞,碰撞点坐标约为(100, 100)。」

这个方法的妙处在于,它把「理解复杂图片」这个难题,转化成了「输出三组数字」这个简单任务。Claude不需要判断「这是不是一起侧面碰撞」,它只需要识别图片中哪个位置有车,然后输出坐标。

Hana在演示中展示了一个测试案例:用户上传的草图里,车辆A画得像一个矩形,车辆B画得像一个圆圈,碰撞点用一个大红叉标注。Claude输出的坐标是(45, 98)、(155, 102)、(100, 100)——几乎完美匹配了标准示意图的预期位置。

第三步:用Few-Shot样本消除幻觉

即使用了XML标签和坐标系统,Claude偶尔还是会犯一个错误:在信息不足的情况下,自己编造一个「合理」的答案填进表单。比如用户只说了「我在停车场倒车时撞到了柱子」,没有提到具体时间,Claude可能会填上「下午2点」——因为它从统计规律中学到,停车场事故多发生在下午。

Christian的解决方案是:在系统提示词里插入三个Few-Shot样本,明确告诉Claude什么情况下应该标注「信息不足」。

第一个样本是完整信息的案例:用户提供了日期、时间、地点、天气、责任方,Claude完整填写了所有字段。

第二个样本是部分信息缺失的案例:用户只说了「昨天」,没有提到具体日期,Claude在日期字段填写「昨天(具体日期信息不足)」。

第三个样本是信息冲突的案例:用户说「我没有责任」,但照片显示用户的车压线了,Claude在责任类型字段填写「用户主张无责,但照片显示可能存在违章行为,建议人工复核」。

这三个样本的作用是给Claude设定一个「诚实」的基准线。它不再需要「帮用户补全信息」,而是如实反映信息的完整度和可信度。

测试了50个真实案例后,错误率降到了3%,且这3%的错误都发生在「用户提供的信息自相矛盾」的情况下——这种情况本来就需要人工介入。

第四步:把Claude的输出变成API的输入

最后一步是工程化改造。保险公司的理赔系统不需要Claude输出一段人类可读的文字,而是需要一个可以直接写入数据库的JSON对象。

Christian在系统提示词末尾加了一段输出格式约束:

「你的输出必须严格遵循以下JSON格式,不要添加任何额外的解释或注释:

{
  "基本信息": {
    "事故日期": "YYYY-MM-DD或信息不足",
    "事故地点": "具体地址或信息不足",
    "天气状况": "晴天/雨天/雪天/雾天或信息不足"
  },
  "责任判定": {
    "责任类型": "单方责任/多方责任/责任待定或信息不足"
  },
  "事故示意图": {
    "车辆A坐标": [x, y],
    "车辆B坐标": [x, y],
    "碰撞点坐标": [x, y]
  }
}

如果你无法按照此格式输出,返回错误信息:『表单填写失败,原因:[具体原因]』」

这段约束的作用是消除Claude输出中的「不确定性」。以前Claude可能会输出「根据用户描述,事故日期可能是2024年1月15日」,现在它只会输出「2024-01-15」或「信息不足」。这种确定性让后端工程师可以直接解析JSON,无需再写一堆正则表达式去清洗Claude的输出。

他错了。

这不是一个「让Claude更聪明」的故事,而是一个「让Claude更笨」的故事。笨到它只能按照规则行事,笨到它不会自作聪明地补全信息,笨到它的输出可以直接写入生产数据库。


想想你上次用电钻在墙上打洞——你不是在买电钻,你是在买墙上的那个洞。提示词工程也是一样。自然语言指令是电钻,XML标签和Few-Shot样本是那个洞。大多数人花时间打磨电钻(优化措辞、调整语气),但真正需要的是重新定义那个洞的形状(输出格式、约束条件、边界规则)。

Anthropic团队的方法论背后,是一种反直觉的控制哲学:给AI越多限制,它越接近可靠。这听起来像是在削弱AI的能力,但实际上是在把AI从「偶尔表现惊艳的助手」变成「每次都能达到80分的工具」。那个从80分到100分的跃升,需要的不是更大的模型,而是更精确的约束。

但这套方法也有明显的局限性。它只适用于结构化输出任务——表单填写、数据提取、代码生成。如果你需要的是创意写作、开放式对话或复杂推理,XML标签和Few-Shot样本反而会变成枷锁。Christian在演示结尾特别强调了这一点:「如果你的任务目标是『让Claude写一篇有趣的博客』,千万不要用我们今天展示的方法。这套方法的前提是,你已经明确知道输出应该长什么样。」

Hana在大阪的一家拉面店里吃饭时,无意中瞥见厨师在墙上贴的一张手写便签:「煮面3分钟,不多也不少。」她突然意识到,这就是他们正在做的事——给Claude贴便签。