Breeze 代码审查器

为什么需要自动化代码审查

在 Pull Request 流程中，人工审查常面临两类问题：一是容易遗漏跨语言的通用风险，比如硬编码的 API 密钥、残留的 console.log 调试语句或未处理的 SQL 拼接模式；二是代码质量检查依赖团队规范的一致性，超长函数、过深嵌套或上帝类等问题可能在迭代中逐渐累积，直到维护成本爆发。尤其当 PR 包含多文件、多语言改动时，人工识别风险优先级和质量缺陷会变得耗时且不可靠。

技能如何组织审查流程

该技能通过分层规则和工具链实现自动化审查，核心逻辑是先加载规则，再分析差异，最后生成报告：

• 规则加载：每次审查固定加载 SKILL.md（定义工具和阈值）、rules/universal.md（跨语言通用规则）和 1 个语言特定规则文件（根据文件扩展名映射，例如 .py 对应 languages/python.md），确保审查逻辑不遗漏基础规则。
• PR 差异分析：PR Analyzer 工具分析分支间代码差异，除通用检测项（硬编码密钥、SQL 注入模式、调试语句残留等），还会结合语言特定规则识别风险，输出复杂度评分（1-10）、风险等级（critical/high/medium/low）和文件审查优先级，同时校验 commit message 规范。
• 代码质量检测：Code Quality Checker 工具按预设阈值检测代码结构问题，例如函数超 50 行、文件超 500 行、类超过 20 个方法等，阈值统一且可复现，避免人工判断的主观性。
• 报告生成：Review Report Generator 将前两步的发现整合为结构化报告，包含风险信号、质量检查、安全/异步/资源管理/异常处理等维度，并根据评分给出明确结论（如 Approve、Approve with suggestions、Request changes）。

对于新语言支持，只需基于现有语言模板创建 languages/xx.md 文件（包含要求的 8 个核心章节），在扩展映射表中添加对应文件扩展名即可。确定性分析脚本（如 code_quality_checker.py）需额外补充语言扩展名映射、代码结构正则和特定代码气味检测函数，并通过回归测试（expected_outputs/ 目录）确保分析行为的稳定性。

适用边界与注意点

• 该技能依赖预定义的规则和阈值，自定义检测项需通过维护语言规则文件实现，无法自动发现未定义的代码模式。
• 确定性脚本仅识别明确配置的语言，未配置的扩展名会回退到 Python 分析模式，可能导致误判。
• 报告中的结论基于评分阈值（如 90+ 无高危问题才 Approve），复杂业务逻辑的合理性仍需人工判断。