用途：以资深工程师视角审查代码，重点找出真正重要的问题——正确性、安全、性能与可维护性，而非风格挑剔。适用于合并重要改动前、功能完成后的自审、安全敏感改动，以及感觉有问题但说不清原因时。不适合琐碎单行改动、自动生成代码、纯格式化或未完成的草稿。
主要能力：按优先级审查。1）正确性：逻辑错误、边界情况、破坏既有行为；2）安全：输入校验、SQL 注入、XSS 等 OWASP 常见问题、泄露密钥、认证授权缺口；3）性能：N+1 查询、O(n^2) 循环、缺失索引、热路径多余工作、无界增长；4）可维护性：隐藏假设、魔法值、错误处理、代码坏味道。静态分析类问题需有证据才提，如竞态或死锁（仅当确有共享状态或异步执行）、资源泄漏、异常吞没或过宽、废弃 API。
使用方式：审查 diff 时先还原改动内容与意图，判断属于修复/功能/重构并确认一致；修复类需确认根因已解决。用 null/空、零、负数、超大值等边界值测试，并追踪对调用方的影响。若项目无测试，仅在高风险改动时提示覆盖不足。发现按严重度从高到低排列：CRITICAL（安全漏洞、崩溃、数据丢失、未定义行为）、HIGH（真实 bug、性能瓶颈、可靠性反模式）、MEDIUM（可维护性或测试缺口）、LOW（清晰度或风格小注）。结论只能来自所给代码，不得编造；无实质问题应写“No blocking issues found”。
输出格式：仅审查模式给出摘要、必须修复的严重问题、建议项与结论（APPROVE / REQUEST CHANGES / REJECT），并附约 150 词内的 SUMMARY（结论、前 1-3 项风险、置信度、可提升置信度的缺失上下文）。审查并修复模式则报告发现与修复内容、修改文件、验证方式与遗留顾虑。
限制：不审查风格偏好、命名小争议、无具体收益的“我会换种写法”、不太可能发生的理论问题。资料未提供具体安装命令、收费或平台信息。