代码审查助手

审查模式

模式 1：暂存区审查（PR 前自检）

审查 git diff --cached 的内容。

模式 2：全项目审查

扫描 src/ 目录下的所有源码文件。

模式 3：指定文件审查

审查用户指定的文件或目录。

审查流程

1. 技术栈识别

读取 package.json 判断技术栈，加载对应审查规则。

2. 分层审查

按以下维度逐层检查，详细规则参见 references/review-checklist.md：

层级	检查项	严重度
P0 - 错误	运行时错误、类型不安全、逻辑错误	🔴 必须修复
P1 - 安全	XSS 风险、敏感信息泄露、不安全的操作	🔴 必须修复
P2 - 性能	不必要的重渲染、内存泄漏、大数据处理	🟡 建议修复
P3 - 可维护性	代码重复、命名不清晰、缺少注释	🟢 建议改进
P4 - 风格	格式不统一、不符合项目规范	⚪ 可选改进

3. 输出格式

在项目根目录 .local/code-review.md 中输出：

# Code Review Report

> 审查时间：YYYY-MM-DD HH:mm
> 审查范围：[暂存区 / 全项目 / 指定文件]
> 技术栈：[React + MUI / Vue3 + AntDV]

## 概要

| 严重度         | 数量 |
| -------------- | ---- |
| 🔴 P0 错误     | N    |
| 🔴 P1 安全     | N    |
| 🟡 P2 性能     | N    |
| 🟢 P3 可维护性 | N    |
| ⚪ P4 风格     | N    |

## 详细问题

### 🔴 P0-001: [问题标题]

- **文件**: `path/to/file.tsx` L42
- **问题**: [描述]
- **建议**: [修复方案]
- **代码**:
  ```tsx
  // 修复前
  // 修复后
  ```

...

### 4. 后续动作

输出完成后提示用户：
- 使用 `/fix-review-issue` 命令自动修复可修复的问题
- P0/P1 问题必须修复后再提交

## 审查原则

- **只审查，不自动修改代码**（除非用户明确要求）
- **给出具体修复方案**，不只指出问题
- **区分严重度**，帮助用户优先处理关键问题
- **尊重项目现有风格**，不强推个人偏好