实际上能迁移什么
你的 Skills，完全无需修改。 Cline 的项目技能路径为 .cline/skills/（推荐）、.clinerules/skills/ 和 .claude/skills/。第三条路径意味着你一直在与 Claude Code 一起使用的仓库已经满足了 Cline 的要求。全局技能存放在 ~/.cline/skills/。一个与你习惯相反的优先级注意事项：“当全局技能和项目技能同名时，全局技能优先。” Cline 还建议将 SKILL.md 保持在 5k token 以下，并将溢出的内容拆分到 docs/ 目录中，它“仅在需要时加载引用的文件”。
你的指令内容，只要放入 Cline 读取的文件中即可。 两种整洁的形式。重命名为项目根目录下的 AGENTS.md，Cline 将其视为“跨工具兼容的标准格式”。或者将其拆分到 .clinerules/ 中——Cline 会“处理 .clinerules/ 内的所有 .md 和 .txt 文件，并将它们合并为一套统一的规则”，还可以使用类似 01-coding.md 的数字前缀进行排序。
你的个人层，移至不同的归宿。 Claude Code 的用户指令存放在 ~/.claude/CLAUDE.md，被描述为“所有项目的个人偏好”。Cline 的全局规则目录在 macOS 和 Linux/WSL 上是 ~/Documents/Cline/Rules，在 Windows 上是 Documents\Cline\Rules。它还会从 ~/.agents/AGENTS.md 读取跨工具的全局指令。注意这个位置：是 Documents，而不是点文件（dotfile）——在去 ~/.cline/ 寻找之前，这一点很值得了解。
其他内容都无法干净地迁移，且有三件事的表现有所不同。
你的自动记忆（auto memory）没有去处。 这是真正的差距所在。Claude Code 会在 ~/.claude/projects/<project>/memory/ 中为自己写笔记——共有四种类型，在 frontmatter 中标记为 user、feedback、project 和 reference——并且默认开启。Cline 没有等效的自动存储。对于希望直接复制文件夹的人来说更糟糕的是：Claude Code 的文档指出“自动记忆是机器本地的”且“文件不会跨机器或云环境共享”。这些文件也刻意保留了你的指令文件没有提及的内容，因为 Claude 会“跳过任何它可以从代码库中推导出的内容”并“跳过你的 CLAUDE.md 文件中已经说明的任何内容”。这意味着记忆目录中保存的恰恰是不会出现在你重命名的文件中的内容。
优先级和合并方式不同。 Claude Code 会进行拼接：托管策略，然后是用户指令，接着是项目指令，并注明“如果两条规则相互矛盾，Claude 可能会任意选择一条”。Cline 也会进行合并，但会解决冲突：“当工作区规则和全局规则同时存在时，Cline 会将它们合并。当工作区规则与全局规则冲突时，工作区规则优先。” 因此，在 Claude Code 中暗中与你的项目文件冲突的个人偏好，现在将确定无疑地失效。
路径范围规则变成了开关。 Claude Code 拥有带有 paths: frontmatter 通配符字段的 .claude/rules/ 文件，仅针对匹配的文件加载。Cline 的等效控制是手动而非自动的：“每条规则都有一个启用或禁用的开关，” Cline 自己的例子是“在进行原型设计时你想要禁用的严格测试规则，或者仅在开发特定客户的功能时才需要的客户特定规则”。目标相同，触发方式不同——由你手动切换，而不是通过通配符自动执行。
手动迁移
步骤 1：在动指令文件之前，先读取你的自动记忆
先做这一步，因为这是迁移中唯一无法稍后从仓库中恢复的部分。
在 Claude Code 中运行 /memory 来浏览记忆目录，或者直接打开 ~/.claude/projects/<project>/memory/。它包含一个 MEMORY.md 索引以及每个主题一个文件。阅读时需要了解两点：在会话开始时，只有“MEMORY.md 的前 200 行，或前 25KB（以先到者为准）”会被加载，而主题文件是“按需读取”而不是直接加载的——因此里面的内容可能比 Claude 平常使用的要多。
然后运行 /context 并检查 Memory files 下的列表。这是实际加载内容的权威记录，它会告诉你即将重命名的 CLAUDE.md 是否是唯一的文件——子目录中的文件是按需加载的，且导入解析的“最大深度为四跳”，因此 monorepo（单体仓库）中实际起作用的文件可能比根目录文件所显示的要多。
复制出你想要保留的内容。这不是文件移动，而是一次阅读练习。feedback 和 project 条目通常是最有价值的，因为按照设计，它们包含了你给出的修正以及无法从代码中推导出的决策。
步骤 2：落实指令，然后决定是否使用 Memory Bank
首先落实指令，并选择一种形式。 如果 Cline 现在是该仓库上唯一的智能体，请将 CLAUDE.md 重命名为 AGENTS.md。如果团队成员仍在使用 Claude Code，请保留 CLAUDE.md 并添加 AGENTS.md——但选择其中一个作为权威版本，并保持另一个精简，因为两个完整的副本会产生偏差。拆分到 .clinerules/ 是更好的选择：带有开关的独立文件比没人想编辑的单个大文件要好得多。这一决定的文件格式部分在如何将你的 CLAUDE.md 迁移到 AGENTS.md中单独进行了介绍。
既然你已经到了这一步，请删除 Claude Code 指南已经告诉你要删减的部分。它的建议是“目标在 200 行以内”，因为“较长的文件会消耗更多上下文并降低遵循度”，同样的逻辑也适用于 Cline 加载的任何内容。
然后是 Memory Bank，这是人们常常跳过的部分。 Cline 对跨会话上下文的解决方案是一种你需要安装的方法论，而不是一个你直接启用的功能。设置分为三个步骤：复制 Cline 的自定义指令，“将它们添加到 Cline 规则文件中，例如 .clinerules/memory-bank.md”，然后让 Cline “初始化 memory bank”。
它会在仓库中创建六个 markdown 文件——projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md 和 progress.md——其中 activeContext.md 是“更新最频繁”的文件。驱动它的是三个短语：“initialize memory bank”（初始化 memory bank）、“update memory bank”（更新 memory bank）以及“follow your custom instructions”（遵循你的自定义指令）以恢复。
阅读 Cline 自己对原因的阐述，因为它对这种权衡的解释异常直接：“我是 Cline，一名优秀的软件工程师，我有一个独特的特征：我的记忆在会话之间会完全重置。这不是一个限制——正是这一点促使我保持完美的文档记录。”
这就是这次迁移的真实面貌。Claude Code 的记忆是自动且机器本地的。Cline 的记忆则是手动的，且保存在你的仓库中。你获得了一些你永远无法从 ~/.claude/projects/ 中得到的东西——团队成员可以阅读它、审查它，而且换了新电脑它依然存在。你放弃了那些在你不知情下自动发生的部分。
一个工作流注意事项：/newtask 是最接近交接原语的功能，被描述为工作起来“就像开发人员交接一样。它将重要的内容（总体计划、已完成的工作、相关文件、后续步骤）打包到一个具有干净上下文窗口的新任务中”。/smol（别名 /compact）则是在原地进行压缩。如果你希望将状态记录下来而不是仅仅进行总结，请在执行这两者之前使用 update memory bank。
更好的方法：不要再让你的记忆成为编辑器的属性
看看这次迁移实际上包含了什么。一个文件被重命名了。一个文件夹已经放对了地方。唯一不可逆的步骤是读取一个工具在单台机器上以仅该工具使用的格式编写的笔记目录。
这不是 Claude Code 的失败，也不是 Cline 的失败。当持久知识存在于产生它的任何智能体内部时，就会发生这种情况。Claude Code 的自动记忆明确是机器本地的。Cline 的 Memory Bank 明确是一种你需要手动维护的文档实践。两者都是合理的设计；但两者都不是你存放“为什么要做出某个决定”的唯一副本的理想场所。
这正是 MemoryLake 所承载的：将你项目的持久知识保存在一个供工具查询的层中，这样切换编辑器就只是一种偏好选择，而不是一次痛苦的迁移。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建 API 密钥。一个凭证即可跨你连接的所有工具使用。
步骤 2：上传你的第一批记忆
简短的条目，每条只包含一个主张。在步骤 1 中读取的 /memory 记忆犹新时写下这些内容：
feedback（反馈）类别中的所有内容。 你给出的修正和确认的方法。这是在新工具上最容易被重新争议的类别，因为代码库中没有任何内容暗示这一点。
附带原因的决策。 “由于只读副本在负载下存在延迟，迁移只能是渐进式的。”指令规定了规则；只有这样才能阻止替代方案被再次提出。
在此处已经尝试并被拒绝的方法。 指令文件中没有，提交信息中也没有，但每次会话都会被重新提出。
没有任何声明的环境事实。 仅在 CI 中失败的测试、未记录的速率限制、两个任务之间的顺序依赖关系。
步骤 3：连接你的 AI 和智能体
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此支持 MCP 的原生智能体（包括 Claude Code、Cline、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。这意味着在过渡期间，你可以在同一个仓库上同时运行 Cline 和 Claude Code，而无需维护两份相同的推理副本。
三个坦诚的限制。MemoryLake 不会编写你的 AGENTS.md、.clinerules/ 或你的 Memory Bank 文件——这些是你引导每个工具的方式，上述的发现行为属于它们自己。它只保存你或你的智能体放入其中的内容，因此步骤 2 是手动的。此外，指令是上下文而不是强制配置；对于每次都必须遵守的任何内容，请使用每个工具自身的强制执行机制，而不是记忆层。
这在实践中改变了什么
Skills 不再是迁移项。 .claude/skills/ 是 Cline 读取的目录。无需移动。
“哪个文件生效？”有一个简短的答案。 .clinerules/、.cursorrules、.windsurfrules、AGENTS.md——而不是 CLAUDE.md。
冲突得以解决，而不是像抛硬币一样随机。 在 Cline 中，工作区规则优于全局规则。而 Claude Code “可能会任意选择一条”。
长指令文件变成了几个带有开关的短文件。 这也是你在进行后端工作时停止加载前端部分的方法。
你的上下文变得可审查。 Memory Bank 文件保存在仓库中，并会经过 pull request。而 ~/.claude/projects/<project>/memory/ 永远无法做到这一点。
换新电脑不再意味着重置。 自动记忆是机器本地的；而提交的文件则不是。
从 Claude Code 切换到 Cline 的最佳实践
在重命名任何内容之前，先读取 /memory。 它保存了你的 CLAUDE.md 刻意不包含的内容，而且它不会随你一起迁移。
运行 /context 以确认实际加载的内容。 子目录文件和四跳导入意味着根文件很少是全部情况。
选择 AGENTS.md 或 .clinerules/，且只保留一个权威来源。 两个完整的副本在一个 sprint 内就会产生偏差。
在迁移之前进行拆分，而不是在迁移之后。 带有开关的独立 .clinerules/ 文件是开关功能有用的唯一原因。
务必安装 Memory Bank。 它只是一个规则文件加上一个命令，跳过它就是人们得出 Cline 会遗忘事情这一结论的原因——症状方面在为什么 Cline 会遗忘项目上下文中进行了介绍。
在 /newtask 或 /smol 之前更新 memory bank。 压缩并不等同于记录下来。
提交 .cline/ 和你的 Memory Bank。 Cline 自己的指南是使用项目配置“来实现应随仓库一起移动的团队共享行为”。
不要将推理过程放在总是加载的文件中。 这两个工具都会限制它们承载的内容，而推理过程是首当其冲的受害者——普遍问题在为什么智能体会忽略你编写的指令文件中进行了介绍。
结论
从 Claude Code 到 Cline 看起来就像是一次重命名，机械部分确实如此：.claude/skills/ 已经可以工作，而 CLAUDE.md 变成了 AGENTS.md 或一组 .clinerules/ 文件。陷阱在于，Cline 的规则表会自动检测 .cursorrules 和 .windsurfrules，却从未提及 CLAUDE.md，因此你一直依赖的那个文件，正是另一端没有读取器的那个文件名。
真正无法迁移的部分是自动记忆。Claude Code 会在 ~/.claude/projects/<project>/memory/ 中为自己写入自动记忆，分为四个类别，其设计目的是包含你的指令文件没有提及的内容——而且它是机器本地的。Cline 的替代方案是 Memory Bank：仓库中的六个 markdown 文件，通过一个规则文件和一个命令进行初始化，并由你手动维护。这种权衡是值得明智做出的，因为你获得了可审查性，但失去了自动化。
先读取记忆目录，使用 /context 确认加载的内容，将指令落实到一个权威文件中，正确安装 Memory Bank，并将决策和被拒绝的方法放在两个工具都可以查询的地方。这样一来，你今天早上打开了哪个编辑器，就不再是决定你的智能体理解能力的决定性事实了。