你的 AI 路线图的瓶颈不是 GPU 容量、模型可用性或 Prompt 工程的品味。它是那一两个真正懂得如何构建能发现回归（regression）的评估（eval）的工程师的日程表。每个负责功能的产品经理都在他们的队列中。每一次模型升级都在他们的队列中。每一次群体漂移、每一次 Prompt 修改、每一个“这个评审模型（judge）是否仍然校准”的问题，最终都会进入同一个收件箱。而这位工程师在本季度已经说了三次“不，这还没准备好”，两次被否决，眼睁睁看着回归在生产环境中复合增长，现在正在更新他们的 LinkedIn。
这就是评估瓶颈，大多数组织在被咬到之前都意识不到它的存在。到 2025 年为止，显而易见的工作重点是 AI 工程师——招聘 AI 工程师、发布 AI 功能、迭代 Prompt、更换模型。到了 2026 年第一季度，吞吐量问题下移了一层。将 AI 团队人数翻倍的团队发现，增加更多功能工程师并没有让功能发布得更快，因为每个功能仍然需要一个评估（eval），而负责评估的工程师还是那个人。
我上个季度合作的一个团队连续拒绝了三名进入 AI 工程师流程的候选人。三个人都挂在了编程筛选环节 —— 就是那种让你在 35 分钟限时内实现一个滑动窗口去重器的题目。团队随后录用了通过该环节的候选人。四个月后，正是这位工程师交付了一项功能，其 eval（评估集）在 CI（持续集成）中得分高达 92%，但上线后的第二天，支持队列就爆满了。那个 eval 衡量的是与精选测试集的精确匹配。而生产环境的用户提问方式完全不同。招聘小组里没有人问过候选人他们会如何捕捉到这一差距。
这就是 Bug 的轮廓。面试流程筛选的是工作中价值最低的技能，却对最重要的技能视而不见。团队没有“判断力”面试轮次。他们只有编程轮、系统设计轮和行为面试轮，运行的还是 2021 年的那套循环 —— 那套为编写针对稳定库的确定性代码的工程师量身定制的流程。
我认识的一个团队花了六个月的时间，在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人，录用了 3 名。但这三个人中，没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题，问题出在面试流程。
标准的工程面试是为这样一套技术栈校准的：正确性可验证，性能可通过基准测试衡量，优秀的工程师是那些能将问题分解为确定性组件，并根据已知规范推导边缘情况的人。那套技术栈依然存在，那些技能依然重要，但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。
这是一个结构性问题，而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”，并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集，这是一个极其微小的群体。这导致了长达六个月的失败招聘，而大家还在纳闷 AI 工程师都去哪儿了。
我今年雇佣的三位最优秀的 AI 工程师，如果让他们互相面试，可能都会被刷掉。那个能写出在模型升级后依然稳健的提示词（prompt）的人，这辈子没写过一个有用的评估（eval）用例。那个能设计出捕捉到关键故障的评估集的人，写的提示词其他工程师根本不想去维护或扩展。那个能设计出既能“故障闭合”（fail closed）又不阻塞正常路径的护栏（guardrail）的人，对另外两个人的看法我在这里不便多说。
职级体系将他们三人都称为“AI 工程师”。定级委员会在对比他们的晋升材料时，仿佛他们做的是同样的工作。其实不然。
信号消失了。在最近对 19,368 场技术面试的审计中，38.5% 的候选人被标记为存在 AI 辅助作弊行为，其中技术岗位的作弊比例高达 48%，初级候选人的作弊率几乎是资深候选人的两倍。更令人堪忧的是：61% 被检测到的作弊者分数超过了及格线。如果没有检测层，他们本可以晋级。面试作为一种评估工具，已经不再能衡量它最初设计要衡量的东西了。
这并不是针对当今年轻人的道德恐慌，而是评估工具的机械性失效。技术面试曾被校准为一个特定的世界：候选人在时间压力下，在陌生的环境中，必须凭记忆和第一性原理编写出正确的代码。这种约束——即让信号清晰可辨的关键——已被在第二台设备上运行的免费聊天窗口瓦解了。每一家仍在进行 LeetCode 式筛选的公司，现在都在花钱对一场考生可以轻易外包的考试进行排名。
大多数招聘 LLM 岗位的工程团队进行的面试大同小异：两轮 LeetCode，一个系统设计问题，可能还有一个关于 Transformer 内部机制的小测验。他们考核的重点不对 —— 而且他们自己也知道。那些在这些筛选中表现优异的候选人往往难以交付实际可用的 AI 功能，而那些在二叉搜索上栽跟头的候选人却能从零开始构建一个评估套件，并在一个下午内调试好一个产生幻觉的流水线。
能预示在 LLM 工程领域取得成功的技能，与传统机器学习或软件面试所测试的内容几乎没有交集。尚未更新招聘流程的招聘经理正在产生大量的漏选（false negatives）—— 拒绝了本可以成功的工程师 —— 而误选者（false positives）则带着扎实的 LeetCode 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。
当今大多数招聘 AI 工程师的团队，都在运行一套为一个根本不存在的岗位所优化的面试流程。他们筛查的是 LeetCode 刷题能力，考察候选人对 Transformer 内部机制的了解程度，并给那些能够自信地在白板上画出分布式系统的人加分。然而，这些候选人加入团队后，却在调试幻觉频发的检索流水线时束手无策，并且交付了一个在测试环境中表现完美、在生产中悄然退化的模型集成。
这不是人才问题，而是测量问题。预示 AI 工程成功的技能在传统面试循环中几乎是不可见的——而面试实际测量到的技能，与工作的真实需求相关性极低。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
