用好 Codex（开发者进阶）
典型工作流
四个最常用的 Codex 工作流：读懂陌生代码、修 bug、写测试、代码审查，每个都附提示词示例和验证方法。
下面四个场景覆盖了日常大部分用法。每个场景都给出提示词示例，以及怎么确认 Codex 做对了。
开始任何会改代码的任务前，先 git commit 留一个检查点。
读懂陌生代码
适合刚接手项目、看别人的服务、梳理数据流时。这类任务只读不写，可以用只读模式（/permissions 切到 Read Only）。
codex我需要理解这个服务用的协议。读一下 @foo.ts @schema.ts，
讲讲数据结构和请求/响应流程，重点说明必填和可选字段，以及向后兼容的规则。怎么验证：让它输出一份你能逐条对照的清单。
把请求流程整理成编号步骤，然后列出涉及的文件。修 bug
能在本地复现的 bug，用 CLI 效果最好：Codex 可以自己跑复现步骤、看报错、改代码、再跑一遍验证。
Bug：<一句话描述现象>
复现：
1) <步骤>
2) <步骤>
期望：<应该是什么样>
实际：<现在是什么样>
约束：
- 改动尽量小，不改公共接口。
- 能加回归测试就加一个。
先复现，再修，最后跑 lint 和最相关的测试，报告运行的命令和结果。你提供：复现步骤和约束（这比笼统描述重要得多）。 Codex 提供：命令输出、它找到的调用位置、触发的堆栈信息。
怎么验证：Codex 修完应该重新跑复现步骤；你再用 /diff 看一遍改动。
写测试
给 @src/transform.ts 里的 invert_list 函数补测试，
覆盖正常情况和边界情况，风格参考项目里已有的测试。在 IDE 扩展里，可以先选中函数，用命令面板里的 Add to Codex Thread 把它加进对话，再说"给这个函数写单元测试，沿用其他测试的写法"。
怎么验证：
- 让 Codex 运行新测试，确认通过；
- 故意改坏被测函数，看测试能不能抓住，再改回来。
代码审查
本地审查
改完代码、提交之前：
/review可以选：
- Review against a base branch：相对某个基础分支审查整个分支的改动；
- Review uncommitted changes：审查所有未提交的改动（已暂存、未暂存、未跟踪的都算）；
- Review a commit：审查某一个提交；
- Custom review instructions：按你给的标准审查。
审查只出意见、不会修改你的工作区。要换一个模型专门做审查，在配置里设置 review_model。
也可以在终端里直接跑，适合放进脚本：
codex review --uncommitted
codex review --base main
codex review --commit <SHA>GitHub PR 审查
在 PR 评论里写 @codex review，详见云端任务与 GitHub。
一个完整的节奏
- 开新对话，一次只做一件事；
- 先读后写：让 Codex 讲清楚相关代码，确认它的理解没问题；
- 大任务先
/plan，确认方案再动手； - 小步修改，每步都让它跑测试；
/diff+/review，自己再看一遍；- 提交，然后
/new开始下一个任务。