多维度并行代码评审时分配维度、去重、校准严重性并生成合并报告

当你组织多个评审员按不同质量维度并行评审代码，并需要合并去重 findings、统一严重性、输出合并报告时使用。

适用场景

解决思路

1. 分配安全维度：关注漏洞、认证、输入校验；当代码处理用户输入或认证时始终纳入。
2. 分配性能维度：关注查询效率、内存、缓存；当改动数据访问或热路径时纳入。
3. 分配架构维度：关注 SOLID、耦合、模式；用于结构性变更或新模块。
4. 分配测试维度：关注覆盖率、质量、边界情况；当添加新功能时纳入。
5. 分配可访问性维度：关注 WCAG、ARIA、键盘导航；用于 UI/前端变更。
6. 针对 API 端点变更，分配安全、性能、架构维度。
7. 针对前端组件，分配架构、测试、可访问性维度。
8. 针对数据库迁移，分配性能、架构维度。
9. 针对认证变更，分配安全、测试维度。
10. 针对全功能评审，分配安全、性能、架构、测试维度。
11. 去重合并规则：相同 file:line、相同问题——合并为一条 finding，并记录所有评审员贡献。
12. 去重合并规则：相同 file:line、不同问题——保留为独立 findings。
13. 去重合并规则：相同问题、不同位置——保持独立但交叉引用。
14. 去重合并规则：严重性冲突——采用更高的严重性评级。
15. 去重合并规则：建议冲突——两者都包含，并标注评审员归属。
16. 去重流程：遍历所有评审员报告中的每个 finding，检查是否有另一个 finding 引用相同 file:line。
17. 去重流程：如果是，检查它们是否描述同一问题。
18. 去重流程：如果是同一问题，合并并保留更详细的描述。
19. 去重流程：如果是不同问题，两者都保留，标记为 co-located。
20. 去重流程：合并后的 findings 采用其中最高严重性。
21. 按严重性标准评定 Critical：影响为数据丢失、安全泄露、完全失败；可能性为确定或非常可能；示例：SQL 注入、认证绕过、数据损坏。
22. 按严重性标准评定 High：影响为显著功能影响、退化；可能性为可能；示例：内存泄漏、缺少校验、流程中断。
23. 按严重性标准评定 Medium：影响为部分影响、存在绕过方法；可能性为可能；示例：N+1 查询、缺少边界情况、错误信息不清晰。
24. 按严重性标准评定 Low：影响为最小影响、表面问题；可能性为不太可能；示例：风格问题、次要优化、命名。
25. 校准规则：可被外部用户利用的安全漏洞始终评为 Critical 或 High。
26. 校准规则：热路径中的性能问题至少评为 Medium。
27. 校准规则：关键路径缺少测试至少评为 Medium。
28. 校准规则：核心功能的可访问性违规至少评为 Medium。
29. 校准规则：无功能影响的代码风格问题评为 Low。
30. 使用 markdown 合并报告模板生成报告，包含目标（files/PR/directory）、评审员（dimension-1、dimension-2、dimension-3）、日期、已评审文件数（count）。
31. 在合并报告中按严重性分组列出 findings：Critical Findings（数量）。
32. 在合并报告中按严重性分组列出 findings：High Findings（数量）。
33. 在合并报告中按严重性分组列出 findings：Medium Findings（数量）。
34. 在合并报告中按严重性分组列出 findings：Low Findings（数量）。
35. 每个 finding 条目包含：[CR-001] {Title}、Location: `{file}:{line}`、Dimension: {Security/Performance/etc.}、Description、Impact、Fix。
36. 添加 Summary 表格，按维度统计 Critical、High、Medium、Low、Total。
37. 添加 Recommendation：整体评估和按优先级排序的行动项。

适用边界 · 注意事项

• 只有单个评审员或只需评审单一质量维度的简单变更时，不需要多评审员协调模式。