一家企业AI服务商 recently 丢掉了签约不久的客户，对方给出的理由十分直白：竞品的演示界面看起来更炫。至于究竟强在哪里，客户自己也说不清楚。
类似的情节正在行业内反复出现。不少团队发现，自己做的企业AI项目换一家供应商来接手，效果相差无几，客户续约的意愿自然高不起来。
围绕这一现象的讨论，最终指向一个老词——护城河。
过去几年，行业对这个概念的理解经历过一轮更替。最早的答案是模型：谁的模型能力强，谁先把产品做出来，谁就占据先机。这一判断如今已很少有人再提，因为模型两三个月就换一代，所谓先手连一个季度都撑不住。
随后，讨论挪到了另一层：流程、数据、系统集成、客户信任。这套说法听起来更有分量，也让从业者安心了一阵。可细究之下，这一层同样站不住。流程是一份规范文件，数据是一个库，集成是一组接口，客户关系是几位熟面孔，这些东西有一个共同点：别人搬得走。
有观点对此给出了一个尖锐的比喻：把护城河修在能被搬走的东西上，那不叫护城河，只能叫库存。
那么，究竟什么东西搬不走？答案收敛到了同一个词上：上下文（Context）。
需要澄清的是，这里的上下文，既不是提示词里粘贴的那段文字，也不是灌进向量数据库的企业文档。它指的是一家企业私有世界的完整投影，业务专长、内部流程、判断习惯、例外处置，以及这些内容持续的变动与更新。
支持这一判断的理由，可以归纳为七个方面。
其一，模型读不到企业内部。大模型几乎读过公开世界的一切，唯独没读过某一家具体的公司。谁的话在内部算数，哪份数据是权威版本，某一单为什么破例放行——这些信息只存在于组织内部，市场上没有任何交易渠道可以买到。
其三，时间是买不来的。上下文不是上线当天就有的，头一年注定单薄。要跑上一两年，边界情况、行业惯例、这家企业特有的例外处理方式才会陆续浮出水面并被记录下来。接口可以采购，数据可以采购，人力可以采购，唯独这段积累不行。
其四，静态知识会衰减。整理得再整齐的资料，放上一年也要过期一半。但如果每一次使用都留下修正记录，哪里错了、人改成了什么、下一回怎么调整，上下文就会越用越厚。前者是一次性投入，后者是一套持续变强的机制，性质完全不同。
其五，权限问题不可回避。上下文不只是知道什么，更关键的是哪些内容、谁能看。合同、薪酬、并购材料、核心数据对哪些人可见，映射的是组织结构本身，而不是几行技术配置。准确与安全，都压在新的权限体系上。
其六，换模型是一种检验手段。想验证护城河是否成立，办法很简单：把底层模型换成更强的，其他一律不动，看还剩下什么。如果效果归零，说明此前靠的是模型能力，而非自己的资产；如果积累的资产和能力原封未动，才谈得上护城河属性。
其七，迁移本身就是代价。客户不走，往往不是因为合同捆绑，而是因为离开意味着丢掉多年积累的上下文。合约期从来不是主要约束，真正的阻力在于：一旦更换供应商，这些东西全部要重建，账单由客户自己付，组织记忆也随之清零。
值得注意的是，这七条并不需要逐条去建设。上下文做成了，七条都包含在内；做不成，一条也留不住。与其分头去垒七堵墙，不如把上下文这一件事做实，墙会自己长出来。
不过，道理讲通与事情做成之间，还隔着一段最容易被轻轻带过的距离。
许多团队听完这套逻辑频频点头，自认为找到了答案，回去之后沿用的仍是老路子：接数据、接模型、上线、验收、撤人。半年后再看，上下文依旧薄薄一层。
问题出在哪？做上下文有一个特殊要求：不能待在自己公司的办公室里想，必须深扎客户现场。以探索为导向的AI项目，一旦离开现场、离开那些专属规则和内部数据、离开一轮又一轮的训练与纠错、离开它真正运行起来的那个环境，就拿不到任何有用的上下文。
一位从业者回忆了让他印象最深的一幕：客户的两个部门负责人当场吵了起来，吵到一半他才听懂，双方争的不是流程，而是一个从未写进任何文档的决策点——什么情况下、由谁来点头。这个细节，在需求会上问过三次，没有一个人说得出来。
据此得出的结论只有一句话：构建上下文，得有人蹲在客户那里，一回一回地做，不能交付完就撒手。这正是FDE（Forward Deployed Engineering，前沿部署工程）的做法——派几个人常驻客户现场，把这件事当作工程项目来推进。
行业里关于下一个万亿美元赛道的讨论一直没停过，有人押模型，有人押算力，而上下文正在被越来越多的从业者视为真正的答案所在。
反观市面上的大多数企业AI产品，处境并不乐观。它们并非做得差，而是现有做法从原理上就长不出上下文。一个Demo从头跑到尾，检索能答，Agent也能跑，但产品与这家公司之间没有多少关系——换一家供应商，结果差不多，被快速替代也就不足为奇。
一个最直接的检验标准随之而来：如果换掉你，客户并不觉得可惜，那便说明护城河从未建成。
