摘要

企业使用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?aff=qBX9

它主要处理几类问题：

• 统一接入公有模型、企业私有模型和本地推理服务；

• 集中管理供应商密钥与企业令牌；

• 按部门、项目、用户和令牌归集费用；

• 设置配额、预算、限流和异常告警；

• 记录调用模型、Token消耗、延迟、错误和责任主体；

• 执行访问控制、敏感信息处理和日志留存；

• 根据价格、可用性和业务规则选择模型链路。

产品提供软件部署和硬件网关两种形态。

G系列硬件不配置本地GPU，主要负责外部模型API和企业已有模型服务的接入治理；S系列带本地算力，适合需要本地推理或对数据处理位置有要求的场景。

是否需要硬件，要根据网络结构、数据位置、并发量和运维能力判断。网关一体机不是所有团队的必选项。

FinAPI成本治理

MAI Gateway的产品资料将AI成本治理方法称为FinAPI，分为三个阶段：

1. 统一管理模型、API Key、调用主体和付款方式；

2. 审计费用，把Token消耗归属到具体部门、项目和用户；

3. 根据业务效果调整模型、路由、缓存和上下文策略。

FinAPI是产品方提出的框架名称。行业里更常见的相关概念是FinOps for AI。

FinOps Foundation同样建议企业先盘点模型账户、API Key和支付方式，再通过代理层获得费用归属数据，逐步建立预算、告警、异常检测与内部成本分摊。

其共同思路并不复杂：

先把钱花在哪里看清楚，再讨论怎么优化。

十二、AI网关不是AI项目的“成功证明”

AI网关能够解决统一接入、权限、成本和日志问题，但它也有明确边界。

它不能替企业定义业务需求，不能自动修复混乱的内部文档，也不能保证模型输出永远正确。

接入网关不等于自动满足合规要求。合规结论仍然取决于部署方式、数据类型、制度流程和适用法律。

路由、缓存和上下文压缩可能降低费用，但不存在适用于所有企业的固定降本比例。

如果一个AI项目解决的是错误问题，网关只能把这个错误项目管理得更清楚。

所以，企业仍然需要把网关记录与订单、客服、研发、财务等业务数据连接起来，计算每次有效结果的真实成本。

结语

《AI Mania Is Eviscerating Global Decision-Making》真正值得关注的，不是那个刺眼的0%。

文章描述的是一种组织失灵：

领导者不敢承认没有计划，项目团队不敢报告失败，员工用虚假的AI行为满足考核，供应商和客户则互相强化对方的乐观表态。

最后，所有人都在谈AI，企业却越来越难判断什么工作真正重要。

解决这个问题，不能依赖下一代模型。

企业需要重新建立最普通的管理能力：明确问题、设定基线、记录成本、听取一线反馈，并允许无效项目停止。

AI网关可以让调用、费用和责任变得可追溯。

至于一个AI项目究竟值不值得做，还要回到业务结果。

这个问题不应该由模型替企业回答。