《8000字讲透 ｜ Codex零基础入门教程》

本《Codex零基础入门教程》保证你和你的兄弟姐妹都能看懂，只要小学毕业就能看明白。这不是功能词典，而是一名普通学习者从第一次打开 Codex，到真正让它完成一个可验收任务的完整路线，以最通俗易懂的语言传递给你。建议您先收藏，后边慢慢看！

第一次打开 Codex 时，我犯的错误和很多人一样：把它当成一个“更会写代码的 ChatGPT”。我在输入框里写了一句“帮我做一个网站”，然后盯着它生成文件。几分钟后页面确实能打开，但按钮有的不能点，移动端会溢出，刷新后数据消失，我也不知道它改了哪些文件。

那一刻我才明白：会生成代码，不等于会交付项目。 Codex 真正厉害的地方，不是某一次回答写得多漂亮，而是它能进入一个真实项目，读取文件、理解约束、修改代码、运行命令、检查结果，再根据反馈继续迭代。它更像一个能操作电脑和项目环境的执行者，而不是只在聊天框里给建议的问答机器人。

这也意味着，使用 Codex 的门槛并不只是“会不会写提示词”。你还要学会给它正确的工作目录、合适的权限、足够但不过量的上下文，以及明确的验收标准。只要这四件事没处理好，再强的模型也可能在错误方向上跑得很快。

这篇教程不要求你是程序员。你只需要会创建文件夹、安装软件、复制命令，并愿意在每一步查看结果。我会用一个“个人任务看板”作为练习项目，把安装、第一次对话、需求拆解、修改文件、运行测试、代码审查、长期规则和重复工作复用全部串起来。跟着做完，你得到的不只是一个 Demo，而是一套以后做网页、自动化脚本、数据工具和 AI 产品都能复用的方法。

一、先理解 Codex：它不是“替你写几段代码”，而是替你完成一段工作循环

过去我使用普通 AI 编程工具时，流程通常是：我描述问题，AI 给出代码，我复制到编辑器，报错后再把报错复制回来。上下文在聊天框、编辑器和终端之间来回搬运，最累的不是写代码，而是不断解释“我刚才做了什么”。

Codex 把这条链路接了起来。它可以在授权范围内查看项目文件、搜索代码、编辑文件、执行构建或测试命令，并把结果继续作为下一步判断依据。一个完整循环通常是：

1. 理解目标：确认你到底要解决什么问题。
2. 检查环境：读取目录、关键文件、项目说明和依赖。
3. 制定计划：把大任务拆成可验证的小步骤。
4. 执行修改：创建或编辑文件，必要时运行命令。
5. 验证结果：执行测试、构建、类型检查或实际预览。
6. 审查差异：确认没有误改文件，没有引入明显回归。
7. 交付说明：告诉你改了什么、验证了什么、还剩什么风险。

真正有价值的是第五步和第六步。只生成代码的 Agent 很容易给你一种“已经完成”的错觉，而一个合格的 Agent 应该拿证据证明结果。以后每次下任务，我都会在结尾加一句：

这一句看起来普通，却能明显减少“代码写完了但不能用”的情况。

二、四种入口怎么选：新手先选离工作最近的那个

Codex 目前不是单一形态。你会看到桌面应用、IDE 扩展、CLI 命令行和 Web/云端。它们不是谁替代谁，而是适合不同的工作位置。

我的选择方法很简单：第一次学习用桌面应用或 CLI；正在写代码时用 IDE；需要并行或长时间执行时再用云端。不要一开始把四种入口全部配置一遍。入口越多，不代表效率越高，反而容易把注意力耗在配置上。

三、开始前只准备三样东西：项目文件夹、Git 和一个可验证的小目标

很多教程一上来就讲模型、MCP、Skills 和复杂配置。我照着配置了一堆东西，最后连第一个任务都没跑通。后来我把准备工作缩成三项：

第一，准备一个独立项目文件夹：

不要第一次就让 Codex 扫描桌面、下载目录或整个硬盘。工作目录既决定它看到什么，也决定它默认能改什么。新手最好创建一个专门练习目录：

第二，安装 Git，并养成任务前后留检查点的习惯：

Git 不是程序员专属工具，它更像项目的“撤销历史”。在 Codex 动手前提交一次，任务完成后再看差异，即使修改不满意，也能准确知道发生了什么。

第三，选择一个能在 30 到 60 分钟内验收的小目标：

第一次不要做“完整电商平台”“微信替代品”或“全自动赚钱系统”。目标越大，你越难判断问题来自需求、模型、环境还是代码。本文的练习目标是：

四、安装 Codex 和 CLI：先用官方方式，再处理系统差异

官方当前为 macOS 和 Linux 提供独立安装脚本。在终端中运行：

安装后启动并验证版本：

第一次启动时，按界面提示选择“使用 ChatGPT 登录”或其他可用的登录方式。

五、第一次不要让它写代码：先让它解释自己看到了什么

我第一次真正建立信任，不是因为 Codex 生成了页面，而是因为我先让它做了一次只读检查。我输入：

这一步有三个作用：确认它真的在正确目录、确认它理解目标、在写代码前看到技术选择。 接着让它把目标转换成可验证的验收清单：

六、提示词不用写成论文，只要补齐四个字段

新手提示词的主要问题不是不够长，而是缺字段。高质量任务必须归纳为四部分：

七、权限怎么选：不是越大越省事，而是刚好够用

Codex 能执行命令、修改文件和访问网络，权限过大不仅增加风险，也会让你失去观察它工作过程的机会。

我的简单规则是：读代码用只读，正常改项目用工作区，安装依赖和访问网络按次确认，删除文件、重置历史、强制推送和生产环境操作必须单独检查。权限的目标不是阻止 Codex 工作，而是让错误的影响半径可控。

八、必须认识的命令：先学 8 个，其他需要时再查

九、AGENTS.md：把每次都要重复的话变成项目规则

当我连续三次提醒 Codex“不要使用 npm，请用 pnpm”“修改后要跑测试”“不要碰生成目录”时，我才理解 `AGENTS.md` 的价值。它相当于写给 Agent 的项目说明，Codex 进入项目时会自动读取相关层级的规则。

⚠️ AGENTS.md 两大禁忌： 1. 严禁写成几千字的愿望清单（充满“深度思考”等模糊大词）；2. 严禁把一次性需求写进去（如“今天把按钮改成绿色”）。长期规则必须稳定、可执行、能反复使用。

十、真正跑通一次：计划、执行、验证、审查

现在回到任务看板。第一轮不要同时追求功能和精美视觉，先让它完成最小闭环：

第一版出来后，做一轮手动验收：新增三条任务、输入空格拦截、标记完成、删除任务、刷新页面、移动端窄屏测试。发现问题时，提供最小可复现用例：

功能通过后，再单独做视觉轮次。最后运行 `/review` 从代码审查视角检查 diff。把失败变成可定位、可修复、可回归验证的问题，你真正训练的是交付能力，而不是抽卡能力。

十一、上下文管理：给得太少会猜，给得太多会迷路

把上下文合理拆解为四层：

1. 第一层（当前任务）：这一次要做什么、问题如何复现、完成标准是什么（短而明确）。
2. 第二层（项目规则）：放在 `AGENTS.md`，包括目录结构、运行命令与工程约束。
3. 第三层（可复用流程）：当同一套步骤反复执行时，用 Skill 封装（如代码审查清单、发布规范）。
4. 第四层（外部动态信息）：当数据在 GitHub、Sentry、Figma 且持续变化时，通过 MCP 连接。

十二、模型与推理强度：按任务难度选，不要把最高档当默认

• 低/中等推理：文件解释、文案微调、明确的单文件修改。
• 中等/高推理：多文件功能、常规重构、测试补全。
• 高/更高推理：疑难 Bug、架构迁移、长链路任务、安全审查。

选择模型时看三个维度：任务是否复杂、错误代价是否高、你是否能快速验证。

十三、MCP、Skills 和插件：先跑通人工流程，再自动化

黄金法则：没有手动重复三次的流程，暂时不自动化。

新手最合理的升级顺序是：先完成纯本地项目 → 写好 AGENTS.md → 将重复审查做成 Skill → 最后按需接入外部 MCP。

十四、我踩过的 10 个坑，以及更直接的修正方式

1. 在错误目录启动。修正：启动后第一件事查看工作目录和文件清单。
2. 一句话要求完成大型项目。修正：先定义最小闭环，把大目标拆成每轮可验收的任务。
3. 没有 Git 检查点。修正：任务前提交一次，完成后查看 diff，再决定是否保留。
4. 只描述想要什么，不说不能改什么。修正：明确依赖、接口、目录和数据安全边界。
5. 把“运行成功”当成“需求完成”。修正：用用户动作写验收清单，运行测试只是证据之一。
6. 发现 Bug 后让它大规模重构。修正：先要求根因分析，再做最小修改，最后补回归检查。
7. 一开始就给全盘权限。修正：只读探索，工作区执行，高风险动作单独确认。
8. 把所有规则塞进每次提示词。修正：长期规则写入 AGENTS.md，重复流程做成 Skill。
9. 同一个长会话处理不相关任务。修正：一个会话对应一个连贯目标，过长就整理并压缩，分叉就新开。
10. 相信最终总结，不看实际差异。修正：查看修改文件、命令输出、测试结果和 Git diff。Agent 的自述不是证据，执行记录才是。

十五、5 个可以直接复制的入门提示词

用后感悟与核心公式

用了一段时间后，我对 Codex 最大的认知变化是：提示词只是任务入口，真正决定结果的是工作系统。

一个可靠的系统包括正确的工作目录、可恢复的 Git 检查点、足够清楚的目标与边界、刚好够用的权限、能被执行的验收标准、持续更新的项目规则，以及任务完成后的测试和审查。模型能力越强，这套系统越重要，因为强大的 Agent 能更快放大正确方向，也能更快放大错误假设。

任何一项接近零，最终结果都会打折。把这四项练熟，你得到的就不只是一个会写代码的 AI，而是一套能持续放大个人执行力的工作方式。