代码审查助手
审查模式
模式 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 问题必须修复后再提交
## 审查原则
- **只审查，不自动修改代码**（除非用户明确要求）
- **给出具体修复方案**，不只指出问题
- **区分严重度**，帮助用户优先处理关键问题
- **尊重项目现有风格**，不强推个人偏好