Codex CLI实战5个真实开发场景下的高效用法与避坑指南写这篇文章的起因很简单——网上关于Codex的文章十篇有九篇在讲怎么安装、怎么付费。真正讲装上之后怎么用的内容几乎空白。用了三个月Codex CLI之后我把日常开发中最常用的五个场景和踩过的坑整理出来给已经装好但不知道怎么用的朋友一个参考。一、环境准备只说重点如果你还没装Windows用户最简单的方式# 方式一Scoop安装推荐scoopinstallcodex# 方式二直接下载预配置包# 从 codex.ijinshan.com 下载省去配环境变量装完之后第一步设置模型。默认模型表现一般手动指定GPT-5系列codex--modelgpt-5.3第二步创建.codexignore文件否则Codex会扫描node_modules里所有文件——你会等到怀疑人生# .codexignore语法和.gitignore一样 node_modules/ dist/ build/ .vscode/ *.log第三步建议在codex工作目录下建一个CODEX.md文件用来描述项目规范。Codex每次启动会读取这个文件作为系统提示# CODEX.md - 项目使用TypeScript Express - 数据库是PostgreSQLORM用Prisma - 测试框架Jest - 代码风格函数式优先避免class - 所有API接口必须有输入验证二、场景1生成完整的REST API接口需求为User模块新增一个根据ID查询用户订单的接口包含分页。直接对Codex说codexadd a GET /users/:id/orders endpoint with pagination (page limit query params). Include Prisma query in the service layer, input validation, and Jest tests. Return 404 if user not found.Codex的具体执行过程创建orders.controller.ts——路由处理更新orders.service.ts——添加getOrdersByUserId方法添加zod输入验证——page和limit的合法性检查生成orders.test.ts——包括正常用例、边界值、用户不存在的404自动执行npm test——六个测试用例一次通过生成的核心代码示例// orders.service.tsCodex自动生成exportasyncfunctiongetOrdersByUserId(userId:number,page:number1,limit:number20){constskip(page-1)*limit;const[orders,total]awaitPromise.all([prisma.order.findMany({where:{userId},skip,take:limit,orderBy:{createdAt:desc},include:{items:true}}),prisma.order.count({where:{userId}})]);return{data:orders,pagination:{page,limit,total,totalPages:Math.ceil(total/limit)}};}整个过程五分钟手动写至少要半小时。三、场景2重构臃肿的Service文件项目中有一个2100行的user.service.ts包含了用户相关的所有逻辑——注册、登录、资料修改、权限管理、密码重置全塞在一个文件里。一句命令codexrefactor src/services/user.service.ts. Split it into smaller modules: auth.service.ts, profile.service.ts, password.service.ts, permissions.service.ts. Extract shared utilities. Keep all existing tests passing. Update all imports across the codebase.Codex的做法值得一说——它不是粗暴地切成几块就完事而是先分析当前文件的所有导出函数和它们的依赖关系按职责分组后逐一创建新文件提取公共工具函数到user.utils.ts更新整个项目中所有import路径每切完一个模块就跑一次测试保证不挂重构过程中有两个测试挂了循环依赖问题Codex自动识别并修复。最终2100行的文件拆成了5个文件平均每个200-400行。四、场景3自动修复Lint错误CI/CD里挂了237个ESLint错误手动修得一个个点。Codex一句话codexfix all ESLint errors in the project. Run npx eslint --fix first, then manually fix remaining issues. Dont disable rules.执行过程先跑npx eslint --fix自动修复了约180个剩下的逐个分析主要是no-unused-vars、typescript-eslint/no-explicit-any、import/order自动补充缺失的类型定义调整import顺序修完后自动跑一遍测试确认没有引入新问题。五、场景4生成数据库迁移需求为三个表添加软删除支持deleted_at字段。codexadd soft delete support to users, orders, and products tables. Generate migration files, update Prisma schema, add middleware to filter out soft-deleted records by default, and add tests.Codex完成后你得到的是一个migration SQL文件更新后的schema.prisma一个Prisma middleware自动过滤deleted_at IS NOT NULL的记录测试覆盖软删除后的增删改查核心的middleware代码// Codex自动添加的软删除中间件prisma.$use(async(params,next){if(params.actionfindUnique||params.actionfindFirst){params.actionfindFirst;params.args.where{...params.args.where,deletedAt:null};}if(params.actionfindMany){params.args.where{...params.args.where,deletedAt:null};}returnnext(params);});六、场景5排查线上Bug凌晨三点收到告警/api/checkout接口500错误。从床上爬起来把报错栈甩给Codexcodextheres a 500 error on the /api/checkout endpoint. Heres the error: TypeError: Cannot read properties of undefined (reading price) at OrderService.calculateTotal (/app/src/services/order.service.ts:142) at CheckoutController.processCheckout (/app/src/controllers/checkout.controller.ts:56)36秒后Codex给出诊断根因order.service.ts第142行products数组中某个元素没有price字段。 数据库中存在关联的product_id但该商品已被删除products表中有该id的记录但statusdeleted 导致Prisma include返回null而非跳过。 修复方案在Prisma查询的include条件中添加status: active过滤。然后自动应用修复、跑测试、生成commit message。整个过程不到两分钟。七、四个必须注意的坑坑1.codexignore别忘了配前面提过了再强调一次。不配的话Codex会把node_modules全部读进去第一次执行能卡五分钟。坑2第一次用别直接上核心模块先让Codex写测试、加注释、修lint。观察几次它的代码风格和你的项目是否契合再让它碰核心业务逻辑。坑3–approve模式适合个人项目团队慎用--approve模式下Codex会自动git commit。如果你在团队中工作建议关掉逐条确认改动codex --no-approveyour task here坑4大型重构分步来不要一条指令让它重构整个项目。拆成小步骤每一步验证后再继续。Codex虽然强但不是银弹。八、总结Codex CLI和Copilot/Cursor的本质区别前者是描述需求→AI执行后者是写代码→AI补全。交互范式完全不同。对于后端开发者尤其是日常大量CRUD、数据库迁移、测试编写这类重复性工作Codex CLI的效率提升是数量级的。工具在这里codex.ijinshan.com装好就能用。