12 个官方场景把 Codex 的用法摊开：从代码审查到 PPT、数据分析和游戏开发，核心是把规则、上下文和验收方式交给 AI。
OpenAI 给 Codex 新放出来的，不像一个普通功能页。
更像一本「照着干」的小册子。
OpenAI 开发者关系负责人 Romain Huet 透露，Codex 的官方用例库已经上线。里面不是只摆几个概念，而是把具体任务拆成了可执行步骤：怎么开局、怎么给上下文、怎么验证结果，连 Starter Prompt 也一起给了。
如果已经安装 Codex 应用，部分案例还能直接从页面跳进 Codex 里开始做。
官方用例库入口
这 12 个用例有一个共同点：它们不再把 Codex 限定在「写代码」。
它可以审 PR，可以还原前端，可以跑数据分析，可以生成 PPT，可以做浏览器游戏，也可以帮新人读懂大型代码库。
真正重要的不是任务数量，而是 OpenAI 正在示范一种用法：
先把规则写清楚，再把目标交给 Codex，让它在工作区里自己读、自己改、自己验证。
先看三条线索
如果只是把 12 个案例当目录看，很容易漏掉 OpenAI 真正想表达的东西。
我更建议把它拆成三条线索。
第一条，是工程协作。
PR 审查、API 迁移、读大型代码库，这些场景都指向同一件事：Codex 不是坐在旁边等你问一句答一句，而是进入仓库之后，按项目规则完成一段可交付的工作。
它要知道哪里能改，哪里不能碰，什么算通过，什么必须交给人确认。
第二条，是知识工作自动化。
数据分析、PPT、Slack 派活，看起来不那么“程序员”，但背后的模式一样：任务有输入、有规则、有产物，也有检查方法。只要流程能被拆开，Codex 就有接手空间。
这也是为什么 PPT 用例会强调可编辑，数据分析用例会强调不覆盖原始数据。它们不是为了展示生成能力，而是在强调工作资产要能继续被人使用。
第三条，是多工具组合。
游戏、Figma、ChatGPT 应用这些案例，都不是单靠一个模型完成。它们会调用浏览器、设计工具、文档查询、图片生成、测试脚本和本地环境。
这说明 Codex 的核心价值正在从“会写代码”变成“会调度一组工具完成任务”。
所以读这份案例库时，最好不要只问：这个功能我会不会用？
更应该问：我手里的重复工作，能不能被写成规则、上下文和验收标准？
只要能写出来，就有机会交给 Codex。
建议的学习顺序
如果从实用角度看，我不建议按官网顺序一口气学完。
更适合普通用户的顺序，应该是从低风险、高频率、容易验证的任务开始。
第一组先看 PR 审查、读懂大型代码库和 Slack 派活。
这几个场景都不需要你马上把生产流程全交出去。你可以先让 Codex 做解释、做初审、做小范围修复，再由人确认。风险低，反馈快，也最容易建立信任。
第二组再看数据分析和 PPT。
这两个任务对非程序员更友好，但它们对输入和验收要求很高。数据分析要防止凭空补数据，PPT 要防止整页图片化。只要你把规则说清楚，它们就很容易变成可复用流程。
第三组适合前端和设计团队：截图变页面、Figma 变代码。
这两类任务很吃现有设计系统。如果你的项目组件混乱、设计稿也没有 token 和 Auto Layout，Codex 依然能做，但会花更多时间修正。如果系统本身规范，它的效率会明显提高。
第四组才是更复杂的玩法：ChatGPT 应用、游戏开发、Apple 应用、API 迁移。
这些任务涉及更多工具链、认证、构建环境和长期维护，不适合作为第一次尝试。等你已经习惯了用 `AGENTS.md` 写规则、用测试命令做验收，再碰它们会顺很多。
所以这份案例库最好的读法不是收藏。
而是挑一个小任务，今天就让 Codex 跑一遍。
下面按任务场景拆开看。
1. 先把 PR 初审交给 Codex
PR 审查任务卡
最容易开始的场景，是 GitHub PR 审查。
把 Codex 接入仓库之后，它可以在 PR 提交后先做一轮检查：哪里可能引入回归，哪里缺测试，哪里文档没有跟上，哪里行为变化需要多看一眼。
如果团队不想一开始就全自动，也可以在评论里手动触发。
写 `@codex review`，它负责看。
看完以后，如果你认可它指出的问题，再写 `@codex fix it`，它可以继续开云端任务修。
这个场景里最关键的文件是 `AGENTS.md`。
它相当于项目里的 AI 工作说明书。你可以写清楚审查优先级，比如安全问题、测试缺口、文档遗漏分别怎么处理。Codex 会按离当前文件最近的 `AGENTS.md` 来理解本仓库的规矩。
Starter Prompt：
@codex review，检查安全回归、缺失测试、以及有风险的行为变更。
这不是替代人工审查，而是把第一轮低层检查提前做掉。
人最后看的，应该是判断题，不是所有细节题。
2. 截图不只是参考图，可以变成页面
前端 UI 还原任务卡
第二类任务是前端落地。
你可以把桌面端、移动端、交互状态、设计参考图一并给 Codex，再告诉它项目里已经有什么组件、token、工具类和排版约定。
这里的重点不是「生成一个像的页面」。
重点是让 Codex 用现有设计系统实现页面。
也就是说，它应该复用已有组件和样式规则，而不是临时造一套自己的 CSS。
实现后再用 Playwright 打开浏览器，在不同屏幕尺寸下对照检查。偏了就继续改，直到布局、间距、层级和响应式行为都说得过去。
Starter Prompt：
用截图和说明作为参考，在当前项目中实现这个 UI。要求：复用现有设计系统的组件和 token，把截图翻译成仓库里的工具类和模式，匹配间距、布局、层级和响应式行为，兼容桌面和移动端。
这其实很接近一个靠谱前端的工作方式：
不是从零堆样式，而是先理解项目已有的设计语言。
3. 让数据分析从「画张图」升级成项目
数据分析任务卡
数据分析这个用例，反而最能说明 Codex 不只是程序员工具。
一个好分析不会从「帮我看看数据」开始。
它应该先定义问题。比如要判断「高速公路附近的房子，房价是不是更低？」这种问题，边界越清楚，后面的清洗、合并和建模越不容易跑偏。
然后要设置工作区规则。
在 `AGENTS.md` 里说清楚 Python 环境、目录结构和文件保护规则。原始数据放 `data/raw/`，处理后的数据放 `data/processed/`，不要覆盖原始文件。
接着才是让 Codex 看数据。
它需要先识别文件格式、字段含义、编码、候选 join key、缺失值和异常值。合并前先检查主键唯一性和匹配率，建模时从可解释的基线模型开始，常见选择包括 statsmodels 和 scikit-learn。
最后再输出给不同人看的结果：Markdown、Excel、PDF 或 .docx。
Starter Prompt：
我在这个工作区做数据分析项目。目标：搞清楚高速公路附近的房子是否估值更低。先读
AGENTS.md
了解 Python 环境，加载数据集，描述每个文件的内容、可能的 join key 和数据质量问题，然后提出一个可复现的工作流程。约束：优先用脚本而非 notebook 状态，不要编造缺失值或合并键。输出：环境配置计划、数据清单、分析计划、第一批要创建的命令或文件。
这个案例最有价值的地方，是它把「分析」拆成了可复现的流程，而不是一次性问答。
4. 把产品能力接进 ChatGPT
ChatGPT 应用任务卡
更高级一点的用法，是做 ChatGPT 应用。
这个场景不是写一个普通网页，而是把某个产品能力接进 ChatGPT，让用户在对话里调用你的工具。
结构上通常有三块：
MCP 服务器，负责工具定义、数据返回和认证。
Widget，可选，用来在 ChatGPT 里展示交互界面。
模型集成，让 ChatGPT 根据工具说明决定何时调用。
Codex 可以在这里帮你做工具规划、MCP 脚手架、Widget 初版、本地 HTTPS 测试环境，以及后续认证和部署步骤。
官方反复强调的顺序是：不要一上来就搬整个产品。
先挑一个核心场景，把工具接口跑通。
Starter Prompt：
用 $chatgpt-apps 和 $openai-docs 为 [你的场景] 规划一个 ChatGPT 应用。要求：从一个核心用户场景开始，提出 3-5 个工具及其名称、描述、输入输出，建议 v1 是否需要 Widget，TypeScript 做 MCP 服务器，React 做 Widget。输出：工具规划、文件树、测试 Prompt 集、风险和待定事项。
如果要总结这个案例，就是一句话：
先定义工具边界，再谈 UI 和部署。
5. Apple 应用开发，也要先变成命令行流程
Apple 开发任务卡
iOS 和 macOS 这类项目，Codex 也能介入。
官方示例是搭建 SwiftUI 应用，并把构建和启动流程做成脚本。
这里的思路是 CLI 优先。
能用 `xcodebuild` 跑的，就尽量让 Codex 通过命令行跑。这样它能看到构建日志、错误信息和测试结果，也更容易反复调整。
如果 `xcodebuild` 过于繁琐，可以用 Tuist 管理项目生成。
已有 Xcode 项目还可以配 XcodeBuildMCP，让 Codex 控制 Scheme、模拟器、截图和 UI 自动化。
官方还给 Apple 生态准备了一些专项 Skill，比如 SwiftUI、Liquid Glass、性能、并发、视图重构等方向。
Starter Prompt：
搭建一个 SwiftUI 启动应用，并添加一个构建和启动脚本，我可以把它绑定到本地环境的 Build 操作上。
这个用例的启发很简单：
只要一个开发流程能被脚本化，Codex 就更容易稳定接手。
6. 游戏开发先写计划，再让 Codex 开工
浏览器游戏任务卡
做浏览器游戏这个案例，看起来和编程助手的刻板印象差得最远。
但官方给的做法很工程化。
先写 `PLAN.md`，把玩家目标、核心循环、操作方式、胜负条件、难度递进、视觉风格、技术栈和里程碑讲清楚。
再写 `AGENTS.md`，说明游戏名称、项目规则和技术选型。官方建议的组合包括 Next.js 加 Phaser 或 PixiJS。
这个过程会用到几类能力：
Playwright Interactive，用真实浏览器测试手感和界面。
ImageGen，用来做概念图、背景、精灵和视觉素材。
OpenAI Docs，用来查 API 和实现细节。
Starter Prompt：
用 $playwright-interactive、$imagegen 和 $openai-docs 来规划并构建一个浏览器游戏。实现 PLAN.md，并在
.logs/
下记录工作日志。
这个案例不是说 Codex 能瞬间做出神作。
它想表达的是：复杂任务可以先变成计划，再变成一次次可检查的迭代。
7. PPT 也可以走工程化流程
PPT 生成任务卡
PPT 这个用例很现实。
官方方案是用 PptxGenJS 处理 .pptx，再配合 ImageGen 做视觉素材。
但它没有鼓励把整页幻灯片直接生成成图片。
相反，它要求保留可编辑性。
文字应该还是 PowerPoint 文本对象，简单图表尽量用原生图表。改已有 deck 之前，先检查页面比例、结构和品牌风格；改完以后，把每页渲染成 PNG，再检查文字溢出、字体替换和元素位置。
Starter Prompt：
用 $slides 和 $imagegen 编辑这个幻灯片：在每页右下角加 logo，把文字左移并在指定页面生成抽象数字艺术插图，保持文字可编辑，按现有品牌风格新增幻灯片，渲染成图片审核，检查溢出和字体替换问题，保存可复用的生成 Prompt。
这类任务以前很烦，是因为文件格式复杂、人工检查碎。
Codex 适合接的，正是这种「能改、能渲染、能复查」的流程。
8. 难题不要赌一次生成，要靠评估循环
评估迭代任务卡
第八个用例讲的是方法，而不是某个具体软件。
官方把它叫评估驱动的改进循环。
有些任务天然不可能一次做好。比如复杂报告、迁移工程、前端视觉对齐、长文生成、测试修复，都需要多轮检查和调整。
Codex 的做法是：先找到评估方式，再每次只改一个点，跑评估，记录分数和变化，然后继续下一轮。
评估可以是确定性的，比如测试是否通过、程序是否可运行。
也可以是 LLM 评审，比如可读性、完整度、是否满足目标。
Starter Prompt：
这个工作区里有个棘手的任务，我想让你用评估驱动的改进循环来做。开始之前：读
AGENTS.md
，找到给当前输出打分的脚本或命令。迭代循环：每次只做一个聚焦的改进，每次有意义的改动后重跑评估，记录分数和改动内容，直接检查生成的产物，持续迭代直到总分和 LLM 评审平均分都超过 90%。约束：不要在第一个可接受的结果就停下来，除非新结果明显更差否则不要回退，遇到瓶颈时说明卡在哪里。
这其实是在提醒用户：
让 Codex 做复杂任务时，最好给它一把尺子。
没有评估，迭代就容易变成凭感觉改。
9. 在 Slack 里直接派活
Slack 集成任务卡
Slack 集成的逻辑更像团队协作。
装好 Slack 应用，连接仓库和环境，把 @Codex 加进频道或线程。之后团队成员可以在对话里直接描述问题，让 Codex 去云端环境执行。
它做完后会把结果贴回线程，也可以去 Codex 云端面板继续查看。
这种方式适合处理小修复、排查、线程里已经讨论清楚的问题。
关键是请求要具体：哪个仓库、哪个环境、优先看哪些文件，都要说清楚。
Starter Prompt：
@Codex 分析这个线程里提到的问题，并在 <环境名称> 中实现修复。
这相当于把 Codex 变成团队频道里随叫随到的执行角色。
但它能不能做对，还是取决于上下文给得够不够准。
10. 从 Figma 节点落到代码
Figma 实现任务卡
Figma 转代码和截图转页面不一样。
截图给的是视觉结果，Figma 给的是结构化设计信息。
所以官方建议先整理好设计文件：颜色、排版、间距用 Variables 或 Design Tokens 管理；组件要复用；响应式关系用 Auto Layout；图层命名不要混乱。
然后 Codex 通过 Figma Skill 获取上下文。
`get_design_context` 负责拿节点结构。
`get_metadata` 负责拿更细的设计信息。
`get_screenshot` 负责拿视觉参考。
实现之后，再用 Playwright 做视觉对照。
Starter Prompt：
实现这个 Figma 设计……先用
get_design_context
获取目标节点或画面……复用现有设计系统的组件和 token……桌面和移动端都要做响应式……用 Playwright 检查 UI 是否匹配参考设计。
这个案例对设计团队也有提醒：
设计稿越规范，AI 落代码越省力。
11. 新代码库先让 Codex 画地图
代码库理解任务卡
读大型代码库，是很多新人最痛苦的第一关。
官方给的思路不是让 Codex 总结整个仓库，而是让它解释一个系统区域的请求流转。
入口在哪里？
哪些模块管业务逻辑？
哪些模块管传输层？
数据校验在哪里发生？
改之前有什么隐含假设？
后续应该先读哪些文件？
Starter Prompt：
解释代码库中 <系统区域> 的请求流转过程。包括：哪些模块负责什么，数据在哪里做校验，改代码前有哪些注意事项。最后告诉我接下来应该读哪些文件。
还可以继续追问：
哪个模块负责业务逻辑，哪个负责传输层，哪个是 UI？
校验逻辑在哪里执行，有哪些隐含的假设？
如果我改了这个流程，哪些关联文件和后台任务容易被忽略？
改完之后应该跑哪些测试？
这个用法最像「代码库导览」。
它不替你理解系统，但能把入口和阅读顺序先找出来。
12. API 迁移别急着改模型名
API 升级任务卡
最后一个场景是升级 OpenAI API 集成。
这个任务看似简单，实际最容易出问题。
因为迁移往往不只是换模型名。endpoint、参数、工具调用、返回格式、Prompt 假设，都可能跟着变。
Codex 的正确打开方式，是先盘点。
当前用了哪些模型？
哪些 endpoint？
哪里依赖旧参数？
哪些 Prompt 需要人工确认？
然后再做最小迁移计划，只改必须改的部分，尽量保留原有行为。需要更新 Prompt 时，再根据最新模型和 API 指南调整。
Starter Prompt：
用 $openai-docs 将这个 OpenAI 集成升级到最新推荐的模型和 API 特性。具体来说，查找最新的模型和 Prompt 指南。盘点当前的模型、endpoint 和工具假设，制定最小迁移计划，保留现有行为（除非新 API/模型要求改变），根据最新指南更新 Prompt，标记所有需要人工审核的变更。
◇ ◆ ◇
这 12 个用例放在一起看，真正的主题不是「Codex 又会做什么」。
主题是：怎么把工作交给 Codex。
怎么迁移到自己的工作里
如果你真的想把这份案例库用起来，不建议从“我要不要全部学一遍”开始。
更好的做法，是先挑一个最近一周反复出现的具体任务。
比如每次发版前都要检查 PR。
比如每次做报告都要清洗同一类数据。
比如每次接新需求都要先在代码库里找入口。
任务越具体，Codex 越容易接。
然后把这个任务拆成四个东西。
第一，输入是什么。
是一个 PR、一个 Figma 节点、一份 Excel、一组截图，还是一段 Slack 讨论？
第二，规则是什么。
哪些文件不能动？用什么库？输出要放哪里？测试命令是什么？这些最好都写进 `AGENTS.md` 或项目文档。
第三，验收标准是什么。
前端要不要跑 Playwright？PPT 要不要渲染成 PNG 检查？数据分析要不要保留原始数据和可复现脚本？如果没有验收标准，Codex 很容易只给一个“看起来完成”的结果。
第四，谁做最后判断。
Codex 可以先跑第一轮，但安全、业务逻辑、对外发布内容，最好仍然留一个人工确认点。
这样一拆，很多原本看起来只能靠人盯着做的活，就会变成可以委托的工作流。
也正是这个原因，OpenAI 这次没有只展示“模型能力”，而是展示“任务交接方式”。
你要给它三样东西。
第一，明确目标。
第二，足够上下文。
第三，可验证的结果标准。
而 `AGENTS.md` 之所以反复出现，是因为它承担了「长期上下文」的角色。项目规则、目录约定、测试命令、审查标准，都可以提前写进去。
这样 Codex 每次接任务时，不需要从零猜你的工作方式。
所以这份案例库最值得看的地方，不是 12 个单点技巧。
它更像 OpenAI 给出的一套协作模板：
人负责定义问题和验收标准，Codex 负责进入工作区执行、验证和交付
