企业级代码审查

要解决什么问题

PR 或本地改动一旦堆叠，审查很容易变成「扫一眼语法」或凭感觉挑刺：安全面漏掉硬编码密钥、维护面说不清测试该补哪里、性能面 N+1 也常被略过。团队若缺少统一 checklist，Reviewer 与 Author 对「什么叫过线」往往各说各话。

本技能在用户明确要求审查代码、Pull Request 或提交记录时启动，目标是把审查收敛到可重复的技术维度，并产出带位置与修改建议的报告，而不是替业务做对错裁决。

技能如何工作

1. 取得代码：通过 exec 或 git-read 拉取待审内容；若给出 PR URL，先拿到 diff。
2. 四维顺序审查：

- 程式碼品質：命名、SRP、DRY、循环复杂度（建议 ≤ 10）
- 安全性：输入校验、SQL Injection / XSS 等常见风险、敏感信息是否 hardcode
- 可維護性：复杂逻辑注释、核心逻辑单测覆盖率（≥ 80%）、错误处理
- 效能：N+1 查询、不必要的重复计算

1. 结构化报告：每个问题需标注行号或函数名，并给出修改方向；整体评级 A（无重大问题）/B（中等需改）/C（高严重度）/D（需重大重构）。

适用边界

• 只评估技术品质（结构、安全、可测性、明显性能反模式），不判断商业逻辑是否合理。
• 覆盖率、复杂度等阈值为 SKILL 内约定，需结合项目规范自行对齐；自动化工具未跑过的指标，审查结论应视为「待验证」而非实测数据。