# 1. Review 反馈的"优先级"（priority）中 nit、suggestion、issue、blocking 的分级，如何让作者优先处理高价值意见？ A 所有意见都同权，作者自行取舍 B 分级会降低作者主动性，应取消 C nit/suggestion/issue/blocking 分级让作者优先处理高价值意见，blocking 必须修复 ✓ 正确答案 D 只有 blocking 需要记录，其余忽略
# 2. Review 反馈的"具体性"（specificity）原则中指向行号、给出示例、解释原因 A 反馈只需指出"这里有问题"，定位由作者自己找 B 具体性会让反馈过于冗长，应尽量简短 C 具体反馈应指向行号、给出示例并解释原因，让作者直接可行动 ✓ 正确答案 D 原因说明是多余的，作者照着改即可
# 3. Review 反馈的"可操作性"（actionable）中给出修复建议而非单纯指出问题，如何提升意见的可执行性？ A 可操作反馈给出修复方向与理由，让作者知道如何改，提升采纳率 ✓ 正确答案 B 指出问题就够了，怎么改是作者的事 C 可操作反馈会限制作者思路，应只指出问题 D 可操作性只适用于新手评审
# 4. Review 反馈的"客观证据"（objective evidence）中文档、规范、测试、metrics 引用 A 反馈应只用个人观点，不需要证据 B 客观证据只在大型项目需要 C 引用规范、文档、测试与 metrics 等客观证据能减少主观争执、提升说服力 ✓ 正确答案 D 引用证据会让反馈过于冗长
# 5. Review 反馈的"建设性"（constructive）中聚焦代码而非个人 A 反馈应直接指出"你写错了"，最直接有效 B 建设性意味着只说好话，不指出问题 C 建设性反馈聚焦代码而非个人，用客观语言描述问题，保护心理安全 ✓ 正确答案 D 措辞只影响感受，不影响采纳率
# 6. 代码变更的"风险分级"（risk classification）中 critical、high、medium、low 的客观标准 A 风险分级只由评审者主观感觉决定 B 分级只影响发布，不影响评审 C 所有变更风险相同，无需分级 D 依据影响面、波及范围、数据/资金敏感性等客观维度分级，并驱动评审强度与门禁 ✓ 正确答案
# 7. 风险分级的"变更影响"维度中单服务 vs 跨服务、单库 vs 跨库 A 单服务与跨服务变更风险相同 B 跨服务/跨库变更涉及契约、发布顺序与一致性，风险显著更高，需更严格评审 ✓ 正确答案 C 单库变更一定比跨库更危险 D 影响维度不影响风险分级
# 8. 风险分级的"变更类型"维度中 feature、refactor、bugfix、perf、security A 不同类型（重构/安全/性能等）风险特征不同，评审关注点应相应调整 ✓ 正确答案 B 所有变更类型风险相同，评审方式一致 C 安全修复风险最低，可快速合并 D 重构无任何风险
# 9. Review 反馈中 emoji 表情的使用规范（:bulb:、:warning:、:hammer:） A emoji 越多越好，能表达所有情绪 B 统一约定 emoji 语义（如 :warning: 表示高风险）可辅助快速分类，但应适度使用 ✓ 正确答案 C emoji 会显得不专业，应完全禁用 D emoji 只用于个人消息，不用于评审
# 10. Review 反馈的"thread"（讨论串）中保持讨论集中避免分散 A thread 把同一问题的讨论收敛在特定位置，便于迭代与回溯 ✓ 正确答案 B 每个问题都应单独开多条评论，越分散越好 C thread 会阻碍讨论，应避免使用 D thread 只对远程评审有意义
# 11. critical 级变更的多重评审（multi-reviewer）要求 A critical 变更只需一个人看，避免拖延 B 多重评审只用于大型团队 C 评审者越多质量一定越高 D 多重评审提供独立视角互补，降低漏检与权威偏差，适合高风险变更 ✓ 正确答案
# 12. 评审中"我不同意但作者有道理"时如何收敛，避免无限辩论？ A 无客观依据的分歧应尊重作者选择，避免无限辩论，必要时升级仲裁 ✓ 正确答案 B 评审者必须坚持自己的意见直到作者同意 C 分歧越多人讨论越好，无限辩论也应继续 D 作者永远无权决定，评审者说了算
# 13. 如何避免评审变成"找茬竞赛"，建立以学习为导向的评审文化？ A 评审员应尽量多报问题，报得越多越优秀 B 强调肯定性反馈、提问式表达与知识沉淀，让评审成为共同学习而非对抗 ✓ 正确答案 C 找茬竞赛能提升评审强度，应鼓励 D 文化建设与评审质量无关
# 14. 评审意见的"拒绝与辩解"流程中作者不同意意见时的记录、讨论与仲裁机制，如何既避免无效争论又保留合理异议？ A 作者必须无条件接受所有评审意见 B 作者可以无视评审意见，无需说明 C 异议应记录、限定轮次讨论，实现细节尊重作者、不可逆决策升级仲裁 ✓ 正确答案 D 任何异议都必须争论到一方服软
# 15. 风险分级的上下文维度中新增代码、修改核心路径与删除代码的评审关注点与风险差异如何判断？ A 新增、修改、删除代码的风险完全相同 B 新增关注设计契合、修改核心路径关注回归、删除关注引用与契约，评审重点应不同 ✓ 正确答案 C 删除代码没有任何风险 D 上下文不影响评审关注点
# 16. 评审的责任边界中评审者负责发现、作者负责修复与验证，如何界定职责避免推诿？ A 评审者应对所有缺陷负责，即使没发现 B 评审者应替作者写好所有修复 C 作者无需回应评审意见 D 评审者负责发现并说明，作者负责修复验证并对变更负责，二者互补 ✓ 正确答案
# 17. low 级变更的快速评审（quick review）或快速合并 A low 级变更也必须完整评审，不能省 B low 级变更无需任何检查即可合并 C low 级变更可走快速通道（快速评审或自动合并），释放评审精力给高价值变更 ✓ 正确答案 D 所有变更都应快速合并
# 18. 评审意见与修复提交的追溯中如何把每条意见关联到对应提交，便于审计与复盘？ A 通过 thread resolved、提交引用等把意见与修复关联，形成闭环便于审计与复盘 ✓ 正确答案 B 评审意见与修复提交无关，无需关联 C 追溯只用于合规审计 D 提交信息不应引用评审意见
