当你把 Codex 当作一个拥有明确上下文、并且对“完成”有清晰定义的队友来使用时，它的效果最好。本页给出了面向 Codex IDE 扩展、Codex CLI 和 Codex Cloud 的端到端工作流示例。
如果你刚开始使用 Codex，建议先读 提示词，然后再回到这里看这些更具体的配方。
如何阅读这些示例
每个工作流示例都包含：
- 适用场景：什么时候该用，以及更适合在哪个 Codex 入口中使用（IDE、CLI 或云端）
- 步骤：附带示例提示词
- 上下文说明：Codex 会自动看到什么，以及哪些内容需要你主动附上
- 验证方式：如何检查输出结果
注意： IDE 扩展会自动把当前打开的文件带入上下文。在 CLI 中，你通常需要显式提到路径，或者使用
/mention和@路径补全来附加文件。
解释一个代码库
适用于你正在入门、接手某个服务，或者想理解一个协议、数据模型或请求流时。
IDE 扩展工作流（最适合本地探索）
打开最相关的文件。
选中你关心的代码（可选，但强烈推荐）。
向 Codex 发送提示词：
解释请求是如何在当前选中的代码中流转的。 请包括： - 每个相关模块职责的简要总结 - 数据在哪里被校验、校验了什么 - 修改这里时需要注意的一两个“坑点”
验证：
- 让 Codex 生成一份你可以快速核对的图解或检查清单：
把请求流总结成一个编号步骤列表，然后列出涉及到的文件。CLI 工作流（适合你想保留对话记录和 shell 命令时）
启动一个交互式会话：
codex附加文件（可选）并发送提示词：
我需要理解这个服务使用的协议。请阅读 @foo.ts @schema.ts，并解释 schema 以及 request/response 流程。重点关注必填字段与可选字段，以及向后兼容规则。
上下文说明：
- 在输入框中，你可以使用
@插入工作区内的文件路径，或使用/mention附加特定文件。
修一个 bug
适用于你已经能在本地复现故障行为时。
CLI 工作流（复现与验证形成紧凑闭环）
在仓库根目录启动 Codex：
codex把复现步骤以及你怀疑的文件一起告诉 Codex：
Bug：点击设置页上的 “Save” 有时会显示 “Saved”，但并没有真正持久化改动。 复现步骤： 1) 启动应用：npm run dev 2) 打开 /settings 3) 切换 “Enable alerts” 4) 点击 Save 5) 刷新页面：开关又恢复了 约束： - 不要改 API shape。 - 尽量做最小修复；如果可行，加一个回归测试。 先在本地复现这个 bug，再给出修复补丁并运行检查。
上下文说明：
- 由你提供：复现步骤和约束，这些通常比高层描述更重要。
- 由 Codex 提供：命令输出、它找到的调用点，以及过程中触发的堆栈信息。
验证：
- 修复后，Codex 应该重新执行复现步骤。
- 如果你有标准检查流水线，可以要求它运行：
修复后，运行 lint 和最小相关测试集，并汇报执行的命令与结果。IDE 扩展工作流
打开你认为 bug 所在的文件，以及它最近的调用方。
向 Codex 发送提示词：
找出导致 “Saved” 显示成功但并未真正保存的 bug。提出修复方案后，再告诉我如何在 UI 中验证它。
编写一个测试
适用于你希望非常明确地限定测试范围时。
IDE 扩展工作流（基于选区）
打开包含目标函数的文件。
选中定义该函数的代码行。在命令面板中选择 “Add to Codex Thread”，把这段代码加入上下文。
向 Codex 发送提示词：
为这个函数写一个单元测试，并遵循仓库里已有测试的约定。
上下文说明：
- “Add to Codex Thread” 会把你选中的代码行，也就是行号范围，以及当前打开的文件一起加入上下文。
CLI 工作流（在提示词中描述路径和函数）
启动 Codex：
codex使用函数名发送提示词：
在 @transform.ts 中为 invert_list 函数补一个测试。覆盖 happy path 和边界情况。
基于截图做原型
适用于你已经有设计稿、截图或 UI 参考图，并且想快速得到一个可运行原型时。
CLI 工作流（图片 + 提示词）
先把截图保存在本地，例如
./specs/ui.png。运行 Codex：
codex把图片文件拖进终端，把它附加到提示词中。
再补充约束和结构：
根据这张图片创建一个新的 dashboard。 约束： - 使用 react、vite 和 tailwind。代码请写成 typescript。 - 尽量贴近截图中的间距、字体和布局。 交付物： - 一个渲染该 UI 的新 route/page - 所需的小型组件 - 一个说明如何在本地运行的 README.md
上下文说明：
- 图片提供的是视觉要求，但你仍然需要明确实现约束，例如框架、路由方式和组件风格。
- 如果有不明显的行为，比如 hover 状态、校验规则或键盘交互，最好再用文字补充。
验证：
- 可以让 Codex 启动开发服务器，并明确告诉你应该去哪里看：
启动开发服务器，并告诉我查看这个原型的本地 URL / route。IDE 扩展工作流（图片 + 现有文件）
在 Codex 聊天中附加图片（拖放或粘贴）。
向 Codex 发送提示词：
新建一个 settings 页面。以附加的截图作为目标 UI。 同时遵循这个项目中其他文件已经存在的设计和视觉模式。
配合实时更新迭代 UI
适用于你想要保持“设计 → 微调 → 刷新 → 再微调”的紧凑迭代节奏时。
CLI 工作流（先跑 Vite，再用短提示词迭代）
启动 Codex：
codex在另一个终端窗口启动开发服务器：
npm run dev让 Codex 先提出一些改动方向：
为 landing page 提出 2 到 3 个样式改进方向。选定一个方向，再用小而具体的提示词继续迭代：
采用方案 2。 只改 header： - 让排版更有杂志感 - 增加留白 - 确保在移动端仍然好看用聚焦式请求继续重复迭代：
下一轮迭代：降低视觉噪音。 保留现有布局，但简化颜色并移除多余边框。
验证：
- 在浏览器中“实时”查看代码更新后的结果。
- 把你喜欢的改动提交，不喜欢的就回退。
- 如果你回退或手动修改了某个改动，记得告诉 Codex，避免它在下一轮提示词中把这些改动又覆盖掉。
把重构委派到云端
适用于你想先在本地谨慎设计，本地上下文更完整、检查也更快，再把耗时较长的实现工作外包给可并行运行的云任务时。
本地规划（IDE）
确保你当前的工作已经提交，或至少已经 stash，这样后续比较改动会更干净。
让 Codex 先产出一份重构计划。如果你有
$plan技能，可以显式调用它：$plan 我们需要把 auth 子系统重构为： - 拆分职责（token parsing、session loading、permissions） - 减少循环依赖 - 提升可测试性 约束： - 不改变用户可见行为 - 保持公开 API 稳定 - 给出分阶段迁移计划审查这份计划，并与 Codex 继续协商修改：
请修订这份计划： - 明确每个 milestone 会移动哪些文件 - 加入回滚策略
上下文说明：
- 当 Codex 能在本地扫描当前代码时，规划效果最好，例如入口点、模块边界和依赖关系线索。
云端委派（IDE → 云端）
如果你还没有配置，请先设置一个 Codex 云端环境。
点击提示词输入框下方的云图标，并选择你的云端环境。
在下一条提示词中，Codex 会在云端创建一个新线程，并继承当前线程上下文，包括计划以及任何本地源码改动。
按计划实现 Milestone 1。审查云端 diff，如有需要继续迭代。
直接在云端创建 PR，或者把改动拉回本地测试并收尾。
对计划中的更多 milestone 重复这个流程。
做一次本地代码审查
适用于你想在提交或创建 PR 之前，先获得第二双眼睛时。
CLI 工作流（审查当前工作树）
启动 Codex：
codex运行 review 命令：
/review可选：追加更明确的关注点说明：
/review 重点检查边界情况和安全问题
验证：
- 根据 review 反馈修复问题，然后重新运行
/review，确认这些问题已经解决。
审查 GitHub 拉取请求
适用于你不想把分支拉到本地，也希望先获得评审反馈时。
在使用这个能力之前，请先为你的仓库启用 Codex Code review。参见 GitHub 代码评审。
GitHub 工作流（基于评论触发）
打开 GitHub 上的拉取请求。
留下一条评论，并明确
@codex你的关注点：@codex review可选：追加更明确的说明。
@codex review for security vulnerabilities and security concerns
更新文档
适用于你需要做一处准确且清晰的文档改动时。
IDE 或 CLI 工作流（本地改动 + 本地校验）
找到要修改的文档文件，并在 IDE 中打开，或在 IDE / CLI 中用
@提及它们。给 Codex 明确范围和校验要求：
更新 “advanced features” 文档，补充认证排障说明。并验证所有链接都有效。当 Codex 起草完改动后，审查文档，再按需继续迭代。
验证：
- 阅读渲染后的页面。