AI Engineer Interview Playbook 包含什么，不适合谁
你花了三周准备那个AI Engineer面试，把transformer架构图背得比论文作者还熟，MoE的负载均衡公式随口就来。面试官让你设计一个RAG系统的检索策略，你从BM25讲到Dense Retrieval再讲到HyDE，滴水不漏。然后你挂了。
反馈邮件写的是“技术深度足够，但缺乏工程判断”。你不是不会，你是不懂这场游戏的规则——面试不是考你懂多少，而是考你在关键时刻能不能替团队做一个没人敢做的技术决策。这就是Playbook要解决的问题，也是它不解决某些问题的原因。
一句话总结
AI Engineer Interview Playbook不是一本面经合集，而是一套工程决策的裁决框架。它的核心功能是让你在面试中表现出“我已经在这套系统上踩过坑并且知道怎么避免你重蹈覆辙”的气场，而不是“我读过很多论文”。
这本书的价值在于帮你理解一个残酷的事实：面试官问“你怎么优化推理延迟”，不是在等你说vLLM的continuous batching，而是想看你有没有能力判断这个延迟到底值不值得优化——因为绝大多数延迟问题根本不是技术问题，是产品需求没对齐。如果你以为背完所有开源模型的benchmark就能过关，这本书会让你很不舒服。
适合谁看
这本Playbook写给那些技术已经过关，但总是在最后一轮被“工程判断不足”挂掉的人。具体画像：你能手写attention，但你解释不了为什么某个场景下宁可用规则引擎也不用BERT；
你能部署Kubernetes集群，但你在被问到“这个pipeline的SLA定多少”时第一反应是去看同类系统而不是去问下游业务的容忍度。如果你还在纠结LangChain和LlamaIndex哪个更好，这本书对你还太早——它不教你选工具，它教你什么时候该扔掉所有工具自己写一个。
不适合的人同样明确。第一种，应届毕业生没有至少两年生产环境经验。书里讨论的很多场景——比如模型版本回滚导致的数据漂移、feature store和online serving的schema不一致造成的静默失败——没有亲自凌晨三点被PagerDuty叫起来的人读不出味道。第二种，想找system design面试模板的人。
这里没有模板，只有决策树。模板告诉你要加缓存，决策树让你先问“缓存命中率跌到多少时这个系统会死”——答案取决于业务是推荐系统还是支付风控，前者可以降级到随机出，后者降级一次就要写事故报告。第三种，只做research不想碰工程的人。这本书假定你已经在生产环境里对model serving、data pipeline、evaluation framework至少一个领域有切肤之痛，否则你会觉得它太“产品导向”——对，它就是产品导向的，因为AI Engineer的价值不是造轮子，是造出能被别人用的轮子。
为什么AI Engineer面试的本质不是考技术
大多数候选人走进面试房间的时候，脑子里装的是一个知识图谱——transformer变体、量化方法、检索算法、分布式训练策略。他们以为面试是一场知识检索比赛。错了。
面试官坐在对面，心里想的是另一件事：这个人下个月oncall的时候，凌晨两点收到latency spike告警，他会先查模型serving的GPU利用率还是先查上游请求的payload size变化。这不是技术问题，这是判断优先级的能力。而判断优先级的能力没法靠背知识点获得。
AI Engineer面试真正在考的东西是工程权衡。一个经典的现场：面试官问，你要上线一个新版的embedding模型，旧模型产出的向量已经在向量数据库里存了三个亿，你怎么做迁移。糟糕的回答是“做一次全量重算，灰度切流”。这个回答技术上完全正确，但工程上会死人——三个亿的向量重算要烧多少GPU小时，算过吗。更好的回答是：先问这个embedding被下游怎么消费的。
如果是top-K检索，新旧模型产出的向量在余弦相似度上的相对排序是否保持一致？如果排序相关性保持0.95以上，直接用新模型做online serving，旧索引不动，观察召回指标。如果是作为特征喂进下游模型的，那就必须做A/B测试，因为新embedding的数值分布变化可能导致下游模型的特征偏移——不是重不重算的问题，是怎么验证重算后不把下游模型搞崩的问题。前者考虑的是成本，后者考虑的是系统性风险。面试官听到第二种回答，心里会做一个判断：这个人能独立负责一个项目，不用我盯。
这就是Playbook反复强调的一点：你不是在展示你知道什么，你是在展示你做过什么判断。判断的对错甚至不是最重要的，重要的是你判断的维度——你是不是在技术可行性和业务连续性之间画了一条清晰的边界。
> 📖 延伸阅读：doordash-pm-behavioral-2026-zh
面试流程拆解：每一轮到底在筛什么
AI Engineer的面试流程通常四到五轮，每家公司的名字不一样，但底层逻辑完全一致。第一轮是技术筛选，通常叫coding或technical screen，但不要被名字骗了。不是让你刷LeetCode。这一轮的实质是看你能不能把一个模糊需求翻译成代码框架。面试官可能会说：“设计一个简单的RAG接口，输入query返回top-3文档。
”普通候选人会直接写一个函数，调OpenAI embedding API，算cosine similarity，返回前三。过关的候选人会先问：query的QPS预估多少，文档库多大，更新频率多少。然后根据答案选择用numpy做in-memory检索还是接Milvus。前者适合1000个文档以内的prototype，后者才扛得住生产流量。第一轮就挂的人，不是因为代码写错了，而是因为他们在不该写代码的时候就开始写代码了。
第二轮是系统设计，这一轮最容易被误判。外面有很多System Design Interview的资料，讲怎么设计YouTube、怎么设计Uber。AI Engineer的系统设计完全不同。它不关心你怎么做sharding，它关心你怎么设计一个模型推理pipeline的容错机制。比如面试官让你设计一个实时翻译服务，模型用Whisper加LLM。糟糕的回答是画一个微服务架构图：API gateway进来，丢到消息队列，worker消费，调模型，返回结果。
这个架构在生产环境里撑不过第一次流量尖峰，因为Whisper的推理延迟在GPU上可能从200毫秒飙到3秒，取决于音频长度，消息队列的backpressure会瞬间打爆。好的回答是从SLA反推架构：如果端到端延迟要求是2秒以内，那么单个音频片段必须控制在15秒以内，超过的直接拒绝而不是排队；LLM的翻译步骤需要做streaming，不能等完整文本出来再返回；Whisper和LLM之间加一个fallback——如果LLM调不通，降级为传统NMT模型。这才是系统设计在AI语境下的正确打开方式。
第三轮是行为面试，很多技术背景的人栽在这里，因为觉得这是“讲故事”。它不是在考讲故事，是在考你在没有完美信息的时候怎么下注。面试官会问：讲一个你推翻了之前技术决策的经历。这个问题的陷阱在于，如果你只是想证明自己“勇于认错”，你会讲一个简单版本——“我用错了工具，后来换了新的，效果变好了”。
这不够。面试官想听到的是你推翻决策时的信息环境：你当时基于什么假设选了A方案，后来什么数据让你意识到假设错了，你做了什么实验验证新假设，以及最关键的一步——你怎么说服当时和你一起做A方案的同事转向B。最后一步最难，因为它涉及的不是技术，是组织行为。你需要在回顾中展现出你知道技术决策同时也是人的决策，不是靠正确性赢得争论，而是靠降低别人的切换成本。
第四轮是hiring manager面，通常是决定性的。HM不关心你懂多少，HM关心的是把你放进团队以后，他需要花多少精力替你擦屁股。这个判断通过一个问题做出：你对你做过的系统的失败模式有多清楚。HM会抓住你简历里的一个项目问：“这个系统如果挂了，第一块倒下的多米诺骨牌是什么。”如果你回答“模型服务挂了”，你没理解问题。
模型服务挂是结果，不是原因。原因可能是特征提取的定时任务跑超时了，连锁导致在线特征存储的读延迟飙升，进而导致模型推理超时，最后整个链路崩掉。能精确说出多米诺骨牌第一块的人，在HM眼里是可以被信任的。因为他不需要别人告诉他出事了，他自己能闻到烟味。
准备清单
把这份清单当成你面试前的自检表，每一项只打勾或打叉，不要给自己打“差不多”。
- 选一个你做过的项目，用三句话讲清楚它的失败模式。不是它怎么成功的，是它怎么失败的。如果能讲出某个周三下午五点四十三分你看到监控面板上一条平直的线突然变成锯齿的那一刻，你就算准备好了。如果只能讲“性能不行了我们优化了”，请重新准备。
- 对简历上的每一个技术选型，准备一个“为什么不用另一个”的回答。你用了FAISS，面试官会问为什么不用ScaNN或者pgvector。不是让你列性能对比表，是让你说出你当时的约束条件——团队有没有人维护C++代码，你的延迟预算有多少毫秒，索引更新的频率是每天还是每分钟。技术选型脱离约束条件就是耍流氓，面试官最擅长抓这种流氓。
- 准备三个“我主动说不”的案例。不是老板让你做你说不，是技术方案上你说“这个优化不值得做”、“这个模型不适合这个场景”、“这个SLA定得没意义”。AI Engineer的价值有一半体现在阻止愚蠢的事情发生，如果你简历上全是“我做了X”，没有“我拒绝做Y”，HM会怀疑你是个执行机器。
- 把RAG、Agent、Fine-tuning这三个词从你的面试词汇里暂时删掉。不是它们不重要，是它们太容易被当成挡箭牌。面试官问“你怎么提高回答准确率”，最差的回答是“我们可以上RAG”。
你要说：先分析当前错误case的分布，是知识缺失还是推理错误还是格式错误。知识缺失才上RAG，推理错误要改prompt结构，格式错误直接上constrained decoding。Playbook里有完整的RAG误用场景复盘，把那一章看完再上战场。
- 模拟一次压力条件下的系统设计。找个朋友当面试官，让他在你画架构图的时候突然加约束：“现在GPU预算砍半”、“下游服务突然限流99%”、“CEO要求今晚必须上线”。看你的架构能不能在这些条件下不散架。散架了就重新设计，直到你的设计里每一个组件都有明确的降级路径。
- 系统性拆解AI Engineer面试的决策框架。市面上大多数资料在教你“怎么回答”，这本PM面试手册里的工程决策模块在教你“怎么在回答之前先判断问题的真正意图”。面试官问“你选哪个模型”，他真正想问的是“你知不知道这个场景下什么指标是北极星”。搞清楚意图，答案会自动浮现。
> 📖 延伸阅读：RivianPM模拟面试真题与参考答案2026
常见错误
第一个错误：把技术深度理解为覆盖广度。
面试官让你设计一个模型评估pipeline，有人从数据切分讲到cross-validation讲到统计显著性检验，面面俱到，像在背教科书目录。这是BAD。GOOD的做法是：先问这个模型上线以后最怕发生什么。如果是推荐模型，最怕的是filter bubble——用户越点越窄，评估pipeline的核心指标就不该是AUC，而是内容多样性的长期趋势。
如果是风控模型，最怕的是漏过高风险交易，那你评估pipeline的核心就是召回率在低概率区间的表现，甚至要做adversarial evaluation——主动构造攻击样本看模型能不能拦住。不是你讲得越多越对，是你抓到最致命的问题才算对。一个只讲了三个指标但每个指标都对应一个生产事故的人，完胜一个列了二十个指标但没有任何优先级的人。
第二个错误：把“我不知道”当成弱点。
面试里被问到完全没接触过的东西，比如“你怎么做LLM输出的结构化保证”，很多人会开始硬编。他们会说用JSON mode，用function calling，用regex parsing。如果面试官追问“JSON mode在流式输出场景下怎么做括号匹配”，他们就炸了。这是BAD。GOOD的回答是：“我没在生产环境里做过流式输出的结构化保证，但我做过非流式的。
非流式场景下我们用constrained decoding限制token空间，流式场景我猜测核心难点是局部最优和全局结构之间的冲突——你可能为了局部括号匹配牺牲了语义质量。如果要我现在给一个方案，我会先做一次离线实验，看在流式和非流式之间结构完整性的差距有多大，如果差距不可接受，就考虑chunk级别的re-ranking加全局约束。”这段话的精髓不是给了什么方案，而是展示了三件事：你知道自己的边界在哪里（诚实），你知道这个问题真正的难点是什么（判断力），你知道下一步该做什么（行动力）。面试官不怕你不知道，怕你不知道自己不知道。
第三个错误：在行为面试里把“我们”挂在嘴边。
“我们做了这个项目，我们提高了20%的性能，我们解决了问题。”面试官耳朵里的过滤器会自动把“我们”翻译成“别人做的，我在旁边看”。这是BAD。GOOD的说法是：“我在这个项目里做了一个有争议的决定——我坚持用online A/B测试而不是离线评估来选最终模型。团队里有人觉得太慢，我拿了之前一个case的数据：离线评估最好的模型上线以后点击率跌了3%，因为我们离线的负样本构造方式和线上真实分布差了1.8个百分点。
这个数据让团队同意多花一周做A/B。最终我们选出来的模型比离线最优的差2个点，但线上表现好5个点。”这段话里充满了“我”。不是抢功，是让面试官能精确地把你从背景噪音里分离出来。他说不清楚你做了什么，你就什么都没有做。
FAQ
Q：我没有AI Engineering的背景，但做过backend engineer，能转吗？
能，但要换一个叙事框架。不要说“我想学AI”，这句话在面试官耳朵里等于“我需要公司花钱让我学习”。要说：“我在backend做了四年，处理过日均五亿请求的分布式系统。我发现AI系统最大的瓶颈往往不在模型本身，而在模型周围的工程基础设施——特征pipeline的延迟、模型版本管理的回滚机制、在线和离线数据的一致性。这些恰好是我过去四年每天都在解决的问题。
我现在想把这些工程能力移植到AI栈上。”这个叙事把“转行者”重新定位为“带资进组的人”，你不是来索取的，你是来输出的。具体案例：一个做API gateway的人转AI Engineer，他面试时讲的是怎么把gateway的限流和熔断机制应用到模型serving的推理调度上——当GPU利用率超过85%时自动降级到轻量模型，而不是让请求排队到超时。HM当场给了strong hire，不是因为他的AI知识，是因为他已经能解决团队当下的痛点。
Q：Playbook里有多少内容是关于最新模型的？
几乎没有。如果你期待看到GPT-4o和Claude 3.5的benchmark对比，你会失望。这本书的假设前提是：模型会变，架构会变，但工程决策的底层逻辑不会变。
你今天纠结用Mixtral还是Llama，三年后你在纠结的东西名字会完全不同，但你判断要不要做模型蒸馏的逻辑是一样的——你依然需要权衡推理成本和精度损失，依然需要做A/B测试验证，依然需要考虑蒸馏后的模型在长尾case上的退化是否可接受。Playbook花了大量篇幅在构建这种不变的判断框架上。它不帮你选模型，它帮你建立选模型时的决策肌肉记忆。
Q：这本书能不能帮我通过Google或OpenAI的面试？
它不会教你Google面试里那道“设计一个YouTube视频推荐系统”的标准题，因为网上已经有上百篇面经讲那道题。它会帮你的是，当面试官在follow-up环节突然问“你的推荐系统在用户第一次打开app时推荐什么”时，你不会直接说“热门内容”——那是cold start的标准答案，也是让Google面试官无聊到想翻白眼的答案。你会先问：这个新用户是从什么渠道来的。如果是付费广告来的，说明获客成本高，首日留存是北极星，推荐策略应该偏向探索性——故意推一些非主流的、有惊喜感的内容，哪怕点击率低，但能让用户觉得这个app“懂我”。
如果是有机增长，首日留存没那么紧迫，可以用保守的popularity策略先积累数据。这个追问本身，就是你读过这本书的证明。不是因为它告诉了你这个追问，是因为你学会了在标准答案面前保持怀疑。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。