从第 0 篇总览到第 17 篇工作边界，这套 Codex 教程已经形成了一条完整主线。
文章变多以后，新的问题也出现了：新读者不一定知道从哪里开始；已经在用 Codex 的人，也没有必要把 18 篇从头顺序读完。有人只想安全地完成第一次修改，有人正在搭建 Skills，有人关心团队规则，还有人只想解决“这个任务到底该不该交给 Agent”。
所以这篇不是简单的文章目录，而是一张阅读地图。它会回答三个问题：
- 每一篇具体解决什么问题？
- 读完能带走什么可复用产物？
- 按你现在的目标，最短应该读哪几篇？
| 项目 | 说明 |
|---|---|
| 内容类型 | Codex 系列总览与阅读导航 |
| 覆盖范围 | 第 0 篇总览、第 1–17 篇主线，以及 2 篇 Agent 工程延伸阅读 |
| 适合读者 | 初次接触 Codex、已经在项目中使用 Codex、准备沉淀 Skills 或建立团队规范的人 |
| 使用方式 | 不要求顺序通读；先选目标路径，再回到完整地图补课 |
| 读完产物 | 一条适合自己的阅读路线，以及一份可勾选的学习清单 |
| 整理日期 | 2026-07-25 |
内容边界
这篇只负责解释系列结构和文章之间的关系，不重复各篇中的命令与产品细节。涉及 Codex 当前入口、权限、配置和产品能力时，请以对应文章的核对日期与 OpenAI 官方资料为准。
一分钟概览
- 刚开始用 Codex：读
01 → 02 → 03 → 05 → 07 → 09，先建立心智和安全基线，再完成一次真实修复。 - 已经有项目要做：读
04 → 06 → 07 → 08 → 10，重点解决项目理解、规则、交付流程和 GitHub 协作。 - 想把重复工作沉淀成能力：读
11 → 12 → 13 → 14 → 15，从 Skill 一直走到外部连接、资料研究和内容发布。 - 准备推广到团队：读
06 → 08 → 10 → 16 → 17，先建立规则与权限，再讨论团队治理和使用边界。
图 1：Codex 系列 00–17 五阶段学习地图
图 1：完整主线不是不断增加 Agent 权限，而是先建立安全基线，再逐步增加交付能力，最后把规则、责任和边界收回来。
1. 先选路线：你不一定需要从第 1 篇读到第 17 篇
把教程编号理解成课程难度，很容易产生误会。后面的文章不一定比前面“更高级”，而是处理的工程范围更大。例如，第 8 篇讲权限，并不意味着新手应该等读完前 7 篇才看；如果你准备让 Codex 修改真实仓库，它反而应该提前阅读。
下面四条路线更接近实际使用场景。
| 你的目标 | 推荐路线 | 完成后的状态 |
|---|---|---|
| 第一次安全使用 Codex | 01 → 02 → 03 → 05 → 07 → 09 | 能选择入口、控制目录与权限，并完成一次可验证的小修改 |
| 把 Codex 用进现有项目 | 04 → 06 → 07 → 08 → 10 | 能让 Codex 读懂项目，遵守仓库规则，并通过 PR 完成交付 |
| 建立自己的 AI 工作流 | 11 → 12 → 13 → 14 → 15 | 能把重复任务做成可触发、可连接、可测试、可维护的能力 |
| 在团队中推广 Codex | 06 → 08 → 10 → 16 → 17 | 能区分项目规则、自动检查、权限策略和人工责任 |
如果你暂时还不知道自己的目标，先读第 1 篇和第 3 篇。前者决定你怎样理解 Codex，后者决定你是否能在真实项目里放心地迈出第一步。
2. 第 0 篇：先看全景，但不要把它当成操作手册
00｜把 Codex 用进真实项目：入口、权限、Git、AGENTS.md 与 Prompt 模板
解决的问题： Codex 的入口、权限、Git、项目规则、Skills 和 MCP 分散在很多地方，怎样先建立一张全景图？
这是整个系列的奠基篇。它覆盖范围最广，适合第一次收藏时快速了解 Codex 可以进入项目的哪些环节，也适合读完若干专题后回来复盘概念之间的关系。
读完带走： 一套六步交付法、入口与权限速查卡、AGENTS.md 和 Prompt 模板。
什么时候读： 想先看全貌时读；真正动手时，跳到后面对应的专题篇，不必靠这一篇解决全部细节。
3. 第一阶段：建立工程 Agent 心智与安全基线
这一阶段的目标不是“学会更多命令”，而是建立三个前提：知道 Codex 是什么、知道从哪里使用、知道怎样限制它的活动范围。
01｜Codex 101：它不是代码生成器，而是工程 Agent
解决的问题： 为什么只把 Codex 当代码补全工具会低估它，而把它当成全自动外包又会失控？
文章用“读项目、改文件、跑验证、检查 diff”的完整交付过程定义工程 Agent，并给出适合与不适合交给 Codex 的任务判断方法。
读完带走： 工程 Agent 心智模型、一份任务适配判断表，以及一次低风险的 30 分钟练习。
02｜Codex 入口选择：ChatGPT 桌面应用、CLI、IDE、Web / Cloud 怎么选
解决的问题： 面对多个入口，不应按“哪个更强”选择，而应该按任务发生在哪里、需要什么权限、结果怎样交付来选择。
文章比较桌面应用、CLI、IDE Extension 和 Web / Cloud 的工作位置与边界。它不是产品功能排行榜，而是一套入口选择方法。
读完带走： 入口选择速查表，以及按任务位置、交互密度、运行时长和远程依赖做判断的决策流程。
03｜第一次安全使用 Codex：目录、Git、权限和回滚
解决的问题： 第一次让 Agent 改真实文件之前，怎样确保改动看得见、失败退得回、危险动作停得住？
文章从工作目录、Git 基线、权限模式和回滚路径开始，强调安全不是最后加上的提醒，而是任务启动条件。
读完带走： 首次运行检查表、练习项目模板和回滚决策表。
这一阶段的完成标志
你能解释 Codex 将在哪个目录工作、能做哪些动作、修改如何被 Git 记录、验收失败以后怎样恢复。只要这四件事说不清楚，就还不适合扩大任务范围。
4. 第二阶段：让 Codex 读懂项目并形成稳定交付流程
有了安全基线以后，下一步不是写更长的 Prompt，而是让项目上下文、任务合同和执行步骤各自进入正确的位置。
04｜别急着写 Prompt：先让 Codex 读懂项目
解决的问题： 为什么一句看似清楚的需求，进入陌生项目后仍然会被错误实现？
文章把“读项目”拆成只读扫描、项目地图、风险确认和实施 Prompt。它要求 Codex 先找到入口、依赖、规则与验证方式，再讨论修改方案。
读完带走： 项目理解 Prompt、项目地图模板，以及从探索结果生成实施任务的方法。
05｜Codex Prompt 骨架：目标、上下文、约束和验收标准
解决的问题： 怎样把“帮我改一下”改写成双方都能判断是否完成的任务？
文章把 Prompt 拆成目标、上下文、约束和验收标准四个部分。重点不是修辞技巧，而是把任务合同写完整。
读完带走： 可复制的 Prompt 骨架、常见任务模板和从模糊需求到可验收任务的改写示例。
06｜AGENTS.md：Codex 项目说明书
解决的问题： 每次任务都要重复说明目录结构、命令、代码规范和禁止事项，怎样把它们变成项目长期资产？
文章解释 AGENTS.md 的职责、作用域与继承方式，并区分项目规则和一次性任务要求。一次性目标仍然留在 Prompt，长期稳定规则才进入项目说明书。
读完带走： 博客、前端和后端项目的 AGENTS.md 模板，以及规则自检清单。
07｜Codex 工作流：Explore → Plan → Code → Verify → Review
解决的问题： 为什么 Agent 经常“改得很快，收尾很慢”，以及怎样让一次任务真正形成闭环？
文章用 Explore、Plan、Code、Verify、Review 五个阶段组织执行。每个阶段都有输入、输出和停止条件，避免探索、实现和验收混在一起。
读完带走： 一套真实任务 checklist、分阶段 Prompt 模板和最终交付格式。
这一阶段的完成标志
你能给 Codex 一份有验收标准的任务，让它先输出项目地图和计划，再做小范围修改，最后交付测试结果、diff、风险与未完成项。
5. 第三阶段：把本地修改推进到可审查的工程交付
这一阶段开始接触更真实的风险：命令可能影响系统，修复需要可复现，代码最终要进入 GitHub 协作流程。
08｜权限与安全：Sandbox、Approval、危险命令怎么管
解决的问题： Sandbox、Approval 和项目规则分别能防什么？哪些动作即使 Agent 能做，也必须停下来确认？
文章把权限控制拆成沙箱、批准、permission profile、Rules 和自动审查五层，并给出危险命令与发布动作的处理原则。
读完带走： 高风险命令清单、个人项目配置模板和博客发布安全流程。
09｜Codex CLI 实战：从读项目到修复一个可复现的 bug
解决的问题： 前面的原则怎样真正落到一次修复里，而不是停留在 Prompt 模板？
文章提供一个可运行的 JavaScript 小项目，从确认目录、复现失败、扫描项目、做最小修改，一直走到测试、diff 和 review。
读完带走： 一次可以跟做的 CLI 修复实验，以及适用于真实 bug 的调试与验收顺序。
10｜Codex + GitHub：从 issue 到 PR、Review 与 Cloud 任务
解决的问题： Codex 完成本地修改以后，怎样通过 issue、分支、PR、CI 和 review 进入团队可审查的交付过程？
文章用一个完整 GitHub 任务贯穿需求拆解、draft PR、CI、Codex Review、反馈修复、Cloud task 和最终合并。
读完带走： issue 模板、PR 模板、review 修复流程和合并前检查清单。
这一阶段的完成标志
你不仅能看到“代码已经改了”，还可以指出原始问题如何复现、修改集中在哪里、哪些测试通过、PR 如何描述，以及谁拥有最终合并权。
6. 第四阶段：把重复动作沉淀成 Skills、连接和内容工作流
前 10 篇主要解决“怎样完成一次任务”。第 11 篇开始，关注点变成“怎样让下一次不必从头教一遍”。
11｜Codex Skills 入门：把重复任务沉淀成可复用能力
解决的问题： 哪些反复出现的 Prompt 值得做成 Skill？一个 Skill 至少需要哪些内容才能被正确触发？
文章从“技术文章 review”这一重复任务出发，创建仓库级 SKILL.md，解释触发条件、作用域和渐进式加载。
读完带走： 第一个可复用 Skill，以及正向、负向触发测试清单。
12｜Codex Skills 进阶：用 references、scripts 与 evals 建立可验证工作流
解决的问题： 一个已经能用的 SKILL.md，怎样在内容变多、维护者增加和错误成本上升以后继续可靠？
文章逐步加入 references、scripts、evals 和版本记录，并区分“目录结构正确”“脚本通过”“Agent 行为符合预期”“人工验收通过”四种不同证据。
读完带走： 一个完整 Skill 包的目录方案、检查脚本、评估样例和版本维护方法。
13｜Codex Plugins、MCP 与 Apps：什么时候该打包能力，什么时候该连接外部系统
解决的问题： Skill、Plugin、MCP 和 App 都在扩展 Agent，但它们解决的并不是同一个问题，应该如何选择？
文章用“官方资料研究助手”贯穿能力打包、外部连接、权限边界和故障恢复。判断重点是代码和数据位于哪里、谁维护连接、外部动作有什么风险。
读完带走： MCP / Plugin / App 决策表、最小配置示例包和渐进授权清单。
14｜Codex 做资料调研：怎样把 X、GitHub 与官方文档整理成可引用的研究笔记
解决的问题： 搜到很多链接并不等于完成研究，怎样把官方事实、社区信号和本地实验整理成可审计证据？
文章演示如何拆分主张、分级来源、固定 GitHub commit、保留检索日期，并在证据冲突时缩小结论范围。
读完带走： research note 模板、证据台账、引用规范和冲突处理流程。
15｜Codex 写作工作流：从研究笔记到审稿、配图与发布
解决的问题： 有了研究笔记以后，怎样避免文章变成资料堆砌，并把草稿、审稿、配图、构建和发布连成闭环？
文章用一篇真实技术文章贯穿 Article Brief、证据交接、分段起草、三遍审稿、内容专属配图、部署门禁和线上验证。
读完带走： 写作发布模板、Prompt、检查脚本和可运行的内容流水线示例。
这一阶段的完成标志
你能把一个反复任务从聊天记录中拿出来，明确触发条件、参考资料、确定性脚本和人工验收，并知道什么时候才需要连接外部系统。
7. 第五阶段：从个人效率走向团队治理和任务边界
能力增加到一定程度后，继续追求“更多自动化”会开始产生反作用。最后两篇不再增加工具，而是处理规则所有权、责任划分、隐私和停止条件。
16｜Codex 团队化：怎样共享 AGENTS.md、Skills、项目规则与发布边界
解决的问题： 个人习惯变成团队规则以后，谁维护、谁审核、怎样验证、如何试点和回滚？
文章把规则分配到 AGENTS.md、Skills、确定性检查和权限策略，并用 PR 就绪流程展示规则从发现摩擦到推广的变更闭环。
读完带走： 团队 Codex 使用规范、规则路由表、责任矩阵和试点检查清单。
17｜Codex 的限制：额度、上下文、幻觉、隐私和工作边界
解决的问题： 不再只问“Codex 能不能做”，而是判断“它应该做到哪一步”。
文章从额度、上下文、证据、权限、隐私、可逆性和验证成本评估任务，将执行方式分为 GREEN、YELLOW 和 RED。
读完带走： 一套可运行的任务边界评估器，以及输入、证据、权限、恢复和人工责任检查表。
这一阶段的完成标志
团队能说清哪些规则只是建议、哪些由 CI 强制、哪些动作需要人工批准；同时能主动拒绝不适合交给 Agent 的输入和任务。
8. 六组容易混淆的文章，区别到底在哪里
第 3 篇和第 8 篇都讲安全
第一次使用先看第 3 篇；准备扩大命令和外部动作范围时，再深入第 8 篇。
第 4 篇和第 6 篇都讲项目上下文
项目地图是一次探索产物，AGENTS.md 是持续维护的项目说明书，不要把扫描结果原样塞进规则文件。
第 5 篇和第 7 篇都能改善任务质量
目标不清楚时先修 Prompt；执行混乱、验证不足时修工作流。
第 11 篇和第 12 篇都讲 Skills
不要一开始就堆满 references、scripts 和 evals。先证明任务真的重复、触发条件真的清楚，再逐步工程化。
第 13 篇和第 14 篇都涉及外部资料
连接成功只证明“能访问”，不证明资料可靠，更不证明结论成立。
第 16 篇和第 17 篇都在收紧边界
治理解决“怎样共同使用”，边界解决“什么时候不该使用”。
9. 两篇延伸阅读：从 Codex 工作流走向通用 Agent 工程
主线完成后，如果你想继续理解 Agent 系统本身，而不只关注 Codex 的具体用法，可以接着读两篇延伸文章。
从 Context Engineering 到 Graph Engineering：读懂 AI Agent 的四层工程
这是一篇概念入门。它用博客后台 Bug 示例解释 Context、Harness、Loop 与 Graph 分别控制什么，以及它们为什么不是四个互相替代的流行词。
适合在读完第 7、11、13 篇后阅读。此时你已经接触工作流、Skills 和外部连接，更容易看懂这四层如何共同构成 Agent 系统。
Graph Engineering：从单 Agent 循环到可验证的工作图
这是一篇进阶设计实战。它讨论 Node、Edge、State、Verifier、预算、人工闸门和 Trace，并提供零依赖的 Node.js Graph Lab。
适合已经能设计单 Agent 工作流，并且真的遇到并行研究、独立验证、多角色写入或人工审批需求的读者。任务还没有复杂到这些程度时，先把第 7 篇的单 Agent 闭环做好，通常更划算。
10. 可复制的学习检查表
不需要把“读完”当成目标。每完成一篇，最好留下一个能在下一次任务中复用的产物。
- 00：我有一张 Codex 进入真实项目的全景图
- 01：我能判断任务是否适合交给工程 Agent
- 02：我能根据任务位置和交付方式选择入口
- 03：我建立了目录、Git、权限和回滚基线
- 04：我能输出项目地图，而不是直接要求 Agent 改代码
- 05：我能写出包含目标、上下文、约束和验收的任务
- 06：项目有一份短而可维护的
AGENTS.md - 07：任务能走完 Explore、Plan、Code、Verify、Review
- 08：危险动作、批准条件和人工边界已经明确
- 09：我完成过一次从失败复现到 diff review 的修复
- 10：我能用 issue、PR、CI 和 review 交付修改
- 11：我把一个重复任务做成了可触发的 Skill
- 12：Skill 有 references、scripts 或 evals 中真正需要的部分
- 13：我能解释何时使用 Skill、Plugin、MCP 或 App
- 14：我的研究结论有来源等级、日期和证据台账
- 15：文章或文档能通过审稿、构建和线上验证
- 16：团队规则有所有者、强制方式、试点和回滚路径
- 17：我能识别应该停止自动化或转为人工处理的任务
11. 最后：选择下一篇，而不是收藏后从不开始
如果今天只有 30 分钟，按下面的方式选一篇：
- 还没真正用过 Codex：读第 1 篇，完成里面的低风险练习。
- 正准备让 Codex 改真实仓库：读第 3 篇，先建立回滚基线。
- Codex 经常改偏：读第 4 篇和第 5 篇。
- 修改能完成但收不了尾：读第 7 篇。
- 每次都在重复同一套说明：读第 11 篇。
- 准备在团队推广：先读第 16 篇，再用第 17 篇检查是否越界。
这套系列真正想留下的，不是 18 篇关于某个产品的使用说明，而是一条比较稳定的工程路线：
先看清任务和边界
→ 再让 Agent 进入项目
→ 用证据和验证完成交付
→ 把重复过程沉淀成能力
→ 最后把规则、权限和责任交还给系统与人
工具入口会变化，命令会更新，模型也会继续迭代。但只要任务仍然需要上下文、执行、验证和责任，这条路线就不会很快过时。