代码审查与质量

它解决什么问题

代码评审在实践中常有两种失败：一是评审退化成风格之争，reviewer 因为"和我会写的不一样"否决改动；二是评审流于形式，只扫一眼主流程，正确性、边界条件、安全与性能问题被跳过。另一个越来越常见的场景是：代码由另一个 agent 或模型生成，你需要一套稳定可复用的标准来评估产物，而不是每次临时想几条检查项。

工作方式

这个技能把评审固定为五条轴线，每次改动在合并前都完整走一遍，无例外：

• 正确性（Correctness）：代码是否真的实现了它声称的功能？是否匹配 spec？null、空值、边界值等边界情况是否处理？错误路径（而非仅 happy path）是否覆盖？测试是否真的测了该测的东西？是否存在 off-by-one、竞态条件或状态不一致？
• 可读性与简洁性（Readability & Simplicity）：另一位工程师（或 agent）能否不经作者解释就看懂？命名是否有描述性且符合项目约定？控制流是否直白？1000 行能写成 100 行就是失败；抽象是否赚到了它的复杂度——第三次用例出现前不要过早泛化。
• 架构（Architecture）、安全（Security）、性能（Performance）：其余三条轴线与上述两条同级，按技能定义逐一过检。

核心决策标准很明确：只要改动确定能改善整体代码健康，就通过——即使它不完美。完美的代码不存在，目标是持续改进；不要因为"这不是我会写的方式"而阻塞合并。

典型触发点：合并 PR 前、功能实现完成后、评估其他 agent 或模型产出的代码时、重构既有代码时、bug 修复后（修复本身与回归测试都要评审）。

适用边界

它提供的是评审框架与决策标准，不替代 lint、静态分析或 CI 中的测试运行——机器能检查的部分仍应由工具负责。通过标准面向"持续改善"的项目文化；若项目有合规或安全关键要求，可能需要在此之上叠加更严格的门禁。