🩺 摘要
📝 详情
Codex CLI实战：从代码补全到全自动重构，5个真实场景拆解
省流版： 上篇讲了Codex CLI的安装和基本用法。这篇深入到真实开发场景——写一个完整的REST API、做数据库迁移、批量修复lint错误、生成测试套件、跨分支代码迁移。每个场景都贴完整命令和结果。
场景一：从零生成一个完整的REST API
场景描述
你需要快速搭建一个用户管理微服务：注册、登录、CRUD、JWT鉴权。
操作
mkdir user-service && cd user-service
git init
codex exec --yolo "
创建一个基于FastAPI的用户管理服务：
- main.py：FastAPI应用入口
- models.py：SQLAlchemy User模型（username, email, password_hash, created_at）
- schemas.py：Pydantic请求/响应模型
- auth.py：JWT认证（注册、登录、token刷新）
- crud.py：用户CRUD操作
- database.py：数据库连接配置（SQLite用于开发）
- requirements.txt：所有依赖
- 测试文件用pytest
核心要求：
1. 密码用bcrypt加密存储
2. JWT token有效期24小时
3. 注册时邮箱唯一校验
4. 所有接口有类型注解
5. 用依赖注入管理数据库会话
"
结果
Codex CLI会生成大概7-8个文件，1000行左右代码。你用YOLO模式是因为——从头生成新项目，不用考虑兼容现有代码。
生成后直接用：
pip install -r requirements.txt
uvicorn main:app --reload
# 访问 http://localhost:8000/docs 查看API文档
场景二：大规模数据库迁移
场景描述
现有项目一直在用SQLite，是时候迁移到PostgreSQL了。涉及：修改连接配置、替换SQLite专属语法、迁移数据。
操作
codex exec "
把项目从SQLite迁移到PostgreSQL：
1. 修改database.py的数据库URL配置（使用DATABASE_URL环境变量）
2. 检查所有SQL查询，确保没有SQLite专属语法
3. 添加psycopg2到requirements.txt
4. 写一个数据迁移脚本migrate_data.py，从SQLite导出数据插入PostgreSQL
5. 更新.env.example加入DATABASE_URL配置
6. 更新README.md说明迁移步骤
约束：保持原有代码结构不变，只改必要的配置和兼容性问题
"
结果
Codex会：
- 自动识别项目中所有的SQLite相关代码
- 创建PostgreSQL兼容的配置
- 生成数据迁移脚本
- 更新文档
这也是Codex CLI的强项：跨文件的系统级修改。单单SQLite→PostgreSQL这个改动，涉及配置、查询语法、迁移脚本、文档——如果自己改，至少半小时到一小时。Codex几分钟搞定。
场景三：批量修复lint错误
场景描述
接手一个旧项目，200+个lint错误。手动改不现实。
操作
# 先看有多少lint问题
ruff check .
# 假设输出：Found 234 errors in 47 files
# 让Codex修
codex exec --full-auto "
用ruff检查当前项目的所有lint错误，逐个修复。
修复优先级：
1. 先修F错误（pyflakes，影响运行）
2. 再修E错误（pycodestyle风格）
3. 最后修I错误（import排序）
修复后运行 ruff check . 确认没有新问题
保持原有的逻辑不变，只改格式
"
注意
用--full-auto而不是默认模式，因为200+个lint错误逐个确认太浪费时间。但建议先看看lint类型——如果是逻辑问题（F错误），修完后git diff检查一下AI改对没有。
场景四：生成完整测试套件
场景描述
项目有代码但没有测试。你想在CI上线前，给核心模块补上测试。
操作
codex exec "
给我的项目写测试：
1. 检测当前项目使用的测试框架（pytest/unittest）
2. 如果没有，安装pytest并配置
3. 给src/core/目录下的所有模块写单元测试
4. 测试覆盖率目标80%以上
5. 使用mock隔离外部依赖（数据库、API调用）
6. 测试文件命名遵循 test_{module}.py
7. 运行 pytest --cov=src/core --cov-report=term 验证覆盖率
先给个计划，我确认后再执行
"
为什么先要计划
测试是最容易翻车的场景——AI生成的测试可能： - 测试了不存在的方法 - 用了错误的mock - 测试框架版本不兼容
让Codex先输出测试计划，你看一眼结构再确认，稳很多。
场景五：跨分支代码迁移
场景描述
你在feature-A分支上做了一个数据库重构，现在需要把这个改动迁移到feature-B分支上。
操作
# 先在feature-B分支上
git checkout feature-B
# 让Codex分析feature-A的改动并迁移
codex exec "
1. 先查看 feature-A 相对于 main 的改动：git diff main...feature-A
2. 分析这些改动的核心逻辑
3. 检查 feature-B 分支上是否有冲突的代码
4. 如果有冲突，给出迁移方案
5. 逐文件迁移核心逻辑（不要复制整个文件，只迁移关键改动）
6. 迁移后运行测试确认没有破坏现有功能
"
比手动强在哪？
手动跨分支迁移最怕的是：漏改依赖、漏改配置、漏改import。Codex会帮你检查这些潜在问题。
Codex CLI工作流总结
经过这几个场景，可以总结出一个通用的工作流：
简单任务（修bug、加小功能）
codex exec "具体描述" → review diff → confirm
中等任务（重构、加模块）
codex exec "先给计划" → 看计划 → codex exec "按计划执行" → review
复杂任务（架构改动、迁移）
codex exec --full-auto "分步骤执行" → git diff → 逐文件检查
安全建议
| 模式 | 适合场景 | 确认机制 |
|---|---|---|
| 默认模式 | 日常开发、修bug | 逐文件确认 |
| --full-auto | 批量修改、lint修复 | 改完后整体review |
| --yolo | 生成新项目、脚手架 | 看最终结果 |
不要对生产环境代码用YOLO模式。 这个原则能帮你在99%的情况下不翻车。
三个节省大量时间的小技巧
1. 用管道传递上下文
cat error.log | codex exec "根据错误日志修复代码"
让Codex直接看到报错信息，不用自己复制粘贴。
2. 指定关键文件
codex exec "分析性能瓶颈" -f app/core/database.py -f app/models/user.py
用-f手动指定文件，让Codex把注意力放在关键地方，节省token。
3. 分任务执行
不要一个会话里做太多事。code-review、写代码、改配置分成三个独立会话。这样做的好处：
- 每个会话的上下文更干净
- 中途出错了不会影响已完成的工作
- token消耗更可控
总结
Codex CLI不只是「在终端里帮你写代码」的工具。它的真正价值在于：
- 系统级修改——跨文件、跨模块的全量改动，Codex比人工更不容易漏
- 沙箱安全——改完后review再落地，不给生产环境添乱
- 文档即规范——AGENTS.md让团队编码规范自动贯彻到每个AI任务
五个场景覆盖了日常开发的绝大多数情况。记不住没关系——记住codex exec这个核心命令，其他都是锦上添花。
💡 建议收藏本文。 实战场景就是开发中的高频操作，遇到类似的直接回来抄命令。
📤 转发给朋友，他肯定会感谢你。 你的朋友如果还在手工迁移代码——让他看看场景五。
📚 AI编码工具系列 ← （一）Aider AI编程助手入门 · （二）Aider进阶 ← （三）Codex CLI入门教程 → （四）OpenCode vs Aider vs Claude Code：三款终端AI编程助手横评 → （五）AI代码文档自动生成指南 · （六）AI辅助代码迁移实战
💬 评论 (0)