PR Review 分析 Skill

本 Skill 提供 PR Code Review 评论分析的知识库，用于支持 /fix-pr-review 工作流。

1. 置信度评估体系

1.1 评分因素

置信度表示评论的"可操作性"，分数范围 0-100。

因素	权重	说明
明确性 (clarity)	40%	评论是否清晰指出问题和位置
具体性 (specificity)	30%	是否有具体示例或测试场景
上下文 (context)	20%	是否理解代码上下文和影响
可复现 (reproducibility)	10%	是否有复现步骤

1.2 评分指标

明确性 (Clarity) - 权重 40%

指标	分值	示例
有具体文件位置	+30	"src/auth.py:42"
有行号	+10	"第 42 行"
有期望行为描述	+30	"应该返回 401"
有代码示例	+20	`if token.expired:`
评论长度 > 50 字	+10	详细描述

具体性 (Specificity) - 权重 30%

指标	分值	示例
有测试建议	+40	"添加测试用例验证..."
有具体值/示例	+30	"返回 {"error": "expired"}"
有对比说明	+30	"应该用 X 而不是 Y"

上下文 (Context) - 权重 20%

指标	分值	示例
引用其他代码位置	+25	"这会影响 UserService"
讨论影响范围	+25	"可能导致数据不一致"
基础分	50	-

可复现 (Reproducibility) - 权重 10%

指标	分值	示例
有步骤描述	+30	"1. 登录 2. 访问 /api"
有输入输出描述	+20	"当 token 过期时..."
基础分	50	-

1.3 置信度等级

分数范围	等级	处理方式
80-100	高 (high)	自动处理
60-79	中 (medium)	询问用户后处理
40-59	低 (low)	标记需澄清
0-39	极低 (very_low)	跳过，回复 reviewer

---

2. 优先级分类体系

2.1 优先级定义

优先级	名称	描述	处理要求
P0	Blocker	阻塞上线的安全/数据问题	必须立即处理
P1	Critical	核心功能缺陷	当前 PR 必须修复
P2	Major	重要改进	建议本 PR 修复
P3	Minor	建议/风格问题	可选处理

2.2 分类关键词

P0 (Blocker) 关键词

安全相关（自动升级 2 个优先级）：

• security, vulnerability, injection
• XSS, CSRF, leak, exposed
• sensitive, password, token, secret
• 安全, 漏洞, 泄露, 暴露

关键缺陷：

• crash, data loss, downtime
• blocker, production, urgent
• 崩溃, 数据丢失, 紧急, 阻塞

P1 (Critical) 关键词

• bug, broken, fail, error
• incorrect, doesn't work, not working
• wrong, invalid, missing
• 错误, 失败, 不正确, 缺失

P2 (Major) 关键词

• should, better, improve
• optimize, refactor, performance
• cleanup, simplify
• 应该, 改进, 优化, 重构

P3 (Minor) 关键词

• consider, maybe, could
• nit, style, minor, typo
• nitpick, suggestion
• 建议, 风格, 小问题

2.3 优先级提升规则

条件	提升
包含安全关键词	+2 级
包含数据相关关键词	+1 级
文件在核心路径 (auth, payment)	+1 级

---

3. 技术栈识别

3.1 路径模式匹配

Backend

patterns:
  - "src/api/**"
  - "src/models/**"
  - "src/services/**"
  - "app/**"
  - "tests/backend/**"
  - "tests/unit/**"
  - "**/*.py"

Frontend

patterns:
  - "src/components/**"
  - "src/pages/**"
  - "src/hooks/**"
  - "src/stores/**"
  - "tests/frontend/**"
  - "**/*.tsx"
  - "**/*.jsx"

E2E

patterns:
  - "tests/e2e/**"
  - "e2e/**"
  - "playwright/**"
  - "cypress/**"

3.2 文件扩展名推断

扩展名	技术栈
.py	Backend
.tsx, .ts, .jsx, .js	Frontend
.spec.ts, .test.ts (在 e2e 目录)	E2E

---

4. 常见评论模式

4.1 Backend 常见评论

数据库相关

模式	置信度加成	优先级
"事务/transaction"	+15	P1
"N+1 查询"	+20	P1
"索引/index"	+10	P2
"死锁/deadlock"	+20	P0

API 相关

模式	置信度加成	优先级
"状态码错误"	+15	P1
"响应格式"	+10	P2
"参数验证"	+15	P1
"错误处理"	+15	P1

认证相关

模式	置信度加成	优先级
"token 过期"	+20	P0
"权限检查"	+20	P0
"会话管理"	+15	P1

4.2 Frontend 常见评论

React 相关

模式	置信度加成	优先级
"useEffect 依赖"	+15	P1
"状态管理"	+10	P2
"memo/useMemo"	+10	P2
"key 属性"	+15	P1

测试相关

模式	置信度加成	优先级
"mock 冲突"	+20	P1
"异步测试"	+15	P1
"测试覆盖"	+10	P2

4.3 E2E 常见评论

模式	置信度加成	优先级
"选择器不稳定"	+15	P1
"超时问题"	+15	P1
"等待条件"	+15	P1
"断言不准确"	+10	P2

---

5. 回复最佳实践

5.1 回复原则

1. 感谢 Reviewer：始终表示感谢
2. 说明行动：清楚描述做了什么
3. 提供证据：链接到修复代码/测试
4. 开放沟通：邀请进一步讨论

5.2 回复模板

已修复

✅ 已修复

感谢指出！已在 `{commit}` 中完成修复。

**变更**：
- {变更描述}

**测试**：
- ✅ {测试名称} 通过

需要澄清

⏸️ 需要更多信息

感谢建议！为了更好地理解，能否提供：
1. {问题 1}
2. {问题 2}

不采纳（有理由）

ℹ️ 暂不修改

感谢建议！经过分析，当前实现是预期行为，原因：
- {原因}

如果您有不同看法，欢迎继续讨论。

5.3 避免的回复

• ❌ "你的建议不对"
• ❌ "代码已经这样写了"
• ❌ 不提供任何解释的 "已修复"
• ❌ 防御性语气

---

6. 时间窗口过滤

6.1 过滤规则

有效评论条件：

• 评论创建时间 > 最后 commit 时间
• 或评论更新时间 > 最后 commit 时间（有新回复）

6.2 时区处理

• 所有时间使用 UTC
• GitHub API 返回的时间已是 UTC
• 比较前确保时区一致

6.3 边界情况

情况	处理
评论与 commit 同时	保守保留
更新时间 > 创建时间	检查更新内容
评论在 commit 前但有新回复	保留

---

7. TDD 集成

7.1 修复流程

所有 PR Review 修复必须遵循 TDD：

1. RED：编写能复现评论问题的测试
2. GREEN：最小实现使测试通过
3. REFACTOR：优化代码

7.2 测试命名

# 格式: test_{功能}_{评论描述}
def test_token_validation_returns_401_when_expired():
    """
    PR Review: rc_123456
    Reviewer: @alice_dev
    """
    pass

7.3 覆盖率要求

• 新增代码：100% 覆盖
• 修改代码：不低于原覆盖率
• 总体覆盖：>= 90%

---

8. 知识沉淀

8.1 何时沉淀

• P0/P1 评论的修复
• 置信度 >= 85 的评论
• 新发现的问题模式

8.2 沉淀内容

## {问题模式名称}

**频率**: ★★★☆☆
**技术栈**: Backend/Frontend/E2E
**关键词**: token, expire, validation

### 问题描述
{描述}

### 解决方案
{TDD 修复代码示例}

### 检查清单
- [ ] 检查项 1
- [ ] 检查项 2

8.3 沉淀位置

• 通用模式：docs/best-practices/pr-review-patterns.md
• 技术栈特定：docs/best-practices/{stack}/*.md