让 Codex “review 一下”通常会得到一长串泛泛建议。更有价值的审查，应该回答四件事：这次要达成什么、实际改了什么、哪里最可能出错、证据是否覆盖风险。把这四项给全，评论才会变成可处理的任务。
审查前准备一页上下文
写清需求链接或一句话目标、受影响路径、不可改变的行为、已运行的测试和已知限制。然后让 Codex 只审当前 diff，按严重程度输出问题，并要求每一项附上文件位置、触发条件和建议验证方式。
四栏审查法
| 栏位 | 要问的问题 |
|---|---|
| 需求 | 改动是否覆盖目标，是否悄悄改变旧行为？ |
| 变更 | 新增、删除和配置改动各自影响什么？ |
| 风险 | 边界值、权限、并发、空数据和失败路径是否处理？ |
| 测试 | 哪些检查已执行，哪些场景仍没有证据？ |
请只审查当前 diff。按“阻断、建议、待确认”分类。
每项必须包含：位置、触发条件、影响、最小验证方法。
如果没有证据，请写“无法确认”，不要臆测。最后由人决定是否修改。AI 适合快速扫出盲区，不替代对业务规则和上线后果的负责。
