第一季《AI 时代 PM 工作流重构》· 第 19 篇 · 第四部分 交付 预估字数：5000
第十八个"不以为然"——
90% 的 PM 上线前只跑核心 case eval。
不是 PM 偷懒。是大多数 PM 以为"核心 case 都通过了，上线应该没问题"——结果上线第三天 DPD 式翻车——核心 eval 通过 ≠ 生产稳定，缺一类 eval 就足以让产品翻车。
读完这一篇你会知道——上线前 PM 必须自己跑一遍完整的 pre-launch eval。5 大类清单一项不漏。
测什么：你的核心能力在 50-200 个真实任务上的通过率。
最低标准：
- 每个核心能力 ≥ 50 case
- 通过率 ≥ 业务定义的上线门槛（如 90%）
- 覆盖正常 case 60% + 边界 case 30% + 对抗 case 10%
怎么跑：
- L1 unit tests（CI 跑）
- L2 完整 eval 集（手工 + LLM judge）
- 详见第 12 篇 Eval 章节模板
测什么：模型在真实负载下的延迟和并发表现。
最低标准：
- P50 延迟 ≤ 业务承诺（如 2s）
- P99/P50 比建议关注（业内通常 2-4 倍，超过 5 倍需排查）——不能只看 P50
- 并发能撑住预期峰值的 2 倍
怎么跑：
- 用 Locust / k6 等压测工具
- 模拟真实流量分布（不是均匀）
- 测 spike 场景（突发 10 倍流量）
测什么：单次调用成本 + 月度预算预估 + 头部 1% 用户消费。
最低标准：
- 单次成本 ≤ PRD 里写的预算
- 月度预算预估 ≤ ARR × 30%
- 头部 1% 用户消费 ≤ 平均的 5 倍（否则需 hard cap）
怎么跑：
- 跑 1000 次调用统计 token 用量分布
- 算月度成本预估
- 配 monthly budget hard cap
测什么：prompt injection / 越狱 / 诱导 / 边界 case 的抗性。
最低标准：
- 50+ 对抗 case
- prompt injection 防护率 ≥ 95%
- jailbreak 抵抗率 ≥ 90%
- 灾难级输出（暴力/色情/违法）必须 100% 拦截
怎么跑：
- 用 PromptArmor / Lakera 等红队工具
- 自己写 20 个最常见的对抗模式
- 找 1-2 个安全工程师 review
测什么：本次发版没有把历史 case 跑坏。
最低标准：
- 历史 case 集通过率不下降
- 哪怕新功能很 sexy，老 case 不能退化
- 退化的 case > 5% → 发版 block
怎么跑：
- 每次发版自动跑 regression eval
- CI 集成
- 退化超过阈值 → 自动 block PR
## Pre-launch Eval Checklist
### Day -7：跑核心 eval
[ ] L1 unit tests 全通过
[ ] L2 完整 eval 通过率 ≥ X%
[ ] 每个核心能力都达标
### Day -5：跑性能 eval
[ ] P50 延迟 ≤ X ms
[ ] P99 延迟 ≤ X ms
[ ] 并发峰值通过
### Day -3：跑成本 eval
[ ] 单次调用成本 ≤ X 元
[ ] 月度预算预估 ≤ X 元
[ ] hard cap 配置完成
### Day -2：跑对抗 eval
[ ] 50+ 对抗 case 通过率 ≥ 95%
[ ] 灾难级 100% 拦截
[ ] 安全工程师 review 完成
### Day -1：跑回归 eval
[ ] 历史 case 通过率不下降
[ ] 没有退化 > 5% 的 case
### Day 0：上线
[ ] 灰度 5% → 24h 监控
[ ] 灰度 20% → 24h 监控
[ ] 灰度 50% → 24h 监控
[ ] 全量
### Day +7：上线后 review
[ ] 真实流量 vs 预测对比
[ ] 实际成本 vs 预算
[ ] 新发现的 bad case 补进 eval照这个 checklist 走——你能睡着觉。
PM 必须自己跑的：
- 类别 1 核心 case（PM 最懂业务标准）
- 类别 4 对抗 eval 的业务相关部分（PM 最懂场景）
工程师跑的：
- 类别 2 性能（压测）
- 类别 3 成本（token 统计）
- 类别 5 回归（CI 自动）
双方一起 review：
- 类别 4 对抗 eval 的技术部分（prompt injection）
- 最终发版决策
情况 1：核心 case 通过率不达标 → 延期上线，回去改 prompt / 换模型
情况 2：性能不达标 → 降级上线（用便宜模型 + 简化 prompt）或延期
情况 3：成本超预算 → 加 hard cap + 降级方案，可以上线
情况 4：对抗 eval 不达标 → 必须延期——这是合规和公关风险底线
情况 5：回归 eval 退化 > 5% → 必须 fix 才能上线
哪些必须人工？哪些自动化？
- 涉及主观判断（语气 / 风格 / 创意）
- 涉及高风险场景（医疗 / 法律 / 金融）
- 新出现的失败模式（标注后训练 LLM judge）
- 格式校验（JSON schema / 字段类型）
- 事实校验（事实 vs 标准答案）
- 状态校验（任务是否完成）
- 安全过滤（toxicity / bias）
- CI 每次 commit：跑便宜的 code-based grader（成本接近零）
- preview / production 评估阶段：才用 LLM-as-judge（贵但强）
- 人工 eval：留给"对齐 judge"和"边界争议 case"
Maven 课程教的工作流：
- 先人工标 100-200 条
- 训练 LLM judge 与人对齐
- 再放量
最反直觉的一件事——eval 通过了 ≠ 上线就稳。
3 个真实差距案例：
UK 快递公司聊天机器人——pre-launch eval 通过了，但 post-update 没回归 eval。
被英国音乐家 Ashley Beauchamp 调教出脏话和"DPD 是世界最差快递"的诗，单条推文 X 内数百万曝光。
教训：pre-launch eval 通过 ≠ post-update 还稳。每次更新都要重新跑 regression eval。
纽约市政府小企业 chatbot 给出违法经营建议（教用户拿员工小费、歧视特定人群）。
eval 没覆盖"合规正确性"——pre-launch eval 通过了，但 eval 维度根本没包含合规。
教训：eval 维度必须覆盖业务关键 dimension。漏一个维度 = 上线翻车。
bot 错误承诺丧亲折扣可后申请退款，Civil Resolution Tribunal 判航司赔偿 C$650.88。
明确企业不能用"chatbot 是独立法律实体"抗辩。
eval 没覆盖"政策一致性"——bot 编了一条不存在的政策。
教训：RAG / 知识库类产品必须有"事实溯源"维度的 eval。
上线第一周必然会出新 bad case——这是 AI 产品的常态。
PM 必须做的：
- 每天 review 当天的 bad case
- 立刻补进 eval 集（24h 内）
- 下次 release 自动跑回归
- 标"已加 eval"或"待加 eval"
eval 集是活的，不是上线一次性的。
参见第 13 篇 EDD 的核心思想——eval 跟随产品演化。
8 年做软件质量工程的视角——
任何成熟的工业系统上线前都有 5 道保险——功能验证 + 性能验证 + 安全验证 + 容错验证 + 回归验证。
Pre-launch Eval 5 大类正是这 5 道保险的 AI 时代版本——
- 核心 case 覆盖 = 功能验证
- 性能（延迟+并发）= 性能验证
- 对抗（恶意输入）= 安全验证
- 成本 = 容错验证（避免账单失控）
- 回归 = 回归验证
5 道保险任何一道不过 = 上线即翻车。这是 60 年工业可靠性的基本原则。
LLM 圈把这些保险丢了——只是因为"AI 看起来灵活"，让人误以为可以跳过。结果就是 DPD 单条推文数百万曝光 + NYC MyCity 教企业违法 + Air Canada 立判例。
- 每次发版按 5 类逐项跑
- 任何一类不达标 → 暂缓发版
- 不要全部丢给工程师
- 工程师跑你不在场的 case，PM 跑你在场的 case
- 24h 内必须补
- 下次发版自动跑回归
- 月度 review 新增 case
- 每次发版前对照检查
- "我们的 eval 维度覆盖完了吗？"
- "Eval 通过≠生产稳定，DPD 那次更新废掉了 guardrails，单条推文数百万曝光教训免费。"
- "上线前不补 eval，上线后赔的钱够买 10 年 LLM judge。"
- "Air Canada 想用'chatbot 是独立法律实体'抗辩——法院当场打脸：你的 bot 说的话就是你说的话。"
这一篇是交付段（第 16-19 篇）的收尾。
到这里你应该有完整的 AI 产品交付能力：
- 第 16 篇——72h MVP（演示能力闭环）
- 第 17 篇——PM 用 Claude Code（杀手锏）
- 第 18 篇——多轴灰度策略
- 第 19 篇——Pre-launch Eval 5 大类清单
下一篇进入第五部分——运营。
AI 产品的运营和传统产品完全不同——监控指标变了、bad case 管理变了、降级勇气是 PM 必修课。
第 20 篇先讲 AI 产品的监控指标体系——传统 Funnel 之外，必须看 4 类 AI 特有指标。
下一篇见。
本文配套资产：Pre-launch Eval 5 大类 checklist + 各类最低标准 + 3 个差距案例自检（付费读者解锁） 下一篇预告：20 · AI 产品的监控指标体系——传统 Funnel 之外要看什么 反馈 / 加入读者群：欢迎在公众号「蔡逸雯」留言