题目重点：让不熟悉产品的面试官也能跟上技术决策与个人贡献。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 使用本人实际经历与可公开数据，团队scope、本人决策及他人贡献分清；没经历过的情况可说明，不能编造成功或失败故事。
- 案例没有通用唯一标准答案。结果指标没有可靠baseline就用可审查的交付/反馈证据，不捏造数值。
解题路线
- 先用一分钟定义用户问题、旧系统限制、项目规模和你负责的边界；系统图标出数据/控制流、owner与关键失败点，不堆内部名词。
- 挑一个可展开机制，讲备选、为什么选、如何验证、什么会失败及如何恢复。项目大不等于技术深，必须能解释接口、数据模型、复杂度/容量或训练评价等实际判断。
- 结果分业务/工程影响和验证限制，讲上线及监测，而非停在架构完成。对数字来源、对照条件和个人因果贡献保留边界。
- 根据面试官理解调整节奏，先讲核心再开放深挖；细节资料备用而非全部塞slides。未知问题可以现场分析并承认，不用术语遮掩。
手动走一遍
可准备：问题/架构/一个深机制/取舍/验证/影响六页，具体页数按时间，不必机械遵守。跨团队项目要能讲一个你亲自负责的难技术点，否则只有协作广度。
规模与取舍
主答2分钟，项目深挖可扩5–10分钟；准备1页系统/责任图与关键取舍，信息密度取决于与问题相关的证据，而非项目数量。
易错点与追问
容易失分的边界
- 讲满所有项目导致最重要机制没时间解释。
- 图里组件很多但无法回答数据一致性/失败恢复。
继续深挖
- 如果规模扩大10倍，哪条假设先失效？
- 重做项目你会改变哪个决策，依据是什么？
