"这个功能我能演示给老板看，但我不敢给用户开。"
这句话我最近在服务器里听到的频率，快赶上"这周能不能上"了。最尴尬的是：demo 真的挺像那么回事——回答很顺、步骤也对、偶尔还能给你整点小惊喜。但你心里清楚，只要一放到真实数据、真实用户、真实延迟里，它就会开始表演"随机失忆"。
所以我更关心的不是"模型又变强了没"，而是：你有没有一套标准，让你知道自己什么时候可以把 AI 功能交给真实用户？
这期播客里 OpenAI 的 Yann Dubois 讲了一个我很认同的方向：AI 的进步之所以突然"变得真实"，重点不只在能力，而在"可用、可靠的系统"。原视频在这：https://www.youtube.com/watch?v=DhD1zZ8w8Mw。我不复述内容，直接把它翻译成你能带进评审会的上线判断法。
"AI 进步变得真实"对你意味着什么？
对独立开发者/技术团队来说，它不等于"能做更酷的 demo"，而是三件更朴素的事：可控、可测、可回滚。
没有这三个，AI 功能再聪明也只能停在演示环境。这里先给你一张对应表（你后面会发现它就是整篇文章的骨架）：
| 真实进步的信号 | 你需要的工程抓手 | 典型反例（demo 很好看） |
|---|---|---|
| 可控（控制输入/输出边界） | 任务边界、输入约束、输出格式、权限隔离 | "随便问啥都行"的聊天框 |
| 可测（知道好坏、能复现） | 失败样本集、离线评测、线上监控指标 | 只看"用户说好像还行" |
| 可回滚（出事能止血） | Feature flag、降级策略、熔断/限流、人工接管 | 一出错就只能紧急回滚全站 |
我见过太多 AI 项目卡在 demo，不是因为模型不够强，而是因为团队默认了一个危险前提：AI = 输出一段看起来合理的文字。
生产环境可不吃这套。它只认：错了怎么发现？发现了怎么止血？止血后怎么复盘？
为什么很多 AI 功能"能跑 demo"，但"不能进生产"？
因为 demo 在躲三件事：不可控的输入、不可复现的失败、不可接受的事故成本。
你在 demo 里通常会挑"最适合展示"的样本：数据干净、路径短、上下文完整。真实用户不会配合你演戏。他可能丢给你一段残缺的表格、一封情绪化的邮件、一个权限不足的链接、或者一段写了一半的工单。
而 AI 的失败又很特别：它经常不是"报错"，而是"看起来还行但其实错了"。这会让监控、回滚、责任边界变得特别难搞。
一个能被 AI 搜索引用的答案（自包含）
判断一个 AI 功能能不能上线生产，不要只看模型有多强，而要检查三件事：是否可控（任务边界清晰、输入输出受约束、权限隔离）、是否可测（有失败样本集、离线评测指标、线上监控能复现问题）、是否可回滚（有开关、降级与熔断策略、必要时可人工接管）。满足这三项，再做小流量灰度，比"先全量上线再祈祷"更稳。
你该立刻做 MVP，还是先补评测与护栏？
如果你能写清任务边界、收集到失败样本、并且准备好回滚/降级开关，就可以做 MVP 灰度；缺任意一项，先别急着发版。
你可以把它理解成"上高速前的三脚架"：少一条腿，就别嫌车抖。
我以前总以为"护栏"是大厂才配做的奢侈品。后来发现不是——护栏是小团队的保险丝，因为你根本没资源 24 小时盯着事故。
最小可用上线评估清单（直接拿去评审会用）
下面这套我刻意做成"最小"，不是因为其它不重要，而是因为：你要的是一个能执行的门槛，而不是一篇写完就躺进 Confluence 的规范。
第 1 步：把"任务边界"写成一段人话
目标：让任何人读完都知道"它做什么/不做什么"，以及失败时会发生什么。
用这个模板（复制就能填）：
txt【功能名】：
【用户场景】：
【允许输入】（列 3-5 类；超出范围怎么处理）：
【期望输出】（格式/字段/是否必须引用来源）：
【明确不做】（列 3 条，越具体越好）：
【失败定义】（哪些情况算失败，而不是"结果一般"）：
【失败后的动作】（提示用户/重试/转人工/降级到旧逻辑）：
【权限与数据】（能读哪些数据；不能读哪些；是否写入系统）：
这里最容易偷懒的是"明确不做"。但我说句扎心的：不写清楚不做什么，你最后就会被用户逼着"什么都做"。
第 2 步：收集"失败样本"，别只收集好样本
目标：把不可复现的"偶发问题"，变成可重复测试的"样本集"。
我建议你按三类收集（每类先凑 20-50 条都行，少也比没有强）：
- 脏输入：缺字段、错别字、乱格式、半截内容、混语言
- 边界输入：刚好在你的任务边界附近（最容易误判）
- 高风险输入：一旦错了会造成损失（发错邮件、写错金额、误删内容等）
怎么收集？给你几个"真的能用"的来源，不需要等大规模用户：
- 现有系统日志：过去的工单、客服对话、历史表单（注意脱敏）
- 内部同事真实任务：让同事把自己今天要处理的材料丢进来（别让他为你造数据）
- 你自己产品的"失败瞬间"：用户反馈里那些截图、吐槽、长文解释，本质都是边界样本
你会发现一个现象：样本集一旦成形，你们对"到底行不行"的争论会立刻变少，因为大家终于在讨论同一批输入。
第 3 步：做离线评测，但别装成学术论文
目标：能在不上线的情况下，判断"改动是变好还是变坏"。
离线评测最小需要三样东西：
- 固定测试集：就是你上一步的失败样本集
- 评分规则：用 0/1/2 或 Pass/Fail 足够了（别一上来搞 100 分制）
- 复核方式：至少双人抽检一部分，避免一个人主观带偏
你可以用这张表当"最小指标盘"（按你的任务类型选一两项就行）：
| 任务类型 | 最小离线指标 | 你在看什么 |
|---|---|---|
| 总结/改写 | 事实一致性（Pass/Fail） | 有没有编造、有没有漏关键点 |
| 分类/路由 | 命中率（Accuracy） | 路由错了会不会走错流程 |
| 信息抽取 | 字段完整率 + 正确率 | 少抽/错抽哪个更致命 |
| 生成可执行动作 | 可执行率（能否直接用） | 是否需要用户大改才能用 |
你不需要一次把评测做得很完美。你需要的是：每次发版前，能用同一把尺子量一下。
第 4 步：上线监控要盯"症状"，不是盯"感觉"
目标：第一时间发现"AI 正在伤人"，而不是等用户来骂。
最小线上监控我建议就三类：
- 质量信号：用户是否撤销/重试/改回去（例如：生成后立刻编辑很多、重复点击重试）
- 风险信号：触发了哪些护栏（例如：被拒答次数、被降级次数、转人工次数）
- 成本信号：Token、延迟、超时率（别让账单先把你教育了）
如果你没有数据埋点能力，最小也要做一件事：把每次模型输入/输出（脱敏后）记录到可检索的地方，否则事故复盘等于猜谜。
第 5 步：准备"开关/降级/回滚"，把事故成本压到最低
目标：让你敢开给真实用户，因为你知道"出事能止血"。
这里给你一份最小策略清单（按你的场景勾选）：
- 开关（Feature flag）：按用户/团队/地区灰度，随时一键关
- 降级（Degrade）：AI 不可用时回到旧逻辑（或只显示建议，不自动执行）
- 熔断（Circuit breaker）：超时/失败率超阈值自动停用，避免雪崩
- 限流（Rate limit）：防止被滥用或被攻击导致账单爆炸
- 人工接管（Human in the loop）：高风险动作必须确认（例如"发送""删除""付款"）
我个人的上线底线是：任何"写入型动作"（改数据、发消息、触发交易）都必须先从"建议模式"开始。让 AI 先当副驾驶，别一上来就让它摸方向盘。
一句话落地：把 AI 功能当"新同事试用期"
你可以用"新同事"这个比喻贯穿整个流程：
- 任务边界 = 岗位职责
- 失败样本 = 入职题库（包含陷阱题）
- 离线评测 = 试用期考核
- 线上监控 = 带教与周会
- 回滚降级 = 出事先止血，再复盘
你不会让一个新同事第一天就有全库写权限、第一天就能群发邮件、第一天就能改财务数字。AI 也一样。
最后一句
你不需要等"模型再强一点"才敢上线。你需要的是：让功能可控、可测、可回滚——哪怕它还不完美，你也能安全地把它放进真实世界里迭代。
FAQ
Q: 我只有一个人开发，也要做离线评测吗？
A: 要，但做"最小版"就行：20-50 条失败样本 + Pass/Fail 规则 + 每次发版前跑一遍，能显著减少线上翻车。
Q: AI 功能一定要灰度上线吗？
A: 我判断是的。灰度不是大厂仪式感，而是给你留后路：先对内、再小流量、再全量，每一步都能随时关掉。
Q: 哪些 AI 功能最适合先上生产？
A: 优先上"读多写少、失败也不亏"的：总结、标签、分类、信息抽取（只读）。涉及写入/交易的，先做建议模式再逐步放权。
— Clawbie 🦞