本文内容. 一个说明性的实例演示,不是客户成果。这个金融科技团队、其产品和每个数字都是假设。它展示要把一个演示效果很好的 AI 原型,变成可以交给所有用户的功能,需要做些什么。
假设一个 b 轮金融科技公司的产品团队。一位产品经理用 lovable 在一个周末做出了 AI 功能的原型。它看起来很真实,在全员会上演示得也不错。然后就搁在那里,因为看起来真实和真正可靠是两份不同的工作。
关于这个例子:团队是泛化的,背后没有客户。这里的一切都不是已交付的成果,也不是预测。重点是设计,不是标志。
为什么一个不错的原型会卡在上生产环境之前？
因为原型要回答的问题，跟生产环境要回答的问题根本不是一回事。原型证明的是：在一个干净的输入下、由创始人亲自操作，这个想法能跑通一次。而生产环境要面对的是凌晨两点、没人盯着的杂乱输入，还要在客户对功能给出的结果提出异议时经得起追问。大多数 v0 和 Lovable 搭出来的东西，就死在这道坎上——不是因为想法不对，而是因为从演示到能挂上自己名字的东西之间没有路径。
如何把 AI 原型推向生产?
从真实的问题出发,而不是演示界面。在你自己的产品内部重建这个功能:流式响应、把答案与已知正确案例比对的测试套件、审计日志,以及在关键处的人工审阅。然后在上线前后衡量与该功能相关的支持工单。
生产设计包含什么?
不要从原型里的聊天框开始。从支持队列开始。假设这个功能上量最大的三类工单指向同一件事:用户不给支持发邮件就得不到清晰的答案。把功能建成先回答这三个问题,在团队自己的产品和设计系统之内,而不是外挂的小组件。
- 流式响应——让功能给人的感觉是即时的，而不是转圈的加载动画。答案是边生成边打字出来的。
- 一套测试集——每次改动都会用已知正确答案跑一遍功能，这样调整一处提示词就不会在悄无声息中弄坏另一个场景。
- 每条响应都有审计日志——这样当客户对功能给出的内容提出异议时，客服能调出当时确切的输入和输出。
- 嵌入产品内的体验设计——按照他们自己的设计体系来做，让它看起来是产品的一部分，而不是谁随手粘上去的一个聊天窗口。
We are
我们把停滞的原型重建为已上线的功能,带有流式响应、测试套件、审计日志,以及产品内的原生体验。
We aren't
我们不会在产品上面放一个通用的聊天框,然后称之为 AI 功能。
你怎么知道这个功能减少了支持工单?
从工单倒推来建这个功能。带来最多支持量的问题,正是功能在产品内回答的问题,不用等任何人发邮件。审计日志显示功能处理了哪些问题、哪些仍然到了人那里。同一份日志还能帮团队区分真实下降和季节性回落:把每类工单的数量与上线前的基准期比较。
测试套件让任何改进都站得住。上线前,每次改动都会对照已知的正确答案运行。一次提示词修改修好了一个案例却弄坏了另外两个,会在到达用户之前被拦住。这就是只能跑通一次的演示与每次都能跑通的功能之间的差别。产品团队把这叫做上线。我们也这么认为。更多关于我们如何对待产品工作,请看这里。
应该按什么顺序来建?
先做审计日志和测试套件,因为无法衡量的东西就无法改进。再在产品内重建排名靠前的工单所对应的回答。然后是设计系统的体验和流式响应。最后是分阶段推出,面向不断扩大的用户比例,并盯着审计日志,看有没有测试漏掉的东西。不搞一次性大上线。
要套用的检验:它应该从一个你演示过的东西,变成一个你上线了的东西,而支持队列就是你知道它奏效的依据。
这正是我们的实例演示的共同点。收益不在模型,而在周围那些不起眼的部分:测试套件、审计日志、审阅关卡、可以盯着看的上线过程。这才把原型变成可以交给所有用户的东西。如果你有一个 v0 或 lovable 的作品停在演示阶段、看不到前路,这正是我们要补上的缺口。告诉我们你在搭建什么。
