代码审查技能

目的

本技能依据以下指南（~/.claude/CLAUDE.md）提供系统化的代码审查：

• 提升代码质量
• 发现安全漏洞
• 识别性能问题
• 评估可维护性
• 应用最佳实践

适用场景

在以下情况中使用本技能：

• 收到 Pull Request（PR）的审查请求时
• 明确收到“请审查代码”类指令时
• 被要求进行代码质量检查时
• 需要开展安全审查时
• 计划重构前进行初步评估时

操作说明

1. 检查 CI/CD 状态

若为 Pull Request，请首先检查 CI/CD 状态：

# 若已明确 GitHub PR 编号
gh pr view  --json statusCheckRollup

# 或者，查看当前分支关联的 PR
gh pr status
gh pr checks

根据 CI/CD 检查结果采取相应措施：

• ✅ 全部通过：进入常规代码审查流程
• ❌ 存在失败项：
  • 审查自己提交的 PR：分析失败原因并完成修复
  • 审查他人提交的 PR：确认失败详情，并将相关信息纳入审查评论

CI 失败时的详细排查命令：

# 查看失败检查的详细信息
gh pr checks 

# 获取日志（适用于 GitHub Actions）
gh run view  --log-failed

2. 明确审查范围

确认待审查内容：

# 查看变更文件列表
git status
git diff --name-only

# 若为 PR，查看差异内容
gh pr diff 

# 或者，若已指定具体文件，则以该文件为审查目标

3. 理解上下文

开始审查前，请确认以下信息：

• 项目类型（原型 / MVP / 生产环境）
• 相关已有代码
• 测试是否存在
• 文档是否完备

4. 处理 CI 失败

若自己的 PR 出现 CI 失败：

1. 定位失败原因：

   • 测试失败：具体是哪个测试、为何失败
   • 构建错误：编译错误、类型错误等
   • Linter / Formatter：编码风格违规
   • 安全扫描：检测到安全漏洞

2. 实施修复：

   • 阅读错误日志，修正根本原因
   • 同步更新相关测试用例
   • 在本地执行相同检查以验证修复效果

3. 重新推送：

   git add .
   git commit -m "fix: resolve CI failures"
   git push
   

若审查他人 PR 时发现 CI 失败：

请在审查评论开头添加如下内容：

## ⚠️ CI/CD Status

### 失败的检查项
- [检查名称1]: [失败原因摘要]
- [检查名称2]: [失败原因摘要]

### 需要采取的修复动作
1. [具体修复内容]
2. [具体修复内容]

更多细节请参见下方代码审查意见。

---

5. 开展系统化审查

从以下维度对代码进行评估（详细标准参见 reference.md）：

A. 代码质量

• 可读性（变量名、函数名是否恰当）
• 是否遵守 DRY 原则
• 抽象层级是否合理
• 注释质量（是否说明“为什么”而非仅“做什么”）

B. 错误处理

• 是否恰当地覆盖各类错误场景
• 是否避免简单压制错误，而致力于解决根本原因
• 错误信息是否清晰明确
• 对外部 API 调用失败是否有妥善处理

C. 安全性

• 是否硬编码了认证凭据
• 是否实现输入验证
• 是否规避 OWASP Top 10 所列常见漏洞
• 是否遵循最小权限原则

D. 测试

• 测试覆盖率
• 是否覆盖边界条件和异常路径
• 测试是否相互独立
• 测试代码是否具备良好可读性

E. 性能

• 是否存在 N+1 查询问题
• 是否存在冗余循环或重复计算
• 缓存策略是否合理
• 是否存在资源泄漏（如内存、文件句柄、数据库连接等）

F. 可维护性

• 模块划分是否合理
• 依赖关系是否清晰明确
• 技术债务是否已被记录
• 编码风格是否统一一致

6. 提供审查反馈

按以下格式输出审查结果：

## コードレビュー結果

### ⚠️ CI/CD Status (该情况适用时)
[在此处填写 CI 失败相关信息]

### 🔴 Critical Issues (需立即修复)
- [具体问题及位置]
- [修复建议]

### 🟡 Warnings (建议修复)
- [改进建议]
- [理由说明]

### 🟢 Good Practices (值得肯定的实践)
- [值得表扬的具体实现]

### 💡 Suggestions (可选优化建议)
- [更优实现方案]

### 📝 Notes
- [其他观察或注意事项]

7. 建设性沟通

• 聚焦于代码本身，而非开发者个人
• 不仅指出问题，也主动肯定优点
• 提出具体、可落地的改进方案
• 解释“为什么”需要该修改，帮助理解其必要性

核心原则

1. 考虑项目上下文：原型项目与生产环境应采用不同审查标准
2. 明确优先级：按 Critical > Warning > Suggestion 显式标注问题严重程度
3. 注重实用性：不追求绝对完美，兼顾效率与质量的合理平衡
4. 把握学习机会：将审查过程视为团队知识共享与能力提升的重要契机

参考文档

• 详细的审查标准细则
• 实际审查案例参考

依赖项

• Git（用于查看变更差异）
• GitHub CLI（gh）——用于获取 PR 信息及 CI/CD 状态
• 项目专属的 linter / formatter（如已配置）

CI/CD 集成支持

本技能兼容以下 CI/CD 系统：

• GitHub Actions
• CircleCI（通过 GitHub 集成方式）
• 其他已集成至 GitHub Checks 的 CI/CD 系统

注意：检查 PR 的 CI/CD 状态需使用 gh 命令。安装方法如下：

# macOS
brew install gh

# 认证登录
gh auth login