提交之前，让 Codex 做一次有重点的代码审查

代码能够构建，不代表改动已经准备好提交。一个新判断分支可能漏掉空值，一处缓存调整可能影响另一种查询，一个看似简单的按钮改名也可能破坏自动化定位。审查的重点，是把这些行为变化和触发条件找出来。

先明确比较什么

“检查一下代码”没有给出范围。应明确检查未提交改动、某一次提交，还是当前分支相对目标分支的差异。还要说明改动想实现的行为，否则审查者很难区分缺陷与有意调整。

在 Git 项目中，Codex 的内置 /review 可以检查本地变更，并给出按优先级排列的发现；官方文档说明，该审查不会修改工作区。审查与后续修复可以分开进行。[1]

给出项目真正关心的风险

搜索功能可以重点看查询参数、空结果和分页；支付回调应重点看幂等性、金额和状态转换；导出功能要关注权限、字段和大数据量。一个任务只需要列出最相关的几项，不必把所有工程规范都重复一遍。

请审查当前分支相对目标分支的改动，先确认比较范围。
这次改动为文章列表增加分类筛选。

重点检查：
1. 默认访问是否仍显示全部文章。
2. 分类与搜索同时使用时，结果是否正确。
3. 浏览器后退、刷新与空结果是否保持一致。

先只报告问题，不修改文件。
每条发现给出位置、触发条件、实际行为和预期行为。
没有足够证据的疑点请单独说明。

一条发现应该包含什么

有价值的发现不只是一句“这里可能有问题”。它应描述一个具体输入或状态，并把它连接到代码路径和后果。比如：先选择分类，再输入关键词，随后清空关键词时分类状态被重置，导致结果超出用户选定范围。

拿到发现后，先重现它。确认涉及当前版本，确认预期行为有依据，再决定修复。模型提出的问题可能建立在错误假设上；把每条意见都当成必改项，反而可能引入新的问题。

修复之后，检查新的差异

把确认的问题交给 Codex 修复时，明确保留其他改动。修复完成后，重新检查相关测试和最新差异，避免沿用修改前的审查结论。

如果一条修复引出了公共接口变化，原来的局部测试可能不够；如果只是修正一个孤立分支，则优先运行覆盖该分支及相邻行为的检查。验证范围应跟随风险变化，而不是机械地重复所有操作。

把结论写成可交接的结果

最终记录可以很短：检查了什么范围、确认了哪些问题、哪些已修复、执行了哪些检查，还有哪些环境无法验证。“没有发现问题”只描述本次审查结果，不等于对所有输入和部署环境作出保证。

良好的审查让下一位维护者看见判断依据，也让提交者知道这次变更剩下的风险在哪里。