用途：为团队提供一套系统化的代码评审方法，目标是既提升代码质量，也促进知识共享与协作，而非把评审当作门槛或个人评判。
主要能力与结构：
- 评审优先级：将问题分为关键（安全漏洞、数据丢失风险、无迁移的破坏性变更、影响正确性的逻辑错误，需阻止合并）、重要（缺陷与边界情况、性能问题、缺少测试、架构问题）、建议（可读性、命名、文档、重构机会）和细节偏好（风格、格式、主观选择）四档。
- 检查清单：覆盖安全（硬编码密钥、输入校验、SQL 注入、XSS、认证授权、敏感数据、依赖更新、调试后门）、逻辑（边界、错误处理、空值、竞态、状态管理）、架构（项目模式、关注点分离、依赖方向、循环依赖、抽象层级、DRY、SOLID）、可维护性（可读性、函数大小、命名、注释、魔法值、复杂度）、测试（新功能测试、边界覆盖、可读性、实现细节、既有测试）与性能（查询效率、N+1、缓存、内存、主线程阻塞）。
- 反馈格式：按“级别、问题、原因、建议”给出，并用前缀区分关键、重要、建议、细节、疑问、思考与肯定。
- 沟通语气：避免命令与否定式表达，改用“考虑”“如果……会怎样”等提问式措辞。
- 策略与场景：分概览、细节、上下文三遍评审；超大 PR 建议拆分并优先看高风险文件；针对重构、缺陷修复、新功能、依赖更新等场景列出关键提问。
- 其他：提供提交评审前的自检清单、评审者时效与完整性要求，以及 10 分钟快速评审路径和常见风险信号（如超大 diff、缺测试、注释代码、无票据 TODO、魔法值等）。
使用方式：按资料中的检查清单逐项核对变更，用统一反馈格式写出评论，并依据优先级决定是否阻止合并。资料未提供安装命令、工具集成方式或自动化能力说明。
适用场景：团队代码评审、PR 审查、评审规范制定与评审者培训。
限制：资料为评审方法论与实践指南，未说明支持的平台、语言、是否自动化执行或具体产品形态；未提供收费、价格或效果数据；缺失事实暂未提供。