Code Review

SKILL.md

---
name: code-review
description: |
  AI 驱动的代码审查工具。对代码变更进行多维度审查，输出结构化的 Review 意见。

  **当以下情况时使用此 Skill**:
  (1) 需要对代码进行 Code Review
  (2) 需要审查 PR/MR 的代码变更
  (3) 用户提到"code review"、"代码审查"、"帮我看看代码"、"这段代码有问题吗"
  (4) 需要检查代码安全性、性能、可维护性
  (5) 提交代码前的自查
  (6) 用户提到"PR review"、"代码质量"、"技术债务"
metadata:
  openclaw:
    emoji: "🔍"
    version: "1.0.0"
    author: "小摩事业部"
    tags: ["code-review", "developer-tools", "security", "performance", "quality", "chinese"]
---

# 🔍 AI Code Review — 智能代码审查

> 不遗漏每一行有问题的代码。

## 🎯 核心功能

1. **多维度审查** — 从安全、性能、可维护性、逻辑、风格 5 个维度扫描代码
2. **风险评级** — 🔴严重 / 🟡警告 / 🔵建议，优先级清晰
3. **修复建议** — 每个问题附带具体的修复代码片段
4. **PR 审查模式** — 分析 diff 输出结构化的 PR Review 报告
5. **快速审查** — 只输出严重问题，适合紧急提交前自查

## 📋 使用模式

### 模式一：完整代码审查

用户提交代码片段或文件内容，进行全面的代码审查。

**输入格式**：
```
帮我 review 这段代码：[代码片段]
```

**输出格式**：

```markdown
## 🔍 Code Review 报告

**审查文件**: [文件名/代码片段]
**总体评级**: ⭐⭐⭐⭐ (4/5)
**发现**: 3 个问题（🔴 0 严重 / 🟡 1 警告 / 🔵 2 建议）

### 🔴 严重问题
（无）

### 🟡 警告

#### 1. [问题标题]
- **位置**: 第 42 行
- **维度**: 安全
- **问题**: SQL 拼接导致注入风险
- **修复**:
```语言
// 修复前
String query = "SELECT * FROM users WHERE id = " + userId;

// 修复后
String query = "SELECT * FROM users WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setString(1, userId);
```

### 🔵 建议

#### 2. [建议标题]
- **位置**: 第 15-20 行
- **维度**: 可维护性
- **建议**: 提取为独立方法
- **参考**:
```语言
// 建议重构为
private User findUserById(String userId) { ... }
```

### ✅ 做得好的地方
- 异常处理完整
- 日志记录规范
```

### 模式二：PR 审查

用户提交 diff 或 PR 内容，进行变更审查。

**输入格式**：
```
审查这个 PR：[diff 内容]
```

或

```
审查我最近的代码变更
```

**执行步骤**：
1. 如用户在工作目录中，主动用 `git diff` 获取变更
2. 分析变更文件列表和影响范围
3. 对每个文件的变更逐一审查
4. 汇总为 PR Review 报告

**输出格式**：

```markdown
## 🔍 PR Review 报告

**变更范围**: 5 个文件（+142/-38）
**风险等级**: 🟡 中
**审查结论**: ✅ 可以合并（修复 1 个警告后）

### 📊 变更概览
| 文件 | 变更行数 | 风险 | 评审结果 |
|------|---------|------|---------|
| auth/login.go | +45/-12 | 🟡 | 有 1 个警告 |
| utils/crypto.go | +23/-5 | 🟢 | 通过 |
| config.yaml | +8/-2 | 🟢 | 通过 |
| tests/auth_test.go | +58/-15 | 🟢 | 通过 |
| README.md | +8/-4 | 🟢 | 通过 |

### 🟡 需要关注的问题
[详细问题列表和修复建议]

### 💡 改进建议
[非必须但能提升代码质量的建议]

### ✅ 值得肯定
[写得好的地方]
```

### 模式三：安全审查

专注于安全维度的深度审查。

**输入格式**：
```
安全审查这段代码：[代码]
```

**审查重点**：
- SQL 注入 / XSS / CSRF
- 硬编码密钥/密码
- 不安全的反序列化
- 权限/认证绕过
- 敏感数据泄露
- 依赖漏洞

### 模式四：快速自查

提交前快速扫描，只输出严重问题。

**输入格式**：
```
快速检查这段代码：[代码]
```

**输出格式**：
```
🔍 快速审查结果：✅ 可以提交 / ⚠️ 有 N 个问题

[如果有问题，列出简要说明和修复建议]
```

## 🧠 审查维度详解

加载 `review-rules.md` 获取完整的审查规则库。

### 五大审查维度

| 维度 | 关注点 | 严重级别 |
|------|--------|---------|
| 🔒 安全 | 注入、泄露、认证、加密 | 🔴 严重 |
| ⚡ 性能 | 算法复杂度、内存、缓存、N+1查询 | 🟡 警告 |
| 🔧 可维护性 | 代码复杂度、重复、命名、注释 | 🔵 建议 |
| 🧩 逻辑 | 边界条件、空值、并发、竞态 | 🔴 严重 |
| 📐 风格 | 编码规范、格式、最佳实践 | 🔵 建议 |

### 语言特定规则

根据代码语言自动切换审查规则：

| 语言 | 特定关注点 |
|------|-----------|
| Java | 资源泄漏、空指针、并发安全、Spring 最佳实践 |
| Python | 类型安全、GIL、装饰器滥用、异步陷阱 |
| Go | goroutine 泄漏、error 处理、channel 死锁 |
| JavaScript/TS | Promise 错误处理、原型污染、类型安全 |
| SQL | 注入、索引、N+1、事务隔离级别 |
| Rust | 生命周期、unsafe 使用、内存安全 |

## 🔄 工作流程

1. **读取审查规则** → 用 `read` 工具读取 `review-rules.md`
2. **分析代码** → 确定语言、文件类型、变更范围
3. **多维度扫描** → 按规则库逐条检查
4. **风险评级** → 对每个发现分级
5. **生成修复建议** → 附带代码片段
6. **输出报告** → 按模式要求格式化输出

## 📐 评级标准

### 总体评级（⭐ 1-5 星）

| 评级 | 含义 | 标准 |
|------|------|------|
| ⭐ | 不可合并 | 有严重安全漏洞或逻辑错误 |
| ⭐⭐ | 需要大改 | 多个严重问题或设计缺陷 |
| ⭐⭐⭐ | 可以更好 | 有警告级问题需要修复 |
| ⭐⭐⭐⭐ | 良好 | 只有建议级改进 |
| ⭐⭐⭐⭐⭐ | 优秀 | 代码质量很高，无显著问题 |

### 问题分级标准

| 级别 | 标准 | 处理 |
|------|------|------|
| 🔴 严重 | 安全漏洞、数据丢失风险、逻辑错误 | 必须修复 |
| 🟡 警告 | 性能问题、潜在 bug、可维护性差 | 建议修复 |
| 🔵 建议 | 风格改进、最佳实践、优化 | 可选改进 |

## ⚙️ 配置

用户可以指定以下参数（通过对话自然语言）：

| 参数 | 说明 | 默认值 |
|------|------|--------|
| 模式 | full / pr / security / quick | full |
| 严格度 | strict（更多检查）/ normal / loose | normal |
| 语言 | 自动检测 / 手动指定 | 自动 |
| 关注维度 | security / performance / all | all |
| 输出语言 | 中文 / 英文 | 中文 |

## 💡 使用技巧

### 结合 Git 工作流

```bash
# 审查最近一次提交
git show HEAD | code-review

# 审查暂存区变更
git diff --cached

# 审查某次 PR 的所有变更
git diff main...feature-branch
```

### 审查策略建议

- **提交前**：用 quick 模式快速自查
- **PR 审查**：用 pr 模式完整审查
- **安全审计**：用 security 模式深度扫描
- **上线前**：full 模式 + strict 严格度

## 🚨 执行规范

1. **先读规则**：每次执行前，读取 `review-rules.md` 获取最新审查规则
2. **不遗漏**：每个维度都要检查，不要跳过
3. **给证据**：每个问题都要指出具体代码位置
4. **给修复**：不要只说问题，要给出修复方案
5. **看整体**：不只是逐行审查，还要看整体架构和设计
6. **公正评价**：也要指出做得好的地方，不只是找问题

## 版本历史

- **v1.0.0** (2026-05-23) — 初始版本，5 大审查维度，4 种使用模式，多语言支持