classifying-review-findings

审查发现分类

严重程度类别

表情符号	类别	标准
❌	CRITICAL	会导致故障、崩溃、数据泄露或违反要求
⚠️	IMPORTANT	缺少错误处理、未处理边缘情况，可能导致错误
♻️	DEBT	重复使用模式、违反约定，需要在 6 个月内返工
🎨	SUGGESTED	可衡量地提升安全性、将复杂度降低 3 以上，或消除一类错误
❓	QUESTION	需要人工判断——要求、意图或系统冲突不明确

每条发现都必须使用表情符号 + 文本的混合格式（如果适用多个严重程度，使用最严重的一个：❌ > ⚠️ > ♻️ > 🎨 > ❓）：

分类前

确认以下全部三点：

1. 能否追踪执行路径并说明错误行为？
2. 是否已通过其他方式处理（错误边界、中间件、验证器）？
3. 是否确定框架行为和语言语义？

如果任何一项的答案是“否”或“不确定” → 不要将其分类为发现。

不成立的发现（拒绝）

• 表扬（“实现得很棒”）
• 含糊的建议（“可以更简单”）
• 没有强制标准的风格偏好
• 命名方面的吹毛求疵，除非确实会造成误导
• PR 元数据问题（标题、描述、测试计划）——由摘要技能处理，不在此处分类
• 对现有依赖项进行的 Renovate/Dependabot 次要版本或补丁版本更新，且 CI 通过——这些属于常规的第 5 阶段监控，不属于可审查的发现

建议改进（🎨）标准

只建议能够带来可衡量价值的改进：

1. 安全性提升——消除整类漏洞（SQL 注入、XSS 等）
2. 复杂度降低——将圈复杂度降低 3 以上，或减少一个嵌套层级
3. 预防错误——彻底杜绝整类错误（类型安全、空值安全）
4. 性能提升——将 O(n²) 降至 O(n)，或消除 N+1 查询（提供证据）

提供具体指标：

• ❌“这可以更简单”
• ✅“此处的圈复杂度为 12；提取验证逻辑后可降至 6”

如果无法衡量改进效果，就不要提出建议。