OpenAI Codex 官方用例库：12 个场景 + Starter Prompt 全提取，照着用就行

Codex 用例库是什么

大部分人知道 Codex 能写代码，但坐到电脑前不知道怎么给它布置任务。用例库解决的就是这个问题：别自己想了，先照着官方验证过的来。

每个都带现成的 starter prompt（启动提示词），点一下直接加载到 Codex 里，改改参数就能跑。

按角色选你的场景

12 个用例覆盖六个方向。先找到跟你最相关的：

6 个核心用例详解（附完整 Starter Prompt）

① PR 自动审查：5 秒搞定第一轮 Code Review

难度： 简单 | 耗时： 5 秒

把 Codex 加到你的 GitHub 组织或仓库，它会在每个 PR 上自动跑一遍审查，抓回归、漏测试、文档缺失。人工审查之前先过一遍，省掉很多低级问题。

Starter Prompt（在 PR 评论区直接用）：

@codex review for security regressions, missing tests, and risky behavior changes. @codex 审查安全回归、缺失测试和有风险的行为变更。

发现问题后，直接评论 @codex fix it，它会尝试修复。

自定义审查规则： 在仓库根目录加一个 AGENTS.md 文件：

## Review guidelines
- Flag typos and grammar issues as P0 issues.
- Flag potential missing documentation as P1 issues.
- Flag missing tests as P1 issues.

Codex 会按这个规则来审查所有 PR。

② 截图转响应式 UI：丢张图，出代码

难度： 中等 | 耗时： ~1 小时

给 Codex 一张截图或设计稿，它生成能跑的响应式 UI 代码，还会用 Playwright 打开浏览器对比效果，不满意就继续改。

Starter Prompt（完整版，直接复制）：

Implement this UI in the current project using the screenshots and notes I provide as the source of truth. Requirements: - Reuse the existing design system components and tokens. - Translate the screenshots into this repo's utilities and component patterns instead of inventing a parallel system. - Match spacing, layout, hierarchy, and responsive behavior closely. - Respect the repo's routing, state, and data-fetch patterns. - Make the page responsive on desktop and mobile. - If any screenshot detail is ambiguous, choose the simplest implementation that still matches the overall direction and note the assumption briefly. Validation: - Compare the finished UI against the provided screenshots for both look and behavior. - Use $playwright-interactive to check that the UI matches the references and iterate as needed until it does. 用我提供的截图和备注作为参考，在当前项目中实现这个 UI。 要求： - 复用已有的设计系统组件和 token。 - 把截图翻译成本仓库的工具类和组件模式，不要自造一套平行系统。 - 间距、布局、层级和响应式行为要尽量贴合截图。 - 遵循仓库现有的路由、状态管理和数据获取模式。 - 页面要在桌面端和移动端都能用。 - 截图里有模糊的地方，选最简单的实现方式，简要记录你的假设。 验证： - 把完成的 UI 和截图做视觉和行为上的对比。 - 用 $playwright-interactive 检查 UI 是否匹配参考图，不匹配就继续迭代。

要点： 提示词越具体，结果越好。说清楚你要什么交互模式、用哪套设计系统、哪些组件可以复用。模糊描述只会得到模糊结果。

迭代提示词模板：

[当前效果截图] [参考截图] This doesn't look right. Make sure to implement something that matches closely the reference: [具体哪里不对] [当前效果截图] [参考截图] 这里不对。确保实现的效果和参考图尽量一致：[具体哪里不对]

③ iOS/macOS SwiftUI 开发：从脚手架到模拟器

难度： 中等 | 耗时： 可长可短

这个用例集成了知名 iOS 开发者 Dimillian 的 SwiftUI 技能作为插件，内置了 Liquid Glass 适配、性能审计、并发模式等一整套最佳实践。

Starter Prompt（完整版）：

Scaffold a starter SwiftUI app and add a build-and-launch script I can wire to a Build action in my local environment. Constraints: - Stay CLI-first. Prefer Apple's xcodebuild; if a cleaner setup helps, it's okay to use Tuist. - If this repo already contains a full Xcode project, use XcodeBuildMCP to list targets, pick the right scheme, build, launch, and capture screenshots while you iterate. - Reuse existing models, navigation patterns, and shared utilities when they already exist. - Keep iOS and macOS compatibility intact unless I explicitly scope the work to one platform. - Use a small trustworthy validation loop after each change, then expand to broader builds only when the narrower check passes. - Tell me whether you treated this as a greenfield scaffold or an existing-project change. Deliver: - the app scaffold or requested feature slice - a small build-and-launch script with the exact commands - the smallest relevant validation steps you ran - the exact scheme, simulator, and checks you used 搭建一个 SwiftUI 初始应用，加一个构建+启动脚本，我可以在本地环境绑定到 Build 操作上。 约束： - CLI 优先。优先用 Apple 的 xcodebuild，如果 Tuist 能让配置更干净也可以。 - 如果仓库里已有完整的 Xcode 项目，用 XcodeBuildMCP 列出 target，选对 scheme，构建、启动，迭代过程中截图验证。 - 已有的 model、导航模式和共享工具类，能复用就复用。 - 保持 iOS 和 macOS 兼容，除非我明确说只做一个平台。 - 每次改动后跑最小验证循环，通过了再扩展到更大范围的构建。 - 告诉我你是把这个当全新项目搭建的，还是在已有项目上改的。 交付： - 应用脚手架或请求的功能切片 - 一个包含完整命令的构建+启动脚本 - 你跑过的最小验证步骤 - 你用的 scheme、模拟器和检查方式

核心思路： CLI 优先，用 xcodebuild 而不是 Xcode GUI，这样 Agent 可以保持自动化循环。每次改完跑最小验证，通过了再扩展。

④ 从 Slack 启动编码任务

难度： 简单

在 Slack 里 @ Codex，它会把讨论线程变成一个 Codex 云端任务，完成后把结果链接发回线程。

Starter Prompt（在 Slack 线程里直接用）：

@Codex analyze the issue mentioned in this thread and implement a fix in [你的环境名称]. @Codex 分析这个线程里提到的问题，在 [环境名] 里实现修复。

技巧： 任务描述越具体越好。如果线程里的信息不够，补充相关文件路径、预期行为、约束条件。大代码库里最好指定相关的文件或目录。

⑤ 数据分析出报告

难度： 中等

给 Codex 一个数据集和一个问题，它会从数据清洗、合并、探索、建模到最终报告一路跑通。

Starter Prompt（完整版）：

I'm doing a data analysis project in this workspace. Goal: - Figure out whether [你的具体问题，如：houses near the highway have lower property valuations]. Start by: - reading AGENTS.md and explaining the recommended Python environment - loading the dataset(s) at [数据集路径] - describing what each file contains, likely join keys, and obvious data quality issues - proposing a reproducible workflow from import and tidy through visualization, modeling, and report output Constraints: - prefer scripts and saved artifacts over one-off notebook state - do not invent missing values or merge keys - suggest any skills or worktree splits that would make the workflow more reproducible Output: - setup plan - data inventory - analysis plan - first commands or files to create 我在这个工作区做一个数据分析项目。 目标： - 搞清楚 [你的具体问题，如：靠近高速公路的房子是否估值更低]。 先做这些： - 读 AGENTS.md，说明推荐的 Python 环境 - 加载 [数据集路径] 的数据集 - 描述每个文件包含什么、可能的关联键、明显的数据质量问题 - 提出一个可复现的工作流：从导入清洗到可视化、建模、输出报告 约束： - 优先用脚本和保存的产物，不要用一次性的 notebook 状态 - 不要自己编造缺失值或合并键 - 建议用哪些 skill 或 worktree 拆分来让工作流更可复现 输出： - 环境配置方案 - 数据清单 - 分析方案 - 首先要创建的命令或文件

推荐工具链： pandas + matplotlib 做分析，statsmodels 或 scikit-learn 做建模。源数据放 data/raw/，清洗后放 data/processed/。

⑥ 评分循环解难题

难度： 中等

把 Codex 当成一个"评分改进循环"：定义评估脚本 → 跑一次 → 看分数 → 改一处 → 重跑 → 直到达标。

Starter Prompt（完整版）：

I have a difficult task in this workspace and I want you to run it as an eval-driven improvement loop. Before changing anything: Read AGENTS.md. Find the script or command that scores the current output. Iteration loop: Make one focused improvement at a time. Re-run the eval command after each meaningful change. Log the scores and what changed. Inspect generated artifacts directly. If the output is visual, use view_image. Keep going until both the overall score and the LLM average are above 90%. Constraints: Do not stop at the first acceptable result. Do not revert to an earlier version unless the new result is clearly worse in scores or artifacts. If the eval improves but is still below target, explain the bottleneck and continue. Output: current best scores, log of major iterations, remaining risks or weak spots. 我在这个工作区有一个困难任务，请你用评分驱动的改进循环来解决。 改任何东西之前：先读 AGENTS.md，找到给当前输出打分的脚本或命令。 迭代循环：每次只做一处改进。每次有意义的改动后重新跑评分。记录分数和改了什么。直接检查生成的产物。如果输出是视觉类的，用 view_image 查看。持续改进，直到总分和 LLM 平均分都超过 90%。 约束：不要在第一个"还行"的结果上停下来。不要回退到旧版本，除非新结果的分数或产物明显更差。如果评分提升了但还没达标，说明瓶颈在哪，继续改。 输出：当前最佳分数、主要迭代记录、剩余风险或薄弱点。

核心纪律： 每次只改一处，改完就跑评估，记录分数变化。不要一口气改一堆然后发现不知道哪个变量起了作用。

其余 6 个用例速查

每个用例在官网都有完整的 starter prompt，点击即可加载到 Codex。

贯穿所有用例的方法论

看完 12 个用例，有几个反复出现的模式：

1. AGENTS.md 是核心

几乎每个用例都提到了"在 AGENTS.md 里定义规则"。这个文件告诉 Codex 项目的技术栈、编码规范、审查标准、验证方式。写得越具体，Codex 的输出越靠谱。

2. Skills 是标准化的能力包

playwright−interactive（浏览器测试）、playwright-interactive（浏览器测试）、 playwright−interactive（浏览器测试）、imagegen（图片生成）、slides（幻灯片编辑）、slides（幻灯片编辑）、 slides（幻灯片编辑）、chatgpt-apps（ChatGPT 应用开发）、$openai-docs（官方文档查询），这些 Skill 在用例之间反复被组合使用。

3. 验证循环是方法论的核心

不是"让 Codex 一次生成最终结果"，而是"做一步 → 验证 → 改 → 再验证"。前端用 Playwright 截图对比，游戏用浏览器实测，数据分析用评估脚本打分。自动化验证是让 Codex 能长时间无人值守运行的前提。

4. Worktree 隔离并行任务

多个方向的探索放在不同的 Git worktree 里跑，互不干扰。数据分析的清洗和建模分开，游戏的不同功能模块分开。改坏了一个方向不影响其他。

从零开始操作指南

1. 打开 Codex 用例库

2. 按角色或任务类型筛选，找到你想试的场景

3. 点击用例，看完整说明和 starter prompt

4. 如果装了 Codex App，直接点"Open in Codex"按钮，prompt 自动加载

5. 把 prompt 里的占位符换成你自己的信息（仓库名、数据集路径、具体问题）

6. 跑一次，看结果。不满意就调整 prompt 中的 constraints 部分

通用技巧： 所有用例都支持在仓库根目录放一个 AGENTS.md 文件，写上项目特定的规则和约束。Codex 每次执行前会先读这个文件，相当于给它一个持久的"项目上下文"。

这篇教程覆盖了 Codex 用例库全部 12 个场景，重点拆解了 6 个最实用的用例和完整 starter prompt。 🔗：Codex 用例库