这篇文章记录我从 Claude Code 迁到 Codex App 的过程：Codex 如何自动识别并导入CLAUDE.md、Skill、Command 和 Agent；哪些内容可以直接使用；哪些还要手动调整；以及迁移之后，我如何重新分配 Codex 和 Claude 的工作。

我开始迁移，不是为了尝鲜。

Opus 最近越来越不好用，Fable 虽然能力更强，但价格太高。我所在的行业又是医疗，项目需求中常常出现疾病、诊断、用药等词，频繁触发 Fable 的安全机制，随后自动降级到 Opus。模型一旦切换，复杂任务的执行质量和稳定性都会受到影响。

当这种情况开始妨碍日常开发，我决定把项目开发逐步迁到 Codex。

我原以为最麻烦的是搬CLAUDE.md、Skill 和各种配置。结果 Codex 打开旧项目后，直接弹出了导入窗口。配置几分钟就搬完了，需要手动处理的问题反而出目前导入之后。

Codex 怎么知道这是一个 Claude 项目

我第一次迁移时，没有手动复制文件，也没有对着两套配置目录逐项修改。

在 Codex App 里点击项目旁边的+，选择使用现有项目，然后打开原来用 Claude Code 的项目，Codex 会自动探测里面的 Claude 配置。识别到后来，界面直接弹出一句：

请选择要导入的设置

它在我的项目里识别出了四类内容：

• •CLAUDE.md

• • Skill

• • Command

• • Agent

选中需要的内容，确认导入，迁移的第一步就做完了。如果打开项目时跳过了这个窗口，后面也能从设置里手动启动迁移。

这两个入口解决的是同一件事。第一次打开旧项目，跟着弹窗走最省事；当时没迁，或者想稍后再处理，就去设置里手动导入。

我原本给自己留了半天，准备处理配置文件、目录和格式差异。实际操作下来，这部分只用了几分钟。

自动探测到了，为什么还不算迁完

导入结束后，我先拿一个日常开发的代码仓库做验证。

这个仓库里既有前后端代码，也有编译启动脚本、文档资料和测试脚本。Claude Code 里还接入了一些开源 Skill 和工具，也有自己写的 Command 和 Skill，列如负责数据库查询的db-query。

迁到 Codex 后，项目规则、开源 Skill 和工具基本都能正常识别。Codex 能读懂前后端目录，也能找到仓库里的编译、启动和测试脚本。问题出在我准备调用db-query时：原来的 Command 虽然出目前导入结果里，却不能继续按 Claude Code 的方式使用。

这次验证里，需要手动处理的是 Command 和CLAUDE.local.md。

Command 被识别了，但不能继续照旧使用

导入窗口能探测到 Claude Command，不代表 Codex 还会按 Claude Code 的方式执行它。

我原来的 Command 需要改成 Skill。Command 更像一个快捷入口，Skill 则包含完整的执行流程。迁移时不能只看导入列表，还得真的调用一次。

我的处理方式很简单：不批量重写所有 Command，只迁高频使用的。用到哪个，就把哪个整理成 Skill。这样还能顺手删掉长期没用过的旧命令。

CLAUDE.local.md需要单独处理

另一个问题是CLAUDE.local.md。

Claude Code 可以用它保存个人或本地规则，又不用把内容提交到项目里。这次自动导入没有处理它。里面还需要保留的内容，要改为通过AGENTS.md单独引用。

这一步不能偷懒。CLAUDE.local.md里常常放着个人路径、本机命令或只适合自己的偏好，直接合并进团队共享的AGENTS.md，很容易把本地配置带给整个项目。

所以我目前会把内容分一遍：团队都要遵守的规则写进项目级AGENTS.md；只跟自己环境有关的内容继续放在独立文件中，再按需引用。

还需要注意的一点是，CLAUDE.md变成AGENTS.md不能只靠改文件名。旧文件里有不少针对 Claude Code 行为写的“补丁”，搬到 Codex 后未必还有必要。导入完成后，我更关心两件事：哪些旧规则该删，哪些要求要写得更具体。

从 CLI 到 App，变化有想象中大吗

从 Claude Code CLI 换到 Codex App，最直观的变化当然是界面。

以前大部分操作都在终端里完成。目前任务、对话、文件改动和执行进度都放到了 UI 中，查看、切换和预览更方便。尤其是做界面设计或 PPT 这类展示型工作时，App 的优势很直接，不需要在终端、文件管理器和预览工具之间反复切换。

但用了几天后来，我觉得两者本质上没有那么大差别。你依旧是在描述任务、提供上下文、观察执行过程，然后验收结果。UI 改变的是入口和信息呈现，不是 Agent 工作的基本逻辑。

这反而降低了我的迁移成本。Claude Code CLI 里形成的任务拆分和验收习惯，大部分还能继续用。需要重新适应的，主要是 Codex App 里的任务组织方式，以及什么时候打断、什么时候引导、什么时候把新要求排到下一轮。

这些操作我之前单独写过一篇，这里不再展开。从 CLI 到 UI 需要适应，但没有重新学一套工具那么夸张。

我没有卸载 Claude Code

迁移后，我没有急着做“Claude Code 和 Codex 到底谁更强”的结论，也没有把 Claude Code 卸掉。

目前我的分工很明确：

• • 项目需求开发逐渐以 Codex 为主。

• • 需要长时间深度推理的任务，暂时继续用 Claude。

• • 内容创作目前也保留在 Claude。

这个分法未必适合所有人，但解决了我的实际问题。项目开发看重稳定执行、规则继承和过程管理，Codex 更符合我目前的需要。深度推理和创作又是另一回事。我没必要为了“迁移完成”四个字，把所有工作都塞给同一个工具。

如果你也准备迁，可以按这个顺序来：

1. 1. 先用 Codex 的导入功能搬现有配置。

2. 2. 选一个熟悉的小项目，验证规则和常用 Skill。

3. 3. 把仍在使用的 Command 逐个改成 Skill。

4. 4. 单独检查CLAUDE.local.md，不要直接并入共享规则。

5. 5. Claude Code 先留着，用一段时间再决定任务怎么分。

权限也提议先保守一点。新工具能读到旧规则，不等于你已经了解它在所有场景里的行为。跑过几个真实任务，再逐步放开，比一开始追求全自动省事。

搬完配置之后，我怎么选

回头看，这次迁移比我预想中简单。

Codex 能自动识别CLAUDE.md、Skill、Command 和 Agent，省掉了大量复制配置的工作。需要手动处理的主要有两处：原来的 Command 要改成 Skill，CLAUDE.local.md里的本地规则也要重新安排。

我没有因此卸载 Claude Code。目前项目需求开发逐渐以 Codex 为主，深度推理和内容创作暂时继续使用 Claude。

迁移之后，我不再纠结 Claude Code 和 Codex 谁更强。项目开发需要稳定执行，我就用 Codex；深度推理和创作依旧适合 Claude，我就继续保留。工具不必选边站，能稳定完成手上的任务就够了。