这是一个以资深视角进行代码评审的框架，用途是评审代码、给出建设性反馈、评估 PR（Pull Request），并把指导他人与保持代码质量作为核心。
用途与目标优先级：按顺序关注正确性（是否做该做的事、是否处理边界情况、是否安全）、可维护性（他人能否理解、是否易于修改、是否遵循项目既有模式）、性能（是否存在明显性能问题，但不做过早优化）、风格（是否与代码库一致，优先级最低，理想情况下交给自动化工具）。
评审流程：先理解上下文再读代码，包括阅读 PR 描述明确解决什么问题、为何采用该方案，查看相关 ticket/issue 的验收标准与已记录的边界情况，并判断改动范围大小。其原则是：若不理解“为什么”，先提问，再评审“怎么做”。随后按结构化顺序评审：测试（是否存在、是否覆盖正常路径和重要边界、是否可维护）、API/接口（公共契约是否合理、是否与现有 API 一致、是否考虑版本化）、实现（逻辑是否正确、错误处理是否恰当、副作用是否受控）、集成（对系统其余部分的影响、是否有破坏性变更、是否需要迁移）。
评论分级：用阻塞（BLOCKER，要求修改，如会导致生产环境故障、安全漏洞、数据丢失、未记录的破坏性变更）、建议（SUGGESTION，如清晰度改进、更地道的模式、非关键性能、可选重构）、小问题（NIT，可选，如风格格式、命名、锦上添花的注释）以及表扬（PRAISE，如优雅方案、良好边界处理、优秀测试）来分类。
有效评论方式：避免“这是错的”这类无解释评论，应说明问题并给出建议、先提问再假设、提供上下文、承认权衡取舍。反馈应因材施教：对初级开发者多解释原因、提供文档示例；对资深开发者聚焦边界情况和架构、以同行身份讨论权衡；对项目新人指出项目约定与历史背景。
接收评审的心态：把评审视为改进代码而非攻击个人，允许有理由地维护决定，“不知道”也是合理回答；同意时明确确认，想讨论时给出理由，不理解时请求澄清，避免防御性回应或忽略评论。
使用限制：资料未提供官方安装方式、收费信息、支持平台或具体使用步骤；内容以评审方法论与示例为主，命令与代码示例需按原文保留，不得改动。