不是每个痛点，都值得上AI 

一张打分表，决定你手上那一堆想法先做哪个

Jimmy营销公式 · 用模型拆 AI 落地

帮企业上 AI 失败，十有八九不是技术不行，是场景选错了。

多家机构在 2025 年陆续发布的数据，指向同一个结论：企业做过的 AI 试点里，真正走到正式上线、进了生产环境的，往往不到两成；更多的项目停在演示阶段，半年后被无声下线。

有人把它叫"试点黑洞"——演示那天全场鼓掌，三个月后没人再提。

与此同时，这些项目里，相当一部分技术上是跑通的。模型能答、界面能用、Demo 能录。问题出在更早的地方——这件事从一开始，就不该排在第一位。

选错场景的代价，比做砸一个项目还大。做砸了，客户知道是这一件事没做好；选错了，客户会得出一个更大的结论——"AI 这东西在我们这儿没用"。

这个结论一旦形成，你在同一家公司里就很难有第二次机会了。

那么，进了客户公司之后，第一个AI落地的项目 / 业务 / 场景，应该怎么选？

我前阵子在公众号上看到一个很好的方法论，叫做：业务价值度 × 技术可行性。

这篇文章，我把那位作者的模型拆解了一下，做成了6张实战卡。

欢迎阅读，欢迎一键三连。

PART 01 · 三种选法

场景是怎么被选错的

我见过大部分团队选场景，逃不出这三种方式，而三种都是错的。

• 按嗓门选。谁在会上提得最激动，就先做谁的。问题是，最激动的人往往是最不懂可行性的人，他描述的是疼，不是可做的方案。这类项目上线后最常见的结局是：做出来了，但没人认领——因为当初喊得最响的那位，根本不是用的人。

• 按新鲜选。老板周末看了一场发布会，周一把那个方向扔给了团队。于是选择标准变成了"外面最近在讲什么"，而不是"我们这儿最疼什么"。新鲜感驱动的选题，通常三个月后就过时，而你的项目周期往往比三个月长。

• 按难度选。技术团队倾向于挑有挑战的做，因为做重复的简单活没成就感。结果是最难啃的先上，三个月啃不动，团队信心先崩了。更要命的是，这类项目做完往往只能 demo，因为难的不是算法，是它背后的数据根本没准备好。

这三种选法的共同问题是：它们都在回答"我们想做什么"，而不是"我们该先做什么"。一个连排序都没有流程的团队，再多技术储备也只会变成一堆零散的 demo。

最该先做的那个场景，往往是最不性感的。它高频、规则固定、数据现成，讲出来没人鼓掌——但它能上线，而能上线这件事，比什么都重要。

PART 02 · 提问顺序

先问该不该做，再问能不能做

顺序很重要。大多数团队的默认顺序是反的——先问"技术上能不能做"，能做就做。这个顺序会天然把项目引向灾难。

因为技术团队永远能找到能做的方案，而"能做"和"该做"之间隔着整个商业逻辑。一个"能做"的项目，可能做完才发现没人需要、没法证明价值、老板也不认。

正确的顺序是两问：

第一问（业务价值度）：这件事做成了，对业务到底有多重要？

第二问（技术可行性）：以现在的底子，能不能真的做成？

场景选择公式

场景优先级 = 业务价值度 × 技术可行性

两轴各五项、各 1–5 分，双轴都过 15 分才立项

注意这里是乘法，不是加法。

为什么？因为加法，允许"技术上很牛但业务上没人需要"的东西蒙混过关。

设想一个项目：业务价值打 22 分（满分 25），技术可行只打 8 分——因为数据散、规则乱、要动五个老系统。如果用一个总分（22+8=30）去比另一个均衡项目（18+18=36），它只差一点，看着还行，于是排进了第一版。结果就是前面说的：演示能跑，上线卡死。

换成乘法，算式变成 22×8=176，而均衡项目是 18×18=324——前者直接被甩开一倍多。乘法不会让"一轴塌了另一轴来补"这种话成立。任何一轴塌到个位数，总分就崩了，想赖都赖不掉。

任何一个轴塌了，整个场景就是零。

这也解释了为什么"看起来很美"的项目最危险——它的价值轴往往很高，可行性轴很低，而人天生容易被高价值那一侧吸引。

PART 03 · 第一轴：业务价值度

业务价值度：这件事值不值得做

五项，每项 1 到 5 分，满分 25 分，15 分是分界线。打分的刻度我给死了，你照着打就行：

打分项	1 分	5 分
发生频率	一年碰上几次	每天几十次，躲不开
收益可量化	说不清省了多少，只能说"效率提升"	能算到具体数字：省几个人、少几小时
影响面	只影响一两个人的工作	整条业务链都会跟着变
贴不贴主线	跟公司今年要打的仗没关系	正面顶在今年的核心目标上
决策者会不会拍板	老板从没提过这事	老板自己反复提，且愿意给资源

拆解一下这五项：

• 频率，决定它值不值得被自动化，一年三次的事再疼也不值得先做；
  

• 可量化，决定你做完能不能证明，证明不了等于白做；
  

• 影响面，决定它值多少钱，只影响一个人的活，天花板就摆在那儿；
  

• 贴主线，决定资源会不会持续供给，不贴主线的事，年中一砍预算第一个死的就是它；
  

• 决策者拍板，决定它能不能真的发生。

这五项里最容易被忽略的是最后一项，也最致命。

我见过技术上完全跑得通、业务上也真有价值的项目，最后死在没人拍板上——因为真正握资源的人从来没觉得那是他的事。它可能是某个总监的心血，但老板心里那本账上没这一笔，于是资源给一半、优先级排末尾、出了事没人兜底。

这种项目不是做不成，是做成了也没人认。

还有一个提醒："收益可量化"打低分的项目，不要进第一版。

不是因为它没价值，是因为你做完了没法证明。做完了没法证明，就等于没做——客户记不住"感觉快了点"，只会记住"花了钱没看到数"。所以这一项低分，宁可先攒着，等它有了可量化的切口再动。

PART 04 · 第二轴：技术可行性

技术可行性：现在能不能真的做成

这一轴问的是：以客户现在的底子，而不是以理想状态，这件事能不能落地。

很多人打分习惯性往好了打——"数据以后会有的""规则应该能整理出来"。

别，按事实打。

打分项	1 分	5 分
数据现不现成	散在聊天记录和纸质单据里	已在系统，随时能取、口径统一
规则稳不稳定	全靠老师傅的经验和手感	有成文标准，新人照着做也能做对
错了代价多大	出错就是资金或合规事故	错了重来一次就行，无外部影响
能力成不成熟	行业里基本没人做成过	是已被验证过的成熟能力
要动多少老系统	要打通五个以上老系统、涉及权限改造	基本不用动现有系统，或只需读数据

这一轴里最值得注意的是第三项：错了代价多大。

很多人以为这是风险问题，其实是成本问题——容错空间小的场景，你必须配人工复核、留证据链、做回归测试，这些加起来才是它的真实成本。

同样是"自动化"，一个错了能重来的场景，和一个错了要赔钱的场景，工作量差三倍以上。所以这一项打 1 分的场景，不是说不能做，是说它不该是你的第一单。

另外：数据现不现成，是最容易被高估的一项。

几乎每个客户都会说"我们数据都有"，但你真去查，会发现一半在私人表格里、一半在聊天记录里、真正在系统里且口径统一的没几张表。

所以这一项如果靠"他们口头说有"来打分，往往会往高了打——务必按"今天能不能真的取出来、取出来口径一不一致"来打。

分享一个技巧：把场景切到足够小，小到数据能搞干净；数据搞干净，结果才可信。

很多人一上来就想做一个"大系统"，但大系统意味着散在十几个地方的数据，任何一块不齐都做不成。反过来，先把一个小环节做透，数据范围收窄了，反而容易做成。做成之后，再顺着同样的办法复制下一个小环节。

PART 05 · 算一遍

拿两个真场景算一遍

假设客户手上只有两个想法：A. 客服常见问题自动回复，B. 合同条款风险审查。老板直觉想先做 B，因为 B 听起来更值钱、更"高级"。我们打一遍：

打分项	A 客服回复	B 合同审查
发生频率	5（每天上百次）	2（一周几份）
收益可量化	4（能算节省的工时）	4（能算法务工时）
影响面	3（主要在客服部）	5（出一次事损失巨大）
贴不贴主线	3（相关但不核心）	4（今年在控风险）
决策者拍板	4（老板提过客诉多）	5（老板高度关注）
业务价值合计	19	20
数据现不现成	4（历史对话都在系统里）	2（历史合同多是扫描件）
规则稳不稳定	3（常见问题有标准答案）	2（高度依赖法务经验）
错了代价多大	4（答错了人工接手）	1（漏审一条可能赔很多）
能力成不成熟	5（成熟能力）	3（有人做但不多）
要动多少老系统	2（要接工单系统）	1（要接合同管理系统）
可行性合计	18	9
结论	立刻做	先治底子

结果很清楚：B 的业务价值（20）其实比 A（19）还高一点，但可行性只有 9，双轴一乘就废了。

如果按"老板最关心哪个"来排，一定会先做 B，然后死在数据上——历史合同是扫描件，光结构化就要几个月；判断标准在法务脑子里，没人写得出来；容错空间还极小。

而 A 虽然不性感，但它能上线。能上线这件事，会替你换到第二单、第三单。

更重要的是，A 做成之后，你顺手积累了"对话数据清洗"这件事的能力，等 B 的底子治得差不多了，再做 B 会快得多。

这就引出一个很实在的规律：垂直场景的第二次，往往只要第一次三成的成本——因为数据管道、验证方法、上线流程都能复用。所以先做能做的，不是将就，是在为后面那个"更值钱但更难"的场景铺路。

再补一个"看起来很美"的第三种场景 C：老板在行业大会上看到的一家"AI 智能体大屏"。

业务价值每一项都按"应该很有用"打了高分（合计可能到 22），但可行性一打：数据散在十几个系统、规则靠几个老员工口口相传、出错影响对外披露、要打通五六个老平台——可行性合计可能只有 7。

这种项目我见过太多次，它最大的陷阱是：价值轴高得让人舍不得放，但乘完那一栏，它根本进不了第一版。表格存在的意义，就是保住你对这件事的判断力，不被"它听起来很厉害"带跑。

PART 06 · 否决项

分数再高也不能做的三种情况

打分表不是万能的。有三类场景，分数打得再高也直接出局，它们不是打分项，是否决项——任何一条成立，不用打分，直接否掉。

一票否决：数据碰不得。

涉及不能访问、不能传出、不能长期保留的数据，且短期内拿不出脱敏方案。这不是技术难度问题，是能不能立项的问题。很多金融、医疗场景卡在这条，不是做不出，是合规上根本不允许你现在做。

一票否决：找不到 owner。

项目里没有一个能对结果负责、能跨部门调动资源的人。这种情况分数打得再漂亮，最后都会卡在同一个地方——"谁来推"。牵头人是个刚升职、跨不动部门的经理，大概率就是三个月里开了十一场会，没推动任何一件事，最后不了了之。

一票否决：一线抵触且没人去谈。

如果这件事会让某个岗位的工作被替代，而项目里没有任何人负责跟他们谈，那上线那天就是它死的那天。人不会因为"系统更先进"就乖乖用，他们会因为"这东西要取代我"而悄悄抵制——不录入、不配合、出了问题第一时间说是系统不行。

PART 07 · 四象限

打完分，把想法分成四堆

两轴各有 15 分这条线，交叉一下就是四个格子。每个格子的处理方式完全不同：

格子	分数	怎么处理
立刻做	价值 ≥15，可行 ≥15	这就是第一版。全部资源压上去，做到上线
先治底子	价值 ≥15，可行 <15	不是不做，是现在做不动。先把数据、规则整理好，下个季度再动
拿来练手	价值 <15，可行 ≥15	做得动但意义不大。可以做，用来练兵和建立信任，但别当商业项目报价
明确砍掉	双低	写清楚为什么不做的理由，让对方确认

敢砍需求，是你从执行方变成判断方的第一步。

一个从不说不的团队，客户只会把它当接单的；

一个能说清"这个现在做不动、原因是数据还没整理"的团队，客户才会把它当顾问。

最后，这个矩阵里，还有两条潜规则。

第一，"立刻做"那一格，最好只有一个。

如果你打完分发现三个想法都进了这一格，说明你的分界线松了，或者你的资源其实不够。第一版只能压一件事——压三件事的结果通常是三件都停在演示阶段。

第二，"先治底子"这一格最容易变成无底洞。

要给它设明确的复审时间，比如"三个月后数据整理完，我们重新打一次分"。没有复审时间，它就永远是"以后再说"，最后不了了之。

PART 08 · 指标三层塔

最后一道筛子：效果停在哪一层

打完分还没完。最后要问自己：这个项目做完，我能承诺的效果停在哪一层？这一问，往往是压垮"看起来很美"项目的最后一根稻草。

层	典型指标	谁看得懂
模型层	准确率、幻觉率	只有做技术的人关心
流程层	处理时长、一次通过率	业务部门负责人关心
业务层	成交率、成本、客诉量	老板关心

绝大多数 AI 项目死在模型层——汇报时讲准确率从 82% 提到 91%，台下老板礼貌地点头，心里想的是"所以呢"。

怎么办？

给你一个最核心的法则，叫做“So What”：每上一层，都问一句"So What"。

准确率从 82% 提到 91%。

so what？ 

所以一次通过率从 40% 提到 75%。

so what？

所以人工复核量减半。

so what？

所以单票处理成本从 12 元降到 6 元。

问不到第三层，说明这个场景的价值链是断的。

这也解释了为什么有研究把上线后的问题拆开看，发现大约七成卡在人和流程（变革管理、工作流改造、权责划分），真正卡在技术本身的只有两成左右。模型跑得好，不等于它进了业务流程；进了流程，不等于它产生了老板看得见的业务数字。

只有走到第三层，这个项目才真正进入企业的价值链。停在第一层的项目注定验收不了——不是做得不好，是没人能用它做决策。

PART 09 · 分差

这张表在会场上怎么用

这张表最好用的地方，不是打出分数，是让人分头打一遍然后比。一个人打分，分是主观的；三个人各自打，分差会替你把问题暴露出来。

具体做法：让客户那边三个人各自独立打分——一个管业务的、一个管数据的、一个真正干活的一线。三张表收回来放一起看。

这时候会出现两种情况。某一项三个人打分很接近，说明这件事大家有共识，可以按分数走。但如果某一项分差拉得很开（比如业务的人打 5 分、数据的人打 1 分），那里就是你们最大的认知裂缝。

打分不是考核，是给团队一个共同语言。分数差太多，说明假设还没对齐——而把假设对齐，本身就是进场第一个月最值钱的产出。

业务的人以为数据都在系统里，数据的人知道有一半在私人表格里；一线以为这个流程每天几十次，老板以为一个月几次。这些裂缝不摊开，就会变成三个月后的返工。而把它们摊在桌面上，只需要二十分钟。

这场会怎么开（15 分钟就够）

• 第一步，把所有待选的想法写在白板上，不讨论、不排序。

• 第二步，每人拿一张表独立打分，全程不许讨论。这一步很关键——一旦开口，第一个说的人就会锚定所有人。

• 第三步，同时亮分。

• 第四步，只讨论分差大于 2 分的项，其余按平均分走。你会发现问题往往不在分数上，而在大家说的根本不是同一件事。

怎么把"不做"说出口

打分表最难的一步不是打分，是汇报——你得告诉老板"你最想要的那个，我们建议先别做"。这句话说不好，前面的分数全白打。我用一个三句结构：

• 第一句，说砍了什么："合同审查这个我们先不排在第一版。"不要铺垫，直接说结论。

• 第二句，说为什么，而且必须是可改变的原因："因为历史合同大多是扫描件，判断标准也还在法务的脑子里，这两件事没解决之前硬做，做出来的东西没人敢用。"

• 第三句，说什么时候能做："把这两件事整理完，它的可行性会从 9 分变成 18 分。我们三个月后重新打一次分。"

PART 10 · 整个模型，和营销底层同源

营销人看到这里应该笑了

这张表本质上在干什么？资源有限的时候决定先做哪件事。这件事我们这行干了十年，只是换了几个名字。

FDE 里说的	市场营销里的
业务价值度打分	卖点取舍、主推什么
技术可行性打分	这个创意执行不做得出来、成本多少
四象限排优先级	媒介排期、预算分配
指标三层塔	曝光、转化、营收的指标分层
明确砍掉的想法	brief 收敛、跟客户说"这个不做"

五件事，一件不差。

区别只是过去这些判断写在提案里、含在服务费里，客户看不见；现在它有了名字、有了分数、能单独成一份交付物。

所以当你跟客户讲"先做哪个场景"的时候，你不是在卖技术，你是在卖判断——而这恰恰是你最值钱、也最不容易被替代的那部分。

写在最后

选场景，是这门手艺里最像判断的一步

技术会越来越便宜，模型会越来越强，唯一不会贬值的是判断先做哪一个的能力。今天你多会选一个场景，明天就少陪跑一个无底洞。

先做哪个，比做得多好，
更决定这门生意能不能活下去。

回到开头那个数字：多数 AI 试点停在演示阶段，不是因为做不出 demo，而是因为从来没人认真回答过"先做哪个"。

一张表、两个小时、一次坦诚的打分，就能把很多项目从"试点黑洞"里捞出来。这件事，你今天就能做，不需要等任何技术升级。

— Jimmy营销公式 · 用模型拆 AI 落地 —