模块 05 — 架构师问答题（含 1 道场景决策题）

先自己答，再对照要点。术语保持英文。

Q1. 「prompt 里写了必须输出 JSON」和「结构化输出」差在哪？什么场景必须用后者？

要点：

• 前者是软约束（自然语言指令），存在围栏、缺字段、类型漂移等漏网率；后者是约束解码 (constrained decoding)：schema 编译成文法，非法 token 序列在解码期被禁止，官方承诺 Always valid / Type safe / Reliable。
• 必须用后者的场景：输出直接进数据库/下游服务、跨系统契约、批量处理（Batch 50% 折扣）、无人工兜底的自动化链路。
• 后者不解决的：语义正确性（值可以格式全对但内容错）——那是评估/人审的职责。
• 局限：schema 复杂度限制（20 strict 工具 / 24 可选参数 / 16 union 参数）、不支持递归 schema、与 Citations 不兼容。

Q2. 结构化输出的两个特性分别解决什么问题？什么时候组合使用？

要点：

• JSON outputs（output_config.format）控制 Claude 说什么：最终回复是合法 JSON。
• Strict tool use（strict: true）控制 Claude 怎么调工具：工具名与入参保证过 schema。
• 组合场景：agentic workflow 中需要「工具调用参数可靠 + 最终回复结构化」双保证（如：先调 search_flights 再返回 {summary, next_steps}）。

Q3. 画出并解释「生成 → 校验 → 重试」管线的分支逻辑：哪类错误重试，哪类不重试？

要点（对应 README 2.5 节 Mermaid 图）：

• 格式类（非法 JSON、缺字段、越界枚举）：结构化输出下理论消失；不可用时走「校验失败 → 错误信息拼进 prompt 修复式重问 → 带退避重试」。
• 语义类（值错、编造）：重试无效，进评估管线 / 人工审核 / 降级路径。
• 架构师职责是把错误分类并路由，而不是统一 500。

Q4. 官方对 few-shot 示例的三条要求 + 推荐数量是什么？示例太多/太同构各有什么害处？

要点：Relevant（贴近真实用例）、Diverse（覆盖边界、避免学到意外模式）、Structured（<example>/<examples> 标签）；推荐 3–5 个。太多 → 输入 token 成本上升（应配合 prompt caching）；太同构 → 模型学到示例分布偏差（如答案全是某类标签），泛化差。

Q5. 截至 2026-08-30，extended thinking 的官方状态是什么？存量系统如何迁移？

要点：

• 手动模式（thinking.type: "enabled" + budget_tokens）在 Claude 4.6 弃用（仍可用）、4.7+ 直接 400 拒绝；4.5 及更早模型上它是唯一 thinking 模式。
• 迁移到 adaptive thinking：thinking: {type: "adaptive"} + output_config.effort 控制深度；Fable 5 / Mythos 5 上 thinking 永远开启。
• 遗留规则（跑存量时仍要懂）：budget ≥1024、< max_tokens（interleaved 例外）、预算是目标值非硬顶、>32k 建议 Batch、改 budget 会打断 prompt cache、手动模式下最后 assistant 回合须以 thinking 块开头。

Q6. 什么是 interleaved thinking？它为什么对 agent 系统重要？

要点：让 Claude 在同一回合的工具调用之间插入思考块（先消化 tool result 再决定下一步），而不是只在回合开头想一次。对 agent loop 至关重要：每次工具返回后的观察 (observation) 都能被消化后再规划 (planning)。截至 2026-08-30：旧模型需 beta header；Opus 4.6 手动模式无 interleaved（须 adaptive）；Haiku 4.5 不支持。

场景决策题（Scenario Decision）

S1. 工单抽取系统选格式保证方案

Scenario：你在为一家电商构建客服工单自动分派系统。Claude 从用户邮件抽取 {topic, severity, product_line} 写入工单系统，后者要求 severity ∈ {low, medium, high, urgent}，任何脏数据都会导致分派引擎崩溃。日均 5 万封邮件，预算敏感。

Constraints：

• 下游对 schema 违规零容忍
• 延迟不敏感（可批量），成本敏感
• 邮件中偶尔混有用户粘贴的恶意指令（prompt injection 面）

Options：

• A. prompt 里贴 JSON 格式说明 + few-shot，裸 json.loads 入库
• B. 结构化输出 output_config.format（json_schema）+ enum + 下游归一化，配合 Batch API
• C. 训练一个小分类模型替代 LLM 抽取
• D. 结构化输出 + 每封邮件人工抽查 10%

Best choice: B

Why: schema 硬保证消灭格式/枚举类违规（零容忍的唯一可靠手段）；enum 限定取值域；Batch API 拿 50% 折扣对冲日均 5 万的成本压力；<email> 标签隔离用户内容缩小注入面。

Why others are weaker:

• A：软约束有漏网率，围栏/缺字段/枚举漂移都会打进下游导致崩溃。
• C：topic 是开放文本，小分类模型覆盖不了长尾新主题；维护成本转移而非消除。
• D：10% 抽查无法阻止 90% 的脏数据进分派引擎——质检不能替代防线。

Tradeoffs: B 依赖模型/平台支持结构化输出；schema 复杂度受限；enum 大小写需归一化；Batch 引入最长 24h 延迟（此处可接受）。

What would change the answer: 若 severity 之外还需「按任意用户自定义字段抽取」（schema 动态、可能递归）→ 结构化输出不支持递归 schema，需拆两步（先抽取字段名列表，再逐字段抽取）。若要求实时（<2s）响应 → 放弃 Batch，接受全价。