TL;DR: 你在 Claude Code 中搭建的“大脑”只能服务一个人，因为它本来就是为一个人设计的。自动记忆是本机存储的，会话中的经验随会话结束而消失，你的 Obsidian 仓库只有一个读者。这一点比过去更重要，因为42% 的机构知识是个人独有的，而且 FDE 团队正在快速增长。将客户背景迁移到共享、可查询记忆中的团队报告了诸如 Aircall 每位工程师的部署量提升 3 倍之类的成果。本文梳理了个人化设置在哪些地方失效，以及团队记忆需要承载什么。
前沿部署工程的招聘速度超过了其体系化的速度。该职位的月度招聘信息在 2025 年 1 月至 9 月间增长了 800% 以上，而这份工作本身就依赖上下文运转。前沿部署工程师是指大约一半时间与客户一起理解问题、另一半时间为该特定客户构建解决方案的工程师。这两部分工作产生的知识都不会落入工单：客户承诺了什么、你在下午 4 点的会话中决定了什么、你排除了哪条集成路径以及为什么。
最优秀的 FDE 已经为自己解决了这个问题。他们将通话记录通过 Claude Code 处理，为每个项目维护一个 Obsidian 仓库，并保存迁移文件，以便新会话能从上一个会话结束的地方继续。这套方法行之有效，而且效果很好——直到第二个人需要其中的内容。一家垂直领域金融科技初创公司的创始 FDE 直言不讳：“共享上下文仍然是一个未解决的问题。这真的很令人惊讶。”
他说得对，而原因在于结构性问题，而非缺少某个功能。个人化技术栈的每一层，从 Claude Code 的记忆模型到磁盘上的仓库，都假设只有一个所有者。本文将按照这套技术栈实际搭建的方式逐一讲解，指出它失效的四个地方，以及团队版本必须承载的三种记忆。如果你想先了解这个术语本身的定义，请参阅什么是共享上下文。
FDE 实际搭建的个人大脑技术栈
我们反复看到的这套设置包含三层，由从未相互交流过的人各自独立搭建。这种趋同性是问题真实存在的最有力证据。
一个仓库、一条记录管道和一个终端
基础层是一个 markdown 仓库，通常是 Obsidian，每个客户账户对应一个文件夹。通话记录从录音工具流入，由 Claude 进行总结，并作为每日笔记保存。随着项目推进，决策、承诺和注意事项不断累积。这是应用于客户工作的第二大脑模式，在单人使用时确实非常好用。
在此之上是 Claude Code。知识库成为会话的上下文，会话产生解决方案和决策，其中一部分会回流到笔记中。一家工作流自动化平台的 FDE 负责人坦率地描述了这种规模：“我和 Claude Code 已经进行了几十个会话了。而我才刚刚意识到，这些会话之间没有任何集中管理。”
迁移仪式
第三层是手动粘合。当一个会话的上下文窗口填满时，FDE 会为下一个会话写一份交接文件：当前状态、未完结的事项、已做的决策。这是一种手工执行的上下文迁移，每周要进行好几次，而且它只把上下文迁移给你自己。Anthropic 自己的指导也是同样的思路，建议你在任务之间清除上下文，因为窗口很快就会填满。会话被设计成用完即弃的，但其中的知识不是。
一些团队正试图把这一切正式化。一家垂直领域 AI 创业公司的 FDE 告诉我们，他的团队正在构建“我们称之为内部 FD OS 或 FD 操作系统”的东西，目标是为每个人创建“一个共享的上下文仓库”。这个直觉是对的，但底层的工具却在与之对抗。
为什么你在 Claude Code 中构建的大脑无法在团队中共享？
简短的回答：Claude Code 记忆中唯一团队共享的部分是存放编码规范的那部分，而客户账户上下文并不属于那里。
CLAUDE.md 实际共享了什么
Claude Code 的记忆层级中有一层是真正共享的。官方文档将项目记忆列为“通过源码控制与团队成员共享”，最佳实践指南也告诉你把 CLAUDE.md 提交到 git，让团队可以共同贡献。因此，指令、规范和构建命令确实能在人与人之间传递，前提是这些人在同一个代码仓库中工作。
这是一个真实的机制，但对于账户状态来说，它的形态是错的。一份写着“使用 pnpm，优先使用 v2 API”的 CLAUDE.md 会随着时间不断增值。而一份写着“Meridian 的切换在周二的电话会议后推迟到了 10 月 12 日”的 CLAUDE.md，在下次通话结束的那一刻就过时了，而且你的销售团队永远不会打开代码仓库去读它。我们在 Claude Code 团队记忆中逐个文件地剖析了这一点。
什么永远不会离开你的机器
真正从你的工作中学习的层在设计上就是个人的。同样的文档指出“自动记忆是机器本地的”，其文件“不会在机器或云环境之间共享”。Claude Code 在你的会话中积累的关于某个账户的一切——每一次调试的死胡同、每一条客户约束——都只留在你的笔记本电脑上。你的同事的 Claude 在同一个账户上要从零开始。
用户已经注意到了
这不是什么小众抱怨。Claude Code 仓库中的一个公开功能请求要求提供“一个共享层，至少让项目记忆和技能可以在 Claude Code、Cowork 和 Claude.ai Projects 之间访问”，并指出目前记忆文件、MCP 连接和上下文无法在不同界面之间迁移。需求已经明确登记。产品的记忆模型仍然是个人化的，这对一个编码工具来说是合理的，但对一个通过它运营客户账户的团队来说，却是一个真实的缺口。
个人大脑在哪里会失灵？四个失灵点
一个拥有紧凑知识库的独立 FDE 不会感到痛苦。痛苦会按时间表到来，出现在四个可预测的时刻。如果你正在规划你的 FDE 团队结构，这四点值得在问题发生之前就提前设计好。
失灵点 1：第二个 FDE 加入账户
当你为账户招入第一个人手时，这堵墙就出现了。上文引用的那位创始 FDE 对此直言不讳：“最重要的一点是，我无法把 Obsidian 大脑分享给其他人。”Obsidian 的同步协作功能虽然存在，但其官方限制对团队使用来说非常严苛：“尚不支持细粒度权限。所有协作者获得的权限与知识库所有者相同”，没有实时编辑，冲突只能在同步时合并。两个人同时写一个知识库是一个合并问题，而不是记忆。
于是第二个 FDE 只能用老办法上手——不断打断第一个人。关于入职的研究显示，新人的上手期长达六个月，其中大部分时间都花在寻找同事早已掌握的知识上。我们为让第二个 FDE 上手一个正在运营的账户单独写了一份操作手册，而整个流程都依赖于新人无需开口询问就能查询到的上下文。
失灵点 2：工程师（以及他们的编码 Agent）需要客户的上下文
为你的账户构建产品的工程师需要知道承诺了什么、决定了什么，而且他们的编码 Agent 也越来越需要这些信息。Google 2025 年的 DORA 报告发现90% 的受访者现在在工作中使用 AI，同时 30% 的人表示对 AI 生成的代码信任度很低或没有信任。上下文质量是关键杠杆，因为正如同一份报告所说，AI 会“放大已经存在的东西”。一个被喂入过时或缺失的账户上下文的 Agent，放大的恰恰就是这些问题。
如今，FDE 靠亲自沟通来弥合这一差距。一位保险理赔平台的 FDE 描述了这样的结果：“销售说的是一套，市场说的是另一套，我实现的东西……就像在用过时的文档玩传话游戏。”每一次通过人工中转，也都要消耗这个人。关于打断的研究表明，每次上下文切换需要23 分 15 秒才能回到原来的任务。
失灵点 3：经理和销售团队询问状态问题
第三个断点是那些永远不会打开知识库或终端的读者。准备季度业务回顾（QBR）的经理、走进续约电话的客户经理、正在处理升级工单的支持主管。正如那位金融科技领域的 FDE 所说：“销售人员不用 Claude Code。”他们的问题很简单，但回答起来成本很高：72% 的项目专业人员每月要花半天甚至更多时间来汇总报告。这半天时间，大多是 FDE 在向那些读不了笔记的人重新讲述自己的笔记里早已记录的内容。
断点 4：交接
离职、轮岗、晋升、并购带来的新客户。最终，掌握上下文的那个人总会变得不可用，而这正是个人大脑失效最严重的地方。Panopto 2018 年的研究发现，42% 的组织知识是个人独有的，并估算出低效的知识共享每年给大型企业造成 4700 万美元的损失。离职前一周写的交接文档只是一份快照。它无法回答后续问题，而且一旦作者离开，也没人能对照原始来源去核实它。
团队记忆需要保存什么？
指出断点只是容易的那一半。更难的问题是，共享记忆到底要包含什么才能挺过这些断点。观察那些完成了这一转变的 FDE 团队，答案是三条信息流，每一条都附带来源。这就是项目大脑的形态，也是这些团队最终趋同的那类产物。
客户事件：承诺了什么，发生了什么变化
第一条信息流是面向客户的记录。通话中做出的承诺、变更过的日期、调整过的范围、暴露出的风险。这些材料目前被困在通话记录和每日笔记里，而它正是第二位 FDE 和客户经理都需要的。检验标准是事实是否带有来源：像“切换时间改到 10 月 12 日”这样的说法，应该链接到做出变更的那次通话。
产品决策：决定了什么，为什么
第二条信息流是决策，尤其是构建过程中做出的决策。你选择了哪条 API 路径、排除了哪些方案、是什么约束促成了这个选择。这些事实一旦缺失，工程师就得付出高昂代价重新摸索。知识工作者每周已经要浪费 5.3 小时等待或重新创建同事已有的知识，而一个被错误重新发现的决策，比慢慢重新发现还要糟糕。
会话：终端里发生了什么
第三条信息流最新，也最容易流失。真正的交付决策现在发生在 Claude Code 会话里，而会话一结束它们就消失了。上文 FDE 负责人所描述的“几十个会话”问题，本质上是一份从未被记录在任何地方的决策日志。把选定的会话成果有意识地、并在你批准同步范围的前提下写入团队记忆，本身就是一项独立的工作流。我们在Claude Code 会话中做出的产品决策一文中对此有详细介绍。
团队记忆需要在哪里可以被访问到？
内容只是规格的一半，另一半是触达，因为每个断点都涉及在不同工具中阅读的人，而记忆只有在人们能在自己已经工作的地方使用它时，才算得上是共享的。
对于工程师和他们的 Agent 来说，那是终端。Tandem 的 账户大脑 可以通过 Tandem MCP 从 Claude、Claude Code 或 ChatGPT 访问。在 Aircall，“工程师通过 MCP 在 Claude 中查询上线相关背景（承诺事项、迁移日期、集成决策）。”该公司的资深软件工程师 Paul Yi 描述了实际使用中的感受：“我在 Claude 里问‘什么在阻碍切换’，就能得到带来源的真实答案。同样的问题，无论谁问，答案都一样。我们曾试图自己构建这样的东西，但没能坚持下来。”
对于管理者销售人员来说，是 Claude 聊天，他们无需接触终端就能向同一个大脑提出同样的问题。对其他人来说，则是 Slack，简报可以按需或按计划送达。多人向同一个大脑推送内容，提醒接收者可配置，而且大脑本身是通过 AI 聊天界面编辑的，而不是靠人工维护 markdown 文件。一个 Salesforce 连接器覆盖了 CRM 侧。当大脑执行风险检查时，它会返回一份风险列表，每条风险都附带解释、原因以及背后的来源和引文，因此在任何内容呈现在客户面前之前，人类都可以先行核实。
个人大脑 vs 团队记忆：真正改变的是什么
大多数团队并不是直接从知识库跳到产品。现实的比较应包括他们今天实际在用的东西，首先从那个没人有意选择、却默认存在的方案开始。
- 电子表格 + Slack。谁能读：理论上所有人。谁维护：没有特定负责人，更新滞后。交接存续性：差，讨论串散落各处，跟踪表过时。Agent 访问：无。
- Obsidian 知识库 + Claude Code。谁能读：所有者本人。谁维护：所有者本人。交接存续性：差，42% 的知识留在个人手中。Agent 访问：仅限所有者的会话。
- git 中的 CLAUDE.md。谁能读：该仓库的工程师。谁维护：提交代码的人。交接存续性：部分，约定得以保留，但账户状态从未存放在其中。Agent 访问：有，但仅限约定内容。
- 自建上下文存储。谁能读：可配置。谁维护：某位工程师兼职维护。交接存续性：因团队而异，漂移是主要风险。Agent 访问：如果你构建了的话。
- 项目大脑（例如 Tandem）。谁能读：整个团队，从 Claude Code、Claude 聊天或 Slack 访问。谁维护：从通话、会话和连接器同步，由人工审批。交接存续性：为此而设计。Agent 访问：通过 Tandem MCP。
关于那张表格，有两点坦诚的说明。自建那一行完全可以行得通，而且能让你保持完全掌控，但我们在各团队中的观察是，普通的大脑（如 Obsidian 之类）在协调整理不再有人负责之后，大约会在 500 到 1,000 条事实之间逐渐失准。而自建还是采购的抉择也值得比表格中的一个单元格更多的篇幅，所以我们在自建还是采购共享上下文层中列出了真实的模式和成本。MIT 2025 年的研究提供了一个在投入工程师之前值得了解的基础成功率：采购的专业工具成功率约为 67%，而内部自建大约只有三分之一，而在一个 95% 的企业 AI 试点都没有产生可衡量的损益影响的领域，这主要是因为通用工具学不会团队的工作流程。
无需迁移项目即可切换
完成切换的团队并没有停下工作来做这件事。模式是这样的：
- 选一个进行中的客户账户，而不是你的存档。 迁移多年的知识库历史才是扼杀项目的任务。记忆从今天开始。
- 先接入事件源。 通话和 CRM 在任何人改变习惯之前，就为大脑提供了客户账户事件流。
- 保留你的个人工具栈，加上同步。 你的知识库和你的会话都保留不变。变化的是选定的成果会被推送到共享大脑，而由你决定什么值得推送。
- 给阅读者各自的入口。 工程师在 Claude Code 中使用 Tandem MCP，经理使用 Claude 聊天，客户团队使用 Slack 简报。
- 让第一次交接或上手成为检验。 团队记忆的衡量标准是，下一个人是否还需要上一个人，最好是在这变得紧急之前。Spendesk 的客户成功与客户管理负责人 Mathilde Hamy 描述了及格标准：“一名工程师接手任何客户账户，五分钟内就知道承诺了什么、有什么风险。没有人需要维护任何东西。”
保留人工的部分
共享记忆消除的是传话的工作，而不是判断。把界限说清楚比推销话术更重要。
你仍然决定从会话中同步什么。除非你选择，否则没有任何内容会从你的终端进入团队记忆，而每个检查点自动重新同步是我们尚未实现的功能。Agent 负责起草和标记，但风险会连同理由和来源一起返回，正是为了让人在 anything 到达客户之前可以批准或拒绝。关系本身也无法转移。一名新的 FDE 可以在五分钟内读完所有承诺，但仍然需要数周时间才能赢得承诺背后的信任，这就是为什么我们的上手手册把上下文转移和判断转移当作两个不同的问题。而客户账户上的第一次艰难对话是你的，无论大脑知道什么。
用商业术语来说，结果是什么
这些断点会悄然累积，这也是团队长期容忍它们的原因。修复它们带来的回报体现在三个方面，按顺序依次是：不必招聘的人员、推进更快的项目，以及消失的管理工时。
避免招聘是回报最大的一项。Qonto 的入职运营团队约有 90 名专员。Tandem 的自动化协调和第三天延迟检测让团队多承接了 34% 的业务量，并避免了大约 23 次招聘。按每名专员 8 万至 10 万欧元的全负担成本计算，相比 Tandem 每年约 85 万欧元的成本，这相当于节省了 180 万至 230 万欧元的薪酬支出，第一年回报率达 2 到 2.7 倍。完整模型见 Qonto 案例。
速度是第二项回报。Aircall 将从签约到切换的时间缩短了 30%，现在每位工程师能执行 3 倍数量的上线部署（5 → 15）。他们的 CPO Tom Chen 点明了其中的机制：“我们看到工程师们自信地执行他们从未参与过相关沟通的上线部署。记忆属于团队，而不是个人。”最后这句话用九个字概括了本文的全部论点。
如果你管理着一支 FDE 或实施团队，问题不在于你的员工是否聪明。他们聪明，而且非常聪明，但目前每颗大脑只有一个读者。了解 Tandem 如何为 FDE 团队服务，或者更好，通过演示看 Tandem 如何为你正在进行的一个实施项目标记风险。
常见问题
我不能直接把 CLAUDE.md 提交到 git，然后称之为共享上下文吗？
你应该提交它，但它解决的是另一个问题。项目 CLAUDE.md 与同一代码库中的人共享编码规范，这也是文档所推荐的。而客户状态（承诺、日期、决策、风险）每天都在变化，需要来源依据，而且需要那些永远不会克隆代码库的读者。完整分析请参阅 Claude Code 团队记忆。
我必须放弃我的 Obsidian 仓库和 Claude Code 配置吗？
不，你也不应该放弃。个人工具栈是上下文产生的地方，它仍将是你的工作环境。改变的是，选定的成果会同步到一个他人和 Agent 都可以查询的共享大脑，而不是止步于你的笔记本电脑。
我能在客户面前信任 AI 生成的客户状态吗？
信任来源，而非摘要。Tandem 的风险检查会为每条风险返回解释、原因以及背后的来源引文，因此你在复述之前可以先核实该说法。Aircall 的工程师形容他们得到的是“带来源的实际答案”，而且无论谁提问，答案都相同。
如果我的 FDE 团队目前只有我一个人呢？
那么你的个人配置今天可能够用，但断点反正已经写进了你的日程表。第二次招聘、第一个需要你上下文的工程师、第一次交接，这些到来得都比团队预期的快，尤其是该岗位的招聘在九个月内增长了超过 800%。尽早建立共享记忆，比日后重建要便宜得多。
团队记忆和知识库或企业搜索是一回事吗？
不是。知识库存放的是经过整理的文档，搜索检索的是曾经写下的内容，无论是什么时候写的。团队记忆保存的是当前的、带来源链接的客户状态：截至目前承诺了什么、决定了什么、存在什么风险。面向 FDE 的项目大脑一文详细阐述了这条界线。
关键术语
共享上下文：整个团队及其 AI Agent 都可以查询的客户知识，而不是只掌握在某个人手里的知识。这个术语来自从业者，它所指代的正是本文讨论的问题。
团队记忆：共享上下文的同义词，强调持久性。即不因任何单个成员离职、晋升或休假而丢失的记忆。
项目大脑：这一类别的核心产物，是一份持续维护、带来源链接的项目状态记录，人们和 Agent 查询它，而不是去问“谁知道”。
客户大脑：Tandem（面向实施和部署团队的 AI 工作区）中的一部分，用于保存共享的客户上下文，运行带来源的风险检测，并为 Tandem Agent 和客户工作区提供数据。
前沿部署工程师（FDE）：前沿部署工程师是指大约一半时间与客户一起理解问题、另一半时间为该特定客户构建解决方案的工程师。
CLAUDE.md：Claude Code 的项目记忆文件。通过版本控制与队友共享，用于记录约定和指令，而非客户状态。
自动记忆：Claude Code 的机器本地记忆，会在你的多次会话中积累经验教训。它不会在机器、人员或云环境之间共享。
Tandem MCP：Tandem 的 MCP 服务器，使客户大脑可以从 Claude、Claude Code 或 ChatGPT 中查询，无论对人类还是编程 Agent 都适用。
---