题目重点：按 Software Architect 面经明确的 lead project、AI 与 infra architecture 经历追问，准备约束、替代方案、迁移、供应商协作和运维验证。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 本文是简历项目深挖框架，不声称面试官指定某个具体云架构；合成案例只用于说明取舍。
- 供应商沟通只讲真实发生的需求、SLA、接口和风险，不把‘反馈缺乏经验’写成所有候选人必考题。
解题路线
- 选一个本人主导的项目，先写业务目标与非功能要求：吞吐/延迟、可靠性、数据驻留、预算、交付时间和团队技能。说明自己对哪些决定有最终责任。
- 画 2–3 个备选架构及取舍表：自建/托管、同步/异步、集中/分布式、供应商依赖。对每个主要决定给当时测量和失败模式，而非只说‘可扩展’。
- 说明落地：试点、迁移、双写/对账、回滚、CI/CD、权限、监控和 oncall；与供应商或其他团队协作时讲需求澄清、升级路径与合同/SLA 边界。
- 最后用运行中的指标与故障复盘验证架构判断，承认未达成的目标和下一阶段改进。若 AI 项目涉及模型，区分模型效果、推理成本与基础设施稳定性。
手动走一遍
训练模板：一家企业需要把批量推理迁到新 GPU 平台。候选方案为托管服务或自建 K8s；基于成本、显存型号、运维负担和地区合规选试点，记录压测与回滚门槛。所有数字与供应商关系须来自候选人真实项目。
规模与取舍
项目设计没有单一 Big-O；需要给出容量估算、峰值/平均比、故障恢复目标和年度运维成本的可核口径。报告架构时用最关键约束驱动细节，而非堆砌组件。
易错点与追问
容易失分的边界
- 只列云产品名，没有替代方案和为何选择。
- 说主导项目却无法解释个人决策权与团队分工。
- 演示架构图却不谈迁移、监控和故障。
- 把供应商经验写成未经亲历的合同谈判。
- 把面经反馈当成公司所有 Architect 岗位固定评分规则。
继续深挖
- 如果供应商 SLA 未兑现，故障与成本如何转移？
- 预算减半时会牺牲什么能力？
- 哪些指标证明迁移后架构真的更好？
- 为何不用完全自建或完全托管？
