AI 工程师面试系统性失灵：停止考实现，开始考评测设计

我上个季度合作的一个团队连续拒绝了三名进入 AI 工程师流程的候选人。三个人都挂在了编程筛选环节 —— 就是那种让你在 35 分钟限时内实现一个滑动窗口去重器的题目。团队随后录用了通过该环节的候选人。四个月后，正是这位工程师交付了一项功能，其 eval（评估集）在 CI（持续集成）中得分高达 92%，但上线后的第二天，支持队列就爆满了。那个 eval 衡量的是与精选测试集的精确匹配。而生产环境的用户提问方式完全不同。招聘小组里没有人问过候选人他们会如何捕捉到这一差距。

这就是 Bug 的轮廓。面试流程筛选的是工作中价值最低的技能，却对最重要的技能视而不见。团队没有“判断力”面试轮次。他们只有编程轮、系统设计轮和行为面试轮，运行的还是 2021 年的那套循环 —— 那套为编写针对稳定库的确定性代码的工程师量身定制的流程。

2026 年 AI 工程师的日常工作与此几乎毫无共同点。工作由每周面对的十几次判断决定，而面试从未考察过这些：什么时候微调（fine-tuning）是错误答案？如何编写一个不会被刷分的 eval？什么时候你对模型的输出足够信任，可以跳过人机协作（human-in-the-loop）？什么时候你该告诉利益相关者“我们不应该发布这个功能”？实现是成本最低的部分。在指标显示正确时，意识到系统其实是错误的 —— 这才是瓶颈。

面试针对的是错误的 Bug 分布

传统的软件面试考察两种技能：你是否能在严格限制下生成正确的代码，以及你是否能对大规模系统进行推理。两者依然有价值，但都不充分。AI 工程师产生的 Bug 聚集方式，与面试筛选的 Bug 完全不同。

确定性工程师的 Bug 源于心理模型的不完整 —— 差一错误（off-by-one errors）、遗漏的边缘情况、竞态条件。LeetCode 风格的筛选是这种技能的一个虽然伴随噪声但真实的代理指标，而系统设计轮则捕捉了架构层面的版本。AI 工程师产生的 Bug 则源于随机系统的不匹配 —— 一个在 eval 集上表现良好但在分布偏移（distribution shift）时失败的提示词（prompt），一个模型自信且错误地调用的工具，一个没人注意到的成本回归（因为请求数看起来正常，但 Token 数却翻了三倍）。

你无法通过测试第一类技能来筛选第二类技能。这些技能的重叠程度远低于面试流程所假设的水平。能在 35 分钟内解决滑动窗口去重问题的候选人，与能看着绿色的 CI eval 并问道“这是否衡量了用户实际遇到的失败模式？”的候选人之间并没有相关性。

一个评测设计轮次到底是什么样的

增加一个评测设计（eval-design）轮次是杠杆率最高的操作 —— 窍门在于候选人应该在编写提示词之前设计 eval。大多数面试形式将此颠倒了。他们给候选人一个提示词工程（prompt-engineering）练习，并要求“让它表现得更好”。结果变成了一场合理化竞赛：候选人针对三四个示例组成的肉眼样本迭代提示词，而你完全无法了解他们会如何捕捉其余 99% 样本中的失败模式。

把它反过来。给候选人一个功能说明书（feature spec）——“构建客户支持分流系统，决定工单进入哪个队列，并包含置信度分数” —— 让他们在前 40 分钟只做两件事：编写 eval，并为其辩护。先不要让他们碰提示词。你评分的对象是评测设计。具体来说：

• 他们是否识别出了说明书中未提及的失败模式？ 一位优秀的候选人会指出说明书中未提及的长尾风险 —— 对抗性输入、多语言查询、应转入人工审核的歧义工单、错误路由成本不对称的情况。
• 他们制定的评估准则（rubric）是否足够精确，以至于两名评分者能达成一致？ Eval 的好坏取决于其准则的标注者间一致性（inter-annotator agreement）。观察他们是说“输出应该是友好的”，还是说“输出应该从这七个列表中指明正确的队列，且在两个队列之间模棱两可的输出被评为未命中”。
• 他们是否考虑了 eval 必须覆盖哪些数据切片？ 运行一次的静态金标准集（gold set）是 2023 年的过时产物。候选人应该考虑群体采样（cohort sampling）—— eval 衡量的是实时分布，还是六个月前才新鲜的精选集？如果是后者，刷新频率是多少？
• 他们是否针对一个小型的人工标注集验证了评判模型（judge）？ 如果 eval 使用 LLM 作为评判者（LLM judge），候选人应该知道在允许评判者把控发布准入之前，必须衡量其与人工标签的一致性。从业者通常在扩大规模前追求 75–90% 的一致性。

直接跳到“我会写提示词让模型输出 JSON”而完全不考虑这些细节的候选人，刚刚告诉你他们无法察觉自己的系统何时出错。这是你能招到的最昂贵的人。

权衡面试取代系统设计环节

目前形式的系统设计面试已成为一种陈旧的遗留环节。候选人在白板上画方框，讲解 QPS 和分片（sharding），面试官则根据他们是否记得提到 CDN 来打分。这些都无法反映 AI 工程师每周需要做的权衡。

替代方案是权衡面试（trade-off interview）——向候选人展示两个维度之间的真实冲突，并观察他们如何进行推理。例如：

• 质量与成本。高级模型在你的评估中高出 3 分，但推理成本是原来的 6 倍。PM 想要发布高级版。在做决定之前你会问什么？能拍板的最简单实验是什么？
• 延迟与能力。在智能体（agent）循环中增加第二次工具调用可以修复 40% 的失败，但会给中值响应增加 800 毫秒的延迟。产品形式是语音对话。请向我阐述你的决策过程。
• 覆盖范围与漂移。你有一个公平性审计，在模型固定为 v3 版本时通过了。迁移到 v4 可以解锁路线图上的三个项目，但会使审计失效。你该怎么办？

你寻找的信号不是“正确答案”——因为根本没有标准答案。你寻找的是候选人是否将权衡分解为可衡量的维度，能否指明可以消除不确定性的实验，以及是否能发现那些让简单答案变得错误的二阶效应。优秀的候选人在从面试官那里提取出约束条件之前会拒绝给出答案。平庸的候选人则会草率选择一个维度并使其合理化。

调试回放环节捕捉“品味”信号

调试回放（Debugging-replay）是一个让候选人分析真实生产环境追踪（trace）的环节——包括用户查询、中间推理过程、工具调用、模型输出以及用户的最终反应——并要求其推断哪里出了问题，以及什么手段可以更早发现它。这更像代码审查（code review）而非编程环节，它探测的是面试形式极少测试的一种特定技能：候选人能否在指标显示正常时，通过观察输出识别出它是糟糕的。

追踪记录是发生过的一切的完整记录，而从追踪记录中推断随机性失败是任何入行超过六个月的 AI 工程师的日常工作。选择一个失败表现微妙的追踪记录：例如模型给出了一个极具误导性的错误答案，但在自动化准则中得分很高；或者一个工具调用成功了，但相对于用户的真实意图来说是错误的工具。观察候选人是否：

• 针对根本原因形成假设，并提出成本最低的实验来证伪
• 能区分“模型产生困惑”（提示词或模型问题）与“系统给出了错误的上下文”（架构问题）
• 注意到现有评估无法捕捉的失败模式，并提出能够标记该模式的评估扩展方案

这是你发现候选人是否有“品味”（taste）的环节。品味不是一种虚无的感觉，它是对“什么是好的”积累的判断力，是在成千上万次追踪分析中磨练出来的。你无法在 45 分钟的环节中合成这种能力，但你可以在大约十分钟的真实推理中检测到它的存在或缺失。

该舍弃什么，以及为什么舍弃比增加环节更难

评估设计、权衡和调试回放环节是增量性的——它们增加了三个新信号。更难的组织变革是舍弃那些不再起作用的环节。具体来说：Leetcode 筛选和系统设计环节中的算法部分。

这很难，因为 Leetcode 筛选是运行成本最低的环节。它易于规模化，具有可辩护性，候选人也对此有心理预期。系统设计环节因为同样的原因而具有惯性。砍掉它们感觉像是在降低标准。其实不然——这是在移除一个只会筛选出错误技能的嘈杂过滤器，同时还在对你真正想要的候选人征收“人才税”。

过渡期间可以考虑两种模式：

• 将 Leetcode 筛选替换为带回家的评估设计练习。候选人拿到一份功能规格书和四小时时间。他们提交一份评估设计（不需要实现）。你根据实战环节的相同维度对其进行评分。分不清评估好坏的候选人会自动被筛选掉。
• 将系统设计环节替换为权衡与架构的混合环节。保留架构设计的核心——并发、数据流、失败模式——但将其锚定在一个真实的 AI 相关系统上，而不是通用的“设计 Twitter”题目。候选人在同样的技能维度上进行推理，但载体是与实际工作相匹配的。

抵制这种转变的团队，通常也是那些雇佣了擅长编程筛选的候选人，然后在六个月后抱怨工程师无法辨别模型何时出错的团队。招聘漏斗是直接原因，而招聘准则是根本原因。

瓶颈在于判断力，面试应该衡量它

这一切背后的结构性转变在于，实现吞吐量（implementation throughput）不再是 AI 团队的约束瓶颈。代码生成是廉价的，提示词迭代是廉价的。瓶颈在于工程师正确判断系统是否正常工作的速度——评估是否测量了正确的指标，追踪记录显示的是真实失败还是刻意筛选的结果，以及团队所做的权衡是否符合预期。这种技能是团队速度的限制因素。它也是目前面试流程最缺乏衡量能力的技能。

如果你在下个季度只对面试流程做一项改动，请增加评估设计环节，并将其放在任何编程环节之前。在这个环节表现出色的候选人在工作中也会表现出色。而在 Leetcode 筛选中表现出色、在评估设计环节表现糟糕的候选人，正是那些会发布在 CI 中得分 92% 却让客服单量暴涨的功能的人。

面试是修复这种差距成本最低的地方。而成本最高的地方是在六个月后的生产环境追踪中，那时必须有人向利益相关者解释，为什么系统出错时评估结果却是绿色的。