不能说公司名，但我得曝光一下这件事

昨天从朋友那了解到一个事儿，他所在公司的产品团队领了个 KPI，要求年底前在产品里上线不少于 10 个 AI 功能。

而且，解决什么需求、用户会不会用、效果怎么评估，都可以往后放，先上了再看效果。

团队内部有人问为什么要做，领导的回答很直接，「这是上面下达的任务」。

说实话，我听完挺无语，真正负责落地的人也只能硬着头皮做。

所以，我想把这件事说出来，也让那些正在用 KPI 推 AI 的老板们照照镜子。

公司名我不能说，你们也不用猜。

不是故意吊胃口，而是不想惹上一些没必要的麻烦，毕竟有些大厂的公关和法务天天盯着网上的信息。

我想聊的，是这种做法本身。

据我了解，现在不少公司都在做类似的事情。

管理层先确定今年必须拥抱 AI，定下战略，然后各个业务团队开始拆 KPI。

每个产品、每条业务线、甚至每个员工都要交一份 AI 作业。

最后，AI 从一种解决问题的能力，变成了必须完成的任务。

我把这种现象叫「AI 指标化」。

从产品角度来说，这种方式最大问题，就是把解决方案放到了需求前面。

正常做产品，应该先识别用户、分析需求、还原场景，然后根据问题选择解决方案。

显然，这种搞法的顺序反过来了。

AI 已经被确定为解决方案，产品经理接下来要做的，就是找一个地方把它塞进去。

于是，产品里多了 AI 对话框、AI 总结、AI 推荐、AI 帮写，发布会和汇报材料上看起来都有了 AI。

但用户为什么要用，解决了什么问题，带来了什么结果，没人说得清楚。

说白了，这就是为了拥抱 AI 而拥抱 AI。

这跟十几年前不少公司都要做 App 很像，很多公司一开始就是照着网站的样式把功能做到了 App 里。

后来才发现，小屏幕有自己的使用场景和交互方式，所以才有了「移动化」这种趋势。

AI 化也一样，把 AI 功能塞进原有产品，不等于完成升级。

同理，当 AI 功能被写进 KPI，团队的行为一定会围绕 KPI 变化。

如果考核的是上线多少个 AI 功能，大家就会追求数量。有了就行，不考虑怎么用、谁需要、解决什么问题。

只有考核用户问题是否解决、业务结果是否改善，团队才会真正关注价值。

所以，公司推动 AI 没问题，用 KPI 推也没问题，关键是 KPI 到底对什么负责。

那么，AI 和产品应该怎么结合？

我觉得，先回到一个最简单的问题：用户在什么场景下遇到了什么问题？

这里我想说两个国外产品的案例，第一个是 GitHub Copilot。

估计很多读者不知道它是干嘛的，简单说就是针对程序员用 AI 提高代码编写效率的 AI 助理。

程序员写代码是一个长期存在且被验证过的需求，其中有大量重复、明确、可以测试的工作。

Copilot 没有单独造一个 AI 页面让程序员去体验，而是进入原来的代码编辑环境，在开发者写代码的过程中提供 AI 补全和建议。

GitHub 曾让 95 名专业开发者完成同一个 JavaScript HTTP 服务器任务，使用 Copilot 的一组平均快了 55%。

发现没，这不是创造功能，而是把 AI 能力融入原本就有的场景和功能里，用新的生产力取代老的方案。

需求原本就存在，AI 进入了真实工作流，结果还能用完成时间和代码质量去验证。

再说一个，Shopify 的 Sidekick 也是类似的产品。

商家本来就需要管理订单、编辑商品、制作折扣、分析销售数据和配置自动化流程。

Sidekick 集成到了 Shopify 后台，直接理解店铺里的商品、订单和数据，帮助商家完成这些原有任务。

涉及实际修改时，系统会先展示结果，再由商家确认是否应用。AI 在这里承担的是执行和辅助决策，用户依然掌握最后的控制权。

通过这两个案例，你就能看出 AI 产品设计的基本逻辑。

先有被验证过的需求，再判断 AI 能力是否适合，接着设计人与 AI 的分工，最后用结果验证价值。

我觉得现在的 AI 应用类产品可以粗分为两类，一类是原生 AI 产品，一类是原有产品的 AI 化。

比如，Codex 这类 Agent 是原生 AI 产品，但微信和飞书这类后期加上 AI 能力的产品属于 AI 化。

容易做成 AI 指标化的，其实是后者。

你们可以去看下现在用的一些加上 AI 能力的产品，其实很多都是硬加，没啥必要。

这里，说下我觉得做 AI 产品的正确方式。

假设，现在让你给客服产品加入 AI 能力，你会怎么做？这是之前一个同学咨询我的一个面试题。

很多人以为让 AI 来取代人工客服回答问题就行，如果这么想，其实就是功能思维。

那么，产品思维是什么？

是从用户、场景、需求开始，一步步拆解业务逻辑和用户问题。

先找出过去三个月最高频的问题，看哪些咨询有明确答案、哪些需要查订单、哪些涉及退款纠纷和情绪安抚。

标准问题可以让 AI 直接处理，复杂问题可以让 AI 先整理信息再转给人工，高风险问题必须保留人工确认。

上线前还要记录原来的响应时间、一次解决率、转人工率、重复咨询率和用户满意度。

同时还要记录答案准确率、高风险问题漏转率，以及 AI 错误回答带来的投诉数量。

AI 上线后再对比这些指标，才能知道它到底有没有价值，这才叫 AI 落地。

另外，我觉得对于产品经理来说，能力结构也在发生变化。

过去更看重需求文档、原型设计、项目推进和跨部门协作的能力。

不是说这些不重要了，而是以后还需要理解模型能力边界、设计人机工作流、准备业务上下文、建立评测标准，以及处理 AI 出错后的兜底机制。

平时学习也不用每天追新模型，先从自己负责的一项真实业务开始。

找 50 个历史案例，先用其中 40 个调试业务背景、判断标准和输出格式，剩下 10 个不参与调试，专门用来验收结果。

如果 Agent 在没见过的案例上依然能达到要求，这套流程才算具备复用价值。

然后让 Agent 跑一遍，对比它和人工处理的差异，分析错误集中在哪里。

把有效的业务背景、分析过程、判断标准和输出格式固化成 Skill，再用同一批案例反复测试。

这套东西跑通后，你拥有的就不只是一个 AI 功能，而是一条能工作的 AI 产品流程。

我还是非常支持拥抱 AI 的，也相信 AI 会重构大量产品和工作方式。

但产品里出现 AI，不代表产品完成了 AI 化。

用户的问题被解决了，业务效率提升了，结果可以被验证了，这才算。

用功能思维做 AI 产品，只会上线一堆无用的软件功能。用产品思维做 AI 产品，就能为业务带去实际价值。

················· 唐韧出品 ·················

用AI思维发现下一个机会

安可时刻

有读者问我最新一期 AI 个体户计划什么时候开，这里统一说一下。

接下来是计划在上海开课，具体时间还没定，后期还有深圳和北京。为了方便来不了线下的，线上也可以报名。

如果你想跟我学习 AI 工作流打造和 Agent 员工搭建，学习自媒体内容创作方法和个人 IP 打造，可以提前找我占座。