老板让你“做一个 AI 助手”,先别急着找供应商

老板让你「做一个 AI 助手」，最危险的不是需求太模糊，而是它听起来已经足够具体。

有了这个技术方向，团队可以马上找产品、约供应商、列功能、估预算。项目似乎一下子动了起来。

但「AI 助手」不是需求，只是一个预设答案。它先规定了要做成什么形态，却没有说明：谁的哪项工作，究竟要发生什么改变。

这件事不先说清，越快进入选型，企业越容易拿供应商的产品能力代替自己的业务任务。

这是《从一句需求到业务结果》系列的第二篇。上一篇讨论的是，成功标准怎样在层层交接中被换掉；这一篇把断点再往前推一步：有些项目从第一句话开始，就还没有真正的任务。

三套方案都不错，为什么还是没法选

先跟着负责人走进一次方案比较会。

周一的启动会上，老板留下一句话：「销售团队也该有个 AI 助手了。你先找几家供应商，下个月给我看方案。」

负责人很快约了三场演示。

第一家让助手读取产品资料，现场回答客户问题；第二家把会议录音变成纪要和跟进邮件；第三家接入 CRM，给销售推荐下一步动作。

三套产品都能演示，也都可以叫「销售 AI 助手」。

到了方案比较会，采购问：「那我们按什么选？」

有人说看回答准确率，有人说看能接多少系统，还有人建议选功能最多的，以后扩展方便。

讨论了一圈，团队才发现：大家从来没有确认过，老板真正想改变的是哪件事。

是新人不熟悉产品？销售会后不更新 CRM？还是大客户跟进经常漏掉下一步？

如果这个问题没有答案，三套方案并不是在竞争如何完成同一项任务。它们是在用各自现成的能力，替企业定义应该解决什么问题。

这不是供应商做错了。

面对一句模糊指令，供应商只能从自己的产品能力、交付经验和商业模式出发理解需求。真正的问题是：企业手里没有一把独立于产品的尺子。

「AI 助手」已经悄悄规定了答案

「AI 助手」听起来很宽，实际上已经带进了许多默认前提：要有一个对话入口，要能生成内容，可能要接知识库，最好还能调用系统。

团队一旦沿着这个名字往下讨论，问题很快就会从「销售哪一步需要改变」变成「助手应该有哪些功能」。

这会漏掉两种可能。

第一，真正的问题也许并不需要一个助手。

销售拿不到答案，可能是数据没有统一，规则没人确认，或者工作交接本身缺了一项责任。再增加一个聊天窗口，并不会让这些条件自动成立。

第二，AI 可能有用，但最合适的介入方式不是一个独立助手。

它也许应该在现有 CRM 里做会前检查，在某个流程节点提醒遗漏，或者只在人工决定之前准备材料。使用者甚至不需要知道背后有没有一个「助手」。

方案名称像先订了交通工具，再问要去哪里。后面做得越认真，团队越容易把问题优化成「怎样把这辆车开好」，而不是「这趟是否应该开车」。

AI 有输出，不等于业务有结果

生成式 AI 让这个偏离比普通软件需求更难察觉。

它可以现场回答问题、总结会议、起草邮件。输出一出现，就很像项目已经向前走了一大步。

但「生成了一封邮件」只证明模型能生成文字。它没有证明销售愿意采用，没有证明内容符合企业边界，没有证明下一步行动没有遗漏，也没有证明客户推进因此变得更可靠。

如果原任务没有写清，验收只能跟着方案走：回答好不好、功能全不全、系统接没接、账号开没开。

最后，企业可能交付了一个表现不错的 AI 助手，却无法回答它究竟改变了什么。

还有一个更隐蔽的后果：演示过后，团队很容易把已经看见的能力写回需求。

需求表面上越来越具体，实际只是从「做一个 AI 助手」变成「做一个像某家产品的 AI 助手」。供应商看似在响应需求，需求却已经被供应商的能力塑了形。

先把 Feature 改写成 Mission

接到一句方案名，不需要当场反驳老板，也不用先开一轮漫长的需求调研。

先把它当成方向假设，然后暂时拿掉产品形态，补齐五个位置：

使用者在某个工作时刻，要在明确约束下完成或改变一项业务行为；通过可观察的结果判断它是否成立。

例如，不写：

给销售做一个 AI 助手。

先试着改成：

大客户销售在客户会议结束后，能依据已经确认的会议记录和 CRM 状态形成下一步行动草案；草案由销售确认后才进入正式记录，并能从真实会议样本里检查关键信息是否遗漏。

这句话仍然不是一份可以直接开发的完整需求。

团队还需要进入真实工作流，确认资料是否存在、哪些信息可以使用、哪些决定必须由人完成，以及这项改变是否值得投入。证据、边界、验收和采用，也需要继续定义。

但它已经完成了最关键的一次转换：讨论不再围绕「助手应该有多少功能」，而是回到「什么方案最适合这项任务」。

不做独立助手，也可能是正确答案

任务说清以后，企业再看 AI 助手，可能得到三种答案。

第一，它确实是合适的产品形态。团队可以围绕同一项任务比较供应商、选择路线，并设计真实验收。

第二，AI 有用，但不需要一个独立助手。把能力嵌入现有流程，比让使用者再打开一个入口更合理。

第三，当前问题主要在数据、规则、流程或责任。先补条件，比采购工具更接近结果。

这三种答案都不代表项目失败。

任务定义的价值，不是替企业证明一定要上 AI，而是让企业知道自己究竟在为什么投入，也知道应该用什么尺度比较不同答案。

找供应商之前，先问这一句

下一次接到「做一个 AI 助手」时，可以先追问：

如果最后没有做出一个叫 AI 助手的东西，我们究竟希望哪类人的哪项工作已经发生了改变？

如果这句话答不出来，现在还不适合比较供应商。团队缺的不是更多产品信息，而是一把共同的尺子。

先把方案名拿掉，不是拖慢项目。

恰恰是为了让产品、供应商和技术路线重新变成可选择的答案，而不是未经讨论的前提。

如果你身边正有人被一句「做个 AI 助手」推着进入选型，可以把这篇文章转给他。不是为了否定 AI，而是先让所有人用同一项业务任务比较答案。