实际迁移了什么
Cursor 和 Codex 都能读取 Markdown 指令。这种相似性掩盖了至关重要的区别。
规则内容会逐字迁移。 .mdc 文件的 Markdown 主体只是给模型的指令。文本内容不需要重写。
规则激活方式不会迁移，因为 Codex 没有激活模型。 Cursor 的项目规则以 .mdc 文件的形式保存在 .cursor/rules 中，带有前置元数据（frontmatter）——description、globs、alwaysApply——并在此基础上构建了四种模式：
- Always Apply（总是应用） —— 适用于每个聊天会话
- Apply Intelligently（智能应用） —— 当 Agent 根据描述决定其相关时应用
- Apply to Specific Files（应用到特定文件） —— 当文件匹配指定模式时应用
- Apply Manually（手动应用） —— 在聊天中被 @ 提及时应用
Codex 只有一种机制：AGENTS.md，它从你的 Codex 主目录（~/.codex/AGENTS.md 或 $CODEX_HOME）向下经过仓库根目录和中间目录，一直解析到你的工作目录，自上而下进行合并，且越接近工作目录的文件优先级越高。作用域是文件所处位置的函数，而不是 glob 或描述的函数。这里没有“智能体决定这是否相关”的层级。
这就是一句话总结的整个迁移问题：四种条件模式必须扁平化合并到一种位置机制上。
`AGENTS.md` 直接迁移——而且你可能已经拥有它。 Cursor 支持在项目根目录中使用 AGENTS.md 作为 .cursor/rules 的替代方案，包括子目录中的嵌套文件。如果你的规则已经存在于那里，那么这次迁移的大部分工作都是无操作（no-op），因为这正是 Codex 所期望的结构。
用户规则（User Rules）作为全局文件迁移。 Cursor 的用户规则是在 Customize → Rules 中定义的全局偏好，适用于所有项目。它们在 Codex 中的等效文件是 ~/.codex/AGENTS.md。意图相同，位置不同，除了复制粘贴外不需要任何转换。
MCP 服务器、设置、插件、斜杠命令和最近的会话通过导入器迁移。 /import 覆盖了六个方面：转换为 config.toml 的 settings.json、两种 JSON 方言中的 MCP 服务器、插件、过去 30 天内多达 50 个最近会话、自定义斜杠命令以及项目作用域的记忆。
有些东西无法迁移。 无法导入来自 Cursor 网页界面的聊天记录——只能导入本地会话数据。导入是单向的；你在 Codex 中更改的任何内容都不会流回。此外，记忆的保真度无法保证：引用特定工具功能（如 Cursor 的 composer 历史记录）的记忆无法映射到 Codex 的运行模型上，这就是为什么在导入后花两分钟使用 /memories list 进行检查是值得的。
还有一样东西在两个方向上都无法迁移：规则背后的推理。Cursor 自己的文档直截了当地解释了规则存在的原因——“大型语言模型在补全之间不会保留记忆。规则在提示词级别提供了持久、可重用的上下文。” 规则只是一种权宜之计，而且是只能容纳你想到并写下来的内容的权宜之计。
手动迁移
步骤 1：按激活方式整理你的规则
在运行任何操作之前，打开每个 .mdc 文件并根据前置元数据（frontmatter）对其进行分类，因为激活模式决定了它的去向。
`alwaysApply: true` → 这些规则直接进入与其实际作用域相匹配的 AGENTS.md 层级。如果某个规则对你的工作来说确实是全局性的，它应该放在 ~/.codex/AGENTS.md 中。如果是关于当前仓库的，则放在仓库根目录。直接翻译，无需多虑。
带有 `globs` 的规则 → 这些规则需要的是放置位置，而不是翻译。作用域限定在 src/api/** 的规则会变成 src/api/ 目录下的 AGENTS.md，当你在该目录中工作时，Codex 会自动读取它。这是最划算的转换：处理得当，你就能保留作用域行为；如果偷懒——直接塞进根目录文件中——你就会让一个特定于 API 的规则应用到你的 CSS 上。
如果 glob 无法干净地映射到某个目录（例如散落在目录树各处的 **/*.test.ts），你有两个坦诚的选择：在最近的 AGENTS.md 中用文字说明条件（“在编辑测试文件时，……”），或者接受它现在总是被加载的事实。文字条件比 glob 匹配要弱——模型必须注意到条件适用——因此请将它们用于遗漏代价较低的规则。
使用 Apply Intelligently（智能应用）的规则 → 这些是需要最认真思考的规则。Cursor 在运行时根据 description 决定规则是否相关。Codex 则不会。每一个这样的规则要么变成总是启用（在每次请求中消耗上下文），要么实际上消失。对它们进行分类：重要的放入文件中，可有可无的则丢弃。不要把它们全部迁移到根文件中，这是最常见的失败做法，会产生每个人都后悔的臃肿指令文件。
Apply Manually（手动应用）规则 → 这些是你刻意引入的参考文档。将它们作为文档保留在仓库中——docs/ 目录就很合适——并在 AGENTS.md 中添加一行，告诉智能体在进行此类工作时阅读相关文件。不要将它们内联。
既然你已经到了这一步，在新家也应用 Cursor 自己的大小建议：保持规则在 500 行以内，并将较大的规则拆分为可组合的碎片。这在 Cursor 中是很好的指导，在 Codex 中则是更好的指导，因为在 Codex 中，作用域内的所有内容都会在每个任务中加载。
步骤 2：运行 /import，然后修复无法映射的内容
确保你使用的是 Codex v0.145 或更高版本，在项目根目录中启动一个新的 Codex TUI 会话，然后运行 /import。选择 Cursor 作为源，并选择你想要的类别。请注意，/import 需要本地嵌入式 TUI 会话——它无法在远程会话或任务正在运行时运行。
然后进行导入器无法为你完成的审核步骤：
- 阅读生成的 `AGENTS.md`。 任何围绕 Cursor 特有概念（如 composer 历史记录、@ 提及工作流、Cursor 自己的工具名称）表述的内容都应该重写或删除。否则，它会一直留在那里，指示 Codex 使用不存在的功能。
- 将 glob 作用域的规则放置到步骤 1 所示的子目录
AGENTS.md文件中。导入器只移动内容，它不会从你的前置元数据中推断目录结构。 - 运行 `/memories list` 并检查迁移过来的内容。引用 Cursor 机制的导入记忆充其量只是噪音。
- 验证 MCP 服务器是否真正启动。 两种 JSON 方言都会转换，但转换后的配置仍然是配置——在 Cursor 中需要环境变量的服务器，在 Codex 中同样需要。
然后决定是否启用 Codex 自己的记忆功能，这与指令是两码事。本地 Codex 记忆默认是关闭的。 在桌面应用的“设置 → 个性化”中勾选“启用记忆”，或者在 ~/.codex/config.toml 的 [features] 部分设置 memories = true；在欧洲经济区（EEA）、英国和瑞士，Codex 仅在你启用后才会使用或生成记忆。你可以分别控制这两个部分：
```toml [features] memories = true
[memories] generate_memories = true # 从新会话中提取记忆 use_memories = true # 将记忆注入未来的会话中 ```
启用后，Codex 会在不同线程之间携带稳定的偏好、循环工作流、技术栈、项目规范和已知陷阱，并将摘要、持久条目、最近输入和支持证据存储在 ~/.codex/memories/ 下。
值得开启。但也值得阅读官方的注意事项，因为它们定义了该功能的本质：生成会跳过活跃或短暂的会话，当你的剩余速率限制百分比低于配置的阈值时会暂停，并且在聊天结束时可能不会立即更新；这些文件是生成的系统状态，你不应该手动编辑它们；敏感信息会从生成的记忆字段中脱敏，但文档仍然建议在共享前进行审查。而且该存储是全局而非针对单个项目的，并且是该机器本地的——它不会同步，一个仓库的记忆可能会出现在另一个仓库中。
更好的方法：统一的记忆层，适用于任何编辑器
步骤 1 是一项有趣的工作，请注意这是什么样的工作：将一个工具的激活模型转换为另一个工具'的目录布局。这种努力不会产生任何可重用的成果。换到下一个编辑器时，你还得再做一遍。
还有一类知识在这次迁移中根本不会出现，因为它们从未存在于规则文件中。比如为什么重试逻辑看起来不对但实际上是对的。客户在三月份拒绝了什么。你在周五下午 6 点发现的限制。规则只包含你坐下来决定写下的内容；其余的内容则存在于无法在导出中存活的聊天线程中。
将这一层保持在编辑器之外，正是它能在这两个问题中幸存下来的原因。MemoryLake 是一个供你的工具读取的记忆层——将决策、文档和积累的上下文保存在一个存储库中，Codex 和 Cursor 可以通过 MCP 访问，其他任何工具也可以通过 API 访问。下一次迁移将变成一个配置项，而不是一个转换项目。
客观地对待文件：.cursor/rules 和 AGENTS.md 确实有真正的优势。它们是纯文本，保存在仓库中，在拉取请求（PR）中进行审查，你的团队成员无需任何操作即可继承它们。将它们保留用于常规规则——这是它们所擅长的，而且 Codex 原生支持读取它们。而记忆层则在以下情况发挥作用：内容太长无法每次都加载、太具体不便公开，或者太容易丢失以至于无法指望有人记得写下来。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是配置文件中——配置文件正是像这样的迁移过程中最容易被复制来复制去的东西。
步骤 2：上传你的第一批记忆
放入保存了你的规则从未捕获的上下文的文档、图像和文件：架构决策及其原因、解释奇怪重试的事件报告、客户的限制。尽可能上传源文件而不是摘要。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。Codex 支持 MCP 服务器，并且导入器已经转换了你现有的 MCP 配置，所以这只是多了一个服务器条目。如果你继续使用 Cursor，也可以从 Cursor 中读取相同的存储，并且可以从你针对 API 构建的任何内容中读取。
这在实践中改变了什么
第一个区别是规则迁移不再是有损的。现在你会丢失激活逻辑和未写下来的知识；而在那之后，你只需要转换真正属于文件的部分。
第二个区别是同时运行两个编辑器变得很正常。很多人保留 Cursor 用于编辑，并使用 Codex 进行更长时间的智能体运行。在今天，这意味着要以两种格式维护同一套规范的两份副本，并眼睁睁地看着它们产生偏差。一个供两者读取的统一存储消除了这种重复——这也是为什么通过 MCP 连接共享记忆值得做一次，而不是针对每个工具都做一遍的原因。
第三个区别是机器独立性。Codex 记忆在设计上是本地的，因此即使在完美的迁移之后，第二台笔记本电脑开始时也是空的。记忆层则没有这个限制。
而且你的指令文件会变小，这在 Codex 中比在 Cursor 中更重要：作用域内的所有内容都会在每个任务中加载，因此 Codex 在启动每个会话时没有你的项目上下文是一个你希望通过检索来解决的问题，而不是通过更长的根文件来解决。
切换的最佳实践
按激活模式转换，而不是按文件转换
直觉是逐个文件进行迁移。相反，应该按前置元数据（frontmatter）进行分类——alwaysApply、globs、基于描述的、手动的——因为每种模式都有不同的去向，而其中一种（Apply Intelligently）根本没有去向。逐个文件迁移会导致所有内容最终都堆在根目录的 AGENTS.md 中。
将有作用域的规则放在有作用域的目录中
关于 API 层的规则应该放在 API 目录下的 AGENTS.md 中。这是整个迁移中价值最高的一个习惯：它保留了你原本会丢失的作用域，并保持了根文件的简短。这也意味着新的团队成员可以在代码所在的位置发现该规则。
审查导入结果，而不是盲目信任它
/import 很好，但它不是翻译器。阅读输出，删掉特定于 Cursor 的表述，运行 /memories list，确认 MCP 服务器已启动。在这里花十五分钟可以防止智能体在数月内一直遵循为其他工具编写的指令。
决定哪些规则真正值得“总是启用”
作用域内的所有内容都会在每次请求中永久消耗上下文。在将以前有条件的规则提升为“总是启用”之前，问问自己是否愿意在每一个任务中都为此付费。大多数“Apply Intelligently”规则都无法通过该测试，删掉它们是比带着它们更好的结果。
结论
现在机械部分很简单了：Codex v0.145 通过一条命令即可导入 Cursor 设置、MCP 服务器、插件、会话、斜杠命令以及项目作用域的记忆。需要你进行判断的部分是，Cursor 的四种激活模式会合并为 Codex 的单一位置机制——因此 alwaysApply 规则直接迁移，glob 作用域的规则变成子目录中的 AGENTS.md 文件，描述触发的规则必须刻意提升或丢弃，而手动规则则保留为你指向的文档。
然后是这次迁移从未触及的层，因为它们从未存在于文件中。将这些内容保存在两个编辑器都能读取的存储库中，是迁移规则与迁移知识之间的区别——正是这一点能让下一次切换不再耗费你又一个下午的时间。