小白也能学会的Codex 入门教程

我给所有 Codex 小白写一篇真正能上手的入门教程。

不讲玄学，不堆术语，只讲一个普通人怎么从 0 开始，用 Codex 帮你读代码、改代码、修 bug、写功能。

1. Codex 是什么？

一句话：

Codex 是 OpenAI 的“代码智能体”。

它不是普通聊天机器人，也不是只会补全几行代码的插件。

更准确地说，它像一个可以参与项目的 AI 程序员。你可以把一个任务交给它，比如：

“帮我看懂这个项目” “帮我修复这个报错” “帮我新增登录页” “帮我给这个接口写测试” “帮我重构这段代码” “帮我审查这次改动有没有问题”

它会读取你的代码结构，理解上下文，提出计划，修改文件，运行命令，甚至帮你解释为什么这样改。

小白最应该先记住一句话：

不要把 Codex 当“搜索引擎”用，要把它当“初级结对程序员”用。

你负责说清楚目标、检查结果、决定是否采纳；Codex 负责帮你读、写、改、查、跑。

2. Codex 适合谁？

我觉得最适合这几类人：

第一类：刚学编程的人。

你看不懂项目结构，不知道某个函数从哪里来，不知道报错是什么意思。Codex 可以帮你用人话解释代码。

第二类：会一点代码，但不熟悉工程项目的人。

你可能会写 Python、JS、HTML，但一打开真实项目就懵了。Codex 可以带你梳理目录、依赖、启动方式和主要逻辑。

第三类：想提高效率的开发者。

重复写 CRUD、改样式、补测试、修 lint、迁移配置，这些任务很适合交给 Codex。

第四类：独立开发者。

一个人做产品时，最缺的是搭档。Codex 可以临时充当“代码搭子”。

3. 新手最推荐从哪里开始？

如果你是纯小白，我建议按这个顺序：

• 先用 Codex 读代码

• 再让 Codex 小范围改代码

• 再让它修 bug

• 最后再让它写完整功能

不要一上来就说：

“帮我做一个完整 SaaS。”

这类需求太大，小白也很难判断它做得对不对。

正确姿势是：

“先解释项目结构。” “再告诉我启动方式。” “再找一个最小功能点修改。” “再让我看 diff。” “再运行测试。”

一步一步来，才安全。

4. 使用前要准备什么？

你至少需要：

• 一个 ChatGPT / OpenAI 账号

• 一个代码项目

• 一个本地开发环境

• 最好会一点 Git 基础

如果你还不会 Git，先记住 3 个命令就够：

git status git diff git checkout -b codex-test

解释一下：

jsongit status：看哪些文件变了 git diff：看具体改了什么 git checkout -b codex-test：新建一个分支，避免污染主分支

新手一定要养成习惯：

不要直接在主分支让 AI 大改代码。

先开分支，改完检查，没问题再合并。

5. Codex 有哪些常见使用方式？

常见入口大概有几种：

第一种：Codex App 适合喜欢图形界面的人。你可以在应用里管理多个任务，看 Codex 的进度和改动。

第二种：Codex CLI 适合习惯终端的人。你在项目目录里打开终端，输入 codex，它就可以读取当前项目。

第三种：IDE 插件 适合在 VS Code、Cursor、Windsurf 这类编辑器里边写边问。

第四种：Codex Web 适合把任务交给云端环境，尤其是结合 GitHub 仓库做任务、提 PR、审查代码。

小白怎么选？

如果你是完全新手：先用 App 或 IDE 插件。 如果你会用终端：直接学 CLI。 如果你有 GitHub 项目：再尝试 Codex Web。

6. Codex CLI 小白安装流程

以 macOS / Linux 为例，官方安装方式通常类似：

jsoncurl -fsSL https://chatgpt.com/codex/install.sh | sh

安装后，在终端输入：

jsoncodex

第一次运行时，它会提示你登录 ChatGPT 账号或使用 API key。

登录完成后，进入你的项目目录：

jsoncd your-project codex

这时你就可以开始和它对话了。

如果你是 Windows 用户，建议优先看官方 Windows 指南，或者用 WSL2 搭一个 Linux 风格开发环境。

7. 第一次用 Codex，别急着让它改代码

第一次打开项目，我建议先发这条：

请先不要修改任何文件。请阅读这个项目，告诉我：

1. 这个项目是做什么的
2. 主要目录结构是什么
3. 启动项目需要哪些命令
4. 新手应该从哪些文件开始看
5. 你建议我下一步做什么

为什么要加“不要修改任何文件”？

因为小白第一次使用，最重要的是先建立信任和理解。你要先看它能不能正确读懂项目，而不是直接让它乱改。

如果它解释得靠谱，再继续下一步。

8. 让 Codex 帮你看懂代码

你可以这样问：

请解释 src/main.ts 的作用。要求：

1. 用小白能听懂的话解释
2. 说明每个主要函数在做什么
3. 标出我需要重点理解的 3 个概念
4. 不要修改代码

或者：

请帮我画出这个请求从前端到后端的执行流程。不要改代码，只解释。

再或者：

我看不懂这个报错，请结合项目代码解释原因，并告诉我可能涉及哪些文件。先不要修改。

新手阶段，Codex 最有价值的能力不是“写代码”，而是“读代码 + 解释代码”。

9. 让 Codex 小范围修改代码

当你准备让它改代码时，千万不要说得太大。

不要这样说：

帮我优化整个项目。

这太泛了。

应该这样说：

请只修改登录页的按钮文案：

1. 把 “Submit” 改成 “登录”
2. 不要改其他样式
3. 修改前先告诉我你准备改哪个文件
4. 修改后展示 diff

或者：

请帮我给用户列表页面增加一个空状态：

1. 当用户数组为空时，显示“暂无用户”
2. 不要影响已有列表渲染
3. 尽量少改代码
4. 修改后说明你改了什么

关键点：

目标要具体。 范围要小。 限制要明确。 结果要可检查。

10. 让 Codex 修 bug 的正确姿势

很多小白会直接丢一句：

帮我修一下。

这不够。

更好的写法：

我运行 npm run dev 后遇到这个错误：

【粘贴报错】

请你：

1. 先解释这个错误是什么意思
2. 找出最可能的原因
3. 告诉我你准备检查哪些文件
4. 先不要修改代码，等我确认

如果你愿意让它直接修，可以这样：

请修复这个报错。要求：

1. 尽量最小改动
2. 不要重构无关代码
3. 修改后运行相关测试或启动命令
4. 给我总结修改原因

修 bug 的核心是：

先定位，再改动，再验证。

不要让 Codex 在没有边界的情况下大面积修改。

11. 让 Codex 写功能的标准提示词

这是一个比较通用的模板：

请为这个项目新增【功能名称】。

背景： 【这里说明这个功能要解决什么问题】

需求：

1. 【需求 1】
2. 【需求 2】
3. 【需求 3】

限制：

1. 尽量遵循当前项目代码风格
2. 不要引入不必要的新依赖
3. 不要修改无关文件
4. 如果有不确定的地方，先列出来再动手

完成后请：

1. 总结改了哪些文件
2. 展示关键 diff
3. 说明如何测试
4. 如果测试失败，说明失败原因

示例：

请为这个 Todo 项目新增“按完成状态筛选”的功能。

需求：

1. 增加 All / Active / Completed 三个筛选项
2. 默认显示 All
3. 点击 Active 只显示未完成任务
4. 点击 Completed 只显示已完成任务

限制：

1. 不要改动数据结构
2. 不要引入新 UI 库
3. 保持当前样式风格

完成后请说明如何手动测试。

12. 一定要学会看 diff

Codex 改完代码后，你不要直接接受。

你至少要看 3 件事：

第一，看它改了哪些文件。

jsongit status

第二，看它具体改了什么。

jsongit diff

第三，运行项目或测试。

jsonnpm test npm run dev pytest go test ./…

不同项目命令不一样，但原则一样：

AI 写完不等于完成。 跑得通、逻辑对、改动小，才算完成。

13. 新手一定要避免的 7 个坑

坑 1：一上来就让它重构整个项目。

重构范围越大，你越难检查。

坑 2：不看 diff 就接受。

这是最危险的习惯。

坑 3：把密钥、密码、token 直接贴给它。

不要把敏感信息发给任何 AI 工具。需要调试时，用假数据或脱敏数据。

坑 4：让它删除大量代码但不确认。

涉及删除、迁移、数据库操作，一定要先让它解释计划。

坑 5：不给上下文。

你只说“报错了”，它不一定能判断。最好贴完整报错、复现步骤、预期结果。

坑 6：同时交给它多个目标。

比如“顺便优化样式、修 bug、加登录、重构目录”。这会让任务失控。

坑 7：迷信 AI 结果。

Codex 很强，但它仍然可能误判。最终负责的人永远是你。

14. 推荐新手使用的固定工作流

我建议你每次都按这个流程：

第一步：创建分支

jsongit checkout -b codex-task

第二步：让 Codex 先读项目，不改代码

请先理解这个项目，并告诉我你会如何完成任务，暂时不要改文件。

第三步：确认方案

如果方案靠谱，再说：

可以开始实现。请保持最小改动，并在完成后总结 diff。

第四步：检查改动

jsongit status git diff

第五步：运行测试

jsonnpm test

或者运行项目：

jsonnpm run dev

第六步：让 Codex 复盘

请总结这次修改：

1. 改了什么
2. 为什么这么改
3. 如何测试
4. 还有哪些潜在风险

这个流程非常适合小白。

15. 给 Codex 写项目说明：AGENTS.md

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

你可以把它理解成“写给 AI 程序员的项目说明书”。

里面可以写：

markdown# AGENTS.md

项目说明

这是一个 Next.js 项目，用于管理个人任务。

常用命令

• 安装依赖：npm install
• 本地启动：npm run dev
• 运行测试：npm test
• 检查格式：npm run lint

代码风格

• 使用 TypeScript
• 组件使用函数组件
• 不要引入新的 UI 库，除非用户明确要求
• 修改前优先保持最小改动

注意事项

• 不要修改 .env 文件
• 不要提交 node_modules
• 涉及数据库迁移时，先解释方案再执行

有了这个文件，Codex 更容易按你的项目规则办事。

16. 小白最实用的 20 条提示词

• 请先不要修改代码，帮我解释这个项目结构。

• 请告诉我这个项目如何启动，本地需要哪些依赖。

• 请用小白能懂的话解释这个文件的作用。

• 请解释这个函数的输入、输出和核心逻辑。

• 请帮我找出这个报错最可能的原因，先不要改代码。

• 请最小改动修复这个 bug，并说明修改原因。

• 请只修改这个组件，不要影响其他文件。

• 请帮我给这个函数补充单元测试。

• 请审查这次 diff，看看有没有潜在 bug。

• 请把这段代码改得更易读，但不要改变行为。

• 请帮我找出这个页面数据是从哪里来的。

• 请列出完成这个功能需要修改的文件，先不要动手。

• 请给我一个实现计划，我确认后再开始写代码。

• 请根据当前项目风格实现，不要引入新依赖。

• 请修改后运行测试，并告诉我测试结果。

• 请解释这次修改的 diff。

• 请检查有没有安全风险，比如泄露 token、SQL 注入、XSS。

• 请把这个复杂函数拆成更小的函数，并保持测试通过。

• 请帮我写 README 的快速开始部分。

• 请像代码审查员一样，指出这段代码最值得改进的 5 个地方。

17. 一个完整案例：让 Codex 修一个前端 bug

假设你的页面按钮点击后没反应。

你可以这样问：

当前项目中，点击登录按钮没有反应。

请你：

1. 找到登录按钮对应的组件
2. 检查点击事件是否绑定
3. 检查请求函数是否被调用
4. 先总结问题原因
5. 暂时不要修改代码

Codex 分析后，如果你觉得合理，再继续：

请按你刚才的分析修复这个问题。要求：

1. 最小改动
2. 不要改 UI 样式
3. 修改后说明涉及文件
4. 告诉我如何手动验证

它完成后，你做检查：

git diff npm run dev

打开页面，手动点按钮验证。

最后让它复盘：

请总结这次 bug 的原因、修复方式，以及以后如何避免。

这样你不仅修了 bug，还学到了知识。

18. 一个完整案例：让 Codex 新增功能

比如你要给博客项目增加搜索框。

提示词可以这样写：

请为当前博客项目新增文章搜索功能。

需求：

1. 在文章列表页顶部增加搜索框
2. 输入关键词后，按标题和摘要过滤文章
3. 没有结果时显示“没有找到相关文章”
4. 搜索逻辑在前端完成，不需要新增后端接口

限制：

1. 保持当前 UI 风格
2. 不要引入新依赖
3. 不要改动文章数据结构
4. 尽量只修改文章列表相关文件

完成后：

1. 总结修改文件
2. 说明如何测试
3. 提醒我可能的边界情况

这个提示词好在哪里？

它说明了页面位置、功能逻辑、空状态、技术限制、改动范围和验收方式。

Codex 最怕的是“你自己也不知道想要什么”。

你越具体，它越靠谱。

19. Codex 不是替你思考，而是放大你的思考

很多新手会有一个误区：

“有了 Codex，我是不是不用学编程了？”

不是。

更准确地说：

你仍然要学基础概念，比如变量、函数、组件、接口、数据库、Git、测试。

但 Codex 可以让你学习速度变快。

以前你看不懂一个项目，可能卡一天。 现在你可以让它逐文件解释。

以前你修一个报错，要到处搜。 现在你可以让它结合项目上下文定位。

以前你不敢改代码。 现在你可以让它先给计划，再小步修改。

它不是让你跳过学习，而是让你在真实项目里边做边学。

20. 我建议小白用 3 天入门 Codex

第一天：只读不改。

任务：

• 让 Codex 解释项目结构

• 让 Codex 解释 3 个核心文件

• 让 Codex 告诉你项目启动方式

• 让 Codex 画出一个功能流程

目标： 你能说清楚这个项目大概怎么跑。

第二天：做小修改。

任务：

• 改一个按钮文案

• 改一个页面空状态

• 改一个 README

• 补一个简单测试

目标： 你会看 git diff，知道 AI 改了哪里。

第三天：修 bug 或加小功能。

任务：

• 修一个明确报错

• 新增一个小功能

• 让 Codex 运行测试

• 让 Codex 做代码审查

目标： 你形成“计划 → 修改 → 检查 → 测试 → 复盘”的闭环。

21. 我的最终建议

如果你是 Codex 小白，记住这 5 条就够了：

• 先让它解释，不要急着让它改。

• 任务越小，结果越靠谱。

• 每次修改前先开 Git 分支。

• 每次修改后必须看 diff。

• 不要贴密钥，不要盲信结果。

Codex 真正厉害的地方，不是“帮你少写几行代码”。

而是它能把你从“一个人对着项目发呆”，变成“有人和你一起读代码、拆任务、试方案、跑测试”。

对于小白来说，这才是最大的价值。

建议你第一次使用时，不要做大项目。

就找一个小项目，然后对 Codex 说：

请先不要修改代码，带我读懂这个项目。

这句话，就是最好的开始。