两个字将在整个领域中拯救你：明确。 "保守一些"不会提高精确度。"只报告高置信度的发现"不会减少误报。有效的做法是精确定义哪些问题要报告、哪些要跳过，并为每个严重级别提供具体的代码示例。
01 显式标准
核心原则
具体的分类标准完胜模糊的置信度指令。
| 方式 | 结果 |
|---|---|
| "保守一些" | 过滤不一致 |
| "只报告高置信度的发现" | 每次应用的阈值都不同 |
| "仅在声明的行为与实际代码行为矛盾时标记。报告 Bug 和安全漏洞。跳过次要的样式偏好。" | 一致、精确的输出 |
误报信任问题
某个类别的高误报率会摧毁对 所有 类别的信任。开发者会完全停止阅读你的发现。
修复： 在改进这些类别的提示时，暂时禁用高误报类别。这在你迭代问题区域的同时恢复信任。
严重度校准
用 具体的代码示例 定义每个级别的显式严重度标准。不是文字描述。而是展示"严重"和"轻微"各自什么样的实际代码。
严重：通过未清洁的用户输入造成 SQL 注入
connection.execute(f"SELECT * FROM users WHERE id = {user_input}")
轻微：未使用的 import 语句
import os # 从未引用
02 少样本提示
少样本示例是 实现一致性最有效的技术。 不是更多指令。不是置信度阈值。是示例。
何时使用
- 详细指令仍产生不一致的格式
- 模型在歧义情况下做出不一致的判断
- 提取任务对文档中存在的信息产生空值/null 字段
如何构建
使用 2-4 个针对歧义场景的示例。每个示例必须展示 推理过程 — 为什么选择了一个操作而非合理的替代方案。这教会泛化到新模式，而不仅仅是匹配预设案例。
示例 1：
输入："函数在出错时返回 null"
分类：Bug（不是样式）
推理：无错误上下文的 null 返回违反了项目的
错误处理契约。这是正确性问题，不是样式偏好。
示例 2：
输入："3 行 lambda 中的变量命名为 'x'"
分类：跳过（样式偏好）
推理：短 lambda 中的短变量名是惯用写法。
标记这个只会产生噪音。
减少幻觉
展示正确处理各种文档结构（行内引用 vs 参考文献、叙述 vs 结构化表格）的少样本示例，能显著提高提取质量。
03 使用 tool_use 的结构化输出
可靠性层级
| 方法 | 语法错误 | 语义错误 |
|---|---|---|
tool_use 配合 JSON Schema | 完全消除 | 仍然可能 |
| 基于提示的 JSON | 可能出现 | 仍然可能 |
tool_use 完全消除语法错误。但不能防止：
- 语义错误： 行项目总和与声明的总计不符
- 字段错位： 值放在错误的字段中
- 捏造： 当源文档缺少信息时，模型为必填字段编造值
tool_choice 配置
| 设置 | 行为 | 用例 |
|---|---|---|
"auto" | 模型可能返回文本而非工具调用 | 默认操作 |
"any" | 必须调用工具，自行选择 | 未知文档类型的保证结构化输出 |
{"type": "tool", "name": "..."} | 必须调用此特定工具 | 强制执行必要的第一步 |
防止捏造的 Schema 设计
| 技术 | 用途 |
|---|---|
| 可选/可空字段 | 当源数据可能不包含信息时。防止捏造。 |
| "unclear" 枚举值 | 用于歧义情况 |
| "other" + 自由文本详情 | 用于可扩展的分类 |
| 格式规范化规则 | 与严格 schema 一起放在提示中 |
04 验证-重试循环
带错误反馈的重试
发送回：原始文档 + 失败的提取 + 具体的验证错误。模型使用错误进行自我纠正。
重试何时有效（何时无效）
| 有效 | 无效 |
|---|---|
| 格式不匹配 | 源文档中确实不存在的信息 |
| 结构输出错误 | |
| 值放错位置 |
考试同时呈现两种场景。你必须识别哪种可通过重试修复。
自我纠正模式
detected_pattern字段： 追踪哪个代码结构触发了发现。支持分析开发者忽略模式。随时间改进提示。calculated_total与stated_total并列： 自动标记差异。conflict_detected布尔值： 用于不一致的源数据。
练习场景
提取工具产出的 JSON 中，行项目总计为 $1,247.83，但 stated_total 字段显示 $1,347.83。验证-重试循环捕获此问题：它将带有具体差异的提取结果发送回去，模型通过重新阅读源文档进行自我纠正。
05 批处理
Message Batches API 约束
| 特性 | 详情 |
|---|---|
| 成本节省 | 50% |
| 处理窗口 | 最多 24 小时 |
| 延迟 SLA | 无 |
| 多轮工具调用 | 不支持 |
| 请求关联 | custom_id 字段 |
匹配规则
| API | 适用于 |
|---|---|
| 同步 | 阻塞工作流 — 合并前检查、开发者等待的任何事项 |
| 批处理 | 延迟容忍 — 隔夜报告、每周审计、夜间测试生成 |
考试呈现一位经理提议对所有流程使用批处理。正确答案是保持阻塞工作流使用同步 API。
批处理失败处理
- 通过
custom_id识别失败文档 - 仅重新提交失败的文档，附带修改（如对超大文档进行分块）
- 在批处理前先在样本集上优化提示，最大化首次通过成功率
06 多实例审查
自我审查的局限性
在同一会话中审查自己输出的模型保留了推理上下文。它不太可能质疑自己的决策。没有先前上下文的独立实例能捕获更多细微问题。
多遍架构
| 遍次 | 用途 |
|---|---|
| 逐文件本地分析 | 每个文件保持一致的深度 |
| 跨文件集成遍次 | 捕获跨文件的数据流问题 |
这防止了注意力稀释和矛盾的发现。
基于置信度的路由
- 模型为每个发现自报置信度
- 将低置信度发现路由到人工审查
- 使用标注的验证集（真值数据）校准置信度阈值
- 将有限的审查人员精力优先分配给最高不确定性的项目
07 动手构建
创建一个提取管道：
- 定义带有全面 JSON Schema 的工具（必填、可选、可空字段，带 "other" 的枚举）
- 实现验证-重试循环
- 处理 10 个不同格式的文档
- 添加少样本示例，比较添加前后的提取质量
- 通过 Message Batches API 运行批处理
- 按
custom_id处理失败