外观
第10章 实战案例
约 3636 字大约 12 分钟
2026-06-09
这一章来聊聊几个我用 Codex 做过的实际案例，从零搭项目到修 Bug 到写文档，看完你就知道 Codex 到底能帮你干啥了。不吹牛，都是真事儿。
案例1：从零开始搭一个新项目
事情是这样的
假设你想做一个简单的待办事项（Todo）应用，前后端都要有，但不知道从哪下手。
怎么做？
第1步：建个文件夹，进到里面
mkdir my-todo-app && cd my-todo-app
git init第2步：告诉 Codex 你想要啥
codex然后输入：
帮我从零创建一个待办事项应用。要求：
1. 前端用 React + TypeScript
2. 后端用 Node.js + Express
3. 数据先用内存存储（不用数据库）
4. 功能：添加、删除、标记完成、查看列表
5. 界面简洁就行，不用太花哨第3步：Codex 先规划，你看看行不行
Codex 会给你一个方案：
Codex：计划这样实现：
1. 项目结构：
- client/ — React 前端
- server/ — Express 后端
- package.json — 项目配置
2. 后端 API：
- GET /api/todos — 获取列表
- POST /api/todos — 添加待办
- PUT /api/todos/:id — 更新状态
- DELETE /api/todos/:id — 删除
3. 前端页面：
- 输入框 + 添加按钮
- 待办列表展示
- 每项可标记完成、可删除你觉得方案没问题，让它开始干。
第4步：Codex 动手干活
它会自动创建文件、写代码、装依赖，一步一步搞定。你只需要在它问"可以改这个文件吗"的时候点确认就行。
第5步：看看效果，调整细节
# Codex 装完依赖后帮你启动
npm run dev打开浏览器看看效果。觉得哪里不满意就继续跟 Codex 说：
列表项之间加点间距，完成的项目用灰色显示加删除线加一个过滤功能，可以看"全部"、"未完成"、"已完成"这个案例的关键收获
| 要点 | 啥意思 |
|---|---|
| 描述要具体 | 说清楚用什么技术、要什么功能，别只说"做一个应用" |
| 先看方案再执行 | 让 Codex 先出计划，你确认了再让它动手 |
| 分步调整 | 第一次做出来的东西肯定不完美，一点点调就好 |
| 用 Git 管理 | 每个大改动之前先 commit，出问题可以回退 |
案例2：程序报错了，帮我修
事情是这样的
你的项目突然跑不起来了，控制台报了一堆红字，看半天也不知道问题在哪。
怎么做？
第1步：启动 Codex
cd /你的项目路径
codex第2步：把报错信息直接扔给 Codex
运行项目的时候报错了，错误信息如下：
TypeError: Cannot read properties of undefined (reading 'map')
at TodoList (src/components/TodoList.jsx:15:22)
at renderWithHooks (node_modules/react-dom/.../react-dom.js:16175:18)第3步：Codex 帮你分析
Codex 会告诉你是怎么回事：
问题在 TodoList.jsx 第15行：
你用了一个可能是 undefined 的变量调了 .map()。
这说明传给 TodoList 组件的 todos 属性没有正确传入。
可能的原因：
1. 父组件没有传 todos 属性
2. API 返回的数据结构不对
3. 初始值设成了 undefined 而不是 []第4步：让 Codex 帮你修
帮我修一下这个问题，确保 todos 为空的时候也不会报错Codex 会直接帮你改代码。加个默认值、加个空值检查，几分钟搞定。
第5步：再跑一次确认
再跑一下看看修好没这个案例的关键收获
- 把完整的错误信息贴给 Codex，越完整越好，包括文件名和行号
- 别只说"报错了"——说清楚你做了什么操作、期待什么结果、实际出了什么错
- 修完了让 Codex 再跑一遍确认，别光看它说修好了就信了
提示
遇到错误的时候，千万别自己瞎猜。把错误信息完整地贴给 Codex，它定位问题的速度比你自己搜 Google 快多了。
案例3：让 Codex 帮忙写文档
事情是这样的
项目写完了，但是文档为零。老板催着要，自己又不想花时间写。咋办？让 Codex 来。
怎么做？
第1步：启动 Codex
cd /你的项目路径
codex第2步：告诉 Codex 你要什么文档
帮我给这个项目写一份 README.md 文档。要求：
1. 项目简介——这个项目是干什么的
2. 技术栈——用了哪些技术
3. 安装和启动步骤——让新人能跑起来
4. 项目结构说明——每个目录是干啥的
5. API 文档——每个接口的用法
6. 常见问题——可能会遇到的坑
用中文写，简洁明了第3步：Codex 自己读代码然后写文档
Codex 会先扫描你的项目，看看都有什么文件、用了什么技术、怎么启动的，然后自动生成文档。
第4步：检查一下，改改细节
API 文档部分加上请求和响应的示例常见问题部分加一条：怎么解决端口被占用的问题用 codex exec 也行
如果你不想聊天，一行命令搞定：
codex exec -o README.md "为这个项目生成一份中文 README 文档"直接把结果写到 README.md 里，省事。
这个案例的关键收获
| 要点 | 啥意思 |
|---|---|
| 说清楚文档要包含哪些部分 | 不然 Codex 可能只写个简单的介绍 |
| 生成后要检查 | Codex 写的文档整体质量不错，但细节可能需要你调整 |
用 -o 参数直接输出到文件 | 比复制粘贴方便 |
| 让它写示例代码 | 文档里光有说明没有示例，别人看了还是不会用 |
案例4：用 Codex 做代码审查
事情是这样的
写完了一段新功能，想让别人帮忙看看代码有没有问题。但同事都忙着呢，等不了。让 Codex 先审查一遍。
怎么做？
第1步：让 Codex 看看你改了啥
cd /你的项目路径
codex帮我审查一下最近改动的代码，关注以下几点：
1. 有没有安全漏洞
2. 有没有性能问题
3. 有没有逻辑错误
4. 命名和代码风格规不规范
5. 有没有边界情况没处理的第2步：Codex 给你审查报告
Codex 会给你一份详细的审查报告：
审查结果：
🔴 严重问题（2个）：
1. 第42行：SQL 查询用字符串拼接，存在 SQL 注入风险
建议：改用参数化查询
2. 第78行：用户密码明文存储
建议：使用 bcrypt 加密后存储
🟡 需要注意（3个）：
1. 第15行：循环里做了重复的数据库查询，建议缓存
2. 第33行：错误处理只用了 console.log，建议用日志系统
3. 第56行：魔法数字 86400，建议定义常量 SECONDS_PER_DAY
🟢 好的地方：
1. 函数命名清晰，一看就知道干啥的
2. 代码结构合理，模块划分得当第3步：让它帮你修
把标红的那两个严重问题修一下Codex 会直接帮你改好。
也可以用 codex exec 一行命令审查
# 审查当前分支相对于 main 的所有改动
codex exec "对比 main 分支，审查所有改动，用中文列出问题"这个案例的关键收获
- 让 Codex 先做初审，人做终审——效率最高
- 审查的时候说清楚关注什么（安全、性能、风格...），不然它可能抓不住重点
- Codex 标红的要仔细看，标黄的可以选择性处理
案例5：重构一个老项目
事情是这样的
接手了一个老项目，代码写得那叫一个乱——重复代码到处都是，函数一个比一个长，命名也看不懂。想整理但不知道从哪下手。
这是所有案例里最复杂的一个，咱们画个流程图看看怎么做。
怎么做？
第1步：让 Codex 先摸摸底
先帮我分析一下这个项目的代码质量。告诉我：
1. 大概有多少文件、多少行代码
2. 代码结构合不合理
3. 最需要重构的部分是什么
4. 有哪些明显的问题（重复代码、过长函数、嵌套太深等）Codex 会给你一份"体检报告"。
第2步：制定重构计划
根据分析结果，给一个重构计划。注意：
1. 每次只重构一个模块
2. 每次重构完都要确保功能不变
3. 先从最简单的开始，复杂的放后面第3步：一个模块一个模块来
从第一个模块开始重构重构完了：
跑一下测试确认功能没变没问题就 commit，然后继续下一个。
第4步：让 Codex 总结
帮我总结一下这次重构做了哪些改动，改了多少文件、多少行代码这个案例的关键收获
- 先分析再动手 —— 别上来就改，先让 Codex 给你一个全局分析
- 小步前进 —— 一次改一点，改完验证，别一口气改几十个文件
- 每步都 commit —— 出问题可以回退
- 先简单后复杂 —— 先搞定容易的建立信心，复杂的后面慢慢来
- 有测试才放心 —— 没有测试的项目，先让 Codex 帮你补测试再重构
注意
重构老项目是最容易翻车的场景。一定要用 Git 管理好每个版本的改动。改一个模块 commit 一次，千万别改了一堆东西都不保存。
案例6：写一个数据处理脚本
事情是这样的
你有一堆数据需要处理——比如把一个 CSV 文件里的数据清洗一下，汇总统计后生成报表。手动搞要半天，写个脚本几分钟就跑完。
怎么做？
第1步：把数据文件放到项目目录里
mkdir data-scripts && cd data-scripts
# 把你的 CSV 文件放进来
cp ~/Downloads/sales-data.csv .
git init第2步：告诉 Codex 你想干啥
codex帮我写一个 Python 脚本处理 sales-data.csv。需求：
1. 读取 CSV 文件
2. 清洗数据：去掉重复行、处理空值、修正格式
3. 按月份汇总销售额
4. 按产品类别统计销售数量
5. 生成一个汇总报表，保存为 Excel 文件
6. 生成一个简单的文字版统计摘要第3步：Codex 写脚本
它会自动创建一个 Python 脚本，包含数据读取、清洗、统计、输出的完整流程。
第4步：跑一下看看
跑一下这个脚本看看结果对不对第5步：调整
汇总报表里加一列"同比增长率"，跟去年同期对比空值的处理改成用上一行的值填充，不要直接删掉这个案例的关键收获
- 数据处理的脚本特别适合让 Codex 写——逻辑明确，输入输出清晰
- 说清楚数据格式（CSV 的列名、数据类型等），Codex 写得更准
- 让 Codex 跑一次看看结果，比你自己检查更快
- 数据量大的时候，让 Codex 帮你优化性能（比如用 pandas 代替循环）
我的真实感受
用 Codex 做了这么多实际项目之后，有几个真切的感受想分享一下：
做得好的
- 从零搭项目：Codex 真的能帮你从一片空白搭出一个能跑的项目，这点确实厉害
- 修 Bug：只要你能把错误信息描述清楚，Codex 定位问题又快又准
- 写文档：以前最讨厌写文档了，现在让 Codex 生成个初稿，自己再改改，轻松多了
- 代码审查：相当于多了一个特别认真的同事帮你 review 代码
做得一般的
- 老项目重构：能做，但需要你一步步引导。Codex 对项目上下文的理解还是有限的，特别是那种业务逻辑很复杂的项目
- 性能优化：它能给出一些常规建议，但真正深入的性能调优还是得靠人
- 创意性的工作：比如设计一个全新的架构方案，Codex 更像是执行者而不是创意者
最重要的一条经验
你描述需求越清楚，Codex 给你的结果就越好。 这是一句废话，但是是实话。别嫌麻烦，多说两句，把背景、目标、限制条件都说清楚。花两分钟描述需求，省下两小时改来改去。
小结
六个案例的要点总结：
| 案例 | 干了啥 | 核心收获 |
|---|---|---|
| 从零搭项目 | 用 Codex 创建完整的 Todo 应用 | 描述要具体，先看方案再执行 |
| 修 Bug | 贴报错信息让 Codex 定位修复 | 完整的错误信息是关键 |
| 写文档 | 让 Codex 扫描项目自动生成文档 | 说清楚要包含哪些章节 |
| 代码审查 | Codex 自动审查 PR | 说清楚关注点，先机器审后人审 |
| 重构老项目 | 一步步引导 Codex 重构 | 小步前进，每步 commit |
| 数据脚本 | 写数据清洗和统计脚本 | 输入输出描述清楚就行 |
怎么描述需求更有效？
| 不太好的说法 | 更好的说法 |
|---|---|
| "帮我写个东西" | "帮我用 Python 写一个 CSV 数据清洗脚本，处理空值用前一行填充" |
| "这里报错了" | "运行 npm start 时报了 TypeError: Cannot read properties of undefined，完整错误如下..." |
| "优化一下" | "这个接口在1000条数据时响应要5秒，帮我优化到1秒以内" |
| "改一下代码" | "把 utils.js 里的 formatDate 函数改成支持中文日期格式输出" |
提示
一句话总结：越具体越好。 告诉 Codex 文件在哪、问题是什么、你期望的结果是什么。模糊的指令只会得到模糊的结果。
下一章来聊聊一些进阶玩法和我踩过的坑，帮你少走弯路：第11章 一些进阶玩法和踩坑经验