在AI热潮下，很多企业和个人陷入了一种“技术强迫症”。

仿佛只要没用上大模型，这个业务就不够高端，不够未来。于是，我们看到了大量为了AI而AI的荒诞场景。

我想说一句不客气的话：把确定性的任务交给概率性的AI，这是产品经理最大的失职。

以下这三个场景，如果你正在做，建议立刻停下来。

场景一：用大模型做“自动报价计算器”

这是我亲眼见到的一个真实需求。

一家设备租赁公司，想做一个“AI智能报价助手”。

需求是：客户输入“我要租5台挖掘机，3台推土机，租期10天”，AI自动识别需求，然后根据后台的单价表，计算出总金额，并生成报价单。

为什么这是伪需求？

因为计算总价是一个“确定性”的数学逻辑：数量 × 单价 × 天数 = 总价。

如果你用大模型去做：

1. 速度慢：API请求一来一回需要几秒钟。

2. 成本高：每次计算都在消耗Token。

3. 不可靠：这是最致命的。大模型（LLM）本质上是概率模型，它不擅长做精确的数学运算。它很有可能一本正经地算错一个小数点，或者产生幻觉，把挖掘机的价格安到推土机头上。

正确的做法是什么？用AI做意图识别（提取出“5台”、“挖掘机”、“10天”这些关键词），然后把这些参数传给代码或者数据库。

剩下的计算，交给Python，交给Excel的VLOOKUP，甚至交给几行简单的JavaScript。代码是100%准确的，而AI不是。不要用一个只会写诗的“文科生”去干会计的活。

场景二：用大模型做“数据库精准查询”

“我想做一个AI，能回答‘上个月销售额超过1万的订单有哪些？’，然后列出所有订单号。”

听起来很美好，Text-to-SQL（自然语言转SQL）也是现在的热门方向。

但在实际落地中，如果你的业务要求是“零误差”，直接让大模型去翻数据往往是灾难。

为什么这是伪需求？

大模型的“上下文窗口”是有限的，你不可能把几万条订单数据全都塞进Prompt里让它去“看”。 即使你用了RAG（检索增强生成），在面对“列出所有符合条件的订单”这种全量检索需求时，RAG经常会漏掉数据，因为它倾向于检索“最相关”的，而不是“全部”。

正确的做法是什么？老老实实写一个BI看板，或者用传统的筛选器。 如果你非要用AI，它的作用应该是“翻译官”——把人的话翻译成SQL语句，然后去数据库里查。 千万别指望大模型自己去充当数据库。它的记忆是模糊的，而数据库的记录是精确的。

场景三：用大模型做“格式化数据清洗”

还有一个经典场景：

“我有一堆乱七八糟的Excel数据，日期格式有的写‘2024.1.1’，有的写‘2024年1月1日’，我想接入GPT，让它把所有日期统一改成‘2024-01-01’。”

为什么这是伪需求？

杀鸡焉用牛刀？

处理这种基于“固定规则”的文本替换，正则表达式（Regex）或者简单的Python脚本比AI快一万倍，而且免费。

让AI去处理这种机械任务，就像是雇佣一个年薪百万的教授去抄写电话号码。 不仅浪费算力，而且AI偶尔还会“自作聪明”。比如它可能会觉得某一行数据看起来像错误的，顺手给你“修正”了，结果导致原始数据丢失。

在数据清洗领域，规则永远优于概率。

AI的边界在哪里？

写这篇内容，不是为了贬低AI，而是为了保护AI。

滥用AI，只会导致项目失败，最后大家得出结论：“AI真难用，全是骗人的。”

我们必须想清楚一个核心逻辑：AI（特别是大语言模型）的核心能力是“理解”、“推理”和“生成”，而不是“计算”、“存储”和“执行”。

• 涉及创意、模糊意图理解、非结构化数据处理（如读文章、看图片、写文案）的，请大胆用AI。

• 涉及精确计算、全量检索、固定规则执行的，请衡量传统的代码软件和AI的成本与精准性再实施。

真正的AI高手，不是手里拿着锤子看什么都是钉子。而是知道什么时候该用锤子，什么时候该用螺丝刀。

别为了所谓的“科技感”，丢掉了最基本的“工程常识”。

有时候，一个VLOOKUP函数，就是比GPT更牛逼。