上周，我正面对一个极其枯燥的重构任务：把一个老旧的 Express.js API 从 CommonJS 的 require 写法迁移到 ES Modules，整整要改 47 个文件。我估摸着，这得花上一整天的时间去搞那种让人头脑发木的查找替换。但我实在不想纯手动去死磕，于是决定，是时候好好试一把 OpenAI 的 Codex 了。
我之前总听人说 Codex 是个能自主干活的编程智能体——它不光是给你补全两行代码，而是能在沙盒环境里真刀真枪地写代码、跑代码、不断迭代。花了几天时间用它啃下那个重构任务还有其他一些活儿后，我摸索出了一套好用的工作流。这里给大家分享一份实操指南，当然，也包括我踩过的一些坑。
选择你的交互界面
首先你得知道，Codex 不止一种用法——它有四种使用方式：
- 桌面应用（如果你讨厌敲命令行，选这个准没错）
- VS Code 扩展（日常开发无缝集成，这是我的主力）
- CLI 命令行工具（处理快速、单一任务的最优选）
- Codex Cloud（完全在 OpenAI 的基础设施上运行）
我最开始用的是 VS Code 扩展，毕竟我一天 90% 的时间都泡在 Code 里。但很快我就发现，遇到批量操作时，我更倾向于用 CLI。敲下一行命令，看着 Codex 启动沙盒、写代码、跑测试，最后把结果交到你手上，这感觉真的挺爽。
安装与配置
咱们走一遍 CLI 的设置流程，因为它的适用性最广。
首先，通过 npm 安装：
npm install -g @openai/codex
接着，你需要配置 OpenAI API 密钥。如果你之前用过 OpenAI API，可能手里已经有了，但得确保这个密钥有权限访问 Codex 所需的模型（根据你的账户等级，可能是 o3-mini 或 o4-mini）。
export OPENAI_API_KEY="sk-your-key-here"
我之前犯了个错，用了一个老密钥，结果没有新版推理模型的访问权限。Codex 只是抛出了一个含糊的认证错误，根本没解释为什么。懵了十分钟后，我在 OpenAI 控制台重新生成了一个新密钥，一切才恢复正常。吸取我的教训：一定要用有相应模型权限的新密钥。
面试环节：选择模型与推理等级
有个点让我挺意外的：刚开始给 Codex 下达任务时，它不会闷头就干，而是先“面试”你。
启动任务时，Codex 会让你选择模型和推理等级。这是个关键决定，我一开始没太当回事。
- 模型：通常在 o3-mini 和 o4-mini 之间选。o4-mini 速度更快、更便宜，而 o3-mini 处理复杂任务时的推理能力更强。
- 推理等级：这控制着 Codex 在动手前要“思考”多久。低等级推理快但浅；高等级推理慢，但更能搞定复杂逻辑。
对于我那个 CommonJS 转 ESM 的活儿，我选了 o3-mini 加高等级推理。而像“给这些工具函数加上 JSDoc 注释”这种简单任务，o4-mini 加低等级推理就绰绰有余了。
实战首秀：代码迁移
我来具体展示一下我是怎么用 Codex 搞定那个重构任务的。
我进入项目目录，然后运行：
codex "Migrate all .js files in the src/ directory from CommonJS require/module.exports to ES Module import/export syntax. Update package.json to include 'type': 'module'. Make sure all file imports include .js extensions in the import paths."
接下来发生的事真的很惊艳。Codex 做了这些：
- 通读了项目结构
- 找出了需要修改的全部 47 个文件
- 制定了执行计划
- 在沙盒中执行了修改
- 跑了一遍现有的测试套件，确认没改坏东西
- 把所有修改的 diff 差异展示给我看
整个过程大概花了四分钟。而我手动估算是八个小时。
但有意思的来了：测试报错了。Codex 漏掉了一个情况：有几个文件在动态 require() 调用里用了模板字符串，这种情况没法简单地转成静态的 import 语句。不过 Codex 并没有摆烂，它读取了测试输出，定位了具体的报错，然后把那些动态引入重构成了带有适当错误处理的 import() 表达式。
这种“编写-测试-读报错-修复”的循环，正是 Codex 跟普通代码生成器最本质的区别。它是真的能对实际情况做出响应。
简单点儿的例子：修 Bug
第二天，我遇到个 Bug，一个日期格式化函数在某些时区偏移量下会返回 "undefined"。我把它丢给了 Codex：
codex "The function formatDateUTC in src/utils/date.js returns 'undefined' when the timezone offset is negative. Fix the bug and add a test case that covers negative offsets."
不到一分钟，Codex 就找到了问题：函数用了 Math.sign() 来判断偏移方向，但没处理 Math.sign() 返回 -1 的情况。它修复了逻辑，还加了一个对应的测试用例。干净、利落、准确。
用了一周后的实操建议
在几个不同的项目里用了几天 Codex 后，我总结出一些能稳定产出更好结果的套路：
明确范围。 “重构认证模块”太笼统了。“把 server.js 里的 JWT 校验逻辑抽离出来，放到 src/middleware/auth.js 这个独立的中间件文件里”，这样 Codex 才有清晰的目标。
交代测试配置。 Codex 会跑测试来验证自己的工作，但它得知道怎么跑。告诉它：“用 npm test 跑测试”或者“使用 Vitest 框架”。
提供规范上下文。 如果你的项目有特定的命名规范、目录结构或模式，提前说清楚。我之前浪费了一次提示词，就因为 Codex 按标准规范建了文件，结果跟我团队非主流的文件夹结构冲突了。
架构设计开高推理，机械操作开低推理。 如果你是让 Codex 设计新功能，把推理等级拉满。如果只是让它补全缺失的分号，低推理快速搞定就行。
合并前务必审查 diff。 Codex 很强，但不是万无一失。在把改动合入代码库前，我一定会审查一遍。有一次它在一个异步函数里引入了一个微妙的竞态条件，乍一看没问题，但在负载下绝对会引发偶发故障。
实话实说的局限性
Codex 不是魔法，有些真实的限制你得心里有数：
- 它最擅长边界清晰的任务。 如果一个改动需要理解代码里没写出来的深层业务逻辑，Codex 就会抓瞎。它读的是你的代码，不是你的脑子。
- 大代码库可能会比较慢。 当我让 Codex 处理一个包含几百个文件的 monorepo 时，它光是熟悉环境就花了相当长的时间。把任务拆成更小、范围更明确的提示词，效果会好得多。
- 沙盒有局限。 Codex 在隔离环境中运行代码。如果你的测试依赖外部服务、数据库或特定的环境变量，你需要提前做好 mock，或者提供配置说明。
- 它不能代替你理解自己的代码。 我见过有开发者看都不看就接受 Codex 的输出，这简直是制造技术债的绝配。把它当成战力倍增器，而不是代码审查的替代品。
最后的想法
回到开头那个 CommonJS 转 ESM 的迁移？我大概花了 30 分钟审查 Codex 的产出，只发现两个小问题（动态 import 的错误处理跟我的写法稍有不同，还有一个文件多了个没必要的 import），当天下午就发布上线了。原本让人痛不欲生的一整天苦力活，算上审查时间，变成了区区几个小时。
Codex 已经在我的工作流中稳占一席之地了，尤其是处理那些繁琐、明确、不需要太多领域知识，但需要在大量文件中细致、一致执行的任务。至于架构决策和复杂的业务逻辑，我还是自己动脑子——但把决策转化为代码这种苦活累活，我全交给 Codex。