Codex 30分钟快速上手推荐：从Cursor和Claude迁移技巧

此前团队主力使用Cursor和Claude Code，但近期被迫做出迁移决定。

导火索是Cursor调整了企业订阅计费模式——个人与企业账户统一转向按量计费。坦白讲，20美元额度撑不到一天，成本涨幅确实离谱。与此同时，Claude Code这边同样棘手：IP地址频繁切换，账号屡次被封禁，团队被折腾得焦头烂额。最终我们统一采购了Codex。本文将梳理此前在Cursor和Claude Code上积累的配置习惯，如何高效迁移至Codex，供面临同样困境的团队参考。

Claude Code配置一键迁移

Codex在这方面考虑得很周到——为Claude Code老用户提供了专用迁移通道。

进入设置 → 常规 → 从其它AI应用导入工作内容，点击导入后，系统会自动将Claude Code中的skill、插件、agent.md以及近30天的对话历史完整迁移过来。至于后续是否会开放Cursor的迁移通道，官方尚未确认，因此Cursor侧的配置目前仍需手动搬运。

Cursor配置迁移全流程

配置全局指令（账号级别）

Codex中的自定义指令与Cursor的rules机制完全对标——用于约束AI在每次交互中必须遵循的规则集合。规则可覆盖项目规范，也可精准到特定技术栈的执行标准。

在设置 → 个性化 → 自定义指令中即可配置你希望Codex遵循的个性化规则。以下是我个人的配置示例供参考：

### 1. 编码前先确认不要私自假设。先说明假设、权衡和不确定点；有争议时由我决策。如果我要求先讨论方案，不要修改代码，直到方案确认无疑问后再开始实现。### 2. 最小改动只用解决问题所需的最少代码。不添加投机性功能，不为单次使用建立抽象。只改必须改的地方，不顺手优化、重构或改动无关代码，保持现有风格。### 3. 分步执行复杂任务先确认技术方案，再按步骤执行；每完成一步先汇报并等待确认后继续。简单任务可自主迭代，直到验证通过。### 4. 优先参考现有实现实现前先找现有业务或模块作为参考，尽量复用已有模式；不明确时先问我。

该指令会在每次Codex会话启动时自动注入上下文。不建议在此文件中堆砌过多规则——指令冗余反而会稀释执行效果。建议仅存放跨项目通用且必须强制执行的核心约束。

需要说明，该操作本质上等同于修改~/.codex/AGENTS.md——路径表述不同，但指向的是同一个底层文件。

配置项目级指令

项目级指令仅在对应项目上下文中自动注入。Codex的实现方式与Claude Code一致——在项目根目录创建AGENTS.md文件即可生效。例如，要求Codex在修改该项目时强制遵循特定技术规范，可将规则写入此文件。

我们的notta项目采用monorepo架构，因此在根目录下仅放置一个AGENT.md并不合理。更优方案是在各个子项目中分别维护独立的指令文件。

配置项目级Skills

Skills本质上是供AI读取的标准化操作流程文档——凡是重复性高、预期结果明确的场景，均可封装为Skill。具体编写方式此处不再赘述，最快捷的途径是使用系统内置的skill creator让AI辅助生成。

迁移Cursor的skills极为简单。原文件存储在.cursor/skills目录下，只需将.cursor重命名为.agents，skills目录内的所有内容无需任何调整。修改完成后重启Codex即可生效。

配置个人级Skills

与指令机制相同，Skills同样支持个人（账号）级别配置。该类Skill可在任意项目中全局调用，存储路径如下：

// 个人级别~/.codex/skills/notta-figma~/.codex/skills/notta-i18n~/.codex/skills/notta-spec// 项目级别.agents/skills/notta-figma/SKILL.md.agents/skills/notta-i18n/SKILL.md.agents/skills/notta-less-guard/SKILL.md

配置MCP服务

打个直观的比方：将Codex视为一个内置大模型的AI黑箱，MCP的作用就是为这个黑箱打开一个通信接口，使其能够与外部系统交互。例如读取Google Doc文档内容、拉取Linear上的缺陷信息等。

配置流程并不复杂：进入设置 → MCP服务器，即可添加或编辑MCP服务。有个关键细节——工作目录决定了MCP的生效范围。若填写Codex根路径，则作用于个人级别；若需对特定项目生效，必须指定对应项目的路径。

开启记忆功能（Memories）

Codex同样内置了记忆功能，与Cursor和Claude Code的实现方式保持一致。在设置 → 个性化 → 记忆 → 启动记忆中开启即可。开启后，Codex会在日常对话中自动识别并存储关键信息。记忆属于账号级别，支持跨项目、跨对话生效。

可以将其理解为一个外挂的RAG记忆系统。举例来说：若AI在某个话题上曾出现过严重错误，正常情况下AI会自行记录该失误。下次遇到相同话题时，它会自动调取这段记忆，从而规避重复踩坑。

若需迁移Cursor中的记忆数据，最直接的方式是：让Codex直接读取Cursor的记忆文件，并将其写入自身的记忆存储中。通常情况下无需手动干预记忆文件，它们存储在~/.codex/memories目录下。

安装与使用Codex插件

插件是Skill、MCP与规则的整合包。以Linear插件为例，它内置了访问Linear的MCP连接，同时预置了若干处理Linear的Skill和指令。前端开发场景下，若希望AI读取Figma设计稿，常规做法是单独配置Figma的MCP。但更高效的方式是直接安装Codex的Figma插件——MCP及相关Skill一次性到位，大幅节省配置时间。

在Codex界面左上角找到插件入口，浏览并安装所需插件即可。

Codex进阶实用技巧

授予Codex更高操作权限

默认状态下，Codex采用常规权限模式。项目的常规操作、代码读取与修改均不受限。但涉及删除或超权限操作时，AI会先征求你的确认。若你希望它全自动执行、免去确认环节，可开启完全访问权限——不过通常不推荐这样做，一旦误删了不明确的文件，后果会比较棘手。

配置项目快捷命令

Codex右上角提供了一项实用功能——可将项目中频繁使用的终端命令配置为快捷按钮。例如快速启动本地服务，只需设置标题与对应命令，后续点击即可让Codex唤醒终端并自动执行，操作极为便捷。

使用Codex内置浏览器

项目启动后，按command + shift + b即可唤起内置浏览器，手动输入地址便能在Codex内部直接访问项目。智能之处在于——若本地服务已正常运行，浏览器区域会自动呈现项目列表，点击即可跳转访问。

更强大的是，开启注释模式后，你可以直接选取页面上的任意DOM元素，输入指令与AI即时交互。对于UI类缺陷修复和问题排查而言，这一功能极具实战价值——AI能直接获取DOM结构与文本信息，代码定位的精准度显著提升。

利用Worktree隔离代码作用域，并行处理多任务

常规操作是：手头有几件互不关联的事项时，可在同一项目中开启多个对话框分别处理。这种方式相当于同时调动多个工作线程。但痛点在于——多个对话框之间的代码修改会相互干扰，代码审查与变更追踪变得十分混乱。

Worktree恰好击中了这个痛点。它基于某个代码分支创建多个完全隔离的独立副本。每个副本的初始状态完全一致，但后续修改互不干扰、互不可见。任务完成后，可将各副本的变更依次合并至目标分支（当然，代码冲突仍需手动处理）。

操作路径如下：新建对话框，选择"新工作树"，指定所需的起始分支即可。系统会在代码区生成一个独立副本，完全不影响主分支的正常工作。所有变更均限定在工作树范围内。

简单概括——多对话框隔离的是对话上下文，而Worktree隔离的是代码工作区。

主目录：/Users/echo/code/notta_monorepo工作树 A：/Users/echo/.codex/worktrees/.../notta_monorepo-xxx

配置SubAgent子代理

SubAgent是应对对话上下文膨胀的经典方案。举个例子：你希望AI同时修复三个缺陷，但如果全部塞进同一个对话框，三个相互独立的问题会纠缠在一起，上下文迅速膨胀，处理目标也日渐模糊。

更科学的做法是：在主线程中拆解任务，随后调用三个子agent分别处理各自的缺陷。修复完成后，每个子agent将结果汇总回主线程。主线程负责调度与最终汇报，三个缺陷的信息完全隔离，彼此独立完成。

Codex同时支持项目级与个人级的SubAgent配置，示例如下：

// 项目级别.codex/agents/code-mapper.toml// 个人级别~/.codex/agents/code-mapper.toml

需注意一个关键区别：前面配置Skills时需要在项目根目录创建.agents目录，而SubAgent则需在项目根目录创建.codex目录，再在其下建立agents子目录。创建SubAgent的最简方式同样是通过AI自动生成。

有一点必须强调：SubAgent不会像Skill那样按需自动触发，你需要显式指示AI去调用它。

举例而言，你配置了产品经理、开发工程师、设计师、测试工程师四个子agent，然后定义一个名为notta-feature-development的skill，在其中明确各阶段应调用的子agent：

当用户说"按完整研发流程做这个需求"或显式调用 `$notta-feature-development` 时：1. 先调用 product subagent 梳理需求边界2. 再调用 design subagent 检查 UI/交互方案3. 再调用 developer subagent 做实现影响分析4. 最后调用 qa subagent 产出测试范围5. 主 agent 汇总结论并等待用户确认

启动该Skill后，AI便能清晰识别：在这个需求开发流程中，各环节应当调用哪个子agent。

使用引导功能，在不中断对话的前提下补充信息

这是开发中极为常见的场景：你向AI下达了任务，AI执行到中途时你发现了偏差，希望及时纠偏。此时无需中断对话，只需补充你希望传达的信息，发送后点击引导即可。

这样做的好处在于——AI的对话流不会被中断，它能够将你补充的信息实时整合进上下文，并据此调整自身行为。

通过/side（侧边对话）基于当前上下文发起子对话

/side对话与Claude Code中的/btw属于同一概念。你在当前对话的基础上临时想到一个额外话题想深入探讨，又不想打断主对话——此时使用侧边对话，即可基于当前对话的上下文创建一个副本，独立展开讨论。

与Guided（引导）的核心区别在于：引导是在主对话中对AI进行实时的信息补充或错误修正；而侧边对话更像是"哎，顺便问一句……"那种即兴探索。

通过/goal目标驱动模式让Codex自主完成长链路任务

/goal是一种目标驱动的执行能力：你向AI设定一个最终目标，它会持续尝试、验证、再尝试，直到达成目标为止。整个过程中它不会主动中断。

启用该功能需要先修改配置文件：在~/.codex/config.toml中添加goals = true。这一步直接让AI帮你完成修改即可。

不过我个人对此模式持保留态度。如果是个人项目，设定目标后静待结果确实省心。但面对正式的生产需求开发，过程中往往存在需求变更或不确定因素。因此我更倾向于使用spec模式来驱动生产级需求——说到底，AI无法承担最终责任，能对结果负责的始终是我们人类自己。