Skip to content

工作流

当你像对待队友一样为 Codex 提供明确的上下文和清晰的"完成"定义时,它表现最佳。

本页提供 Codex IDE 扩展、Codex CLI 和 Codex Cloud 的端到端工作流示例。

如果你是 Codex 新手,请先阅读提示(Prompting),然后再回到这里查看具体操作。

如何阅读这些示例

每个工作流包括:

  • 适用场景以及最适合的 Codex 平台(IDE、CLI 或 Cloud)
  • 步骤以及示例用户提示
  • 上下文说明:Codex 自动能看到什么,以及你应该附上什么
  • 验证方法:如何检查输出

注意: IDE 扩展会自动将你打开的文件作为上下文。在 CLI 中,你通常需要显式指定路径(或使用 /mention@ 路径自动补全来附加文件)。


解释代码库

适用于新成员入职、接手现有服务,或理解协议、数据模型、请求流程的场景。

IDE 扩展工作流(本地探索最快)

  1. 打开最相关的文件
  2. 选中你关心的代码(可选,但建议这样做)
  3. 向 Codex 提问:
    解释请求如何通过所选代码流转。
    包括:
    - 每个涉及模块的职责简要说明
    - 哪些数据在哪些地方被验证
    - 修改时需要注意的一两个"坑"

验证:

  • 请求生成一个图表或清单以便快速验证:
将请求流程总结为编号步骤列表。然后列出涉及的文件。

CLI 工作流(适合需要记录和 shell 命令的场景)

  1. 启动交互式会话:

    bash
    codex
  2. 附加文件(可选)并提问:

    我需要理解这个服务使用的协议。阅读 @foo.ts @schema.ts 并解释架构和请求/响应流程。重点关注必填字段与可选字段以及向后兼容性规则。

上下文说明:

  • 你可以在 composer 中使用 @ 插入工作区中的文件路径,或使用 /mention 附加特定文件。

修复 Bug

适用于你可以在本地复现的失败行为。

CLI 工作流(复现与验证的紧凑循环)

  1. 在仓库根目录启动 Codex:

    bash
    codex
  2. 给 Codex 一个复现步骤,加上你怀疑的文件:

    Bug: 在设置屏幕上点击"保存"时,有时显示"已保存"但更改并未持久化。
    复现步骤:
    1) 启动应用:npm run dev
    2) 访问 /settings
    3) 切换"启用通知"开关
    4) 点击保存
    5) 刷新页面:开关重置为关闭状态
    约束:
    - 不要更改 API 结构
    - 不要更改数据库 schema
    - 首先检查前端状态处理,只在必要时才查看后端

验证:

  • Codex 运行修复后,要求它展示变更内容:
展示你更改的所有文件以及每处更改的原因。
  • 然后运行你的测试套件:
bash
npm test
  • 手动复现 Bug 确认修复。

IDE 扩展工作流

  1. 打开你认为包含 Bug 的文件
  2. 使用编辑器中内联的 Codex 提示:
    当我在 /settings 上切换"启用通知"并点击保存时,更改没有持久化。选中代码显示了保存处理逻辑。找出 Bug 并在编辑器中直接应用修复。

添加功能

适用于在现有代码库中添加新功能或端点。

Cloud 工作流(适合异步/后台任务)

  1. chatgpt.com/codex 打开 Codex Cloud
  2. 附加上下文(Issue、PR、相关文件):
    Issue #42: 在设置页面上添加"深色模式"切换开关
    相关文件:@SettingsPage.tsx @theme.ts
  3. Codex 分析请求并提供实施计划后,批准执行

验证:

  • 审查生成的 PR 中的 diff
  • 本地检出分支并测试
  • 运行现有测试确认没有回归问题

IDE 扩展工作流

  1. 打开需要修改的文件
  2. 描述需求:
    在设置页面上添加深色模式切换开关。使用 @theme.ts 中的主题上下文。切换开关应该:
    - 是一个在明/暗之间切换的开关组件
    - 将偏好设置持久化到 localStorage
    - 在页面加载时读取已保存的偏好设置
    - 与现有样式和布局兼容

重构代码

适用于在不改变行为的情况下改进代码结构。

IDE 扩展工作流

  1. 打开你要重构的文件或文件夹
  2. 提供上下文和约束:
    将 @api/routes.ts 拆分为按领域组织的独立路由模块(users.ts、orders.ts、products.ts)。
    约束:
    - 保持相同的公开 API 结构(路由、中间件)
    - 更新 @api/index.ts 中的导入
    - 不要更改测试 —— 重构后它们应该仍然可以通过

验证:

  • 运行测试确认没有破坏任何功能
  • 要求 Codex 总结所做的更改:
列出拆分的文件以及更新了哪些导入。

编写测试

适用于为现有代码添加测试覆盖。

CLI 工作流

  1. 在仓库中启动 Codex:

    bash
    codex
  2. 提示:

    为 @utils/formatDate.ts 中的所有函数编写单元测试。
    - 使用 Vitest
    - 测试正常情况和边界情况
    - 包括无效输入的测试

验证:

  • 运行测试确认通过
  • 检查覆盖了哪些边缘情况
  • 对可疑逻辑添加额外测试

代码审查(Review)

适用于在合并前让 Codex 审查更改。

IDE 扩展工作流

  1. 打开包含更改的文件或查看 GitHub PR
  2. 提示 Codex:
    审查我对 @checkout.ts 的更改。
    查找:
    - 逻辑错误
    - 未处理的边界情况
    - 安全问题(如 XSS、注入)
    - 性能问题
    - 与现有代码风格的一致性

后续步骤

由 Codex 构建