项目期。今日目标：四个模块在 compose 全栈上真实打通，完整链路跑通并准备 D23 答辩演示。D 指挥全场。
- 全链路跑通：用真实 API key 调
/v1/chat/completions → 上游返回 → 计费扣款 → 面板看到余额变化与流水。
- 联调问题当天修复；无法修复的明确降级方案（答辩时说明）。
- 产出：D23 演示脚本 + 全链路演示截图。
- 环境就绪：compose 全栈起，
docker compose ps 三服务 Running。
- B 先行：B 自己把 verify/deduct/admin 用 curl 全测一遍（联调地基）。
- A ↔ B：A 调 B 的 verify/deduct，用真实场景（正确 key/错 key/余额不足/重复请求）。
- A 对上游：A 转发真实练习端点，确认返回与 usage。
- A 对外：完整走一次
/v1/chat/completions（不带 stream 和带 stream 各一次）。
- C ↔ B：面板四页数据正常，充值后余额刷新。
- 端到端：面板充值 → A 调用 → 面板看余额与流水，数字对得上。
- 联调脚本固化：把上述流程写成可重复脚本（D 负责）。
- 先看日志（D5/D8 学的）：每个服务
docker compose logs <svc>。
- 分段定位：客户端 → A → B → 上游，逐跳 curl 看断在哪。
- 4xx 查自己，5xx 查服务（D3 口诀）。
- 状态码速查：401=key 问题、403=权限、404=路由/模型名、429=限流、502/504=A 或上游问题。
| 问题 | 大概率原因 | 处理 |
|---|
| A 调 B 超时 | compose 网络/端口不对 | 用服务名+端口；先 curl B 确认 |
| 模型名 404 | A 透传的 model 上游没有 | 用 D14 实测可调的模型名 |
| 扣费数字对不上 | usage 取值错/单位错 | 统一按"1K tokens"口径核对 |
| 面板看不到流水 | C 读的接口字段名不对 | 对照契约，用 curl 直接验 B 的返回 |
| 全栈起不来 | Dockerfile/compose 依赖顺序 | 看 compose logs，先修依赖 |
| 时段 | 安排 |
|---|
| 09:00-09:20 | 站会 + 联调顺序宣布（D 指挥） |
| 09:20-12:00 | 按流程联调（A↔B → 对外 → C↔B → 端到端） |
| 13:30-16:00 | 修问题 + 端到端全通 + 演示脚本固化 |
| 16:00-17:00 | 全链路演示彩排（按 D23 流程走一遍） |
| 误区 | 正确理解 |
|---|
| 联调=最后大爆炸 | 有顺序：B 先稳 → A↔B → 对外 → C ↔ 端到端 |
| 问题靠猜 | 逐跳 curl + 看日志，分段定位 |
| 只测成功路径 | 错 key/余额不足/重复请求都要过 |
| 跑通就完事 | 固化成可重复脚本，答辩要再跑 |
| D 是打杂的 | D 是指挥 + 集成者，掌握联调顺序 |