工作流
用 Codex 做代码审查：从范围确认到可执行反馈
建立 Codex 代码审查工作流：读取差异、定位真实缺陷、运行相关检查，并输出带文件与行号的可执行反馈。
审查目标不是复述 diff
有价值的代码审查要指出会影响正确性、安全性、性能或维护性的具体问题，并说明触发条件。仅仅总结“新增了按钮、修改了接口”不能帮助作者修复缺陷。
推荐流程
- 确认审查范围：工作区、提交或 pull request；
- 阅读仓库的
AGENTS.md和相关模块； - 查看 diff，同时阅读变更前后的调用上下文；
- 针对高风险路径运行最小必要测试；
- 按严重程度输出发现，包含文件、行号、原因和修复方向；
- 如果没有发现问题，也要说明验证覆盖和剩余不确定性。
可以直接使用的任务描述
审查当前分支相对于主分支的变更。优先查找会导致错误结果、数据损坏、安全问题或明显回归的缺陷。阅读适用的 AGENTS.md，必要时运行相关测试。每条发现给出文件和最小行范围；不要把格式偏好当成缺陷。最后说明未覆盖的风险。
容易产生误报的地方
- 只看到新代码，没有读到上游校验；
- 把“可能更好”写成确定性 bug；
- 忽略项目已经明确接受的兼容性边界；
- 为证明问题而假设不存在的调用方式；
- 把测试缺失和真实功能错误混为一谈。
高质量反馈应该让作者能复现问题。无法确定时，写清假设和需要补充的证据。
合并前检查
审查结论通过后，仍应查看最终 diff、测试状态、生成文件、迁移和部署配置。Codex 可以辅助检查，但合并权限和上线责任仍属于团队。