Anthropic 官方课程精读：提示词、工具与评估
快照：2026-08-14课程仓库停更于 2025-11⚠️ 先读这一条：课程的代码已经跑不起来了
anthropics/courses 最后一次提交是 2025-11-13，全部 notebook 使用 claude-3-* 系列模型，而这些型号现已全部退役——直接运行任何一个 notebook 都会返回 404。
但方法论内核依然完全有效。本文的目的正是把两者分开：哪些是可以直接用的思维框架，哪些是必须替换的 API 细节。
一、课程构成
| # | 课程 | 内容 | 本文重点 |
|---|---|---|---|
| 1 | Anthropic API fundamentals | 6 个 notebook：请求、消息格式、模型、参数、流式、视觉 | 消息格式硬约束 |
| 2 | Prompt engineering interactive tutorial | 9 章 + 3 个附录，配套练习与答案 | 核心，第三节 |
| 3 | Real world prompting | 5 个 notebook：把技巧组装成生产级复杂提示词 | 提示词工程生命周期 |
| 4 | Prompt evaluations | 9 课：从手工评估到 promptfoo 自动化 | 核心，第五节 |
| 5 | Tool use | 6 课：工具使用完整工作流 | 核心，第四节 |
官方建议按 1→2→3→4→5 顺序学。课程刻意使用当时最便宜的模型以降低学习成本——这也是它今天全线失效的直接原因。
二、时效性对照总表
这是本文最该先看的部分。左列是课程教的，右列是 2026 年的现状。
2.1 已失效，必须替换
| 课程内容 | 现状 | 当前做法 |
|---|---|---|
全部 claude-3-* 模型 ID | 已退役（详见 2.3） | 换成当前型号，见 多模态 AI 指南 的价格与规格表 |
| Prefill（"替 Claude 说话"） —— 第 5 章核心技巧 | 在 Claude 4.6 及之后的模型上返回 400 | 用 output_config.format（结构化输出）或系统提示词约束格式 |
用 stop_sequences 截断收尾 XML | 与 prefill 配套，同样过时 | 结构化输出天然不需要 |
| 用 tool use "骗" Claude 输出 JSON —— Tool Use 第 3 课 | 当年的巧技，现已被原生能力取代 | output_config.format + JSON Schema；工具侧用 strict: true |
temperature=0 求确定性 | Opus 4.7 起 temperature/top_p/top_k 已移除，传入返回 400 | 用 output_config.effort 控制；确定性靠更严格的提示词与结构化输出 |
"think step by step" / <thinking> 标签指令 | 思考已是模型原生能力 | thinking: {type: "adaptive"} + effort，不要再用提示词模拟 |
2.2 依然有效
| 课程内容 | 说明 |
|---|---|
| 消息格式的硬约束 | 首条必须 user、角色必须交替——协议层规则，未变 |
| XML 标签分隔数据与指令 | 依然是最可靠的结构化提示词手段 |
| Few-shot 示例 | 依然是"知识工作中让模型照做的最有效工具" |
| 给模型"退出通道"、引用先行防幻觉 | 依然有效 |
| 十元素复杂提示词结构 | 依然是复杂提示词的最佳起点（第三节） |
| 工具使用四步循环 | 协议本身没变，是所有 Agent 的基础（第四节） |
tool_choice 三态 | auto / any / tool 仍然可用（另有 none） |
| 整套评估方法论 | 四要素、三种评分、迭代流程——完全没有过时（第五节） |
2.3 课程使用的模型与退役状态
| 模型 ID | 出现次数 | 状态 |
|---|---|---|
claude-3-haiku-20240307 | 85 | 退役日期 2026-04-19，已过期 |
claude-3-sonnet-20240229 | 42 | 已退役（2025-07-21） |
claude-3-5-sonnet-20240620 | 35 | 已退役（2025-10-28） |
claude-3-opus-20240229 | 23 | 已退役（2026-01-05） |
💡 想跑通课程代码
把模型 ID 换成当前型号即可解决大部分问题，但第 5 章和 Tool Use 第 3 课会直接报 400——它们依赖的 prefill 与"工具骗 JSON"两个技巧已被移除或取代。这两课要按 2.1 的替代方案改写，而不是换个型号了事。
三、提示词工程：方法论内核
3.1 消息格式的硬约束
这几条属于协议层，违反即报错，与模型版本无关：
- 首条消息必须是
user角色 user/assistant必须交替- 每条消息必须有
role和content两个字段 max_tokens是硬截断——达到上限会在词中间或句中间停止，不会优雅收尾
系统提示词独立于 messages 数组，用于提供上下文、指令与行为约束。
3.2 七条核心技巧与它们各自解决的问题
课程的九章不是并列的技巧清单，每一条对应一类具体失败模式：
| 技巧 | 解决的失败模式 | 关键细节 |
|---|---|---|
| 清晰直接 | 模型加前言、给多个候选而不下结论 | 判据是「把提示词给同事看，他困惑说明模型也困惑」 |
| 角色扮演 | 语气不对、逻辑任务表现差 | 角色可放系统提示词或用户轮；补充"面向谁说话"效果差异明显 |
| XML 分隔数据与指令 | 模型把用户数据当成指令执行 | 变量替换后人眼可辨的边界，模型未必能辨——必须用标签硬分隔 |
| 指定输出格式 | 输出夹杂多余文字、难以程序化提取 | 让模型把结果放进标签，下游正则提取即可 |
| 逐步思考 | 复杂推理直接给答案就出错 | 思考必须"出声"——要求模型思考却只输出答案，等于没思考 |
| Few-shot 示例 | 语气、格式反复说不清 | 比长篇描述更省事；边界情况的示例尤其重要 |
| 防幻觉 | 编造事实、被干扰信息带偏 | 两招：给"我不知道"的退出通道；先提取引用再作答 |
💡 两条容易被略过但很值钱的观察
- 位置敏感性：模型在两个选项中更倾向选第二个（推测与训练数据中"第二个选项更常正确"有关）。做分类或二选一评估时，要交换选项顺序做对照，否则测的是位置偏好而非能力。
- 问题放文档之后：长文档场景下，把问题放在文档后面效果更好。课程正文为了可读性把问题放在了前面，但明确注明这是反例。
3.3 十元素复杂提示词结构
这是第 9 章的核心产出，也是整套课程最可复用的资产。顺序对部分元素是敏感的：
| # | 元素 | 内容 | 位置要求 |
|---|---|---|---|
| 1 | user 角色开场 | 消息数组必须以 user 开头 | 强制 |
| 2 | 任务上下文 | 模型扮演什么角色、总体目标 | 靠前 |
| 3 | 语气上下文 | 需要什么语气 | 靠前，可省略 |
| 4 | 详细任务描述与规则 | 具体任务、必须遵守的规则、"不知道时怎么办" | 中部 |
| 5 | 示例 | 至少一个理想回答，用 <example> 包裹 | 中部 |
| 6 | 输入数据 | 待处理的数据，各自用 XML 标签包裹 | 灵活 |
| 7 | 即时任务描述 | 重申此刻要做什么 | 靠后——长提示词里放开头效果差 |
| 8 | 逐步思考 | "先思考再回答" | 紧跟元素 7 之后 |
| 9 | 输出格式 | 结果放进什么标签 | 靠后 |
| 10 | ⚠️ 已失效，见 2.1 |
⚠️ 用法建议与原文一致
不是每个提示词都需要全部十个元素。推荐做法是先堆满让它跑通，再逐步删减——而不是一开始就追求精简。
同时注意「用户问题放靠近底部」这条：它与 3.2 的位置敏感性是同一个规律的两面。
四、工具使用：四步契约
4.1 循环本身
这是所有 Agent 的基础协议，至今未变：
| 步骤 | 谁做 | 关键点 |
|---|---|---|
| 1 | 你 | 定义工具的 name、description、input_schema |
| 2 | 模型 | 响应的 stop_reason 为 tool_use 即表示要调工具 |
| 3 | 你 | 提取工具名与入参、在客户端执行、把结果作为 tool_result 内容块回传 |
| 4 | 模型 | 用工具结果组织最终回答 |
第 3 步是客户端责任——模型只是"请求"调用，从不自己执行。这条区分是理解一切工具使用的前提。
4.2 tool_choice 三态
| 取值 | 行为 | 用途 |
|---|---|---|
auto | 模型自行决定是否调工具（默认） | 通用场景 |
any | 必须调用某个工具，但不指定哪个 | 确保有工具介入 |
tool | 强制调用指定工具 | 强制结构化输出的老办法 |
💡 auto 模式下提示词质量决定一切
课程明确指出：模型常常过度热衷调用工具。用 auto 时必须在系统提示词里写清"什么时候该调、什么时候不该调"，否则简单问题也会触发工具。
这与当前模型的表现方向相反——较新的模型反而倾向少调工具，需要在工具 description 里写明触发条件。方向变了，但"提示词决定触发率"这条规律没变。
4.3 工具定义的设计要点
description是模型判断"何时调用"的主要依据，要写足input_schema用 JSON Schema 描述，参数也要写 description- 固定取值用
enum，让参数自带语义 - 工具数量要克制，边界清晰不重叠
4.4 结构化输出：今昔对比
课程 Tool Use 第 3 课教的是一个巧技：定义一个工具来描述想要的 JSON 结构，然后强制模型"调用"它——但根本不实现这个工具，纯粹借用工具调用的结构化格式。
这个思路在当年很聪明。现在它已被原生能力取代：
| 需求 | 课程做法 | 当前做法 |
|---|---|---|
| 强制 JSON 输出 | 定义假工具 + tool_choice: tool | output_config: {format: {type: "json_schema", schema: ...}} |
| 保证工具参数合法 | 靠提示词 | 工具定义加 strict: true |
理解旧做法仍有价值——它解释了为什么工具调用与结构化输出在底层是同一件事。
五、评估：把提示词从艺术变成科学
这门课是五门里最没有过时的，因为它讲的几乎全是方法论。
5.1 为什么要做评估
课程引用了内部团队的两句话，值得记住：
团队无法衡量模型表现，是 LLM 生产落地的最大阻碍，也让提示词工程沦为艺术而非科学。
评估很花时间，但前期做好会节省后续大量开发时间，产品也能更早上线。
评估带来四类具体收益：版本比较（v2 是否真比 v1 好）、回归检测（改动是否导致退步）、模型比较（能否换新模型）、降本验证（能否换更便宜的模型而不掉点）。
5.2 一条评估的四要素
| 要素 | 说明 |
|---|---|
| 示例输入 | 必须能代表真实场景会遇到的输入 |
| 标准答案（Golden Answer） | 理想输出；高质量标准答案往往需要领域专家参与 |
| 模型输出 | 实际生成的内容 |
| 分数 | 量化或定性的评价值 |
推荐至少 100 组测试用例。课程为控制学习成本用了远少于此的数量，并明确注明这是妥协。
5.3 三种评分方式的选择
| 方式 | 适合 | 优势 | 代价 |
|---|---|---|---|
| 人工评分 | 语气、创造性、专家领域事实性 | 细腻判断的黄金标准 | 慢、贵、评分者之间不一致 |
| 代码评分 | 有客观判据的任务 | 快、可规模化、结果一致 | 只能处理可程序化判断的输出 |
| 模型评分 | 语气、相关性、适龄性等主观维度 | 兼顾细腻与规模 | 有成本；评分提示词本身也需要被评估 |
代码评分的常见形式：精确匹配、关键词命中、正则匹配、数值比较。
💡 优先级明确
能用代码评分就用代码评分——最简单、最便宜、最一致。只有当判据本身是主观的（语气、适龄、创造性）才升级到模型评分。人工评分留给最需要专家判断的部分，以及为前两种方式建立基准。
5.4 迭代流程
关键在第 3 步的基线分数：没有量化基准，就无法判断改动到底是改进还是退步。
5.5 工具化
课程从手写评估逻辑过渡到 promptfoo（开源），能力覆盖：
- 内置断言：
exact-match、contains-all等 - 自定义代码评分器：写任意 Python/JS 判分逻辑
- 模型评分器：用模型判分，支持自定义评分提示词与多维度打分（如同时评"简洁度 / 准确度 / 语气"各 1–5 分）
- 多模型对照：在
providers里列多个模型，一次评估横向比较 - 结果可视化看板
提到的同类工具还有 Vellum、Scale Evaluation、Prompt Layer、ChainForge。
六、提示词工程生命周期
Real World Prompting 课回答了一个前面几门课没讲的问题：技巧知道了，工作流是什么？
课程对"基础提示"与"提示词工程"的区分很清楚：
| 维度 | 基础提示 | 提示词工程 |
|---|---|---|
| 复杂度 | 单轮、简单查询 | 多轮、复杂指令、结构化输入输出 |
| 精确度 | 可能含糊 → 结果不稳定 | 精确，不留误解空间 |
| 迭代 | 一次性 | 系统性测试、分析、持续改进 |
| 可扩展性 | 一次性场景够用 | 面向生产，能处理各类输入 |
核心区别是可重复性：把交互从随意对话，变成为了稳定解决真实问题而精心编排的过程。
七、笔者判断
这套课程今天的正确用法，是当作方法论手册而非可运行教程：
- 提示词工程课是五门里最耐用的。九章技巧对应九类失败模式，十元素结构至今没有更好的替代品。
- 评估课几乎零过时，而且是最被低估的一门。多数人在"提示词感觉变好了"上浪费时间，评估把它变成可测量的工程问题。
- 工具使用课的四步循环是 Agent 的基础契约，但结构化输出那一课已被原生能力取代。
- API fundamentals 过时最严重，直接看官方文档。
与本知识库其他内容的关系：这套课程是单次调用层面的功夫（怎么写好一个提示词、怎么调一次工具、怎么评估一个提示词）；learn-claude-code 精读 是长时运行系统层面的功夫（循环、压缩、记忆、协作）。两者是上下游关系——harness 造得再好，每一次调用的提示词质量仍然由这套方法论决定。
待验证事项：
- 3.2 提到的"更倾向第二个选项"是基于 Claude 3 时代的观察，当前模型是否仍有此偏好需要实测。
- 4.2 的"过度热衷调工具"在新模型上方向已反转，具体到哪一代发生的变化，课程无从回答。
- 课程仓库停更于 2025-11，是否会更新到新模型没有公开说明。
📚 参考资料
| 资源 | 说明 |
|---|---|
| anthropics/courses | 课程仓库本体 |
| 提示词工程 AWS Workshop 版 | 第 2 门课的 Bedrock 版本 |
| Anthropic 官方文档 | API 细节以此为准，不要以课程为准 |
| 模型总览 | 当前型号、上下文、定价 |
| 结构化输出 | 取代 prefill 与"工具骗 JSON" |
| 工具使用总览 | 四步循环的权威说明 |
| Anthropic Console / Workbench | 人工评估与提示词原型 |
| promptfoo | 评估课使用的开源工具 |
站内相关：Prompt Engineering 完全指南 · AI 评估方法论 · AI Skills 与 Function Calling · Anthropic SDK 核心实战指南
学习履历：本课程收录于 学习笔记 · 在线课程。