用途：评审代码变更，包括 PR、分支、diff、未提交改动，以及智能体、同事或自己写的代码；适用于中型/大型工作合并、提交或交接前，以及 CI、构建、部署、认证、支付、迁移、脆弱配置等小而关键的改动。
主要能力：以工程原则为基线，检查正确性（需求、边界、错误路径、测试、回归、状态/并发）、可读性（命名、控制流、抽象、diff 范围、无死代码）、架构契合（边界、所有权、耦合、现有模式、公共契约）；仅在涉及认证、用户输入、密钥、PII、上传、回调、SQL、CORS/CSP/cookie 时查安全，仅在复杂查询、渲染、大数据、热路径、缓存、worker、包体积或页面加载敏感代码时查性能。支持记录发现、给出结论，并可拆分为规格符合性与代码质量两轮评审。
使用方式：先理解契约与验证证据，再优先审查测试，然后读取实际 diff（如 git diff --stat <base>..<head>、git diff <base>..<head>，未提交时 git status --short、git diff）。发现按 Critical、Important、Minor、Question、FYI 分类，结论为 Approve、Approve with minor follow-ups、Request changes 或 Needs clarification。需要独立视角时可打包上下文交给新评审者，关注变更内容、契约、diff 范围、已运行的验证、已知风险与期望输出格式。
适用场景：提交前评审、合并评审、交接评审、对智能体生成代码的信任评估，以及大型计划驱动工作的两轮评审。
限制：自我评审证据较弱，只适合极小低风险改动；评审者需具备新鲜上下文；安全与性能仅在相关时检查，否则应明确排除；契约缺失或矛盾时无法给出有效结论，应标记为需要澄清；不能以个人偏好阻止净正向改动。