4. AI项目需求分析

好，咱们进入正题。AI项目的需求分析，跟传统软件还真不太一样。

传统软件你问用户要什么，用户说「我要一个报表」，你画个原型就完了。但AI项目呢？用户说「我要一个智能推荐」，你问他推荐什么、怎么推荐、数据从哪来、准确率多少算够？他大概率一脸懵。

所以，AI产品经理的核心能力之一，就是把这四层需求一层层剥开。我习惯把这四层叫做「四件套」：业务、用户、数据、算法。缺一个，项目就容易翻车。

4.1 业务需求调研：别急着谈技术，先搞清楚「为什么做」

很多AI产品经理一上来就聊算法选型，这是大忌。我见过太多项目，技术方案做得漂漂亮亮，结果业务方说「这不是我要的」。

业务需求调研，说白了就是搞清楚三件事：

• 痛点是什么？ 用户现在哪里不爽？
• 价值是什么？ 做了AI能省多少钱、赚多少钱？
• 边界是什么？ 哪些场景不做？哪些数据不能用？

举个例子。我之前做一个客服智能质检项目。业务方说「我要AI自动检测客服违规」。听起来很明确对吧？

但深入聊才发现，他们真正的痛点是：人工抽检覆盖率只有5%，大量投诉漏掉了。而AI的价值不是「检测违规」，而是「把抽检率从5%提到100%」。边界也很清楚：只检测文本对话，不检测语音。

你看，如果我不问这些，直接去搞语音识别，那就跑偏了。

4.2 用户需求分析：谁在用？怎么用？用的时候爽不爽？

业务需求是老板视角，用户需求才是真实使用者的视角。AI产品最怕什么？最怕做出来没人用。

用户需求分析，我一般拆成三步走：

1. 用户画像：谁是一线操作者？谁是审核者？谁是管理者？
2. 使用场景：他们在什么时间、什么地点、什么状态下使用？
3. 交互期望：他们希望AI怎么呈现结果？是弹窗提醒？还是自动处理？

还是那个质检项目。业务方是运营总监，但真正每天用系统的是质检员。质检员一天要看几百条对话，眼睛都快瞎了。

所以他们的需求不是「准确率99%」，而是「一眼就能看到问题在哪」。我后来把AI检测结果用红色高亮标出来，再附上一句话解释。质检员反馈说：「终于不用自己翻聊天记录了。」

嗯，这里要注意：用户需求往往不是功能列表，而是「帮我省事」。

4.3 数据需求分析：没有数据，AI就是空中楼阁

这是AI项目最容易被低估的一环。我见过太多项目，算法模型都选好了，结果发现数据拿不到、或者数据质量一塌糊涂。

数据需求分析，我建议从四个维度来梳理：

我曾经踩过一个坑。项目需要用户行为数据，业务方拍胸脯说「数据库里全都有」。结果一查，数据是有的，但时间戳格式不统一，有的用时间戳，有的用字符串，还有的字段是空的。光清洗数据就花了两周。

所以我现在做数据需求分析，一定会要求业务方提供一份「数据样本」，哪怕只有100条。看一眼样本，就知道数据质量行不行。

4.4 算法需求分析：别让算法工程师猜你要什么

算法需求分析，是AI产品经理最硬核的部分。你得把业务需求翻译成算法能理解的语言。

我一般会跟算法团队对齐这几个点：

• 任务类型：分类？回归？聚类？序列标注？
• 评估指标：准确率、召回率、F1值？还是业务指标如转化率？
• 性能要求：响应时间多少？并发量多少？
• 可解释性：需要告诉用户「为什么」吗？

举个例子。还是那个质检项目，业务方说「我要检测客服有没有辱骂客户」。

翻译成算法需求就是：

• 任务类型：文本二分类（辱骂/非辱骂）
• 评估指标：召回率优先（宁可误报，不能漏报）
• 性能要求：单条对话检测 < 200ms
• 可解释性：需要输出触发关键词，方便质检员复核

你看，这么一写，算法工程师就知道该用什么模型、怎么调参了。

4.5 四层需求的联动关系

这四层需求不是孤立的。我习惯画一个简单的联动图：

你看，业务需求驱动用户需求，用户需求又反过来约束算法需求。数据需求是底层支撑，没有数据，算法就是空谈。

我习惯在PRD里把这四层需求做成一个表格，每一层都写上「验收标准」。这样开发、测试、业务方都能对齐。