自研还是采购的界限已然改变：当供应商原语吞噬你的基础设施时，如何抉择 AI 功能

18 个月前，“我们构建了自己的检索流水线”在架构评审中还是一个非常合理的说法。你拥有分块策略、经过基准测试的嵌入模型、调优过的向量数据库、重排序器，以及一个由 3 名工程师耗时一个季度才搞定的上下文填充启发式算法。那一套技术栈曾是真正的差异化基础设施。而今天，同样的能力只需一次托管的工具调用：将文件上传到向量数据库，将其附加到请求中，供应商就会完成解析、分块、嵌入、存储、检索和重排序——所有这些都隐藏在一个 API 背后。曾经需要 3 名工程师开发一个季度的成果，现在只是一个配置对象。

这就是目前构建 AI 产品令人不安的模式。自建与外购之间的界限并非固定，它在移动，而且只向一个方向移动。每隔几个月，模型供应商就会发布一个原生功能（primitive），蚕食掉你曾经拥有的一个层级：记忆、检索、结构化输出、工具路由，甚至是多步编排。上个季度还让你引以为傲的基础设施，这个季度就成了竞争对手可以免费获得的东西，而且默认配置更好，延迟底线更低，因为它就运行在供应商自己的数据中心内部。

一种本能反应是将其视为需要防范的威胁。但这种思维框架是错误的。供应商吸收通用基础设施实际上是在帮你——它帮你删除了你本就不想要的维护工作。真正的问题在于，你选择构建的东西是位于不断上升的水位线之上还是之下。大多数团队从未明确做出这个决策。他们为了演示需求构建了一切，一年后才发现 70% 的代码库是在重新实现供应商现在提供的原生功能，而那 30% 真正具有防御性的部分反而因为缺乏关注而枯萎。

水位线不断上升，且只升不降

将 AI 技术栈想象成堆叠在水面上的层级，水就是“供应商免费提供给你的东西”。原始模型漂浮在底部。在它之上是检索、记忆、结构化输出、函数调用、智能体循环（agentic loops）、评估和垂直工作流。水位线就是供应商已经吸收的高度。每一次发布都会抬高水位。

如果你观察 API 的变化，这一趋势是显而易见的。结构化输出从“解析 JSON 并祈祷，然后在格式错误时重试”，变成了保证 Schema 的响应模式。函数调用从一个你手动实现的聪明提示词技巧，变成了一等公民级别的请求参数。检索从一个你动用 5 家供应商组装的流水线，变成了一个托管的文件搜索工具。记忆——持久的、有作用域的、跨会话的状态——是目前正在被吸收的层级，供应商和一众框架都在竞相掌控对话历史和长期的用户事实，这样你就不用自己存储它们了。

从“水位线只升不降”可以得出两个结论。首先，任何你构建在当前水位线处的东西，其保质期都很短——你是在为供应商即将发布并比你维护得更好的功能做免费研发。其次，水位线的上升在整个技术栈中是不对称的。它在横向原生功能（即每个 AI 应用都需要的相同能力）中上升得最快，而在纵向深度（即特定于你的领域、你的数据和客户工作流的部分）中上升得最慢。供应商没有动力去构建你所在行业的合规逻辑，但他们有十足的动力去构建检索，因为每个人都需要它。

因此，战略性的做法不是在水位线以下构建并最终失败，也不是去猜测明年水位线在哪里，而是朝着水流无法触及的方向构建。

Sherlocking 是规律，而非风险

当现有巨头吸收了小公司在其平台上构建的功能时，有一个专门的称呼：Sherlocking，得名于苹果公司多次发布抹杀第三方工具的系统功能。f.lux 被 Night Shift 给 Sherlocked 了；Tile 被 AirTag 给 Sherlocked 了；Pebble 被 Apple Watch 给 Sherlocked 了。这种模式由来已久，新鲜的是现在的速度。操作系统一年更新一次，而模型供应商每月都会发布原生功能，现在，一段更新日志就可能成为“杀死你产品的系统更新”。

这些例子已不再是假设。供应商已经发布了对话内应用构建工具，直接与那些部署其模型并宣称“提示词即应用”的创业公司竞争。他们还推出了垂直领域的方案——法律、编程、客户支持——让在这些特定垂直领域构建的创业公司陷入防御态势，其中甚至包括那些核心产品完全运行在该供应商模型之上的公司。当你的供应商也愿意成为你的竞争对手时，“在平台上构建”所带来的风险与你的代码质量无关。

那些在苹果的 Sherlocking 中幸存下来的创始人给出的教训其实并不是“不要在平台上构建”。Dropbox、Spotify 和 1Password 都在后来与他们竞争的平台上构建，并都活了下来——方法是向上移动，进入工作流、网络效应和企业级集成，这些是平台在不改变公司定位的情况下无法复制的。具有防御性的地位从来不是功能本身，而是功能周围的深度：包括融入审批、合规、采购和分析流水线的业务流程集成；高触达的交付实施；以及积累的领域数据和反馈闭环。这些都不是原生功能。这些都需要自建而非外购，但这种“自建”与重新实现检索功能是完全不同的性质。

决策框架：在水位线之下构建，只为逃离它

在决定某项能力是自研（build）还是采购（buy）时，这是我会采用的规则。针对每项能力，问两个问题，你会得到四个象限。

问题一：它是水平的还是垂直的？ “水平”意味着每个 AI 产品都需要它，且形式大致相同——检索、记忆、结构化输出、工具调用、基础编排、可观测性管道。“垂直”意味着它特定于你的领域、你的自有数据、你客户的工作流，或者是你的信任与分发渠道。

问题二：它是在供应商的路线图上，还是违背他们的利益动机？ 一个服务于所有客户的原语（primitive），无论他们是否已经宣布，都在路线图上。而一个只有你的细分领域才需要的能力，他们永远不会优先考虑，因为其 API 内部的可寻址市场太小了。

由此产生了一套行动指南：

• 水平 + 在路线图上 → 采购，并为替换而设计。 这包括检索、结构化输出、函数调用。使用供应商的原语。不要自研。如果某个原语尚未存在但显然应该存在，请在一个可替换的接口后构建最薄的版本，并将你的版本视为临时的桥梁，而非资产。供应商发布它的那天，你删掉代码并感到解脱。
• 水平 + 违背利益动机 → 谨慎构建，预期竞争。 跨供应商路由、供应商中立的评估以及可移植层属于此类。供应商不会构建帮助你离开他们的东西。这些东西具有一定的防御性，但正通过开源框架快速商品化，所以不要过度投入。
• 垂直 + 在路线图上 → 这是 Sherlocking 区域；向上移动或寻求出路。 如果供应商正进入你的垂直领域，你的功能对等是一场必输的竞赛。生存之道在于做得比他们更深——操作层面的集成、服务和私有数据——或者选择一个他们不屑于涉足的更窄的切入点。
• 垂直 + 违背利益动机 → 倾尽所有去构建。 这是唯一一个构建是毫无疑问正确选择的象限。你的私有数据、你的领域逻辑、你的工作流集成、你的客户信任、你的反馈循环。模型是一个必要的输入；而这才是护城河。把你稀缺的工程资源花在这里。

这个框架故意让人感到不安，因为它告诉大多数团队，他们正在构建的大部分内容都属于“采购并为替换而设计”的那一类——而他们一直忽视的那一小部分，才是唯一值得投入顶尖工程师的地方。

迁移税是真实存在的，因此要为更换而构建

反对“直接购买原语”的理由是迁移成本，这很合理。当你用供应商的托管工具替换自研检索的那天，你会继承他们的分块（chunking）默认设置、元数据过滤语义、延迟特征以及定价模型——并且你会失去你曾经调优的那些控制杆。如果你在各处都直接针对自研流水线的内部细节进行构建，那么更换将是一个长达数月的重写过程，而你会理所当然地推迟它，直到你的自定义代码变成一种负担。

解决办法是预先决定水平能力存在于一个狭窄的接口之后。你的应用程序代码应该请求“检索此查询的相关上下文”，而不是直接调用你的向量数据库。这样，“将我们的流水线更换为供应商的工具”就是一个适配器的实现，而不是一个涉及上百个文件的重构。那些在 2024 年与沉重的框架搏斗后，报告在供应商 API 之上编写薄封装层的团队，学到的正是这一点：掌控接缝（seam），租借其后的实现。保留接缝的成本很低。而其后的实现是供应商最终会提供给你的东西，你希望在无需重写的情况下接受这份礼物。

这也改变了你阅读供应商发布日志的方式。一个新的原语不再是一个令人恐惧的竞争事件——而是一个你可以卸下的维护负担。当供应商发布记忆或检索功能时，那些感到痛苦的团队是将差异化押注在拥有那一层之上的团队。而受益的团队是那些一直将其视为租借，并将精力投入到更高一层的团队。

你的处境

停止将“我们应该自研还是采购这个？”视为每项能力的单次决策。真实的判断标准应该是：“水位线在这项能力下的上升速度有多快，我们构建的东西是在水位线之上还是之下？”在水位线之下，采购，并仅掌控接缝，以便在原语发布时更换实现。在水位线之上——在你的领域深度、你的数据、你的工作流集成、你客户的信任中——坚定地构建，因为那是供应商的路线图唯一无法淹没的领地。

2026 年导致 AI 产品失败的错误不是选错了向量数据库。而是花了一年的时间去构建一个供应商注定会商品化的功能的精美版本，然后预算里再也没有余力去处理产品中那些无人能取代的部分。对照这四个象限审计你的代码库。那些在供应商发布原语时你会庆幸删掉的代码行，正是最初就不该作为你差异化竞争力的代码。现在就找到它们，把它们放在接缝之后，然后把省下来的季度时间花在真正属于你的那 30% 上。