你让 Codex review 一个 PR。它给了 8 条 code-review 模板话：「考虑下错误处理」「补 edge case 测试」「线程安全？」「注意 null 输入」。这种话 2018 年 AI 读不懂代码时还有用，现在没用——你按它没法动手，也看不出 Codex 到底打开过那些被改的文件没。
浅 review 几乎都是模糊 prompt 导致的。「review 这个 PR」触发模型默认的”总结模式”；具体问题 + file:line 锚定才能换来具体答案。下面六个 prompt 模板能产出值得读的 review。
常见原因
按命中率从高到低：
1. Prompt 就是「review 这个 PR」没标准
泛 prompt → 泛 review。Codex 套模板，因为没东西告诉它「在这段具体代码里找什么」。
如何判断：回看 prompt——没指明维度（security / perf / correctness / API contract）或具体关切，就是套模板。
2. Codex 看 diff 没读完整文件
光 diff 缺上下文——3 行改动可能正确也可能灾难，取决于函数其他部分。不读整文件，review 只能评论 diff 显示的那几行。
如何判断：review 评论只引 diff 里的行，不涉及周围上下文——Codex 漏了大图景。
3. PR 太大、Codex 抽样了
1500 行 PR 超上下文。Codex 前几个文件细读，后面的抽样或摘要。前面文件评论密、后面稀。
如何判断：每文件评论密度不均——前 3 个有具体反馈、后 7 个一人一句泛话。
4. Codex 用了”安全的 reviewer 嗓音”
没锚定时 Codex 退回到”非承诺”措辞：「考虑」「你也许想」「注意」——既不指出确定问题、也不可被反驳。
如何判断：数「考虑」「也许」「可能」的次数——多就是 hedging 模式，不是真 review。
5. 没给 threat model / 上下文
Codex 不知道 PR 在支付路径。它当通用 CRUD review——具体关切（幂等、竞态、欺诈面）不会出现，因为没东西告诉 Codex 这是高风险代码。
如何判断：review 该提的 domain 风险一个没提——明明在那种代码里。
6. Review prompt 一次问太多
「review correctness + security + perf + style + a11y」——每个维度都浅一遍——它努力照顾全维度反而每个都浅。
如何判断：review 触及很多维度但每个都不深。
最短修复路径
按收益从高到低，Step 1 一步带来 80% 的深度提升。
Step 1：把「review 这个 PR」换成聚焦问题
模板：
按 [具体关切] review 这个 PR。
每条问题：
- file:line（必填——不接受泛话评论）
- 一句话问题描述
- 一句话修法
- 严重度（P0 阻塞 / P1 merge 前 / P2 follow-up）
不要评论 style / 格式 / 其他 ESLint 能 catch 的东西。
不要写「考虑 X」——要么标 X 为问题，要么不提。「不要考虑 X」这条最关键——堵掉 hedging 退路。
Step 2：一次 review 只问一个问题
不要打包维度，独立跑：
Pass 1：「按 correctness review。是否有任何合法输入会得到错误结果？」
Pass 2：「按 null/undefined 处理 review。列出每处新代码在没检 null 前就 deref。」
Pass 3：「按 API 合同变化 review。这个 PR 是否改了任何 public 签名 / 行为？」每 pass 都比一次大杂烩深。
Step 3：前置 context
Context：这个 PR 在支付路径，~10K 笔/天。
我们关心：
- 幂等（同一请求两次不能双扣）
- 竞态（两个并行 webhook 更新同一订单）
- 审计（每次状态变更必须 log 谁 / 何时 / 从什么状态）
仅按这些关切 review，其他维度不管。Domain context 让通用 review 升级成 domain review。
Step 4：对抗式 framing
试试把这段代码打挂：
- `processPayment(req)` 能收到的最坏输入是什么？
- 最坏的并发时序（race condition）是什么？
- 什么状态会让这个函数违反前置/后置条件？
每条给出 输入 + 期待 vs 实际 行为。对抗式问题逼 Codex 从”看着合理”切到”找失败”模式。
Step 5：抽查校准
不要全盘信。挑 2 条评论核实：
review 声称："billing.ts:42 有 read 和 update 之间的竞态。"
打开 billing.ts:42 读周围代码，自己判断。抽查通过——其他评论可信度高。抽查不通过（“42 行什么都没有”）——是幻觉，重 prompt。
Step 6：没 file:line 锚的评论直接拒
Codex 出「考虑下错误处理」没行号，推回去：
「考虑下错误处理」不可执行。每条问题必须：
- 具体 file:line
- 出问题的精确代码行
- 什么输入触发什么错误
按这些约束重 review，锚不上的条删掉。这是给 session 训练——后续 review 会保持具体。
预防建议
- 维护一个 review prompts 目录，每个关切一份（security / perf / correctness）
- 始终前置 domain context（这是支付 / auth / 内部工具）
- 强制 file:line + severity，缺一即拒
- 跑多个窄 review pass，不要一次大杂烩
- 每份 review 抽查 2 条校准信任
- 重要 PR 上 AI review 是补充，不是替代——人工 review 不能省