第3章产品化第一步

3、产品化第一步：需求分析与场景定义：如何识别“真需求”与“伪需求”，大模型适用场景的评估矩阵

说实话，我见过太多团队一上来就喊“我们要接入大模型”。

老板拍脑袋，产品经理跟风，开发同学硬着头皮上。结果呢？折腾三个月，发现用户根本不买账。为什么？因为一开始就没搞清楚——这到底是个真需求，还是个伪需求？

我自己踩过这个坑。2023年初，有个客户想做“AI智能客服”，听起来很酷对吧？结果一调研，他们的用户量每天不到100人，问题类型不超过20种。用传统关键词匹配就能解决90%的问题，非要上大模型。成本翻了10倍，响应速度还慢了。这就是典型的伪需求。

怎么判断？我个人习惯用三把刀。

第一刀：用户真的疼吗？

伪需求往往来自“我觉得用户需要”。真需求是用户自己已经在用笨办法解决问题了。比如用户手动复制粘贴数据做报表，这就是真疼。如果用户根本没提过，只是你觉得“AI能提升效率”，那大概率是伪需求。

第二刀：不用大模型行不行？

你想想看，很多问题用规则引擎、传统机器学习甚至Excel就能搞定。非要上大模型，就是杀鸡用牛刀。我在项目中遇到过，有个团队想做“AI合同审核”，结果发现合同模板是固定的，用正则表达式就能搞定。大模型反而容易抽风，把“甲方”识别成“乙方”。

第三刀：ROI算得过来吗？

大模型调用一次的成本，是传统接口的几十倍。如果用户场景是高频低价值的，比如“每天查天气”，那肯定亏本。真需求应该是“高价值、低频次”或者“高价值、高复杂度”的场景。

嗯，这里要注意。这三刀不是顺序执行的，而是同时砍。只要有一刀砍不动，就得重新审视。

光靠感觉不行，得有个工具。我整理了一个评估矩阵，用了两年，挺管用的。

评估维度	权重	高分特征（5分）	低分特征（1分）
任务复杂度	30%	需要理解上下文、推理、生成	简单分类、匹配、查表
容错率	25%	允许一定幻觉，可人工兜底	必须100%准确，如金融交易
数据丰富度	20%	有大量高质量标注数据	数据稀疏或噪声大
实时性要求	15%	秒级响应可接受	要求毫秒级响应
成本敏感度	10%	用户愿意为效果付费	必须免费或极低成本

怎么用？很简单。每个维度打分，加权求和。总分超过3.5分，可以考虑上大模型。低于3分，我建议你再想想。

我的经验： 任务复杂度这个维度，最容易让人误判。你以为很复杂，其实用prompt engineering就能搞定。我建议先拿小样本跑一下，看看大模型到底能不能比传统方法好20%以上。如果不行，别硬上。

评估完矩阵，接下来就是定义场景。我一般分四步走。

用户故事拆解：把用户的一天拆成时间线，找到那些“卡点”。比如用户写周报要花2小时，这就是卡点。
输入输出定义：大模型吃什么？吐什么？输入是“上周的工作日志”，输出是“结构化周报”。越具体越好。
边界划定：大模型不是万能的。你得告诉它“哪些事别管”。比如写周报，别让它帮你写工作总结，那是老板的事。
失败模式分析：如果大模型答错了，会怎样？用户能接受吗？有没有兜底方案？我曾经做过一个项目，大模型把客户名称搞错了，结果销售直接发给了竞争对手。嗯，从那以后，我每个场景都会先想“最坏情况”。

坑一：把“技术可行性”当成“产品可行性”

大模型能写诗，不代表用户需要AI写诗。我见过一个团队，花三个月做了个“AI写周报”功能，结果用户说：“我写周报就是为了梳理思路，你帮我写了，我还梳理什么？”

坑二：忽略“数据飞轮”

大模型需要持续的数据反馈才能变好。如果场景本身没有数据回流机制，比如“一次性问答”，那模型永远停留在初始水平。我建议优先选择那些“用户会反馈对错”的场景，比如客服、审核。

坑三：低估“人机协作”的复杂度

很多人以为大模型是“全自动”，其实大部分场景是“半自动”。比如AI生成文案，人工审核修改。这个协作流程设计不好，反而增加用户负担。我建议在场景定义阶段，就把“人机分工”画清楚。

拿我最近做的一个项目举例。客户是法务部门，每天要审核上百份合同。

需求分析：

用户痛点：人工审核慢，容易漏条款
真需求：不是“AI替代律师”，而是“AI帮律师快速定位风险条款”
评估矩阵得分：任务复杂度4分（需要理解法律条款），容错率3分（律师会复核），数据丰富度4分（有历史合同），实时性4分（分钟级可接受），成本敏感度3分（预算充足）。加权得分：3.7分，可以上。

场景定义：

这个项目上线后，审核效率提升了60%。为什么成功？因为一开始就认清了“真需求”——不是替代人，而是辅助人。

说白了，大模型产品化的第一步，不是写代码，而是想清楚“到底要不要用大模型”。这个想清楚了，后面的事就顺了。想不清楚，后面全是坑。

我个人习惯，每次接到新需求，先拿评估矩阵过一遍。过不了3.5分的，直接打回去。别怕得罪人，总比上线后没人用强。