模块 2 架构师问答题 — Claude 模型与消息

每题先自己答，再看参考要点。场景题格式：Scenario / Constraints / Options / Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer。

Q1. 客户预算敏感，要求"全用最强模型保证质量"。你的反驳与方案？

参考要点：

• 用价格锚点：Fable 5 输出 $50/MTok 是 Haiku 4.5（$5）的 10x（截至 2026-08-30，来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））
• 质量瓶颈通常在 prompt/检索/工具，不在模型档位；先在低档模型调优，评估集证明不够再升档
• 分层路由：简单意图→Haiku，主力→Sonnet，复杂→Opus/Fable；配缓存与 Batch 进一步压成本
• 何时客户对：低频高价值单次任务（如年度审计分析），质量 > 成本

Q2. 场景题：客服聊天机器人选型

Scenario：面向终端用户的客服聊天，P95 首响应 < 2s，峰值 50 QPS，每轮输入约 4K token（system+检索）、输出 300 token。 Constraints：Start 档限流；成本尽量低；对话多轮（前缀重复率高）。 Options：(a) Fable 5 (b) Opus 5 (c) Sonnet 5 (d) Haiku 4.5 Best choice：Haiku 4.5 + prompt caching + streaming。 Why：Fastest 档延迟 + $1/$5 价格；200K 窗口对 4K 输入绰绰有余；多轮前缀缓存后读取 0.1x 且不占 ITPM；streaming 降 TTFT 满足 2s 感知。 Why others are weaker：Fable/Opus 延迟与价格严重超配；Sonnet 可作质量不够时的第一升档位。 Tradeoffs：复杂投诉/多语言难例质量可能不足——用意图路由把难例升档 Sonnet。 What would change the answer：输入超 200K（塞整本手册）→ 换 1M 窗口模型或（更好）做检索；限流换 Build/Scale 档 → Sonnet 也可行。

Q3. 为什么说 "input_tokens 下降 = 缓存生效"？这个字段到底统计什么？

参考要点：

• input_tokens 只统计最后一个缓存断点之后的 token；总输入 = cache_read + cache_creation + input（来源: https://platform.claude.com/docs/en/build-with-claude/prompt-caching（访问于 2026-08-30））
• 监控上要看四个字段合起来；只盯 input_tokens 会误判"输入变小了"

Q4. stop_reason 处理不当会造成什么生产事故？各举一例。

参考要点：

• max_tokens：被截断的 JSON 直接进下游解析器 → 解析崩；处理：检测截断→提高上限/续写/降级
• tool_use 后追加了 text block：诱发空响应 end_turn（官方"Empty responses"坑，来源: https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons（访问于 2026-08-30））
• refusal 未处理：用户看到无解释的空白
• model_context_window_exceeded：不当错误重试 → 无限循环；应压缩/裁剪后重发

Q5. 多模态工单系统（用户传截图+PDF）怎么控制成本与窗口？

参考要点：

• 图片按 ⌈w/28⌉×⌈h/28⌉ 计费；4.7+ 高分辨率档最多 4784 视觉 token/图（来源: https://platform.claude.com/docs/en/build-with-claude/vision（访问于 2026-08-30））→ 入口先降采样/压缩
• PDF：600 页上限（<1M 窗口时 100 页），密排文档先撞窗口再撞页数（来源: https://platform.claude.com/docs/en/build-with-claude/pdf-support（访问于 2026-08-30））→ 大文档拆分+检索
• 重复附件走 Files API file_id 或缓存，避免每轮重发 base64
• 图片放文本前（官方排版建议）

Q6. 平台迁移决策：直连 Claude API vs Amazon Bedrock/Vertex？

参考要点：

• 直连：最新模型与功能最先可用、Anthropic 计费支持；云平台：IAM/账单整合、既有承诺、合规
• 关键差异（本模块）：退役日程与部分功能可用性由云平台自定（来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））；Bedrock 图片源仅 base64；Microsoft Foundry 不支持 Files API（Azure 部署）
• 决策输入：功能矩阵 + 合规 + 价格，不是纯技术偏好

Q7. 模型退役如何进入企业的变更管理流程？

参考要点：

• 官方承诺 ≥60 天通知（公开发布模型）；退役日期"不早于"（来源: https://platform.claude.com/docs/en/about-claude/model-deprecations（访问于 2026-08-30））
• 盘点：Console Usage Export 按 API key/模型审计存量调用
• 灰度：新模型先过评估集/影子流量（模块 12）；pinned snapshot 保证同 ID 行为稳定，升级是主动决策
• 别忘了参数退役：temperature 在 4.7+ 直接 400——升级检查清单要包含参数面

Q8. streaming 解决什么、不解决什么？

参考要点：

• 解决：感知延迟（TTFT）、长请求的连接稳定性（SDK 用流式防 10 分钟 HTTP 超时，来源: https://platform.claude.com/docs/en/api/errors（访问于 2026-08-30））
• 不解决：总生成时长与 token 成本
• 新增风险面：流中 error 事件（200 后仍可能 529）、未知事件类型的向前兼容、工具参数是 partial JSON 要累积解析