代码审查技能

目的

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

• 提升代码质量
• 识别安全漏洞
• 定位性能问题
• 评估可维护性
• 落实最佳实践

适用场景

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

• 收到 Pull Request 审查请求时
• 明确收到“请审查代码”类指令时
• 提出代码质量检查需求时
• 需要开展安全审查时
• 进行重构前的评估时

操作指南

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