我用Codex CLI解决了后端开发中最头疼的5个问题

今年年初的时候，我开始系统性整理自己日常开发中的时间开销。结果发现一个挺打击人的事实：每天写的代码里，大概60%的时间花在了那些"我知道怎么写、但就是得一行行敲出来"的事情上。

写CRUD接口，写测试，修lint，做数据库迁移，排查线上报错——这些事情技术上没难度，但极其消耗注意力和时间。

四月份开始用Codex CLI，到现在有三个月了。这篇文章不讲安装、不讲配置（网上一搜一大把），只讲一件事：它帮我干掉了哪些让我头疼的问题，以及怎么做到的。

问题一：CRUD接口写吐了

后端开发最消耗心力的不是复杂业务逻辑，是那些一个接一个的CRUD接口。Controller、Service、DAO、Test，一套流程走下来，即使熟练也要十几二十分钟。问题是这个过程里90%的操作都是机械的。

用Codex CLI之后，我通常是这样做的：

直接把需求描述给它：

codex "add a GET /api/products/:id/reviews endpoint, include pagination, sorting by created_at desc, Prisma query with user relation, zod validation, and Jest tests"

五分钟之后，四个文件全部就位，测试跑通，lint无报错。我需要做的就是在生成的代码上补充业务特有的判断逻辑。

三个月下来我的CRUD类需求完成时间从平均4.5小时降到了1.8小时。不是变快了，是不需要自己敲那些机械的部分了。

问题二：重构没人愿意干

每个项目里都有那种两千行的user.service.ts、order.service.ts。所有人都知道该拆，但没人想碰——风险太大，容易引入bug。

我让Codex干的第一次大活就是拆分一个2100行的user.service.ts：

codex "refactor src/services/user.service.ts into auth.service.ts, profile.service.ts, password.service.ts, permissions.service.ts. Keep all tests green. Update imports project-wide."

它的执行过程很讲究——不是简单地把函数搬来搬去。它先静态分析了所有函数的调用关系，然后按职责分组，每切出一个小模块就跑一遍全量测试。中间有两个测试挂了（循环依赖），它自动回溯调整了拆分方案。

最终2100行拆成5个文件，最长的400行，最短的120行。整个过程的commit记录清清楚楚，随便review。

问题三：237个ESLint错误挂在CI里

CI流水线里积压了237个ESLint错误，每次提PR都要顶着红叉。手动修太无聊，不修又过不了。

一句话搞定：

codex "fix all ESLint errors. Run --fix first, then manually handle the rest. Don't disable rules, don't change logic."

Codex先跑了eslint --fix（自动修了约180个），剩下的逐个分析类型定义、import顺序、未使用变量。全部修完之后自动跑了一遍测试确认没引入新问题。

这种事以前只能靠"哪天不忙了集中修一下"，但这个"哪天"从来没来过。有了Codex之后，这类技术债的清理成本降到了零。

问题四：凌晨三点排查线上Bug

这大概是我对Codex CLI改观最大的一个场景。

凌晨三点告警：/api/checkout 500。爬起来第一件事不是翻日志，是把报错栈甩给Codex：

codex "there's a 500 on /api/checkout, stack trace: TypeError: Cannot read properties of undefined (reading 'price') at OrderService.calculateTotal (order.service.ts:142)..."

36秒后它给出诊断：products表中有已被标记为deleted的商品，但Prisma查询的include没有过滤status，导致某些product对象为null。自动修复了查询条件，跑完测试，生成commit。不到两分钟。

说实话，凌晨三点脑子基本是空白的，根本分析不了什么问题。Codex在这个场景下是真正帮了大忙的。

问题五：数据库迁移总是忘记加测试

每次加字段、改表结构，migration写了，model改了，但测试经常忘。等到后来出问题才发现。

后来我形成了一套固定做法：

codex "add soft delete to users, orders, products. Generate migration, update schema, add Prisma middleware to auto-filter, write tests for CRUD after soft delete."

Codex不是只生成SQL完事，而是把整个改动链路全部覆盖——migration、schema更新、middleware、测试用例。甚至帮我考虑到了findUnique和findFirst在软删除下的行为一致性，自动把两者都改写为findFirst加deletedAt: null过滤。

这种细节如果手动处理，大概率会遗漏一两个。

几个容易忽略的实践建议

这三个月用下来，有几个经验不是**文档会告诉你的：

第一，.codexignore一定第一时间配。不配的话它会把node_modules整个扫一遍，第一次执行能卡到你怀疑这个工具是不是坏了。

第二，用CODEX.md定义项目规范。在项目根目录建一个CODEX.md，写清楚技术栈、代码风格、命名约定。Codex每次启动会读这个文件，生成的代码风格和你现有的完全一致。比反复纠正它高效得多。

第三，从测试和lint开始建立信任。不要一上来就让它动核心模块。先让它写测试、修lint、加注释。观察几次风格之后，再逐步放权。我现在对它的信任是逐步建立起来的——它改的代码我会review，但越来越少的改动需要修改。

第四，--approve模式谨慎用。它能一条指令完成"改代码→跑测试→commit"，但我只在个人项目里开这个模式。团队项目还是建议逐条确认。

总结

Codex CLI对我最大的价值不是"AI更强了"，而是它把我从"写代码的人"变成了"描述需求的人"。这两者之间的效率差距，远远超过模型能力的代际提升。

如果你日常工作中有大量CRUD、测试编写、代码重构、数据库迁移这类重复性操作，不妨试试。Windows用户可以直接从codex.ijinshan.com下载，免去配环境的麻烦。

我现在的感觉是：回不去了。