当候选人说“我会直接用提示词解决”时，面试官之间出现的 40 分分歧

候选人在系统设计题上卡住了，停顿了两秒说：“我直接写个提示词（Prompt）就行。”你资历最深的面试官写下：强烈推荐录用——这正是 2026 年优秀工程师的工作方式。你资历第二深的面试官写下：不予录用——把问题丢给聊天机器人不叫工程。同样的五个字，同样的 40 分钟面试，同一张评分表上出现了 40 分的巨大差距。

候选人并没有搞砸你的面试环（Interview Loop），是你的面试环缺乏明确的观点。复盘会中最糟糕的部分不是分歧，而是每个面试官都如此确信自己的判断是正确的，以至于会议演变成了对 AI 本身的立场投票，而不是讨论这个人是否具备交付能力。

这不是候选人质量的问题，而是披着质量外壳的评分标准完整性问题。如果不进行对齐（Calibration），你的招聘标准就会随每周面试官的组合而波动，而不是取决于岗位真正的需求。

你从 2022 年照搬的评分标准，正在评判一个已不复存在的岗位

你正在运行的面试环几乎肯定建立在一种“工程能力”的定义之上，而这种定义早于你团队现在的日常工作模式。面试环检查候选人是否能从零开始实现一个小算法、分析时间复杂度、并在白板上讲解系统设计。这些检查本身没有错，只是它们对于公司 AI 工程师周二早上要做的事情来说，已经不再是核心支撑了。

周二早上的现实更接近于：阅读一段团队中没人写过的 4,000 行模块，判断 LLM 生成的首个修改草案哪里错了，驳回那些隐蔽的错误部分，接受那些微妙的正确部分，并且无论是否由模型编写，都要对结果负责。2022 年的评分标准考核的是 2026 年岗位很少使用的“从零实现”的能力，而对 2026 年岗位经常使用的“评审和编辑 AI 输出”的能力则完全没有给分。

因此，当候选人在没有展示底层推理的情况下直接跳到“我直接写个提示词就行”时，你的面试环没有一套公认的方法来区分两种截然不同的信号：一种是资深工程师，他们准确地识别出这是一个模型可以处理得很好的已解决问题；另一种是初级工程师，他们借此掩盖自己完全无法对问题进行推理的事实。两人给出的都是同样的五个字。但只有其中一个是你想雇佣的候选人。

分歧是数据，而不是噪音

在复盘会上看到 40 分的分歧时，标准的反应是更激烈地争辩、取平均分、或者听从资历最深的人。这三种反应都是错误的。这种分歧是你的面试环本周产生的最有价值的产物，将其视为计票问题而非信号提取问题，会导致招聘标准在没人察觉的情况下悄悄偏移多年。

“评分者间信度”（Inter-rater reliability，简称 IRR）是这个问题的枯燥统计学名称。当结构化面试研究报告称，在经过对齐工作后，评分者间信度从 0.37 左右上升到 0.67 左右时，它真正的意思是：在对齐之前，你的面试官达成一致的概率仅比随机撞大运高一点点；而在对齐之后，他们的一致性足以让面试小组的决定具有意义。在“我直接写个提示词就行”上出现的 40 分差距，是 IRR 低于 0.4 的明显特征。

解决方法不是增加更多面试官，不是制定更详细的评分标准，也不是延长复盘时间。而是一个对齐会议，让面试小组坐下来针对同一个录制的候选人回答，并挖掘出评分差异背后的原因。不是“我觉得应该强烈推荐录用”对比“我觉得不予录用”，而是“我给出强烈推荐录用，是因为驳回 AI 输出需要与从零开始编写同样的判断力，而候选人在追问中展示了这种判断力”对比“我给出不予录用，是因为候选人没有解释他们会写什么提示词或如何验证它，我无法仅凭这个回答判断其是否具备这种判断力”。这是两个不同的评分项。而现在，它们被压缩成了一个分数。

你在 2026 年实际招聘的是什么

“AI 工程师”这个职位头衔承载了太多东西。同一个招聘启事正被用于招募至少三种不同的角色，它们共享技术栈，但需要的技能却有本质区别，而你的面试环可能正在用同一套标准给这三种角色评分。

第一种角色是产品 AI 工程师，他们将现有模型组合成一个可用的产品界面。他们把时间花在检索设计、提示词迭代、评估构建、延迟预算，以及让模型在特定业务场景中表现正常的那些乏味的集成工作上。他们需要品味、系统思维，以及在编写功能之前先编写评估的纪律。

第二种角色是AI 平台工程师，他们构建其他工程师使用的推理、训练或 RAG 基础设施。他们需要分布式系统、可观测性方面的深度，以及处理运行 GPU 工作负载这一不讨巧的底层工作的能力。对于这个岗位，“我直接写个提示词就行”的回答几乎无论谁说都是一个警示信号，因为他们的工作正是构建让提示词得以生效的底层架构。

第三种角色是机器学习/研究工程师，他们更接近模型本身——微调、评估方法论或原始训练工作。他们仍然需要了解数学，通常能从零开始实现一个 Transformer 块，并且会将“我直接写个提示词就行”视为候选人对模型行为没有见解的坦白。

如果你的面试小组用同一套标准面试这三种角色，那么“我直接写个提示词就行”对第一种角色是强烈推荐录用，对第二种角色是中立，对第三种角色则是不予录用。这 40 分的差距并不是对候选人的分歧。而是三个不同的面试官在根据他们各自心目中理想的岗位标准进行评分。

一个在发出 Offer 前能真正暴露分歧的校准流程

行之有效的模式往往令人感到不适，因为它要求面试小组承认彼此之间并未达成共识。大多数面试流程都会跳过校准（calibration），因为参与其中的资深面试官已经工作多年，并假设自己的判断就是标准。但 0.37 的 IRR 数值（评分者间信度）说明事实并非如此。

一个切实可行的流程包含四个部分。首先，在面试开始前，面试小组需要就**职位相称的评估准则（job-shaped rubric）**达成一致 —— 即本次招聘属于上述三种角色中的哪一种，哪些胜任力是核心支撑（load-bearing），哪些只是加分项（nice-to-have）。产出物应是一页纸，而不是 PPT。在这种沟通中暴露出的分歧，正是以前在复盘会议（debrief）上出现得太晚的那些分歧。

其次，面试小组共同回顾两到三个录制或转录的候选人面试环节，并在讨论前独立打分。目的不是为了达成一致，而是为了发现分歧点。如果在多个环节中反复出现某种分歧模式（例如，一位面试官给“我会直接用 prompt 解决”这种回答的分数总是比另一位高），这说明是准则存在歧义，而不是性格冲突。

第三，为模糊的胜任力增加锚点案例（anchor examples）。“表现出对 AI 输出的判断力”这种表述过于抽象，无法实现一致打分。“能识别模型初稿中的特定失效模式，并在合并代码前提出验证步骤”则足够具体，能让两位面试官给出相近的分数。这些锚点应当根据第二步中发现的分歧来编写。

第四，面试小组定期对已录用和已拒绝的候选人进行重新校准。问题不在于“我们选对了吗”，而在于“如果用今天的标准，这份计分卡还会得出相同的结论吗？如果没有，是评估准则发生了漂移，还是标准（bar）发生了漂移？”当那位力挺“我会直接用 prompt 解决”型候选人的资深面试官，现在正因为该员工无法思考边缘情况（edge cases）而感到沮丧时，校准会议就是将这种信号转化为可执行的反馈、而非个人成见的地方。

当团队无法达成共识时，领导者该如何行动

修复这一问题最难的部分不是流程，而是要在你所尊重的工程师面前承认：这个你无法为其招聘准则辩护的职能部门，正是由你负责配置人员的。人的本能是继续运行面试流程，并希望分歧能在足够多的面试场次中被平均抵消。事实并非如此，分歧只会发生偏移。你面试流程实际执行的标准，只是恰好在当周有空的面试官的合集；你在 12 个月内构建的职能部门，是由这种合集塑造的，而非源于任何明确的决策。

领导者的行动应该是暂停面试流程，留出足够的时间运行校准会议，即使招聘需求还在挂着、招聘人员催得很紧、工程经理也想在下一个 OKR 周期前拿到招聘名额。一个无法就“我会直接用 prompt 解决”意味着什么达成共识的小组，会在面试决策中不断做出让“力挺派”和“反对派”面试官在事后都无法辩护的决定。在一个团队内部无法达成评估共识的职能部门中强行配置人员，其代价不是一次性的招聘失误 —— 而是长达一年的职级错位 Offer、一年的复盘会议沦为 AI 哲学辩论，以及一年关于“招进来的人是否在做你所需要的工作”的事后合理化。

候选人那五个字的回答并不是模糊地带，你的评估准则才是。在开启下一轮面试前修复它，复盘会议才能重新回归到对候选人本身的讨论。