什么情况下不该做 AI 落地

说"不该做"这件事，不太受欢迎

我们每次诊断，说"这件事不该做"的比例不低。

这个结论对客户是省钱的，对我们是不赚钱的——因为诊断不收费，说完不该做，这单就没了。

但还是要说。原因很简单：大部分失败的项目，不是技术不行，是一开始就做错了。 做了一件不该做的事，越努力，浪费越大。

下面四种情况，我们见到的最多。

第一种：规则能解决的

这是最常见的一种。

某个审批要判断"这笔费用超没超标准"，某个订单要判断"这个客户有没有超信用额度"，某个库存要判断"要不要补货"。这些事情有明确规则，写进代码就是几十行 if-else。

但有人会用 AI 去做。

结果是：更贵、更慢、还不准。因为模型是概率输出，同样输入可能给不同答案；而规则是确定的，可追溯、可审计、可复现。

判断方法很简单：这件事能不能写成"如果……那么……"？ 能，就用规则。

规则解决不了的是模糊判断——比如"这段客户投诉的语气算不算严重"、“这张单据的照片是不是同一个货品”、“这通电话里客户提到的需求是什么”。这些没有明确边界，才是模型该上场的地方。

第二种：数据基础不具备的

模型不产生信息，它加工信息。没有可用的数据源，它加工不出东西来。

我们见过的情况：客户想做"智能排产"，但车间的工序数据还在纸上；想做"库存预测"，但历史出入库记录散在三个系统里且对不上；想做"客户流失预警"，但客户信息和订单信息不在同一个地方。

这些不是"AI 做得不好"，是"AI 无从下手"。

这时候正确的动作是先做数据治理，不是先做 AI。 数据治理听起来不性感，但它是能往下走的那条路。

判断方法：问一句"这件事的判断依据，现在存在哪个系统里、谁在维护、准不准"。答不上来，就先别做。

第三种：需求还在变、决策人不在场

这两件事经常一起出现，而且互相放大。

需求还在变，意味着范围无法固定。决策人不在场，意味着范围没人能拍板。两个条件同时成立，项目就会变成一个无底洞——每次沟通都要重新确认，每次确认完又变，最后期限和预算都失控。

我们有一个硬性要求：诊断需要决策人在场。 不是要签字，是要在场听、在场问、在场判断。因为很多问题只有决策人能回答：这件事现在是谁在做、做错了有什么后果、谁能拍板、预算大概什么范围。

决策人不在场的诊断，效果会打折扣。这句话我们写在联系页上，不是客套。

第四种：只想做演示

给客户看、给银行看、给投资人看、给上级检查看。

这类需求是真实存在的，我们不评价它的合理性。但要说清楚：演示和上生产是两件事，需要的能力完全不同。

演示只需要"能跑通一次"，可以人工兜底、可以挑最好的输入、可以重来。上生产需要"每天都跑通"，要考虑异常、要考虑数据漂移、要考虑有人在用的时候出错怎么办。

我们不做纯演示项目。原因不是清高，是这类项目没有"采用"这个环节——三条判据里的第二条（是否对采用率负责）直接失效，剩下的就只有"做出来了吗"，那和外包没有区别。

如果确实只需要演示，找做演示的团队更合适，也更便宜。

怎么自己判断

不用等诊断，三个问题可以先自问。

第一，这件事现在浪费了多少钱？

算得出来，才有预算讨论的基础。算不出来，说明连问题本身都没定义清楚。

比如"每天录单 4 人小时"，一年 250 个工作日就是 1000 小时，按人力成本折算，这就是你能接受的最大投入。这个数字算出来，后面的讨论才有意义。

第二，判断这件事的依据，现在存在哪里？

在系统里、在 Excel 里、还是在某个人的脑子里。在脑子里，就得先把它结构化；在 Excel 里，就得先把它搬进系统。这两种情况都要先做基础工作。

第三，这件事做错了，后果是什么？

后果严重且不可逆的场景（比如涉及诊断、涉及资金划转、涉及安全），要格外谨慎。这类场景不是不能做，是必须有"人在回路"的设计，让机器给建议、人做决定。

最后

说"不该做"不是消极。恰恰相反，知道什么不该做，才知道什么该做。

一个什么都愿意接的服务商，通常意味着他没有判断能力，或者他不打算对结果负责。因为真的做过项目的人，都知道有些事做了是害客户。

我们的六条边界写在 常见问题 里：不做纯演示、不做技术锁定、不承诺保证提效、不按人天报价、不接数据基础不具备的、不做规则能解决的事。

这六条不是营销话术，是拒单标准。如果你遇到的服务商什么都能接，可以拿这六条对一下。

想知道这六条背后完整的交付方法，看 方法论。想知道具体行业怎么判断，看 行业方案。