用途：在任何 PR 或变更合并前进行代码评审，覆盖五个维度：正确性（是否符合规格、边界与错误路径、测试是否真正有效）、可读性与简洁性（命名、控制流、抽象是否值得其复杂度、有无死代码）、架构（是否遵循既有模式、模块边界、依赖方向、重复代码）、安全（输入校验、密钥不入库与日志、鉴权、参数化查询、输出编码、依赖漏洞、外部数据视为不可信）、性能（N+1 查询、无界循环与取数、同步阻塞、多余重渲染、缺少分页）。
批准标准：当变更确实改善整体代码健康度时即可批准，即使并不完美；不要因风格偏好而阻塞，符合项目约定就通过。
使用方式与流程：先理解意图与规格，再先看测试（是否有测试、是否测行为而非实现、边界是否覆盖、命名是否清晰），然后按五轴逐文件审查，最后分类标注结论。评审意见前缀约定：无前缀为必须修改；Critical 阻塞合并；Nit 为可选小问题；Optional/Consider 为建议；FYI 仅告知。评审后核验作者的验证说明（跑了哪些测试、构建是否通过、是否手动验证、UI 变更有无截图）。
变更规模：约 100 行为宜，约 300 行在单一逻辑变更下可接受，约 1000 行应拆分。拆分策略包括堆叠提交、按文件组、横向（先共享代码再消费者）、纵向（按功能切片）。重构与功能变更应分开提交。
评审节奏：一个工作日内响应为上限，典型变更应能在同日完成多轮。争议处理以技术事实、风格指南和工程原则为准，不接受“以后再清理”，除非紧急情况并要求另开缺陷单。
多模型评审：可由一个模型写代码、另一个模型审查正确性与架构，再由人做最终判断，以弥补单一模型的盲区。同时应审查依赖：优先标准库与既有工具，评估体积、维护状态、漏洞与许可证。
限制：未提供具体命令、安装方式、价格、平台或工具集成细节，暂未提供。