老王带新人，最累的不是自己写，是审别人的代码。人审代码容易两个毛病：看顺了就放过、看烦了就批"重写"。让 Claude 当第一道关，不是取代人，是替你把那些"明显但该花时间"的刺先挑出来。
怎么贴，比贴什么重要。别只丢一个函数，要给上下文：这段改了什么、为什么改、跑在什么环境。最好直接贴 git diff 的输出，Claude 能区分"新增"和"改动"，判断更准。
指令要它"只挑刺"。模型默认讨好，会顺手夸你代码优雅。所以开头就摁住：
你是一名资深 reviewer，请审查下面的 git diff。 只输出问题，不要夸。每条包含： - 严重度（阻塞/建议/风格） - 位置（文件:大致行） - 问题（一句话） - 为什么（可能踩的坑） - 修改建议（给代码片段） 重点看：空值/边界、并发、错误处理、命名误导、重复逻辑。
重点看它揪出的三类。一是"空值/边界"：函数没判入参为 null、数组越界、除零——人疲劳时最容易漏。二是"错误处理"：catch 了却吞掉、该抛没抛。三是"命名误导"：叫 getUserInfo 却可能返回 null，这种埋雷最阴。Claude 对这些不厌其烦，正好补你的倦。
验收与边界。它给的建议别照单全收——尤其是"重构一下结构"这种大动作，可能引入新 bug。把"阻塞"级的一条条改，"建议"级的挑顺手的，"风格"级的大部分可以忽略。记住：AI 审查是放大镜，不是裁判，最终能不能合，还是你和团队说了算。
配合 Claude Code 用更顺：在终端里直接让它审当前改动，改完再让审一遍，形成"写—审—改"的小循环。等真要人 review 时，低级刺早被挑光了，同事只会看到你逻辑上的巧思。