---
name: code-reviewer
description: "本地代码自审技能，用于开发者 commit 前对自己的改动进行预审。当用户请求 'review 代码'、'审查这次改动'、'找 diff 里的问题'、'review staged changes' 或 'code review this diff' 时使用。重点识别真实缺陷、安全漏洞、性能回退和设计问题，给出可执行的修复建议。默认只输出审查结论，不直接修改代码。"
---

# 代码审查

## 问题门槛

每条问题必须满足以下三点，否则不输出：

1. **可定位**：能指向具体文件和新增行号
2. **可自证**：仅凭当前 diff 和可见上下文即可成立，不依赖 diff 之外的假设
3. **可修复**：给出具体修复方案，而非泛泛建议

同一根因的多处表现合并为一条，不重复列举。

## 严重级别

| 等级 | 含义 | 处理 |
|------|------|------|
| **P0** | 安全漏洞、数据损坏、必现 crash | 必须修复后才能提交 |
| **P1** | 逻辑错误、功能异常、明显性能/可靠性回退 | 提交前修复 |
| **P2** | 可维护性问题、测试不足、非阻塞设计问题 | 当前批次修复或登记后续任务 |
| **P3** | 次要改进 | 可选 |

## 工作流

### 1) 确认审查范围

先用 `git status -sb` 判断当前状态，再决定审查哪部分：

```bash
git status -sb
git --no-pager diff --stat          # unstaged 改动
git --no-pager diff --cached --stat # staged 改动
```

- 有 unstaged 改动 → 审查 `git --no-pager diff`
- 只有 staged 改动 → 审查 `git --no-pager diff --cached`
- 两者都有 → 优先审查 staged `git --no-pager diff --cached`，并提示可再单独审查 unstaged（`git --no-pager diff`）

diff 较大时写入文件再读取：

```bash
git --no-pager diff > code-review.patch
```

**边界情况：**
- **用户直接提供 diff 文本**：跳过 git 命令，直接审查提供的内容。
- **没有任何变更**：说明当前没有可审查内容，提示用户指定 commit 范围（如 `git diff main...HEAD`）。
- **diff 较大**：先用 `--stat` 列出改动文件，按文件逐个审查，不要一次性处理全部 diff。

### 2) 代码分析

#### a) 安全与可靠性

加载 `references/security-checklist.md`，说明问题的触发路径和影响范围。只在有明确代码路径支撑时才输出安全问题。

#### b) 代码质量

加载 `references/code-quality-checklist.md`，优先报告会导致错误结果或失败不可见的问题。

#### c) 架构与设计

加载 `references/solid-checklist.md`，检查本次改动是否引入新的设计问题。有重构建议时给出分步方案，不建议整体重写。

#### d) 冗余与删除（diff 中没有代码删除时跳过）

加载 `references/removal-plan.md`，确认被删代码无残留引用，相关测试和配置已同步清理。

### 3) 整理问题列表

确认每条问题满足门槛（可定位、可自证、可修复）。同一根因的多处表现合并为一条。不为凑数量降低标准。

### 4) 评分

加载 `references/scoring-guide.md`，**每次审查必须根据该指南给出具体评分**：先按最严重问题确定基准区间，再按影响广度、问题数量、可逆性在区间内微调，最终输出一个具体分值（如 8.5、7.0），不得只写区间或省略评分；纯文件删除时记为 N/A。

### 5) 输出格式

按以下格式输出：

```markdown
## 审查摘要

**审查范围**：X 个文件，Y 行新增

**评分**：X / 10（必须为具体分值，如 8.5；仅纯删除时为 N/A）

**提交建议**：✅ 可以提交 / ✅ 可以提交，跟进修复 / 🔧 修复后提交 / 🚫 禁止提交

**问题统计**：P0 × 个 / P1 × 个 / P2 × 个 / P3 × 个

---

## 各维度结果

| # | 维度 | 结论 |
|---|------|------|
| 1 | 安全与可靠性 | ✅ 无问题 / ⚠️ 存在问题（简述） |
| 2 | 代码质量 | ✅ 无问题 / ⚠️ 存在问题（简述） |
| 3 | 架构与设计 | ✅ 无问题 / ⚠️ 存在问题（简述） / 不适用 |

<!-- 纯文件删除时：前三行均填"不适用（纯删除，未引入新代码）"，并在末尾追加一行：
| 4 | 冗余与删除 | ✅ 删除安全 / ⚠️ 存在问题（简述） | -->

---

## 问题列表

### P0 🔴 严重
无

### P1 🟠 高
1. **[文件:行号] 问题标题**
   - **问题**：一句话说明是什么问题
   - **影响**：一句话说明会导致什么后果
   - **修复**：具体方案

### P2 🟡 中
无

### P3 🟢 低
无

---

## 总体评价

2–3 句话说明是否建议提交，以及还需要哪些修复或跟进。
```

**输出规则：**
- 每次审查必须在「审查摘要」中给出根据 `references/scoring-guide.md` 计算的具体评分（X / 10），不得省略。
- 直接给问题，不写前言铺垫。
- 每条问题写清楚：位置、问题是什么、影响是什么、如何修复。
- 纯文件删除时，明确写"评分不适用"。
- 禁止在模板之外添加"亮点"、"优点"、"表扬"等额外章节。
- `## 总体评价` 只写 2–3 句连续段落，不用列表或子标题。

## 参考文件

| 文件 | 用途 |
|------|------|
| `security-checklist.md` | 安全与可靠性检查项 |
| `code-quality-checklist.md` | 错误处理、性能、边界条件、并发检查项 |
| `solid-checklist.md` | 架构与设计问题检查项 |
| `removal-plan.md` | 冗余代码识别与删除计划模板 |
| `scoring-guide.md` | 评分模型、区间规则和提交建议 |