AI 招聘评分标准的问题：为什么你的面试流程选错了工程师

当今大多数招聘 AI 工程师的团队，都在运行一套为一个根本不存在的岗位所优化的面试流程。他们筛查的是 LeetCode 刷题能力，考察候选人对 Transformer 内部机制的了解程度，并给那些能够自信地在白板上画出分布式系统的人加分。然而，这些候选人加入团队后，却在调试幻觉频发的检索流水线时束手无策，并且交付了一个在测试环境中表现完美、在生产中悄然退化的模型集成。

这不是人才问题，而是测量问题。预示 AI 工程成功的技能在传统面试循环中几乎是不可见的——而面试实际测量到的技能，与工作的真实需求相关性极低。

传统面试实际在测什么

经典的软件工程面试诞生于确定性系统时代。写一个函数，运行两遍，得到相同的输出。这套评估模型是有道理的：衡量算法推理能力、数据结构知识和系统设计直觉。这些方面都强，大概率也能胜任工作。

但这套模型在 AI 工程领域失效了，而且失效是根本性的，而非表面性的。

一个候选人在时间压力下能够解出图遍历题，展示的是工作记忆能力、对已知模式的回忆能力，以及在压力下的表现。这些技能并不能直接转化为诊断语言模型在语义相同的提示下返回不一致输出的能力——后者需要完全不同的思维模型。

系统设计面试也是同理。设计一个短链接服务或叫车调度系统，训练候选人在确定性服务的吞吐量、一致性和故障模式上进行推理。虽是有用的基础，但对于推理推理延迟预算、提示注入面、上下文窗口管理，或规模化下的检索质量退化而言，这还远远不够。

当 71% 的工程领导者表示 AI 正在让现有方法更难评估技术技能时，他们观察到的不是边际变化。他们注意到的是：自己的测量工具已经不再适配实际工作。

真正预示 AI 工程表现的技能

2026 年的 AI 工程师岗位，与面试所设计要筛选的岗位毫无相似之处。看看这份工作的日常内容：

调试非确定性故障。 当一个由 LLM 驱动的功能出现问题时，故障模式很少是堆栈追踪或可复现的崩溃。它是一种分布偏移——上周还有 94% 可接受率的响应，本周只有 79% 了，而你不知道原因。诊断这个问题需要读取追踪日志、构建有针对性的评测数据集、隔离是哪次提示变更或检索更新引入了退化，以及对概率分布而非边界情况进行推理。这种技能在面试中几乎从不被考察。

从模糊需求中设计评测。 产品经理不会像传统功能那样为 AI 功能写"验收标准"。他们说的是"让它听起来更自然"或"这里应该更有帮助"。AI 工程师的工作是把这些话翻译成可测试的东西——一个带标注的数据集、一套 LLM 评判员能够一致执行的评分标准、一个能随 PM 所关注的东西一起变动的指标。能做到这一点的工程师极其稀缺且极有价值。做不到这一点的工程师，将永远只是在发布感觉上还不错的东西。

在概率输出之上构建反馈闭环。 确定性软件要么有效，要么无效。AI 系统在置信区间内运作，而这个区间会随着使用模式变化、数据分布漂移和底层模型更新而改变。改进最快的工程师，是那些构建了系统性流水线以从生产中收集信号、将故障路由到正确的标注桶中、以及将真实世界结果与训练数据之间的闭环打通的人。这更接近于科学思维而非工程思维，而大多数面试循环不会将其浮现出来。

生产级提示工程。 在 Jupyter Notebook 中有效的提示，与在生产中稳定有效的提示之间，存在巨大的鸿沟。生产提示需要版本管理、回归测试、分阶段发布和回退逻辑。它们需要处理对抗性输入、用户行为的长尾分布，以及不适合放入 128k 上下文窗口的内容。理解这一点的候选人——把提示当作代码而非指令来对待的人——是可以与其他人区分开来的，但前提是你要问出正确的问题。

团队为何一直沿用错误的方式

错误面试流程的持续存在并非不理性，而是路径依赖的结果。

工程招聘是一个高风险的协调问题。面试流程被标准化是因为一致性很有价值——你希望流水线中的所有候选人都按照同一标准被评估，这样才能跨候选人池进行比较。一旦流程标准化，改变它的成本就很高——你需要重新培训面试官、重新设计评分标准，并在过渡期内接受信号减弱。

更深层的问题是，制定招聘标准的人往往是优秀的传统工程师，他们在确定性的世界中建立了自己的思维模型。他们真心不知道良好的 AI 工程判断力是什么样子，因为他们从未见过它被示范。他们默认信任自己擅长的技能，而那些恰好就是他们拥有的技能。

还有一种声望偏见，在两个方向上扭曲了信号。来自知名 AI 实验室的候选人会通过他们本不应通过的筛选，而来自知名度较低机构的优秀 AI 工程师，则因简历模式不符合模板而被过滤掉。一项对失败 AI 招聘的分析发现，32% 的失败来自于拥有亮眼资质但技能与实际工作不匹配的候选人——凭资历录用，而非凭能力。

能发现真实 AI 工程能力的评估模式

目标不是彻底抛弃技术评估，而是将其重新导向真正重要的技能。

给候选人一个有问题的评测，让他们修复它。 提供一个带标注示例的小型评测数据集、一个提示，以及显示模型表现不佳的结果。要求候选人诊断问题所在，并提出两种修复方案。这考察的正是区分能改善系统的 AI 工程师与仅能描述系统工作原理的人之间的判断力循环。

询问他们构建的系统中的一次生产故障。 不是"告诉我你面临的一个挑战"，而是具体地问："请描述一次模型集成在测试中有效但在生产中失败的经历。什么东西坏了，你如何发现的，你做了什么改变？"真正交付过生产 AI 系统的工程师会有清晰的回答。只构建过 Demo 的工程师则会在具体细节上语焉不详。

提出一个模糊的产品需求，要求给出可证伪的成功标准。 "搜索结果应该感觉更相关。"坐下来观察。优秀的候选人会立刻追问——相关是对谁而言，如何衡量，在什么查询分布上？他们会提出数据集、标注方法论、指标。弱候选人会建议在提示中添加更多上下文，然后宣告完成。

允许使用 AI 工具进行实时调试。 让候选人对一个看起来逼真的损坏 RAG 流水线或行为异常的 Agent 进行诊断性会话。让他们自由使用 AI 编程工具。观察他们如何形成假设、选择对什么进行检测、如何解读模糊的证据，以及何时决定已经找到了根本原因。这揭示的判断力是任何编程题都无法展现的。

围绕你们的真实问题设计面试。 最好的 AI 工程系统设计题不是关于设计 Twitter 的。它们是关于你的团队实际面临过的架构选择：如何处理多步 Agent 的可靠性，如何构建在到达用户之前能捕获回归的评测框架，如何设计一个流水线使其可以迭代而不破坏下游消费者。真正思考过这些问题的候选人会立刻认出它们。没有思考过的人则会敷衍了事。

搞错了的复合代价

将错误的工程师招入 AI 岗位，其复合效应远超将错误工程师招入传统岗位。

一个略有偏差的传统软件工程师仍然可以写出正确的代码。输出是可审计的，故障模式可追溯，他们的工作可以在到达用户之前被审查和纠正。一个缺乏评测设计技能的 AI 工程师，发布的功能看起来可以正常工作——没有错误日志，没有崩溃，只是用户体验在悄然退化，而没有人能够衡量，也没有人能够在不从头重建反馈基础设施的情况下修复。

在错误轴上优化面试信号的团队，积累的是代码中看不见的技术债。它体现在文化中：一种发布令人印象深刻的 Demo、庆祝基准测试提升、却默默回避"这东西对用户来说真的更好了吗"这个问题的文化。

纠正的方法是现成的。预示 AI 工程成功的技能是可教的、可评估的，在精心设计的面试中是可区分的。问题在于，你的招聘流程是否被设计用来发现它们——还是被设计用来发现别的什么。