AI落地真相：六成项目使用率不足，幻觉、部署与Agent三大坑-平芜编程栈

上周末和一个做AI落地交付的朋友通了将近两个小时的语音。他这三年从大厂出来自己接项目，经手的行业覆盖金融、制造、客服，全是正经的企业级合同。电话挂掉之后我在书桌前坐了很久，脑子里只有一个念头反复打转：他说的每一句话，几乎都在印证我这几年的隐忧。现在「AI落地」这个词已经被讲烂了，发布会上的Demo一个比一个惊艳，可真正蹲在企业现场干活的人，看到的根本是另一番景象。这篇文章不打算总结什么方法论，只想把这次让我后背发凉的对话原原本本记录下来，给那些正准备上AI项目、或者正被各种AI焦虑裹挟的团队一个参考。

1. 开场话题：企业买回去的「AI」，有六成人只用了个聊天框

1.1 回访数据背后的真实使用率

我没寒暄太久，直接问了他一句：最近在忙什么？他苦笑了一声，说主要是在给去年的项目做回访，顺便帮客户「擦屁股」。我心里一紧，追问下去——所以之前交付的那些AI系统，到底有多少是真正在用的？

他说他们团队上个月做过一次统计，把近两年交付的三十多个项目翻了个底朝天，结论有点丧气：超过六成的客户，买回去的AI系统日常真实使用率不到一成。注意，这里说的还是「不到一成」，不是两成三成。所谓使用，多数时候就是员工偶尔打开聊天框，问一句「帮我写个周报」「把这个文档总结一下」，然后就没有然后了。真正能把这些系统接进核心业务流程、让团队天天依赖它干活的，十个里面未必有三个。

我问他，问题出在哪？是他交付的东西不行吗？他摇头，说核心问题在需求阶段就错了。很多企业把「上一个AI项目」直接当成KPI，立项的时候根本说不清楚要解决什么业务问题。领导说「别人都上了我们也要上」，采购说「先买个平台再说」，业务部门说「我不知道它能干嘛，但老板让用」。一群人热热闹闹把合同签了，系统部署完，业务侧却完全没想好AI该站在哪个环节干活。

再加上接口没打通、数据没准备好、流程没改过，AI钉在一个旧流程上，看起来像个高科技装饰品。他有一句话让我印象很深：AI落地这件事，死在技术上的少，死在「没人认真想过AI到底替谁干活、怎么干活」上的多。

1.2 制造业质检案例：AI先看一遍，人工再看一遍

他给我讲了一个制造业的例子。客户是某零部件厂，产线上原本有四个质检工位，老板听人说AI质检很厉害，花了几十万上了一套视觉检测系统。项目交付的时候演示效果确实惊艳，公开测试集上的缺陷检出率高得吓人，老板当场就很满意。

结果上了产线，问题接踵而至。现场的光线不是实验室的光线，产品批次之间又有差异，偶尔还有油污干扰，模型开始不断误判。今天把良品当缺陷踢出去，明天把缺陷当良品放过去。最后老板实在没办法，只能让AI先看一遍，人工再看一遍。原来四个人的活还是四个人干，只是旁边多了一套机器在「辅助」。这不叫降本增效，这叫花钱买了个监工。

我问他，这算不算模型选型失败？他说不是模型不行，是数据飞轮根本没转起来。工厂没有专门的标注团队，现场缺陷样本全靠几个工程师下班后手动截图，攒几个月也攒不出一个能用来迭代的数据集。模型上线那天就是它能力的天花板，往后只会越来越跟不上产线的变化。所以他跟我反复强调一个观点：AI落地这场仗，最后拼的不是算法多先进，而是数据运营的耐心和组织改造的决心。技术反而是最不稀缺的部分。

2. 大模型一本正经说假话：他在交付项目里遇见的幻觉事故

2.1 那个被编造出来的收购事件

我问了他一个自己一直很担心的问题：在交付现场，你最怕出什么幺蛾子？他想都没想就回答：幻觉。然后给我讲了一个金融项目的例子。

他们给一家企业做公告摘要和舆情分析，大模型需要读取上市公司公告、新闻，然后输出摘要。测试阶段一切正常，直到某一天，模型在一份研报摘要里生成了一条「某公司已完成对另一家公司的收购」。事实上这个收购从未发生过，纯属模型根据上下文「脑补」出来的。如果这条摘要被当成事实送进内部决策流程，后果不堪设想。

客户的第一反应是「是不是知识库放错了数据」，他们查了一圈，数据源没有任何问题，最终确认是大模型自己编的。客户当场就对AI的态度从热转冷，后面项目推进变得异常艰难。他说，他从那次之后才算真正明白：幻觉不是概率问题，是必然问题。只要让大模型自由生成，它就一定会出现一本正经的假话，区别只是什么时候出现、杀伤力有多大。

2.2 幻觉到底从哪来：它只是在「把话说圆」

我觉得很多非技术出身的朋友对幻觉有误解，这里值得稍微展开一下。大模型的本质不是数据库，也不是搜索引擎，而是一个基于海量语料训练出来的「文字接龙模型」。你问它一个问题，它输出的并不是一个从知识库里查到的答案，而是一个经过概率计算后「最像正确答案」的文字序列。

它天生优化的目标是「连贯」「像人话」，而不是「事实正确」。所以当它遇到知识盲区，或者上下文里没有足够信息的时候，它不会像搜索引擎那样坦诚地告诉你「没找到」，而是会非常自然地接着你的话继续往外编，编出来的内容越合理、越流畅，你就越难分辨真假。一个特别会聊天的朋友，聊到他不熟悉的领域时绝不冷场，而是顺着你的话讲出一段听起来头头是道的经历——这就是大模型干的事。

在企业场景里这件事尤其危险。因为老板和业务人员天然信任「白纸黑字」的输出，一旦模型用非常自信的口吻给出一个错误结论，很少会有人第一时间去质疑它。AI越强，这套「自信的语气」就越有迷惑性。

2.3 防止一本正经说假话的三道闸门

我问他，踩过这么大的坑之后，现在方案里怎么防幻觉？他说他们后来形成了一套固定的三件套做法，我听完觉得非常实用，整理成表格分享出来：

闸门	具体做法	解决的痛点
强制知识库检索	大模型只能基于给定的材料作答，不允许直接调用自身记忆自由发挥	从源头压缩编造空间
置信度分级	所有输出都做置信度打分，低置信度的结果不直接透出，转人工复核	把「不确定」的部分挡在业务流之外
高风险场景白名单	涉及金额、法律、医疗建议的内容，模型只能起草，不能定稿	控制最坏情况下的影响边界

他强调了一个词：权限。AI可以生成千万种说法，但只有经过权限审核的说法才能流出去。这句话我记了一整晚，后面的交流里反复想起它。

提示：如果你的团队准备接入大模型做业务，第一条原则就是永远别让未经校验的模型输出直接触达最终用户或决策环节。宁可让一半的请求转人工，也不能让一个幻觉结果成为既定事实。

3. 本地部署不是保险箱：数据资产与模型治理的账要分开算

3.1 「数据不出内网」不等于数据安全

话题转到数据安全。我说现在很多企业特别迷信私有化部署，觉得把模型放在自己机房里就绝对安全了，你怎么看？他听完直接说：这是一个大坑，而且跳进去的人比想象中多得多。

他见过一个客户，把开源模型部署在自己机房，逢人就自豪地讲「我们数据完全不出内网」。结果他进去做安全评估，发现问题一大串：微调用的语料没做过脱敏，员工和AI的问答记录全部落到日志文件里，日志既不分级也不定期清理；模型服务接口没有鉴权，任何一个能访问内网的普通开发都能绕过前端直接调用底层模型接口；运维后台的密码就贴在某位同事的工位上。所谓本地部署安全，只是完成了一个「物理隔离」的仪式，真正要命的数据资产管理和权限治理，一样都没跟上。

他那句话说到点子上了：数据安全根本不是「模型放在哪」的问题，而是「数据在生命周期里每一个环节有没有被管理」的问题。数据从采集、清洗、标注、微调、推理、日志留存到最终销毁，每一步都可能泄漏。本地部署只是把风险从云上搬到了自家机房，搬的时候还会顺手丢掉云厂商本来提供的那套安全护栏。

3.2 GPU、运维和迭代：本地部署的隐形账

我又问他，如果企业确实对数据有硬性合规要求，非本地部署不可，那这笔账还划算吗？他给我算了一笔细账，我听完觉得很多拍板的人根本没算过。

本地部署不是一次性投入。GPU服务器买回来只是一个开始，后面还有机房、散热、电费、专职运维工程师、依赖库版本管理、模型升级迭代。他帮一个客户做过测算，一年纯运维成本加上人力分摊，比直接调用成熟的模型API贵出好几倍，而且因为内网环境相对封闭，模型一更新，自己部署的版本就又落后了好几个大版本。

相比之下，直接调用成熟API的优势在于弹性、迭代快、安全责任由服务商承担，劣势在于数据要出域、单次调用有成本、对网络环境有依赖。如果企业没有「数据必须留在本地」的合规硬性要求，完全没必要为了心理上的安全感多花这笔冤枉钱。很多人做本地部署，是用真金白银的运维成本换一个「我们用了私有大模型」的面子。

3.3 他现在的数据合规检查清单

我让他把现在接项目时必查的数据合规清单列给我，他随口就报了一串，我当场记了下来：

数据分级：先搞清楚哪些数据能进模型，哪些绝对不能进；
语料脱敏：任何微调用语料，进训练之前必须走完整的脱敏流程；
接口鉴权与审计：调用方身份、调用时间、输入内容、返回结果全部留痕；
日志保留周期：设定上限，定期清洗，不能无限期堆着；
输出内容风控：关键词过滤、敏感内容召回、违规输出熔断；
定期红队测试：雇人假装攻击自己的系统，检验真实防御水平。

这些动作听起来一点也不性感，但每一个都是落地项目里真金白银踩出来的教训。数据安全从来不是靠一个「部署方式」解决的，而是靠一套笨拙但持续的治理动作。

4. Agent是最贵的玩具：跑不通的自动化链条卡在哪

4.1 「数字员工」交付三个月后的真实状态

聊完幻觉，话题自然滑到了最近被炒得火热的Agent上。他说现在最怕听到客户说「我们要做一套完全自动化的数字员工」。这话写在方案PPT里确实很爽，但交付之后，绝大多数Agent项目都变成了昂贵的玩具。

他讲了一个客服自动退款Agent的例子。开发环境里一切正常，Agent能识别用户诉求、查询订单、执行退款、发送通知，一气呵成。结果上线三个月，真正由Agent自动处理的订单占比不到两成，剩下八成全部转人工处理。客户很失望，但他一点都不意外。

为什么Agent在Demo里那么惊艳，一上线就拉胯？因为Demo里的数据是干净的，流程是预设好的，用户的输入是克制的。真实业务完全不是这样，真实业务里充满了歧义、错别字、情绪化的措辞、意外分支和前后矛盾的需求。只要有一个环节没考虑到，整个链条就会断掉，断掉之后的Agent不会像人一样主动求助，它更常见的反应是顺着自己的理解继续「演」下去。

4.2 链条断裂的四个典型卡点

我把聊天里他提到的Agent卡点整理了一下，发现几乎每个项目翻车都跑不出这四个坑：

卡点	典型症状	为什么总断在这里
任务边界不清	Agent要么什么都敢碰，要么什么都不敢做	没有人定义清楚AI的自主权限边界
权限与审批流未打通	流程走到一半卡在系统权限上	业务系统不信任AI，不给开写操作
工具返回结果无校验	API报错被当成正常输入继续执行	缺少对工具调用结果的验证层
异常处理靠运气	遇到没见过的措辞就直接脑补	模型没有「我承认不确定」的机制

这四个卡点我展开说一下。任务边界不清是最常见的，客户往往只丢给Agent一句「你负责处理所有售后事务」，但「所有售后事务」里哪些可以直接拍板、哪些需要请示、哪些不能碰，没有任何人梳理过。Agent主打的又是「自主行动」，边界画大了它什么都敢碰，边界画小了它什么都干不了。

权限和审批流的问题更现实。Agent能分析、能生成文本、能回答提问，但真要写系统、改数据、动钱，企业现有的权限体系根本不会给它开账号。自动化走到一半被权限卡死在半路，最后还是要人去手动操作，Agent就变成了一个「会说话但没手」的前台。

工具返回结果没有校验这个坑，往往出在调用第三方接口的时候。人家返回一个格式错误或超时，Agent不会优雅地重试，也不会把错误信息单独拎出来处理，而是直接把接口返回的乱码当成正常输入，接着往下跑流程。这种错误在Demo里几乎不会出现，因为Demo调用的都是本地Mock接口。

异常处理靠运气就更要命了。真实用户不会按培训样本说话，他们可能表达得很模糊，甚至自相矛盾。Agent遇到不认识的输入时，不会主动承认「我不确定」，而是会调用自己的推理能力，顺着某种自洽的逻辑编一个结论出来继续执行。这其实跟幻觉是同一个根源。

4.3 退款Agent差点闯祸：自动化越深，兜底越要重

他讲了一个让我真正后背发凉的细节，就是刚才说的那个客服退款Agent。

有一次用户输入的内容是「我收到的东西是坏的，但朋友说是正品」，这句话里存在明显的信息矛盾。一个正常人看到这种描述，第一反应是再确认一下，但Agent没有，它自己推理了一番，得出「用户认为商品有问题」的结论，然后在没有任何人工审批的情况下，自动退回了一笔5000元的款项。等到人工审计发现这个单子有问题的时候，钱已经退完了。

后来他们把Agent的自主退款阈值调低到500元，超过这个金额必须转人工，并且对所有包含矛盾信息的输入，一律强制人工介入。这件事给我留下的冲击很大：自动化程度越高，越需要一个足够厚重的兜底机制，否则出事的规模会跟着自动化一起被放大。你越信任Agent的「自主」，越要为它的「自主」准备几道让它碰不到重大决策的墙。

5. 越聊越冷的三个共识：从AI焦虑到组织变革

5.1 共识一：AI取代的不是岗位，是岗位里的执行密度

聊到后面，我们的语气都慢下来了。他说了一句我至今还记得的话：AI不会一夜之间替换掉一批岗位，但会悄无声息地改写每个岗位的构成。

以前一个运营助理可能要花一整天做数据报表、写周报、整理会议纪要，现在用AI两小时干完，剩下的时间变成了审核AI的成果、优化AI的指令、处理AI不敢处理的事。岗位总量没有骤减，但岗位里的「机械执行密度」正在肉眼可见地下降。不会用AI的人，最后不是被AI淘汰的，而是被那个会用AI的同事淘汰的。

他说他现在团队招聘，最看重的已经不是候选人的技术熟练度，而是「能不能判断AI给的结果对不对」。这个能力听起来很虚，实际上就是业务理解力加判断力。AI把执行成本打到地板价之后，人最值钱的部分恰恰是评价、决策和兜底。

5.2 共识二：甲方想买的是「魔法」，乙方交付的是「工程」

他有点无奈地说，这几年接项目，最难的不是技术，是预期管理。很多客户来找他们，嘴上说的是「我们要做数字化转型」，心里想的是「给我一个什么东西，我自己不用动，钱自己会赚」。甲方想要的是一键魔法，乙方能交付的是一套需要持续投入、持续维护的工程系统。

这个认知错位，是大量AI项目烂尾的根源。他见过太多客户，项目交付时兴高采烈，三个月后开始抱怨「怎么还要人管？」「怎么效果没有演示时好？」「怎么模型还会变？」他们意识不到，AI系统跟任何信息系统一样，需要数据喂养、需要规则维护、需要业务方持续参与。没有人生下来就会跑，AI也不是部署完就自动懂事。

他这几年学会的第一件事，就是接项目之前先花很长时间纠正预期，谈不拢就宁可不接。他说这话的时候语气很平静，但听得出背后的疲惫。

5.3 共识三：AI落地最终是一场组织级梳理

我们聊到所谓「成功案例」时，他的判断也让我意外：他最满意的几个项目，最后做的都不是AI的事，而是流程的事。因为你要让AI接进业务流程，就必须先把流程定义清楚，把数据标准统一，把权限边界画出来。很多企业做到一半才发现，自己最大的瓶颈从来不是算法，而是流程压根就没有标准化过。

AI在这里像一面镜子，把组织内部那些模糊的、混乱的、长期靠人肉补位的部分照得清清楚楚。他说他见过最成功的一个项目，甲方业务负责人几乎每周都亲自参加迭代评审，把业务规则一条一条跟算法团队对齐。系统最终上线之后，所有人都觉得「这系统简直是我们自己长出来的」。没有什么魔法，只有业务方和技术方咬着牙把流程拆到不能再细的功夫。