代码评审评分协议

技能文档

---
name: review-scoring
description: 代码评审量化评分协议。提供 10 个维度的加权评分细则（每维 0-10 分），覆盖正确性、完整性、安全性、性能、规范一致性、可测试性、可读性、错误处理、类型安全与集成性，并给出 PASS/CONDITIONAL PASS/FAIL 判定阈值与确定性输出格式校验脚本，适用于 Work-Review-Fix-Check（WRFC）循环或任何需要对代码实现做量化评审的场景。当用户要求「评分审查」「量化评审」「给代码打分」「按评分细则审查」时触发。触发词：代码评分、评审细则、打分审查、WRFC、质量评分。
title: 代码评审评分协议
category: 开发工具
---

# 代码评审评分协议

定义 Work-Review-Fix-Check（WRFC）循环中使用的精确评分细则与评审输出格式，保证代码质量评估的一致性、可量化，并可对评审输出做确定性校验。

## 技能工作流

### 步骤1：按 10 维度逐项评分

每维 1-10 分：**1-3** 严重缺陷；**4-5** 明显问题、低于可接受标准；**6-7** 可接受但有明显问题；**8-9** 良好、有小问题；**10** 卓越、可上生产。

| # | 维度 | 权重 | 关注点 |
|---|------|------|--------|
| 1 | 正确性 Correctness | 20% | 逻辑无误、边界处理、空值检查、无 off-by-one、无竞态、Promise 无未捕获拒绝 |
| 2 | 完整性 Completeness | 15% | 功能完整、无 TODO/占位/注释掉的代码、关键路径齐全 |
| 3 | 安全性 Security | 15% | 输入校验、鉴权检查、密钥不泄漏、防注入、CORS/CSRF 配置 |
| 4 | 性能 Performance | 10% | 无 N+1 查询、索引合理、按需缓存与 memoization、无内存泄漏与阻塞 |
| 5 | 规范一致性 Conventions | 10% | 命名、目录结构、import 顺序、代码风格与项目既有模式一致 |
| 6 | 可测试性 Testability | 10% | 测试存在且有意义、覆盖边界、断言有效、不脆弱 |
| 7 | 可读性 Readability | 5% | 命名清晰、抽象适度、函数不超 50 行、嵌套不超 4 层 |
| 8 | 错误处理 Error Handling | 5% | 错误被捕获并记录、面向用户的消息清晰、无静默失败 |
| 9 | 类型安全 Type Safety | 5% | 类型准确、无滥用 `any`、泛型使用得当、不关严格模式 |
| 10 | 集成性 Integration | 5% | 与既有代码无缝协作、不破坏现有功能、遵守 API 契约、复用共享工具 |

每维评分需对照「评分标准 + 常见问题」逐条核对；详细示例见 `references/scoring-examples.md`。

### 步骤2：计算总分并判定

总分为加权平均：

```
总分 = 正确性×0.20 + 完整性×0.15 + 安全性×0.15 + 性能×0.10 + 规范×0.10
     + 可测试性×0.10 + 可读性×0.05 + 错误处理×0.05 + 类型安全×0.05 + 集成性×0.05
```

判定阈值：

| 分数区间 | 判定 | 后续动作 |
|----------|------|----------|
| ≥ 9.5 | PASS | 可交付，生产就绪 |
| 8.0-9.49 | CONDITIONAL PASS | 小问题——修复后快速复查即可（8.0 含，无需完整重审） |
| 6.0-7.9 | FAIL | 问题较多——修复后必须完整重审 |
| < 6.0 | FAIL | 需要大改——修复后必须完整重审 |

**关键维度规则**：任一维度得分低于 4，无论总分多少，直接判 FAIL。

### 步骤3：按固定格式输出评审

每次评审必须产出以下结构（校验脚本按此格式检查，标记词保持英文原样）：

```markdown
## Review Summary
- **Overall Score**: X.X/10
- **Verdict**: PASS | CONDITIONAL PASS | FAIL
- **Files Reviewed**: [文件列表]

## Dimension Scores
| Dimension | Score | Notes |
|-----------|-------|-------|
| Correctness | X/10 | [具体发现] |
| Completeness | X/10 | [具体发现] |
| Security | X/10 | [具体发现] |
| Performance | X/10 | [具体发现] |
| Conventions | X/10 | [具体发现] |
| Testability | X/10 | [具体发现] |
| Readability | X/10 | [具体发现] |
| Error Handling | X/10 | [具体发现] |
| Type Safety | X/10 | [具体发现] |
| Integration | X/10 | [具体发现] |

## Issues Found

### Critical (must fix)
- [文件:行号] 问题描述。Fix: [具体修复方案]

### Major (should fix)
- [文件:行号] 问题描述。Fix: [具体修复方案]

### Minor (nice to fix)
- [文件:行号] 问题描述。Fix: [具体修复方案]

## What Was Done Well
- [带文件引用的具体正面观察]
```

格式硬性要求：

1. 总分必须是数字（X.X/10 格式，一位小数）
2. Verdict 必须精确为 PASS、CONDITIONAL PASS 或 FAIL
3. 10 个维度全部在列，Notes 必须是具体发现（不得写「看起来不错」这类空话）
4. 每条问题必须归入 Critical/Major/Minor
5. 每条问题必须带 文件:行号 引用
6. 每条问题必须给出具体修复指引（改什么、怎么改、示例代码）
7. 必须包含 What Was Done Well（至少一条正面观察）

问题严重级别指引：

- **Critical**（交付前必须修）：安全漏洞、数据损坏、鉴权绕过、常见输入崩溃、密钥泄漏
- **Major**（交付前应当修）：性能问题（N+1）、重要路径缺错误处理、无障碍违规、影响可维护性的规范违规
- **Minor**（修了更好）：命名欠佳、复杂逻辑缺注释、小风格不一致、可重构点、断言薄弱

注意：严重级别与系统风险场景相关（如高性能系统中性能问题可能是 Critical）。

### 步骤4：修复方执行修复

修复方收到评审后：

**必须修复**：全部 Critical、全部 Major；Minor 除非调度方明确降级。

**必须输出修复报告**：

```markdown
## Fixes Applied

### Critical Issues Addressed
- [文件:行号] [原问题] -> Fixed by: [改动内容]

### Major Issues Addressed
- [文件:行号] [原问题] -> Fixed by: [改动内容]

### Minor Issues Addressed
- [文件:行号] [原问题] -> Fixed by: [改动内容]

### Issues Not Fixed
- [文件:行号] [原问题] -> Reason: [未修复原因]
```

**禁止行为**：

1. 未改代码就宣称已修复
2. 部分修复却不说明
3. 静默跳过问题——跳过必须写进 Issues Not Fixed 并给原因
4. 修复引入新 Bug（需复查确认）

### 步骤5：复审验证

修复完成后，复审方必须：

1. **逐条核验原问题**：确认修复已落地、确实解决了问题、没有把问题挪到别处
2. **重新给全部维度打分**：不得照抄上次分数；从头阅读修改后的文件、按细则重新评分，并记录分数变化（如「Security: 6 -> 9」）
3. **识别新问题**：复审中发现的是新发现，只有修复直接导致的才计入回归，同样按 Critical/Major/Minor 分级

复审输出格式：

```markdown
## Re-Review Summary
- **Overall Score**: X.X/10 (was Y.Y/10)
- **Verdict**: PASS | CONDITIONAL PASS | FAIL
- **Previous Issues**: X critical, Y major, Z minor
- **Issues Resolved**: X critical, Y major, Z minor
- **New Issues Found**: X critical, Y major, Z minor

## Dimension Score Changes
| Dimension | Previous | Current | Change |
|-----------|----------|---------|--------|

## Previous Issues - Resolution Status
### Critical Issues
- [RESOLVED] / [NOT FIXED]: [文件:行号] [原问题]
### Major Issues / Minor Issues
- [RESOLVED] / [NOT FIXED]: [文件:行号] [原问题]

## New Issues Found
[按标准 Critical/Major/Minor 格式]
```

### 步骤6：WRFC 循环决策

1. **Work**：工程师实现功能
2. **Review**：评审方按本细则评分并输出评审
3. **Fix**：修复方处理全部 Critical/Major 并输出修复报告
4. **Check**：复审方核验并重新评分，决定是否进入下一轮

调度方按分数决策：**PASS（≥9.5）** 退出循环；**CONDITIONAL PASS（8.0-9.49）** 再来一轮快速修复+复查；**FAIL（<8.0）** 完整重跑 review-fix-check。

### 步骤7：格式校验

确定性校验脚本：

```bash
bash scripts/validate-review.sh <评审文件.md>   # 校验评审输出格式
bash scripts/validate-fix.sh <修复报告.md>      # 校验修复报告覆盖全部 Critical/Major
```

退出码 0 为合格，1 为格式不合格并列出全部错误。

## 常见评分错误

- **分数虚高**：存在明显问题却给 8-9 分——按细则字面执行，6-7 就是「可接受但有明显问题」
- **严重级别不一致**：鉴权绕过永远 Critical，不是 Major
- **缺文件行号**：「错误处理不好」不合格；「src/api/users.ts:42 - 空 catch 块静默吞错」才合格
- **修复建议空泛**：「修复类型安全问题」不合格；「把 `any` 换成 `User` 类型并用 zod 校验」才合格
- **主观压分**：不得因「领域复杂」「留有余地」打 9.5 而不打 10——没有发现缺陷就必须给 10
- **只列问题不列优点**：必须记录做得好的地方
- **判定与分数矛盾**：7.2 分不能判 PASS（条件通过线 8.0，通过线 9.5）

## 快速参考

```
权重：Correctness 20% | Completeness 15% | Security 15% | Performance 10%
      Conventions 10% | Testability 10% | Readability 5%
      Error Handling 5% | Type Safety 5% | Integration 5%

阈值：9.5+ PASS | 8.0-9.49 CONDITIONAL PASS | <8.0 FAIL

级别：Critical（安全/崩溃/数据损坏）必须修
      Major（性能/缺功能/劣习）应当修
      Minor（风格/优化点）修了更好
```

使用说明

# 代码评审评分协议

按 10 个维度的加权评分细则（每维 0-10 分）对代码实现做量化评审：正确性 20%、完整性 15%、安全性 15%、性能 10%、规范 10%、可测试性 10%，其余各 5%。总分 ≥9.5 判 PASS、8.0-9.49 条件通过、<8.0 判 FAIL，任一维度低于 4 直接 FAIL。附确定性格式校验脚本。

## 最简用法

```text
用代码评审评分协议审查这次改动，输出量化评分
```

```bash
bash scripts/validate-review.sh review.md   # 校验评审输出格式
```

## 特点

- 10 维度加权评分，评审结论可量化、可比较
- PASS / CONDITIONAL PASS / FAIL 三档判定 + 关键维度一票否决
- 固定输出格式：维度评分表、分级问题清单、正面观察
- 修复报告与复审核验流程闭环，杜绝「假修复」
- 自带校验脚本，格式不合格自动拦截

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。