实际可以迁移的内容
任何 Devin 从您的仓库中学习到的内容都不需要迁移。 这是首先需要明确的一点，因为这能极大地减少工作量。Devin 的文档指出，它会自动从现有的 README 以及所连接仓库的文件结构和内容中生成 Knowledge，并且会从包括 CLAUDE.md 和 AGENTS.md 在内的智能体指令文件中拉取并更新 Knowledge。如果某条 Knowledge 笔记只是对 README 的重述，那么它已经存在于 Claude Code 将要读取的仓库中了。
您直接输入到 Devin 中的内容才是不可替代的部分。 那些不存在于其他任何地方的笔记——部署顺序、专有工具的怪癖、某个目录被禁止访问的原因——都保存在 Cognition 的 Web 应用中。Devin 的文档将 Knowledge 描述为“Devin 可以在所有会话中参考的指令和建议集合”，并记录了如何创建、触发和置顶它。但它没有记录如何导出，也没有任何绕过的导出方法。阅读并手动复制是唯一的途径。
触发器与文本同样重要。 这是大多数人会遗漏的部分。Devin 的检索是有条件的：“Knowledge 是根据您设置的触发器（Trigger）进行检索的。触发器越具体（例如该 Knowledge 适用于哪个文件、仓库或任务类型），检索效果就越好。”一条笔记加上它的触发器就是一个有范围限制的规则。没有触发器的笔记只是一句话，您要么会把它加载到每个会话中，要么会完全遗忘。在收集时，请务必将这两列内容一并收集。
置顶（Pinning）也是范围信息。 您可以将 Knowledge 笔记置顶到所有仓库或某个特定仓库。这直接映射到 Claude Code 的记忆层级结构中，因此请在记录时顺便写下——置顶到所有地方的笔记会变成个人或组织级别的指令，而置顶到单个仓库的笔记则会变成该仓库提交的指令。
Claude Code 在另一端为您提供的内容。 CLAUDE.md 文件会在每个会话开始时加载，解析顺序从宽泛到具体：组织管理的文件，然后是用于您个人偏好的 ~/.claude/CLAUDE.md，接着是为您的团队提交的项目 ./CLAUDE.md 或 ./.claude/CLAUDE.md，最后是用于私有单项目笔记的 ./CLAUDE.local.md。工作目录之上的文件会在启动时完整加载；子目录中的文件会在 Claude 读取该目录下的文件时加载。对于条件加载，可以使用 .claude/rules/，其中的规则文件可以携带 paths: 前置元数据（frontmatter），并且只有在 Claude 接触到匹配的文件时才会进入上下文——这是 Claude Code 中与 Devin 触发器最接近的结构等价物。
在开始之前，有两点坦诚的说明。 Devin 的 Knowledge 是一个真正发挥作用的真实功能，这次迁移之所以令人烦恼，是因为您正在离开一个好用的东西，而不是在逃离一个坏掉的东西。而且 Claude Code 本身也不是一个记忆系统：其文档明确指出，指令文件是“上下文，而非强制配置”，不保证严格遵守。如果某个规则每次都必须执行，文档建议您使用钩子（hooks），而不是写一句措辞更严厉的话。
手动迁移步骤
步骤 1：在失去访问权限之前收集 Knowledge，并按来源分类
打开您的 Knowledge 列表，将每条笔记复制到一个临时文件中，记录每条笔记的三个要素：文本、触发器以及它被置顶到的范围。请在您的订阅仍然有效时完成此操作。这次迁移中的其他所有步骤都是可重复的，唯独这一步不是。
然后根据笔记的来源，将它们分类到以下三个堆中：
源自仓库。 对 README、目录布局、package.json 中写入的测试命令的重复陈述。删除这些。Claude Code 会读取仓库，并且 /init 会根据它找到的内容生成一个初始的 CLAUDE.md。继续复制它们只会让文件变得冗长，从而降低遵循度。
由您编写，且仍然有效。 部署顺序、需要特定标志的工具、本季度任何人都不应该重构的模块及其原因。这些是需要迁移的内容。
由您编写，但已不再有效。 每个 Knowledge 集合中都有这些内容——例如已退役服务的笔记、已修复 Bug 的临时解决方案。在指令文件中留下一条过时的规则比丢失它更糟糕，因为 Claude 会遵守它。现在就果断删除它们，趁您还记得哪些是哪些。
在此过程中，有一个有用的线索：Devin 会话会显示它们访问了哪些 Knowledge。因此，最近的会话可以告诉您哪些笔记在实践中真正被触发了。一个月内未被检索过的笔记要么是触发器设置得不好，要么是已经不再相关，无论哪种情况，它都是第三堆的候选对象。
步骤 2：将笔记重构为 CLAUDE.md 和路径范围规则
现在，根据您记录的范围放置保留下来的笔记，不要把它们全部放在一个文件中：
- 置顶到所有仓库，个人 →
~/.claude/CLAUDE.md。您的习惯、您偏好的工作流。保持简短；它会加载到您机器上的每个项目中。 - 置顶到所有仓库，团队范围标准 → 每个仓库中的项目
CLAUDE.md，或者如果您的团队集中部署了组织管理策略文件，则使用该文件。 - 置顶到单个仓库 → 该仓库根目录下的
./CLAUDE.md，并提交到版本控制中，这样您的团队成员就可以继承它，而无需重新摸索。 - 在特定文件或特定类型的任务上触发 →
.claude/rules/中的一个文件，其paths:前置元数据与这些文件匹配。这与您的 Devin 触发器所做的事情最接近：paths: ["src/api/**/*.ts"]会在 Claude 在 API 层工作时加载该规则，否则会保持在上下文之外。 - 私有且特定于项目 →
./CLAUDE.local.md，加入 gitignore。
这里有两个技术细节可以减少痛苦。Claude Code 的文档建议每个 CLAUDE.md 的行数控制在 200 行以内，因为更长的文件会消耗更多上下文，并降低指令被一致遵循的概率——因此步骤 1 中的分类整理不仅仅是为了整洁，而是为了让最终效果更好。如果您的仓库中已经有一个 Devin 之前读取的 AGENTS.md，请不要重复它：创建一个 CLAUDE.md，通过 @AGENTS.md 导入它，并在下方添加特定于 Claude 的指令，这样两个工具就可以读取同一个源。
最后，请注意您刚刚绕过的这种不对称性。Devin 一直在读取您仓库的智能体文件。当您在启用新的交互式流程的情况下运行 /init 时，Claude Code 可以从 Devin Desktop 设置中读取 .devin/rules/ 文件，并且 /import 可以导入受支持智能体的配置。但没有任何工具可以读取仅存在于 Web 应用中的 Knowledge。这个教训与 Devin 无关——它告诉我们，存储在供应商 UI 中的知识，终有一天需要您手动复制。
更好的方法：统一的记忆层，适用于任何智能体
您刚刚花了一个小时将供应商的知识库转换为文件。这些文件确实是一个真正的改进：版本控制、可评审、可检索、可移植。但是，如果您在下个季度引入 Codex，或者如果团队成员在编写发布说明时希望在 ChatGPT 中使用相同的上下文，想想您必须再次做些什么——您将不得不再次从一个只有单一工具能读取的地方进行复制。
解决方法是将持久性材料保存在每个助手都能读取的统一存储中，并让指令文件专注于它们擅长的事情：编码智能体需要时刻面对的简短、硬性的规则。
MemoryLake 就是为此设计的记忆层——将您规则背后的决策、事件历史和源文档集中保存在一个地方，支持 MCP 的工具（如 Claude 和 Codex）可以直接读取，而 ChatGPT 则可以通过 API 读取。规则留在仓库中，而原因不再保存在单一产品的数据库中。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出您的第一次请求。将其保存在您的环境变量或机密管理器中，而不是直接粘贴到会话中。
步骤 2：上传您的第一批记忆
放入您刚刚迁移的笔记背后的文档、图像和文件：部署顺序所依据的操作手册、导致目录被禁止访问的事件报告、架构决策、您曾经记录过的供应商 API 怪癖。上传源文件，而不是单行版本——单行版本是您刚刚花了一个小时重新构建的内容。
步骤 3：连接您的 AI 和智能体
通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆的权限。Claude Code 可以通过 MCP 直接读取该存储，并与您的 CLAUDE.md 文件协同工作。对于 ChatGPT，通过 API 检索您需要的内容，并将其注入到调用模型的提示词或工作流中。
这在实践中带来了什么改变
第一个区别是原因与规则同行。“在预发布部署之前运行迁移”是一条会被遵守的规则，直到有人觉得它看起来多余。而“在预发布部署之前运行迁移——无序部署在 3 月份导致预发布环境宕机了两次，请参阅报告”则是一条能在新工程师的评判中幸存下来的规则。
第二个区别是您的 CLAUDE.md 可以保持简短。指令文件面临的矛盾在于，所有有用的东西都想塞进那个总是加载的文件中，而总是加载的文件随着体积的增大，效果会变差。有了可用于检索细节的系统，该文件就只需保留硬性约束，别无其他——这也是解决智能体在每个会话中重新读取您的代码库而不是从已知内容开始的方案。
第三个区别是下一次迁移的成本很低。这一次花了他一个小时从 UI 中复制。下一次只需要更改配置，因为知识并不在您要离开的工具内部。
而且它与 Claude Code 现有的功能相辅相成。它的自动记忆（auto memory）会自行不断积累构建命令和调试见解——这非常有用，且是针对每个仓库的。但值得了解其局限性：该存储是机器本地的，其文档指出这些文件不会在机器或云环境之间共享。因此，它是一个很好的本地便利层，但不是一个好的记录系统，而这恰恰是您想要的合理分工。
离开智能体平台的最佳实践
在仍有访问权限时进行收集
Knowledge、记忆和保存的上下文在订阅失效前一直可见，失效后一分钟也看不到。先复制，后整理。这是整个迁移过程中唯一有截止期限的步骤。
记录触发器，而不仅仅是文本
检索条件也是信息。当 Devin 接触支付模块时触发的笔记会变成一个路径范围规则；如果遗忘了该条件，同一条笔记要么会变成每个会话中的噪音，要么会因为不相关而被您删除。请务必复制这两列。
在迁移过程中进行删除
迁移是有人用全新的眼光审视每条规则的唯一时刻。好好利用它。过时的指令比缺失的指令更糟糕，因为智能体会遵守它们，而您可能一个月都注意不到。
将原因放在可检索的地方，将规则放在加载的地方
两行字的规则应该放在 CLAUDE.md 中。而产生该规则的事件报告、RFC 以及供应商讨论贴则应该放在一个存储中，以便智能体在需要解释或重新考虑时拉取。将两者都塞进指令文件中，会导致这些文件膨胀到 800 行并最终不再被遵守。
不要指望任何指令文件能起到强制执行的作用
Claude Code 自己的文档很明确，指令文件是上下文，而不是强制配置，并指出对于每次都必须发生的事情应该使用钩子（hooks）。如果您正在迁移的规则是承重墙级别的——例如绝不直接推送到 main 分支、必须运行 linter——请将其实现为钩子或 CI 检查，并让指令文件解释其存在的原因。
结论
从 Devin 迁移到 Claude Code 是一次单向复制，其原因在于结构设计而非恶意限制：Devin 的 Knowledge 会从您的仓库文件中拉取内容，包括 CLAUDE.md 和 AGENTS.md，但没有任何东西能从 Devin 中拉取出来。任何源自您仓库的内容已经存在于 Claude Code 将要查找的地方。您在 Web 应用中输入的任何内容，加上限定其范围的触发器和置顶，都必须在您仍有访问权限时手动收集。
在进行收集时，另一只手准备好删除键，然后按范围重构：个人偏好放在 ~/.claude/CLAUDE.md，团队标准放在已提交的 CLAUDE.md，特定于文件的规则放在带有 paths: 前置元数据的 .claude/rules/ 中，私有笔记放在 CLAUDE.local.md 中。保持文件简短。然后将这些规则背后的原因放在您助手读取的统一存储中，这样下一次您更换平台时，您只是更换了一个工具，而不是重新挖掘您所知道的一切。