Claude Code 跨会话协作该保存哪些上下文

Claude Code 花一小时查清的认证问题，换个会话又要解释一遍，未必是模型的记忆出了同一种故障。原文的核心判断是：继续对话、项目规则、任务进度和团队决策，需要放在不同地方，单靠保存聊天记录补不齐。

这套思路对经常让 AI 接手分支、跨工具继续开发的程序员很有用。它没有提供提升效率的对照实验，但给出了一套可执行的上下文分工，以及一个很直接的验收办法：关掉旧对话，新会话还能不能解释当前工作和约束。

找回对话，不等于保存了项目知识

原文从一个认证故障切入：作者设定的场景里，Claude Code 查出移动端重试方式不同，因此 token refresh 必须保留独立路径；代码改了两个文件，局部测试通过，还有一个集成测试留待处理。

下一次打开仓库，代码还在，排除过的方向、保留独立路径的原因、未通过的测试却未必在。这实际上包含四类断点：旧对话没有恢复，稳定规则只留在聊天里，未完成工作没有交接，团队决策缺少当前有效的共享记录。

如果只是接着同一段工作做，恢复会话最省事。按原文说明，claude --continue 会恢复当前目录最近的交互会话，claude --resume 打开选择器。可以先用 /rename auth-refresh-debug 命名，再用 claude --resume auth-refresh-debug 找回。恢复内容包括对话、工具调用和结果，比人工摘要更完整。

但它有边界：CLI、desktop app、web app 和 VS Code extension 的历史彼此不同，会话保存在本地，体积也可能很大。隔了很久恢复时，拿到的可能已经是压缩摘要；启动参数也不一定恢复，例如依赖 --plugin-dir 的会话，需要重新传参或正式安装插件。

同一会话里突然忘事，则可能来自上下文压缩（compaction）。上下文窗口装满后，摘要没保留的信息就退出当前上下文。原文给出的定向压缩命令是 /compact focus on the auth refresh bug, attempted fixes, current failing test, and constraints we must preserve，意图是明确留下故障、尝试过的修复、失败测试和必须保留的约束。

项目根目录的 CLAUDE.md、auto memory 等内容会在压缩后重新加载；仅在对话里说过的要求，以及部分路径限定的上下文，可能被摘要遗漏。可以用 /context 查看窗口占用，用 /memory 检查加载的记忆文件。

恢复会话解决的是接着聊，持久记录解决的是换个上下文还能接着做。

稳定规则和临时进度，为什么要分开放

CLAUDE.md 应当保存每次开工都要重复的内容：构建测试命令、目录约定、不可随意跨越的边界，以及深入资料的入口。

下面这个原文示例，同时记录了怎么测试、什么不能改、决策去哪找：

## Billing service

- Run focused tests with `pnpm test billing`.
- Do not make the event queue the only confirmation path.
- Accepted architecture decisions are indexed in `docs/adr/README.md`.

关键是最后一行：它把详细决策指向专门记录，避免把所有历史塞进启动指令。

原文引用的建议是将 CLAUDE.md 控制在约 200 行以内，文件越长，越占上下文，也越难稳定遵循。路径专属规则放进 .claude/rules/；多工具共用的内容，可以通过 @path 导入 AGENTS.md。不过，CLAUDE.md 是给模型看的指令，并非强制配置。

auto memory 则适合个人使用中的项目经验，例如测试的特殊行为、调试线索和偏好。按原文描述，它默认开启，以 Markdown 保存在本机，不会自动同步到其他机器或云环境，独立子代理也不会自动继承主对话的记忆。应通过 /memory 检查并删除错误记录，不能把架构选择、团队政策或负责人信息只存一份在这里。

临时任务需要另一种文件：交接记录。它回答已完成什么、还剩什么、下一步先做什么、哪些约束必须保留。原文示例很具体：

## Auth refresh handoff

Done:
- traced refresh failures to mobile retry timing
- changed `token-store.ts` and `refresh.ts`
- unit tests pass

Next:
- fix `auth.integration.test.ts` case 14
- rerun the mobile retry fixture

Do not change:
- separate mobile refresh path; see ADR 0021

Branch: `fix/mobile-refresh`
Last good command: `pnpm test auth --filter refresh`

要看的是 Do not change：交接不只列待办，还把约束连接到 ADR 0021，避免下一次修测试时顺手破坏既定设计。

这类记录可以放在 .handoffs/current.md，需要别人、另一台机器或另一种工具继续时，随分支提交。任务结束后删除，防止过期的下一步继续指挥模型。

插件负责方法，共享系统负责当前事实

原文对 memory plugin 的判断很清楚：插件首先解决分发问题。

Claude Code plugin 可以打包 skills、agents、hooks、MCP server configuration。例如，/handoff skill 统一交接格式，hook 提醒 PR 前运行测试，受限工具的 review agent 执行审查，MCP 配置连接内部系统。对应文件可以是 skills/handoff/SKILL.md、hooks/ 和 .mcp.json。

这些能力定义怎么做，频繁变化的团队状态应放在它读取的系统里。否则，插件一旦带着旧状态分发，大家就会稳定地获得过时信息。

MCP 适合按需获取跨人员、跨仓库、在代码之外变化的信息，例如工单、部署状态和文档。但连接成功，不代表结果能够直接采信。检索可能同时找到旧提案和替代方案，模型若不知道状态，就可能把两者当成同等有效的依据。

因此，团队决策需要专门记录。单仓库可以使用 ADR（架构决策记录），保存选择及适用范围、理由和约束、负责人、当前状态，以及替代记录入口。状态包括 proposed、accepted、deprecated、superseded，分别对应提议、接受、弃用和被替代。

检索到一条记录，只能证明它存在，不能证明它现在仍然有效。

原文最后介绍了作者推广的 Lockstep：负责人审批从 Slack、文档、工单和 PR 捕获的决策，Claude Code 写代码前通过 get_product_context 获取相关内容，PR 检查提示潜在冲突；默认警告，主动选择后才阻断。这是其产品方案的描述，原文没有给出准确率或对照结果。

我的判断

我赞同把上下文按用途、变化速度和共享范围拆开。尤其是区分「当时讨论过什么」与「团队最终接受了什么」，比继续堆聊天摘要更有价值。

不过，这是一套工作流建议，原文没有展示遗忘率下降多少、返工减少多少，也没有比较不同记录方案的维护成本。开头的认证问题是说明场景，不能当作效果实验。

对单仓库的小团队，CLAUDE.md、分支交接和 docs/adr/ 可能已经够用。它们能随代码审查、版本追踪，代价是需要持续更新。跨仓库、跨产品团队时，共享决策系统更有吸引力，但仍要解决审批、权限、状态更新和旧记录退出的问题。原文没有充分说明这些维护成本。

另一个边界是执行可靠性。既然 CLAUDE.md 只是指令，「PR 前跑测试」就不能仅靠它保证。常见替代做法是把可自动验证的要求交给 CI，把模型需要理解的原因和约束留在文档中。

能拿来做什么

• 给经常重复解释的仓库要求找固定位置。把 Node 项目的构建命令、局部测试命令和目录约定写进简短的 CLAUDE.md，路径专属规则放进 .claude/rules/，详细决策留链接。
• 暂停一个尚未完成的修复前，留下可执行的交接。写明改过的文件、失败用例、下一条命令和不可破坏的约束，需要跨人或跨机器继续时随分支提交。
• 为会改变后续实现方向的选择建立决策记录。特别是认证流程、队列职责这类约束，要写清状态和适用范围；方案被替代时同步更新，避免模型继续引用旧结论。
• 用新会话验收上下文是否完整。让它回答分支在完成什么、哪个测试还失败、移动端刷新路径为何独立、依据哪条决策；修改决策后再问一次，检查它是否仍依赖旧对话。