如何招聘AI工程师而不踩坑

招聘看的是持续展现的判断力

演示没问题。简历也漂亮。面试一完，大家都挺兴奋。

然后有人问：如果系统把同一笔退款发了两次会怎样？

沉默的代价可不低。

招AI工程师之所以难，是因为工作的可见部分完成得太早。一个能用流畅段落回复的聊天窗口，看起来就像成品了。但你完全看不出它是否遵守权限设置、能否在超时后恢复运行、或者每张工单花费的成本是不是比它本要替代的人还高。

你不需要在注意力头的问题上争出个输赢。你需要的是足够多的证据，来决定谁能替你做那些决策。

要为其背后的判断力而招人。在发出录用通知之前，让那种判断力变得可见。

以下是我会用来筛选一位将AI交付到产品中的工程师的流程：先写下预期结果，打开一份真实的工作，为一次短期的带薪工作环节付费，然后根据实际所见打分。研究和基础设施岗位需要不同的练习。从岗位本身入手。

先定义岗位，再买简历

「我们需要一位AI工程师」这句话，和「我们需要一个懂钱的人」差不多有用。会计？CFO？还是那位劝创始人别再买域名的哥们？

选一个你想雇人来负责的问题。

一个人可以覆盖多个行。期望在全部五个方面都达到同等深度，这就是有报酬的愿望清单式的岗位描述。

在开始面试之前，先写下前90天的目标。例如：

确定一个支持草拟助手是否能减少处理时间而不增加策略错误。交付一个可度量的试点、一条人工审核路径，以及一份关于扩展、修改或停止的建议。

这给了候选人一些可以反驳的东西，而这正是关键。优秀的候选人会问：处理时间如何度量？谁拥有策略？有没有人检查过当前的人工回答质量如何？差劲的候选人只会说听起来挺激动人心的。

如果你的团队里没人能评判技术证据，那就请一位外部从业者来做评估——同时问清楚他们之后是否期望向你出售实施。否则，候选人最终还是自己充当自己的技术参考，这其实是一种姿态更好的利益冲突。

让他们打开引擎盖

一家知名雇主告诉你的是某人在哪里工作过。一次演示告诉你的是某件事成功运作过一次——在一台笔记本电脑上，心情不错的时候。两者都无法告诉你这个人能在你的团队里承担什么。

让他们挑一个可以一追到底的项目：

“带我过一遍你亲自交付的某个东西。你负责了什么，什么出了岔子，结果因为哪些证据而改变了？”

然后沿着一条决策追完整个弧线：最初的方法是什么？他们度量了什么？拒绝了哪个备选方案，原因是什么？某位队友贡献了什么？现在再来看，他们会怎么做？

要一个工件：某次失败跑的脱敏追踪记录、一份评估报告、一份设计文档、一个测试、一段短的代码走查。追踪记录就是系统在到达答案的过程中做了什么的所有记录——每一次工具调用、每一次重试、每一次默默吞掉。这是读完文章和看到真正工作之间的区别。

拒绝交出前雇主客户数据的候选人，是通过了测试，不是没通过。

换成一个重构的示例，或者用下面这个共享练习。“展示证据”绝不能变成“带来别人的秘密”。

对于资历较浅的候选人，证据可以小一些，这没问题。把期望的范围和监督级别按岗位做缩放。你测试的是理解力和所有权，不是对知名Logo的接触权。

值得花在面试时间上的五个问题

这些是深挖的提示，不是冷知识。如果背出答案就足以通过，那这个问题就没什么用。

1. “你怎么判断这个智能体是不是改善了？”

关注的是用岗位语言定义的成功：工单正确解决的数量、智能体真正发出的草稿、本可以不发生的升级。然后问一个平均分数会隐藏哪些失败，以及他们会拿新版本跟什么做对比。

好的答案让度量是可检查的。让他们当场草绘三个测试用例，并说明谁来判断每个用例是否通过。如果是模型给答案打分，问问他们怎么检查评分器。“得分 94%”并不是度量，如果同一次运行在周二得分 82%。

Anthropic的智能体评估指南划出了你面试中该有的区分：智能体做过什么的记录，不等于结果。一个智能体报告“我发出了退款”是一句话，不是一个退款。

2. “工具在提交退款后超时了。现在怎么办？”

“重试”是错误的条件反射。钱可能已经不在手上了。

关注的是在采取行动前先检查交易状态、用幂等键让第二次尝试落在第一次操作上，以及当状态真正未知时的升级路径。问问谁会看到这次失败，以及之后工作如何恢复。具体术语不重要，重要的是他们的设计能不能因为一次错误而向客户收两次钱。

3. “这个系统能读取、改动和花费什么？”

询问边界：能读取哪些记录、能执行哪些行动、哪些环节需要人工批准，以及什么机制能阻止一个循环刷爆你的信用卡跑一整夜。

然后问边界在哪里执行。一条让模型“小心”的提示只是用策略文本搭建的防火墙——意图是有的，但执行不到位。让他们画出边界，并提出一个试图跨越边界的测试。

同时问一下数据暴露情况：哪些数据会传给模型提供商，哪些会写入日志，谁可以读取这些日志。“我们记录所有东西”是等着被合规对话找上门的话。

4. “这个系统的哪一部分你会不用 LLM 来实现？”

一名合格的工程师能从自己的方案中拿掉 AI。资格规则、算术计算和权限检查都有不会产生幻觉的、无聊的实现方式。而理解一位沮丧客户的意思则不能。

问问在具体的工作流中模型给你带来了什么，以及什么证据能证明额外的故障面是值得的。如果图中的每个框都需要智能体，那就要求画一个更小的图。

5. “讲一个你放弃过的方案。”

注意听那个改变了他们看法的观察。用户想要的是搜索，不是聊天。更贵的模型反而降低了总处理成本。某个功能不值得上线，他们这样说了。

一个坦诚的负面结果胜过精心打磨的成功故事，因为成功故事很少揭示决策规则。问问他们停止了做什么，以及花了多久才停下来。

为一个小型工作会话付酬

使用一个有边界的、付费的合成数据练习。提前发送简要说明和评分标准——你是在招聘判断力，而不是招聘面对突然袭击的能力。让人们使用他们会在工作中使用的工具，包括 AI，然后让他们解释和验证产出的结果。

一个面向应用工程师的示例性 90 分钟会话：

你接手了一个支持助手，它负责起草回复并提议退款。这里有十二个合成工单、一份简短的政策文档和四次记录的执行。有一条回答引用了我们三月份已废弃的政策。有一个退款请求超时。有一个工单要求获取另一位客户的信息。请给出是否扩大试点的建议，并展示一个小的改进或测试。

十五分钟用于明确目标，四十五分钟深入探索，三十分钟解释建议。给他们一个准备好的环境，这样练习就不会暗中变成对 npm install 的测试。照顾无障碍需求，并保持候选人的条件相当。

你观察的是他们提出了哪些问题、查看了哪些证据、首先关注哪个风险。他们是否注意到十二个工单无法确立可靠性？他们能否交付一个窄范围的修复而不声称系统现在没问题了？他们能否说出下周应该做什么？

那个为重复退款添加了一个失败测试的候选人，可能比那个交付了漂亮聊天界面的候选人告诉你的更多。

对同一角色的所有人都应用相同的核心问题和相同的评分标准——这就是美国人事管理办公室 结构化面试指南 背后的基本结构，它的存在是为了让你的评审团队比较候选人而不是凭感觉。让练习贴近真实工作。工作样本和免费咨询之间的界限比大多数招聘经理想的要窄，而候选人在房间对面就能看出来。

招聘评分表

将此内容复制到面试文档中。在见到任何人之前就每个维度的要求水平达成一致，因为一旦你喜欢上某人，标准就会移动。每位面试官在复盘之前独立评分，并为每个评分附上具体的观察记录。

1 = 无支撑或存在重大缺陷，2 = 在大量指导下可工作，3 = 在角色范围内是合理的，4 = 合理的判断加上已验证的验证。N/O = 未观察到，当面试从未产生证据时使用。N/O 是一个需要去填补的缺口，而不是一个拿来平均掉的零分。

这是一个决策辅助工具，而不是经过验证的岗位绩效预测器。请根据你的角色校准它，并在人们入职后对照实际发生的情况进行检查——否则你只是在调校一个你从未评分过的评判标准。

对于独立负责生产环境的人，我希望在每个基本维度上都看到合理的证据。一个强大的总分永远不应掩盖未解决的权限或恢复方面的弱点；这两项是日后会找你算账的。对于正在成长中的工程师，写下他们需要的支持以及提供支持的人的名字。

用三句话结束复盘：这个人能拥有什么？他们需要什么支持？我们仍然不确定什么？ 一个不能回答这些问题的评审团即将进行一场关于执行力的四十分钟对话。

红旗警示值得多问一个问题

当候选人无法将自己的贡献与团队的贡献区分开来、将每个过去的项目都视为未中断的成功、或者用形容词来回答度量问题时，要小心。“高度准确”需要一个分母。

其他烟雾信号：在问题被理解之前，智能体就出现在设计中；运营成本没有上限；故障恢复属于其他团队；安全性完全存在于提示词中。

在得出结论之前，用一个具体的场景再探究一次。不熟悉的术语并不代表概念缺失，很多优秀的工程师是用不同的名称学习这些想法的。当候选人中途意识到自己的错误时，要给予肯定。在看到矛盾证据后拒绝更新——这才是取消资格的行为——而需要安静片刻思考则不是。

已经开始担心招错人了？先审计工作

一个挣扎的 AI 项目并不能证明你招错了工程师。可能要求本身就不可能完成，数据不可用，或者领导层在任何人测量质量之前就在主题演讲中承诺了完全自主权。

在你要求重写之前，在适当的访问控制下保留代码、配置、评估结果和相关日志。然后确定公司实际控制哪些账户、服务和 API 密钥——这正是团队发现整个管道运行在一个人个人账单上的时刻。

请独立审视几个代表性的工作流。哪些有效？哪些失败？哪些断言可以复现？在不确定的行为正在调查期间，限制高风险操作，并将工作分类为保留、修复和替换。

要求一份简短的恢复计划，包含验收测试、指定的负责人和决策日期。“我们需要一个新框架”是一个需要审视的提议，而不是一个诊断。

允许招进来的人破坏路线图

如果你的公司在惩罚它刚刚花了六周时间来选择的判断力，那么以上一切都不起作用。

那个说“这一步必须有人工审批”或“试点还不足以扩展”的工程师，需要一位能在众人面前听得进去的领导者。如果你为了证据而招人，然后又埋没那些不便于听的发现，你就制造了一台昂贵的机器，专门用来生产你早已想要的答案。

因此，对于下一个 AI 角色：写出结果，使用评分卡，观察候选人如何深入探究不完美之处。

你希望找到的人，既能向你展示系统为何已就绪——也会在系统尚未就绪的那一天，大声告诉你。