上线不是终点，第一周决定"能不能活下去"
AI 功能上线后第一周，最容易出的事不是效果差，而是：成本失控、延迟飙升、坏输入打崩、
以及"没人知道它到底在发生什么"。所以第一周要盯指标，而不是盯好评。
上线前就准备好的四件事
- 埋点：请求 id、模型与提示词版本、耗时（首字与总时长）、成败、校验失败原因、成本（见"埋点"那篇）；
- 护栏：限流、配额、超时、最大输入长度、最大输出长度；
- 降级链：上游不可用时按"重试→小模型→规则兜底→明确不可用"逐层退（见"降级设计"那篇）；
- 回滚开关：能一键关掉或切回旧版本/旧模型 —— 没有回滚开关就不要全量上线。
第一周每天看什么
当天（高频）
- 错误率与失败类型分布（格式错 / 超时 / 校验拒绝 / 上游 5xx）；
- P95 延迟（首字与总时长分开）；
- 降级触发次数与原因；
- 成本曲线（当日花费、单次均价）。
每天（固定时间）
- 负反馈与人工介入样本（抽 10 条看原文，不要只看比例）；
- 坏的"最贵请求"Top 10（哪类输入最烧钱）；
- 被拒绝的输入样例（可能是规则写太紧，把正常请求挡了）。
三个典型事故与对应防线
| 事故 | 防线 |
|---|---|
| 某租户脚本刷接口，成本当天翻倍 | 租户配额 + 限流 + 成本告警 |
| 某类超长输入让 P95 从 2s 变 30s | 输入长度上限 + 超时 + 排队可见 |
| 上游抖动导致大面积失败 | 重试 + 降级链 + 明确不可用提示 |
第一周结束时要能回答
- 谁在用（入口、频次、留存）；
- 效果如何（成功率、负反馈率、失败类型）；
- 花了多少（单位成本、最贵的功能与租户）；
- 出过什么事（每次事故的原因与已加的防线）；
- 下一步做什么（按数据，而不是按感觉）。
一个反面清单（别做这些）
- 上线即全量、无回滚开关；
- 只看"好评率"，不看失败类型；
- 成本不设告警，月末才发现；
- 出了事故只改文案，不加防线。