上线检查清单:把七章收成一页纸

一、功能与质量(AP2-AP5)

• 有一套正式评测集,50-100 条,含边界样本和"不该答"样本(ap5.1)
• 另有一份保留集,从未参与调优(ap5.1)
• 有基线分数,并已提交进 Git(ap5.5)
• 回归门禁已挂进 CI,分数跌了 exit(1)(ap5.5)
• 结构化输出有校验器,不合格能自动修复或重试(ap3.2)
• 有拒答机制,不确定时能说"不知道"而不是编(ap3.4)
• RAG 的检索质量已单独评测(命中率,不是只看最终回答)(ap4.4)
• 回答带引用,且引用能被自动核验(ap4.6)
• 幻觉率有可测的定义和当前值(ap5.4)

二、成本(AP1、AP6、AP7)

• 每次调用都记进流水:用户、功能、token、缓存命中、成本、延迟(ap1.6)
• 系统提示固定不变,动态内容只加在尾部(前缀缓存的命根子)(ap1.4/ap7.2)
• 知道自己的缓存命中率,并且它在监控里(ap1.4)
• 有每日/每小时成本上限,超了自动降级(ap6.4)
• 建了成本模型:能回答"10 倍用户我付得起吗"(ap7.6)
• 输入长度有上限,防止一次粘贴 10 万字(ap7.1)

三、可靠性(AP1、AP6)

• 错误分类正确:该重试的重试,401/400 直接失败(ap1.1)
• 重试有指数退避和次数上限(ap1.1)
• 有备用通道,主模型挂了能切(ap6.1)
• 有熔断器,主通道连续失败后不再干等(ap6.1)
• 有静态兜底文案,含人工入口——现在就写好,别等故障时现编(ap6.1)
• 备用通道最近验证过(不是一行没跑过的代码)(ap6.1)

四、安全(AP6)

• 外部内容做了标签隔离,系统提示声明"标签内是数据"(ap6.2)
• 输出有链接白名单,非自有域名的链接被剥掉(ap6.2)
• 外部内容不渲染富文本(或已确认渲染是安全的)(ap6.2)
• 危险动作需要人确认,模型只能建议(ap6.2/ap3.4)
• 有一份针对本产品的注入攻击样本集,并纳入门禁(ap6.2)
• 输入侧审核:词表兜红线 + 模型兜语义(ap6.3)
• 输出侧审核:查的是功效宣称和夸大,不只是违禁词(ap6.3)
• 审核有三档(pass / suspect / block),不是只有拦和放(ap6.3)
• 有误伤测试集,确认正常的负面反馈不会被拦(ap6.3)
• 限流 + 日配额 + 成本熔断三层齐备(ap6.4)
• 异常用量告警(超过中位数 N 倍)(ap6.4)
• 日志已脱敏,且脱敏器用样本集测过(顺序和边界!)(ap6.5)
• 第三方监控上报的那份也脱敏了(ap6.5)
• 日志有留存期限,到期自动删除(定时任务 + 监控)(ap6.5)
• 密钥不在代码、不在镜像、不在日志里(ap1.5)

五、合规(AP6)

• 备案/登记的判定已做,理由已写下来;需要办的已排进时间表(ap6.6)
• AI 生成内容有显式标识(界面可见)(ap6.6)
• 导出文件有隐式标识(元数据)(ap6.6)
• 服务协议/隐私政策写明了 AI 使用、数据用途、留存期(ap6.6)
• 有投诉举报入口,且有人处理(ap6.6)
• 功能没有越过资质红线(医疗/法律/金融/自动化决策)(ap6.6)

六、工程与体验(AP7)

• 接口有 request_id,响应和日志能对上(ap7.1)
• 错误码分级:4xx / 429 / 502 / 500,异常细节不外泄(ap7.1)
• 并发压过,中位等待可接受(ap7.1)
• 流式的空窗期有反馈,有停止按钮,中断能恢复(ap7.3)
• curl -N 验证过公网流式真的是流式(ap7.6)
• 日志区分 ok 和 business_ok(ap7.4)
• 有 P50/P95/P99,告警阈值基于自己的基线(ap7.4)
• 四个告警已配并演练过:业务成功率、P95、成本、降级率(ap7.4)
• 灰度用稳定哈希分流,日志有 variant 字段(ap7.5)
• kill_switch 存在且演练过,回滚在 1 分钟内生效(ap7.5)
• 提示词、模型、检索索引三者一起版本化(ap7.5)

上线当天:一份操作手册

两条纪律:

1. 别在周五下午或下班前发布。出问题的时候你需要人、需要时间。
2. 发布和回滚都必须是"一个人 5 分钟内能独立完成"的操作。如果回滚需要三个人协作 20 分钟,那你等于没有回滚。

上线后 72 小时:盯这六件事

头 72 小时的每一条真实失败样本都是金子——当天就把它们捞进评测集(ap5.6),而不是等"以后有空"。

🔧 动手做:过一遍清单(30 分钟)

1. 把这 41 条复制进你的项目(README 或 issue 模板),逐条打勾。
2. 对每一条打不了勾的,写一句"风险是什么"——这一步比打勾更重要。
3. 挑出三条"现在就能补上的",今天补掉。
4. 挑出三条"确实做不了的"(比如备案还在办),写下缓解措施和时间点。
5. 写你的 runbook:发布步骤、回滚步骤、值班联系人——贴在团队群置顶,不是放在没人找得到的文档里。
6. 演练一次回滚,计时。

✅ 做到这里你应该有:一份打过勾的清单 + 已知风险列表 + 一份 runbook + 一次回滚演练的耗时记录。

为什么:🎉 AP7 完结,同时你的产品可以上线了。

这七组 41 条,每一条背后都是本课的一次实测——不是"最佳实践大全",是"这门课亲手撞出来的坑":重试 126 秒换来 0 个成功、一条格式要求穿透最强防线、1 个用户吃掉 85% 账单、正则把身份证脱成手机号、滑动窗口贵了 54%、10 个 200 里 0 个可用、1% 灰度只有 6% 的发现概率。

清单的价值不在于它全,在于它每一条都有过代价。

下一章讲这件事能不能做下去:AP8 增长与商业化——单位经济模型、免费额度设计、定价、留存。

这是本课的通用上线清单:【贴上面 41 条】。我的产品是【描述:功能、用户、数据来源、是否面向公众、是否收费】。请帮我:1) 标出哪些条目对我不适用(说明理由);2) 补充我这类产品特有的检查项;3) 把可自动化的条目挑出来,给出在 CI 里检查它们的脚本思路;4) 为我还做不到的条目,给出缓解措施和优先级;5) 生成一份适合我团队的发布 runbook(含回滚步骤和值班分工)。