如何在不丢失上下文的情况下从 Warp 迁移到 Claude Code (2026)

项目规则（Project Rules）几乎可以无缝迁移。 Warp 的项目规则存在于仓库根目录或子目录中的“AGENTS.md 文件（或为了向后兼容的 WARP.md）”中。Claude Code 以相同的格式读取 CLAUDE.md。内容可以原封不动地移动；只有文件名和解析顺序发生了变化。

一个关于文件名的细节经常让人踩坑。 Warp 的文档中有一个明确的警告：“文件名必须全部大写才能被 Warp 识别（例如 AGENTS.md，而不是 agents.md 或 Agents.md）。”Claude Code 寻找的是 CLAUDE.md。如果你复制了该文件却忘记重命名，Warp 会停止读取它，而 Claude Code 也永远不会开始读取。

全局规则（Global Rules）会变成用户指令，但有一个注意事项。 Warp 的全局规则“适用于所有项目和上下文”，并在 Warp Drive Rules 面板中进行管理，每个规则都有一个可选的名称和关于“该规则的作用以及何时应用”的描述。Claude Code 最接近的等价物是 ~/.claude/CLAUDE.md，被描述为“所有项目的个人偏好”。内容可以映射，但元数据不行——因为没有可以保留的单条规则描述字段，所以如果某个 Warp 全局规则依赖其描述来指示何时应用，它就会变成一条无条件的指令。

规则优先级发生了变化。 Warp 按规定的顺序解决冲突：“1. 当前子目录的项目规则文件中的规则 2. 根目录的项目规则文件中的规则 3. 全局规则。”Claude Code 则“按加载顺序，从最宽泛的范围到最具体的范围”加载其四个作用域，“因此项目指令在上下文中会出现在用户指令之后”——依次是托管策略（managed policy）、用户、项目，然后是 CLAUDE.local.md。虽然出发点相同，但机制不同，而且 Claude Code 的文档坦言了其失效模式：“如果两条规则相互矛盾，Claude 可能会随机选择一条。”

子目录加载方式接近但并不完全相同。 Warp 会“自动应用根目录和当前目录中的 AGENTS.md（或 WARP.md）”，对于其他子目录，它会“尽最大努力尝试也包含该子目录的规则文件”。Claude Code 在启动时会加载“工作目录之上目录层级中”的文件，而“子目录中的文件则在 Claude 读取这些目录中的文件时按需加载”。两者对子树的加载都是惰性的，但触发机制不同。

代码库上下文（Codebase Context）无法迁移。 Warp 会“索引你由 Git 跟踪的代码库，以帮助智能体理解你的代码”，并且值得注意的是，“没有代码存储在 Warp 服务器上”。你可以通过忽略文件来调整它，并在 Synced、Discovering files、Failed 或 Codebase too large 下检查其状态。这是一个索引，而不是文档，因此没有什么可以导出的。Claude Code 则是按需读取文件。你失去的是该索引提供的检索质量；你得到的是无需等待同步。

Agent Memory（智能体记忆）是重头戏，而且界限非常明确。 Warp 的 Agent Memory “为 Warp 中的智能体在支持的 harness（包括 Warp Agent、Claude Code 和 Codex）之间提供持久记忆”。它非常真实、成熟，且功能比大多数同类产品更丰富：个人、智能体和团队存储库；新智能体默认开启“自动记忆（Auto-memory）”；对话结束后自动提取，其中“新知识会与现有记忆合并，或在冲突时取而代之”；每个存储库具有只读或读写权限，并配有专属指令；此外还具有可追溯性（“每条记忆都会记录其来源”）和可审计性（“记忆的每次更改都会被记录”）。

有两个事实决定了这些记忆是否能跟随你。首先，它“处于研究预览阶段，并针对设计合作伙伴按团队启用”，且有等待名单——因此大多数读者一开始根本就没有这个功能。其次，这也是让设计合作伙伴感到意外的一点：对第三方 harness 的支持仅适用于“当它们作为云端智能体运行时”，文档明确指出“在研究预览期间，不支持在本地运行第三方 harness”。

因此，如果你拥有 Agent Memory，并且迁移到在本地终端运行的 Claude Code，那么你就脱离了受支持的路径。记忆本身仍保留在原处——“记忆始终与其所有者（用户、智能体或团队）绑定，与读取或写入的 harness 无关”——而 Warp 仍然是保存它的系统。

步骤 1：移动规则并设置范围

首先从文件开始，因为它们是真正可以复制的部分。

将仓库中的每个 AGENTS.md（或 WARP.md）复制，并在相同路径下创建对应的 CLAUDE.md。根目录文件对应根目录 CLAUDE.md，ui/AGENTS.md 对应 ui/CLAUDE.md。内容保持不变。

然后按范围进行拆分，而不是将所有内容都塞进一个文件中。Claude Code 的文档建议“每个 CLAUDE.md 文件控制在 200 行以内”，因为“较长的文件会消耗更多上下文并降低遵循度”。如果你的 Warp 根文件超过了这个长度，现在就是拆分它的好时机——Claude Code 的 .claude/rules/ 目录可以存放主题文件，“所有 .md 文件都会被递归发现”，并且规则可以通过 paths 前置元数据（frontmatter）来限定范围，从而使其“仅在 Claude 处理与指定模式匹配的文件时应用”。

这种映射值得深思熟虑地进行。Warp 的子目录规则文件之所以存在，部分原因在于 Warp 没有其他方法来限定指导范围。在 Claude Code 中，你可以将其保留为嵌套 CLAUDE.md，或者将其转换为按路径限定范围的规则，后者通常更适合诸如“所有 API 处理器必须验证输入”之类的规则。

将全局规则移动到 ~/.claude/CLAUDE.md。对于任何真正属于单个项目的个人偏好，项目根目录下的 CLAUDE.local.md 可以承担这一职责，并且应该将其加入 .gitignore。

最后，要进行验证，而不是凭空假设。在会话中运行 /context，并检查 Memory files 下的列表——这是 Claude Code 官方文档中确认实际加载了哪些内容的方法。上述每个迁移步骤都可能处于一种“表面上成功了一半”的静默状态，而这正是为什么 Claude Code 会遗忘项目上下文这一更普遍现象背后的根源。

步骤 2：决定如何处理没有对应文件的知识

现在来处理无法复制的部分。

如果你之前使用的是 Agent Memory，在停止使用 Warp 之前，先盘点一下这些存储库中的内容。可追溯性在这里很有帮助——每条记忆都会记录其来源——而团队存储库通常是存放有价值材料的地方：部署操作手册、代码审查规范、值班流程。阅读它们并写下仍然重要的内容。目前没有可以将 Warp 存储库转换为 Claude Code 记忆目录的导出路径，因此这是一个阅读和重写的过程，而且需要你手动完成。

Claude Code 有自己的自动层来接收其中的一部分。自动记忆（Auto memory）默认开启，Claude 会写入四种类型的笔记，并用 type 字段进行标记：user 表示“你的角色、专业知识和工作偏好”；feedback 表示“你给 Claude 的纠正以及你确认的方法”；project 表示“正在进行的工作、截止日期以及 Claude 无法从代码或 git 历史中推导出的决策”；reference 表示“在项目之外哪里可以找到信息”。

在依赖它之前，先了解它的结构。它将纯文本文件存储在 ~/.claude/projects/<project>/memory/ 下，并带有一个 MEMORY.md 索引，加载的切片是受限的：“每个会话（前 200 行或 25KB）”。它的范围是“每个仓库，跨工作区（worktree）共享”，派生自 git 仓库。而且 Claude 会刻意避免重复：“Claude 会跳过任何它可以从代码库中推导出的内容”，并且“还会跳过你的 CLAUDE.md 文件中已经写明的内容”。

这两个系统之间的差距不在于质量，而在于拓扑结构。Warp 的存储库是托管的，可以附加到多个智能体上，并且可以通过将存储库附加到整个团队使用的智能体来与团队共享。而 Claude Code 的自动记忆是本地的、基于每个仓库的，且仅属于你个人。从前者迁移到后者意味着团队的共享知识变成了几个人的私有文件——这就是在成员离职时保留团队 AI 上下文中所描述的失效模式。

以上所有内容都是一次性的转换，会让你只剩下本地文件，并失去团队共享层。还有第三种选择，可以让转换工作量更小，结果更持久：将持久的知识保存在一个不属于任何一个工具的存储库中。

这重新定义了迁移。你不需要将 Warp 的记忆翻译成 Claude Code 的记忆，而是将两者都指向同一个层，让特定于工具的文件保持精简且专注于工具本身。这也意味着下一次迁移（肯定还会有的）只是重命名规则文件，而不是一项考古工程。MemoryLake 的设置只需三个步骤。

步骤 1：创建 API 密钥

登录并在你的控制面板中生成一个 API 密钥。该凭据属于你，而不是属于某个 harness，这正是这里的关键属性：Warp 的 Agent Memory 仅在第三方 harness 作为 Warp 云端智能体运行时才覆盖它们，而这可以覆盖你在任何地方运行的 Claude Code，包括本地。

步骤 2：上传你的第一批记忆

这是手动迁移步骤 2 中的材料所去的地方。部署操作手册、审查规范、架构决策及其原因，以及新团队成员需要的领域词汇。任何你从 Warp 团队存储库中读取且不想丢失的内容。

将特定于工具的配置保留在原处。构建命令和文件布局保留在 CLAUDE.md 中；事实信息则移动到这里。

步骤 3：连接你的 AI 和智能体

将 Claude Code 指向该存储库，如果你仍在同时运行两者，也将 Warp 指向它。处于迁移中期的团队通常会同时运行两者一段时间，而这段时期正是共享层发挥作用的最佳时机——这与通用的跨智能体记忆背后的道理相同。

第一个改变是迁移不再是“有损”的。无论如何文件都会被复制；丢失的是那些无法归档到文件中的知识，而这正是共享存储库所保存的部分。

第二个改变是团队知识仍然是团队知识。Warp 通过将存储库附加到整个团队使用的智能体上，使共享变得简单。而 Claude Code 的自动记忆在设计上是基于每个仓库且本地化的。在采用第二个工具时，共享层可以保留前者的属性。

第三个改变是同时运行这两个工具不再是一项维护负担。Warp 的 /init 甚至可以链接现有的外部规则文件——支持的列表包括 CLAUDE.md、.cursorrules、AGENT.md、GEMINI.md、.clinerules、.windsurfrules 和 .github/copilot-instructions.md——因此指令层可以真正统一为一个文件。知识层也需要同样的对待，而这正是 Warp 的项目规则设置自身能够做到和无法做到的事情。

• 重命名，而不仅仅是复制。 AGENTS.md 在 Warp 中必须全部大写；Claude Code 需要 CLAUDE.md。复制但未重命名的文件两者都不会读取。
• 在迁移前进行拆分。 每个 CLAUDE.md 控制在 200 行以内；将限定范围的 Warp 子目录规则转换为 .claude/rules/ 下按 paths 限定范围的条目。
• 使用 /context 进行验证。 检查 Memory files 列表，而不是假设文件已加载。
• 在离开 Warp 之前阅读你的 Warp 存储库。 可追溯性会告诉你每条记忆的来源；没有工具会为你自动导出它们。
• 自动记忆是有选择性的。 它会跳过你的 CLAUDE.md 中已经写明的内容以及它可以从代码中推导出的内容，并且只加载前 200 行或 25KB。
• 避免规则冲突。 Claude Code 可能会在相互冲突的规则之间随机选择，因此请定期审查嵌套文件和规则。
• 对于必须强制执行的内容使用钩子（hook）。 指令是上下文，而不是强制执行；PreToolUse 钩子是文档中记载的彻底阻止某项操作的方法。
• 不要假设 Agent Memory 会跟随你。 它是一个针对设计合作伙伴按团队启用的研究预览功能，而在预览期间，本地第三方 harness 并不在受支持的路径中。

这次迁移中关于文件的那一半工作只是重命名和范围决策，而且 Claude Code 的规则目录在条件性指导方面确实比一堆子目录文件做得更好。

让人头疼的是没有人能导出的那一半。Warp 拥有一个托管的、团队共享的、经过审计的记忆系统；而 Claude Code 则在每个仓库中保存本地 Markdown。在离开前阅读你的存储库，将持久的事实保存在不属于任何一个工具的地方，这样迁移只会花费你一个下午的时间，而不是一个季度的重新学习成本。