为什么成员离职会带走上下文
账户被移除的瞬间，聊天记录即变得无法访问
这是最清晰的界限，Anthropic 在文档中明确指出：“当用户从您的 Team 或 Enterprise 组织中被移除时，其余成员将无法再访问其聊天记录。”
这也适用于共享链接。帮助中心甚至给出了人们会遇到的错误提示：“未找到对话。请求的对话不存在，或者您没有访问权限。”某人在六个月前粘贴到工单中的链接将无法再打开。
数据并没有消失——“被移除用户的数据仍将包含在您组织的 Primary Owner 运行的任何数据导出中”——但管理员导出是一种合规工具，而不是在周二下午回答某个具体问题的方法。
成员离职后，私有项目仍保持私有
项目的可见性是在创建时决定的，移除成员并不会放宽这一限制。“如果项目的可见性设置为私有，一旦该团队成员从账户中被移除，组织的其他成员将无法访问该项目。”
文档中给出的补救措施将工作交给了即将离职的人：“如果团队成员知道他们正在私有项目中处理某些需要交接的工作，他们需要调整项目的权限，以便组织中的每个人都可以编辑它，或者邀请特定用户并授予他们‘可编辑’权限。”
这在设计上是正确的，但在流程上却很脆弱。它完全依赖于某人在离职前的最后一周，还能记得其他人会需要他们的哪些项目。
个人记忆本质上就是私有的
Claude 的记忆是基于每个用户的存储。在 Team 和 Enterprise 计划中，所有者可以控制该功能是否可用，然后，用 Anthropic 的话来说，“所有者无法查看或编辑用户的个人记忆。”
这是一种隐私保护，也理应如此。但这意味着 Claude 学到的关于该员工工作如何衔接的一切——专业词汇、经常遇到的限制、涉及的人员——在任何可检索的意义上都不属于组织知识。没有任何视图可以让你直接继承它。
编程工具的划分方式相同，且界限体现在路径中
一旦你开始留意，就会发现这种模式在不断重复，而且通常在文件路径中清晰可见。
Claude Code 从 ./CLAUDE.md 加载项目指令，其官方文档将其描述为通过版本控制共享给“团队成员”。个人指令保存在 ~/.claude/CLAUDE.md，范围仅限“仅限您（所有项目）”。而自动记忆（Claude 为自己记录的关于修正和决策的笔记）则保存在 ~/.claude/projects/<project>/memory/，并有明确的警告指出它“是机器本地的”，且“文件不会跨机器或云环境共享”。笔记本电脑被格式化，这些记忆也就彻底消失了。
Cursor 将项目规则（Project Rules）放在 .cursor/rules 中，并声明它们“受版本控制”。用户规则（User Rules）是个人专属的。团队规则（Team Rules）集中管理，并“包含在该团队所有仓库和项目的 Agent (Chat) 模型上下文中”。此外，计划模式（Plan Mode）有一个值得注意的默认设置：“计划默认保存在您的主目录中。点击‘保存到工作区’（Save to workspace）可将其移至您的工作区，以便日后参考、团队共享和归档。”任何没有点击该按钮的计划，都只是一个个人文件。
Cline 在意图上表现得异常直接。它的指南建议使用项目配置“来实现应随仓库转移的团队共享行为”，并且“提交您希望与团队共享的 .cline/ 文件”。全局规则则存在于仓库之外的 ~/.cline/ 和 ~/Documents/Cline/Rules 中。
Kiro 将工作区引导（workspace steering）保存在 .kiro/steering/，与保存在 ~/.kiro/steering/ 的全局引导区分开来，其 Crew 记忆层则位于 ~/.kiro/crew/workspace/memory/ 下。Kiro Web 的学习记忆范围甚至更窄：“只有作为创建任务的用户的您的反馈，才会影响智能体学习的内容。”
这四个工具的共同规则是：存在于仓库中的，得以保留。存在于主目录或账户中的，随人离去。
人们尝试过的方法
更长时间的离职面谈。 这很有用，能记录下离职员工能想到的内容。但它无法捕捉到他们多年前就习以为常、不再关注的几十个微小限制条件。
在最后一天前导出所有内容。 这只能给你一个归档文件，而不是一个可用的资源。Anthropic 指出，被移除用户的数据会保留在组织导出中，大多数工具也都有某种导出途径。但是，当出现问题时，没有人会去查询一个包含对话记录的 zip 压缩包。
要求他们共享自己的项目。 这是正确的，也是文档中推荐的补救措施。但这需要他们在最忙碌的离职两周内，去预测下个季度别人会需要他们的哪些私有项目。
“以防万一”保持账户开启。 这种做法很常见且成本高昂，而且通常会产生一个无人管理的登录账号，任何离职清单都无法覆盖它。
临时重新添加他们。 这在 Claude 中确实有效：“如果团队成员被移除，稍后使用相同的电子邮件地址重新添加到同一个组织中，之前的聊天、项目和技能将会恢复。”这确实是紧急情况下的恢复途径。但它不能算作一个计划，而且向一个已经在其他地方开始新工作的人提出这种要求也很奇怪。
编写更多文档。 直觉是对的，但目标错了。文档回答的是一整页内容，而问题需要的是一个具体的答案。两者之间的差距在如何将项目文档转化为 AI 记忆中有所讨论。
解决方案：在人员尚未离职时，将共享知识写入共享空间
改变一下思路，这个问题就会变得易于解决：你不需要在某人离职后去恢复他们的上下文。你需要确保本就属于组织的那部分内容，从一开始就保存在属于组织的地方。
这种区分还能让你尊重合理的界限。离职同事的个人记忆、私有项目和未共享的技能属于他们自己——Anthropic 明确表示，未共享的技能“保留在他们的账户中并可恢复”，且所有者无法读取个人记忆。这些都不应该是你的目标。你真正想要的是团队的知识：决策、限制条件、原因，以及那些属于项目本身而非个人的事实。
这就是 MemoryLake 的作用：一个由工作区（而不是个人账户）拥有的、供你的工具查询的共享记忆层。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并为工作区创建 API 密钥。该凭据属于团队，因此不会随个人离职而失效。
步骤 2：上传你的第一批记忆
简短的条目，每条记录一个事实。最有价值的做法是与某人坐下来，写下只有他们知道的事情。需要捕捉的内容包括：
附带原因的决策。 “我们按租户而不是按区域进行分片，因为第一季度的合规审查排除了跨区域复制。”决策体现在代码中，而原因只在某个人的脑海里。
在此已被否决的方法。 这是最容易被反复争论的类别，而且它不会出现在任何文档或提交信息中。
没有任何提示的环境事实。 必须在另一个任务之前运行的任务。无人记录的供应商限制。只在 CI 中失败的测试。
用通俗语言解释的人和事。 哪个团队负责维护那个容易出错的模块。那个奇怪的临时解决方案是为哪个客户准备的。那个服务的内部名称到底指的是什么。
起关键支撑作用的临时解决方案。 每个团队都有两三个这样的方案。在维护它们的人离职之前，它们是隐形的。
步骤 3：连接你的 AI 和智能体
连接你团队使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此支持 MCP 的原生智能体（包括 Claude Code、Cursor、Cline、Codex 和 OpenClaw 等）可以通过指向 MCP 服务器进行连接，而其他助手则可以通过 API 读取相同的记忆。这意味着新员工在第一周就能获得与离职员工相同的答案，而无需任何人访问离职员工的账户。这种跨工具的形式是知识工作者的跨工具记忆的主题。
三个坦诚的限制。MemoryLake 无法读取、恢复或导入任何人在厂商侧的记忆、聊天记录或私有项目——这些内容存在于每个厂商的产品中，受其访问控制保护，理应如此。它只保存你或你的智能体放入其中的内容，因此步骤 2 需要人工刻意去完成。此外，它不是一个离职合规工具：如果你需要离职员工活动的正式记录，那是你保留政策下的管理员导出，而不是记忆层。
这在实践中带来了什么改变
离职交接不再是一场知识榨取。 知识已经记录在团队拥有的某个地方了。
电脑被格式化不再重要。 机器本地的自动记忆从来都不是唯一的副本。
“我们为什么要这样做？”有了答案。 任何人提问都能得到解答，而不需要知道该去问谁。
新员工入职培训时间真正缩短了。 新人可以直接查询同一个记忆层，而不需要去打扰四个人。
默认私有不再是地雷。 你不需要依赖某人在最后一周还记得去修改权限。
厂商记忆保持个人化，这很好。 你不再需要它成为组织层面的记忆——这正是持久记忆的真正含义中的普遍区别。
在成员离职时保留上下文的最佳实践
对你的技术栈中的界限进行一次审计。 针对每个工具，明确哪些内容在仓库中，哪些在主目录或账户中。这只需要花一个小时，却能理清所有问题。
将项目默认可见性设置为组织。 私有应该是一个有原因的刻意决定，而不是在没有人选择时的默认状态。
让“保存到工作区”成为习惯，而不是救急手段。 Cursor 计划默认保存在主目录中。许多其他工具也是如此。
提交共享层。 .cursor/rules、.cline/、.kiro/steering/、./CLAUDE.md——所有这些在设计上都是存在于仓库中的。请以这种方式使用它们。
写下原因，而不仅仅是规则。 规则可以在版本控制中保留下来。但它存在的原因通常无法保留，而这正是防止规则在明年被推翻的关键。
在离职通知期开始时进行知识交接，而不是在结束时。 离职的最后一周应该用来处理行政事务。
询问他们已经习以为常的事情。 问“你知道哪些没有写在任何地方的事情？”通常只会得到一个耸肩。而问“你必须向最近入职的新人解释什么？”则能得到一个清单。
尊重属于他们的东西。 个人记忆、未共享的技能和私有项目属于个人。请他们共享团队需要的内容，但不要将他们的账户视为资产。
结论
成员离职导致大量上下文丢失的原因不是删除，而是访问权限。账户被移除的瞬间，聊天记录即变得无法访问——Anthropic 直接指出了这一点，甚至记录了人们会看到的错误提示。私有项目仍保持私有，文档中给出的补救措施需要离职人员自己修改权限。个人记忆保持个人化，所有者明确无法读取。Claude Code 的自动记忆是机器本地的，无法在笔记本电脑格式化后幸存。Cursor 计划默认保存在主目录中。Kiro 的 Crew 记忆位于用户的主路径下。Kiro Web 仅从任务创建者自己的反馈中学习。
其中每一个都是合理的合理设计，有几个甚至是你不希望被移除的隐私保护措施。但它们共同指向同一个事实：团队上下文中存在于代码仓库中的部分在成员离职后得以保留，而存在于账户或笔记本电脑中的部分则无法保留。
因此，请有意识地进行划分。审计你使用的每个工具中的界限，将项目默认设置为组织可见，提交共享层，并将决策、原因和被否决的方法放入工作区拥有的记忆层中。在人员尚未离职时就着手去做——不是因为有人要走，而是因为只有在这个时候做起来才最容易。