PR Review 代码审查
全面审查 Pull Request，输出结构化的审查报告。
审查维度
1. 代码质量
| 检查项 | 说明 |
|---|---|
| 代码风格 | 是否符合项目规范 |
| 复杂度 | 圈复杂度是否过高 |
| 重复代码 | 是否存在重复逻辑 |
| 命名规范 | 变量/函数命名是否清晰 |
| 错误处理 | 异常是否正确处理 |
| 潜在 Bug | 逻辑错误、边界条件 |
2. 架构设计
| 检查项 | 说明 |
|---|---|
| 项目结构一致性 | 是否遵循现有架构 |
| 依赖合理性 | 是否引入不必要的依赖 |
| 设计模式 | 是否正确使用设计模式 |
| 关注点分离 | 职责是否清晰 |
3. 安全性
| 检查项 | 说明 |
|---|---|
| SQL 注入 | 参数化查询是否正确 |
| XSS | 输出是否正确转义 |
| 敏感信息泄露 | 是否暴露密钥/密码 |
| 权限验证 | 访问控制是否完整 |
| 输入验证 | 用户输入是否验证 |
4. 性能
| 检查项 | 说明 |
|---|---|
| N+1 查询 | 数据库查询是否优化 |
| 内存泄漏 | 资源是否正确释放 |
| 不必要的计算 | 是否有冗余操作 |
| 缓存使用 | 是否合理使用缓存 |
审查流程
bash
# 1. 获取 PR 信息
gh pr view {pr_number} --json files,additions,deletions
# 2. 查看变更内容
gh pr diff {pr_number}
# 3. 阅读相关文件完整上下文
Read: 变更文件的完整内容
# 4. 搜索相关依赖
Grep: 函数名/类名 查找引用
# 5. 发布审查评论
gh pr comment {pr_number} --body "审查报告"
审查结论
| 结论 | 说明 | 使用场景 |
|---|---|---|
APPROVE | 批准合并 | 无问题或仅有建议 |
REQUEST_CHANGES | 需要修改 | 存在严重或重要问题 |
COMMENT | 仅评论 | 有问题但不阻塞合并 |
问题分级
🔴 严重问题 (Critical)
- •安全漏洞
- •数据丢失风险
- •生产环境崩溃风险
- •明显的逻辑错误
🟠 重要问题 (Important)
- •性能问题
- •代码质量问题
- •架构设计问题
- •测试覆盖不足
🟢 改进建议 (Suggestions)
- •代码风格改进
- •命名优化
- •文档补充
- •最佳实践建议
输出格式
PR 评论模板
markdown
## 🔍 PR 代码审查报告
### 📋 概要
- **变更文件数**: {files}
- **新增/删除行数**: +{additions} / -{deletions}
### 🎯 审查结论
**{APPROVE/REQUEST_CHANGES/COMMENT}**
{结论简要说明}
### 🔴 严重问题 (Critical)
{如无则显示"无"}
1. **{问题标题}** - `path/to/file.ts:123`
- 问题描述
- 修复建议
### 🟠 重要问题 (Important)
{如无则显示"无"}
1. **{问题标题}** - `path/to/file.ts:456`
- 问题描述
- 修复建议
### 🟢 改进建议 (Suggestions)
{如无则显示"无"}
1. **{建议标题}** - `path/to/file.ts:789`
- 建议内容
### ✨ 代码亮点
{值得肯定的好实践}
### 💡 总体评价
{对本次 PR 的整体评价}
---
桀桀桀! 魂殿来抓人啦!
结构化输出 Schema
json
{
"conclusion": "APPROVE|REQUEST_CHANGES|COMMENT",
"summary": "简要总结（100字以内）",
"critical_count": 0,
"important_count": 2,
"suggestion_count": 3,
"security_issues": ["安全问题1"],
"performance_issues": ["性能问题1"],
"highlights": ["代码亮点1"]
}
注意事项
- •所有评论使用简体中文
- •给出具体的文件名和行号
- •对好的实践也要给予肯定
- •保持客观、专业的态度
- •使用
gh pr comment发布单条综合评论 - •不要创建多条评论或行内评论