企业AI产品，究竟有没有护城河？

本文来自微信公众号： ToBeSaaS ，作者：戴珂产品卖出去了，客户用着也还行。可没过几天，客户来了一句话：不续费了，因为我们找到了一个更好的。问他好在哪儿，多半说演示看起来更炫。

这时候才会想到那个词：护城河。01护城河的说法，其实都停在表面前几年大家讲AI产品的护城河，讲的是模型。谁家模型强，谁先把东西做出来，谁就有先手。这个说法现在几乎没人提，因为模型两三个月换一代，先手保不住一个季度。

后来护城河的说法往上挪了一层。把护城河挪到流程、数据、集成、信任上。听着比模型那一层深，也确实让人安心了不少。可这一层还是浅的。因为这些东西，说白了都是“你手里有什么”。流程是一份规范，数据是一个库，集成是一组接口，客户关系是几个熟人，没有一样是别人拿不走的。

把护城河建在一个能被别人移走的东西上，那就不叫护城河，那叫库存。02上下文：真正的护城河那什么搬不走？只有一样：上下文（Context）。这里说的上下文，不是提示词里塞的那段文字，也不是把文档灌进向量库。

它是这家公司私有世界的完整投影——它的业务专长、流程、判断、例外、变化和更新。为什么是它，七项。1.模型看不到企业内部模型什么都读过，就是没读过这家公司。它不知道谁说话算数、哪份数是准的、这一单为什么破例。

这些只存在于组织内部，也没有可以交易的获取渠道。2.数据要先成为关系一堆文档、表格摆在那儿，不算上下文。文档只是资料，得先和人、项目、客户、流程对上，知道是谁在问、处在哪个环节、哪个来源权威、下一步做什么。

这层关系长在企业的日常里，没法整包移出。3.时间不能采购这东西不是上线就有，得靠时间积累出来。头一年一定是薄的，要跑上一两年，边界情况、行业惯例、这家企业特有的例外处置才会浮出来并被记下来。

接口、数据、人力都能采购，这段积累时间不能。4.静态知识会衰减整理得再齐整，放上一年也过期一半。可如果每次使用都留下修正——错了什么、人改成什么、下回怎么调——它会自己往上增厚。前一种是一次性投入，后一种是持续变强的机制。

5.权限是重要的上下文不光是知道什么，更重要的是哪些内容、谁能看。合同、薪酬、并购材料、核心数据对谁可见，是组织结构的映射，不是技术配置。准确与安全，全靠新的权限体系。6.换模型，是检验方法真想验证一下是不是护城河，方法很简单：换个模型试试。

把底层模型换成更强的，其他都不动，看还剩什么。归零，说明此前靠的是模型能力，不是自己的资产。如果积累的资产和能力都没变，才具备护城河属性。7.迁移的成本客户不走，不是因为合同限制，是走了就会“组织失意”。

合约期本来也不是主要约束，真正的阻力在于更换意味着丢掉过去积累的上下文。如果迁移，这些都要重新建，代价由客户自己出。对于上下文的七项约束，不用一项一项去建。上下文做成了，七项都在里头；

做不成，一项也留不住。也别分头去垒七堵墙。把上下文这一件事做实，那七堵墙自己会长出来，足以构成稳固的护城河。03护城河想明白了，不等于有了护城河的道理到这儿讲完了吗？没有。讲完的是“是什么”，没讲“怎么做”。

这一段最容易被轻轻带过去。很多人听完点头，觉得找到答案了，回去还是老办法——接数据、接模型、上线、验收、撤人。半年后再看，上下文还是薄薄一层。为什么会这样？因为做上下文有个特点：不能待在自己公司办公室里想，要深扎客户现场。

原因也很简单。以探索为导向的AI项目，一旦离开现场、离开客户、离开那些专属规则和内部数据，离开一次次训练和改错，离开它真正跑起来的那个环境，就得不到任何有用的上下文。我印象最深的一件事，是听客户两个部门负责人吵了一架。

吵到一半才听明白，他们争的并不是流程，而是一个从来没写进任何文档的决策点——谁在什么情况下可以点头。这件事，在需求会上问过三次，没人说得出来。说了这么多，结论就一个：构建上下文这件事，得有人在客户那儿蹲着，一回一回地做，不能一次交付就撒手不管。

这就是FDE。FDE是派几个人去客户那儿待着，并且把这件事当成前沿部署工程（Forward Deployed Engineering）来做。这个内容，我在前一篇文章中已经详细讨论过。

总之，护城河不是想出来的，是通过FDE方式干出来的。04大部分企业AI产品，确实没有护城河回到现实。市面上大部分企业AI项目，其实是没有护城河的。他们并不是做得差，因为这套做法从原理上就长不出上下文。

说句得罪人的话，目前大部分AI产品，都是靠一个Demo从头跑到底，检索能答，Agent也能跑，但就是跟这家公司没什么关系。换一家供应商，效果差不多。快速被竞品替代，也就不足为奇了。

如果换掉你，客户并不觉得可惜，那就是最直接的证据：你没建起护城河。写在最后整个AI行业都在找“下一个万亿美元赛道”。有人赌模型，有人押算力。但在我看来，“上下文市场”才是那个赛道。而基于上下文构建护的城河，才是最值得的。