TL;DR: 构建共享上下文层，你就拥有第二个产品；购买它，你就拥有一个供应商决策。成功数据偏向一边：购买的专用 AI 工具成功率约 67%，而内部构建约为三分之一。Aircall 先尝试自建，后来改为购买，现在实现了每位工程师 3 倍的部署速度。当对技术栈的控制才是真正的需求时，就自建；当需求是能在最初几百条事实之后仍保持最新的客户上下文时，就购买。

大约在第二或第三位前沿部署工程师加入时，每个部署团队都会开同一场会。个人的配置都能用：一位工程师维护着 Obsidian 仓库，另一位通过 Claude Code 处理通话记录，但其他人都看不到这些内容。于是有人提出显而易见的解决方案：建一张 Supabase 表、一个自定义保存命令、一个周末的工作量。我们要构建自己的共享上下文层。

这个提议是合理的。团队有工程师，第一个版本确实只需一个周末。问题出现在第二到第六个月，届时上下文层变成了一个拥有用户、流水线、身份验证和数据质量积压任务的产品，而维护它的人是你最资深的 FDE。共享上下文问题不会因为你写了代码就消失，它只是转移了。

本文将逐一介绍我们不断遇到的自建模式、那几个月的时间究竟花在了哪里、自建“大脑”在哪个节点悄然失效，以及双方各自的真实理由。支持购买的观点来自构建者自己的话，而非供应商的恐吓。

我们不断遇到的自建方案

三种模式涵盖了部署团队内部构建的大部分内容。这三种起初都能用，而这恰恰是它们代价高昂的原因。

带保存与压缩命令的 Supabase 存储

2026 年最常见的模式：一个 Postgres 存储（通常是 Supabase），由 Claude Code 中的自定义斜杠命令驱动，该命令在压缩前总结会话并写入有用的事实。这是对真实空缺的巧妙回应，因为否则会话中的经验教训会随终端一起消亡。某工作流自动化平台的 FDE 负责人向我们展示了他的版本，并说：“我实际上把它叫做，呃，FTE 操作系统。”他也承认这个自建项目已被搁置数月，卡在多用户 Gmail 身份验证上，而客户账户却在不断变化。这种模式出现得如此频繁，以至于团队现在都给它起了名字，我们还单独撰文介绍了FDE 操作系统实际包含的内容。

将通话记录导入向量数据库

第二种模式把每一份通话记录都灌入向量数据库（Turbopuffer、pgvector，任你选择），再在其上叠加检索。第一天效果令人惊艳。你问起 Acme 集成，就能拿到相关的片段。问题在于，检索质量从来都不是难点。一位从业者对生产环境 RAG 系统的分析发现，在概念验证后失败的项目中，60% 是败在数据新鲜度，而非检索。存储返回的是三月份说过的话，却没有人构建能发现四月已与之矛盾的部分。

Obsidian、Git 和 wiki 组合

第三种模式完全跳过数据库：markdown 仓库、Git 代码库，有时再在上面加一个 wiki。一家约 50 人 AI 公司的 FDE 团队负责人这样描述他的方案：“我搭建了，呃，Obsidian、一个 Wiki 和 Git [...] 而这现在带来了维护成本。” Obsidian 自己的文档也坦承了协作上限：没有细粒度权限、没有真正的实时编辑，冲突只能在同步时合并。我们曾详细讨论过 Obsidian 第二大脑为何在 FDE 团队中失效，简而言之：它在第二个人加入时就失效了。

这几个月的时间到底花在哪了？

周末估算只覆盖了 schema 和保存命令，却从未覆盖接下来的三条工作流，而内部自建项目正是卡在这些地方，最终躺在待办清单里。

每个数据源一条管道

客户背景信息并非来自单一来源，而是来自通话、Slack 讨论、工单、邮件、CRM 和编码会话。每个来源都需要自己的摄取管道、自己的去重逻辑和自己的故障处理。一家视觉 AI 公司的 FDE 在构建中途告诉我们：“数据管道，那些多用户的东西，已经算是一个痛点。” 这是第六周时的构建状态，而不是第一年就能解决的。

多用户鉴权是那道墙

单用户大脑不需要权限模型。但当第二个人开始读写时，你就需要对接 Google Workspace 的鉴权、按来源配置的凭证，以及决定谁可以看到哪个客户。工作流自动化团队的构建正是在这一点上停滞的。这是毫无光彩、对客户毫无可见收益的工作，因此在每一次优先级之争中都会输给真正的交付工作。

数据对账永远无人负责

存储不断填充，新事实与旧事实相互矛盾。上线日期变了，赞助人换了，范围在某次没人同步的通话中被砍掉了。总得有人来决定哪个版本是真的，而这项工作不在任何人的日程表上。Stripe 2018 年的开发者研究发现，普通开发者每周已经要花 超过 17 小时在调试和重构等维护工作上。内部大脑又在此基础上增加了一个新的维护面，而维护它的人恰恰是你雇来陪客户的那些人。

为什么自建大脑会逐渐失灵

以下是我们从已接入的团队中观察到的规律：一个普通的“大脑”（Obsidian 之类）会在 500 到 1,000 条事实之间逐渐漂移。这是我们的观察，而非行业基准。低于这个规模时，构建者可以在脑中掌握整个知识库，并一眼发现并修补错误。超过这个规模后，矛盾积累的速度超过了任何人整理的速度，“大脑”开始自信地返回已被取代的信息。

这种失效是悄无声息的，这正是它的危险之处。检索仍然正常，答案听起来仍然正确。同一份从业者分析指出，一个系统可能在标准指标上得分 95%，却返回已被取代数周的信息。你的工程师向客户引用了一个迁移日期，而这个日期来自两次通话之前。我们在关于自建大脑上下文漂移的文章中拆解了其运作机制和及时发现问题的工作手册。

成功数据怎么说

自建的本能值得用数据来公正审视，而数据对它相当不利。据 Fortune 报道，MIT 的 NANDA 研究发现，约 95% 的企业生成式 AI 试点没有产生可衡量的损益影响，而幸存者内部的分化才是有趣之处：购买的专用工具约 67% 的情况下能成功，而内部自建工具只有约三分之一的情况能成功。报告指出，通用工具之所以停滞不前，是因为它们不从工作流中学习，也不适应工作流。内部自建的工具可以适应你的工作流，但前提是有人持续维护它。

2025 年 DORA 报告换了个说法：AI 不能修复一个团队，它只会放大已有的东西。上下文层会放大你的整理流程。如果那个流程是“没人负责，以后再说”，那么这一层什么也放大不了。

而两者都不做同样有代价。Panopto 2018 年的知识共享研究发现，知识工作者每周浪费 5.3 小时等待或重新创建知识，按大公司规模计算，这相当于每年 4,700 万美元的生产力损失。电子表格加 Slack 的现状并非它看起来那样是免费的选择。

Aircall 经历了完整的全过程。他们的工程师希望有一个统一的地方来询问上线问题，并且无论谁提问都能得到相同的答案。那里的高级软件工程师 Paul Yi 说得很直白：“我在 Claude 里问‘什么在阻碍切换’，就能得到带来源的真实答案。同样的问题，同样的答案，无论谁问。我们曾试图自建这样的东西，但没能维持住。”在切换到购买的项目大脑后，团队的总结写道“几分钟内完成连接，零工程资源投入”，Aircall 的完整故事中有前后对比。

自建 vs 购买，并排对比

  • 电子表格 + Slack（真正的现状）。首次见效时间：已部署。谁来维护：所有人，也就是没人。漂移处理：没有，你只能在 Slack 里重新提问。它的优势：无需构建，无需学习。
  • 自建方案（Supabase + Claude Code，vault + Git）。首次见效时间：v1 版本一个周末，多用户版本需要数月。维护者：你资历最深的前沿部署工程师，且未列入预算。漂移处理：手动、未量化、通常被跳过。优势所在：完全掌控、无供应商风险、与你的技术栈完全契合。
  • 购买项目大脑（Tandem 的账户大脑）。首次见效时间：数天，因团队而异。维护者：供应商。漂移处理：内置对账机制，漂移以排序后的风险形式呈现，由人工审核。优势所在：当 FDE 们专注于 FDE 工作时，上下文保持最新。

加了阴影的单元格是刻意的。自建方案的维护成本真实存在但未量化，因为几乎没有人跟踪它。

什么时候自建是正确的选择

自建并非总是答案，假装相反只会重复本文承诺避免的供应商 FUD（恐惧、不确定和怀疑）。在以下情况自建：

  • 上下文层就是你的产品。如果你销售记忆基础设施，或者你的差异化依赖于专有数据管道，那就完全自己掌控。
  • 你有平台工程师，而这正是他们的本职工作。能存活下来的自建项目都有明确的负责人和路线图时间。死掉的自建项目都是交付工程师的副业。
  • 数据驻留或政策排除了供应商。某些受监管的环境使外部存储成为不可选项。完全掌控和零供应商风险是真正的优势，无论成功统计数据怎么说，这一点都不会改变。
  • 你是一个人管理三个账户。低于漂移阈值时，个人 vault 加上自律就足够了。我们的项目大脑创建指南介绍了无论使用哪种工具都应该记录什么，而 Notion 和 Airtable 的 DIY 路线是一个合理的中间步骤。

当需求是让账户上下文在人员和工具之间保持最新，同时你的工程师专注于账户工作时，就该购买。这是服务水平问题，而不是模式问题，而服务水平正是供应商存在的意义。

如何执行这个决策

  • 为维护者定价，而不是为原型定价。周末搭建几乎免费。估算管道、认证和对账的持续工时，然后指明将由谁承担这些工时，以及他们会放弃哪些账户工作。
  • 清点你的数据源。通话、Slack、工单、邮件、CRM、编码会话。每一个都是你需要搭建并照料的管道。少于两个，自建是可行的。超过三个，就要怀疑自己的估算。
  • 指定对账人。谁来判断两个相互矛盾的事实哪个是真的，什么时候做判断？如果答案是“模型”或“以后再说”，你就找到了自己的失败模式。
  • 在开始之前设置漂移警戒线。选定一个你每月执行的检查，比如抽样十个事实并与实际情况核对。如果你不愿承诺做这个检查，你就是在选择漂移。
  • 计算 ROI 时，要看避免的招聘成本，而不是工具成本。 关键的财务问题是：现有的上下文能否让同一个团队承接更多客户，然后才是项目结项能快多少。

仍然需要人工的部分

无论你怎么选，有些工作始终要靠人。判断力无法通过任何存储——自建或外购——来传递。在 Tandem 中，你可以选择将 Claude Code 会话中的哪些内容同步进大脑，任何内容都不会在你未触发的情况下被推送。风险检查会返回一份风险列表，每条风险都附带解释、原因和依据来源，而每一条都由人来决定如何处理。评估任何记忆系统是否如实反映你的客户情况，仍然是一门有待完善的功课，工程师应该向每一家供应商——包括我们——提出这个问题。

决策的成本核算

自建给你控制权，以及一个未列入预算的“第二产品”。外购给你的是上下文新鲜度的服务水平保障。就商业论证而言，我们能分享的最清晰案例是 Qonto 的：“Qonto 的入职团队约有 90 名专员。Tandem 的自动化协调和第三天延迟检测让团队多承接了 34% 的业务量，并避免了约 23 个招聘名额。按每名专员 8 万至 10 万欧元的全负担成本计算，节省的人力成本为 180 万至 230 万欧元，而 Tandem 的年成本约为 85 万欧元，第一年回报率为 2 到 2.7 倍。”详情见 Qonto 案例。

如果你的团队正在自建，或正在为此争论不休，最快的比较方式就是用你们自己的客户来验证。预约演示，看 Tandem 在你们一个正在运行的实施方案中标记风险，然后再决定是否还要继续自建。

常见问题

自建内部共享上下文层到底需要多长时间？

单用户原型只需几天。多用户权限、按数据源的管道以及数据对账则需要数月的零散投入，而这正是我们见过的自建项目搁浅之处。请为一位长期负责人做预算，而不是为一个有截止日期的项目。

自建上下文层的运行成本是多少？

主要是资深 FDE 的时间投入，这也是它很少出现在估算中的原因。开发者每周已经要花 17 个以上的小时做维护工作，而大脑还会在负担上增加管道、权限和数据质量排查。相比之下，基础设施成本微不足道。

500 到 1,000 条事实的漂移阈值是硬性规则吗？

不是。这是我们在已服务的团队中的观察结果，并非有据可查的基准，且会随客户数量和管理规范程度而变化。稳定的部分是它的形态：低于该阈值时，一个人看到错误就能随手修正；高于该阈值时，矛盾的增长速度会超过对账能力。

什么时候自建显然是正确的选择？

当上下文层本身就是你的核心产品时，当有平台团队将其纳入路线图并负责维护时，或者当政策禁止使用外部供应商时。只管理少数几个客户的独立 FDE，用个人知识库加自律也能运转良好。

我们已经建好的 Supabase 存储还能继续用吗？

是的，团队通常会这样做，作为存档。真正关键的切换在于新上下文落在哪里、问题在哪里提出。Tandem 的大脑可以通过 Tandem MCP 从 Claude、Claude Code 或 ChatGPT 中查询，因此日常工作会转移到那里，而旧的存储保持原样。

关键术语

共享上下文：账户级状态（承诺了什么、决定了什么、有哪些风险、下一步是什么），整个团队及其 AI 工具都可以查询并信任它。它解决的问题是上下文只存在于某个人脑中或某个知识库中。

项目大脑：这一类别的核心产物，一个持续维护、可查询的存储，保存经过核对并附带来源的项目事实。参见什么是项目大脑。

账户大脑：Tandem 版本的项目大脑，具备风险检测、由人工批准的 Tandem Agent 操作，以及客户工作区。是面向实施与部署团队的 AI 工作区的一部分。

上下文漂移：知识库所记录的内容与账户实际情况之间不断扩大的差距。它本质上是隐性的，因为检索功能仍在正常工作，而答案却已过时。

自建还是购买阈值：维护内部工具的成本超过购买相应服务水平成本的临界点，通常在流水线、身份验证和对账工作超出某位负责人的业余时间承受范围时被突破。

Tandem MCP：Tandem 的 Model Context Protocol 服务器，让 Claude、Claude Code 或 ChatGPT 能够查询账户大脑，并将选定的会话事实同步回其中。