最近很多人开始用 Codex 写代码，尤其是用了 Cursor、Claude Code、Windsurf 之后，再看到 Codex，很容易把它也当成一个“更会写代码的聊天框”。

但我用下来发现，Codex 真正的价值不在于“问它代码问题”，而在于它可以进入项目目录，读取文件、理解上下文、修改代码、运行命令，再把改动结果展示出来。

换句话说，它更像一个能动手的编码助手，而不是单纯陪你聊天的 AI。

也正因为它能动手，所以新手第一次用 Codex，最重要的不是让它帮你做多大的功能，而是先建立一个安全使用习惯。

我的建议是：

先让它读项目，不要急着改；
先让它讲方案，不要直接动手；
每次只让它改一小块；
改完一定看 diff；
能跑测试就跑测试；
重要项目动手前先打 Git 检查点。

这篇文章就按新手视角，把 Codex 从入口选择、第一次任务、权限控制、提示词写法，到 Git 检查点和 AGENTS.md 的使用方式，完整梳理一遍。

一、先搞清楚：Codex 适合干什么？

Codex 最适合做的事情，不是“从零帮你写一个完整系统”。

它更适合处理那些和项目上下文强相关的任务。

比如：

看懂一个陌生项目；
解释目录结构；
找到入口文件；
根据报错定位问题；
做小范围 bug 修复；
补单元测试；
整理 README；
检查未提交改动；
辅助做 PR 代码评审。

它和普通聊天模型最大的区别是：普通聊天模型只能根据你贴出来的代码回答，而 Codex 可以直接在项目里看文件、改文件、跑命令。

比如你可以这样问：

请暂时不要修改任何文件，先帮我解释这个项目：
1. 项目主要是做什么的？
2. 技术栈是什么？
3. 主要目录分别负责什么？
4. 入口文件可能在哪里？
5. 本地运行大概需要哪些命令？
6. 哪些地方你不确定？请直接说不确定，不要猜。

这条提示词的重点是“暂时不要修改任何文件”。

第一次用 Codex，千万不要一上来就说：

帮我优化一下整个项目。

这种话范围太大，Codex 很容易改一堆你根本没准备审查的东西。

新手更稳的方式是：

先读项目；
再讲理解；
再给方案；
再做小改；
最后由人审查。

二、入口怎么选：App、IDE、CLI、Web 有什么区别？

Codex 有不同入口，新手最容易卡在这里：到底该用哪一个？

我的建议很简单：

刚开始用，优先选 App；
每天都在 VS Code、Cursor、Windsurf 写代码，可以用 IDE 扩展；
熟悉终端和 Git，再考虑 CLI；
涉及 GitHub PR、云端任务，再看 Web 或云端能力。

1. Codex App：适合新手建立完整流程

App 更像一个桌面工作台。
你可以选择项目文件夹，查看任务进展，审查代码改动，也比较适合新手建立“读项目—改代码—看 diff”的习惯。

第一次打开项目时，最好选一个练习项目，而不是直接打开公司的核心项目。

如果项目还不是 Git 仓库，建议先初始化一下：

git init
git status

至少这样你后面能看清楚 Codex 改了哪些文件。

2. IDE 扩展：适合日常写代码

如果你平时一直在编辑器里工作，IDE 扩展会比较顺手。

它适合边写边问，比如：

解释某个函数；
帮我看这段代码有没有问题；
帮我补一个测试；
帮我重构当前选中的函数；
检查当前文件的边界情况。

但新手不要一上来就开太高权限。

比较稳的顺序是：

先用 Chat，只问问题；
再用 Agent，让它做小范围修改；
最后才考虑 Full Access。

Full Access 不是不能用，而是要等你知道它可能改什么、会跑什么命令之后再用。

3. CLI：适合懂终端的人

CLI 很方便，但也更容易出问题。

因为它就在你的终端里工作，如果你当前目录选错了，Codex 可能就在错误的项目里动手。

所以每次开工前，我都会先跑：

pwd
git status

确认自己在哪个目录，当前工作区是不是干净的。

如果是 monorepo，一定要把范围写清楚：

本次只处理 packages/web 目录，不要修改 packages/api 和 packages/mobile。

这句话很重要。

不要默认 Codex 一定知道你的边界。

三、第一次任务，不要改代码

很多人第一次用 Codex，就想让它修 bug、加功能、重构代码。

我不建议这样。

第一次任务最好只读不改。

可以直接复制这段：

请暂时不要修改任何文件，先帮我理解这个项目：

1. 这个项目是做什么的？
2. 使用了什么技术栈？
3. 主要目录分别负责什么？
4. 入口文件在哪里？
5. 本地启动可能需要哪些命令？
6. 如果有不确定的地方，请明确说“不确定”，不要猜。

为什么要这样做？

因为你要先判断 Codex 是否真的理解了项目。

如果它连目录结构、技术栈、启动方式都说不清楚，你就让它改代码，风险会很高。

这一步还能顺便测试它有没有胡说。

比如项目里根本没有 Dockerfile，它却说“可以通过 Docker 启动”，那就说明它在凭经验猜。

这种情况就要马上收紧范围，让它说明依据：

请说明你是根据哪些文件判断启动方式的，不要根据经验推测。

四、第一个改动，建议只改 README

等 Codex 能正确解释项目后，再让它做第一个小改动。

我建议从 README 开始。

因为 README 风险低，而且很适合练习看 diff。

可以这样写：

请只修改 README.md，新增一节“新手如何启动这个项目”。

要求：
1. 不要修改任何其他文件。
2. 不要安装新依赖。
3. 不要改业务代码。
4. 如果项目里没有明确启动命令，请写“不确定”，不要编造。
5. 改完后告诉我具体修改了哪些内容。

这条提示词把范围限制得很窄。

如果 Codex 改了 README 之外的文件，你就能立刻发现。

改完之后，不要只看它的总结。

一定要看 Git 状态：

git status
git diff

看 diff 时重点看这几点：

它有没有只改允许的文件；
有没有新增陌生依赖；
有没有删除重要配置；
有没有把不确定内容写成确定结论；
有没有顺手改了一堆格式；
改动是不是符合你的目标。

新手不一定能看懂每一行代码，但至少要看懂：它动了哪些文件，动了多少，是否超范围。

五、修 bug 时，别只说“帮我看看”

很多人让 Codex 修 bug，提示词只有一句：

项目报错了，帮我看看。

这样效果通常不好。

因为它不知道你怎么复现，也不知道期望行为是什么。

更好的写法是：

我遇到了一个 bug，请帮我定位并修复。

现象：
[粘贴报错或异常行为]

复现步骤：
1. [第一步]
2. [第二步]
3. [第三步]

期望结果：
[正常情况下应该是什么样]

要求：
1. 先说明你判断的原因。
2. 做最小必要改动。
3. 不要在没问我之前新增依赖。
4. 修复后运行相关测试，或者说明为什么跑不了。
5. 最后列出改动文件和风险点。

这里最重要的是“复现步骤”。

你说得越具体，Codex 越不容易猜错方向。

还有一点：修 bug 要强调“最小必要改动”。

否则它可能顺手重构一堆代码，最后 bug 也许修了，但你很难审。

六、加功能时，要先让它给方案

如果是新增功能，不建议直接让 Codex 开改。

先让它给方案。

比如：

请帮我加一个小功能。

功能目标：
[描述功能]

范围：
可以修改：[文件或目录]
不要修改：[文件或目录]

要求：
1. 先给一个简短方案，不要马上改代码。
2. 每一步保持小改动。
3. 沿用现有代码风格。
4. 如果需要新依赖，请先停下来问我。
5. 完成后运行相关检查。

输出：
1. 改了哪些文件
2. 如何验证
3. 还有哪些需要我手工检查

等它给出方案后，你先看一眼。

如果方案明显太大，就让它拆小：

这个方案太大，请拆成 3 个独立小任务。我们先只做第一步。

和 Codex 协作，最怕一次性任务过大。

任务越大，它越容易自由发挥；任务越小，你越容易控制结果。

七、UI 任务最好配截图，并说明验收方式

如果你让 Codex 做前端页面，最好给截图或者设计稿。

提示词可以这样写：

请根据截图实现这个页面。

要求：
1. 使用项目现有技术栈。
2. 布局、间距、字号层级尽量贴近截图。
3. 不要在没问我之前引入新的 UI 库。
4. 只新增必要组件。
5. 完成后告诉我执行哪个命令、打开哪个地址查看效果。

还可以补充：

目标页面路由；
是否需要响应式；
是否支持深色模式；
是否必须沿用现有组件库；
主要检查哪些交互。

前端任务不要只看代码。
一定要跑起来看页面。

如果项目支持本地预览，可以让 Codex 完成后告诉你：

请告诉我：
1. 需要执行什么启动命令；
2. 本地访问哪个地址；
3. 我应该检查哪些页面和交互；
4. 如果无法打开或验证，请说明原因。

八、权限审批：不要机械点同意

Codex 能执行命令，所以审批一定要谨慎。

遇到命令审批时，不要无脑点同意。

尤其是这些命令要小心：

rm -rf
sudo
curl ... | sh
npm install some-package-you-do-not-understand

还有这些行为也要留意：

访问项目目录之外的文件；
修改系统目录；
下载并执行脚本；
批量删除文件；
修改锁文件但不解释原因；
修改环境变量或密钥文件。

如果你看不懂命令，就让它解释：

请解释这条命令要做什么，为什么必要，有没有更安全、范围更小的做法。

解释不清楚，就不要批准。

新手宁愿慢一点，也不要让 Codex 在你看不懂的情况下执行高风险命令。

九、敏感信息不要直接交给 Codex

很多人排查问题时，会把完整日志、配置文件、环境变量一股脑贴进去。

这很危险。

这些内容不要直接贴：

API Key；
数据库密码；
生产环境令牌；
Cookie；
客户隐私数据；
生产数据库连接串；
公司内部不允许外传的资料。

报错日志也要先看一眼。
很多日志里会带请求头、URL 参数、token 片段或数据库地址。

粘贴前先脱敏，比如：

DATABASE_URL=postgres://USER:PASSWORD@HOST:PORT/DB
API_KEY=YOUR_API_KEY

能让它看懂结构就够了，不需要给真实密钥。

十、重要项目动手前，先打 Git 检查点

这是我觉得最重要的一条。

在重要项目里用 Codex 前，先看当前状态：

git status

如果当前已经有改动，而且这些改动有价值，先提交一个检查点：

git add .
git commit -m "checkpoint before codex task"

然后再让 Codex 工作。

Codex 改完后，再看：

git status
git diff

如果不满意，可以回滚未提交改动：

git restore .

如果你还不熟 Git，那就先不要在重要项目里练 Codex。
先找一个练习仓库，把“改动—diff—回滚”这套流程练熟。

一句话：没有 Git 检查点，就不要让 Codex 在重要项目里大范围改代码。

十一、AGENTS.md：把项目规矩写给 Codex 看

如果你经常在同一个项目里用 Codex，可以在项目根目录放一个 AGENTS.md。

可以把它理解成写给编码智能体看的项目说明书。

里面可以写：

启动命令；
测试命令；
构建命令；
lint 命令；
代码风格；
禁止修改的目录；
是否允许新增依赖；
公共 API 修改规则；
最终总结格式。

比如：

# AGENTS.md

## 项目约定

- 修改 JavaScript 文件后，请运行 npm test。
- 在用户确认之前，不要新增生产依赖。
- 不要修改 generated 目录下的文件。
- 修改公共工具函数时，需要同步更新相关测试。
- 最终总结里，请列出改动文件、验证情况和风险点。

什么时候该写 AGENTS.md？

我的判断标准是：

当你第二次提醒 Codex 同一件事，就该写进 AGENTS.md。

比如你每次都说“不要新增依赖”，那就写进去。
比如你每次都说“不要改 generated 目录”，也写进去。
比如团队里多人都用 Codex，那更应该写进去。

这样能减少重复沟通，也能让团队使用规则更一致。

十二、给新手的一套 7 天练习路线

如果你是第一次用 Codex，不要一上来挑战复杂项目。

可以按 7 天练习。

第 1 天：只读项目

请不要修改任何文件。解释这个项目是做什么的、目录结构是什么、入口在哪里、怎么运行。

目标：让 Codex 读懂项目，你也熟悉它的表达方式。

第 2 天：整理项目概览

基于你对项目的理解，起草 docs/project-overview.md。

要求：
1. 面向新手。
2. 说明主要目录和启动步骤。
3. 不要修改任何代码文件。

目标：练习低风险文档任务。

第 3 天：只改 README

请只修改 README.md，加上安装和启动说明。不要修改任何其他文件。

目标：练习看 diff。

第 4 天：修一个小 bug

报错如下：
[粘贴报错]

复现步骤：
1. [第一步]
2. [第二步]
3. [第三步]

请找出原因，并做最小修复。修完后运行相关检查。

目标：学会描述问题，而不是只说“跑不起来”。

第 5 天：补一个测试

请为刚才修复的问题补一个最小测试。

要求：
1. 先讲清楚这个测试覆盖什么。
2. 不要顺手做大改动。
3. 完成后把测试跑一遍。

目标：让 Codex 不只写代码，也帮助验证代码。

第 6 天：评审未提交改动

请评审当前未提交的改动。

关注：
1. 明显 bug
2. 边界情况
3. 回归风险
4. 是否需要补测试

暂时不要修改文件，只输出评审意见。

目标：把 Codex 当成第二双眼睛。

第 7 天：尝试隔离分支

请在隔离分支里尝试实现下面这个小功能：

[功能描述]

要求：
1. 先给方案。
2. 改动保持小。
3. 完成后说明如何验证。

目标：练习在安全环境里做更复杂的任务。

十三、常见问题

1. 不会写代码，可以用 Codex 吗？

可以，但不要从高风险任务开始。

推荐顺序是：

解释项目；
整理文档；
看懂报错；
修改 README；
修小 bug；
补测试；
做小功能。

不要一上来让它做完整系统，也不要让它操作生产环境。

2. Codex 改错了怎么办？

先看 diff。

如果只是小问题，可以继续让它调整：

你刚才修改了不该动的文件。请撤回这些文件的改动，只保留 README.md 的修改。

如果已经改乱，用 Git 回滚：

git restore .

如果你不熟悉 Git，先在练习项目里使用。

3. Codex 总是改太多怎么办？

通常是你的提示词范围太宽。

改成这样：

本次只允许修改 src/utils/date.ts。
不要修改其他文件。
不要新增依赖。
先给方案，等我确认后再改。

范围越清楚，结果越可控。

4. 它编造启动命令怎么办？

让它说依据。

如果项目里没有明确写启动命令，请直接说“不确定”，不要根据经验编造。
请说明你是根据哪些文件判断启动命令的。

常见依据一般是：

package.json；
README.md；
Makefile；
Dockerfile；
docker-compose.yml；
.github/workflows；
pyproject.toml；
pom.xml。

没有依据，就不要信。

结语：Codex 好不好用，关键看你会不会控范围

Codex 不是魔法，也不是万能程序员。

它真正适合的使用方式，是在清晰边界里帮你完成具体任务：

读项目；
找问题；
做小改；
补测试；
看 diff；
做评审。

新手不要追求“一句话做完整项目”。

先把这条链路跑顺：

读项目 → 小改动 → 看 diff → 跑测试 → 人工确认

等你能稳定控制这套流程，再去尝试 Worktree、CLI、云端任务和 PR 评审。

如果你是第一次用 Codex，就从这条提示词开始：

请暂时不要修改任何文件。请用中文解释这个项目的结构、技术栈、入口文件、运行方式和不确定点。

能安全地用，才是真的会用。