95%的企业AI项目死在哪里？一篇关于「上下文基础设施」的深度复盘.

2025年底，复盘去年参与的企业AI项目时，一个尴尬的事实摆在面前：有的勉强验收，有的至今没有完全交付。更值得追问的是，很多项目从启动之初就推不动——不是因为技术太难，而是因为根本不知道该往哪个方向推。

直到看到MIT做的生成式AI企业落地调研数据，心里才算有些释然：全球95%的企业AI项目，都止步于单场景演示，始终无法落地到企业生产环境。换句更直接的话说，就是失败了。这个比例高得惊人，以至于它暗示了一个判断：问题不是出在某家公司的执行力上，而是出在行业对AI落地这件事的整体理解上。

以往项目复盘会上，大家总把项目不及预期归因于两件事：要么怪大模型能力不行，要么怪企业数据质量太差。但结合这一年大量AI实施项目积累的经验来看，这两者都不是核心症结。造成绝大多数项目折戟的根本原因，其实是企业组织层面的上下文体系缺失。

上下文——Context——这个词听起来抽象，但它的作用并不抽象。短期演示之所以能跑通，是因为演示阶段可以人工补位、可以用预设数据、可以绕开边界情况。一旦投入实际运行，AI幻觉、决策失真、业务跑崩、合规失控等问题就会全面爆发。根本原因只有一个：AI不知道它工作在一个什么样的企业里。

现在问题已经足够清晰了：企业上下文体系缺失，是绝大多数企业AI落地失败的首要诱因。换一个更严厉的说法：在全域企业上下文体系梳理、搭建完备之前，根本就不应该启动项目。

---

**01 认知纠偏：大模型的能力被高估了**

这个观点可能会让人觉得反常识——毕竟过去两年，整个行业都在追逐更强的基座模型。

很多企业做AI落地，带着很深的思维惯性：只要AI输出达不到预期，第一反应就是模型没选好。于是大手笔采购顶尖大模型，扩建算力集群，不在乎高额Token开销，把AI优先当成企业头号战略。但最后AI试点还是走不上生产，前期投入没法产生业务收益。

为什么？因为这套落地思路存在一个本质缺陷。

通用大模型只具备公共通识——它知道怎么对仗工整、怎么逻辑自洽、怎么写出语法正确的句子。但它完全不掌握企业独有的内部业务信息：企业专属业务术语、指标统计口径、多系统数据流转链路、历史业务特殊处理规则、分级数据访问权限——所有这些，都属于大模型预训练阶段无法触达的私有上下文。

即便选用业界顶尖基座模型，如果缺少企业专属业务背景作为输入素材，AI只能依托通用常识主观推演业务事实。生成的文本表面逻辑通顺，但经不起业务实践的检验——因为它根本不理解那些数字背后的含义。

拿法律行业打个比方：一个律师如果只知道公开法条，却没有任何同类判例作为参照，几乎没有可能打赢一场复杂的商业诉讼。法条是通识，判例才是上下文。大模型和企业的关系，就是法条和判例的关系。

坦白说，当前行业使用的大部分落地手段，本质上都是临时补救方案：人工撰写静态提示词、团队各自搭建数据上下文、无上限扩充上下文窗口。这些手段能完成单场景短期演示，甚至能让客户走完验收流程。但从规模化生产落地的角度看，项目本质仍然是失败的——因为演示成功和生产稳定运行之间，差着一整套上下文体系。

从过去一年大量落地项目中总结出的核心教训是：大模型仅仅是推理计算工具，它本身不掌握任何企业级知识。一套完整、合规、可管控的企业上下文体系，才是AI输出可信业务结论的底层根基。

---

**02 核心框架：四层全域上下文，缺一不可**

行业其实早已意识到上下文建设的重要性。但目前多数企业的实践，只停留在了数据层面——这有效果，但远远不够。

真正能够支撑企业可信AI稳定运行——或者说，一个Agent要想在企业环境里正常运转起来——需要四个层面的上下文架构支持。这四个层面缺一不可，自下而上层层递进，每一层都会叠加和放大整体的业务价值。缺失任意一层，都会造成不可逆的落地缺陷。这也是绝大多数企业AI项目失败的共性短板。

**第一层：数据上下文**

这是整个体系的技术底座。核心包含数据表结构、数据血缘、数据质量评分、数据新鲜度与全量技术元数据。

其中，数据血缘是最容易被忽视但最关键的一环。它记录数据从原始采集、ETL加工、指标聚合到下游AI调用的完整字段级流转链路——简单说，就是告诉AI这个数字是从哪里来的、经过了哪些加工、最终变成了什么。这是AI读懂数据来源的基础。

当前多数企业只完成了这一层的基础搭建。但问题在于，仅靠技术元数据，AI只能识别数据表的字段名称，无法理解这些数字对应的真实业务含义。它可能调取过期数据来做当前分析，也可能关联错误的字段。举一个具体例子：一家企业同时存在「实时流水营收表」和「月末结算营收表」两张表，前者是当天实时变动的流水，后者是经过财务核销后的正式数据。如果AI没有完整的数据血缘信息，它完全可能在需要月度经营分析的时候，错误拉取临时流水数据，输出一份和正式财报对不上的分析报告。

构建数据上下文最大的难点在于数据来源问题。绝大多数业务数据无法直接从底层数据库提取——它们分散在各个内外部SaaS系统中，需要通过API采集和对接。而很多企业连这个基本条件都不具备。

**第二层：语义上下文**

这一层用于消解跨部门、跨系统的术语歧义。核心包含统一业务定义、行业术语词典、同义词映射与歧义消解规则。

缺少业务语义上下文的AI，无法自动区分指标口径。即使数据计算逻辑完全正确，最终的分析结论也会误导决策。这里说的不是技术问题，是管理问题。

企业内部普遍存在「同名不同义」的问题。随便举几个真实场景：SaaS订阅业务中说的「收入」，市场部门指的是第四季度已确认的收入，而销售部门指的是总签约金额，两者可能差了好几倍。「客户」在销售系统里指的是有付费记录的账户，在市场系统里却包含了所有试用注册用户。如果AI不做语义区分，问它「上季度有多少客户」，它会给出一个自己都不知道对错的数字。

这类问题靠模型微调解决不了。因为模型根本不理解这两个部门的「收入」和「客户」为什么不同——它只知道这两个词对应不同的数据字段。只有显式的语义上下文，才能让AI知道什么时候该用哪个口径。

**第三层：知识上下文**

这一层承载的是企业没有明文记录的内部隐性知识。涵盖历史业务决策逻辑、例外处理规则、未成文的决策经验。

通用大模型无法获取企业多年沉淀的实操经验。而缺失这一层上下文的AI，只会机械套用公开的规则和标准，忽略特殊业务场景的约束，输出脱离企业实际的「标准化」方案——也就是那种「技术上完全正确，但组织上完全错误」的答案。

举一个金融行业的例子。做风控方案的时候，除了依据常规风控指标（征信分数、收入负债比、历史逾期记录等），真正有效的内部特征可能包括：该客户历史上与这家机构的交互频次变化、某类特殊产品的还款模式、甚至某个区域特有的欺诈模式。这些特征不会出现在任何公开教材或监管文件里，它们是这家机构在自己的业务实践中积累出来的判断依据。AI如果不知道这些，它给出的风控方案就和从教科书里抄出来的没有区别——安全、合规，但没有实战价值。

知识上下文还有一个特殊的性质：它是最容易被忽视的。数据上下文可以来自IT系统，语义上下文可以通过梳理文档整理出来，但知识上下文往往存在于资深员工的脑子里，从未被文字化，甚至从未被意识到是「知识」。

**第四层：用户与角色上下文**

这是合规风控的顶层屏障。核心包含数据访问权限、用户操作历史、企业组织架构、个性化使用偏好。

这一层的作用是根据使用者身份，动态裁剪上下文的可见范围。举个例子：普通销售人员不应该能看到公司的财务报表数据，非HR岗位的员工不应该能访问薪资信息，外部合作伙伴不应该能接触内部战略文档。用户与角色上下文负责的就是这些边界划定。与此同时，它还需要留存全链路审计日志，以便事后追溯。

缺少角色上下文的AI存在重大的合规隐患。最典型的风险场景是：AI客服在回答客户问题的时候，无意中泄露了另一个客户的隐私信息——因为客服Agent根本不知道当前对话者的身份和权限范围，它只是忠实地回答了问题。在欧盟GDPR和中国的个人信息保护法框架下，这种场景一旦出事，处罚金额和品牌声誉损失都将是灾难性的。

这四层上下文形成一个完整的闭环。只有数据上下文，AI只有死的数据，没有业务理解力。叠加语义上下文，AI能统一理解不同部门的业务口径。再补充知识上下文，AI拥有了成熟业务判断力。四层全部完备，才能实现数据可信、口径统一、经验完整、权限合规的企业级AI业务推理。

---

**03 底层认知：上下文不是文档，是企业基础设施**

印象很深的一个项目经历。此前跟进过一个AI落地项目，启动之前，各业务线和技术团队都分别搭建了自身场景下基本完整的上下文体系。财务团队梳理了营收核算相关的数据与术语，销售团队搭建了客户跟进的配套上下文，产研和风控也各自完成了对应模块的整理。

从单条线来看，每个团队做得都不错。但问题出在整合环节。

这套分散建设的方案很快暴露出了致命缺陷：所有上下文都是各团队闭门独立搭建的——没有统一标准，没有互通校验。当我们把多套上下文整合到统一的企业全局视图中时才发现，各模块的内容互相割裂，指标定义、统计口径、数据范围完全无法对齐。财务说的「净利润」和业务说的「净利润」差了三个调整项，销售说的「成交客户」和客服说的「成交客户」差了七个判定条件。这些上下文彼此之间没有兼容和联动的逻辑。

更棘手的是，每套孤立上下文在自身体系内都是自洽的。单条业务线、单个独立场景运行时，AI的输出结果看起来通顺合理，交付演示时看不出明显问题，甚至能顺利通过阶段性验收。客户看了也觉得不错，该签字签字，该付款付款。但问题不会在验收环节暴露——它会在之后爆发。

一旦需要打通跨部门业务、做企业全域综合分析，多套冲突的上下文叠加在一起之后，AI的计算与判断标准就彻底混乱了。输出结论互相矛盾，同一组数据在不同口径下得出截然相反的结论，各类逻辑漏洞和统计错误集中爆发。最终的结果是：系统不可用。

这也是大量项目看起来演示效果亮眼，最终却无法投产落地的典型假象：局部上下文完整，不等于企业全域上下文体系成立。分散的、孤立的场景化自建模式，解决不了组织级AI规模化落地的核心矛盾。

经过这些项目的教训，得出的判断是：企业上下文不能只是零散的文档、数据定义和规则清单，更不能交由各业务团队各自为政搭建。它应当和算力、存储、云平台一样，被定位为企业数字化核心基建——可以称之为Context Infrastructure，上下文设施。

这个定位意味着什么？就像网络基础设施、服务器基础设施一样，上下文设施具备三个核心属性：统一标准，全局统一维护，全部门共享复用。它不属于某一个业务部门，也不属于某一个项目，而是企业全体AI应用共用的底层支撑底座。

只有自上而下地统一规划、统一治理、统一更新四层完整上下文架构，才能从根源上规避多套口径冲突、信息割裂的落地陷阱，让AI跨部门、全流程稳定可信运行。这不是一个可有可无的选项——它决定了企业AI投入最终是资产还是费用。

---

**04 落地破局：全域上下文设施建设四步法**

如果想跳出行业95%的AI落地失败困局，企业必须彻底扭转固有思路：放弃以模型选型、模型调优为核心的建设路线，优先搭建包含四层架构的全域上下文基础设施。

从实际落地经验来看，整套路径分为四个关键动作，层层递进：

**第一步：统一资产底座，打通四层上下文**

这是最基础也是最关键的一步。把企业上下文定义成全公司共享的核心数字资产，搭建全局统一的上下文图谱，串联数据、语义、知识、组织四层上下文。目标是消除各部门之间的信息孤岛和口径冲突——在架构层面确保所有AI应用使用的是同一套上下文标准，而不是各说各话。

**第二步：自动化动态运维，解决上下文老化问题**

很多企业做完一次上下文梳理之后就放着不管了。但上下文是会老化的——数据表结构会迭代，业务规则会调整，指标口径会变更。如果不配套全链路自动更新机制，静态的上下文很快就会滞后失效。AI拿着半年前的上下文来做今天的业务推理，结果不会比没有上下文好多少。

**第三步：标准化统一分发，赋能全量AI应用**

上下文建设好之后，还需要一个标准化的分发机制。基于标准化MCP协议，对内所有AI应用统一输出可管控、携带完整溯源信息的上下文素材。实现一次建设、全域复用的目标。这样做的好处是：新的AI应用上线时不需要重新对接和梳理上下文，直接接入统一分发通道即可。

**第四步：前置合规治理，满足监管要求**

合规不能在出了问题之后再补救。必须在上下文体系搭建的同时，提前搭建分级访问权限和全流程操作审计体系。从源头管控数据使用边界，适配不同行业和跨境场景的合规规则。这一步做在前面，可以省掉后续大量的合规补救成本和法律风险。

---

**写在最后**

过去两年，中国企业的AI投入可以用「千军万马过独木桥」来形容。但真正从桥上走过去、进入生产环境创造价值的，少之又少。

很多企业始终困在「重模型、轻底座」的AI建设误区里。它们愿意花大价钱采购顶尖模型、扩建算力集群，却不愿意花时间把企业内部的上下文体系梳理清楚。结果就是：算力和模型越堆越强，AI输出的结果却始终脱离企业实际，无法真正投入使用。

这背后的根本原因不是技术问题，是认知问题。算力与基座模型仅仅是推理工具——它们不知道企业的业务逻辑、不知道部门间的术语分歧、不知道资深员工脑子里的经验判断、不知道谁有权限看到什么数据。一套统一治理、四层架构完备的全域上下文体系，才是企业AI规模化落地的核心护城河。

跳出单场景演示带来的虚假成功，自上而下搭建标准化的Context Infrastructure，依靠完整四层上下文打通数据、业务规则、隐性经验与权限管控——这是目前能看到的最可行的路径，也是打破95%项目无法投产这个行业魔咒的唯一办法。

让AI不再局限于短期演示，真正转化为持续创造经营价值的数字化长期资产。这件事不是靠更好的模型实现的，而是靠更好的上下文。

长按图片保存，扫码关注公众号

转载注明出处：http://www.wzimo.com/xinling/73.html