考点4：提示词工程与结构化输出（20%）

4.1 使用显式标准设计提示词以提高准确性

关键知识：

• 显式标准比模糊指令更有效（例如，"仅在注释与代码矛盾时标记"vs"检查注释准确性"）
• "更保守一点"这样的通用指导比具体的分类标准效果更差
• 误报对开发者信任的影响：某些类别的高误报率会破坏对准确类别的信任

关键技能：

• 定义审查标准：报告什么（错误、安全）vs 忽略什么（次要风格）
• 临时禁用误报率高的类别
• 为每个级别定义带有代码示例的显式严重性标准

4.2 使用少样本提示词提高输出一致性

关键知识：

• 少样本示例是产生格式一致、可操作输出的最有效方法
• 少样本可以演示处理模糊情况的方式（工具选择、测试覆盖缺口）
• 少样本帮助模型泛化到新模式，而不仅仅是重复默认行为
• 少样本可以减少提取任务中的幻觉

关键技能：

• 为模糊场景提供2-4个带有推理说明的针对性示例
• 包含演示输出格式的少样本示例（位置、问题、严重性、建议修复）
• 提供区分可接受代码模式与真实问题的示例
• 提供来自不同结构文档的正确提取示例

4.3 使用 tool_use 和JSON Schema强制结构化输出

关键知识：

• 带有JSON Schema的 tool_use 是保证模式合规输出并消除JSON语法错误的最可靠方式
• 使用 tool_choice: "auto" 模型可以返回文本；使用 "any" 时必须调用工具；强制选择会选择特定工具
• 严格的JSON Schema消除语法错误，但不能防止语义错误（总计不加；值在错误字段中）
• Schema设计：必填vs可选字段；带有"其他"加详情字符串的枚举以实现可扩展性

关键技能：

• 使用JSON Schema定义提取工具并从 tool_use 结果中解析数据
• 当存在多个Schema时，使用 tool_choice: "any" 保证结构化输出
• 强制特定工具调用：tool_choice: {"type": "tool", "name": "extract_metadata"}
• 当来源可能不包含信息时，将字段设为可选/可空，以避免伪造值
• 使用枚举值如 "unclear" 和 "other" 加上详细字段进行可扩展分类

4.4 为提取质量实现验证、重试和反馈循环

关键知识：

• 带错误反馈的重试：在重试提示词中包含具体的验证错误以指导修正
• 当信息根本不存在于来源中时，重试无效
• 反馈循环设计：追踪触发发现的模式（detected_pattern）
• 语义错误（总计不一致）vs 语法错误（由 tool_use 解决）

关键技能：

• 包含原始文档、不正确提取和具体验证错误的后续提示词
• 识别重试何时无效（所需信息只在外部文档中）
• 在发现中包含 detected_pattern 字段以分析误报
• 通过提取 calculated_total 和 stated_total 来设计自我纠正以检测差异

4.5 设计高效的批处理策略

关键知识：

• Message Batches API：节省50%，最长24小时处理窗口，无延迟SLA保证
• 批处理适用于非阻塞任务（隔夜报告、审计），不适用于阻塞任务（合并前检查）
• Batch API不支持单个请求中的多轮工具调用
• custom_id 字段在批次内关联请求/响应

关键技能：

• 对阻塞检查使用同步API；对隔夜/每周工作负载使用Batch API
• 根据SLA需求规划批次提交节奏（例如，对30小时保证使用4小时窗口，含24小时处理）
• 通过重新提交仅失败的文档（由 custom_id 标识）来处理失败
• 在大规模处理之前使用样本迭代优化提示词

4.6 设计多实例和多轮审查架构

关键知识：

• 自我审查的局限性：模型保留其推理上下文，不太可能挑战自己的决策
• 独立审查实例（没有生成上下文）更擅长发现细微问题
• 多轮审查：每文件本地分析加上跨文件集成检查，以避免注意力分散

关键技能：

• 使用第二个独立的Claude实例在没有生成上下文的情况下审查变更
• 将多文件审查拆分为每文件检查加上集成检查，用于跨文件数据流分析
• 使用带有自评置信度的验证检查以校准的方式路由审查

---