题目重点：针对公开描述的仓库评审实作题，给出逐 PR 复现、问题归类、改进选择、验证与 AI 工具使用边界。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 本文讲评审流程与训练方法，不推测四个 PR 的实际 bug、接口或正确修复。
- 面试允许的 AI 工具和 TypeScript 环境以现场要求为准；工具建议必须由候选人读 diff、跑测试和解释。
- 训练版优先选择能在剩余时间完成且可验证的 PR 改进，权衡风险、影响、测试成本与依赖，不默认代码量最大者最优。
解题路线
- 先快速建立项目基线：README、package scripts、类型检查、测试与目录结构。对每个 PR 记录同一张小表：用户问题/预期行为、改动路径、关键不变量、测试证据、风险和一个具体评论。只靠 PR 标题或 AI 摘要会漏掉实现差异。
- 逐 PR 使用 `git diff` 与调用链定位新逻辑，把问题分为正确性、边界、并发/异步、性能、权限/数据泄漏、维护性；给评论时指向具体输入/代码路径和失败后果，而不是泛泛说‘需要更多测试’。
- 选择一项改进前先跑最小失败用例或记录已有回归测试，再实现小步补丁；如果无法本地复现，也要明确证据不足，选风险较低的可验证问题。修改后运行相关单测、类型检查和必要的集成测试，复看 diff 是否带来无关改动。
- AI 工具可帮索引调用链、生成候选测试、解释陌生 TS 类型；每条结论要回到源码和实际运行结果。若 AI 修改跨文件，先确认为何改动、是否改变 public API，不能把工具输出视为评审意见本身。
- 最后口头总结四 PR 的价值与风险、为何选该 PR、修改前后行为和仍未覆盖的边界；若时间不足，交代已验证与未验证的范围。
手动走一遍
虚构训练例：四个 PR 分别修改 API 输入校验、缓存、日志和 UI。你发现缓存 PR 的 key 漏了 locale，构造两个相同 user id 不同 locale 的测试使旧代码返回错语言；选择它，补完整 key 并跑类型/单测。对其他 PR 仍给有证据的简短意见。这个例子不对应真实四个 PR。
规模与取舍
设四个 PR 的 diff 总量 D、涉及调用链 R、测试耗时 T。初轮扫描至少 O(D)，深挖所选 PR 还需阅读其依赖和运行测试；面试瓶颈通常是理解与验证时间，不是对 diff 行做算法优化。控制 AI 查询与测试次数，优先获取能改变决策的证据。
易错点与追问
容易失分的边界
- 直接让 AI 为四个 PR 写摘要并照读，不知道关键路径和失败条件。
- 只评代码风格，没解释 PR 解决的用户问题或潜在功能回归。
- 选一个大 PR 做广泛重构，来不及交付可运行的改进。
- 工具改完后不跑类型检查/测试、不复核生成的 diff。
- 编造未公开四个 PR 的实际内容。
继续深挖
- 四个 PR 互相依赖时，按什么顺序评审与合并？
- 若某 PR 测试不能运行，怎样用静态证据与最小脚本降低不确定性？
- 怎样记录 AI 工具介入的判断点，使评审仍可审计？
