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 LayoutCodex 依然能做但会花更多时间修正。如果系统本身规范它的效率会明显提高。第四组才是更复杂的玩法ChatGPT 应用、游戏开发、Apple 应用、API 迁移。这些任务涉及更多工具链、认证、构建环境和长期维护不适合作为第一次尝试。等你已经习惯了用 AGENTS.md 写规则、用测试命令做验收再碰它们会顺很多。所以这份案例库最好的读法不是收藏。而是挑一个小任务今天就让 Codex 跑一遍。下面按任务场景拆开看。1. 先把 PR 初审交给 CodexPR 审查任务卡最容易开始的场景是 GitHub PR 审查。把 Codex 接入仓库之后它可以在 PR 提交后先做一轮检查哪里可能引入回归哪里缺测试哪里文档没有跟上哪里行为变化需要多看一眼。如果团队不想一开始就全自动也可以在评论里手动触发。写 codex review它负责看。看完以后如果你认可它指出的问题再写 codex fix it它可以继续开云端任务修。这个场景里最关键的文件是 AGENTS.md。它相当于项目里的 AI 工作说明书。你可以写清楚审查优先级比如安全问题、测试缺口、文档遗漏分别怎么处理。Codex 会按离当前文件最近的 AGENTS.md 来理解本仓库的规矩。Starter Promptcodex 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. 把产品能力接进 ChatGPTChatGPT 应用任务卡更高级一点的用法是做 ChatGPT 应用。这个场景不是写一个普通网页而是把某个产品能力接进 ChatGPT让用户在对话里调用你的工具。结构上通常有三块MCP 服务器负责工具定义、数据返回和认证。Widget可选用来在 ChatGPT 里展示交互界面。模型集成让 ChatGPT 根据工具说明决定何时调用。Codex 可以在这里帮你做工具规划、MCP 脚手架、Widget 初版、本地 HTTPS 测试环境以及后续认证和部署步骤。官方反复强调的顺序是不要一上来就搬整个产品。先挑一个核心场景把工具接口跑通。Starter Prompt用 $chatgpt-apps 和 $openai-docs 为 [你的场景] 规划一个 ChatGPT 应用。要求从一个核心用户场景开始提出 3-5 个工具及其名称、描述、输入输出建议 v1 是否需要 WidgetTypeScript 做 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 PromptCodex 分析这个线程里提到的问题并在 环境名称 中实现修复。这相当于把 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 或项目文档。第三验收标准是什么。前端要不要跑 PlaywrightPPT 要不要渲染成 PNG 检查数据分析要不要保留原始数据和可复现脚本如果没有验收标准Codex 很容易只给一个“看起来完成”的结果。第四谁做最后判断。Codex 可以先跑第一轮但安全、业务逻辑、对外发布内容最好仍然留一个人工确认点。这样一拆很多原本看起来只能靠人盯着做的活就会变成可以委托的工作流。也正是这个原因OpenAI 这次没有只展示“模型能力”而是展示“任务交接方式”。你要给它三样东西。第一明确目标。第二足够上下文。第三可验证的结果标准。而 AGENTS.md 之所以反复出现是因为它承担了「长期上下文」的角色。项目规则、目录约定、测试命令、审查标准都可以提前写进去。这样 Codex 每次接任务时不需要从零猜你的工作方式。所以这份案例库最值得看的地方不是 12 个单点技巧。它更像 OpenAI 给出的一套协作模板人负责定义问题和验收标准Codex 负责进入工作区执行、验证和交付