别再用软件思维做AI产品了

去年，我观察了三个不同的AI产品团队，他们用与传统软件完全相同的流程来交付功能：详尽的PRD文档、像素级精确的设计稿、两周一个冲刺、QA测试、上线。每一次，这个功能不到一周就让人觉得不对劲。

不是坏了，也不是有bug。只是……感觉不对。用户会试一次AI功能，然后说一句"嗯"，就回去继续做他们之前在做的事了。

过去两年我一直在构建AI产品，我学到的最重要的一个道理是：传统软件的那套方法论，会主动破坏AI产品。

1、核心问题

传统软件是确定性的。你点一个按钮，每次都会发生同样的事情。你可以写一个规格文档，按照规格构建，产品要么符合规格，要么不符合。

AI产品是概率性的。同样的输入会产生不同的输出。"正确"的答案取决于上下文、时机、用户历史，有时候甚至取决于运气。你无法通过写规格文档来获得好的AI体验，因为你无法预测体验会是什么样的。

这不是一个小区别。它改变了一切关于你应该如何构建产品的方式。

标准的做法大致是这样的：

研究问题 → 写需求文档 → 设计方案 → 构建 → 对照需求测试 → 上线。

当你知道"完成"是什么样子时，这套方法非常好用。结账流程要么能处理支付，要么不能。搜索栏要么返回结果，要么不返回。

但是AI功能的"完成"是什么样子？聊天机器人的回复什么时候算"足够好"？AI推荐系统什么时候算"有效"？这些问题没有干净的答案，假装它们有答案只会导致技术上能用但实际上令人失望的产品。

在传统软件中，测试是在构建之后进行的。在AI产品中，评估需要放在最前面。在写任何一行代码之前，先定义你将如何衡量AI输出是否够好。不是实验室里的"准确"，而是对使用它的人真正有用。

在我正在构建的AI产品中，我们在构建新功能之前花了三周时间只确定评估标准。感觉很慢，但这为我们省去了数月构建错误方向的时间。

传统产品发布功能。AI产品需要发布反馈闭环。功能不是AI的输出，功能是让AI输出随时间不断改进的系统。

这意味着要建立从用户那里收集信号的机制——了解什么有效，什么无效。不是问卷调查，不是NPS评分，而是实际的行为信号：他们使用了输出吗？他们编辑了吗？他们回来了吗？

如果你发布了一个AI功能却没有反馈闭环，那你发布的是一个演示，不是一个产品。

传统软件用错误信息来处理异常："出了点问题，请重试。"AI产品的失败方式不同。它们会因为自信地给出错误答案、微妙地偏题、或者就是帮不上忙而失败。

我见过的最好的AI产品，在失败场景上花的设计时间比成功场景更多。当AI给出了不好的推荐怎么办？当它产生幻觉怎么办？当用户不知道输出是对是错怎么办？

如果你的AI产品只有在AI表现好时才能用，那你的产品其实并不能用。

构建AI产品比构建传统软件更难。不是因为技术更复杂（虽然确实如此），而是因为产品思维需要从根本上不同。

你无法躲在需求文档和测试用例后面。你需要培养在概率系统中辨别"好"的品味。你需要习惯于发布你明知有时会出错的东西，同时构建系统让它随着时间的推移减少出错。

大多数产品团队并没有为此做好准备。他们是为确定性世界优化的。这就是为什么大多数AI功能感觉像是事后补充，因为它们是用错误的思维模型构建的。

在AI领域获胜的公司，不是那些拥有最好模型的公司。而是那些弄清楚如何围绕不完美、不可预测、但不断改进的模型来构建产品的公司。这需要一种完全不同的产品开发方法。

别再写那些读起来像传统软件规格文档的AI功能需求了。开始构建评估框架、反馈闭环和优雅的失败模式。这才是构建AI产品的真正做法。

汇智网翻译整理，转载请标明出处