# 1. 你 review PR 时发现重大问题但 PR 很大改起来多，你看怎么 argue 拆分 A 拆分 PR 是给作者增加负担，应尽量避免 B 只要 CI 通过，PR 大小不影响评审质量 C 拆分的目的是让每个 PR 都能被完整评审，降低漏掉重大 bug 的风险 ✓ 正确答案 D 拆分只适用于新功能，不适用于 bugfix
# 2. 你 review 别人的 PR 但他不在工位（会议/请假），你等还是 approve 你怎么看怎么 argue A 区分问题级别：blocker 等作者、非 blocker 可放行并跟踪 ✓ 正确答案 B 一律先 approve，避免阻塞 C 一律等作者回来再 approve D 直接拒绝评审，等作者回来重新提
# 3. 你 review 别人的 PR 但他不改（reviewer 提了意见 PR 作者忽略），你怎么看怎么 argue A 立即向领导投诉作者不配合 B 主动确认作者是否看到、是否理解，再决定下一步 ✓ 正确答案 C 直接合并 PR 避免纠缠 D 在群里公开批评作者
# 4. 你 review 别人的 PR 发现不是你能判断的（架构层面），你看怎么 argue 升级 A 整理信息后请资深 reviewer 或架构师参与把关 ✓ 正确答案 B 凭感觉提一个模糊意见 C 既然看不懂就直接 approve，别耽误进度 D 拒绝评审这个 PR
# 5. 你想把 review SLA 改成"工作日"但有人说"紧急 PR 怎么办"，你怎么看怎么 argue A 放弃所有 SLA，让团队自由发挥 B 常规 SLA 设工作日，同时单独定义"紧急通道"处理紧急 PR ✓ 正确答案 C 工作日 SLA 完全禁止周末 review D 所有 PR 都按紧急处理，不设常规 SLA
# 6. 你提交的 PR reviewer 要求再设计（架构层面），但你不同意，你看怎么 argue A 坚决不改，坚持自己的方案 B 直接照 reviewer 说的改，避免冲突 C 用成本/风险/收益对比分析双方方案，必要时请资深者裁决 ✓ 正确答案 D 绕过 reviewer 直接合并
# 7. 你提交的紧急 PR 需要立即 review，但 reviewer 在忙你怎么看怎么 argue A 说明紧急原因和影响，主动提供上下文，必要时请相关方确认紧急程度 ✓ 正确答案 B 反复催促 reviewer，直到他放下手头工作 C 放弃紧急 PR，等 reviewer 有空 D 直接绕过 review 合并
# 8. 你的 PR 很大 reviewer 看了 1 小时没看完，你说"我先合并你继续看"，你怎么看怎么 argue A 是提高效率的好办法，应推广 B 高风险改动不可接受，本质应反思 PR 是否过大并拆分 ✓ 正确答案 C 只要 reviewer 同意就永远没问题 D 先合后看不会增加任何成本
# 9. 你的 PR 提交后一直没 review，你催了同事说"没时间"，你看怎么 argue A 每天发消息催，直到他烦 B 放弃 review 直接合并 C 直接找领导投诉 D 主动整理 PR 关键信息降低 review 成本，约定明确时间点，必要时引用 SLA ✓ 正确答案
# 10. 你的 PR 被 reviewer 卡了 3 天，你怀疑是 reviewer 故意不 review，你怎么看怎么 argue A 直接质问对方是不是故意刁难 B 用事实和 SLA 沟通，给对方解释空间，必要时升级 ✓ 正确答案 C 从此不再提交 PR 给这位 reviewer D 在群里公开抱怨
# 11. 你的团队 review SLA 是"按 PR 大小"分级（大 PR 3 天/小 PR 1 天），但 PR 大小难定义你怎么看怎么 argue A 大小很好判断，无需担心 B 用行数/文件数/风险类别等客观指标定义大小，并配合拆分机制 ✓ 正确答案 C 所有 PR 一视同仁用同一天数 D 取消 SLA，完全靠自觉
# 12. 你的团队有人 review 很快但质量差，你看怎么推动深度 review A 公开批评 review 快的人 B 建立 review checklist 和质量指标，让深度成为可执行动作 ✓ 正确答案 C 要求每个人 review 必须超过 1 小时 D 取消 review，全凭自觉
# 13. 你的团队有人从不 review 别人的 PR，你看怎么推动 A 把 review 纳入轮值机制和职责考核，明确 review 是共同义务 ✓ 正确答案 B 端到端只靠某一个人 review C 不再帮他 review 他的 PR 作为报复 D 默认这是他的个人自由
# 14. 你的团队有大 PR（几千行）无法快速 review，你看怎么推动拆分 A 增加 reviewer 数量，硬着头皮看完 B 从制度层面规范 PR 大小，用里程碑拆分，从源头预防大 PR ✓ 正确答案 C 让作者自己承担 review 责任 D 接受现实，大 PR 就慢慢审
# 15. 你的团队的 review SLA 是 leader 定的，但大家不遵守，你看怎么 argue A 和 leader 对齐调整 SLA，建立可见度量与监督反馈机制，让 leader 参与推行 ✓ 正确答案 B 在群里公开批评不遵守的人 C 放弃 SLA，完全靠自觉 D 自己带头遵守但不管别人
# 16. 团队的 review SLA 不合理（PR 很大也要 24 小时），你怎么看怎么 argue 拆分 A 完全合理，越快越好 B SLA 应与 PR 规模匹配，并配合拆分让大 PR 不再出现 ✓ 正确答案 C 大 PR 应该不设 SLA，无限期审 D 取消所有 SLA
# 17. 团队的 review SLA 是"1 天"，但有人说"我出差"，你怎么看怎么 argue A 取消 SLA，出差就没人管 B 通过 backup 机制，出差前提前交接，保证 SLA 不因个人出差失效 ✓ 正确答案 C 让出差的人远程 review，不管时差 D 只对不出差的人要求 SLA
# 18. 团队的 review SLA 是"工作时间"，但全球团队有时差你怎么看怎么 argue A 仍按各自工作时间，管不到全球 B 用绝对时间窗口定义 SLA，配合接力机制保证 24 小时覆盖 ✓ 正确答案 C 取消 SLA D 只要求同一时区的人 review
# 19. 团队的 review 习惯是"看心情"，你想推动规律化（每天 review）你看怎么 argue A 约定固定 review 时段、用看板让状态可见、写进团队共识 ✓ 正确答案 B 强制每个人每天 review 8 小时 C 让 leader 一个人每天 review 所有 PR D 无所谓，保持现状
# 20. 团队的 review 节奏不规律（忙的时候慢/闲的时候快），你怎么看怎么稳定化 A 忙的时候就先不做 review B 让团队闲时再集中 review C 固定 review 时间块、轮值分担、设置积压阈值触发分流 ✓ 正确答案 D 只 review 最重要的 PR
# 21. 团队约定 PR 24 小时内 review 但实际平均 3 天，你怎么看怎么推动 A 直接提高 SLA 要求，改成 1 小时 B 放弃 SLA，接受 3 天 C 惩罚所有 reviewer D 度量差距出现在哪（响应/评审深度/PR 大小），再针对性解决 ✓ 正确答案
# 22. 你 review 别人的 PR 发现设计有问题但他是 senior，你看怎么 argue A 因为是 senior 就不提，他肯定对 B 私下绕过，不让他知道 C 当众严肃指出，证明自己更行 D 用事实和场景支撑观点，以探讨姿态沟通，同时保持开放 ✓ 正确答案
# 23. 你的 PR reviewer 要求拆分 PR（太大了），但拆分会让分支复杂你怎么看怎么 argue A 拒绝拆分，保住分支简单 B 按依赖顺序分批合并、保持分支短命，用机制管理分支复杂度 ✓ 正确答案 C 拆成无数个 PR，越长越乱 D 单分支直接合并，不 review
# 24. 你的 PR review 时被要求"再改改"但没说具体怎么改，你看怎么 argue A 随便改一点，交差就行 B 抱怨 reviewer 说不清楚 C 直接不理，等 reviewer 说清楚 D 复述理解并追问具体意见，必要时给出候选方向供选择 ✓ 正确答案
# 25. 你的 PR 被 reviewer 要求很多改动但有些是"风格"问题，你看怎么 argue A 全部按 reviewer 个人偏好改 B 让 reviewer 自己定一套规则 C 拒绝所有风格修改 D 用 formatter/lint 工具统一风格，区分实质问题与风格问题 ✓ 正确答案
# 26. 你的团队 review SLA 影响开发效率（review 慢导致代码过期），你怎么看怎么 argue A 责怪作者代码写得不好 B 让作者加班赶工 C 量化 review 等待导致的冲突返工成本，推动缩短 SLA 和小 PR 快速合并 ✓ 正确答案 D 接受现状，过期就重写
# 27. 你的团队 review SLA 被打破但没人追究，你怎么看怎么推动 A 让 SLA 达成情况可见、定期回顾、形成有责任有闭环的文化 ✓ 正确答案 B 让 leader 当场批评打破 SLA 的人 C 提高 SLA 数字，看起来更严格 D 取消 SLA，不设约束
# 28. 你的 PR 包含"未来扩展"代码（YAGNI 不该写），你想拆分但同事说"留着吧"，你怎么看怎么 argue A 留着，反正以后可能用 B 只要能跑，写多少都行 C 移除或拆分，等需求真正出现再基于需求实现 ✓ 正确答案 D 预留代码越多越好，体现前瞻性
# 29. 你的 PR 包含 UI+逻辑改动，你想拆分但 UI 和逻辑紧耦合你怎么看怎么 argue A 把不依赖 UI 的逻辑抽成独立模块，按可独立验证的单元拆分 ✓ 正确答案 B 无法拆就不拆，硬着头皮审查 C 只合并 UI，不合并逻辑 D 直接合并，不 review
# 30. 你的 PR 包含兼容性代码（兼容旧版本），你想拆分但兼容代码必须和生产代码一起你怎么看怎么 argue A 无论如何都要拆开，哪怕制造不兼容窗口 B 放弃兼容，直接破坏旧版本 C 只改生产代码，不管兼容 D 接受必要耦合，但剔除无关改动，聚焦核心，保证评审质量 ✓ 正确答案
# 31. 你的 PR 包含多个文件的修改，拆分会影响 git history 清晰度，你怎么看怎么 argue A 拆分必然破坏 history 清晰度 B history 清晰度不重要，能合就行 C 合理拆分配合清晰 commit 反而让 history 更有价值 ✓ 正确答案 D 一个 PR 越大越好，方便回溯
# 32. 你的 PR 包含多种语言代码（JS+SQL+配置），你想拆分但需要不同 reviewer 你怎么看怎么 argue A 一个 reviewer 全包，反正都是代码 B 只 review 一种语言 C 按领域拆分 PR 或用 CODEOWNERS 分工，让专业 reviewer 审自己擅长的部分 ✓ 正确答案 D 不拆分，直接合并
# 33. 你的 PR 包含性能优化+bugfix，你想拆分但两者都改同一文件你怎么看怎么 argue A 用独立 commit 或独立 PR 区分，便于独立评审和回滚 ✓ 正确答案 B 混在一起，反正都是一次改动 C 只合性能优化，不管 bugfix D 合并后再说
# 34. 你的 PR 包含新 feature+bugfix，你想拆分但 bugfix 是新 feature 的前置你怎么看怎么 argue A 不拆，一起合并 B 先合并独立有价值的 bugfix PR，再合 feature PR，用依赖顺序管理 ✓ 正确答案 C 只合 feature，bugfix 以后再说 D 把 bugfix 藏在 feature 里不分
# 35. 你的 PR 因为依赖关系不能简单拆分（A 依赖 B），你怎么看怎么 argue A 按依赖顺序先合 B 再合 A，或用接口解耦 ✓ 正确答案 B 放弃拆分，一起合并 C 把 A 和 B 都删掉 D 无脑拆成两个互不相干的 PR
# 36. 你的 PR 想拆分成 5 个小 PR 但担心合并冲突，你怎么看怎么 argue A 拆分必然导致更多冲突 B 冲突无解，只能硬碰 C 小 PR 快速合入+频繁同步主分支，通常比大 PR 冲突更少 ✓ 正确答案 D 5 个 PR 一定乱
# 37. 你的 PR 想按模块拆分但 reviewer 说"逻辑分散"，你怎么看怎么 argue A 不拆了，全塞一个 PR B 拆得更碎，物理文件越多越好 C 按功能/场景而非物理模块拆分，确保每个 PR 逻辑连贯 ✓ 正确答案 D 让 reviewer 自己看所有文件
# 38. 你的 PR 里有一些是临时禁用代码（feature flag），你想拆分但 feature flag 很难管理你怎么看怎么 argue A 不拆，flag 和功能代码永远在一起 B 永远别用 feature flag C 拆分 flag 配置与功能代码，并为 flag 建立 owner/上线时间/清理计划 ✓ 正确答案 D flag 越多越好，方便管理
# 39. 你的 PR reviewer 说"拆成 2 个 PR"但你觉得"合并好理解"，你怎么看怎么 argue A 坚持合并，因为作者最懂 B 完全照 reviewer 拆，不解释 C 尊重评审与回滚考量，必要时折中拆分，用 PR 描述解决理解问题 ✓ 正确答案 D 绕过 reviewer 直接合并
# 40. 团队 review 积压严重时，你如何设计“评审清理日或批量处理”机制，并度量 backlog 的下降？ A 清理日集中攻坚存量 + 日常 SLA 和阈值告警防复发，用积压数/等待时长/清零率度量 ✓ 正确答案 B 只设一个清理日，把积压清完就不管了 C 取消后续 review，让积压自然清零 D 只统计积压数量，不设目标
# 41. 你的 PR 想拆分成 2 个但每个都不完整（功能不完整），你怎么看怎么 argue A 调整拆分粒度，让每个 PR 都是独立可用、可验证的增量，或保持完整 ✓ 正确答案 B 照拆不误，反正能合 C 拆得越碎越好，不完整不重要 D 把半成品直接合入主分支
# 42. 你 review 别人的 PR 很快（几小时），但你的 PR review 很慢，你怎么看怎么平衡 A 要求别人也像我一样快，不然就说他们不行 B 分享快速 review 的方法，帮助团队一起提升节奏，同时守住质量 ✓ 正确答案 C 故意放慢自己的 review，保持公平 D 不再帮别人 review
# 43. 你的 PR 包含数据库 migration，migration 必须和代码一起发，你该怎么拆分 A 无论如何都一个 PR，不拆 B 按兼容性阶段拆分：先向后兼容变更，再切换代码，最后清理 ✓ 正确答案 C 只发代码，migration 单独延后 D 先删列再改代码，越快越好
# 44. 你的 PR 有 3000 行，reviewer 说"太大了"，你该怎么拆分 A 直接平均切成 3 个 1000 行的 PR B 分析 PR 构成（功能/依赖/风险），按可独立验证的维度拆分 ✓ 正确答案 C 把 3000 行全部删除重写 D 让 reviewer 硬着头皮看完
# 45. 你的 PR 里有一些是纯重构（不影响功能），你想拆分但需要 reviewer 看两遍你怎么看怎么 argue A 分开后每遍评审目标明确，重构用"行为不变"验证、功能用"正确性"验证，总成本更低 ✓ 正确答案 B 拆开会浪费 reviewer 时间，就该混着 C 重构和功能永远不能分开 D 只 review 功能，重构随便
# 46. 你的 PR 包含工具代码+业务代码，你想拆分但工具代码必须在业务代码前 review，你怎么看怎么 argue A 先提交并 review 工具代码 PR，再提交业务代码 PR，按依赖顺序拆分 ✓ 正确答案 B 混在一起，节省时间 C 先做业务代码，工具代码以后再说 D 工具代码和业务代码永远不分开
# 47. 紧急 PR 的特快通道如何定义“紧急”边界，避免所有人滥用导致 SLA 形同虚设？ A 用标准清单判定 + 设代价 + 定期审计，防止滥用 ✓ 正确答案 B 用户说急就算紧急 C 所有 PR 都走紧急通道，反正快 D 紧急不设任何判定
