翻译：Transwan
校对：Carl Cui
从 Demo 到生产的“死亡之谷”
如果你做过 AI 功能，大概率有过这样的体验：团队在开发一个让人兴奋的新功能，发布排期已经敲定；模型能给出近乎完美的回答，系统原型看起来就像德芙那样丝滑。会议室里，每个人都开始想象它上线后会变成一个流行的产品，许多次，我曾坐在这样的会议室里，那种气氛确实很棒。
然后，你开始做发布前测试：
移动端延迟飙升到 10 秒；模型在占实际用户查询 15% 的边缘案例上开始产生幻觉。经过一番努力，你从 A/B 测试结果上看不到明显的提升，因为 AI 输出的方差太大，使得传统的假设检验基本上失效。安全团队第一周就标出了 340 个失败案例，而你每天都在调试那些以各种新颖方式失败的非确定性案例。
很多时候，这不是模型能力问题，而是工程规范问题。发布 AI 产品和交付传统软件很不一样，我吃了苦头之后才明白这一点。下面这份 playbook，就是我从这些经验里总结出来的经验教训。
延迟预算
每个 AI 功能都会带来额外的延迟开销。大语言模型推理需要时间，实际可能是 500 毫秒，也可能是 5 秒，甚至 50 秒，这取决于模型大小、输入长度以及基础设施配置。对 ToC 产品来说，用户往往期待低于 200 毫秒的交互响应，所以系统响应延迟不是一个上线后再优化的小问题，而是设计阶段就必须正面处理的硬约束。
我最常见到的错误，是团队只看 p50 延迟。一个 p50 为 800 毫秒的功能听起来还不错，直到你发现它的 p90 是 15 秒。这意味着每 100 个用户里，就有 10 个要坐在那里等 15 秒以上。放到规模化产品里，这就是每天成千上万次糟糕体验。
我的做法是按交互类型定义延迟预算，而不是给所有场景设一个统一标准：
- 同步交互，也就是用户盯着 loading 状态等待结果的场景，应该在 1 秒内完成
- 渐进式交互，也就是输出逐个 token 流式返回的场景，首个 token 应该在 500 毫秒内出现，完整响应最好控制在 5 秒内
- 异步交互，也就是用户可以继续做别的事的场景，可以在有进度提示的情况下放宽到 20 秒左右
冷启动也要单独测量。模型加载到内存后的第一个请求，可能比后续请求慢 10 倍。如果你的流量是突发型的，冷启动会特别惩罚那些在高峰时段进入产品的高活跃用户。
还要记住，延迟预算应该覆盖整个链路，而不只是模型推理。一个典型的 AI 功能链路包括：
- 输入预处理，比如分词、上下文组装和 prompt 构造；
- 模型推理；
- 输出后处理，比如解析、格式化和安全过滤；
- 以及最终响应交付。
这些步骤都会累积耗时，只优化推理、不看其他环节，就像轮胎漏气时还在调发动机。
最后，对生成式功能要尽量使用流式输出，不要等完整响应生成完才一次性展示，而是在 token 生成时就推给用户。一个 4 秒完成、但 300 毫秒就开始出现内容的响应，会比一个 4 秒后突然整段出现的响应快得多。在用户体验方面，感知即现实。
设计降级方案
传统软件通常以无聊且可预测的方式失败。AI 功能则不一样，它会以新奇、不可预测，偶尔还很有创意的方式失败。我曾见过一个模型在用户询问产品推荐时，回复了一首关于孤独的诗。你的兜底策略，必须比一个简单的 try/catch 复杂得多。
我将降级方案视为一个层级结构：
- 第一层是模型降级：当主模型失败时，切到更简单、更快、更可靠的模型。大多数失败都可以在用户无感知的情况下被处理掉；
- 第二层是缓存降级：对于和历史请求相似的问题，直接返回缓存响应；
- 第三层是模板降级：当生成彻底失败时，退回到预先写好的模板。体验降级总比功能彻底死掉好。
- 第四层是优雅省略：有时最好的兜底方式，是干脆不展示这个 AI 功能，而不是把一个坏掉的版本暴露给用户；
所有这些设计背后的原则是：用户绝不应该遇到未经处理的 AI 故障。每一种失败模式都应该映射到某个明确的降级层级；只要条件允许，层级之间的切换就应该对用户不可见。
评估质量
传统软件的质量往往是二元的：按钮要么能用，要么不能用。AI 功能的质量则是连续的、主观的，而且会随上下文变化。我最终采用了一个四层质量金字塔。
最底层是安全性，这是不可妥协的。输出里是否包含有害内容、个人身份信息（PII）或捏造的事实？这一层可以按二元方式处理，并且应该用自动化分类器覆盖 100% 的输出。
第二层是事实正确性，它依赖具体领域。输出到底对不对？对编程助手来说，这意味着生成的代码能编译、能通过测试。对写作工具来说，这意味着语法正确、风格合适。它需要用领域相关的评估套件来衡量。
第三层是有用性，它以用户为中心。用户是否真的从中受益？可以跟踪接受率、编辑距离、任务完成时间和复用率。传统产品指标和 AI 特有指标，会在这一层交汇。
第四层是体验上的惊喜感。输出让人感觉好吗？这是最难度量的一层，但它往往决定用户是否愿意采用这个功能。有时候数据告诉你功能运行正常，但用户的直觉告诉你“不太对”。这一层就是用来捕捉这种差距的。
AI 功能的 A/B 测试
AI 功能的 A/B 测试天然比传统功能更难，因为 AI 输出是非确定性的。同一个用户做同一件事，两次可能得到不同结果，这引入了传统实验框架并不擅长处理的方差。
核心挑战在于，组内方差会扩大统计显著性所需的样本量，通常是原来的 3 到 5 倍。如果你还按传统的样本量假设来跑 AI 实验，那么你可能会把噪音看成信号。
其次是指标选择问题。一个聊天机器人如果生成了有趣但在事实上错误的回复，可能会带来很漂亮的参与度数据，但同时却在积极地误导用户。所以你必须同时衡量参与度和质量。比起原始参与度，“质量分超过阈值的有效参与交互”通常更有意义。
时间维度也很重要。AI 功能的价值会随着用户学习如何使用它而变化。如果存在学习曲线，短期实验会低估长期价值；如果存在新鲜感红利，短期实验又会高估价值。
我的实践建议是：给 AI 实验预留比传统实验多 2 到 3 倍的时间和流量；更多使用贝叶斯方法，因为它们更适合处理高方差；并且始终把定量测试和定性研究结合起来。10 个用户访谈就能暴露出任何统计分析都无法发现的失败模式。
监控模型漂移
模型漂移，是 AI 输出质量随时间推移发生的缓慢且不可见的腐烂，造成这种情况的原因不止一个。
数据漂移来自世界变化和用户行为演进。一个基于 2024 年数据训练的模型，在处理 2026 年的新概念、新俚语和新文化事件时，表现自然会变差。
供应商漂移的发生是因为第三方 API 在未经你同意的情况下发生了变化。 OpenAI 承认 GPT-4 的行为在 2023 年 3 月至 6 月期间发生了可测量的偏移，斯坦福大学的研究人员也记录了其显著的性能波动。解决办法是固定模型版本，让更新按照你的节奏发生，并且先经过你的测试。
评估漂移是最隐蔽的一种，即使你的质量指标也会过期：发布时合理的评估标准，可能会随着使用模式变化和用户预期提高而不再适用。因此，每季度审查一次评估套件是必要的。
至少，你需要每天对 1% 到 5% 的生产流量做自动化质量评估；每周分析输入分布特征；每月对 100 到 500 个样本做人工评估。没有漂移监控就上线 AI 功能，就像部署一个没有告警的服务。等用户告诉你的时候，你才会知道它已经坏了，而到那时用户已经怒不可遏了。
评估框架
怎么知道一个 AI 功能已经足够好？你需要两套根本不同的评估方法。
自动化评估赋予你速度。你可以构建一个包含 500 到 2000 个标注样本的黄金集，训练一个分类器，或者使用一个能力足够强的模型作为评审，并且每季度用人工判断校准一次，目标是达到 85% 的一致性。自动化评估每小时可以处理数千个样本，因此对迭代速度非常关键。但它的缺陷也很明确：训练数据里没有的新型失败模式，它往往看不到。
人工评估能捕捉到自动化遗漏的问题。可以组织 5 到 7 名评估者，混合领域专家和代表性用户；使用一致的评分标准，覆盖准确性、帮助性、语气、完整性和安全性。开发阶段每周跑一次，生产阶段每月跑一次。它的代价是成本高，每个样本大约 15 到 30 美元；速度慢，周转时间通常是 24 到 72 小时；而且不可避免地受到人为偏见影响。可以通过轮换评估者、把单次评估控制在两小时以内来降低这些问题。
用模型做评审，也就是 model as judge，正在成为一种越来越可行的折中方案。判断质量通常比生成高质量结果更容易，所以一个模型往往可以可靠地评价某些输出，即便它自己未必能生成同等质量的结果。它适合高吞吐量评估，但仍然必须定期和人工判断对齐。
优雅降级与 prompt 工程
优雅降级的意思是：当能力下降时，体验应该平滑地变差，而不是断崖式下跌。你应该围绕能力级别来设计，而不是只设计“可用/不可用”两个状态。定义 4 到 5 个级别，并为每个级别规定具体行为。
以 AI 写作助手为例：Level 5 是完整能力，提供实时建议、语气调整和结构推荐；Level 4 是因为延迟升高，建议在 2 到 3 秒停顿后出现；Level 3 只提供基础建议，比如语法和拼写，不再提供风格反馈。每个级别都是一个经过深思熟虑的设计决策，而不是意外。
能让降级不可见时，就尽量让它不可见。用户不应该看到一个“坏掉”的体验，他们看到的应该只是一个细节更少的体验。这两者在心理感受上差别很大。不过，如果降级严重到用户一定会注意到，主动说明“AI 建议暂时受限”会比默默推送低质量输出更能建立信任。
生产环境里的 prompt engineering，本质上就是软件工程。在生产环境中，prompt 是代码，所以它需要版本控制、测试、监控和维护。每个 prompt 都应该进版本控制，prompt 应该参数化，而不是把上下文硬编码进去。生产 prompt 应该是模板，并且清楚定义用户上下文、系统状态和动态指令的注入点。
这样做有两个好处：它让 prompt 变得可测试，因为你可以注入已知输入并验证输出；也让 prompt 变得可维护，因为改变上下文处理方式时，不需要从头重写整个 prompt。
prompt 也要跑回归测试。维护 200 到 500 个测试用例，覆盖预期输入的完整分布，包括边缘案例和对抗性输入。每次 prompt 变更上线前，都应该跑一遍测试集。
生产环境里也要监控 prompt 表现。跟踪接受率、用户编辑、重新生成请求等输出质量指标，并按 prompt 版本切分。当你发布一个新版本时，至少用 72 小时把它的生产指标和上一版对比，再判断它是否稳定。这基本上就是 prompt 的金丝雀发布。
正确地交付
这些系统并不是你在发布后可以硬凑上去的可选附加组件。我见过的每一个失败功能，几乎都是先把功能做出来，然后计划“以后再补生产加固”。但“以后”通常永远不会来。
AI 功能是概率性的、非确定性的，而且即使没人改代码，它们也会随时间变化。你需要从一开始就建设这些系统，为它们配备合适的人，并且像对待核心基础设施一样认真对待它们。
Demo 和生产之间确实隔着一条很宽的沟。但只要桥搭对了，这条沟并不是过不去。
注：与本文相关的研究工作以个人身份完成，文中观点仅代表作者个人。
原文链接
The PM’s Playbook for Shipping AI Features That Actually Work in Production