评审提示为什么要分维度
自由发挥式的评审容易挑软柿子：反复说命名和注释，漏掉并发与安全。按维度分工（正确性、边界、并发、安全、性能、可读性）能保证覆盖面，再要求每条意见写清位置、问题、建议，输出才可执行。评审提示的产出是给人改代码用的，不是给人点赞用的。
基本信息
| 评审维度 | 正确性 / 边界 / 并发 / 安全 / 性能 / 可读性 |
|---|---|
| 单条结构 | 位置 + 问题 + 建议（三段式） |
| 缺项处理 | 没有发现问题的维度明确输出「无」 |
| 禁止项 | 「建议进一步优化」这类没有指向的意见 |
典型使用场景
- 合并请求（MR/PR）预审：先机器过一遍维度清单，减轻人工评审负担
- 关键路径代码复核：并发与边界维度重点检查，配合压测结论
- 历史代码巡检：按维度批量扫描存量代码，输出问题清单与优先级
- 接口变更审查：重点看兼容性、错误码与超时处理
- 安全相关改动：权限校验、输入校验、日志脱敏单独列维度
评审提示模板
评审提示模板
评审下面的代码，按维度逐条给出意见：
[维度] 正确性/边界/并发/安全/性能/可读性
[位置] 文件:行号或函数名
[问题] 具体描述（引用代码片段）
[建议] 可执行的修改方向
# 空维度也要表态，避免漏判被误读为「没问题」
没有发现问题的维度输出“无”；不要泛泛而谈“建议优化”。
# 大 diff 分批送审，一次只看一个文件或一个函数
分批建议：单次输入不超过 300 行 diff，按文件切分。
代码：<diff>……</diff>维度检查要点
| 维度 | 重点看什么 | 常见漏项 |
|---|---|---|
| 正确性 | 逻辑分支与返回值是否符合契约 | 异常路径返回值未覆盖 |
| 边界 | 空集合、零值、最大长度、时区 | 空输入与并发边界 |
| 并发 | 共享状态、锁粒度、幂等性 | 重试导致的重复副作用 |
| 安全 | 鉴权、输入校验、日志脱敏 | 越权访问与敏感信息落盘 |
| 性能 | 复杂度、循环内查询、批量操作 | N+1 查询与无分页全表扫描 |
| 可读性 | 命名、函数长度、注释必要性 | 过长的条件表达式 |
大 diff 一次性送审会漏：按文件或函数分批，每批只关注少数维度，命中率明显更高。
评审意见要能落到具体行。要求引用代码片段后，模型编造行号的情况会明显减少，人工核对也更快。