模块 10 — 动手实验：生产化你的 Claude 应用

目标：把模块 10 的六个面（环境/密钥、可观测性、故障处理、权衡、升级、参考架构）各做一遍最小实操。全部实验不需要 API key——示例脚本用模拟上游离线运行。预计 90–120 分钟。

Lab 0：环境准备（无需 key）

🎯 学习重点：先以退出码和断言建立两个离线脚本的可重复基线。

cd claude-architect-study/10-production/examples
python3 01_resilient_call_orchestrator.py    # 应打印 7 个场景 + 全部断言通过
python3 02_cost_latency_estimator.py         # 应打印 3 个 workload 对比 + 手工核算

✅ 检查点：两个脚本退出码为 0；01 脚本末行含「全部断言通过」。

Lab 1：故障处置演练（重试/熔断/降级/升级）

🎯 学习重点：通过改重试次数与超时预算，观察瞬时错误如何转入降级或升级路径。

无需 key（模拟上游）。

1. 阅读 01_resilient_call_orchestrator.py，找到 classify() 方法——对照 README 10.3.1 的错误处置表，确认四种分类（spend_cap / rate_limit / transient / permanent）的依据
2. 修改 run_scenario 新增一个场景：504 timeout_error 出现一次后成功。先预测输出（它会被归为哪类、退避多久），再运行验证
3. 把 Orchestrator 的 max_retries 改为 0，重跑场景 1（529 两次后成功），观察行为变化并解释：为什么「关闭重试」会让可用性对瞬时抖动过敏
4. 把 TimeoutBudget 的 total_ms 改成 1,500 重跑场景 5，观察「预算耗尽 → 降级」提前触发——这就是超时预算的意义

✅ 检查点：能用一句话说出「同样是 429，什么时候该重试、什么时候必须停」。

Lab 2：错误分类速查卡（无需 key）

🎯 学习重点：逐码映射处置，尤其准确区分带 retry-after 与 spend-cap 两种 429。

对照官方 errors 文档（https://platform.claude.com/docs/en/api/errors，访问于 2026-08-30），手写补全下表（右列先遮住）：

✅ 检查点：与 README 10.3.1 表格逐行核对；两行 429 的区别必须答对。

Lab 3：成本/延迟/可靠性权衡工作台（无需 key）

🎯 学习重点：改变命中率和 workload 参数，用计算结果而不是直觉选择模型、缓存与 batch。

无需 key（价格表截至 2026-08-30 已内置，来源见脚本头注释）。

1. 运行 02_cost_latency_estimator.py，记录三个 workload 的推荐与理由
2. 把场景 A（客服助手）的 cache_hit_rate 从 0.75 改成 0.3，观察推荐成本变化——解释为什么命中率跌一半、缓存收益跌得更多（写入 ×1.25 的未命中部分占比上升）
3. 新增一个 Workload：name="代码评审机器人", 5,000 请求/日, 前缀 12,000 tokens, 动态 6,000 tokens, 输出 2,000 tokens, interactive=False, reliability_need="medium"。先手工预测推荐（哪个模型？缓存开吗？batch 开吗？），再运行验证
4. 打开 Console 的公开定价页对照脚本价格常量，若有出入，改常量并在文件头更新「截至」日期——这就是「易变事实标注」的维护动作

✅ 检查点：能解释场景 B 为什么推荐「Haiku + 缓存 + Batches」而场景 C 推荐「Opus + 缓存 + 实时」。

Lab 4：日志脱敏工作台（无需 key）

🎯 学习重点：证明删除敏感内容后仍能保留 request_id、模型和 token 等可观测字段。

写一个 20 行的 redact.py（或纸面设计）：输入一条模拟日志 JSON（含 user_email、Authorization 头、prompt 原文），输出脱敏后的日志（邮箱→***、凭证→计数、原文→长度+语言标签）。验收标准：

1. 输出里搜索不到任何 @ 符号的邮箱与 Bearer 字样
2. 结构化字段保留（token 计数、模型、request_id）——可观测性不因脱敏而丢失
3. 思考题：如果合规要求「保留可回放的原文」，你会把它存哪、谁能读、存多久？

✅ 检查点：能对照 README 10.2.2 的「该记/不能记」清单逐项自评你的输出。

Lab 5：真实环境的密钥与配置检查（无 key 也可做检查）

🎯 学习重点：盘点配置与凭证生命周期，并设计可回退的新凭证切换顺序。

1. 纸面盘点你（或假想组织）当前的配置分层：模型 ID 写在哪（代码/配置/环境变量）？staging 与 prod 差异由什么承载？
2. 对照三原则打分：密钥是否可能出现在代码库/日志/工单里？有没有轮换流程？有没有按 workspace/key 拆分用量？
3. 若有云环境：查你的平台是否支持 Workload Identity Federation 式的短时效凭证接入（官方指南: https://platform.claude.com/docs/en/manage-claude/authentication，访问于 2026-08-30），列一个迁移三步：新凭证接入 → 流量切换 → 撤销静态 key

✅ 检查点：能说出「静态 key 退役」的完整顺序与每步的回退点。

Lab 6：升级演练 + 灰度设计（无需 key）

🎯 学习重点：所有灰度比例、观察时长、阈值与成本上限都必须有数据或风险依据。

1. 选一个你们（或假想）锁定的模型 ID，查官方 model deprecations 页（https://platform.claude.com/docs/en/about-claude/model-deprecations，访问于 2026-08-30）确认其当前状态
2. 设计升级方案一页纸：golden dataset 规模与来源、staging 回归评估的通过标准、灰度阶梯（起步比例/每档观察指标与时长）、回滚触发条件（哪个指标坏到什么程度切回）、双跑对比的成本上限
3. 把「新模型 F1 下降 1.5pp」代入你的方案，写出前 24 小时的处置时间线

✅ 检查点：方案里每个数字都有理由（为什么 1% 起步、为什么观察 48 小时），而不是拍脑袋。

收尾自测

🎯 学习重点：不查资料完成错误、缓存、熔断、batch、密钥和退役迁移六类生产判断。

做完 6 个 lab 后，你应能不查资料回答（模块 10 验收线）：

1. spend cap 429 与限流 429 的处置差异？
2. cache_control 断点放错位置的后果与修正？
3. 熔断器 open 期间用户请求去哪了？
4. 什么负载该进 Batches？什么绝对不能？
5. 生产上静态 key 的三个替代/治理动作？
6. 模型 deprecated 后 90 天里你的迁移节奏？