TL;DR: Claude Code 在团队间共享的记忆只有一种：提交到源码管理的项目 CLAUDE.md，它把编码规范带给每一个克隆该仓库的人。Auto memory 从设计上就是机器本地的，而整个记忆层级中没有任何部分是用来存放客户背景信息的——比如向客户承诺了什么、做了什么决定、有什么风险。在如今 90% 的开发者在工作中使用 AI 的背景下，这个缺口每周都在扩大。Aircall 通过一个 Claude Code 可通过 MCP 查询的团队记忆补上了这一缺口，现在每位工程师的交付速度提升了 3 倍。

一位整天在 Claude Code 中工作的前沿部署工程师会积累起真正有价值的记忆。项目 CLAUDE.md 记录了构建命令和架构上的特殊之处。Auto memory 则悄悄学会了哪个测试套件不稳定，以及你如何组织一次数据库迁移。几个月后，这个工具就像了解这个客户一样了解你。

然后第二个人接手了这项工作。一位工程师接手你负责范围的某个集成，或者一位新的 FDE 加入这个客户，几乎没有任何记忆随之传递过去。某工作流自动化平台的 FDE 负责人说得很直白：“我和 Claude Code 进行过好几十次会话，我才刚开始意识到这些会话完全没有集中管理。”

本文梳理了 Claude Code 的记忆在团队间实际共享了什么、哪些永远不会离开你的机器，以及客户的业务背景应该存放在哪里。简而言之：git 传递的是你的编码规范，而没有任何东西传递你的业务背景。

Claude Code 记忆的组织方式

Claude Code 的记忆系统是一组在会话启动时加载的 markdown 文件。四个层级从公司级一直堆叠到机器级，而每个层级对这里的关键问题——还有谁能看到它？——都有不同的答案。

四个文件层级

  • 托管策略。 由管理员部署到组织内的每台机器。它携带全组织范围的指令，个人无法覆盖。
  • 用户记忆。 位于 ~/.claude 的个人 CLAUDE.md，适用于你打开的每个项目。记录你偏好的工作方式，只有你自己可见。
  • 项目记忆。 仓库根目录下的 CLAUDE.md。官方文档将项目指令描述为“通过源码管理与团队成员共享”，这一条款就是全部的团队共享机制。
  • 本地项目记忆。 CLAUDE.local.md，不纳入版本控制，用于存放不应让队友看到的每个项目的笔记，比如你的沙箱 URL。

Auto memory，由 Claude 自动整理的部分

除了你手动编写的文件之外，Claude Code 还会维护自动记忆：一个 MEMORY.md 和若干主题文件，由它在了解你的项目的过程中自行维护。文档明确说明了其范围：“自动记忆是机器本地的……文件不会跨机器或云环境共享。”此外还有预算限制。只有 MEMORY.md 的前 200 行或 25KB 会加载到上下文中，所以即使是你自己的机器，保存的内容也比你想的要少。

CLAUDE.md 能在团队间共享吗？

其中一层可以，而且值得做好。Anthropic 自己的最佳实践指南建议“将 CLAUDE.md 提交到 git，让团队都能参与贡献。这个文件的价值会随着时间不断累积。”编码规范、构建命令、测试中的坑、关于代码库的架构决策：所有这些都会随仓库克隆传递给任何人，而修改则以拉取请求的速度送达，并附带审查。

这是代码上下文层面真正的团队记忆。如果你的团队还没有提交共享的 CLAUDE.md，本周就从这里开始。本文其余部分要讲的，是这个文件从未被设计承载的内容。

什么内容永远不会跨人员或机器传递

会话中的经验随会话消亡

文档建议在任务之间运行 /clear，因为上下文窗口很快就会被填满。会话在设计上就是一次性的，这对代码来说没问题，但对决策来说却很糟糕。一家垂直领域金融科技公司的创始 FDE 描述了半个行业都已采用的变通习惯：“每当我的 claude code […] 达到 76% […] 我就有一本台账。”一个手动维护的迁移文件能让下一个会话从上一个会话压缩的地方继续。它只对一个人在一台机器上有效，对其他任何人都无效。

自动记忆只留在机器上

Claude Code 通过自动记忆了解到的关于你项目的一切，都只属于你一个人。换台笔记本电脑，它就从零开始。坐在你旁边、在同一个仓库上工作的队友什么都得不到，因为记忆属于机器，而不属于项目，也不属于团队。

任何内容都无法跨界面流通

Claude Code 仓库上的一个开放的功能请求要求提供“一个共享层，至少要满足：项目记忆和技能可以在 Claude Code、Cowork 和 Claude.ai Projects 之间访问。”在类似功能发布之前，记忆文件、技能和 MCP 连接都是按界面单独配置的。聊天产品则从另一面映照出同样的问题：ChatGPT 的项目记忆存在于聊天产品内部，按项目隔离上下文，而且没有任何内容能到达终端。

为什么账户上下文在 CLAUDE.md 中没有容身之处

账户的业务上下文在这个层级结构中无处安放，文档实际上也通过将 CLAUDE.md 的范围限定为项目规范和指令说明了这一点。启动会议上承诺了什么、为什么你放弃了 webhook 方案改用轮询、客户 IT 团队冻结了哪个切换日期：这些是账户状态，而不是代码状态。有三个特性使它不适合放在这里。

它以通话的速度变化，而不是以拉取请求的速度变化。周二通话中做出的承诺，在有人记得去开一个 PR 之前会一直停留在文件里过时，而没人会在客户通话之后去开 PR。

最需要它的人从不克隆代码仓库。同一位创始 FDE 告诉我们：“最重要的一点是我无法把 Obsidian 大脑分享给其他人……销售人员不用 Claude Code。”销售、经理和客户成功团队需要关于客户的答案，而一个藏在 git 权限后面的 markdown 文件对他们所有人都不可见。这是共享上下文问题的缩影，并且有一个值得内化的工作定义：承诺了什么、决定了什么、有什么风险、下一步是什么。

即使对工程师来说，会议记录也不是客户状态。把通话摘要粘贴进 CLAUDE.md 会把文件那点微小的上下文预算浪费在未经整理的散文上。项目大脑里应该放的是带有来源的、经过核对的事实，那是一种不同的产物，需要不同的管道。

各类记忆存放之处的对比

  • 电子表格 + Slack。存放内容：状态行、埋在对话线程里的决策。谁还能读到：任何有访问权限的人，前提是他们知道去哪里找。如何保持更新：手动更新，因团队而异。
  • git 中的项目 CLAUDE.md。存放内容：编码规范、命令、架构笔记。谁还能读到：克隆代码仓库的队友。如何保持更新：拉取请求。
  • 自动记忆（MEMORY.md）。存放内容：Claude 对你项目的学习成果。谁还能读到：没人，它只存在于本机。如何保持更新：Claude 在每台机器上自行维护。
  • Claude Projects / ChatGPT Projects。存放内容：文件、指令、聊天侧的记忆。谁还能读到：协作者，受套餐和文件数量限制。如何保持更新：由维护每个项目的人负责。
  • 团队记忆（客户大脑）。存放内容：承诺、决策、风险，每条都带来源。谁还能读到：整个团队及其 Agent，可从 Claude Code、Claude 聊天或 Slack 访问。如何保持更新：队友推送他们选择的更新，提醒接收者可配置。

第一行才是真正的在位者。大多数团队不是输给某个竞品记忆产品，而是输给一个没人更新的追踪表和一条没人看完的 Slack 滚动消息。

团队如何给 Claude Code 提供共享记忆

行之有效的模式保持了清晰的分工。CLAUDE.md 存放这个团队如何写代码。代码仓库之外的团队记忆存放每个客户上什么是真实的。Claude Code 通过 MCP 访问后者，就像它访问任何外部系统一样。

Tandem 是为实施与部署团队打造的 AI 工作区，正是作为第二种记忆而构建的。账户大脑存储每个客户的带来源链接的事实，通过 Tandem MCP 在会话中查询它只需一次连接，而不是每个会话粘贴一次。当会话产生了值得保留的内容时，由你自己推送到大脑，并选择推送什么。在 Claude Code 会话中做出的决策不再随着 /clear 而消失。

Aircall 正是这样分工运作的。工程师通过 MCP 经由 Claude 查询上线背景信息（承诺事项、号码移植日期、集成决策）。那里的高级软件工程师 Paul Yi 这样描述效果：“同样的问题，同样的答案，无论谁问。”多人向同一个大脑推送内容，而大脑通过 AI 聊天界面编辑，而不是靠人工打理文件——这对维护过 wiki 的人来说意义重大。一家工业 AI 公司的 FDE 用一句话向我们提出了需求：“我不想再照看另一个系统。”

对于围绕这一角色扩充团队的团队，Tandem 的 FDE 团队工作区覆盖了流程的其余环节：按需或定时的简报，可送达任何地方（包括 Slack），经理或销售可以从 Claude 聊天中查询同一个大脑，而不必来打扰你。

哪些仍需人工操作

坦诚说明边界，因为边界确实存在。

你的共享 CLAUDE.md 仍需要维护。只有当人们真正针对它提交 PR 时，它的价值才会不断累积，而且当它臃肿时，总得有人修剪。

将会话同步到团队记忆是一个有意识的动作。由你触发，并由你选择什么值得保留。在每个检查点自动重新同步是用户提出的需求，但尚未上线。针对大脑的每一次 Agent 操作，都由人来选择或批准会发生什么。

而判断力是无法迁移的。记忆告诉下一位工程师做了什么决定以及为什么。它不会告诉他们接下来该做什么决定，这正是为什么在上下文问题被解决之后，资深 FDE 依然有价值。

代码交给 git，账户记忆另配一套

共享的 CLAUDE.md 在约定共享方面领先所有其他 AI 工具好几年，所以要充分利用它。但它永远装不下账户的记忆，因为自动记忆止步于你的机器，而业务上下文在设计之初就被有意排除在外。把两者清晰分开的团队得到了 Aircall 得到的效果：任何工程师问“切换上线被什么卡住了”，都会得到与 FDE 会给出的相同的、有来源的答案。观看 Tandem 在你自己的一个活跃账户上回答这个问题的演示。

常见问题

我的同事能看到我的 Claude Code 自动记忆吗？

不能。文档说明自动记忆是机器本地的，不会在机器之间或云环境之间共享。要把一条经验交给同事，要么通过 PR 提交到项目的 CLAUDE.md，要么把它推送到仓库之外、同事也能查询的团队记忆中。

我应该把客户承诺写进 CLAUDE.md 吗？

不行。承诺以通话的速度变化，而文件以 PR 的速度更新，需要承诺信息的人大多看不到代码仓库，而且记忆文件的上下文预算很小，最好留给编码规范。把代码上下文放在 CLAUDE.md 里，把客户账户上下文放在可查询的团队记忆中。

Claude Code 的记忆能跟随我在自己的多台机器之间迁移吗？

只有 git 里的内容可以。项目级 CLAUDE.md 随代码仓库一起走，而自动记忆和 CLAUDE.local.md 则留在各自的机器上。换一台新笔记本电脑时，无论旧机器积累了多少知识，MEMORY.md 都是空的。

对于一个两人的 FDE 团队来说，共享的 CLAUDE.md 够用吗？

对于代码规范来说，够用，而且这是正确的第一步。但当你第一次让第二位 FDE 加入一个进行中的客户账户时，差距就显现出来了：他们会问承诺了什么、为什么做出某个决策、有什么风险。这些内容都不在代码仓库里。

团队实际上是如何给 Claude Code 提供客户账户上下文的？

通过 MCP。Tandem MCP 把账户大脑开放给 Claude、Claude Code 或 ChatGPT，让工程师和他们的编码 Agent 在会话中途就能调取承诺、决策和风险。在 Aircall，这一模式支持每位工程师实现 3 倍的交付量，而且无论谁提问，得到的都是同一个有出处的答案。

关键术语

共享上下文：整个团队及其 AI 工具都可以查询的账户级记忆。它回答承诺了什么、决定了什么、有什么风险、下一步是什么，并提供信息来源。

团队记忆：共享上下文的同义词，强调的是失效点，即记忆能否在人与人之间传递后依然留存。

项目大脑：这一类别的核心产物。一个持续维护、带来源链接的项目真实状态存储，而不是散落各处的笔记和聊天记录。

账户大脑：Tandem 的产品部分。为每个客户账户配备一个项目大脑，再加上风险检测、Tandem Agent 和客户工作区。

CLAUDE.md：Claude Code 的指令文件。项目级的那份通过版本控制与队友共享，是 Claude Code 记忆中唯一团队共享的部分。

自动记忆：Claude Code 为自己整理的记忆（MEMORY.md 加上主题文件）。仅存在于本机，从不在机器、人员或界面之间共享。

Tandem MCP：一个 MCP 服务器，让 Claude、Claude Code 或 ChatGPT 能够查询账户大脑，并把选定的更新推送回去。