核心用法
afrexai-code-reviewer 是一个纯文档型的企业级代码审查框架，通过 SPEAR 五维评估体系 为代码审查提供结构化方法论。用户可通过自然语言指令触发审查，支持 GitHub PR、本地 diff、单文件或粘贴代码四种输入模式。核心工作流程为：输入代码 → 自动套用 SPEAR 框架 → 生成标准化评分报告。
SPEAR 框架的五个维度及其权重分别为：Security（安全，3x）、Performance（性能，2x）、Error Handling（错误处理，2x）、Architecture（架构，1.5x）、Reliability（可靠性，1.5x）。每个维度下设 10-12 项具体检查点，覆盖 60+ 种语言特定模式（TypeScript/Python/Go/Java/SQL 等）。评分采用扣分制：CRITICAL 问题扣 3 分、HIGH 扣 2 分、MEDIUM 扣 1 分、LOW 扣 0.5 分，最终换算为 0-100 分并给出五级 verdict（EXCELLENT/GOOD/NEEDS WORK/SIGNIFICANT ISSUES/BLOCK）。
显著优点
框架化思维：将主观代码审查转化为可量化的评分体系，大幅降低评审者认知负担，同时保证审查覆盖面的完整性。Security 维度 3 倍权重的设计体现了"安全优先"的工程原则。
语言覆盖全面：不仅提供通用检查项，还针对主流语言列出典型反模式（如 Python 的 bare except、Go 的 error 丢弃、JavaScript 的 any 类型滥用），实用性极强。
输出标准化：强制使用统一的 Markdown 报告模板，包含执行摘要、维度得分表、分级 findings、正向反馈、优先建议五大模块，便于团队沉淀审查知识。
零依赖设计：纯指导性 Skill，无需安装任何工具链或配置环境，开箱即用。
潜在缺点与局限性
执行依赖人工：该 Skill 仅为审查指南，不自动分析代码，所有检查需评审者手动完成，无法替代静态分析工具（如 SonarQube、CodeQL）的自动化能力。
评分主观性：虽然提供了扣分标准，但"God function >50 行"等阈值、以及问题严重程度的判定仍依赖评审者经验，不同人可能给出差异较大的评分。
语言更新滞后：新兴语言特性（如 Rust 的 async、Zig 的 comptime）或框架特定模式（如 React Server Components）可能未被及时覆盖。
大型 PR 适配性：虽提及>500 行 PR 应拆分，但未提供有效的增量审查策略，实际执行中可能因信息量过大而流于形式。
适合的目标群体
- 技术团队负责人：需要建立团队代码审查规范，统一评审标准
- 初级/中级开发者：希望系统学习代码质量维度，提升审查能力
- 开源项目维护者：处理外部贡献时快速评估 PR 质量
- 代码审计顾问：为客户提供结构化审查报告时作为方法论支撑
使用风险
性能风险：无。纯文档型 Skill，无计算开销。
依赖风险：无第三方依赖，但需注意该 Skill 本身不产生审查结果，实际效果完全取决于使用者的工程判断力。
误用风险：过度依赖评分可能导致"分数导向"而非"质量导向"的审查文化；建议将 SPEAR 作为辅助框架，而非唯一决策依据。