之前公司一直使用的 cursor 和 Claude code，但因为 cursor 企业订阅后续取消了 request 计费模式，无论是个人还是企业用户都是按量计费，导致现在 20$ 最多也只能用一天；而 Claude code 也因为 IP 变动频繁造成封号，最终采购了 codex，本文也是基于之前使用 cursor 和 Claude code 习惯，帮助大家快速将 AI 相关配置迁移过来。
codex 对于 Claude code 专门做了配置入口，我们可以在 设置 -- 常规 -- 从其它 AI 应用导入工作内容，选择导入后支持将 Claude code 的 skill、插件、agent.md 以及最近 30 天的聊天记录直接迁移过来；未来是否会支持 cursor 暂不确定，cursor 的迁移暂时得手动处理。
codex 的指令效果和 cursor 的 rule 作用类型，它的作用是告知 AI 在问答时必须遵循的规则，它可能是项目规范，细化到某个技术的要求等等，我们可以直接在 设置 -- 个性化 -- 自定义指令 添加你希望 codex 遵循的个人规则，这里分享下我的规则。
## 1. 编码前先确认
不要私自假设。先说明假设、权衡和不确定点；有争议时由我决策。
如果我要求先讨论方案，不要修改代码，直到方案确认无疑问后再开始实现。
## 2. 最小改动
只用解决问题所需的最少代码。不添加投机性功能，不为单次使用建立抽象。
只改必须改的地方，不顺手优化、重构或改动无关代码，保持现有风格。
## 3. 分步执行
复杂任务先确认技术方案，再按步骤执行；每完成一步先汇报并等待确认后继续。
简单任务可自主迭代，直到验证通过。
## 4. 优先参考现有实现
实现前先找现有业务或模块作为参考，尽量复用已有模式；不明确时先问我。
这个执行会在 codex 会话启动时自动注入到上下文中，所以一般不推荐这个文件包含过多复杂的指令；俗话说的好，指令越多那就等于没指定，所以一般这里存放你希望跨项目且 codex 必须遵守的重要指令。
另外，以上执行的修改等同于修改 ~/.codex/AGENTS.md，修改方式不同，但本质是同一个文件。
顾名思义，这个 rule 只会在对应项目上下文提问时，自动注入到对话上下文，codex 的做法和 Claude code 相同，我们只用在项目根路径新建 AGENTS.md 文件即可，比如 codex 在修改这个项目时必须遵守的技术规范等等。
而我们 notta 项目是一个 monorepo 仓库，因此也不适合项目根路径创建一个 AGENT.md，合适的做法是在不同项目创建属于它自己的项目级别指令，比如：
Skills 简单理解就是给 AI 阅读的 sop 文档，我们可以将工作中重复性高预期明确的事情封装成 skills，具体 skill 如何写这里不展开，最简单的方式是使用 skill creator 的系统级别 skill 来让 AI 创建。
之前 cursor 的 skill 都在 .cursor/skills 目录下，将 cursor 的 skills 迁移过来非常简单，我们只用将 .cursor 改成 .agents即可，skills 目录不用做任何修改，之后重启 codex 即可，如图：
与指令相同，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
如果我们将 codex 理解一个内置大模型的 AI 黑盒，MCP 的作用就是让这个盒子能和外界通信，比如阅读 Google doc 文档，拉取 linear bug 信息；codex 配置 mcp 也很简单，在 设置 -- MCP 服务器 可添加和编辑 mcp，比如我非常喜欢 kiro 的 spec 工作流，所以添加了如下配置，如图：
其中工作目录决定这个 MCP 的作用范围，比如截图是 codex 根路径，那就是个人级别 MCP，如果需要对特定项目生效，再次增加项目路径即可。
与 cursor 、Claude code 一样，codex 同样支持开启 memories，我们可以在 设置 -- 个性化 -- 记忆 -- 启动记忆，之后 codex 会在和你日常沟通中自动提取重要的记忆，记忆是账号级别，也就是跨项目跨对话。
codex 的 memories 类似一个外置的 RAG，比如某个话题之前 AI 犯错过，但对你非常重要，一般 AI 会主动记录记忆，那么下次相同问题讨论 AI 会主动接入记忆避免犯错。
如果你希望迁移 cursor 的 memories，最简单的方式让 codex 阅读 cursor memories 后直接写入自身的记忆文件，一般情况我们不需要手动维护 memories，记忆记录在 ~/.codex/memories 目录下。
简单来说，插件是 skill、mcp 和 rule 的集合体，比如 linear 插件，它内置了访问 linear 的 mcp，也提前定义了一些处理 linear 的一些 skill 或者指令；比如我们做前端开发阅读让 AI 阅读 figma 设计稿就需要配置 figma mcp，但更简单的办法是直接安装 codex figma 插件，这样 mcp 以及一些 skill 直接会内置，配置上更为简单。
我们能在 codex 左上角的插件中找到你可能需要的插件，点击安装即可。
默认情况下，codex 使用默认权限，一般项目的修改，读取 codex 自动会帮你完成，但在一些删除以及一些越权操作，codex 会主动询问你，但如果你希望 codex 自动完成所有事情，不要提问，可以考虑使用完全访问权限，但一般不太推荐，万一删了什么你不知情就很麻烦。
我们 codex 右上角可以配置一些快捷项目脚本命令，比如快速启动本地服务等等，添加标题描述，项目命令，后续点击启动 codex 会唤醒终端执行命令，这一点还是挺便捷的。
使用项目启动本地项目后，我们可以使用 command + shift + b唤醒内置浏览器能力，然后手动输入地址就能在 codex 里直接访问项目；比较智能的是，如果你本地已经起了服务，这里也会展示项目，点击后就能访问。
更强大的是，我们能开启注释能力，然后直接选择 dom 后输入 prompt ，直接和 codex 对话，这对于 UI bug 修复和缩小问题会非常方便，codex 能直接拿到 dom 信息以及文本信息，对于代码定位会更加精确。
正常情况下，如果你有多个不相干的问题，你完全可以对于同个项目新开多个对话，然后分别提问，此时 codex 等同于用多个脑子帮你干活，但多个对话的代码改动会相互影响，在做 review 以及你理解代码变动其实没那么方便。
而 worktree 的作用是基于代码分支作为一个起点，开启多个分支副本（大家起点一模一样），且大家的修改相互不影响，也相互不可见，但你能在任务做完将变动一一合并到目标分支（当然可能会有代码冲突）。
我们可以新建一个对话，然后选择新工作树，选择你需要的目标起点分支开始对话即可，此时代码区将会产生一个副本，且不影响你目前主分支，你的所有修改都在这个工作树。
简单理解，多对话窗口隔离的是对话上下文；worktree 隔离的是代码工作区。
主目录：
/Users/echo/code/notta_monorepo
工作树 A：
/Users/echo/.codex/worktrees/.../notta_monorepo-xxx
Subagent 是治理对话上下文过大变的腐烂的一个方案，举个例子，你希望 AI 同时帮你修复 3 个 bug，但如果在同一对话中进行，本身 3 个互不相关的 bug 的对话信息会糅合在一起，造成上下文目标变得不清晰；而更合理的做法是，主线程调用 3 个 subagent 分别处理 bug，最终修复后分别总结信息告知主线程，主线程负责调度和最终对话汇报，bug 信息被三个隔离的 subagent 独立完成。
codex 支持项目级别和个人级别的 subagent 配置，如下：
// 项目级别
.codex/agents/code-mapper.toml
// 个人级别
~/.codex/agents/code-mapper.toml
需要注意，codex 的 skills 是在项目根路径直接新建一个 .agents 目录，而 subagent 是需要在项目根路径新建一个 .codex 目录，然后在此目录下再新建 agents 目录，创建一个 subagent 最简单的方式同样是让 AI 帮你创建。
需要注意的是，codex 的 subagent 需要你显式告知 AI 调用，它做不到像 skill 那样自动理解按需调用。
比如我们配置产品经理、开发、设计师、测试四个 subagent，然后定义一个 notta-feature-development 的 skill，在 skill 中定义何时调用这些 subagent：
当用户说“按完整研发流程做这个需求”或显式调用 `$notta-feature-development` 时：
1. 先调用 product subagent 梳理需求边界
2. 再调用 design subagent 检查 UI/交互方案
3. 再调用 developer subagent 做实现影响分析
4. 最后调用 qa subagent 产出测试范围
5. 主 agent 汇总结论并等待用户确认
之后启动这个 skill，AI 就知晓这个需求开发流中，什么阶段应该调用哪个 subagent 了。
这是一个非常常见的场景，比如你给了 codex 一个任务，但做了三分之二你发现目标跟你的理解有偏差，你希望及时纠正 AI，此时可以不结束对话，而是直接补充信息后回车发送，然后点击 引导
此时 AI 对话不会中断，而是将你补充的信息即可补充到上下文中，及时纠正 AI 行为。
/goal 是一个目标驱动的能力，给 codex 一个目标，之后 codex 会在开发，验证，循环中不断尝试，直到最终达到目标，在此之前不会停下。
如果要使用它，需要修改配置文件，在 ~/.codex/config.toml 中增加 goals = true ，这个修改行为让 AI 完成即可。
但我个人并不太推荐这个模式，如果是做个人项目，给一个目标后等结果即可，过程也不需要太操心；但对于需求开发，需求过程其实经常会存在变动或者不稳定定，所以我还是推荐 spec 模式来推进生产需求开发，毕竟 AI 无法背责，背责的是我们人类。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。