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

yaml

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

Frontend

yaml

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

E2E

yaml

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 回复原则

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

5.2 回复模板

已修复

markdown

✅ 已修复

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

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

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

需要澄清

markdown

⏸️ 需要更多信息

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

不采纳（有理由）

markdown

ℹ️ 暂不修改

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

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

5.3 避免的回复

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

6. 时间窗口过滤

6.1 过滤规则

有效评论条件：

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

6.2 时区处理

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

6.3 边界情况

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

7. TDD 集成

7.1 修复流程

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

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

7.2 测试命名

python

# 格式: 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 沉淀内容

markdown

## {问题模式名称}

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

### 问题描述
{描述}

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

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

8.3 沉淀位置

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