Codex Use Cases：适合交给 Codex 的任务类型

适用场景

这篇手册用于回答一个很实际的问题：Codex 到底适合做什么？

官方 use cases 页面展示的是可以交给 Codex 的常见工程工作。本站把它整理成更可执行的中文清单，帮助你在团队里建立“哪些任务可以交给 Codex、怎么写任务、怎么验收”的标准。

任务选择原则

适合交给 Codex 的任务通常有三个特点：

1. 输入明确：仓库、文件、错误、目标或上下文清楚。
2. 输出可审查：可以看 diff、日志、测试、PR 或报告。
3. 风险可控制：即使做错，也能通过版本控制、审批和测试回滚。

不满足这三点时，先让 Codex 做分析，不要直接让它改代码。

适合 Codex 的任务类型

| 类型 | 适合交给 Codex 的任务 | 验收方式 | | --- | --- | --- | | 理解代码 | 解释模块结构、调用链、数据流 | 人工阅读总结，抽查文件引用 | | 修复 bug | 根据报错定位原因并给最小 patch | 复现步骤、测试、lint | | 补测试 | 为边界条件、回归 bug 补测试 | 测试失败再通过 | | 代码迁移 | 小范围 API 迁移、配置升级 | diff、构建、迁移清单 | | 文档维护 | 根据代码更新 README、教程、FAQ | 人工审阅和链接检查 | | 安全审查 | 检查 diff、triage findings、修复确认问题 | 安全证据、测试、review | | 前端验证 | 使用浏览器查看页面、记录视觉问题 | 截图、DOM 检查、响应式验证 |

步骤 1：把任务写小

不要这样写：

请优化整个项目。

更好的写法是：

请检查登录页移动端布局，在不改 API 的前提下修复按钮溢出问题。完成后运行 lint，并说明改了哪些文件。

一个好任务通常包含目标、范围、限制和验证命令。

步骤 2：先分析，再修改

对陌生项目，建议第一轮只让 Codex 读：

请阅读这个仓库，找出本地启动、测试和主要页面入口。先不要修改代码。

确认它理解正确后，再继续：

现在请只修改首页相关文件，解决刚才提到的移动端溢出问题。

这样可以降低 Codex 在不了解项目时直接改错方向的概率。

步骤 3：为每类任务准备验收标准

把验收写进 prompt：

完成后请运行 npm run lint 和 npm run build。如果 build 失败，请先修复你引入的问题；如果失败原因和本任务无关，请说明证据。

安全类任务可以要求：

请给出每个 finding 的证据、可达路径、反证、剩余疑问和建议下一步。没有证据不要直接标 confirmed。

步骤 4：用入口匹配任务

• App：适合多线程、worktree、review、浏览器和桌面操作。
• IDE Extension：适合当前文件、选区、TODO 和编辑器上下文。
• CLI：适合终端、脚本、CI、非交互任务。
• Cloud/Web：适合远端环境、GitHub PR、并行任务和长时间后台执行。

入口选错也能做事，但会增加上下文搬运和验证成本。

常见错误

不要把“我想要的最终结果”写成一句模糊愿望。Codex 需要知道范围和验收方式。

不要让 Codex 同时做产品决策、设计改版、数据库迁移和发布。拆成多个可审查任务。

不要省略“不要做什么”。比如“不改公共 API”“不引入新依赖”“不动无关文件”常常很关键。

小结

Codex 最适合处理可描述、可审查、可回滚的工程任务。真正的效率来自任务拆分：先让它理解，再让它修改，最后用测试、构建、截图或证据验收。