前面五篇把 Codex 的入口和核心功能都讲完了，最后这篇讲怎么把它们串成一条稳定的工作流，以及五个从建站到做视频的真实案例。很多人用 Codex 翻车，不是 AI 不行，而是用法不对。一句话丢给它「帮我做个网站」，AI 改得飞快，但你不知道它改了什么，也不敢直接交付。
标准六步法：从需求到交付
稳定的用法是按固定流程推进，需求不是直接变成交付物，中间必须经过六步：需求拆解 → 制定计划 → 小步实现 → 测试 → 代码审查 → 提交复盘。
第一步需求拆解，回答七个问题：背景是什么（项目处于什么阶段，为什么现在改），要解决什么问题（把「优化首页」具体到「优化首屏标题，副标题和 CTA 按钮」），哪些文件可能相关，哪些功能不能动，什么结果算完成，需要哪些测试，有哪些风险。这七个问题说清楚了，翻车概率直接降一半。
第二步先计划后动手。提示词开头就写明「先不要写代码，也不要修改任何文件，请先制定修改计划，等我确认后再执行」。也可以直接用计划模式或 /plan 命令。等发现方向不对时它已经改了一堆文件，回头检查和回滚都很麻烦，所以先确认再修改。
第三步小步实现，一次只改一个功能点。比如优化首页拆成五小步：先改首屏标题，再调 CTA 按钮，再优化移动端布局，再补卖点卡片，最后处理样式细节。同时要明确限制：不要顺手重构无关代码、不改目录结构和依赖版本，发现可优化的地方先记录为建议，不许直接改。遇到不确定的情况（该改哪个文件，能不能删旧代码，要不要新增依赖）必须停下来问你。
第四步测试，用结果证明完成。不要相信 AI 说「完成了」，按顺序跑：单元测试 → 类型检查 → lint → 构建 → 手动测试 → 回归测试。两个容易踩的坑：老项目本身就有 lint 问题，别让 Codex 顺手全重构了。回归测试最容易被忽略，改了首页按钮，可能影响复用同一组件的其他页面。
第五步代码审查看 diff，防它改到不该改的地方。第六步提交并复盘，AI 负责执行，人负责拍板。
五个实战案例：一个人做完一整套生意
书里最精彩的部分是用一个「宠物零食售卖」项目，串起了五个由浅入深的实战案例，全部用 Codex 完成：
案例一：从零做出售卖网站。本地建文件夹 → 在 Codex App 里选好目录 → 开计划模式生成项目计划 → 确认后执行 → 预览 index.html → 建 Git 仓库管理代码 → 用注释功能直接在页面上标细节修改 → 加月销量和热销榜功能 → 推到 GitHub → 用 GitHub Pages 发布上线，拿到一个别人也能访问的链接。注意 GitHub Pages 只适合静态网站，需要后端和数据库的业务不适用。
案例二：加功能优化页面。新增用户登录注册（保存收货地址），按宠物分类再细分食品分类，购物车结算时提示确认地址。每次都先开计划模式确认 AI 理解了需求再动手。
案例三：做管理后台。同样计划模式先行，做完提交 Git 保存。
案例四：用 Skill 做招商 PPT。把 GitHub 上的 PPT Skill 地址发给 Codex 安装，用「/」选择对应 Skill，最终生成一份完整的品牌招商 PPT。这正是 Skill 的价值：固定工作方法装一次，以后反复用。
案例五：用插件做宣传视频。安装 HyperFrames 视频插件，计划生成视频，成品是一条可直接播放的宠物零食宣传片。写代码的 AI 顺带把营销物料也包了。
进阶：第三方模型接入
书里附录还提了一个非官方玩法：用 CC Switch 这个第三方开源桌面工具给 Codex 接第三方模型。它把手动改配置文件变成可视化面板，核心功能有三个：Provider 一键切换（官方 API 切中转，切 DeepSeek 等），MCP 统一管理（不用分别给 Claude Code，Codex，Gemini 配），Skills 管理（从 GitHub 或 ZIP 安装并同步到不同工具）。
需要提醒的是：这属于非官方方案，模型兼容性，上下文长度，工具调用，费用和隐私都以第三方服务商为准，重要项目先用测试仓库验证，别直接在生产项目里试。
写在系列最后
六篇讲完，回到开头那句话：Codex 是能交代任务的工程执行者，不只是帮你写代码的 ChatGPT。入门路径也很清晰：先从 Codex App 做本地练习，熟悉 thread、diff 和计划模式这几个核心概念。再学 CLI 进真实项目，配好 Git 和沙盒权限。然后按六步法推进任务。最后用 Skill、MCP 和 AGENTS.md 把你的工作流沉淀下来。
AI 编程工具的重点已经从「帮你写代码」转向「帮你交付任务」。工具越来越强，会用工作流的人，才是真正的差别所在。
