在团队协作过程中，我们一直大量使用 Cursor 和 Claude Code 这两款 AI 编程工具。然而近期，团队不得不做出工具切换的决定。
主要原因在于，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 视角完成迁移
3.1 配置账号级别指令（全局指令）
Codex 中的自定义指令，与 Cursor 里的 rules 属于同一类机制——它的作用是告诉 AI，每次问答时必须遵守哪些规则。这些规则可以是项目规范，也可以细化到某项技术的具体要求。
你可以在设置 → 个性化 → 自定义指令里添加你希望 Codex 遵守的个人规则。这里分享一下我的配置作为参考：
### 1. 编码前先确认不要私自假设。先说明假设、权衡和不确定点；有争议时由我决策。如果我要求先讨论方案，不要修改代码，直到方案确认无疑问后再开始实现。### 2. 最小改动只用解决问题所需的最少代码。不添加投机性功能，不为单次使用建立抽象。只改必须改的地方，不顺手优化、重构或改动无关代码，保持现有风格。### 3. 分步执行复杂任务先确认技术方案，再按步骤执行；每完成一步先汇报并等待确认后继续。简单任务可自主迭代，直到验证通过。### 4. 优先参考现有实现实现前先找现有业务或模块作为参考，尽量复用已有模式；不明确时先问我。这段指令在 Codex 会话启动时会自动注入到上下文。通常不建议在这个文件里塞入过多指令——俗话说，指令越多反而等于没有指定。因此这里最好只放置你对所有项目都通用的、必须遵守的核心规则。
另外，这个修改等价于修改~/.codex/AGENTS.md，路径不同，但本质上指向的是同一个文件。
3.2 配置项目级别指令
顾名思义，项目级别的指令只会在对应项目的上下文中自动注入。Codex 的做法和 Claude Code 一致，你只需在项目根目录下新建一个AGENTS.md文件即可。比如你希望 Codex 在修改这个项目时，必须遵守某套技术规范，就将内容写在这个文件里。
我们的 notta 项目是一个 monorepo 仓库，因此不适合在根路径下只放一个 AGENT.md。更合理的做法是在不同的子项目里各自创建自己的指令文件。
3.3 配置项目级别 Skills
可以把 Skills 理解为供 AI 阅读的 SOP 文档——那些重复性高、预期明确的场景，都适合封装成 Skill。具体写法这里不展开，最直接的方式是借助系统自带的skill creator让 AI 帮你创建。
迁移 Cursor 的 skills 非常简单。之前它们都存放在.cursor/skills目录下，现在你只需把.cursor改为.agents，skills 目录里的内容完全不需要变动。改完之后重启 Codex 即可生效。
3.4 个人级别 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.md3.5 配置 MCP
讲一个形象点的类比：如果把 Codex 理解成一个内置大模型的 AI 黑盒，MCP 的作用就是给这个盒子开一个接口，让它能够与外界通信。比如读取 Google Doc 文档、拉取 Linear 上的 bug 信息等。
配置方式并不复杂：进入设置 → MCP 服务器，就可以添加和编辑 MCP 服务。这里有一个小细节——工作目录决定了 MCP 的作用范围。如果填写的是 Codex 根路径，就是个人级别；如果需要对某个特定项目生效，则必须指定项目路径。
3.6 开启记忆 Memories
Codex 同样支持记忆功能，与 Cursor、Claude Code 的做法一致。你可以在设置 → 个性化 → 记忆 → 启动记忆开启它。之后 Codex 会在日常对话中自动提取并记录重要信息。记忆是账号级别的，跨项目、跨对话都能生效。
可以把它理解成一个外置的 RAG 系统。举个例子：AI 在某个话题上曾经犯过错误，但那个错误对你影响很大——正常流程下，AI 自己会记住。下次遇到同样的话题，它就会自动调用这段记忆，避免再次踩坑。
如果你想迁移 Cursor 的记忆，最直接的办法是：让 Codex 直接读取 Cursor 的记忆文件，然后写入它自己的记忆存储中。通常情况下，我们不需要手动维护记忆文件，它们存放在~/.codex/memories目录下。
3.7 使用 Codex 插件
插件是 Skill、MCP 和规则的集合体。比如有一个 Linear 插件，它内置了访问 Linear 的 MCP，也提前定义了一些处理 Linear 的 Skill 和指令。你做前端开发时，想让 AI 读取 Figma 设计稿，就需要配置 Figma 的 MCP。但更省事的做法是直接安装一个 Codex 的 Figma 插件——MCP 和相关的 Skill 都一并解决了，省时省力。
在 Codex 界面左上角找到插件入口，浏览并安装你需要的插件即可。
四、一些 Codex 小技巧
4.1 给予 Codex 更高权限
默认情况下，Codex 使用的是常规权限。项目的常规操作、代码读取、修改都没有问题。但涉及删除或者超出权限的操作，AI 会先询问你的意见。如果你希望它自动处理一切、不再啰嗦，可以启用完全访问权限——不过一般不太建议这么做，万一它悄悄删除了某些你不清楚的内容，就比较麻烦了。
4.2 配置项目快捷命令
Codex 右上角有一个功能，允许你把项目里常用的终端命令配置成快捷按钮。比如快速启动本地服务，给它加一个标题和对应的命令，下次点击后 Codex 就会帮你唤醒终端执行命令。这一点确实非常方便。
4.3 使用 Codex 内置浏览器
项目启动之后，可以用command + shift + b唤醒内置浏览器，手动输入地址就能在 Codex 里面直接访问你的项目了。比较智能的是，如果本地服务已经启动，浏览器区域会直接展示项目列表，点击即可访问。
更妙的是，开启注释模式后，你可以直接选中页面上的某个 DOM 元素，输入指令与 AI 直接对话。对于 UI 类的 bug 修复和问题排查来说，这个功能非常实用——AI 可以直接获取 DOM 信息和文本信息，代码定位也就更加精准了。
4.4 使用 Worktree 隔离代码作用域，同时处理多个任务
通常的做法是：如果你手上有几件互不相关的事情，完全可以在同一个项目里开启多个对话框，分别提问。这样处理起来就像同时用了多个大脑。但问题是——多个对话框里的代码改动能互相干扰，做 review 和理解代码变动会变得相当麻烦。
Worktree 正好解决了这个痛点。它会以某个代码分支为起点，创建多个完全独立的副本。每个副本起点完全一样，但彼此改动互不影响、互不可见。任务完成之后，你可以把每个副本的改动逐一合并到目标分支上（当然，可能会存在代码冲突需要处理）。
操作方式：新建一个对话框，选择“新工作树”，然后指定你需要的起点分支即可。此时代码区会生成一个副本，完全不影响你主分支的工作。所有的修改都只发生在工作树里。
简单理解就是：多对话框隔离的是对话上下文，Worktree 隔离的是代码工作区。
主目录：/Users/echo/code/notta_monorepo工作树 A：/Users/echo/.codex/worktrees/.../notta_monorepo-xxx4.5 配置 SubAgent
SubAgent 是解决对话上下文过大的常用方案。举个例子：你希望 AI 同时修复三个 bug，但如果都放在同一个对话框里处理，三个互不相关的问题会搅在一起，上下文变得越来越乱，目标也逐渐模糊了。
更合理的做法是：将主线程里的任务分解，然后调用三个子 agent 分别处理各自的 bug。修复结束后，每一个子 agent 把结果汇总给主线程。主线程负责调度和最终的汇报，三个 bug 之间的信息完全隔离，各自独立完成。
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，在 skill 里定义什么阶段调用什么子 agent：
当用户说"按完整研发流程做这个需求"或显式调用 `$notta-feature-development` 时：1. 先调用 product subagent 梳理需求边界2. 再调用 design subagent 检查 UI/交互方案3. 再调用 developer subagent 做实现影响分析4. 最后调用 qa subagent 产出测试范围5. 主 agent 汇总结论并等待用户确认启动这个 Skill 后，AI 就明白了：在这个需求开发流程中，什么时候应该调用哪个子 agent。
4.6 使用引导，在不打断对话的情况下额外补充信息
这是工作中非常常见的场景：你给 AI 布置了一个任务，AI 已经做到了一半，你发现偏差，想及时纠正。此时不用中断对话，只需要补充你想说的信息，发送之后点击引导即可。
这样做的好处是，AI 的对话不会被打断，它会把你补充的信息及时吸收进上下文，修正自己的行为。
4.7 使用/side（/侧边）基于当前对话发起副对话
/side对话与 Claude Code 里的/btw是同一个概念。你在当前对话的基础上灵机一动，想到了一个额外的话题想探讨一下，又不想干扰主对话——这时候使用侧边对话，就能基于当前对话的上下文，开一个副本出来单独聊聊。
和 Guided（引导）的区别在于：引导是在主对话里对 AI 进行及时的信息补充或错误纠正；而侧边对话更像是：“哎，顺便问一句……”的那种随机探索。
4.8 使用/goal目标驱动 Codex 完成长任务
/goal是一种目标驱动型能力：你给 AI 一个目标，它会不断尝试、验证、再尝试，直到达标为止。过程当中它不会停下来。
想使用这个功能，需要先修改配置文件：在~/.codex/config.toml中加入goals = true。这个操作直接让 AI 帮你改就行。
不过我个人对这个模式持保留态度。如果你在做的是个人项目，给一个目标后直接等结果也算省心。但如果是正经的生产需求开发，过程中经常存在需求变动或者不稳定因素。所以我更推荐用 spec 模式来推进生产需求——说到底，AI 背不了责任，能背责的最终还是我们人类自己。
