怎么判断一个 AI 场景值不值得做?

不是因为技术做不到。恰恰相反——现在大部分被提出来的 AI 场景，技术上都能做出来。卡住它们的是另一个问题：做出来值不值。

一、问题不是"能不能做"，是"值不值"

企业提出 AI 场景的典型形态有三种：

• 对标型：「竞品上了个 AI 客服，我们也得有」
• 触动型：「看了个 demo，这个东西不错，我们内部是不是也能用」
• 任务型：「上面要求今年要有一个 AI 落地案例」

三种都很正常，但都没有回答同一个问题：这个场景做出来，谁会用、多久用一次、怎么算它做成了？

这个问题不回答，项目就会以最难受的方式失败——不是技术上做不出来，是做出来了没人用，或者一直在改，因为没人能说清什么时候算完成。

下面三个判据，是我在真实项目里筛选场景时用的。三个都过，值得做；缺一个，就要慎。

二、判据一：痛点够不够高频

要问的问题：这个场景对应的活，一个月发生几次？

为什么低频场景不该先做：一个每月用三次的工具，即使做得好，也建立不起使用习惯——用户会忘记它存在，或者觉得"我自己弄一下更快"。而习惯建立不起来，就没有后续迭代的反馈，项目会停在"上线了但没人用"的状态。

一个容易误判的地方：不要用"这个活总共花多少时间"来判断，要用"多久发生一次"。一个每次花两小时但一年只做两回的活，不适合先做 AI；一个每次只花十分钟但每天都有的活，反而更值得。

三、判据二：边界够不够清楚

要问的问题：这个场景"什么算做完"能说清楚吗？更重要的是——"什么不做"能说清楚吗？

边界不清楚的场景，会有非常典型的表现：

• 需求谈的时候说"就是把我们那个流程智能化一下"
• 做到一半不断冒出新期待："这个是不是也能顺便处理一下"
• 永远处于"快了快了"的状态，因为没人知道终点在哪

为什么它是最硬的一条：边界不清的项目无法报价、无法排期、无法验收——这三件事同时失效，项目基本就失去可控性了。

实操建议：判断一个场景边界清不清楚，有个简单办法——让对方写一句话，说明这个场景里"AI 不该做什么"。写不出来的，边界大概率不清楚。

四、判据三：结果够不够可判断

要问的问题：怎么知道它做得对不对？

这一条最容易被跳过，但它决定了项目能不能被证明成功。

为什么"结果可判断"比"技术先进"重要：因为我们做过的真实项目里，最有价值的场景往往不是最炫的那个，而是能把"做对了没有"说清楚的那个。

举例：设备手册知识问答这个场景，看起来很朴素，但它有一个巨大优势——答案对不对可以核对（问一个问题，看它引的是不是手册里那一节）。因为可判断，所以能验收、能持续改进、能证明价值。反过来，一些"AI 帮我们做判断"的场景，看着高级，但正确性没法核对，项目做完也很难说清到底做成了什么。

五、三类看着好、建议往后放的场景

第三类最值得说：如果实际使用的人不觉得痛，做得再好也推不动。判断方法很简单——去问那个每天要干这活的人："这件事你希望有人替你干吗？"

六、一个筛选手法：打分排序

如果有多个候选场景，别用讨论决定，用打分：

选法：先看边界清晰度（低于 3 分直接排除，因为不可控），再在剩下的里选总分最高的。

为什么先卡边界而不是先看总分：边界不清的项目，做得越深越麻烦——它的风险不是"做砸"，是"永远做不完"。总分高但边界模糊的场景，往往是最贵的坑。

七、一个提醒：第一个项目要"小而可验证"

最后一个建议，也是最重要的一个：

第一个 AI 项目不要选"最有价值的"，要选"最容易验证成功"的。

理由不是保守，是策略：

一个小场景跑通，价值不只是"省了多少时间"，更重要的是它给了内部一个可信的样本——"这个东西真的能用"，比你讲十遍 AI 能力都管用。

反过来，第一个项目如果拖了半年还没上线，后面再推任何 AI 场景，听起来都像画饼。

所以判断顺序应该是：先挑能跑通的，再挑更值钱的。

常见问题

为什么「结果可判断」这一条这么关键？

因为它同时决定三件事：能不能验收、能不能持续改进、能不能证明价值。

一个结果可判断的场景，你可以准备一组标准问题做回归测试——上线前后对比、每月对比，退化能发现、改进能衡量。而结果不可判断的场景，项目结束时只能说"上线了"，说不出"效果怎么样"，后续也就无从优化。

实践中的判断方法很简单：试着写出 5 个能判断对错的标准问题。写不出来，说明这个场景还不适合启动。

边界不清楚的场景，实际会表现成什么样？

最典型的是"永远快完成了"：需求描述是"把我们那个流程智能化一下"，做到一半不断冒出新期待，谁都说不出什么算做完。

它的直接后果是三件事同时失效——无法报价、无法排期、无法验收。因为这三件都建立在"范围有边界"这个前提上。

识别方法也简单：让对方写一句"这个场景里 AI 不该做什么"。写不出来的，边界大概率不清楚，建议先把边界谈清楚再启动。

第一个 AI 项目做多大合适？

建议以「两到四周内能跑出可验证版本」为尺度。

这个尺度的意思是：范围要小到能快速看到实物，又要完整到能判断"到底行不行"——通常是一条主路径，加上最关键的几个边界情况，不需要覆盖全部场景。

为什么不建议第一个就做大：大项目的失败代价不只是钱，还有内部信心。第一个项目拖太久或效果说不清，会让后续所有 AI 提案都变得难以推动。而小项目跑通后，它本身就是最好的内部说服材料。

痛感来自管理层和来自一线，差别真有那么大吗？

差别很大，因为使用者不是提需求的人。

如果实际干这活的一线人员不觉得痛，项目上线后常见的结局是：没人主动用，或者用了两次又回到老办法。而管理层看到的是"系统做了但没人用"，容易误判成工具不好用，实际上问题出在场景选错了对象。

判断方法很直接：去问那个每天要干这活的人——「这件事你希望有人替你干吗？」如果对方的反应是"习惯了，还行"，这个场景的优先级就该往后放。