其中有一个团队占用的Ticket比例高得离谱——他们大约50%的Sprint时间都花在了“Bug”上，而其他团队这一比例约为25%。从表面数据来看，这似乎是一个质量问题。

但事实并非如此，当我们深入分析这些Ticket背后的上下文时，发现几乎没有一个是真正的Bug，它们只是为了弥补缺失的产品功能而采取的手工变通方案：客户不断提出请求，要求我们帮他们恢复误删的项目。由于没有上线项目恢复功能，直接消耗了大约1.5个工程师的产能。我找到产品团队说：“把这个功能做出来，你们就能释放一个半人手。”

这次分析只花了45分钟，之所以能做到这一点，是因为我们的数据已经做好了组织规划：按团队打了标签、关联了贡献者、可以通过MCP访问，并且受到基于角色的访问控制保护。这些都不是“AI”本身，但它们构成了AI底层的基座，而这恰恰是几乎没有人会优先投资的部分。原因或许在于这类投资并不讨喜：更新数据字典、访问控制、团队分类体系以及系统间映射。其中大部分工作二十年来其实本质未变，AI只是让忽视这些工作的代价变得更高了。

大模型底层的智慧

在全面推进AI落地过程中，作为CTO，我反复感受到上下文数据层的价值。在找到更合适的词之前，我将这种价值主张称为“上下文智能”。自2025年底以来，Anthropic的工程团队一直将这类工作称为“上下文工程”，不久后CIO也对这一概念进行了专题报道。无论将其称为上下文智能还是上下文工程，它都是技术栈中依然需要实质性编程工作的部分。

如果说业务逻辑是公司官方的组织架构图，那么上下文智能就是了解谁才是真正把事情办成的人、决策究竟是如何做出的，以及那些未被写明的潜规则。一个是理论，另一个则是现实。

大多数企业系统记录的都是理论，而能够记录工作究竟如何开展——人们做了什么、团队如何运转、决策卡在何处——的系统则非常罕见且难以构建。事实证明，如果没有这两者，现代大语言模型将毫无用处。

在最近举办的一次公司黑客松上，我切身体会到了这一点。九支工程团队面对同一个Prompt：通过AI让我们的业务数据集变得更加易用。我的团队在Postgres和丰富化数据支持的MCP服务器之上，构建了基于Persona的聊天机器人(包括CFO、CIO和销售经理)，其他团队则构建了仪表盘生成器、Looker对话式分析工具以及工作流智能体。

初始的Demo都遇到了同样的问题，Claude确实能和我们的数据对话，但给出的答案要么泛泛而谈，要么在胡说八道时显得自信满满。CFO Persona会高高兴兴地汇报“支出趋势”，但实际上却悄悄混淆了两个不同表中的两类不同成本;CIO Persona能够回答有关团队生产力的问题，但它计算的却是跨岗位职能本不该被聚合的平均值;销售经理Persona返回的答案在数据 Schema上技术正确，但在业务逻辑上完全脱节。原始数据非常丰富，但围绕它的上下文层却尚未建立。直接与原始数据对话并不是一个AI产品，它充其量只是个Demo。

在比赛的第二天，我手下一位资深工程师拆除了智能体对数据库的直接连接，他不再试图通过Prompt工程让LLM去理解我们的业务，而是将这些逻辑编码到了数据管道中，他从那些失败的CFO回答倒推，梳理出一名经验丰富的财务总监所依赖的隐性知识：明确定义哪些历史数据表真正代表“支出”、编写货币标准化规则，并硬编码我们的财年时间窗口，他构建了一系列语义SQL视图来强制执行这些规则，并限制MCP服务器仅暴露这一经过精细整理的层级。当我们让同一个模型面对相同的问题时，它返回了截然不同的答案——具体、有据可查，且完全基于我们真实的业务现实。模型本身并没有变聪明，聪明的是底层的工程架构。

这种模式如今无处不在

麦肯锡不断发布报告称，软件开发高居企业AI应用场景之首，企业在试点中实现了30%–50%的生产力提升。试点的数据是真实的，但它们很少能在生产环境中转化为顶线收益或底线利润。我们自己公司的数据也印证了这一点：在2025年Q1至2026年Q1期间，我们的AI工具总使用量增长了328%(翻了4倍多)，而在同一时期，PR(Pull Request)吞吐量仅增长了49%。

这一巨大的差距——应用率大幅上升，而实际产出增幅缓慢——就是“上下文差距”。如果将通用智能体直接接入未经解读的原始数据，它轻则效率低下，重则带来破坏。一个在缺乏客户细分或产品层级上下文的情况下优化销售的智能体，只会自信地推荐错误的东西。Anthropic直接点明了这种转变：基于语言模型的开发，正逐渐“从为Prompt寻找恰当的词句，转向回答更宏观的问题——即什么样的上下文配置最有可能触发模型产生我们预期的行为”。这第二个问题——即怎样的上下文配置——才是胜负的关键。而大多数机构目前仍在试图回答第一个问题。

工作真正落地的领域

与我交流的CTO中，越来越多的人正在相应地调整他们的AI投资策略，他们将更少精力放在模型本身，而是更多投入到模型与数据之间的这一层。

当同行问我这在日常工作中具体表现为什么时，我会告诉他们，我给每个工程岗位都下达了同样的命令：LLM绝不能直接接触未经上下文处理的原始数据。

在实践中，这可以拆解为三项并不炫酷的具体工作：

1. 语义中间件： 我们需要编写代码，在原始数据到达模型之前将其转化为对业务有意义的信号。我们的Feature Store存储的是“员工在关键路径功能上的代码推进速度”，而不是“X提交了50次Git Commit”。搞清楚“关键路径”在我们产品、组织以及当前团队中究竟意味着什么，这才是核心工作，这项工作不会因为模型变得更强大而变得廉价。

2. 多智能体设计： 与其使用一个无所不知的调度器，不如运行作用域限定在特定领域的细分智能体，每个智能体都配有能够捕获主模型已知失效模式的规则。我们将其与RAG结合，检索的是带有规则约束的预计算洞察，而非原始文档。校验检查点设置在各个步骤之间，用于标记违反已知约束条件的建议(例如将完全不同岗位的生产力进行平均)。这些安全栏不是为了炫技，而是因为我们已经亲眼目睹过模型犯过这些一模一样的错误。

3. 严肃对待业务逻辑的评估： 当我评估一个模型时，通用基准测试的准确率是最不重要的指标。我想知道的是它是否尊重我们的业务约束，以及能否无缝融入我们现有的架构中。这有时意味着微调我们的模式，有时需要采用Constitutional(宪政)方法来嵌入原则，有时则是确定性规则与概率性规则并存的混合系统。贯穿其中的主线始终是一致的：结合现实情况进行验证，而不是看基准测试分数。

为什么这在当前至关重要

之所以这比六个月前更为关键，是因为AI的应用速度已经远远超过了效果衡量，更不用说系统集成了。模型评估与威胁研究机构(METR)关于开发者生产力的研究以一种意料之外的方式证实了这一点。在2025年初，他们进行了一项对照研究，发现AI工具使有经验的开源开发者速度变慢了19%，而当他们在2025年底试图重复这项研究时，实验却无法继续了：30%到50%的开发者拒绝在不使用AI的情况下提交任务，他们不再接受剥离工具的工作方式。METR目前正在重新设计这项研究，因为最初的研究方法已经无法应对开发者当下的实际工作方式。AI的应用普及速度就是如此迅速。但我敢打赌，将这种普及转化为实际成果所需的组织配套设施——上下文层、工作流重构、围绕新工具的再培训——其演进速度远远没有跟上。

依靠上下文抢占先机

据我观察，那些成功应用AI的团队都是率先构建了上下文层，而那些陷入困境的团队最终也补上了上下文这一课，只是付出了更高的成本和更多的阵痛。原始数据是新的硬通货，但没有上下文层的原始数据就像放在保险库里的现金，无法发挥任何作用。洞见与噪声之间的区别，就在于那层能够理解数据真正含义的代码。

这一层才是工作的核心所在，也是未来十年竞争优势的立足之本，以我的经验来看，只有率先构建好这一层的企业，才能真正收获市场一直在承诺的生产力提升。

企业网D1net(www.d1net.com)：

国内头部to B IT门户，旗下运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。