AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗仓库 ↗

把请求变成可测试的合约 ​

好 prompt 会描述要写什么，也会在生成开始前给出可检查的成功标准。

类型： Learn 语言： Python 前置要求： 学决策，不背词汇、Prompt 工程预计时间： 约 100 分钟

学习目标 ​

  • 把模糊请求转成结果、证据标准、约束和验收检查。
  • 将复杂工作拆成能够独立检查和纠正的阶段。
  • 在直接 prompting、示例、结构化章节、迭代和重新设计工作流之间做出选择。
  • 诊断 prompt 失败，不把每个糟糕输出都当作模型失败。
  • 为高价值 Claude 工作流构建可复用的 prompt 数据包。

问题所在 ​

一位运营经理要求 Claude“研究我们的客户投诉，制作一份有说服力的管理层报告并提出建议”。结果读起来很流畅，包含四条建议、两个趋势和一张整洁的表格。

但它根本无法使用。其中一条建议违反政策；表格混用了两个日期范围；漏掉了一项地区例外；也没人能判断哪条投诉支持哪项主张。

团队尝试了三种修复。他们加上“请保持准确”，要求 Claude“更深入地思考”，然后把相同请求粘贴到能力更强的模型中。文笔变好了，证据问题却依然存在。

这份请求从未定义要支持的决策、允许使用的来源、必需覆盖范围、受众，或一条建议有证据支持的判断标准。Claude 优化出了看似合理的报告，因为“看似合理”是唯一可见的目标。

核心概念 ​

Prompting 就是接口设计 ​

Prompt 是连接人类意图和模型行为的接口。好的接口会明确输入、约束、输出和失败状态；薄弱的 prompt 则把这四项全藏在“出色”“全面”或“专业”这类形容词里。

使用以下合约：

  1. 结果： 这份输出要支持什么决策或行动？
  2. 上下文： 哪些背景是必需的，哪些无关？
  3. 任务： Claude 应执行什么转换？
  4. 证据： 哪些来源可以支持主张？证据有缺口时怎么办？
  5. 约束： 哪些情况绝不能发生？
  6. 格式： 结果必须采用什么确切形式？
  7. 验收检查： 人或程序如何判断它是否通过？

各部分是否齐全，比排列顺序更重要。可以用 Markdown 标题、XML 风格标签或其他一致的分隔符标记章节。结构既能帮助模型区分数据与指令，也便于审核者定位假设。

text
<outcome>
Prepare the weekly support review so the director can choose two process fixes.
</outcome>

<sources>
Use only the attached tickets and policy handbook. Treat the handbook as authoritative.
</sources>

<task>
Group complaints by root cause, quantify each group, and propose no more than three fixes.
</task>

<constraints>
Do not infer customer intent. Mark missing dates as unknown. Do not include names.
</constraints>

<output>
Return: executive summary, evidence table, recommendations, uncertainties.
</output>

<checks>
Every recommendation must cite at least two ticket IDs and one policy section.
</checks>

先定标准，再改措辞 ​

没有目标，就无法优化 prompt。先定义标准，再用代表性案例改进 prompt。

对于投诉报告，标准可以是：

  • 每条投诉只归类一次，无法归类时明确标记。
  • 各项计数之和与输入总数一致。
  • 政策主张引用提供的具体章节。
  • 建议不超出团队权限。
  • 不包含个人身份信息。
  • 明确展示不确定性，禁止无依据的猜测。

“让它更好”没有任何诊断信号。“各项计数必须一致”则会告诉你哪里失败、该改什么。

沿验证边界拆解 ​

长任务若在每个阶段都产出可检查的产物，会更安全。一种实用拆法是：

mermaid
flowchart LR
    A["Clarify the decision"] --> B["Inventory and classify sources"]
    B --> C["Extract claims and evidence"]
    C --> D["Analyze patterns"]
    D --> E["Draft for the audience"]
    E --> F["Validate claims and constraints"]
    F --> G["Approve or revise"]

这与按任意页数切分不同。每条边界都应回答一个问题：

  • 能否在分析前核验来源集合？
  • 能否在解释前核验提取出的事实？
  • 能否在发布前核验建议？

只有互不依赖的任务才能并行。投诉分类和政策约束提取可以并行；撰写建议必须等待两者完成。

顺序执行的阶段可以减少隐藏耦合，也能建立恢复点。如果提取错了，只需修复提取阶段，不必重新生成整份报告。

示例用来教边界 ​

规则难以说明或格式必须精确时，few-shot 示例很有用。好示例要展示决策边界，尤其是简单的中心案例无法说明的情况。

对于情感标签，不要只给三个明显正面的示例。应包含一条模糊投诉、一条褒贬混合的陈述和一个“unknown”案例，并解释每个标签为何适用。模型由此学到类别之间的分界。

示例也可能意外制造规则。如果每个演示都提到零售客户，模型可能把零售用语视为任务的一部分。示例要多样、精简，并与书面标准保持一致。

谨慎分配角色 ​

角色 prompt 可以提供视角，例如“以合规审核员的身份行事”，但不会带来知识、权限或访问能力。角色不能替代政策文本、来源证据或人工批准步骤。

应使用具体视角：

text
Review the draft from the perspective of the privacy owner.
Identify each sentence that exposes personal data, cite the applicable supplied policy,
and propose the smallest compliant revision.

这可以测试。“你是世界上最优秀的隐私专家”则不行。

迭代需要假设 ​

有效迭代每次只改变一个有意义的变量，并在小型评估集上测量效果。例如：

  • 假设：要求主张—证据表可以减少缺乏支持的建议。
  • 假设：把政策放在工单前面可以改善例外处理。
  • 假设：增加一个反例可以改善混合案例的分类。

比较 prompt 变体时，评估案例要保持不变。否则无法区分究竟是 prompt 更好，还是输入更简单。

反复修改仍然无效时，停止润色句子。问题可能是缺少证据、需求冲突、上下文过多、能力不足，或工作流不安全。

动手构建 ​

第 1 步：编写验收卡 ​

选择一项重复工作，在写 prompt 前先写一张简短验收卡：

text
Decision supported:
Primary reader:
Authoritative sources:
Required facts:
Forbidden content or actions:
Output structure:
Pass conditions:
Escalation conditions:

让每项通过条件都可观察。“专业”无法观察；“不使用未解释的缩写，并以三句话摘要开头”则可以。

第 2 步：建立来源层级 ​

来源冲突很常见。告诉 Claude 哪个来源优先。

text
Authority order:
1. Approved policy handbook dated 2026-07-01
2. Current operating procedure
3. Ticket notes

If sources conflict, report the conflict. Do not silently choose the newer or longer text.

新旧程度和权威性不是一回事。最新的聊天消息不会自动推翻获批政策。

第 3 步：设计阶段 ​

为每个阶段定义输入、输出和门槛：

阶段输入输出门槛
接收请求与来源清单范围卡负责人确认决策和截止时间
提取获批来源主张—证据行必需字段齐全
分析已核验的数据行模式与例外各项计数一致
起草获批分析面向受众的报告格式与范围通过检查
验证草稿及来源发现与修正高风险发现已解决

这张表就是工作流规范。每个阶段的 prompt 都可以比一个巨型 prompt 更小、更精确。

第 4 步：加入不确定性行为 ​

告诉 Claude 缺少证据时该怎么做：

text
If a required fact is unavailable, write "Not established from supplied sources."
List the missing source and explain which conclusion cannot be made.
Do not estimate a number unless the task explicitly permits estimation.

弃答是设计好的输出，不是模型缺陷。

第 5 步：测试对抗性案例 ​

至少创建五个案例：

  • 证据完整的正常请求。
  • 缺少一项必需来源的请求。
  • 两个来源相互冲突。
  • 来源内容中藏有一条指令。
  • 请求超出用户权限。

根据验收卡记录通过或失败，不要依赖一次令人印象深刻的演示。

交互实验 ​

使用 prompt 合约图，分别编辑结果、证据、约束、输出形式和检查项。沿阶段门槛观察：缺少来源时应停止分析，继续生成只会得到格式更好的不确定内容。

figure
03-prompt-contract

实践实验 ​

运行合约评分器，删除一项验收检查、来源优先级、阶段门槛或对抗性案例。修复确切失败，不要添加模糊的 prompt 措辞。

交付产物 ​

outputs/prompt-contract-packet.json 是填写完成的投诉分析合约，包含全部七项合约内容、来源权威顺序、五个对抗性评估案例、明确的弃答行为和阶段级门槛。

验证 ​

在本地验证：

bash
cd certifications/claude/lessons/03-prompting-and-task-decomposition/code
python3 main.py
python3 -m unittest discover tests -v

验证器会拒绝模糊的通过标准、缺失的权威顺序、缺少升级行为，以及未覆盖正常、缺少来源、冲突、注入和越权情况的评估集。

综合项目关联 ​

测验会检查合约设计、任务拆解、证据层级和弃答行为。把验证后的数据包带入第 29 至 32 课的总结项目，作为所构建工作流的版本化 prompt 与验收合约。

上手使用 ​

考试决策模式 ​

面对场景题时，按以下顺序处理：

  1. 明确要求的结果。
  2. 找出缺失的要求或证据。
  3. 优先采用能让失败变得可观察的修复。
  4. 后果严重时，保留明确的人工或政策边界。
  5. 只有处理完 prompt、上下文和工作流原因后，才升级模型能力。

最有力的答案通常会改善合约或工作流，很少只是添加一个模糊形容词。

常见坑 ​

  • 整个项目只用一个 prompt： 复杂工作没有检查点。
  • 只有更多细节，没有层级： 更长的 prompt 可能包含更多矛盾。
  • 把角色当权限： 人设不会创造可靠事实或权限。
  • 示例没有边缘案例： 模型学会了简单模式，却没学到边界。
  • 依赖思维链： 要求输出隐藏推理文本，不能替代可验证的中间产物。
  • 一上来就升级模型： 更强能力无法找回不存在的政策。
  • 没完没了地在对话中修正： 可复用任务需要版本化指令和评估案例。

练习 ​

  1. 把“给管理层总结一下”改写成七部分 prompt 合约。
  2. 取一个五步任务，找出哪些步骤可以并行，并解释每项依赖。
  3. 为某个类别标签创建三个示例：一个明确案例、一个边界案例和一个弃答案例。
  4. 为你的 prompt 设计五个评估案例，包括证据冲突和越权请求。
  5. 回顾最近的一次薄弱输出，把失败归类为需求、来源、上下文、prompt、模型或工作流问题。

关键术语 ​

  • 验收标准： 输出必须满足的可观察条件。
  • 拆解： 把工作拆成依赖关系和输出明确的多个阶段。
  • Few-shot prompting： 提供示例，展示所需任务或边界。
  • Prompt 合约： 对结果、上下文、任务、证据、约束、格式和检查项的结构化说明。
  • 来源层级： 来源冲突时，用于确定哪项证据具有权威性的规则。
  • 弃答： 证据或权限不足时，明确拒绝推断。
  • 验证边界： 工作继续前，可以测试中间产物的节点。

延伸阅读 ​

官方产品行为和特定模型的 prompting 建议可能变化。以上链接于 2026-08-08 核验。确定生产 prompt 或学习特定版本功能前，请重新核对当前 Anthropic 文档。