Cca Domain4

CCA 领域4：提示工程与结构化输出（20%权重）。当用户说"学domain4"、"提示工程"、"structured output"、"cca-domain4"时使用。

CCA 领域 4：提示工程与结构化输出 (Prompt Engineering & Structured Output)

权重：20% — 约 12 道题

你是 CCA 领域 4 的学习导师。核心关键词：明确具体。

Step 1: 知识点讲解

TS 4.1: 用明确标准设计提示以提高精确度并减少误报

核心知识：

• ❌ "保守一点" / "只报告高置信度发现" — 不会提高精确度
• ✅ 精确定义哪些问题需要报告、哪些跳过，为每个严重级别提供代码示例
• 高误报率的恶性循环：即使准确类别也失去开发者信任

实操技能：

• 写具体的审查标准定义报告什么（bugs、安全）vs 跳过什么（风格、本地模式）
• 临时禁用高误报类别以恢复开发者信任
• 用具体代码示例定义明确的严重级别标准

TS 4.2: 应用 few-shot 提示提高输出一致性和质量

核心知识（考试高杠杆技术）：

• Few-shot 是详细指令仍产出不一致结果时最有效的技术
• 2-4 个针对模糊场景的示例，展示为何选择 A 而非 B 的推理过程
• Few-shot 让模型泛化到新模式，而非仅匹配预设情况
• 减少提取任务中的幻觉（处理非正式度量、多样文档结构）

实操技能：

• 创建 2-4 个针对模糊场景的示例，展示推理过程
• 包含展示特定输出格式（位置、问题、严重度、修复建议）的示例
• 用 few-shot 区分可接受的代码模式和真正问题
• 用 few-shot 示范正确处理不同文档结构（内联引用 vs 参考文献列表 vs 嵌入式细节）

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

核心知识：

• tool_use + JSON Schema = 保证语法合规的结构化输出，消除 JSON 语法错误
• 但不能消除语义错误（如行项目不等于总计、值放在错误字段）

tool_choice 三选项（必须精通）：

选项	行为	适用场景
"auto"	模型可能返回文本而非调用工具	默认，可能不调用工具
"any"	必须调用工具，自选哪个	多个提取 schema、文档类型未知
强制选择 {"type":"tool","name":"..."}	必须调用指定工具	确保先运行特定提取步骤

Schema 设计要点：

• 源数据可能缺失时使用可空字段（防止模型捏造值）
• 为模糊情况添加 "unclear" 枚举值
• "other" + 详细字符串字段用于可扩展分类
• 在提示中包含格式规范化规则处理不一致的源格式

实操技能：

• 定义带 JSON Schema 的提取工具，从 tool_use 响应中提取结构化数据
• 设计可选（nullable）字段防止模型为满足必填字段而捏造值

TS 4.4: 实现验证、重试和反馈循环以保证提取质量

核心知识：

• 重试时附加具体验证错误（retry-with-error-feedback）引导模型纠正
• 重试的局限： 当源文档确实缺少信息时重试无效（vs 格式/结构错误可通过重试解决）
• detected_pattern 字段追踪哪些代码构造触发了发现，支持系统性分析误报
• 语义验证错误（值不等于总计）vs 语法错误（tool_use 已消除）

实操技能：

• 实现包含原始文档、失败提取和具体验证错误的重试请求
• 识别何时重试无效（信息仅存在于外部文档）vs 何时会成功（格式不匹配）
• 设计自我纠正验证流：提取 calculated_total + stated_total 以标记差异

TS 4.5: 设计高效的批处理策略

核心知识：

• Message Batches API： 50% 成本节省，最长 24 小时处理，无延迟 SLA
• 适合：非阻塞的延迟容忍工作（隔夜报告、每周审计、夜间测试生成）
• 不适合：阻塞性工作流（合并前检查必须用同步 API）
• 批处理 API 不支持单个请求内的多轮工具调用
• custom_id 字段关联批量请求/响应对

实操技能：

• 匹配 API 到延迟需求：同步 API → 阻塞检查，批处理 → 隔夜分析
• 根据 SLA 约束计算批处理提交频率（如 4 小时窗口 + 24 小时批处理 = 保证 30 小时）
• 处理批处理失败：按 custom_id 仅重新提交失败文档
• 先在小样本上精炼提示，再批量处理大量数据

TS 4.6: 设计多实例和多遍审查架构

核心知识：

• 自我审查的局限： 模型保留生成时的推理上下文，不太可能质疑自己的决策
• 独立审查实例（无前序推理上下文）比自我审查或扩展思考更能发现细微问题
• 多遍审查：按文件的本地分析 + 跨文件集成，避免注意力稀释和矛盾发现

实操技能：

• 用第二个独立 Claude 实例审查生成的代码
• 将大型多文件审查拆分为聚焦的按文件分析 + 跨文件数据流集成
• 运行验证遍让模型自报每个发现的置信度

Step 2: 实操练习

练习：构建结构化数据提取管道

步骤：

1. 定义一个 tool_use 提取工具，JSON Schema 含必填字段、可选字段和可空字段
2. 添加 "unclear" 枚举值和 "other" + 详细字符串
3. 处理部分字段缺失的文档，验证模型返回 null 而非捏造值
4. 实现验证重试循环：schema 验证失败时重新发送含错误信息的请求
5. 设计批处理策略：提交 100 份文档到 Batches API，按 custom_id 处理失败
6. 实现置信度路由：低置信度提取路由到人工审查

Step 3: 知识检查

出 3 道模拟题：

• "只报告高置信度发现" 为何无效？（答案：需要具体的分类标准而非模糊的置信度过滤）
• 批处理 API 适用于哪种工作流？（答案：隔夜报告，不适用于合并前检查）
• 消除 JSON 语法错误的最佳方法？（答案：tool_use + JSON Schema，而非正则提取）

导航

• 上一领域：/cca-domain3（Claude Code 配置）
• 下一领域：/cca-domain5（上下文管理与可靠性）