# 1. Code Review 的核心目标中发现缺陷、知识共享、规范执行、设计对齐——四者的优先级排序 A 发现缺陷是唯一目标，应把人工精力全部用于逐行找 bug B 设计对齐与知识共享是长期价值最高的目标，规范执行应尽量下沉到自动化 ✓ 正确答案 C 规范执行优先级最高，评审应逐条核对命名规范 D 四个目标优先级固定不变，任何场景下权重相同
# 2. Review 的"安全氛围"中建设性反馈与心理安全（psychological safety） A 心理安全会降低评审强度，应避免营造 B 心理安全让作者敢于暴露弱点、评审者敢于提出疑问，从而提升真实反馈质量 ✓ 正确答案 C 心理安全指评审中只说好话、不批评 D 心理安全只对新人重要，资深工程师不需要
# 3. Review 的"异步优先"（async-first）与"必要时同步"（sync when needed）的边界 A 所有评审都应同步进行，效率最高 B 默认异步优先，遇到文字难以澄清的歧义或设计分歧时应升级为同步并回写结论 ✓ 正确答案 C 异步评审没有任何缺点，永远优先 D 同步评审只用于远程团队，本地团队必须异步
# 4. Review 的"轻量 PR"（small PR）原则中< 400 行的可读性与认知负荷研究 A 变更越大评审越全面，应鼓励大 PR B 认知负荷与 PR 大小无关 C 超过约 400 行的 PR 缺陷发现率显著下降，小 PR 更利于完整理解与深入评审 ✓ 正确答案 D 小 PR 只对新人有利，对资深工程师无意义
# 5. Review 的"高质量反馈"原则中可执行的建议 vs 个人偏好 A 任何个人偏好都值得写成评审意见 B 可执行建议指向具体位置、给出方案与理由，个人偏好应谨慎表达避免噪音 ✓ 正确答案 C 反馈越详细越好，不考虑是否可执行 D 只有架构师的意见需要可执行，普通评审者不需要
# 6. Review 范围的"什么该看、什么不该看"，风格 vs 架构 vs 业务逻辑的边界 A 评审应逐行挑出所有风格问题，一个都不能少 B 风格等低级问题应交给自动化，人工聚焦架构与业务逻辑语义 ✓ 正确答案 C 架构问题不重要，只需看业务逻辑 D 评审范围越宽越好，包揽所有层面
# 7. 评审通过标准（approval criteria）的显式化中最少批准数、必需评审者（CODEOWNERS）、CI 全绿三类条件如何组合成合并门禁 A 最少批准数、CODEOWNERS 必需批准与 CI 全绿三类条件组合成可执行的合并门禁 ✓ 正确答案 B 门禁只需 CI 全绿即可，评审可省 C 批准数越多越好，不设上限 D CODEOWNERS 门禁只对大公司有用
# 8. 评审 Checklist 的"分层设计"中通用项（命名、测试、错误处理）与领域项（SQL 注入、并发安全）如何避免清单膨胀到逐项勾选失效 A 清单项越多越全面，应尽量堆叠 B 通用层控制精简，领域层按变更类型动态加载，避免清单膨胀失效 ✓ 正确答案 C 清单只该包含 SQL 注入等高风险项 D 清单一旦制定就不可修改
# 9. Review 的"作者自我评审"（self-review）的检查清单 A 自我评审是评审者的职责，作者无需自审 B 作者提交前自审可拦截低级错误，降低评审者负担，让评审聚焦设计问题 ✓ 正确答案 C 自我评审会浪费时间，应跳过 D 自我评审只在大型 PR 才需要
# 10. Review 的"快速首过"（first pass）原则中 24 小时内首过 A 评审可以拖到作者提醒后再看 B 首过必须一次审完所有内容 C 24 小时内首过能让反馈保持新鲜、降低修复成本并避免 PR 堆积 ✓ 正确答案 D 快速首过会降低评审质量
# 11. Review 的"自助 PR 模板"（pull_request_template.md）的设计 A 模板字段越多越好，能覆盖所有信息 B 模板引导作者提供动机、方案、测试等关键上下文，降低评审理解成本 ✓ 正确答案 C 模板会限制作者自由，应禁用 D 模板只对大型仓库有意义
# 12. Definition of Done（完成的定义）中 DoD 如何与代码评审合并条件、测试覆盖、文档更新联动，避免"代码能跑就算完成"？ A DoD 指代码能编译运行即可 B DoD 一旦定义就不可变更 C DoD 只属于项目管理，与代码无关 D DoD 显式定义完成标准，把评审、测试、文档联动起来，避免"能跑就行" ✓ 正确答案
# 13. PR 生命周期状态机中 draft、in-review、changes-requested、approved 的状态流转与合并纪律如何自动化？ A 状态机+分支保护让合并纪律自动化，新提交需重新批准避免"批准后塞变更" ✓ 正确答案 B 状态流转无需规则，评审者随意切换 C draft 状态不能转 in-review D approved 后就不能再修改
# 14. 评审者的阅读策略中先读 PR 描述与测试用例建立预期再读 diff，如何系统性提升缺陷发现率？ A 直接从第一行 diff 读到最后一行的效率最高 B 测试用例与评审无关，不必读 C 先读 PR 描述与测试用例建立预期，再读实现，能更聚焦地发现行为偏差 ✓ 正确答案 D 阅读顺序不会影响缺陷发现率
# 15. Checklist 与自动化 lint 的职责切分中哪些清单项应交给机器强制、哪些必须保留人工判断 A 所有清单项都应交给机器 B 确定性规则交给自动化，需要语义判断的项保留人工评审 ✓ 正确答案 C 所有清单项都必须人工逐条勾选 D lint 与清单毫无关系
# 16. 评审的度量中覆盖率、周期与缺陷？ A 单一指标（如覆盖率）就足以评估评审质量 B 度量只用于考核个人绩效 C 覆盖率、周期与缺陷等指标应组合解读，区分先行与滞后指标，用于改进流程 ✓ 正确答案 D 缺陷指标与评审无关
# 17. 评审 vs 结对中协作模式的取舍？ A 结对一定优于评审，应全部用结对 B 结对只用于新人，评审只用于资深 C 两种模式互斥，不能同时使用 D 评审是异步后置把关，结对是同步前置预防，按复杂度和风险选择，二者可互补 ✓ 正确答案
# 18. 评审的知识沉淀中评审中反复出现的通用问题如何反哺规范与 FAQ，避免同类问题反复提出？ A 评审问题应随提随忘，不必沉淀 B 沉淀会浪费时间，应避免 C 沉淀文档只能由架构师维护 D 高频通用问题应分类统计并沉淀为规范/FAQ/ lint 规则，减少重复反馈 ✓ 正确答案
