AIHR
把AI引入招聘的初衷几乎一致：简历太多看不过来，用模型先筛一遍。这个诉求真实且合理，但它掩盖了一个更深的问题。多数企业的招聘困境从来不是筛不出人，而是从一开始就不知道自己要什么样的人。
一、瓶颈转移：从筛人到定义人
招聘由两个环节构成：定义标准，然后按标准匹配人选。过去二十年，行业的绝大多数创新集中在第二个环节，渠道扩展、简历解析、关键词检索、人才库打标，都是为了更快更多地找到人。
第一个环节长期处于粗放状态。业务部门提交的用人需求通常长这样：有相关经验、沟通能力强、能扛住压力。这三句话无法变成筛选标准，因为它们没有定义什么叫相关、什么叫强、什么叫扛得住。
在人工筛选为主的年代，这个问题被招聘官的经验隐性修补。一个有经验的招聘官会拿着这样的需求去追问业务负责人：上一个做得好的人是什么样的，他做对了什么，团队里现在缺的是哪一块。通过这些追问，模糊需求被临时翻译成可判断的标准。
当AI接管筛选，这个隐性修补环节首当其冲被跳过。模型不追问，它直接执行。给它一句模糊的需求，它会漂亮地输出一批看起来匹配的简历，速度快、数量足、格式专业。模糊输入乘以高效执行，产出的是规模化的错配。
AI没有制造招聘的定义困境，它只是把这个一直存在但被人工经验掩盖的缺陷，以十倍的效率放大并呈现出来。
二、亚马逊引擎给出了什么教训
要理解定义失准与模型结合的风险，亚马逊的招聘引擎是一个绕不开的案例。
亚马逊大约在二零一四年开始构建一套用算法给求职者打分的系统，目标是自动化筛选。团队用过去十年间提交给公司的简历训练模型，让模型学会识别什么样的人值得进入面试。
问题在于训练数据本身。这十年间招聘成功者的简历以男性占压倒性比例，模型因此学会了把包含特定性别指向词汇的简历降级，包括出现在女子象棋俱乐部这类经历里的用词。系统还学会了给两所特定大学的毕业生加分，因为历史数据里这些学校的校友更多。
团队尝试修改代码，甚至试图让算法忽略这些词，但无法保证模型不会找到新的替代方式做出同样的区分。这套系统在二零一七年前后被废弃，相关团队解散。
这个案例常被讲成一个偏见故事，但它的组织含义更重要。当标准定义不清，模型会用历史数据里最容易获得的信号去填补定义空缺。历史数据记录的是过去谁被录用了，而不是谁真正胜任。这两者之间的差距，就是错配的来源。
三、业务部门为什么给不出标准
把责任推给业务部门并不公允，他们给不出清晰标准有结构性原因。
第一，多数业务负责人对岗位的理解来自个例而非抽象。他真正能描述的是上一位做得好的人长什么样，而不是这个角色需要具备什么。一旦要求他脱离具体的人去谈能力，描述会迅速滑向空泛。
第二，岗位本身在变化。很多岗位的边界每年都在调整，负责人自己对明年的要求也没有清晰图景。要求他给出稳定标准，本质上要求他先做一次他自己也没完成的思考。
第三，用人需求的表达缺乏工具。组织给业务部门的表单是学历、年限、职级这些字段，它们描述的是候选人的外部特征而非岗位的内在挑战。在这种表单里，业务负责人没有地方写下真正重要的那部分。
换一组提问就能换出标准
撬动点不在要求业务把需求写得更详细，而在改变提问的方式。有效的提问从来不是「你要什么样的人」，而是「这个人来了要解决什么」。
一组真正有用的问题大致是这样：他入职后前九十天必须拿下的结果是什么；这个位置上过去的人通常在哪里失败；哪些能力可以进来之后再补，哪些必须在入职时就具备；如果这个岗位由内部人接手，谁可能是那个人，他差的部分是什么。
这组问题的价值在于它强迫业务负责人描述困难而非描述人。困难是具体的，人是抽象的。从困难出发推导能力要求，得到的才是可判断的标准。
四、简历信号为什么必须被替代
即使定义清楚了，第二个障碍仍然存在：简历本身是一个极弱的胜任信号。
简历记录的是经历标签，比如某校毕业、某公司任职、某项目参与。这些标签与真实胜任之间的相关性，远低于多数人的直觉。同一个title在不同组织里对应的实际责任可能相差巨大，同一个项目里不同人的贡献差异也不会体现在一行描述里。
当AI被喂以简历数据，它优化的是对经历标签的匹配度，而不是对真实能力的预测力。这正是亚马逊引擎失手的机制：模型在简历的表面特征里找到了与历史成功者高度相关的信号，然后把这个相关当成了因果。
替代方案的方向很明确，是用工作样本替代经历标签。给候选人一个贴近真实岗位的简化任务，评估他处理这个任务的实际产出与推理过程。这种做法在成本上高于筛简历，但它提供的信号强度完全不同。
成本顾虑可以用分层设计缓解：先用低成本的信号剔除明显不匹配的候选人，对进入核心范围的人再使用工作样本。关键是工作样本必须在关键决策点上使用，而不是被完全省略。
五、一次真实的需求对齐沙盘
把前面的原则放进一场具体的招聘需求沟通里，操作会显得清晰。
需求方是某产品线负责人，理由是团队缺人，要求尽快到岗一个资深人选。招聘官按惯例收到的信息是 title、汇报关系、薪资区间，以及一句「要有大厂背景，能独立带队」。
如果直接执行，这批需求会变成一组检索条件：年限、公司名单、是否有管理经历。检索很快，几天就能给出候选人，面试通过率却很难看，因为「能独立带队」没有被定义。
换成从困难出发的追问，得到的图景完全不同。原来这个产品线在过去的失败集中在一个具体环节：跨部门推动资源时，前任倾向于自己做而非说服对方配合，导致协作方抵制、进度卡死。真正稀缺的不是带人经验，是跨边界影响的能力。
改写之后的需求变成：需要有在缺少正式授权的情况下推动多方协作的具体经历，并且能讲清楚当时怎么争取到的支持。这个标准可以直接转化为面试问题，也可以转化为一个简短的情境任务。
差别在于前者检索的是标签，后者判断的是能力。同一个岗位，两套标准招到的人完全不同。
六、合规是不可跳过的外部约束
在设计与部署招聘AI的阶段，合规不是可以后续补充的环节。欧盟人工智能法案把就业领域的候选人筛选与评估列为高风险应用，要求部署方承担数据治理、人工监督、可解释性与记录留存等义务。
对企业而言最实际的一条是举证责任倒置：当候选人对筛选结果提出质疑，组织需要能够解释为什么拒绝了这个人。以深度学习模型为基础的黑箱筛选，很难满足这一要求。
务实的选择是在关键决策点保留可解释机制。不是要求整个系统透明，而是要求每一个拒绝决定都能给出可复核的理由。这条约束会改变系统的设计取向，从追求预测精度转向追求可辩护性。
七、招聘官的角色重述
AI进入招聘流程之后，招聘官的工作不是变少，是重心移动。被替代的是检索与初筛部分，这些本就不是这个角色的核心价值。
剩下三件事的难度显著上升。
第一是需求翻译。把业务部门模糊的诉求转成可判断的标准，这需要理解业务的实际处境，也需要提问的勇气。
第二是評価设计。既然简历是弱信号，就必须设计替代信号，比如工作样本、情境任务、结构化追问。设计评价工具是一件专业活，比筛选简历难得多。
第三是边界守卫。当供应商宣称系统可以自动识别胜任与否，招聘官需要判断哪些环节不能交给模型，尤其是涉及合规与不可逆判断的部分。
八、会翻车的几个地方
- 直接把JD翻译成检索条件。业务给的需求通常是外部特征而非能力要求，未经翻译就执行，等于用高效工具放大原始缺陷。
- 用历史录用数据直接训练。历史数据只记录谁被录用，不记录谁真正胜任。亚马逊的教训正在于此，模型会把历史偏好学成标准。
- 用简历信号评估胜任。经历标签与真实能力的关联远低于直觉，关键决策点应当使用工作样本。
- 跳过可解释性要求。一旦部署黑箱筛选，面对质询时无法举证，这在监管框架下是明确风险。
- 把招聘官的产能等同于面试场次。当筛选被自动化，招聘官的价值转向需求澄清与评价设计，继续用场次衡量只会鼓励错的行为。
结语
从招聘到人才战略的说法被讲了很多年，落到实处只有一件事：把定义权拿回来。AI在匹配环节的能力增长是确定的，它不会在「我们要什么样的人」这个问题上有任何帮助，因为这个问题只属于人。
衡量一个组织的招聘是否被AI真正增强，可以看一个简单指标：用人部门提交的需求里，描述困难的句子占比是多少。如果这个数字接近零，那么无论采购了多先进的系统，筛选的都还是标签。
参考信源
- 亚马逊（Amazon）公开披露与主流媒体报道
- Regulation (EU) 2024/1689（欧盟《人工智能法案》）
