AI 面试毫无区分度：为什么你的流程无法识别能交付 LLM 产品的人才

我认识的一个团队花了六个月的时间，在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人，录用了 3 名。但这三个人中，没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题，问题出在面试流程。

标准的工程面试是为这样一套技术栈校准的：正确性可验证，性能可通过基准测试衡量，优秀的工程师是那些能将问题分解为确定性组件，并根据已知规范推导边缘情况的人。那套技术栈依然存在，那些技能依然重要，但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。

这是一个结构性问题，而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”，并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集，这是一个极其微小的群体。这导致了长达六个月的失败招聘，而大家还在纳闷 AI 工程师都去哪儿了。

你的面试流程未测试的五项技能

有五种能力将能交付 LLM 产品的工程师与不能交付的人区分开来。在标准的编码环节、典型的系统设计环节或针对确定性系统工作的行为面试中，这些能力都无法显现。

对非确定性的适应力。 现代 LLM 即使在温度（Temperature）为 0 的情况下也无法完全复现——浮点运算、GPU 并行计算、混合专家模型（MoE）路由以及批处理级别的依赖性，使得同一输入在不同运行中会产生不同的输出。如果一个工程师坚持要为创意写作界面编写单元测试，并且在被告知正确的测试方法是使用带有校准评判器的留出评估集（held-out eval set）时感到恼火，那么无论他的编码能力有多强，他都不适合。这不是通过指导就能快速弥补的知识差距，而是一种性格特质。一些资深工程师将非确定性视为一种冒犯，并在入职后的前六个月里试图通过规则将其从系统中剔除，而不是围绕它进行设计。

Prompt 调试的直觉。 这种技能表面看起来像 Prompt 工程，但更接近于实验方法：形成一个关于模型为什么执行 X 的假设，设计能证伪该假设的最微小扰动，在固定切分的数据集上进行测量，然后重复。那些说“我只是不断尝试直到成功”的候选人也可以交付产品，但速度很慢，而且他们无法解释为什么评估得分最高的 Prompt 是值得保留的那一个。能够清晰说明为什么要使用 XML 标签而非 Markdown、为什么示例放在指令之前，以及为什么采用某种结构化输出的候选人，其调试速度要快十倍。

评估（Eval）设计。 如果没有冻结的数据切分、校准锚点以及模型更改与评判器更改之间的增量归因，“模型变得更好了”这句话就毫无意义。从未主导过评估集的候选人会将指标视为绝对真理。交付过 Agent 的候选人知道，评估套件是一份契约——存在于定义目标的团队、把控发布的团队以及解释回归问题的团队之间——并且评估集本身也会发生偏移，需要版本控制、校准，以及在评判器模型升级时的应对方案。

成本直觉。 在被要求设计一个功能时，候选人思考的是 Token、扇出（fanout）和缓存命中率，还是仅仅思考 QPS 和延迟？对于 LLM 产品来说，单次任务成本是核心运营变量，其重要性在云时代早期之后从未如此凸显。如果候选人在设计功能时没有提到 Token 预算、Prompt 缓存策略或模型分级路由，那么你不能把盈亏（P&L）责任交给他。而能谈论感知缓存的 Prompt 结构如何将成本降低一个数量级的候选人，则是在向你展示他确实交付过产品。

容错与恢复意识。 经典的系统工作追求“这绝不该发生”。LLM 产品则要求接受系统有时会出错的事实，并设计恢复方案，而不是追求那不存在的 100% 正确率。如果候选人坚持认为正确的设计是将故障率降至零，这表明他会在入职后的第一个季度里为那些更适合通过“撤销”按钮、确认步骤或人工介入机制解决的问题，编写日益复杂的防护栏。

现有的面试环节实际上筛出了什么

回顾标准的资深工程师面试流程，看看每个环节选拔的是什么。

经典的编码环节选拔的是能根据已知规范推导确定性逻辑的工程师——这对 LLM 产品中非模型的部分有用，对模型部分没用。系统设计环节选拔的是能分解处理 Y QPS 后端的工程师——这对 Agent 下层的云基础设施有用，但对 Agent 本身是否奏效没用。行为面试选拔的是沟通清晰度、责任感和判断力——这与领域无关且依然有价值，但无法预测 LLM 交付能力。如果有关卡环节（take-home），通常是确定性算法或带身份认证的 CRUD 应用——这只是把编码环节选拔的东西又测了一遍。

候选人可以完美通过流程中的每一个环节，却从未证明过自己能写 Prompt、设计评估、思考 Token 预算或调试不稳定的 Agent 追踪轨迹。他们被录用后的工作需要这四项能力。面试流程并不是给这些技能打分打得不对，而是根本没有问。

这种“硬塞式” AI 面试轮次的校准失败

当这种差距显现时，本能反应往往是增加一个“AI 面试轮次”——一场关于 Transformer、RAG 或提示词工程（Prompt Engineering）的 45 分钟对话。这非但没有改善招聘流程，反而让它变得更糟。

如果在没有取消或重新调整其他环节权重的情况下直接增加 AI 轮次，就会将招聘门槛提高到所有环节的并集。为了通过面试，候选人现在既需要精通传统系统（Classical Systems），又需要熟练掌握大语言模型（LLM）。在 2026 年，这种交集的人群规模很小，且在未来一段时间内仍将保持如此，因为那些曾大规模交付过 LLM 产品的人，过去两年都在忙于此道——而不是在刷 LeetCode 或温习分布式系统的琐碎知识点。你的流程现在是在筛选“独角兽”，而实际工作需要的是在具备足够传统基础的前提下，能够掌握 LLM 技能簇的工程师。

这种“硬塞式” AI 轮次的第二种失败模式是，它往往倾向于考察琐碎知识点，而非实战技能。反向传播推导和注意力机制（Attention Heads）背后的数学原理虽然能在白板上写得干净漂亮，但几乎无法体现交付能力（Shipping Signal）——最擅长表现这些内容的候选人，通常是那些生产环境经验最少的人。一个能从零开始推导多头注意力机制，却从未在 Token 预算限制下部署过功能的候选人，恰恰是你团队目前工作的错误人选。

真正能体现技能的流程重构

有效的面试流程重构包含四个部分，它要求取消或压缩现有的环节，而不是盲目叠加。

一个端到端交付小型 LLM 功能的课后作业（Take-home）或结对编程环节。 交付成果是一个可以运行的功能，包含候选人设计的评估集（Eval Set）、校准锚点（Calibration Anchor）以及一份书面的权衡说明文档。你的评分标准是：评估集是否合理、提示词是否有理有据（而非像念咒语一样盲目尝试）、候选人是否估算了功能的 Token 成本。一个由你提供 API Key 的两小时结对编程环节，比课后作业能更快地体现这些能力，并避免了多日作业给有家庭或工作的候选人带来的不对称负担。

一个系统设计环节，其题目应为“设计一个在 Y QPS 下每用户每月成本低于 X 美元的功能”，而不是“设计一个处理 Y QPS 的后端”。 成本框架迫使候选人去考虑 Token、扇出（Fanout）、模型层级路由、缓存命中率，以及哪些调用应该同步执行，哪些应该异步处理。优秀的候选人会发现约束条件在延迟目标下无法满足，并提出路由层或小模型降级方案。平庸的候选人则只会设计后端，并将 LLM 视为一个免费的黑盒。

一个调试环节，向候选人提供一个不稳定的智能体追踪记录（Flaky Agent Trace）——即一个真实或模拟的转录文本，其中智能体采取了错误的行动、陷入死循环或产生了格式错误的结构化输出——并要求他们对模型、提示词、工具定义和框架进行故障排查，找出根本原因。这一环节的作用与传统系统中的“根据堆栈日志找 Bug”相同，它能体现同类技能：根据你见过的失败模式进行模式匹配。从未见过不稳定追踪记录的候选人会胡乱猜测。而真正交付过智能体的候选人会在两分钟内缩小搜索范围。

关于应对非确定性（Non-determinism）的深入对话，旨在筛选出那些具有“无法进行单元测试就不发布”这种条件反射的人，同时保留健康的质疑精神。正确的提问方式不是“你能接受模型犯错吗”——所有候选人都会说可以——而是“请讲讲你交付过的一个失败模式是概率性的功能，以及你是如何定义‘可接受’标准的”。答案要么包含评估集、校准锚点和恢复设计，要么就没有。

比招聘效果更好的“横向移动”

已经交付过 LLM 产品的工程师招聘市场异常紧张、昂贵且竞争激烈。一个始终效果更好、但大多数公司因为无法体现在招聘仪表盘上而忽略的做法是：内部轮岗。

一个拥有 5 年以上交付经验的优秀系统工程师，在一位已经交付过智能体的导师指导下进行为期 90 天的 LLM 轮岗，就能将现有的严谨性映射到新的形态上——这比大多数外部招聘更快，且获客成本极低。当工程师具备底层的判断力时，LLM 产品所需的技能簇是可以学会的；在 90 天的时间内学不会的是底层判断力本身。轮岗的高级工程师已经具备了判断力，而初级的 LLM 新员工往往不具备。

团队在轮岗上犯的错误是将其视为“信息观光”，而不是“学徒制”。工程师需要交付一个功能、负责一个评估、处理智能体故障的报警，并编写事后分析（Postmortem）。没有这些，轮岗产出的只是“游客”，而不是“建设者”。有了这些，大约一个季度就能培养出一名建设者，其在留存率和士气方面的优势是外部招聘路径无法比拟的。

架构层面的实现

解决这个问题的公司并不是通过寻找更多的“独角兽”来完成的。他们解决问题的方式是承认 AI 招聘是一个流程重构问题，而不是人才供给问题，并且像对待任何其他生产系统一样对待招聘流程：对其进行埋点监测、持续迭代，并设定明确的信噪比目标。他们淘汰了那些不再能预测绩效的面试环节。他们增加了能发掘岗位实际所需技能集群的环节。他们根据已经成功交付产品的工程师来校准门槛，而不是根据一个并不存在的理想化画像。

大多数公司仍在使用 2018 年的流程来应对 2026 年的工作，并得出 2026 年的工程师不存在的结论。工程师是存在的。只是流程看不见他们。解决办法不是再增加一个生搬硬套的环节，而是去做更难的工作：去探究交付 LLM 产品究竟需要什么，并重建流程来精准地考察这些问题。