OpenAI Codex vs 手动操作：效率对比实测
我为什么要做这个测试
上个月我接了一个老项目的维护工作——一个三年的 Laravel 后端加一个 React 前端，代码库大概 12 万行，文档几乎没有。我的任务是：加一个导出功能、修三个历史遗留 bug、顺便把两个 API 从 REST 迁移到 GraphQL。
放在以前，这种活儿我大概要磨两周。这次我决定做个实验：一半任务用 Codex CLI 做，另一半完全手动，记录每一项的实际耗时，看看所谓的“效率提升”到底有多少水分。
测试环境
- Codex CLI（npm 包，
@openai/codex），接 GPT-5 的 codex 模型 - 一个 12 万行的真实业务代码库，不是我平时用来 demo 的玩具项目
- 计时方式：手机秒表，从拿到需求到测试通过为止
任务分配是这样的，我特意挑了难度和性质不同的活儿：
| 任务 | 方式 |
|---|---|
| 导出 CSV 功能（新功能） | 手动 |
| 三个历史 bug 修复 | Codex |
| REST → GraphQL 迁移 | 手动 |
| 写单元测试补齐 | Codex |
| 数据库迁移脚本升级 | Codex |
第一轮：手动做导出功能 —— 3 小时 40 分钟
我老老实实手动写。找到导出相关的 service 层花了 25 分钟（这还是因为我熟悉 Laravel 的目录习惯，不熟的话更久），写查询、分块处理、流式响应、处理中文编码问题（BOM 头这个坑谁踩谁知道），最后写测试。
这 3 小时 40 分钟里，真正写代码的时间大概只有 1 小时 10 分钟。剩下全部是：读别人的代码、确认业务逻辑、查这个项目自定义的 response 格式、跑测试修边角。
这个数据很重要，后面会呼应到。
第二轮：Codex 修 bug —— 意外的好，但有一次惊吓
我用的是 Codex CLI，在项目根目录直接跑交互模式：
codex
第一个 bug 的提示词我是这么写的：
用户反馈：当订单状态是 "refunded" 时，订单列表页的金额列显示为负数。
请在这个代码库中定位问题，给出修复方案。先不要改代码，告诉我你的分析和打算改哪些文件。
这里有个我踩过的坑要先说：第一次我用的是简短提示，就一句“修复金额显示为负数的 bug”。Codex 直接开始大刀阔斧改代码，改了 5 个文件，其中两个改动跟问题完全无关，是在“顺手重构”。我全部拒绝了，重来。
加了“先分析再动手”的约束之后，效果好得多。它正确地定位到了 OrderTransformer.php 里的一个问题——退款单的金额在入账时已经是负数，展示层又取了一次绝对值再乘 -1。这是典型的双重取反 bug，我手动找估计也要半小时。
三个 bug 的最终数据：
- Bug 1：18 分钟（含我 review 的时间）
- Bug 2：26 分钟（Codex 第一次方向错了，我纠正后收敛）
- Bug 3：41 分钟（这个 bug 涉及一个 2019 年的迁移文件，Codex 找到了，但修复方案在生产环境有锁表风险，我自己改了方案）
总计约 1 小时 25 分钟。我自估手动做同样的三个 bug，保守要 3 到 4 小时。这部分效率提升是真实的，大概 2.5 倍。
但要强调：每一次我都逐行 review 了它的 diff。不 review 直接合，Bug 3 那个方案会出生产事故。
第三轮：手动做 GraphQL 迁移 —— 我赢在了“决策”上
这个任务我手动做，4 个小时。难点不在写代码，在于决策：schema 怎么设计、哪些字段暴露、resolver 的 N+1 问题怎么处理、跟现有的鉴权中间件怎么对接。
我试着想象如果让 Codex 做会怎样——它大概能快速生成一个“能跑”的版本，但这些架构决策恰恰是它最容易自信地做错的地方。比如我们项目里 user 的 phone 字段有严格的脱敏要求，这种业务约束它从代码里看不出来（其实在注释里有一条，但它没注意）。
第四轮：让 Codex 补测试 —— 最省心的部分
这是效率差距最大的一项：
为 src/Services/ExportService.php 补齐单元测试。
要求：覆盖成功路径、空结果、超大结果集分块、特殊字符转义。
使用项目现有的 PHPUnit 测试风格，参考 tests/Unit/OrderServiceTest.php 的写法。
给它一个参考文件非常关键。第一次我没给参考，它写的是标准 PHPUnit 风格，但和项目里的 Mockery 用法不一致，风格割裂。加上参考文件后，输出直接能用。
5 个测试文件，43 分钟完成，我 review 后只改了两处断言。手动做这个活儿，我估计至少 3 小时。接近 4 倍的提升，因为写测试模式重复度高、判断成本低。
数据汇总
| 任务 | 手动耗时(估) | Codex 耗时 | 提升 |
|---|---|---|---|
| 导出功能 | 3.7h（实测） | — | — |
| 修 3 个 bug | ~3.5h | 1.4h | ~2.5x |
| GraphQL 迁移 | 4h（实测） | — | — |
| 补测试 | ~3h | 0.7h | ~4x |
| DB 迁移脚本 | ~2h | 0.9h | ~2x |
我的实操建议
- 永远先让它分析，再让它动手。 提示词里加“先不要改代码，先给我方案”。这是我从第一次翻车学到的最重要一课。
- 给它参考文件。 “参考 XXX 的风格”，输出的代码风格一致性天差地别。
- 给上下文约束。 我们项目有自定义的 response wrapper，我在提示里明确说“必须使用 App\Http\Responses\BaseResponse”，否则它自己发明一套。
- 改动越大的任务，diff review 时间要算进总成本。 Codex 的耗时数据里，我的 review 时间占了三成，这不能省。
- 低风险、高重复的活优先交给它：测试、模板代码、迁移脚本、格式转换。涉及架构和业务规则的活自己来。
诚实的局限性
- Codex 在这个老代码库里偶尔会“自信地编造”——引用一个不存在的方法时语气和引用真实方法完全一样，必须靠 IDE 跳转验证。
- 它对项目的隐性约定（脱敏规则、部署限制）一无所知，除非写在代码或注释里。
- 简单任务（改个文案、加个字段）用它反而慢，光描述需求的时间就够自己改完了。
- 总体上，这次实验我的净节省大约是 6 小时，不是宣传语里那种“10 倍效率”。对一个熟悉代码库的熟练开发者来说，它更像一个很快但需要盯着的初级同事——用得好省力，撒手不管出事。