Code reviewer cn

代码审查（中文版）

基于 anthropics/skills 和 obra/superpowers 的代码审查方法论。

触发条件

当用户请求代码审查、PR Review、或代码质量检查时激活。

审查流程

1. 理解上下文

• 阅读相关文件和依赖
• 理解代码的业务目的
• 识别关键路径和边界条件

2. 分层审查

架构层

• 设计模式是否合理
• 模块划分是否清晰
• 依赖关系是否健康

逻辑层

• 算法正确性
• 边界条件处理
• 错误处理完整性

安全层

• 输入验证
• SQL注入/XSS防护
• 敏感信息处理

性能层

• 时间复杂度
• 内存使用
• 数据库查询优化

可维护性

• 代码可读性
• 命名规范
• 注释完整性

3. 问题分级

级别	说明	处理方式
🔴 Critical	安全漏洞、数据丢失风险	必须修复
🟠 Major	逻辑错误、性能问题	强烈建议修复
🟡 Minor	代码风格、可读性	建议改进
🔵 Info	最佳实践建议	可选优化

输出格式

# 代码审查报告

## 📋 概览
- **审查范围**：[文件/模块列表]
- **代码行数**：[总行数]
- **审查时间**：[日期]

## 📊 评分

| 维度 | 评分 | 说明 |
|------|------|------|
| 正确性 | X/10 | |
| 安全性 | X/10 | |
| 性能 | X/10 | |
| 可维护性 | X/10 | |
| **综合** | **X/10** | |

## 🔴 Critical 问题 (X个)

### [问题标题]
- **位置**：`文件名:行号`
- **问题**：[描述]
- **风险**：[影响说明]
- **建议**：
```[语言]
// 修复代码

🟠 Major 问题 (X个)

[同上格式]

🟡 Minor 问题 (X个)

[同上格式]

🔵 改进建议

[最佳实践建议列表]

✅ 亮点

[代码中做得好的地方]

## 审查原则

1. **先理解，后评判** - 不要急于下结论
2. **对事不对人** - 关注代码，不评价作者
3. **给出解决方案** - 不只指出问题，还要提供修复建议
4. **保持建设性** - 语气友善，鼓励改进

## 常见检查项

### JavaScript/TypeScript
- [ ] 是否有未处理的 Promise rejection
- [ ] 是否有潜在的内存泄漏
- [ ] TypeScript 类型是否完整
- [ ] 是否有 any 类型滥用

### Python
- [ ] 是否有类型注解
- [ ] 异常处理是否完整
- [ ] 是否有资源泄漏（文件、连接）
- [ ] 是否遵循 PEP8

### 通用
- [ ] 是否有硬编码的敏感信息
- [ ] 是否有适当的日志记录
- [ ] 是否有单元测试覆盖
- [ ] 是否有文档说明