第 3 卷

读懂一个陌生项目

使用 Codex 的第一步，不应该是让它直接写代码，而是让它先读项目。

它可以帮你快速搞清楚：

项目用什么技术栈。

入口文件在哪里。

核心模块在哪里。

测试和构建命令是什么。

哪些文件不能随便动。

很多 Codex 任务失败，不是因为它不会写代码，而是因为它还没理解项目，就被要求直接动手。

解释代码和梳理逻辑

Codex 可以帮你解释看不懂的代码。

比如：

这个函数是做什么的。

这个组件为什么这样写。

接口调用链路是什么。

状态从哪里来。

这个 bug 可能和哪些文件有关。

它不只是解释单个函数，还可以结合上下文，梳理模块关系、数据流和潜在风险。

这对接手旧项目尤其有用。

修 bug 和加功能

Codex 很适合处理边界清楚的开发任务。

比如：

修复一个可复现 bug。

新增一个设置页。

新增一个表单校验。

新增一个接口。

新增一个导出按钮。

优化一个前端页面。

1. 再出方案。
2. 只改一个模块。
3. 跑测试。
4. 看 diff。
5. 确认没问题后再继续。

Codex 更适合连续完成小任务，而不是一次吞下大项目。

写测试、做重构

Codex 可以帮你补测试，也可以帮你重构代码。

它可以做：

补单元测试。

补边界条件。

补异常场景。

提取重复逻辑。

拆分过长函数。

整理组件结构。

封装 API 请求。

但这类任务必须加边界：

不改业务逻辑。

不改公共 API。

不引入无关依赖。

不大范围重构。

修改后必须跑测试。

Codex 能重构，但你必须控制范围。

写文档和整理 PR

Codex 很适合写工程文档。

比如：

README。

安装说明。

项目结构说明。

PR 描述。

commit message。

更新日志。

文档不是附属品。

在 Codex 工作流里，文档本身就是上下文基础设施。

文档越清楚，后续人和 AI 接手项目都会更轻松。

但要提醒 Codex：

不要编造不存在的命令，不确定的信息要明确标注。

跑命令、看 diff、做 review

Codex 和普通聊天工具最大的区别之一，是它可以在项目环境里运行命令。

它可以：

运行测试。

运行 lint。

运行 typecheck。

运行 build。

查看 git status。

查看 git diff。

搜索代码。

检查修改结果。

这让 Codex 不只是“猜答案”，而是可以验证结果。

但命令执行也有风险。

能验证的，可以让它验证。

有风险的，必须由你批准。

涉及生产环境、数据库、真实用户数据的操作，不要交给它自动执行。

什么时候适合用 Codex

适合 Codex 的任务，一般有几个特点：