这篇文章讲的是什么. 一次公开复盘：一家 B 轮金融科技公司的产品团队，有一个演示效果很好、却一直发布不出去的 ai 功能。我们用五周时间把它重建成一个可上线的正式功能，最终推给了 100% 的用户，上线后该功能相关的客服工单量下降了 60%。
原型早就有了，是一位产品经理用 Lovable 花一个周末搭出来的。它看起来很像那么回事，在全员会议上演示效果也不错。然后它就闲置了四个月——因为看起来靠谱和真正靠谱是两码事。
说明： 客户信息已做匿名处理。五周上线周期和 60% 的工单降幅都是项目交付后的实际数字，不是预测值。我们不透露客户名称，是因为合同有约定。这篇文章的重点是这次搭建本身，而不是客户的招牌。
为什么一个不错的原型会卡在上生产环境之前？
因为原型要回答的问题，跟生产环境要回答的问题根本不是一回事。原型证明的是：在一个干净的输入下、由创始人亲自操作，这个想法能跑通一次。而生产环境要面对的是凌晨两点、没人盯着的杂乱输入，还要在客户对功能给出的结果提出异议时经得起追问。大多数 v0 和 Lovable 搭出来的东西，就死在这道坎上——不是因为想法不对，而是因为从演示到能挂上自己名字的东西之间没有路径。
怎么把一个 ai 原型真正送上生产环境？
从真实问题出发，而不是从演示界面出发。在你自己的产品里重建这个功能，加上流式响应、一套用已知正确答案来校验结果的测试集、审计日志，以及在关键节点上的人工审核。对这家金融科技团队来说，这条路走了五周，让该功能的相关工单减少了 60%。
我们实际搭建了什么？
我们没有从原型里的聊天框入手，而是从他们的客服工单队列入手。这个功能相关工单量最高的三类问题指向同一件事：用户不发邮件给客服就得不到一个明确答案。于是我们先让功能能够回答这三个问题，而且是嵌进他们自己的产品和设计体系里，而不是一个硬贴上去的小组件。
- 流式响应——让功能给人的感觉是即时的，而不是转圈的加载动画。答案是边生成边打字出来的。
- 一套测试集——每次改动都会用已知正确答案跑一遍功能，这样调整一处提示词就不会在悄无声息中弄坏另一个场景。
- 每条响应都有审计日志——这样当客户对功能给出的内容提出异议时，客服能调出当时确切的输入和输出。
- 嵌入产品内的体验设计——按照他们自己的设计体系来做，让它看起来是产品的一部分，而不是谁随手粘上去的一个聊天窗口。
we are
我们把一个卡住的原型重建成一个真正上线的功能，加上流式响应、测试集、审计日志和原生嵌入产品的体验设计。
we aren't
我们没有把一个通用的聊天框扣在产品上面，然后就管它叫 ai 功能。
#为什么客服工单量下降了 60%？
因为我们是倒推着从工单出发来搭建这个功能的。带来最多客服工单的那三个问题，现在功能会在产品内直接回答，用户不必再给任何人发邮件。审计日志告诉我们哪些问题是功能自己搞定的，哪些依然会转到人工手上。也正是这份日志，让我们能确认那 60% 的下降是真实的，而不是季节性的波动——它是按工单类型逐一测算的，对比的是上线前的八周数据。
工单量能持续维持在低位，靠的是那套测试集。上线前，每一次改动都会跑一遍已知正确答案的测试。一次修好了一个场景、却搞坏了另外两个场景的提示词修改，会在触达用户之前就被拦下来。这就是演示时能跑通一次和每次都能跑通的功能之间的区别。产品团队把这个叫作真正发布，我们也这么认为。更多关于我们如何看待产品工作的内容在这里。
从原型到上线一共花了多长时间？
五周，从原型到覆盖 100% 的用户。第一周搭建审计日志和测试集，因为没法度量的东西也没法改进。第二、三周在产品内重建了那三个高频工单问题的回答。第四周做设计体系内的体验和流式响应。第五周是分阶段上线，每次放量 10% 的用户，同时盯着审计日志看有没有测试漏掉的情况。没有一次性全量上线，也没有花一个季度去重建。
它从一个我们拿来演示的东西，变成了一个我们真正发布出去的东西，而客服工单队列就是我们确认它奏效的方式。
这也是我们大多数公开案例复盘的共同点：真正起作用的不是模型本身，而是它周围那些不起眼的部分——测试集、审计日志、审核关卡、可以随时观察的分阶段上线。正是这些，才能把一个原型变成一个敢摆在每一位用户面前的东西。如果你也有一个用 v0 或 Lovable 搭的东西，停在演示阶段找不到往前走的路，那正是我们能帮你补上的缺口。告诉我们你在做什么。