题目重点：推广需要接口、迁移和支持，不只是宣布一个新平台。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 使用本人实际经历与可公开数据，团队scope、本人决策及他人贡献分清；没经历过的情况可说明，不能编造成功或失败故事。
- 案例没有通用唯一标准答案。结果指标没有可靠baseline就用可审查的交付/反馈证据，不捏造数值。
解题路线
- 先识别局部痛点和它是否重复出现，数据/访谈证明适用范围；局部优化不一定适合全公司。
- generalize时区分共性和团队特例，接口提供可明确支持的行为，避免抽象过早变成巨大万能平台。给试点团队共同设计反馈。
- 推广含迁移计划、兼容/回退、文档、owner与支持预算；别团队有自己的deadline和系统约束，不因你的指标好就必须采用。
- 结果看真实采用、用户成本和重复工作减少，而不是发布announcement数量。若部分团队不合适，允许保留原方案，复盘平台维护成本。
手动走一遍
两个团队同样重试事件处理，可抽幂等/日志核心，但不同业务状态仍由各团队owner，不把全业务塞公共库。迁移成功要核对错误率、回滚与支持负担；仅PR合并不等于用户已采用。
规模与取舍
主答2分钟，项目深挖可扩5–10分钟；准备1页系统/责任图与关键取舍，信息密度取决于与问题相关的证据，而非项目数量。
易错点与追问
容易失分的边界
- 一个项目成功后直接要求全公司迁移。
- 推广没有后续owner，支持成本转嫁采用团队。
继续深挖
- 怎样判断共性足够值得平台化？
- 没有汇报关系的团队拒绝迁移时如何评估？
