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 状态，不要编造缺失值或合并键。输出