第6章：提示工程——高级技巧

文档：提示工程 | Anthropic Cookbook

6.1 少样本提示

少样本提示是在提示中包含2–4个输入/输出示例，以演示预期行为。

为什么少样本比文字描述更有效：

• "更精确"之类的模糊指令可以有多种解读方式
• 示例能明确展示预期格式和决策逻辑
• 模型将模式泛化到新情况（而不仅仅是重复示例）

少样本示例的类型及使用时机：

1. 针对模糊场景的示例：

请求："我的订单坏了"
动作：调用 get_customer -> lookup_order -> check status。
理由："坏了"可能指商品损坏；需要订单详情。

请求："帮我找个经理"
动作：立即调用 escalate_to_human。
理由：客户明确要求人工服务。不要尝试自主解决。

2. 针对输出格式的示例：

发现示例：
{
  "location": "src/auth/login.ts:42",
  "issue": "用户名参数中存在SQL注入",
  "severity": "critical",
  "suggested_fix": "使用参数化查询"
}

3. 区分可接受代码与问题代码的示例：

// 可接受（不标记）：
const items = data.filter(x => x.active);

// 问题（标记）：
const items = data.filter(x => x.active == true); // 使用严格相等 ===

4. 从不同文档格式中提取的示例：

带内联引用的文档：
"如研究所示（Smith, 2023），比率为42%。"
-> {"value": "42%", "source": "Smith, 2023", "type": "inline_citation"}

带参考书目引用的文档：
"比率为42%。[1]"
-> {"value": "42%", "source": "reference_1", "type": "bibliography"}

5. 非正式计量的示例：

文本："大约两把米"
-> {"amount": "~100g", "original_text": "两把", "precision": "approximate"}

文本："一撮盐"
-> {"amount": "~1g", "original_text": "一撮", "precision": "approximate"}

少样本对于提取非正式和非标准计量单位尤其有效，因为这些单位种类繁多，纯粹基于规则的指令难以覆盖。

提示中的格式规范化规则： 当使用严格的JSON模式进行结构化输出时，在提示中添加规范化规则：

规范化：
- 日期：始终使用ISO 8601（YYYY-MM-DD）；"昨天" -> 计算绝对日期
- 货币：数字金额+货币代码；"五块钱" -> {"amount": 5, "currency": "CNY"}
- 百分比：小数形式；"一半" -> 0.5

这可以防止JSON语法有效但值不一致的语义错误。

6.2 明确标准与模糊指令

差（模糊）：

检查代码注释的准确性。
保守一点——只报告高置信度的发现。

好（明确标准）：

仅在以下情况下将注释标记为有问题：
1. 注释描述的行为与实际代码行为相矛盾
2. 注释引用了不存在的函数或变量
3. TODO/FIXME注释所指的bug已在代码中修复

不要标记：
- 仅在风格上过时的注释
- 措辞轻微不准确的注释
- 缺失的注释（这是单独的类别）

用示例定义严重性标准：

严重：用户运行时失败
  示例：处理付款时出现NullPointerException

高：安全漏洞
  示例：SQL注入、XSS、缺少授权检查

中：无即时影响的逻辑bug
  示例：排序错误、差一错误

低：代码质量
  示例：重复代码、小数据量的次优算法

6.3 提示链

提示链将复杂任务分解为一系列聚焦的步骤：

步骤1：分析 auth.ts（仅本地问题）
       -> 输出：auth.ts中的问题列表

步骤2：分析 database.ts（仅本地问题）
       -> 输出：database.ts中的问题列表

步骤3：集成检查（跨文件依赖）
       -> 输出：模块边界处的问题

为什么重要：

• 避免注意力稀释——当模型同时接收太多文件时，可能会遗漏某些文件中的bug，同时对其他文件只进行浅层评论
• 确保每个文件的分析质量一致
• 允许单独分析跨文件交互

何时使用提示链与动态分解：

• 提示链 — 可预测、可重复的任务（代码审查、文件迁移）
• 动态分解 — 开放式调查，子任务在执行过程中才变得清晰

6.4 "访谈"模式

在实施解决方案之前，Claude提出澄清问题：

Claude："在为API实现缓存之前，有几个问题：
1. 您偏好哪种缓存失效策略——TTL还是基于事件？
2. 当缓存不可用时，过时数据是否可以接受？
3. 缓存应该是按用户还是全局的？
4. 预期缓存的数据量是多少？"

何时有用：

• 陌生领域（金融科技、医疗、法律系统）
• 有非显而易见影响的任务（缓存策略、故障模式）
• 存在多种可行方案，最佳选择取决于上下文

6.5 验证与带反馈的重试

当提取的数据验证失败时：

步骤1：从文档中提取数据
步骤2：验证（Pydantic、JSON Schema、业务规则）
步骤3：如果有错误——带上下文重试：
  - 原始文档
  - 之前（错误的）提取结果
  - 具体错误："字段'total' = 150，但 sum(line_items) = 145。请重新检查值。"

重试有效的情况：

• 格式错误（日期格式不正确）
• 结构错误（字段放置位置错误）
• 算术不一致（模型可以重新检查）

重试无效的情况：

• 源文档中不存在该信息
• 所需上下文是外部的（数据在另一个未提供的文档中）

Pydantic作为验证工具： Pydantic是一个用于基于模式的数据验证的Python库。对于考试，关键点是：

• 结构验证： 在从Claude接收JSON后，在代码中检查类型、必填项、枚举约束
• 语义验证： 自定义验证器强制执行业务逻辑（条目总和等于合计；start_date < end_date）
• 验证-重试循环： 在Pydantic验证失败时，构建错误消息并带错误上下文重新提示Claude
• JSON Schema生成： Pydantic模型可以为tool_use生成JSON Schema，提供单一事实来源

6.6 自我纠正

检测内部矛盾的模式：

{
  "stated_total": "$150.00",
  "calculated_total": "$145.00",
  "conflict_detected": true,
  "line_items": [
    {"name": "Widget A", "price": 75.00},
    {"name": "Widget B", "price": 70.00}
  ]
}

模型同时提取声明值和计算值——如果两者不同，conflict_detected允许您处理差异。

---