字节笔记本
2026年10月5日 · 约 19 分钟读完
206页Codex橙皮书开源：从安装到跑通真实项目
206页Codex橙皮书开源：从安装到跑通真实项目
有开发者在社区里吐槽："市面上 Codex 的教程太散了：官方文档一块、视频一块、各路博主又一块，新手想系统上手，光把这些东西拼到一起就很花时间。"
所以作者和小伙伴花了十天，自己整理出一本《Codex 橙皮书》，206 页，免费开源，直接拿走。
今天我们就来拆这本"喂饭级"指南，看它到底写了什么，凭什么被转发称为"挖到宝了"。
一、先说清楚：这本书是什么
《Codex 橙皮书》，仓库地址 bozhouDev/codex-orange-book，由开发者和伙伴历时十天打磨，2026 年 6 月 22 日定稿，v0.1.0 版本，非官方指南，持续更新。
它的定位很明确，原话是：
一份 PDF 206 页，从零到能用 Codex 跑通真实项目，挨个章节啃下来就够。
全书围绕五大篇 + 一个附录展开，结构是一条完整的链路：
| 篇章 | 解决的问题 | 一句话 |
|---|---|---|
| 第一篇 | Codex 到底是什么 | 先把概念和定位捋清楚 |
| 第二篇 | 怎么装、怎么配 | App / CLI / IDE / Web 四端上手 |
| 第三篇 | 核心功能详解 | 自动化、插件、Skill、MCP、Git、云端、记忆系统 |
| 第四篇 | 标准工作流 | 自己跑出来的"标准六步法"+ 任务模板库 |
| 第五篇 | 实战案例库 | 宠物零食网站从 0 到 PPT 到视频，五个案例 |
| 附录 | 第三方模型接入 | CC Switch + DeepSeek 等省钱方案 |
适合谁？作者列得很直白：
- 完全没用过 Codex，但想系统上手的人。
- 会写代码，但不知道怎么把 Codex 接入真实项目的人。
- 已经用过 Cursor、Claude Code、ChatGPT，想比较工作流的人。
- 独立开发者、AI 工具博主、技术团队负责人。
二、Codex 不是"又一个写代码工具"
很多人第一次听到 Codex，会下意识把它理解成"又一个 AI 写代码工具"。
橙皮书第一篇开篇就纠正了这个认知偏差：如果只把 Codex 当成"帮我写代码的 ChatGPT"，你很容易低估它。
AI 编程工具的"四次进化"
橙皮书把过去五年的演进拆成四个阶段，这个梳理特别清楚：
2021 年 · Copilot 补全时代。 Codex 这个名字第一次被大量开发者听到，是因为 GitHub Copilot。那时 AI 像一个更聪明的输入法：你写开头，它补后面。项目怎么拆、文件怎么找、测试怎么跑，仍然主要靠人。
2022 年 · ChatGPT 对话时代。 AI 从"补全"进入"对话"，可以问报错、问优化、问接口写法。但它不在真实项目里，你得复制代码、粘贴报错、手动补上下文，再把答案搬回去。
2023 至 2024 年 · Cursor 项目协作时代。 Cursor 让 AI 真正进入编辑器，能看到文件、跨文件重构、根据项目上下文改代码。但它大多数时候仍依附在 IDE 里，你还得盯着它改、判断下一步、跑测试。
2025 年 · Codex 工程 Agent 时代。 Codex 重新出现，已经不只是当年那个补全模型，而是面向真实软件工程任务的 coding agent：能读项目、修 bug、加功能、补测试、重构模块、运行命令、检查 diff、整理 PR 说明，甚至并行处理多个工程任务。
橙皮书给了一句很精炼的总结：
Copilot 帮你补代码，ChatGPT 帮你想代码，Cursor 陪你改项目，而 Codex 开始帮你执行工程任务。
重点正在从"帮你写代码"转向"帮你交付任务"。
Codex vs ChatGPT / Cursor / Claude Code
| 对手 | 核心区别 | 推荐组合 |
|---|---|---|
| ChatGPT | ChatGPT 像顾问，Codex 像实习生 | 先用 ChatGPT 想清楚，再用 Codex 进项目执行 |
| Cursor | Cursor 是 AI 编辑器，Codex 是工程 Agent | Cursor 做日常编码和局部修改，Codex 做任务推进和工程交付 |
| Claude Code | Claude Code 偏终端长期协作，Codex 偏 OpenAI 生态多端联动 | 喜欢终端长协作选前者；已在 OpenAI 生态、要多端流转选后者 |
作者的判断很务实："两者没有绝对谁替代谁"，最终看模型能力、上下文处理、工具链、价格、团队习惯。
三、四个入口怎么选
橙皮书把 Codex 的使用入口拆成四端，并给了明确的选择建议：
| 入口 | 定位 | 适合谁 |
|---|---|---|
| Codex App | 桌面端，多线程、worktree、自动化、Git | 新手最推荐，也是功能最强的 |
| Codex CLI | 本地终端里的 coding agent | 熟悉终端、要做深度项目协作的开发者 |
| Codex IDE Extension | 编辑器插件 | 习惯在 IDE 里干活的人 |
| Codex Web | 浏览器云端运行 | 不想本地配环境、要跑重型任务 |
作者的建议路线很清楚：
如果你主要做本地项目、网页练习和日常开发，优先从 Codex App 开始通常就够用；等你熟悉 Git、终端和团队协作后，再逐步补 CLI、IDE Extension 和 Web。
别一上来就钻 CLI，App 是最顺的起点。
四、核心功能：三个最容易混淆的概念
第三篇是全书最硬核的部分。橙皮书一上来就解决了所有人都会卡住的疑问：插件（Plugin）、Skill、MCP 到底什么关系？
作者用一张总表把它们钉死了：
| 对比 | 插件 Plugin | Skill | MCP |
|---|---|---|---|
| 一句话 | 能力安装包 | 一套固定工作方法 | 连接外部工具的接口 |
| 解决什么问题 | 安装、打包、分发能力 | 同类任务"怎么做" | "连接什么工具或数据" |
| 类比 | 工具箱 | 工具箱里的说明书 | 给工具箱接电的插座 |
| 谁来用 | 普通用户也能一键装 | 普通用户也能用 | 更偏开发者和团队配置 |
| 举例 | GitHub 插件、Figma 插件 | README Skill、Review Skill | 数据库 MCP、文档 MCP |
记住一句口诀就够了：
插件可以把 Skill 和 MCP 打包成更容易安装的能力包；Skill 管"怎么做"，MCP 管"连什么工具"。
Skill 还是 MCP？一个判断标准
| 你的需求 | 用 Skill 还是 MCP |
|---|---|
| 写 README、固定文档输出格式 | Skill |
| 做代码 Review、UI Review | Skill |
| 生成落地页、把修 bug 流程标准化 | Skill |
| 查最新开发文档、新版本 API | MCP |
| 连接数据库 | MCP |
| 读取 Figma 设计稿 | MCP |
| 读取 GitHub issue / PR | MCP |
| 连接 Notion、内部知识库、公司内部工具 | MCP |
一句话："怎么做"的问题用 Skill，"连接什么工具"的问题用 MCP。
Skill 和普通提示词的区别
很多人会问：我每次直接写提示词不就行了，干嘛要做 Skill？
橙皮书的答案很直接：只做一次的任务用提示词，经常重复做的任务做 Skill。
| 对比 | 普通提示词 | Skill |
|---|---|---|
| 使用方式 | 每次手动输入 | 保存成固定能力 |
| 稳定性 | 容易漏要求 | 更稳定 |
| 适合场景 | 临时任务 | 重复任务 |
| 复用性 | 低 | 高 |
一个 Skill 通常包含：instructions（怎么做）、resources（参考资料/模板）、scripts（可选脚本）、examples（示例）、checklist（防漏步骤）。
自动化：给项目请个"AI 值班工程师"
这是全书最有想象力的功能之一。橙皮书的定义是：
Codex 自动化 = 让 Codex 不只是"听你指挥"，而是能按规则定期帮你巡查项目、发现问题、处理问题。
就像给项目请了一个 AI 值班工程师：
平时它不打扰你，有问题它来提醒你，简单问题它先尝试修，最后让你审核决定。
书里给了个很实用的例子：每周 Codex 会话自动复盘。让 Codex 定期检查最近的会话记录、任务结果和常见问题，沉淀成一份可复用的工作流档案，把你的偏好（UI 设计、产品理念、交互原则）整理成后续会话能遵循的规则。
记忆系统：AGENTS.md
这是让 Codex"记住"你项目规则的核心机制。橙皮书给出了完整的 AGENTS.md 模板，包含项目说明、技术栈、常用命令、项目结构、代码规范、UI 规则、禁止事项、完成任务后的流程。
书里强调了一个关键点：文档不是附属品，文档本身就是上下文基础设施。 文档越清楚，后续人和 AI 接手项目都会更轻松。
五、标准六步法：从需求到交付的完整链路
第四篇是全书的灵魂。橙皮书指出新手最容易犯的错：直接一句话丢给 Codex：
帮我做一个网站。 帮我改这个功能。 帮我优化这个项目。
问题在哪？AI 改得很快，但你不知道它到底改了什么，也不知道能不能放心交付。
作者给出了一套自己跑通的"标准六步法"：
| 步骤 | 名称 | 简单来说 | 目的 |
|---|---|---|---|
| 1 | 需求拆解 | 先让 Codex 知道要做什么 | 避免不了解结构就乱改 |
| 2 | 制定计划 | 先列要做什么，确认后再动手 | 避免一步改太多、方向跑偏 |
| 3 | 小步实现 | 一次只改一小块 | 降低出错概率，方便回滚 |
| 4 | 测试 | 改完运行检查并手动验证 | 确认没有明显报错 |
| 5 | 代码审查 | 看 diff，检查改得对不对 | 防止改到不该改的地方 |
| 6 | 提交与复盘 | 提交代码并沉淀经验 | AI 负责执行，人负责拍板 |
第一步"需求拆解"有多细
光第一步，橙皮书就拆成了 7 个子问题：
- 背景是什么：项目处于什么阶段、为什么现在要改
- 要解决什么问题：把"优化首页"变成"优化首页首屏标题、副标题和 CTA 按钮"
- 哪些文件可能相关：提前告诉 Codex 大概位置，减少全项目乱找
- 哪些功能不能动：画边界，防止顺手改坏登录逻辑、接口地址、数据库字段
- 什么结果算完成：明确的验收标准
- 需要哪些测试：页面预览 / 控制台检查 / 构建测试 / 单元测试
- 有哪些风险：影响范围过大、样式污染、依赖风险、逻辑风险、数据风险、兼容风险
书里甚至给了可以直接复制的需求拆解提示词模板：
请先帮我做需求拆解，不要立刻修改代码。
需求：[你的需求]
请分别回答：
1. 这个需求涉及哪些文件？
2. 有哪些地方不能动？
3. 什么结果算完成？
4. 需要哪些测试？
5. 有哪些风险？这套方法论的精髓就一句话：需求不是直接变成交付物，中间必须经过"理解、计划、修改、验证、检查、验收"这几步。
六、五个实战案例：从网页到 PPT 到视频
第五篇是全书最"喂饭"的部分。作者用一个宠物零食售卖的虚拟项目，把整个链路从 0 跑通，五个案例层层递进：
案例一：制作宠物零食售卖的前端页面网站
从零开始，完整走一遍：
- 本地创建文件夹
Pet treats - 开启计划模式，让 Codex 先生成项目计划
- 打开
index.html预览 - 创建 Git 仓库做代码管理
- 用注释功能直接在页面上做细节修改（比如给商品加月销量）
- 新增"热销榜"功能
- 推送代码到 GitHub
- 通过 GitHub Pages 一键发布，让全世界都能访问
最终成品是个真实可访问的网页。作者还贴心提醒：GitHub Pages 适合托管静态网站，不适合跑需要后端、数据库或交易的业务逻辑。
案例二：给网站增加功能和优化页面
在案例一的基础上继续迭代：
- 新建用户登录注册页面
- 创建不同宠物分类，并在分类下做食品分类
- 用注释功能优化细节
- 购物车点击购买时提示确认地址
- 提交到 Git 保存
这一步演示的是如何让 Codex 在已有项目上小步迭代，而不是推倒重来。
案例三：制作宠物零食的管理后台
同样先开计划模式，规划后台要有哪些页面和功能，检查效果后提交 Git。这一步演示的是如何把一个相对复杂的需求拆给 Codex 做。
案例四：制作宠物零食品牌招商 PPT
这里展示了 Skill 的实战用法：
- 安装 PPT Skill
- 用
/选择对应的 Skill - 检查最终结果
把"做 PPT"这件本来要手动折腾的事，固化成一套可复用的流程。
案例五：制作宠物零食宣传视频
这里展示了视频插件的用法：
- 安装视频插件（如 HyperFrames、Remotion）
- 计划生成视频
- 效果预览
五个案例串起来，正好覆盖了橙皮书讲的所有核心能力：网页生成、功能迭代、后台管理、Skill 出 PPT、插件出视频，一条完整的"从想法到交付"链路。
七、附录：第三方模型接入（省钱方案）
附录讲的是个很现实的问题：OpenAI 官方额度用不起怎么办？
橙皮书介绍了 CC Switch 这个第三方开源桌面工具。它不是 Claude Code 或 Codex 本体，而是一个统一管理面板：
以前你要手动改 Claude Code、Codex、Gemini CLI 的配置文件。现在 CC Switch 给你做成一个可视化面板，一键切换。
三大核心用途：
| 功能 | 简单来说 |
|---|---|
| Provider 切换 | 从官方 Claude API 切到中转 API，或切到另一个模型服务 |
| MCP 统一管理 | 不用分别给 Claude Code、Codex、Gemini 配 MCP |
| Skills 管理 | 从 GitHub 或 ZIP 安装 Skill，同步到不同 AI 编程工具 |
书里以 DeepSeek 为例，演示了从创建 API key 到在 CC Switch 里接入的完整流程。
作者也很诚实，这一节明确标注"不属于 OpenAI 官方功能，模型兼容性、稳定性、隐私和费用规则以对应第三方工具与模型服务商为准"。
八、这本书到底好在哪
读完 206 页，我觉得它最值得拿走的有三样东西：
第一，一套认知框架。 它不是教你怎么敲命令，而是先帮你建立"Codex 是什么、能做什么、不能做什么"的心智模型。AI 编程的"四次进化"那段梳理，比绝大多数营销文都清醒。
第二，一套可复制的工作流。 "标准六步法" + 需求拆解模板 + 任务模板库，是从真实项目里跑出来的，不是拍脑袋。每一步都给了"为什么这么做"和"不这么做会怎样"。
第三，五个完整的实战案例。 不是"看，AI 能写代码"的炫技，而是从建文件夹到发布上线的完整链路，每一步都有截图，踩过的坑都写进去了。
作者自己在推文里说得很实在：
我也不会用什么 /loop 或者其他高级开发技巧，就是一个个功能地和 AI 硬聊，然后把很多细节和功能落实到位。过程艰辛，根本没有想象中的美好，但是稍微回头一看，哦，我开发这么多东西了，有意思。
这大概就是这本橙皮书最真实的样子：不是什么天才之作，而是一个普通开发者花了十天，把"怎么真正用 Codex 干活"这件事，老老实实啃下来的成果。
九、怎么拿
- 仓库地址：
github.com/bozhouDev/codex-orange-book - 在线阅读：
vink567.github.io/codex-orange-book - PDF 下载：仓库根目录
Codex橙皮书.pdf（206 页完整版）+Codex橙皮书.preview.pdf（预览版） - 协议：开源，持续更新
作者的姊妹项目（提示词方向）也在路上，每天陆续增加。用作者写给自己的话收尾："反正开始了，就容易了。"
本文基于《Codex 橙皮书》v0.1.0（2026-06-22 校验）整理，非官方指南，所有功能以 OpenAI 官方文档和 Codex 实际版本为准。仓库：bozhouDev/codex-orange-book。
