怎么让 code review 真的有用，而不是挑格式
有用的 review 只回答两件事：这次改动会不会出错，出了问题能不能发现。其余都是次要的。
怎么做
作者先自己审一遍
提 PR 之前，把 diff 贴进「代码审查」，只保留会导致 bug、安全和性能的问题，按严重程度排序，每处给出触发条件和改法。先修完再叫同事，能省掉一轮来回。风格问题交给 linter，不要占用 review 的注意力。
补上能证明改动正确的测试
把实现和现有测试给「给测试用例挑漏」。列清未覆盖的分支，按线上影响补前五个用例，删掉重复和断言实现细节的测试。reviewer 看到的不只是「我加了测试」，而是每个失败场景对应哪条用例，讨论会具体很多。
reviewer 先看影响面，再看代码
把 diff、依赖关系和流量规模给「估算一次改动的风险面」。列受影响的调用方、数据和定时任务，按影响人数和恢复难度排前三，给出回退指标。影响面大的改动，review 的重点应该放在回退方案和上线顺序，而不是变量命名。
盯住失败路径
把改动里处理错误的部分给「审查错误处理」。只看被吞掉的异常、无法定位的报错、不安全的重复写入、该失败却继续跑的地方。这类问题很难靠测试覆盖，通常要有人逐条读代码才能发现。
有并发的地方单独过一遍
如果改动涉及共享状态，把相关代码给「并发与竞态审阅」。假设两个请求同一毫秒到达，列共享可变状态、检查与使用之间的间隙、什么并发量会暴露、最小改法和各自的代价。没有共享状态就跳过，不要为了凑流程硬套。
用到的提示词
常见问题
AI code review 能代替同事 review 吗
不能。AI 通常能查出注入、空指针、N+1 这类模式化问题，但它不知道你们的业务约束、历史事故和发布节奏。同事 review 的价值在于判断这个改动该不该现在做、会不会和别的改动冲突。
review 意见太多，怎么排优先级
先按会不会导致数据错误或线上故障筛一遍，再看触发条件是否现实。风格类意见交给 linter 和格式化工具，不进入 review 讨论；剩下的按「改起来便宜、收益明确」先做。
小改动也要走这套流程吗
不必全套。改一行配置可以只做第 1 步并确认回退方式；涉及共享状态、权限、钱的改动，第 4、5 步不能省。按出错后果来决定投入，而不是按改动的行数。