技能介绍

为什么需要规范代码评审

在日常开发中，代码评审往往陷入两个极端：要么因为标准模糊而沦为无意义的风格争论，要么因为要求苛刻而成为拖延合并的瓶颈。开发者经常遇到"这代码功能正常但结构混乱"的情况，或者在面对动辄数千行的巨型文件时无从下手。如果没有一个客观的多维度清单，评审者很容易陷入主观偏好，只关注代码是不是"像我写的那样"，而忽略了架构退化、潜在性能隐患或深层的复杂度堆积。

核心能力与关键步骤

本技能通过一套标准化的五轴评审体系，将代码质量的检查具象化。它不依赖直觉，而是要求评审者依次检查正确性（如边界条件和错误处理）、可读性与简洁性（如抽象是否赚取了其复杂度）、架构设计（如依赖流向和类型边界）、安全性（如输入校验和SQL注入防范）以及性能（如N+1查询检测）。

在审查流程上，技能主张测试先行，通过测试代码来推断实现意图。对于发现的结构性问题，技能强制要求评审者提供重构建议，例如将重复的条件分支合并，或将特性逻辑从共享模块中剥离。同时，它引入了严格的变更拆分策略，如Stack或Vertical拆分，并要求将重构与特性开发分离提交。最后，通过严重程度标记（如Critical:或Nit）对评审意见进行分级，避免作者在非核心问题上浪费精力。

适用边界与注意点

该技能适用于功能特性开发、重构及Bug修复后的评审，但对"完美代码"有明确的清醒认知：批准标准是改进而非完美。需要注意的是，技能明确要求拒绝"以后会清理"的承诺，要求在提交前完成死代码清理。在处理意见分歧时，应遵循技术事实优于个人偏好的原则。此外，为了弥补单一模型的盲区，推荐采用多模型评审模式，从不同视角交叉验证代码逻辑。