怎么判断一个 AI 场景值不值得做？
📖 摘要：企业想上 AI，卡点很少在"能不能做"，几乎都在"值不值得做"。本文给出一套可以在半小时内走完的场景筛选方法：三个判据（痛点够不够高频、边界够不够清楚、结果够不够可判断）逐条过硬标准；三类看着好但建议往后放的反面场景（涉及决策权下放、依赖外部实时数据、痛感只来自管理层）；以及一个打分排序的具体手法。核心结论：第一个 AI 项目要"小而可验证"，不要"大而全"。适合：准备启动第一个 AI 项目的企业决策者与项目负责人。
「我们也做个 AI 吧」——这句话后面跟着的点子，十个里能顺顺当当落地的不到一半。
不是因为技术做不到。恰恰相反——现在大部分被提出来的 AI 场景，技术上都能做出来。 卡住它们的是另一个问题：做出来值不值。
一、问题不是"能不能做"，是"值不值"
企业提出 AI 场景的典型形态有三种：
- 对标型：「竞品上了个 AI 客服，我们也得有」
- 触动型：「看了个 demo，这个东西不错，我们内部是不是也能用」
- 任务型：「上面要求今年要有一个 AI 落地案例」
三种都很正常，但都没有回答同一个问题：这个场景做出来，谁会用、多久用一次、怎么算它做成了？
这个问题不回答，项目就会以最难受的方式失败——不是技术上做不出来，是做出来了没人用，或者一直在改，因为没人能说清什么时候算完成。
下面三个判据，是我在真实项目里筛选场景时用的。三个都过，值得做；缺一个，就要慎。
二、判据一：痛点够不够高频
要问的问题：这个场景对应的活，一个月发生几次？
| 频次 | 判断 |
|---|---|
| 每天多次 / 每天几次 | ✅ 值得做——用起来就有价值 |
| 每周几次 | 🔶 可做——但要评估"用得少是不是因为流程还没形成" |
| 每月几次 / 更低 | ❌ 不建议先做 |
为什么低频场景不该先做：一个每月用三次的工具，即使做得好，也建立不起使用习惯——用户会忘记它存在，或者觉得"我自己弄一下更快"。而习惯建立不起来，就没有后续迭代的反馈，项目会停在"上线了但没人用"的状态。
一个容易误判的地方：不要用"这个活总共花多少时间"来判断，要用"多久发生一次"。一个每次花两小时但一年只做两回的活，不适合先做 AI；一个每次只花十分钟但每天都有的活，反而更值得。
三、判据二：边界够不够清楚
要问的问题：这个场景"什么算做完"能说清楚吗？更重要的是——"什么不做"能说清楚吗？
边界不清楚的场景，会有非常典型的表现：
- 需求谈的时候说"就是把我们那个流程智能化一下"
- 做到一半不断冒出新期待："这个是不是也能顺便处理一下"
- 永远处于"快了快了"的状态，因为没人知道终点在哪
为什么它是最硬的一条：边界不清的项目无法报价、无法排期、无法验收——这三件事同时失效，项目基本就失去可控性了。
实操建议：判断一个场景边界清不清楚，有个简单办法——让对方写一句话，说明这个场景里"AI 不该做什么"。写不出来的，边界大概率不清楚。
四、判据三：结果够不够可判断
要问的问题：怎么知道它做得对不对？
这一条最容易被跳过，但它决定了项目能不能被证明成功。
| 结果可判断 | 结果不可判断 |
|---|---|
| 能说出"对了是什么样"——比如答案引用了正确的手册章节 | 只能凭感觉："感觉好像还行"/"感觉不太准" |
| 能造出一组标准问题做回归 | 每次都换一批问题，无法比较 |
| 出了问题能定位到环节 | 只知道不好，不知道哪里不好 |
为什么"结果可判断"比"技术先进"重要：因为我们做过的真实项目里，最有价值的场景往往不是最炫的那个，而是能把"做对了没有"说清楚的那个。
举例：设备手册知识问答这个场景，看起来很朴素，但它有一个巨大优势——答案对不对可以核对（问一个问题，看它引的是不是手册里那一节）。因为可判断，所以能验收、能持续改进、能证明价值。反过来，一些"AI 帮我们做判断"的场景，看着高级，但正确性没法核对，项目做完也很难说清到底做成了什么。
五、三类看着好、建议往后放的场景
| 场景类型 | 为什么建议往后放 |
|---|---|
| 涉及决策权下放的（让 AI 直接批准 / 直接拒绝） | 判错的后果不可逆，且责任归属很难界定——适合在系统已经很稳之后再做 |
| 依赖外部系统实时数据的 | 技术上不难，但卡在对接排期和权限上，工期不可控——先做不依赖外部的好 |
| 痛感只来自管理层的 | "老板觉得这个痛"和"一线觉得这个痛"是两回事——前者推动的项目，一线往往不愿用 |
第三类最值得说：如果实际使用的人不觉得痛，做得再好也推不动。判断方法很简单——去问那个每天要干这活的人："这件事你希望有人替你干吗？"
六、一个筛选手法：打分排序
如果有多个候选场景，别用讨论决定，用打分：
| 维度 | 1 分 | 5 分 |
|---|---|---|
| 痛点频次 | 每月几次 | 每天多次 |
| 边界清晰度 | 说不清不做什么 | 一句话能说清范围和禁区 |
| 结果可判断 | 只能凭感觉 | 有明确的对错标准 |
| 不依赖外部 | 需接多个外部系统 | 数据和使用都在内部 |
选法：先看边界清晰度（低于 3 分直接排除，因为不可控），再在剩下的里选总分最高的。
为什么先卡边界而不是先看总分：边界不清的项目，做得越深越麻烦——它的风险不是"做砸"，是"永远做不完"。总分高但边界模糊的场景，往往是最贵的坑。
七、一个提醒：第一个项目要"小而可验证"
最后一个建议，也是最重要的一个：
第一个 AI 项目不要选"最有价值的"，要选"最容易验证成功"的。
理由不是保守，是策略：
| 第一个项目 | 结果 |
|---|---|
| 大而全、周期长 | 出了问题没有参照物；内部信心消耗快；说不清是选错了方向还是执行不到位 |
| 小而可验证 | 两三周能看到实物、能验证对错；跑通了就有内部的可信证据；第二个项目顺利得多 |
一个小场景跑通，价值不只是"省了多少时间"，更重要的是它给了内部一个可信的样本——"这个东西真的能用"，比你讲十遍 AI 能力都管用。
反过来，第一个项目如果拖了半年还没上线，后面再推任何 AI 场景，听起来都像画饼。
所以判断顺序应该是：先挑能跑通的，再挑更值钱的。
常见问题
为什么「结果可判断」这一条这么关键？
因为它同时决定三件事：能不能验收、能不能持续改进、能不能证明价值。
一个结果可判断的场景，你可以准备一组标准问题做回归测试——上线前后对比、每月对比，退化能发现、改进能衡量。而结果不可判断的场景，项目结束时只能说"上线了"，说不出"效果怎么样"，后续也就无从优化。
实践中的判断方法很简单：试着写出 5 个能判断对错的标准问题。写不出来，说明这个场景还不适合启动。
边界不清楚的场景，实际会表现成什么样？
最典型的是"永远快完成了"：需求描述是"把我们那个流程智能化一下"，做到一半不断冒出新期待，谁都说不出什么算做完。
它的直接后果是三件事同时失效——无法报价、无法排期、无法验收。因为这三件都建立在"范围有边界"这个前提上。
识别方法也简单：让对方写一句"这个场景里 AI 不该做什么"。写不出来的，边界大概率不清楚，建议先把边界谈清楚再启动。
第一个 AI 项目做多大合适？
建议以「两到四周内能跑出可验证版本」为尺度。
这个尺度的意思是：范围要小到能快速看到实物，又要完整到能判断"到底行不行"——通常是一条主路径，加上最关键的几个边界情况，不需要覆盖全部场景。
为什么不建议第一个就做大：大项目的失败代价不只是钱，还有内部信心。第一个项目拖太久或效果说不清，会让后续所有 AI 提案都变得难以推动。而小项目跑通后，它本身就是最好的内部说服材料。
痛感来自管理层和来自一线，差别真有那么大吗？
差别很大，因为使用者不是提需求的人。
如果实际干这活的一线人员不觉得痛，项目上线后常见的结局是：没人主动用，或者用了两次又回到老办法。而管理层看到的是"系统做了但没人用"，容易误判成工具不好用，实际上问题出在场景选错了对象。
判断方法很直接：去问那个每天要干这活的人——「这件事你希望有人替你干吗？」如果对方的反应是"习惯了，还行"，这个场景的优先级就该往后放。
相关文章：客户说要「多智能体」，先别急着答应（技术架构层的真伪需求判断，与本篇的业务场景层判断配合使用）｜知识放哪、执行放哪、流程放哪：AI 落地三形态选型总览（场景确定后的形态选择）｜AI 项目的钱，花在哪最容易超支？（边界不清对预算的影响）
本文基于真实交付项目的场景筛选经验撰写（2026-08），判断判据在设备手册知识库等实际项目中应用并验证。文中不含与具体供应商选择相关的建议。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实交付记录。
