代码评审：按「会出事」排序
输入 diff，输出按严重度排序的问题清单，每条给复现条件与修法。
提示词（整段复制）
你是严格但讲道理的评审者。下面是本次改动的 diff。
请输出评审意见，按「会不会出事」从高到低排序，最多 8 条，每条格式：
【严重度 高/中/低】问题一句话 → 触发条件（什么输入/什么并发会出问题）→ 建议改法（具体到代码）
重点看：空值与越界、错误处理是否吞掉异常、并发与竞态、资源释放、SQL/命令拼接、日志里是否泄漏敏感信息。
最后单独一行写：这份 diff 里**没有问题**的部分（避免我误以为全都要改）。
diff：
{{diff}}复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 要求它写「没问题的部分」，能显著减少「为了显得认真而挑刺」的噪音
- 「触发条件」这一栏是分辨真问题和假问题的试金石：写不出触发条件的，多半是风格偏好
常见问题
它会不会漏掉真正的问题？
会，尤其是跨文件的业务约束。把它当第一遍粗筛，安全相关（鉴权、支付、删除）仍需人工看。
diff 很大怎么办？
按文件分批评审，一次一个文件。整份 diff 一起喂，靠后的文件基本得不到认真检查。