# 1. 你培养的 reviewer 开始 review 很严被人投诉，你怎么看怎么 argue 平衡 A 让他别那么严，随便放行 B 帮他建立 blocker/should/nit 优先级，把严格用在关键问题 ✓ 正确答案 C 支持他从严，投诉的人不懂 D 让他辞职
# 2. 你培养的 reviewer 走了（离职）导致 reviewer 池变小，你怎么看怎么 argue 可持续 A 走一个就少一个，接受现状 B 断言评审靠 hardskill 个人天赋 C 只让 leader 一个人 review D 持续超配培养 reviewer、沉淀评审知识，消除单点依赖 ✓ 正确答案
# 3. 你想做 reviewer 绩效考核但 leader 说"没法量化"，你怎么看怎么 argue A 确实没法量化，放弃 B 只按 review 数量排名 C 用数量/速度/质量/深度多维指标，定量+定性结合量化 ✓ 正确答案 D 只按 leader 印象打分
# 4. 你想做 reviewer 轮值但有 reviewer 说"我忙"，你怎么看怎么 argue A 忙的人就不轮值 B 用负载感知分配+替换机制，让忙的人通过换班而非免除解决 ✓ 正确答案 C 强制所有人轮值，忙也要排 D 取消轮值，谁愿意谁做
# 5. 你想培养新人做 reviewer 但 leader 说"再等等"，你怎么看怎么推动 A 听 leader 的，继续等 B 用影子评审+老手复核+低风险范围，让领导放心地开启培养 ✓ 正确答案 C 直接让新人独立评审，证明能力 D 让新人自己争取
# 6. 你想建立 reviewer 轮值机制但有人说"有些人 review 水平不高"，你怎么看怎么 argue A 确实，水平低的不该轮值 B 只有高手能 review C 用分级评审让核心由资深把关、常规众人参与，轮值中培养提升 ✓ 正确答案 D 所有 PR 都让新人评，练手
# 7. 你想推动"reviewer 成长路径"（从 basic 到 advanced），你怎么看设计 A 全靠个人自己摸索 B 成长路径没有意义 C 只分 senior 和 junior 两级 D 分阶段定义评审范围、能力清单、复核反馈和里程碑 ✓ 正确答案
# 8. 你想推动"每个 PR 至少 2 个 reviewer"但有人说"太多了"，你怎么看怎么 argue A 取消，所有 PR 都单审 B 分级：核心/高风险 PR 双审，低风险 PR 弹性单审 ✓ 正确答案 C 所有 PR 都强制 3 人评审 D 只要 2 人就能保证所有质量
# 9. 你想让 reviewer"领域分工"（前端 reviewer 只看前端），但有人说"全栈"，你怎么看怎么 argue A 只要领域专家，够了 B 领域主审保证深度 + 全局复核保证整体视角，结合 ✓ 正确答案 C 只要全栈，不要领域 D 谁都能评，不分领域
# 10. 你想让 reviewer 有"否决权"但有人说"会导致僵持"，你怎么看怎么 argue A 取消否决权，避免僵持 B 保留否决权并配套仲裁/申诉机制，既保质量底线又不失控 ✓ 正确答案 C 否决权只能 senior 用 D 让否决权凌驾一切
# 11. 你想让新人 review senior 的 PR，但 senior 不愿意，你怎么看怎么 argue A 尊重 senior，不让新人看 B 强制 senior 必须接受新人意见 C 新人 review 作为补充视角+资深兜底，双向获益 ✓ 正确答案 D 新人 review 只用于锻炼，不产生价值
# 12. 你的团队 review 质量参差（有人严有人松），你怎么看怎么统一标准 A 让 leader 统一审所有 PR B 取消标准，越严越好 C 让每个 reviewer 按自己的标准来 D 用 checklist、优先级共识、评审案例库统一评审标准 ✓ 正确答案
# 13. 你的团队只有少数人能 review（大部分是 junior），你怎么看怎么扩大 reviewer 池 A 用分级评审、影子评审、老手复核培养 junior 加入评审 ✓ 正确答案 B 继续让少数人扛，等他们更强 C 减少评审，只审关键 PR D 让 junior 独立评审练手
# 14. 你想做 reviewer 奖励（表彰优秀 reviewer）但 leader 说"没必要"，你怎么看怎么 argue A 低成本表彰能让认真 review 被看见，激励评审文化 ✓ 正确答案 B 确实没必要，别浪费 C 只有发大额奖金才有效 D 奖励会让人只为了奖励 review
# 15. 你想做 reviewer 工作量评估（reviewer 工作饱和），你怎么看设计 A 只看 review 的 PR 数量 B 看谁最闲就多给谁 C 结合数量、复杂度、质量多维评估，用于调整负荷分配 ✓ 正确答案 D 评估只是形式，不用于分配
# 16. 你和 PM 对接口事务边界有分歧（PM 要一个大事务，你要多个小事务），你怎么看怎么 argue A 大事务总是更安全 B 依据业务强一致需求决定，可用小事务+补偿实现最终一致 ✓ 正确答案 C 小事务总是更好 D 事务边界无所谓
# 17. 你和 PM 对接口分页有分歧（PM 要 page，你要 cursor），你怎么看怎么 argue A page 永远最简单 B 依据数据量、实时性、跳页需求：大数据量/实时变化用 cursor，小数据用 page ✓ 正确答案 C cursor 永远最优 D 分页方式无所谓
# 18. 你和 PM 对接口字段类型有分歧（PM 要 String，你要 int），你怎么看怎么 argue A 数值就该用 int B 标识符用 int 更省空间 C 依据语义：数值型用数值类型，标识符用 String 避免精度/扩展问题 ✓ 正确答案 D 字段类型无所谓
# 19. 你和 PM 对接口幂等超时时间有分歧（PM 说 1 小时，你说 30 分钟），你怎么看怎么 argue A 1 小时更安全 B 幂等超时无所谓 C 30 分钟更省 D 依据业务真实重试间隔覆盖需求与资源成本权衡 ✓ 正确答案
# 20. 你和 PM 对接口幂等键有分歧（PM 说用业务 ID，你要用系统生成），你怎么看怎么 argue A 业务 ID 够用 B 系统 key 唯一标识更可靠，可与业务 ID 结合使用 ✓ 正确答案 C 系统 key 多余 D 幂等键随便
# 21. 你和 PM 对接口文档格式有分歧（PM 要 Markdown，你要 OpenAPI），你怎么看怎么 argue A Markdown 简单够用 B 用 OpenAPI 作为规范源自动生成文档，解决过期与不一致 ✓ 正确答案 C 只用 OpenAPI 不生成人读文档 D 文档格式无所谓
# 22. 你和 PM 对接口版本管理有分歧（PM 说不用版本，你要 v2），你怎么看怎么 argue A 确实不用版本，简单 B 版本管理为破坏性变更提供隔离和平滑迁移，避免下游被迫强迁 ✓ 正确答案 C 版本越多越好 D 版本只是形式
# 23. 你和 PM 对接口错误码有分歧（PM 要业务错误码，你要 HTTP 状态码），你怎么看怎么 argue A 只用 HTTP 状态码 B 只用业务错误码 C HTTP 状态码管传输层 + 业务错误码管业务层，两者结合 ✓ 正确答案 D 错误码不重要
# 24. 你的接口 Header 变了但下游没更新，你看怎么 argue A 让下游自己适配 B 评估影响，必要时兼容窗口或回滚，并建立变更通知流程 ✓ 正确答案 C 直接改，下游会知道 D 只通知 VIP 下游
# 25. 你的接口 URL 变了但下游写死了 URL，你看怎么 argue 版本管理 A 直接改，下游自己想办法 B 只让大客户迁移 C URL 想变就变 D 保留旧 URL 重定向或版本化，给下游迁移缓冲 ✓ 正确答案
# 26. 你的接口 boolean 字段反转了（true 变成 false），你看怎么 argue A 直接反转，下游会适应 B 反转后加个注释就行 C boolean 反转不影响 D 用新字段或版本化隔离，避免下游静默出错 ✓ 正确答案
# 27. 你的接口依赖库升级（JSON 库），序列化行为变了，你看怎么 argue A 升级完再说 B 序列化行为不会变 C 升级前做新旧序列化对比测试，配合灰度验证兼容 ✓ 正确答案 D 直接禁升级
# 28. 你的接口分页方式变了（page->cursor），下游不兼容，你看怎么 argue A 直接替换，下游更新 B 只通知大客户 C 一次全切，越快越好 D 新旧接口并存 + 明确迁移窗口，平滑过渡 ✓ 正确答案
# 29. 你的接口字段类型变了（int 变 String），下游报错，你看怎么 argue 兼容 A 让下游改代码 B 先回滚，用兼容窗口或版本化规划后推进 ✓ 正确答案 C 报错是下游的问题 D 直接改完不管
# 30. 你的接口支持新协议（如 HTTP/2），老客户端不支持，你看怎么 argue A 强制所有客户端升级 B 只给新客户端用新协议 C 放弃新协议 D 新旧协议并存 + 自动协商降级，渐进式升级 ✓ 正确答案
# 31. 你的接口时间格式变了（timestamp -> ISO），你看怎么 argue A 直接改，下游适应 B timestamp 和 ISO 一样 C 用兼容窗口或版本化过渡，并统一为 ISO 8601 规范 ✓ 正确答案 D 时间格式无所谓
# 32. 你的接口编码格式变了（UTF-8 -> UTF-16），你看怎么 argue A 编码应保持稳定，UTF-8 兼容性更好，应回滚 UTF-16 变更 ✓ 正确答案 B 没问题，UTF-16 更好 C UTF-16 更省空间 D 编码无所谓
# 33. 你的接口请求 body 字段顺序变了（有些库敏感），你看怎么 argue A 字段顺序无所谓 B 字段顺序非契约，但变更时追加而非重排，识别敏感下游 ✓ 正确答案 C 顺序必须严格固定 D 让敏感库自己改
# 34. 你想让 reviewer 写 review 笔记（分享经验）但没人写，你怎么看怎么推动 A 强制每周写一篇 B 只让 senior 写 C 没人写就放弃 D 用轻量模板降低门槛、自己示范、让笔记产生复用价值 ✓ 正确答案
# 35. 你想做契约测试但 PM 说"不需要"，你怎么看怎么 argue A 确实不需要 B 契约测试太贵 C 契约测试低成本预防接口漂移和高成本返工，从核心接口试点 ✓ 正确答案 D 联调时说清楚就行
# 36. 你想做契约测试但 leader 说"先做单元测试"，你怎么看怎么 argue 优先级 A 对，先放弃契约测试 B 两者互补，分阶段推进：先补单元测试，同时试点关键接口契约测试 ✓ 正确答案 C 契约测试比单元测试重要 D 只做契约测试
# 37. 你的契约测试 mock 服务不稳定，你怎么看怎么推动 mock 治理 A 不管，偶尔失败没关系 B mock 不稳定是常态 C 弃用 mock，全用真实服务 D 治理 mock 与真实契约对齐、稳定性、可定位性，让测试可信 ✓ 正确答案
# 38. 你的契约测试和实际行为不一致（mock 不准），你怎么看怎么 argue A mock 差不多就行 B 手写 mock 更可控 C 用真实样本生成 mock，定期与真实比对校准 ✓ 正确答案 D mock 不准怪下游
# 39. 你的契约测试覆盖率低（只覆盖主路径），你怎么看怎么 argue 补充 A 按风险优先级补全错误码、边界、异常场景的契约 ✓ 正确答案 B 主路径够了 C 覆盖率数字很高就行 D 只测成功路径保证稳定
# 41. 你的接口做了 A/B 测试，部分用户行为不同，你看怎么 argue 契约 A 契约测试只测默认分支 B 契约测试覆盖实验分支，实验变更纳入契约管理 ✓ 正确答案 C A/B 不影响契约 D 实验期间不测契约
# 42. 培养新人评审者时你如何设计“影子评审”（新人先评、老手复核），并给出可衡量的成长反馈？ A 新人先评+老手结构化对比，用准确率/漏报率等指标衡量成长 ✓ 正确答案 B 新人看一遍就完事 C 让新人独立评审，不反馈 D 只让新人看老手评
# 43. 你联调时 mock 服务挂了，你看怎么 argue 快速恢复 A 等 mock 恢复再联调 B 放弃联调 C 让 mock 维护方自己解决 D 快速恢复/切换顶替，根因复盘，并提升 mock 高可用 ✓ 正确答案
# 44. 你联调时发现 mock 数据和真实数据不一致（边界 case 漏了），你怎么看怎么推动 mock 完善 A 用 mock 硬测 B mock 不准就怪数据 C 用真实样本补齐 mock 的边界 case，定期与真实比对 ✓ 正确答案 D 放弃 mock，全用真实
# 45. 你联调时发现 mock 服务数据是假的导致问题，你看怎么推动真实数据 A 假数据够用 B 用脱敏后的真实数据样本替代假数据，让 mock 反映真实形态 ✓ 正确答案 C 继续用假数据 D 让下游提供真实数据
# 46. 你联调时环境里的数据库和测试环境不一致（schema 不同），你怎么看怎么推动 A 用 migration 统一管理 schema，环境自动同步，保证一致 ✓ 正确答案 B 手动改库对齐 C 环境不一致正常 D 只保证生产一致
# 47. 接口契约变更时你如何让“契约测试与实现代码同步更新”，避免契约成为第二份过期文档？ A 契约单独维护，靠人记得更新 B 契约先行 + 同 PR 更新 + CI 强制校验，让契约与实现绑定 ✓ 正确答案 C 契约不用测试 D 实现改完再补契约
