当候选人使用智能体时，编程面试衡量的是什么

问题拆解。 在编写任何代码之前，候选人能否将一个模糊、定义不明确的任务分解为一系列可处理的片段？这是给智能体的输入，完全是人类的工作。模糊的提示词产生模糊的代码；清晰拆解的问题产出你真正可以审查的代码。拆解现在处于所有环节的上游，这使其成为最有观察价值的事情。

审查并拒绝智能体的输出。 几家公司完全颠倒了面试过程：他们不再要求候选人生成代码，而是移交一个中型代码库和一份草拟的 PR（Pull Request）——表面上是来自同事——并要求候选人进行审查和改进。这种设定坦诚地反映了工作的转移。一个团队使用的口号很直白：生成是廉价的，验证是昂贵的。观察一个候选人阅读他们没写过的代码，找出测试遗漏的失败模式，并说明其错误原因，这比观察他们打字更具有预测性。

识别智能体何时在“自信地犯错”。 这是一个名字最短但影响最深远的技能。智能体生成的代码可能可以编译、通过可见的测试、阅读起来很简洁——但在涉及到大规模、并发或没人想到要测试的输入时是错误的。能捕捉到这一点的工程师才是值得聘用的工程师。面试应该刻意植入一个看似合理但有缺陷的方案，观察候选人是察觉到了，还是因为其看起来很“自信”就随手放行。

对架构和范畴的品味。 当一名工程师可以在一个下午生成整个技术栈的代码时，约束条件就不再是产出，而是判断：构建什么，不构建什么，做出哪种权衡，何时停止。这些新面试的评审员会根据候选人是否在解决问题前重述问题、提出澄清性问题以及大声讨论权衡进行评分。一位招聘主管说，优秀的雇员“不会立即提出解决方案”。停顿就是信号。

注意这四点的共同之处：智能体无法为候选人提供其中的任何一项。智能体可以写代码，但它不能判定代码是错误的，不能选择范畴，不能承担判断。围绕这些信号设计面试，可以让智能体的存在对衡量结果变得无关紧要——这正是重点所在。你不再与工具对抗，而是开始衡量工具无法完成的事情。

围绕判断力而非打字速度重新设计招聘环节​

具体而言，在 2026 年能产生有效信号的面试，看起来不再像一个空白编辑器，而更像是一场带计时器的 code review。目前正在试点的审计式面试分为三个阶段：简短的定向阶段，候选人在提出任何方案前先确定约束条件；较长的审计阶段，他们在已经运行的代码中搜寻生产环境的故障；以及辩论阶段，他们必须选出首个要发布的修复方案并说明理由。

每个阶段评分的对象都是判断力，而非机械操作。定向阶段奖励那些在优化任何东西之前先询问系统规模的候选人。审计阶段奖励发现 race condition 的人，而不是重新格式化文件的人。辩论阶段奖励优先级排序能力——即意识到你无法修复所有问题，并能解释选择修复特定问题的成本效益逻辑。Agent 是被允许甚至鼓励使用的，因为这些评分都不取决于谁输入了代码，而是取决于谁的判断力在掌舵。

这样做是有实际成本的。审计式面试更难编写——你需要一个真实的、带有真实的非显性缺陷的代码库——而且更难评分，因为判断力无法被简化为一组通过的测试用例。这对面试官提出了更高要求，他们现在必须评估推理过程，而不是对比参考答案看 diff。这一成本正是大多数公司尚未转型的原因：LeetCode 式面试最大的优点在于管理成本低廉，且看起来很客观。重构招聘环节，是用这种廉价感来换取你真正可以信任的信号。

代理指标终于与目标背道而驰​

“你会写代码吗”一直是一个代理指标（proxy）。雇主真正想知道的是“你能交付正确的系统吗”，几十年来，独立编程能力与此高度相关，以至于代理指标几乎等同于目标。面试流程是建立在两者将保持一致的假设之上的。

它们已经分道扬镳了。现在，交付正确的系统意味着能很好地拆解问题、指挥 agent、发现它自信犯下的错误，并掌控架构——而一个候选人可以擅长所有这些，但在凭记忆写二分查找时表现平平。反之亦然：有人可以在白板面试中表现出色，却仍然交付糟糕的系统，因为他们对 agent 提供的一切照单全收。代理指标和目标现在是两个不同的维度，任何仍在针对代理指标进行优化的面试都是在错误的方向上努力。

对招聘团队来说，令人不安的是面试流程落后于实际工作数年之久。形式的重新设计需要数月时间，面试官的重新培训需要更久，而“我们一直是这样筛选的”这种制度惯性非常顽固。与此同时，面试衡量的标准与工作实际要求之间的差距每月都在扩大。一个在 2026 年仍然运行未经修改的 2022 年面试流程的团队，算不上严谨。它是在仔细衡量一项已无法预测其招聘初衷的技能——并在坚信自己正确的同时，悄无声息地筛选掉合适的人才。

解决办法不是做一个更好的防作弊检测器。而是接受候选人拥有 agent、员工也将拥有 agent 的事实，而唯一诚实的面试是衡量在 agent 已经在场的情况下，人类能带来什么。