AI狂热正在掏空企业决策：从模型崇拜、Token指标到AI网关治理

摘要企业使用AI的速度正在明显快于企业证明AI价值的速度。很多公司已经采购模型、建设智能体、上线内部聊天机器人却说不清这些工具究竟有多少人在用、解决了什么问题又产生了多少可核算的收益。技术并不是唯一障碍。更棘手的问题是当“必须拥抱AI”变成组织里的正确答案项目负责人不愿承认失败员工不敢公开质疑管理层最终只能看到一组经过包装的数据。本文从《AI Mania Is Eviscerating Global Decision-Making》一文出发结合行业调查与企业AI治理实践分析AI项目为什么容易陷入“演示成功、业务失败”以及企业如何通过指标、流程和AI网关重新建立决策依据。一、当AI从工具变成一种“组织正确”2026年7月Ludicity发布了一篇题目很重的文章《AI Mania Is Eviscerating Global Decision-Making》直译过来就是“AI狂热正在掏空全球决策”。作者曾与全球各地的从业者交流300多次对象包括一线员工、技术负责人和世界500强高管。他观察到很多公共机构和大型企业正在进入一种奇怪的状态相信AI的人不断加码心里没底的人不敢说话。管理层要么没有清楚的计划要么知道计划有问题却只能继续配合。作者还提到过去一年半其团队参与或旁观的AI项目成功率为0%。这只是作者团队的项目观察不是全球统计但它点出了文章真正想讨论的问题当AI变成组织里的正确答案企业会逐渐失去承认项目失败的能力。有些高管甚至没有真正使用过大模型却已经制定出以AI为中心的公司战略。员工则被要求反复表态证明自己理解AI、使用AI、支持AI。“AI正在改变一切”成了一句很安全的话。反过来问一句“它具体改变了什么”却可能让会议突然安静。二、AI项目失败往往不是模型的问题原文的一个重要判断是很多AI项目的失败与LLM能力没有直接关系。企业本来就不擅长运行软件项目。目标定义模糊、数据基础混乱、部门责任不清、上线后没人持续维护这些问题在传统IT项目里已经存在多年。AI项目在此基础上又增加了新的风险模型输出并不完全确定费用会随着上下文和调用次数变化上游服务可能限流、超时或临时不可用输入内容可能包含个人信息和企业敏感数据智能体可能因为程序缺陷陷入循环调用错误结果看起来依然流畅、合理很难被及时发现。RAND在《The Root Causes of Failure for Artificial Intelligence Projects》中访谈了65名有经验的数据科学家和工程师将AI项目失败原因归纳为几类问题没有定义清楚、数据不足、追逐新技术、基础设施不完整以及任务本身超出了AI的可靠能力。换句话说如果一个团队连普通的软件项目都经常延期、失控换成AI之后不会突然脱胎换骨。Google DORA团队在2025年AI辅助软件开发报告中也给出了类似结论AI会放大团队原有的状态。流程清楚、反馈及时的团队更容易受益原本就混乱的团队问题也会一起加速。三、内部聊天机器人为什么经常没人用企业最常见的AI项目之一是内部知识聊天机器人。管理层希望员工可以直接提问例如报销流程怎么走某个客户的历史合同在哪里新员工如何申请系统权限公司的产品定价规则是什么思路没有问题问题通常出在知识源。不少企业的内部文档长期没有维护。同一个制度散落在邮件、网盘和聊天记录里不同版本互相冲突很多经验甚至只存在于老员工的脑子里。大模型不是读心术。没有被记录、没有开放权限或者已经过期的信息模型不可能自动补齐。员工尝试几次发现答案不准还不如直接问同事很快就会放弃使用。这类项目失败后团队往往继续调模型、改提示词却不愿承认真正需要修的是企业自己的知识管理。于是一个文档治理问题被包装成了模型能力问题。四、AI客服的指标可能很好客户却已经离开原文还记录了一次三菱客服经历。作者的汽车发生故障后拨打客服电话。AI语音非常自然响应也很快还承诺稍后会有工作人员回电。六个月过去他没有接到电话。从客户角度看这次服务显然失败了。但在企业后台这通电话可能没有触发任何错误。系统成功接听了电话机器人正常完成对话没有转接人工也没有产生技术异常。如果管理层只看自动接待率、通话时长和人工分流率这次交互甚至可能被记录为一次成功案例。客户的问题没有解决却从数据里消失了。这正是很多AI项目最隐蔽的问题系统运行指标被当成了业务结果。企业至少需要区分三层数据指标层级常见数据回答的问题系统运行指标请求成功率、延迟、错误率、Token消耗系统能不能运行任务完成指标一次解决率、人工接管率、返工率、答案准确率AI有没有完成任务经营结果指标客户满意度、流失率、单位成本、收入、风险损失项目值不值得继续投入调用量只能证明有人调用。Token消耗只能证明企业花了钱。它们都不能单独证明生产率提高了。五、AI演示为什么特别容易影响决策原文作者曾向客户展示过一套用自然语言查询企业数据的AI工具。客户原本对其他项目兴趣一般看到AI聊天界面之后态度却迅速改变。即使演示人员已经说明这项功能的准确率和生产可用性存在问题客户仍然希望立即购买。这是因为AI演示提供了一种非常直接的控制感。过去管理者想查看上周收入需要找到数据分析师、确认口径、编写查询再等待报表。现在只要输入一句话数字就会立刻出现。至于数字是否准确、使用了哪张表、过滤条件是否正确反而不容易在演示现场被注意到。一个准确率92%的财务查询系统看起来已经很先进。但换个角度理解就是大约每十个数字里可能有一个错误。如果这些数字进入预算、贷款、医疗或经营决策8%的错误并不是小问题。AI演示回答的是“这个界面看起来是否聪明”生产系统必须回答“错误发生时企业能否发现并处理”。六、当Token使用量变成KPI员工就会开始表演部分企业为了推动AI应用会统计每名员工使用了多少Token、调用了多少次模型甚至设置Token排行榜。这个指标很好统计也很容易被操纵。原文提到有工程师为了满足公司的AI使用要求让模型在后台反复执行没有实际意义的任务自己继续按照原来的方式工作。任务完成后再向管理层表示成果由AI辅助完成。员工并不是不知道这样做没有价值。他们只是在回应公司设定的考核方式。类似情况还包括普通数据库迁移被重新包装成AI项目原本人工完成的工作被描述成模型生成为了增加调用量把一次任务拆成多次请求明知AI输出需要全部重做仍然保留“AI参与”的项目标签不适合使用AI的环节也被强制接入模型。当“是否使用AI”比“是否解决问题”更重要时组织获得的就不再是真实反馈。它只能看到员工对指标的服从。七、行业数据也说明采用率与经营回报并不同步麦肯锡在《The State of AI 2025》中调查了105个国家的1993名受访者。88%的受访者表示其所在组织已经在至少一个业务环节中使用AI。但只有大约三分之一的企业进入规模化阶段。39%的受访者认为AI对企业EBIT产生了某种程度的影响其中多数人报告的影响低于5%。被麦肯锡定义为“AI高绩效企业”的受访者约占6%。AI并非没有价值。发表于《经济学季刊》的《Generative AI at Work》研究了5172名客服人员。结果显示AI助手让每小时解决的问题数量平均提高15%对经验较少的员工帮助更明显。但效果高度依赖任务和人员。METR在2025年的开发者实验中发现16名熟悉大型开源项目的资深开发者使用当时的AI工具后完成任务所需时间反而增加了19%。这两个结果可以同时成立。在问题相对稳定、答案可以复用的客服辅助场景里AI能够把优秀员工的经验传递给新人。在需要理解大型代码库、处理隐含约束的任务中资深开发者反而要花时间检查和纠正模型输出。企业真正需要判断的是AI是否适合眼前这个任务。八、怎样让组织重新获得真实信息原文给出了一些非常实用的建议。1. 少在大会上询问项目是否成功公开会议会让人担心自己的立场。项目负责人不愿在同事面前承认判断错误员工也不愿公开反对高层已经支持的方向。一对一沟通更容易获得真实反馈。2. 对项目成功概率做匿名评分可以让项目参与者匿名给成功概率打分例如1到10分。如果管理层普遍打8分一线执行人员普遍只打3分说明项目内部存在大量没有向上传递的信息。3. 直接询问一线用户判断内部聊天机器人是否有效不能只问项目负责人。应该问真正使用它的员工最近一周用了几次哪类问题可以解决哪些答案需要重新核对不使用它时原来的流程要花多长时间使用之后实际节省了多少时间一线用户未必能判断模型技术水平但他们最清楚工具有没有进入日常工作。4. 提前设置退出条件企业应该在项目启动时写清楚预算上限、效果下限和观察周期。如果达到停止条件项目就应该暂停或调整。终止一个无效项目是正常管理行为不是反对AI。九、制度之外还需要一个技术治理入口只靠通知和员工自觉很难治理已经规模化的AI调用。当不同部门分别采购模型、保存API Key、运行Agent和调用外部服务时管理层往往无法回答几个基本问题公司到底连接了多少家模型供应商哪些应用正在持续消耗Token费用应该归属到哪个部门和项目离职员工的密钥是否已经失效敏感数据有没有被发往外部模型某个Agent出现循环调用时谁能及时停止NIST的AI风险管理框架将AI治理分为Govern、Map、Measure和Manage四类持续工作。企业既要明确规则和责任也要盘点系统、测量效果并在上线后处理风险、事故和变更。企业AI网关承担的就是其中一部分运行层治理工作。十、企业AI网关解决什么问题企业AI网关位于员工、Agent、业务应用与模型服务之间。员工 / Agent / 业务系统 | v 企业AI网关 ┌────────────────────┐ │ 身份认证与权限检查 │ │ 令牌、配额与预算 │ │ 敏感数据处理 │ │ 路由与故障切换 │ │ 成本归属与调用日志 │ └────────────────────┘ | ┌──────┼──────┐ v v v 公有模型 私有模型 本地GPU外部模型供应商的API Key由网关集中保管内部应用使用企业签发的受控令牌。每个令牌可以关联部门、项目、用户或具体应用。企业由此可以看到谁调用了哪个模型、消耗多少Token、产生多少费用以及是否触发了权限或安全策略。网关还能为Agent设置调用频率、Token额度和预算上限。程序出现循环或异常重试时可以告警、限速或者直接熔断。这些能力无法证明AI项目产生了价值但能让企业看见项目是如何运行的。十一、以MAI Gateway为例把AI调用变成可以核对的记录根据魔芋AI提供的产品资料魔芋企业AI网关MAI Gateway被定位为企业大模型API的统一入口和治理层。魔芋AI大模型网关I全球大模型一站式调用及服务平台魔芋AI大模型聚合平台大模型网关平台专注于提供高效能、低成本的多品类 AI 模型服务助力开发者和企业聚焦产品创新。https://www.moyu.info/register?affqBX9它主要处理几类问题统一接入公有模型、企业私有模型和本地推理服务集中管理供应商密钥与企业令牌按部门、项目、用户和令牌归集费用设置配额、预算、限流和异常告警记录调用模型、Token消耗、延迟、错误和责任主体执行访问控制、敏感信息处理和日志留存根据价格、可用性和业务规则选择模型链路。产品提供软件部署和硬件网关两种形态。G系列硬件不配置本地GPU主要负责外部模型API和企业已有模型服务的接入治理S系列带本地算力适合需要本地推理或对数据处理位置有要求的场景。是否需要硬件要根据网络结构、数据位置、并发量和运维能力判断。网关一体机不是所有团队的必选项。FinAPI成本治理MAI Gateway的产品资料将AI成本治理方法称为FinAPI分为三个阶段统一管理模型、API Key、调用主体和付款方式审计费用把Token消耗归属到具体部门、项目和用户根据业务效果调整模型、路由、缓存和上下文策略。FinAPI是产品方提出的框架名称。行业里更常见的相关概念是FinOps for AI。FinOps Foundation同样建议企业先盘点模型账户、API Key和支付方式再通过代理层获得费用归属数据逐步建立预算、告警、异常检测与内部成本分摊。其共同思路并不复杂先把钱花在哪里看清楚再讨论怎么优化。十二、AI网关不是AI项目的“成功证明”AI网关能够解决统一接入、权限、成本和日志问题但它也有明确边界。它不能替企业定义业务需求不能自动修复混乱的内部文档也不能保证模型输出永远正确。接入网关不等于自动满足合规要求。合规结论仍然取决于部署方式、数据类型、制度流程和适用法律。路由、缓存和上下文压缩可能降低费用但不存在适用于所有企业的固定降本比例。如果一个AI项目解决的是错误问题网关只能把这个错误项目管理得更清楚。所以企业仍然需要把网关记录与订单、客服、研发、财务等业务数据连接起来计算每次有效结果的真实成本。结语《AI Mania Is Eviscerating Global Decision-Making》真正值得关注的不是那个刺眼的0%。文章描述的是一种组织失灵领导者不敢承认没有计划项目团队不敢报告失败员工用虚假的AI行为满足考核供应商和客户则互相强化对方的乐观表态。最后所有人都在谈AI企业却越来越难判断什么工作真正重要。解决这个问题不能依赖下一代模型。企业需要重新建立最普通的管理能力明确问题、设定基线、记录成本、听取一线反馈并允许无效项目停止。AI网关可以让调用、费用和责任变得可追溯。至于一个AI项目究竟值不值得做还要回到业务结果。这个问题不应该由模型替企业回答。