Codex 是什么：使用方式、适用场景与学习路线
Codex 是 OpenAI 面向软件工程任务提供的编码代理。它不只是回答代码问题，还可以读取代码仓库、修改文件、运行命令、执行测试、分析差异并完成代码审查。
与普通聊天式代码助手相比，Codex 的核心差异是：它能在一个受控环境中直接执行工程动作，并根据运行结果继续迭代。
1. Codex 可以做什么
Codex 常见能力包括：
- 理解陌生代码仓库和模块关系；
- 根据需求修改一个或多个文件；
- 运行构建、Lint、单元测试和集成测试；
- 根据报错、日志或复现步骤修复 Bug；
- 重构代码并保持公共 API 不变；
- 审查未提交改动、指定提交或分支差异；
- 使用
AGENTS.md持久化项目规则； - 使用 Skills、Plugins、MCP 和子代理扩展工作流；
- 通过
codex exec、SDK 或 GitHub Action 接入自动化流程。
Codex 最适合“目标明确、可以验证”的任务，例如：
修复用户保存设置后刷新页面丢失的问题。
要求：
1. 不改变现有 API 返回结构；
2. 添加回归测试；
3. 运行最小相关测试；
4. 汇报修改文件和测试结果。
相比之下，下面这种请求信息不足：
帮我优化这个项目。
“优化”可能指性能、结构、可维护性、界面、构建速度或安全性。应先明确目标和验收标准。
2. Codex 的主要使用方式
2.1 Codex CLI
Codex CLI 在终端中运行，可以读取当前目录的代码，编辑文件并调用本机已有工具。
适合：
- 习惯终端工作的开发者；
- 需要查看完整命令执行过程；
- 需要与 Git、测试、构建脚本一起使用；
- 需要通过
codex exec做自动化。
启动方式：
cd ~/code/my-project
codex
2.2 Codex IDE 扩展
IDE 扩展把 Codex 放在编辑器侧边栏中。它通常能自动获得当前打开文件、选中代码和编辑器上下文。
适合：
- 聚焦修改某个文件或函数；
- 边看代码边与 Codex 讨论；
- 在编辑器内审查 Diff；
- 从本地任务切换到云端任务。
在 CLI 中一般需要主动写明路径；在 IDE 中，打开文件和选中代码通常会自动成为上下文，但仍建议明确说明修改范围。
2.3 Codex 桌面端
桌面端适合同时管理多个项目和多个代理任务，并结合项目、Git、工作树、自动化等功能。
适合：
- 同时推进多个相互独立的开发任务；
- 需要长时间运行或多线程工作流；
- 希望集中查看任务、差异和进度。
2.4 Codex Cloud
Codex Cloud 在隔离的云端环境中执行任务，可以并行处理多个工作项，并把结果形成可审查的变更或 Pull Request。
适合：
- 大规模重构；
- 耗时较长的测试或迁移；
- 同时处理多个 Issue；
- 远程执行并在完成后集中审查。
云端环境与本机环境并不相同。依赖安装、环境变量、Secrets、网络访问和构建命令都需要单独配置。
3. Codex 与普通 ChatGPT 对话的区别
| 能力 | 普通代码问答 | Codex 工程任务 |
|---|---|---|
| 阅读代码 | 依赖粘贴或上传 | 可读取项目目录 |
| 修改文件 | 通常给出代码片段 | 可直接产生文件变更 |
| 运行命令 | 一般不能访问本机 | 可在沙箱内运行命令 |
| 测试验证 | 提供建议 | 可执行测试并读取结果 |
| 多轮迭代 | 依赖用户复制结果 | 可基于命令结果继续处理 |
| 代码审查 | 基于提供内容 | 可审查 Git Diff、提交或分支 |
因此，使用 Codex 时不要只问“代码怎么写”，而应把它当作一个需要目标、上下文、限制条件和验收标准的工程代理。
4. 一个标准 Codex 任务的结构
建议使用以下结构：
目标：
为设置页面添加“导出数据”功能。
相关位置：
- 页面：src/pages/settings.tsx
- API：src/api/export.ts
- 测试：tests/settings/export.test.ts
要求：
- 导出 JSON 文件；
- 不修改现有数据库结构；
- 按现有按钮样式实现；
- 错误时显示 Toast；
- 不新增生产依赖。
验证：
- 运行 npm run lint；
- 运行 npm test -- export；
- 汇报修改文件和命令结果。
四个关键部分分别是：
- 目标：最后要交付什么；
- 上下文：从哪些文件、错误、截图或文档开始；
- 约束：哪些内容不能改；
- 验证：怎样判断任务完成。
5. 哪些任务应该先使用 Plan
以下情况建议先进入 Plan 模式：
- 需要修改多个模块；
- 需求仍然有歧义；
- 涉及数据库、权限、支付或认证；
- 需要保持兼容性；
- 预计工作超过一个小型提交；
- 你还不了解代码仓库结构。
示例：
/plan
分析当前认证系统，设计把 Session 存储从内存迁移到 Redis 的方案。
先不要修改代码。
计划必须包含：影响文件、数据迁移、回滚策略、测试范围和上线步骤。
简单改字、修改样式或修复明确的小问题，不必强制使用 Plan。
6. 建议的学习顺序
第一阶段：掌握本地工作流。
- 安装 CLI；
- 让 Codex解释项目；
- 完成一次小范围修改；
- 学会查看 Diff 和运行测试；
- 学会撤销或恢复变更。
第二阶段：建立项目规则。
- 创建
AGENTS.md； - 配置
config.toml； - 理解 Sandbox 与 Approval；
- 固化构建、测试和审查命令。
第三阶段：处理完整工程任务。
- 使用 Plan 拆分需求；
- 分里程碑实现；
- 自动补充测试；
- 使用
/review做二次审查； - 再考虑 Skills、MCP、子代理和自动化。
7. 新手最容易犯的错误
错误一：一次交给 Codex 太多任务
不要在同一条指令中同时要求重构、升级依赖、改 UI、修测试和部署。任务越大，审查成本越高。
错误二：没有提供验证方式
Codex 可能完成了代码修改，但并不代表程序真的工作。至少要求运行最小相关测试。
错误三：没有创建 Git 检查点
开始前先确认工作区状态：
git status
git add -A && git commit -m "chore: checkpoint before codex task"
不想提交时，也可以使用临时分支或 Git worktree。
错误四：直接给予无限权限
优先使用默认沙箱和按需批准。只有在容器、虚拟机或其他外部隔离环境中，才考虑更宽松权限。
8. 本章练习
在一个已有 Git 项目中运行：
codex
然后输入：
先不要修改代码。
请阅读项目入口、依赖配置和主要目录，回答：
1. 这是一个什么项目；
2. 如何启动；
3. 如何运行测试；
4. 核心业务模块在哪里；
5. 建议我先阅读哪 5 个文件。
完成后，再让 Codex验证它给出的启动和测试命令是否真实存在。
官方参考
- https://learn.chatgpt.com/docs/codex/cli
- https://learn.chatgpt.com/docs/codex/ide
- https://learn.chatgpt.com/docs/codex/cloud
- https://learn.chatgpt.com/docs/prompting
资料核对日期：2026-07-14。Codex 功能和命令更新较快，发布网站时建议同时记录文章更新时间。