用途：在开发流程的验证阶段进行系统化代码评审，关注评审过程与质量维度，而非特定技术栈的模式。适用于需要结构化评审、质量评估与明确结论（通过、要求修改、需要讨论）的场景。
主要能力：按四阶段组织评审。准备阶段使用 git diff <base-branch>...HEAD 与 git diff --stat <base-branch>...HEAD 了解改动与范围，并用 grep 查找代码库中相似实现，确认业务背景。系统评审覆盖六个维度：正确性（先读测试理解意图、追踪代码路径、验证错误场景）、安全性（鉴权授权、API 破坏性变更、敏感数据暴露、输入校验与事务边界）、可维护性（是否沿用现有模式、可读性、复杂逻辑文档、命名、魔法数字、注释掉的代码）、可测试性（新增功能测试、边界与错误路径、确定性、隔离性）、性能（N+1 查询、缺失索引、资源管理）、规范合规（语言最佳实践、lint 与类型检查、质量门禁）。
反馈与决策：所有发现需给出 0-100 置信度，仅报告置信度≥80 的问题。反馈结构为总体评估、优点、问题（按严重级别与置信度分组）、验证状态与决策。决策分为通过、要求修改、需要讨论。
限制与边界：不覆盖技术特定模式与具体实现指导；评审不能替代自动化验证，需先通过验证套件；应过滤预存问题、lint 已处理项、无明确标准的风格偏好等误报；明确的红旗问题（如注释掉的代码、代码中的密钥、未验证的破坏性变更、被跳过或注释掉的测试、缺少测试、硬编码业务逻辑、缺失错误处理、明显安全漏洞）始终要求修改。