| name | code-review |
| description | 对代码变更进行审查,检查正确性、边界、性能、规范。 |
| version | 1.1.0 |
Code Review · 审查方法
你的任务
审查步骤 3 产出的所有代码变更,从多个维度检查质量。审查前先验证代码实际行为。
审查流程
0. 审查前验证
在静态审查之前,先验证代码的实际运行行为:
-
检测测试配置:
- 用 Glob 检查项目根目录有无
package.json
- 有则读取
scripts.test 字段,确认测试命令
- 也检查有无
pytest、go test、cargo test 等其他测试配置
-
运行测试(如有测试配置):
- 执行测试命令,记录结果
- 将测试通过/失败/跳过数量记入审查报告
- 如有失败的测试,先修复再进入审查
-
运行类型检查(如有配置):
- 检查有无
typecheck 脚本,或项目使用 tsc --noEmit
- 记录类型检查结果
-
无测试配置时:
- 标注"项目无测试配置,仅做静态审查"
- 不阻塞审查流程
1. 查看变更文件
用 git diff 或 Read 查看所有变更文件。
2. 逐文件审查
按以下 6 个维度检查每个文件。
3. 标注严重级别
对每个问题标注级别:
- 🔴 必须修复:逻辑错误、安全问题
- 🟡 建议修复:性能问题、规范问题
- 🔵 可选:代码风格、小优化
4. 在对话中输出审查报告
审查维度
1. 正确性(最重要)
- 逻辑是否正确(对照对话中确认的验收标准;验收标准里的视觉规格项——列归属/文案/合并/顺序/所属页签——同样逐条核对,见维度 6)
- 边界条件是否处理
- 空值/异常是否防御
- 数据计算是否正确
2. 边界与安全
- SQL 是否有注入风险
- 用户输入是否校验
- 权限控制是否正确
- 敏感数据是否暴露
3. 性能
- 是否有 N+1 查询
- 大数据量场景是否分页
- 是否有不必要的循环或重复计算
4. 规范
- 命名是否符合项目规范
- 代码风格是否一致
- 注释是否充分
- 文件结构是否合理
5. 可维护性
- 代码是否易读
- 是否有重复代码
- 是否过度设计
- 是否容易测试
6. 视觉规格落地(仅当验收标准含视觉规格项)
对照 PRD 截图/原型逐条比对实现:
- 字段列归属是否一致(该折进已有列的没做成独立列)
- 按钮/菜单文案是否与 PRD 图逐字一致(不自拟、不增减字)
- 入口所属页签/区域是否一致(不新建 PRD 图未要求的页签)
- 筛选项、字段的位置与顺序是否与图一致
凡 PRD 图已给出的位置/文案视为硬性验收项,不符即 🔴。
输出格式
在对话中按以下格式输出审查报告:
## 代码审查报告
### 🧪 运行结果
- 测试:N 通过 / M 失败 / K 跳过
- 类型检查:通过/失败
- (或"项目无测试配置,仅做静态审查")
### 🔴 必须修复(N 项)
1. **<文件:行号>**:<问题描述>
- 原因:<为什么是问题>
- 建议:<修复方案>
### 🟡 建议修复(N 项)
1. **<文件:行号>**:<问题描述>
- 建议:<改进方案>
### 🔵 可选优化(N 项)
1. **<文件:行号>**:<问题描述>
### 总结
- 必须修复:N 项
- 建议修复:N 项
- 可选优化:N 项
- 整体评价:<一句话总结>
注意事项
- 如果有 🔴 必须修复项,回到步骤 3 修复后重新审查
- 不要纠结于代码风格问题(那是 linter 的事);但 PRD 图已定死的界面位置/文案属必查项、非风格问题,实现与图不符即 🔴
- 重点关注逻辑正确性和安全问题
- 审查意见要具体到文件和行号,不要泛泛而谈
- 运行结果是审查报告的第一部分