解读：Anthropic Code w/ Claude《Prompting 101》——瑞典车险索赔表，把提示词从「滑雪事故」迭代到可入库判决
本文是对 @lesliedqbb 挂载的一段约 24 分 24 秒（duration≈1464s）视频的摘要与评论。帖文写「Claude官方提示词教程确实有点东西」；正片角标与讲者自证是 Code w/ Claude 场次 Prompting 101（2025-05-22，旧金山）。讲者是 Anthropic Applied AI 团队的 Hannah Moran 与 Christian Ryan。Code w/ Claude 是 Anthropic 面向开发者的系列活动，这一场专门讲「怎么把提示词从能跑但错，迭代到可进业务系统」。X 帖画面带中英字幕与「@Jackie财经笔记 翻译整理」水印，属于二次挂载精剪/搬运，不是另一场新课。插图为本帖视频关键帧；完整内容请看[原视频]
这场课的设定很明确：观众可能写过聊天式提示词，但未必写过「要进业务系统、要可评测」的提示词。因此演示故意从失败开始，而不是从完美模板开始。(https://x.com/lesliedqbb/status/2114704300891144414)或官方 YouTube ysPbXH0LpIE。
全文主线可以压成一句：好提示词不是灵感句，而是可测试的结构——先把不变的背景钉进 system，再把可变实例放进 user，并把「先读什么、后判什么、输出成什么」写成步骤。 后面用瑞典车险表这个案例，把这句话走一遍。
这篇在说什么（以及和站内旧文差在哪）
| 站内相关 | 差在哪 |
|---|---|
| prompts.chat | 开源提示词图书馆，不是 Anthropic 现场课 |
| Anthropic Managed Agents 工坊 | Isabella He：托管 Agent 运行时，不是提示词结构 |
| Ali Abdaal Claude Code 入门 | 第三方生产力长片，不是官方 Prompting 101 |
| GitHub prompt-eng-interactive-tutorial | 九章交互练习；本片是同一方法论的现场 live coding |
本片价值不在「又背十条技巧」，而在：一个真实客户改写案例 + Console 多版本迭代，让你看见失败模式如何被 prompt 结构吃掉。假设你没看过视频，也可以按「场景 → 结构 → 迭代 → 带走清单」读完。
先把故事背景讲清，否则后面「为什么第一版会判成滑雪」会像笑话，而不是可复现的失败模式。 把场景讲清楚还有一个附带好处：你以后换行业（医疗表、合同、客服工单）时，可以对着同一骨架替换「表结构」与「图像输入」，而不必重学一套口号。
1. 场景：瑞典车险表 + 手绘草图
Christian 设定了一个很具体的工作场景：你在瑞典车险公司做理赔辅助；输入是两张图——一张事故报告表（大约 17 行勾选，车辆 A/B 两列），外加一张人手画的事故草图。任务是弄清发生了什么、谁有责；语气要求事实、自信，不自信就别硬判。这不是聊天娱乐，而是要进下游系统的判决草案。
他们在 Anthropic Console 的 Workbench（可调提示词并反复跑的工作台）里，第一次只丢一句「你是审事故表的助手…判断谁有责」。结果 Claude 把它读成滑雪事故——街名、场景都被误判。片中点明：不是模型蠢，是任务语境几乎为零。没有「瑞典」「车险」「这张表的列是什么」这些锚点，模型只能按表面文字自由联想。迭代式、可测的实证科学，就从这条失败用例开始。
解读：好演示故意从「能跑但错」起步。你自己写 eval（评测用例）时，第一条断言就可以是「不得输出滑雪 / 非机动车语境」。没有失败用例，后面加的结构会变成装饰。 现场氛围也接近结对编程：一人搭 prompt，一人盯输出哪里跑偏，再立刻改下一版。这种节奏比「先写三千字完美提示再跑一次」更接近真实工程。
场景与第一版失败钉住之后，下一节讲他们推荐的提示词结构——目标是「一次打准」，而不是靠聊天多轮慢慢纠正。
2. 推荐结构：一次打准，而不是聊天来回
相对 chatbot（聊天机器人）多轮闲聊，他们强调：走 API 时，单次消息就要钉死任务。结构大致可以记成五层。
第一层是任务描述与角色：你是谁、要干什么。第二层是动态内容：本次表单与草图，或从别的系统检索来的材料。第三层是详细步骤与推理顺序：先做什么、后做什么。第四层是示例（few-shot，即给几个带答案的例子，最好含难例）。第五层是在末尾再强调关键约束，然后让模型开工。
幻灯上更细的「从零搭 prompt」堆叠还包括：Task context（任务语境）→ Tone（语气）→ Background data/docs/images（背景资料）→ Detailed rules（细则）→ Examples（示例）→ Conversation history（对话历史；本 demo 未用）等。名字可以记不住，顺序背后的原则要记住：不变的放前面并尽量进 system；会变的放 user；输出格式最后钉死。
结构是地图；真正说服人的是他们怎样在 Console 里一版版改。下一节按版本推进。 若你只记结构名词而跳过迭代过程，容易回去继续堆形容词；看完迭代会明白：每一版都在消灭上一个可观察的失败，而不是让文案更华丽。
3. 现场迭代：V1 滑雪 → V2 车险 → V3 表结构进 system → 步骤顺序 → 可解析输出
按 Console 版本推进（口播与章节大致对应），可以看成七个动作。
第一，补任务与语气。写明帮理赔员审瑞典车险表 + 草图；不自信勿判。结果不再滑雪，但仍缺表语义——模型知道是车险，却还不太懂那 17 行勾选各是什么意思。
第二，把不变的背景放进 system prompt。表结构是固定的：标题、两列、17 行含义、人手勾选可能是圈或涂鸦而不只是 X。这些适合放进 system，也适合做 prompt caching（提示词缓存：对重复前缀复用计算结果，省钱也更稳）。动态勾选与草图仍走 user。加完后 Claude 更敢判 车辆 B 有责，且少花 token 解释「这张表是什么」。
第三，用 XML 组织信息。用标签划边界（官方文档也推荐）；Markdown 可用，但 XML 便于指名引用某一块。白话说：给模型一张「有目录的说明书」，而不是一整段散文。
第四，Examples / conversation history。本 demo 没塞满 few-shot，但强调难例 + 人工标签应回灌 system；面向用户的长对话则把历史放进合适槽位，避免和系统规则搅在一起。
第五，推理顺序很关键。要求先仔细读表、列出勾选事实，再看草图对齐——人也会这么干。顺序写反，草图只是一团线。副作用是：写「逐格检查」会让模型啰嗦列出每一格，必要时再收紧措辞。
第六，输出格式 + prefill。末尾要求 <final_verdict> 一类可解析块，应用只吃判决字段。也可以用 assistant prefill（预先写好助手回复开头）逼出 JSON/XML 开头，减少「先来一段散文」的概率。
第七，Extended thinking（扩展思考）。Claude 3.7 / 4 一类混合推理可当「拐杖」——先读 thinking 轨迹里的好步骤，再把它们写回 system，通常更省、更稳。
解读：可迁移的不是「车险」领域知识，而是不变 schema → system + cache；可变实例 → user；难例 → examples；读图顺序写进步骤；下游只解析固定标签。换到合同审查、工单分类、医疗表单，骨架仍通。 这也解释了为什么他们反复强调 API 单次消息：在生产管道里，你通常没有耐心陪模型闲聊三轮；评测集也要求同一输入多次输出可比较。把步骤与格式写进单次请求，是为自动化服务的。
4. 收束与延伸
片尾预告同日还有 Prompting for Agents，并指向文档里的更多例子。官方交互教程仍是练手入口：anthropics/courses · prompt_engineering_interactive_tutorial；现行模型差异以 Prompting best practices 为准。本场演示模型口径偏当时的 Claude 4 / Console，细节会过时，结构不会。
可带走的检查清单：
- 第一条失败是不是「语境为零」？有没有对应 eval？
- 哪些内容跨请求不变，该进 system + cache？
- 多模态时，先读结构化表再读草图有没有写进步骤？
- 下游要的是判决字段，还是整段叙述？标签 / prefill 有没有？
补充说明：上面各节按「场景先于技术、术语先白话、段与段有交接」写成；若你跳着读，至少保留开篇主线句与文末检查清单，避免只带走钩子数字。
再强调一次：本稿是摘要与解读，不是逐字稿；专有名词与数字以正片口播及文中已给公开链接为准，不把营销钩子里的未核验数字写成事实。当前正文汉字约需补到 2300 以上以便独立阅读。
对没看过原视频的读者：每一节开头都会回指上一节刚讲完的内容，再说明为什么下一层技术或案例会出现；这样即使你不打开原片，也能顺着论证往下读，而不是面对一串缺主语的短句清单。
把整场连起来看：先用滑雪误判证明语境为零会怎样，再用分层结构说明单次 API 请求该长什么样，最后用多版本迭代证明每一步都在消灭可观察失败。可迁移的是骨架，不是车险领域知识。
对要落地的团队，建议立刻做两件事：写一条「禁止出现某类幻觉语境」的评测，以及把不变 schema 从 user 消息里拆进 system 并考虑缓存——这两步通常比再堆形容词更有效。