官方原文索引： Workflows – Codex / Codex Use Cases
1. 核心架构与原理解析
高效的 Codex 工作流不是"问一个问题等回答"，而是人机协作的流水线。设计良好的工作流应明确：
| 阶段 | 人类职责 | Codex 职责 |
|---|---|---|
| 需求澄清 | 描述业务目标、验收标准 | 追问边界条件、提出技术方案 |
| 方案设计 | 确认架构方向 | 生成技术方案文档、绘制流程 |
| 编码实现 | 审批关键决策 | 编写代码、运行测试、修复错误 |
| 质量验证 | 审查最终产出 | 自测、生成测试报告、修复回归 |
| 交付归档 | 合并代码、发布 | 生成变更日志、更新文档 |
2. 工程落地与代码示例
工作流 A：功能开发（Feature Development）
# 1. 需求澄清（Read Only 模式）
codex --sandbox read-only
> 我需要一个用户邀请功能：被邀请用户通过链接注册后，
> 邀请双方各获得 10 积分。请列出需要修改的文件和数据库变更。
# 2. 方案设计（Plan 模式）
> /plan
> 按上面的需求实现邀请功能，先给出完整方案。
# 3. 编码实现（Full Auto 模式）
> 按确认的方案执行，每完成一个模块运行对应测试。
# 4. 代码审查
> /review main
# 5. 交付
> 生成本次变更的 CHANGELOG 条目工作流 B：Bug 排查（Incident Response）
# 1. 接收错误信息（管道输入）
cat error.log | codex exec --sandbox read-only "定位错误根因"
# 2. 深入分析
> 追踪这个错误在代码中的传播路径，列出所有相关文件。
# 3. 修复验证
> 修复根因并补充防御性代码，运行测试验证。
# 4. 复盘归档
> 生成 incident report：根因、修复方案、预防措施。工作流 C：技术债务清理（Tech Debt）
# 1. 扫描债务
> 扫描项目中所有 TODO/FIXME，按严重性和影响面排序。
# 2. 分批处理
> 先处理影响面最小的 3 个 TODO，逐个修复并测试。
# 3. 持续迭代
# 每天启动时处理 2-3 个，避免大规模重构风险工作流 D：API 文档同步
# 1. 检查文档一致性
> 对比 src/routes/ 下的实现和 docs/api.md 的文档，找出不一致的地方。
# 2. 同步更新
> 根据最新代码更新文档，确保每个端点都有：路径、方法、参数、响应示例。
# 3. 验证
> 检查更新后的文档是否完整准确。3. 场景深入：团队工作流标准化
场景：每日站会前的代码审查
场景：Sprint 结束时的技术债务日
# 每周五下午：Tech Debt Friday
# 1. 生成债务清单
codex --sandbox read-only
> 扫描项目中的技术债务：
> - 重复代码片段
> - 未处理的 TODO
> - 过时的依赖
> - 缺失的测试
> 按影响面和修复成本排序。
# 2. 分配任务
# 团队每人认领 1-2 个债务项
# 3. 修复验证
> 修复分配的债务项，运行测试确认无回归。
# 4. 归档
> 生成本周 Tech Debt 清理报告。场景：新人 Onboarding
# Day 1：理解项目
codex --sandbox read-only
> 请详细解释这个项目的架构，包括：
> 1. 技术栈和选型原因
> 2. 目录结构说明
> 3. 关键设计决策
> 4. 常见开发流程
# Day 2：修复第一个 Bug
> 请指导我修复这个入门级别的 Bug：[附上 issue 链接]
# Day 3：独立完成小功能
> 请 review 我写的代码，给出改进建议。4. 💡 核心避坑与最佳实践 (Takeaways)
- 每个工作流以 Read Only 开始：先用只读模式探查和规划，确认方向后再切写入模式
- Plan → Execute → Review 是黄金三角：跳过任一环节都会增加返工概率
- 用
/fork尝试不同方案：对不确定的技术选型，分叉会话并行对比 - 会话即工作单元：一个会话对应一个独立任务，完成后
/export归档便于追溯 - 建立团队工作流模板：把常用工作流写成文档，新人直接套用
- 自动化重复工作流：把频繁的审查、文档同步任务写成
codex exec脚本