你开启了一个“评测工程师 (eval engineer)”的招聘需求。一周后，你的招聘人员问了一个显而易见的问题：这个岗位的职级是什么，一份优秀的简历长什么样？你给不出答案。两年前，这个头衔还不存在。没有职级评定标准，没有标准的面试流程，LinkedIn 上也没有现成的“评测工程师”人才库。你在为一个行业尚未达成共识是否存在的职位进行招聘。
这是交付 AI 系统过程中一个隐形的瓶颈。模型是现成的，基础设施是可租用的。你无法从市面上直接买到的是这样一种人：他们的实际工作是确保基于 Prompt 的系统保持“诚实”——而你那套为拥有数十年先例的岗位而构建的招聘机制，并没有给他们留位置。
直觉是等待。等待头衔标准化，等待培训班批量产出候选人，等待别人写出你可以照搬的职级指南。这种直觉是错误的。无论头衔是否存在，工作就摆在那里，而现在就开始组建团队的人，会在竞争对手还没开启招聘需求之前，就摸索出什么是真正的“优秀”。
即使头衔杂乱，岗位职责却是真实的
走进任何一家在 2025 年交付了 Agent 系统的公司，你都会发现同样没人负责的工作。需要有人负责评测 (evaluation)：决定新的 Prompt 是否真的比旧的好，构建能回答该问题的测试框架，并防止其失效。需要有人负责 Prompt 界面本身——即那些目前还没人能完全理清的、杂乱无章的系统提示词 (system prompts)、工具描述和 few-shot 示例。需要有人负责可靠性：重试、超时、模型版本锁定，以及目前还没有仪表盘监控的输出质量的缓慢下滑。
招聘板为这些工作发明了十几个名称：评测工程师、Agent 可靠性工程师、上下文工程师、Prompt 系统负责人、AI 可靠性工程师、信任工程师。这些头衔都是噪音。它们是事后贴上的营销标签，在不同公司之间无法直接对应。不要针对头衔招聘，要针对没人负责的工作招聘。
实际的做法是围绕你正在经历的具体失败来编写职位描述。不是“评测工程师，职级待定”，而是“那个能用证据告诉我们，发布这次 Prompt 变更是否会让支持 Agent 表现变差的人”。这种表述起到了两个作用：它告诉招聘人员筛选什么，也告诉了你这个角色目前是需要一个全职岗位，还是一个应该挂载到现有工程师身上两个季度的职责。很多这类角色最初都是后者，这没问题。有问题的是因为觉得头衔还不成熟，就让这些工作处于无人负责的状态。
筛选判断力和品味，而非工具清单
在为陌生的岗位招聘时，人的反应往往是锚定工具。你写下的职位描述要求具备特定评测框架、特定追踪平台或特定 Agent 库的经验。这会造成严格的过滤——而且过滤掉的恰恰是错误的对象。
这个领域的工具保质期是以月来计算的。你今天列出的框架，在新人第一次绩效考评之前可能就被淘汰了。更糟糕的是，要求特定的工具会筛选出那些追逐工具的人，而不是理解底层问题的人。一个仅凭电子表格和一股韧劲从头构建评测框架的人，表现会优于一个能配置流行平台但说不清该测量什么的人。
你实际在筛选的是判断力和品味。在以评测为核心的角色中，编写 Prompt 是简单的部分。难点在于判断新版本是否真的比旧版本更好——选择正确的指标，设计能反映生产环境的测试集，识别基准测试何时失效，以及拒绝那些看起来很漂亮但毫无意义的数字。这就是品味。它不会作为关键词出现在简历上。
所以，直接针对这一点进行面试。给候选人一个真实的、混乱的案例——一个有缺陷的评测集，一个通过了测试但在生产环境中失败的 Prompt，或者一个指标提升了但用户却在抱怨的案例——让他们进行评判。观察他们是去核实还是去假设，观察他们在提出解决方案之前是否询问了系统的实际用途，观察他们是否能阐述在两个不完美选项之间如何权衡。优秀的候选人会将 AI 的输出视为实习生的工作来检查，而不是将其视为神谕来信任。这种怀疑的、注重细节的、对未经审查的数字过敏的直觉，就是这份工作的全部。工具清单无法告诉你这些。
优秀的候选人往往来自“跨界”领域
这是让大多数招聘流程卡壳的地方：这些角色最合适的人选往往并非来自机器学习领域。
人们的本能反应是将所有 AI 相关的招聘需求转给 ML 工程师和研究员。但这些工作大部分不是建模。评测或可靠性团队中没有人是在训练基础模型。他们是在设计测量系统、构建测试基础设施、推理故障模式，并将一个非确定性的黑盒视为需要进行特性化和约束的对象。这些不是 ML 技能，而是 QA 技能、数据工程技能和平台工程技能。
想想谁已经在做评测工程师的核心工作了。一名资深 QA 工程师的整个职业生涯都在决定测试什么、构建框架，以及区分真实的回归和噪音——他们只是还没把这些技能应用到语言模型上。一名处理过脏数据并构建过流水线的数据工程师，比大多数研究员更理解评测集的构建和偏移 (drift)。一名运行过生产系统的平台工程师，已经在思考重试、超时、版本锁定和优雅降级——这正是 Agent 可靠性所需的技能集，只是应用在了一种新型依赖上。
这些人申请你的 AI 职位时，往往会在第一轮就被刷掉，因为他们的简历上写的是“QA”而不是“ML”。解决办法是结构性的。明确告诉你的招聘人员，要从 QA、数据和平台背景的人才中寻找，而不仅仅是 ML。删掉职位描述中的建模术语，以免吓跑合适的人。并增加一个能快速定论的筛选问题：让候选人为一个他们从未见过的系统设计评测方案。从未交付过产品的 ML 研究员往往会不知所措，而 QA 负责人则会两眼放光。雇佣那个两眼放光的人。
在入职第一位员工之前建立职级叙事，而不是在那之后
最昂贵的错误不是招错了人，而是将一个优秀的人才招入一个没有前途的职位。
因为职位头衔是全新的，它没有职级。正因为它没有职级，它就不会出现在你的晋升标准、薪酬职等或绩效定准会议（calibration meetings）中。新员工做了出色的、支柱性的工作——然后到了考核季，却发现没有评价准则（rubric）来描述他们的贡献，没有同级别的群体来进行横向对比，也没有明确的职业下一步。他们得到了一个模糊的评分和不痛不痒的涨薪。一年内他们就会离开，因为没有梯级的职位就是带天花板的工作，而优秀的工程师能感觉到天花板。
你应该在发布招聘需求（req）之前防止这种情况，而不是在之后。将新职位映射到你现有的职级体系（ladder）中。你几乎肯定不需要一套平行的等级制度——工程职级体系已经涵盖了从初级到 Staff 甚至更高级别，职级由工作范畴（scope）、自主性（autonomy）和影响力（impact）决定，而不是由领域决定。一个智能体可靠性工程师（agent-reliability engineer）本质上就是一名可靠性工程师；其影响力只是通过评估覆盖率（eval coverage）和事故减少来衡量，而不是通过功能交付。一个评估系统（eval-systems）负责人就是一名高级工程师，其负责领域是测量基础设施。为每个职级写一段话，描述在该范畴下的工作状态，你就拥有了一个职级叙事（leveling story）。
然后确保那些从未接触过该系统的人也能看懂这个职级叙事。负责绩效定准的经理需要理解，对于一个他们从未管理过的职位，“优秀”是什么样子的。晋升委员会需要一个他们可以辩护的理由。如果唯一能解释新员工影响力的人是新员工自己，那么这个职位在结构上就是无法晋升的，你亲手挖了一个陷阱。花一个小时写好评价准则。这比在 18 个月后重新启动招聘要划算得多。
现在就开始配置人手
所有这一切的模式都是一样的：不要等行业追赶上来才行动。
职位头衔最终会标准化。职级指南会被写出来，面试流程会趋于统一，培训班也会批量生产简历上写满关键词的候选人。到那时，招聘这些职位会变得容易、竞争激烈且昂贵——就像招聘任何成熟领域的专业人才一样。现在的优势在于，上述情况都还没有发生。
因此，根据你正在面临的失败来定义职位。筛选判断力，而不是对照工具清单。从 QA、数据和平台领域进行跨界挖掘，而不仅仅局限于 ML。并在发出录用通知（offer）之前写好职级叙事，这样你招到的人才有路可走。如今正在这样做的团队不仅仅是在填补空位。他们正在积累关于这些职位的组织知识——等到行业其他公司对头衔达成一致时，他们早已知道如何招聘、定级和培养这些人才。
工作现在是真实的。现在就配置人手。