＂我们要一个 AI 助手＂——这句话到底想解决什么问题?

每家企业启动 AI 项目，起点几乎都一样：一份业务方提的需求清单。

清单上通常写着："我们要一个智能客服""我们要一个 AI 助手帮销售写周报""我们要一个知识库问答机器人"。

这些说法有一个共同点：它们描述的全部是"要做的东西"，没有一个字提到"要解决的问题"。

我并不是说这些需求是错的，而是说——如果项目团队拿着这份清单直接开始选型、搭 Demo，就已经输了。因为你不知道这个需求从哪里来，也就不知道它做完之后要交付什么。

一个更现实的观察是：业务方提出的 AI 需求里，相当一部分是伪需求。不是"做不出来"，而是"做出来了也不解决任何问题"，或者"不用 AI 也能解决"。

伪需求不是凭空捏造的需求，它有真实的来源——只是来源不是业务问题本身。

为什么伪需求这么普遍？因为业务方在提需求时，已经在脑子里替技术团队做完了一次方案设计——他们跳过了问题定义，直接给出了自己见过的、听说过的解法。

"我们要一个智能客服"翻译过来其实是"我看过别人的智能客服"。至于我们自己的客服到底哪里出了问题、出在哪个环节、值不值得修——这些信息全在被跳过的那一步里。

而技术团队拿到的是解法而不是问题，就会出现一种奇怪的项目状态：双方对"做什么"没有分歧，但对"为什么做"和"做到什么程度算成功"，从来没有对齐过。

很多项目就是这么启动的：所有人都同意建一个智能客服，没有人说得清客服现在的痛点排序。上线之后发现解决的不是最痛的那个，业务方说"这不是我想要的"，技术团队觉得冤——因为当初没人问过那个被跳过的问题。

怎么在调研阶段就把伪需求筛出来？我习惯用三个问题过一遍。任何一个问题答不上来，这个需求就先挂起，不要进排期。

第一问：这个需求拿掉 AI，还能做吗？如果规则引擎、模板、流程优化或者培训就能解决，那它就不是 AI 需求。AI 应该用在"必须理解非结构化信息"或"必须做模糊判断"的地方。这一问筛掉的是第二种伪需求。

第二问：需求背后的业务指标是什么？"提升效率"不算指标，"客服首响时间从 4 小时降到 30 分钟"才算。如果一个 AI 需求找不到可度量的业务指标，要么问题本身不重要，要么需求方还没想清楚问题。这一问筛掉的是第一种伪需求。

第三问：做完之后，谁的工作方式会改变？AI 落地必然改变某个岗位的工作方式。如果答不上来"谁会因此少做什么、多做什么"，这个需求大概率还停留在概念层面。这一问专门对付第三种伪需求——管理问题包装的需求，往往说不清楚谁的工作会真的变化。

伪需求被识别出来之后，正确的动作不是打回，而是追问。

这三步做完，需求清单通常会短一半，但剩下的那一半，每一个都有明确的来源、指标和责任岗位。这样的清单才值得排期。

所以调研阶段多问一句"这句话到底想解决什么问题"，比后面三个月的开发迭代更值得。