最近业内有一则消息值得关注谷歌 DeepMind 在招聘研发类岗位时会刻意“避开自家 AI”。这家实验室一手推动了大模型、强化学习、AlphaGo 等一系列里程碑成果却在挑选人类工程师时保留了一套更偏重人工判断的流程。很多人看到这个新闻的第一反应是“AI 公司为什么不信任 AI”但我更倾向于把它理解成一个清晰的工程判断AI 在招聘这种“候选人在刻意优化自身表达”的场景里很容易陷入反馈闭环和信号污染而顶尖的 AI 团队恰恰比谁都清楚这个问题的边界在哪里。这篇文章我会从技术角度拆解三件事第一AI 招聘系统到底是怎么工作的问题通常出在哪一环第二为什么“用 AI 直接筛人”和“人机协作筛选”是两条完全不同的技术路线第三如果你也想在团队里搭建一套招聘或筛选系统哪些环节该交给 AI哪些环节必须由人来拍板。1. 招聘“避开自家 AI”看起来保守其实是对技术边界的清醒认识先说背景。谷歌 DeepMind 是当今 AI 领域公认的第一梯队实验室。从 AlphaGo 到 AlphaFold再到后续在大模型和智能体方向上的布局都说明这家机构对 AI 技术本身的信任程度非常高。也正因为如此它在招聘环节选择保留大量人工评估才更值得反复琢磨。招聘场景和代码生成、数据处理、论文阅读有本质上的不同代码生成任务的答案相对可验证程序能不能跑、测试能不能过结果比较客观。数据分析任务的错误可追溯输入输出可对比偏差可以解释。而招聘是一个信号高度不确定的场景。一份简历、一场面试、一段自我介绍都是不完整的抽样信号。AI 模型非常擅长在这些不完整信号中找到统计规律但也非常容易把表面相关当成因果关系。从公开信息看DeepMind 保留人工评估环节并不是因为 AI 技术不够强而是因为“用 AI 去筛选一群工作目标同样是‘如何通过 AI 筛选’的候选人”本身就是一个不稳定的博弈系统。候选人会针对算法优化简历算法又会根据优化后的简历更新自己对“好简历”的定义这个循环一旦转起来筛选标准会越来越偏离真实的工作能力。这里可以给出第一个小结论一家公司选择在什么环节不使用 AI往往比选择在什么环节使用 AI更能说明它对 AI 能力的真实理解。2. 很多人没看懂的关键一个正在形成的“反馈闭环”AI 招聘真正让人担心的不是单点效果差而是它会形成一个闭环让问题自我强化。假设一个岗位发布后存在这样一条链路候选人 A 用大模型生成了一版看起来非常专业、结构完美的简历招聘方用 AI 模型初筛AI 更偏好“表达规范、关键词密集”的文本A 顺利进入面试B 因为简历不够模板化、表达不够标准被算法直接过滤更多候选人看到这个结果后也选择用 AI 改写简历数据库里“漂亮简历”的数量越来越多AI 模型训练时学到的“好简历”特征也越来越单一。这个过程就是典型的反馈闭环中的同质化。如果人工不介入系统最终筛选出来的并不是“最合适的人”而是“最懂 AI 求职套路的人”。真实工程问题的关键在于AI 在招聘场景里优化的是一个代理指标——文本看起来是否符合岗位要求而真正要优化的指标——候选人能否在长期项目中解决问题、能不能融入团队恰恰是这个代理指标很难覆盖的。更麻烦的是这个闭环一旦形成单纯靠优化模型很难打破。因为训练数据本身已经被 AI 生成的文本污染了。你让模型去区分简历是不是 AI 写的短期可能有效但很快候选人的表达又会继续演进让 AI 痕迹更隐蔽。这是一场持续对抗而不是一次性修复。筛选方式对文本规范度的要求识别真实工作能力的程度是否会强化同质化人工初筛要求低能容忍表达多样性较高但受个人经验影响不会关键词规则筛选要求高写不中关键词就漏掉较低会LLM 语义筛选要求高偏好结构化表达中等容易高估表达好的人会而且闭环更快从这张表能看出来LLM 筛选并不是一无是处但它当前阶段最大的问题是它会把“表达能力强”直接等价为“工作能力强”。这两种能力有一定相关性但在工程师招聘这种技能构成非常复杂的场景里相关性不足以支撑“算法一票否决”。3. 技术还原一套 AI 简历筛选系统是怎么搭建的要理解 DeepMind 为什么选择避开自家 AI需要先理解 AI 筛选系统的技术细节。下面用一个简化的 demo把真实系统中常见的三层结构拆开讲。3.1 第一层规则硬筛很多公司会先做规则初筛比如学历、工作年限、技能关键词。这一层最简单代码量也最少。# resume_filter.py # 规则硬筛先过滤硬性条件再进入下一层 import re REQUIRED_EXPERIENCE_YEARS 3 REQUIRED_KEYWORDS [Python, 大模型, 深度学习] def parse_years(resume_text: str) - int: 从简历文本中粗略提取工作年限。 matches re.findall(r(\d{1,2})\s*年, resume_text) return sum(int(y) for y in matches) def hard_filter(resume_text: str) - bool: if parse_years(resume_text) REQUIRED_EXPERIENCE_YEARS: return False if not all(kw in resume_text for kw in REQUIRED_KEYWORDS): return False return True if __name__ __main__: resume 拥有4年后端开发经验熟悉Python、MySQL最近在做推荐系统。 print(hard_filter(resume)) # False因为“大模型”“深度学习”都不在文本里这里的问题很明显关键词写不中就是不合格。很多候选人能力匹配但只是用词不同比如写的是“LLM 推理优化”而不是“大模型”就会在这一层被漏掉。规则筛的意义在于“稳定”不在于“准确”。3.2 第二层基于向量的语义匹配为了解决关键词的局限性更完整的系统会把 JD 和简历都映射为向量用向量相似度做排序。这里用一个简化示例来说明思路重点不是算法本身而是“匹配”这个动作的设计逻辑。# embedding_match.py # 简化示例用 TF-IDF 余弦相似度演示“语义匹配”的思路 from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity jd 我们需要一位有大模型推理经验、能设计和优化Agent系统的工程师 resumes [ 熟练使用PyTorch做过LLM推理加速与Prompt Pipeline优化。, 熟悉Java微服务负责过交易系统与消息队列。, 研究过RAG和向量检索对Agent规划链路有落地经验。, ] vectorizer TfidfVectorizer() corpus [jd] resumes tfidf_matrix vectorizer.fit_transform(corpus) similarities cosine_similarity(tfidf_matrix[0:1], tfidf_matrix[1:]).flatten() for i, score in enumerate(similarities): print(f候选{i 1}: 相似度 {score:.3f})这种做法能捕获部分语义相关性但它的上限取决于两个前提向量模型是否真正理解“大模型”“Agent”这类领域的上下文简历文本本身是否足以表征候选人的真实能力。如果向量模型是在通用语料上训练的它对很多专业岗位的理解往往会比较粗糙。结果就是相关性相近的简历可能被排在一起但相似度排序并不等于能力排序。生产环境里这一层更难的是同一个岗位在不同团队、不同 Line 里的要求差异很大向量模型很难用一个固定阈值统一处理。3.3 第三层大模型打分最近两三年很多团队把大模型引入筛选流程让 LLM 按提示词对简历进行综合评分。这种做法在演示阶段效果惊艳但真正上线后坑往往比预想的多。# llm_scorer.py # 示意用大模型对候选人自我介绍打分的提示词模板 PROMPT 你是一个招聘评估助手。请严格依据岗位要求评估候选人自我介绍。 岗位要求 {jd} 候选人自我介绍 {resume} 评估规则 1. 只基于文本信息判断不猜测候选人没写的内容。 2. 对“扎实可落地的项目经验”给出更高权重。 3. 如果文本存在空泛套话或模板化表达在 risks 中明确标注“内容同质化”。 4. 只返回 JSON不要输出其他内容。 输出格式 {{ score: 0-100, strengths: [...], risks: [...] }} def build_prompt(jd: str, resume: str) - str: return PROMPT.format(jdjd, resumeresume)技术层面上LLM 评分能做很多规则系统做不到的事比如理解项目经历的上下文、识别候选人是否在夸大贡献。但问题同样集中评估标准不稳定同一个模型换一个 Prompt 模板评分结果可能差别很大。会高估“表达清晰”LLM 更偏好文本流畅、结构完整的回答这容易在候选人评估中形成稳定的表达偏差。“同质化”不可见如果所有简历都是用类似模板写出来的LLM 并不容易识别出这种同质化它只会把每份简历当作正常文本继续打分。这一层的工程复杂度通常比想象中大得多。你需要建立评测集、对齐评分标准、做 Prompt 回归测试甚至需要一个专门的人持续维护提示词。招聘场景的样本量往往又不足以支撑精细调优所以很多团队最后会发现大模型筛选简历前期投入高后期解释难还容易引发候选人投诉。4. 实际落地时真正容易出问题的三个环节如果你把 AI 招聘系统的问题简单归类为“模型能力不够”那就低估了这件事。我更愿意把它理解为一个委托关系设计问题你把什么样的判断权委托给模型模型就需要为这个判断承担多大的责任。在招聘场景里最容易失效的三个环节是简历筛选的伪客观性。规则和模型看起来是客观的实际上每一层都在做价值判断。“3 年工作经验”真的适合所有岗位吗对于研究型团队一个刚毕业但有顶会论文的人可能比一个工作了三年但没有深度研究产出的人更合适。规则系统不会知道这一点。候选人行为适应性。候选人会根据自己的理解调整简历和行为方式。当筛选标准被 AI 预测时候选人也会学着“喂”AI 喜欢的内容。这是对抗性的不是一次性的。评估结果不可解释。LLM 的打分过程是一个黑盒它为什么给这个候选人低分团队很难向候选人或用人经理解释清楚。一旦发生争议你甚至没有一份可靠的“决策日志”。这三个环节放到一起其实指向一个更基础的问题AI 筛选在“低风险、高样本量”的场景里很有效但在“高成本决策、低发生频率”的场景里收益和风险非常不匹配。招聘一个工程师的成本绝不只是面试那几小时还包括用人部门几个月甚至一年的时间投入。在这种决策里算法给出的只是一个粗糙预测而人需要承担的是准确率之外的容错空间、解释责任和长期判断。5. 更合理的路线把 AI 放在“辅助”而不是“决策”不把最终决策权交给 AI不代表 AI 在招聘里没有价值。关键在于把 AI 放在哪一环。一个相对合理的工作流设计是AI 负责“整理信息、扩大漏斗、标准化评估”人负责“做决策、看动机、评估软素质”。# recruitment_pipeline.yaml # 一个偏保守的“人机协作”招聘流水线配置示例 pipeline: stage1: name: 候选人体验与信息收集 ai_work: 自动答疑、面试安排、文件整理 human_work: 定义岗位核心诉求 stage2: name: 简历初筛 ai_work: 用规则和向量模型过滤明显不匹配的简历 human_work: 复核通过初筛的简历而不是复核所有简历 stage3: name: 远程笔试 / 代码作业 ai_work: 自动运行测试用例检查代码规范 human_work: 评审设计思路、技术选型、代码可维护性 stage4: name: 结构化面试 ai_work: 生成面试问题清单、记录面试过程、整理访谈摘要 human_work: 进行深度追问判断候选人真实动机和潜力 stage5: name: 最终决策 ai_work: 汇总各轮评估结果生成一致的总结报告 human_work: 拍板、解释、承担结果 fallback: ai_review: true human_override: true这个结构的关键词是AI 不做一票否决也不做最终拍板。AI 负责把海量信息压缩成人类可以高效复核的形式人类则保留对关键节点的控制权。如果要把这个流程抽象成代码可以设计成一个带人工复核点的流水线# pipeline_demo.py # 演示带人工复核点的招聘筛选流水线 from dataclasses import dataclass from typing import List dataclass class Candidate: name: str resume_text: str interview_summary: str class RecruitmentPipeline: def __init__(self, threshold: float 0.6): self.threshold threshold def rule_filter(self, candidate: Candidate) - bool: # 第一层硬性条件过滤宁可多放不要误杀 return Python in candidate.resume_text def embedding_rank(self, candidates: List[Candidate]) - List[Candidate]: # 第二层按相关度排序但这里不做淘汰 return sorted(candidates, keylambda c: len(c.resume_text), reverseTrue) def llm_summary(self, candidate: Candidate) - str: # 第三层生成候选人的结构化摘要供人工决策 return f候选人{candidate.name}的主要经历{candidate.resume_text[:50]}... def run(self, candidates: List[Candidate]) - List[dict]: results [] for c in candidates: if not self.rule_filter(c): results.append({ candidate: c.name, action: reject, reason: 硬性条件不符, }) continue summary self.llm_summary(c) # 关键设计AI 只生成摘要不生成最终结果 results.append({ candidate: c.name, action: manual_review, summary: summary, }) return results pipeline RecruitmentPipeline() candidates [ Candidate(张三, 3年Python后端开发熟悉大模型推理), Candidate(李四, 5年Java开发参与过支付系统建设), ] for r in pipeline.run(candidates): print(r)这个示例里最重要的设计点不是代码本身而是AI 的输出形态是summary而不是score或pass/fail。当 AI 只负责总结时它在招聘流程里的角色是“信息助理”而不是“决策者”出错的边界就小得多。人工复核者看到的是压缩后的信息而不是一个不可解释的分数。6. DeepMind 事件给开发者的启示不是所有环节都需要 AI这条新闻表面上是招聘话题但背后的 AI 工程原则对做系统开发的团队同样有参考价值。技术团队里经常能看到一种倾向因为大模型能处理文本、代码、数据所以“所有环节都塞一个 Agent 进去”。但现实是AI 应该在结果可验证、容错成本低、反馈速度快的环节里发挥最大价值而不应该在结果难验证、容错成本高、反馈周期长的环节里贸然替代人类。拿软件开发场景来类比AI 写单测代码、做代码评审建议、生成接口文档这些环节的错误是可感知、可修正的容错成本低适合大范围使用。AI 做架构设计、生产环境变更审批、匹配候选人这类决策一旦判断错误影响周期很长代价很高就应该保留人类决策节点。在招聘场景里AI 生成面试问题、整理面试记录、做岗位 JD 分析这些都是低风险高价值的辅助工作。但让人类来读简历、做深度追问、做最终判断看起来效率低却是长期最可靠的方式。如果把 DeepMind“避开自家 AI”抽象成一个工程启示那就是不要为了使用 AI 而使用 AI而是为每一个环节设计“人类复核点”和“错误兜底方案”。这个原则不仅适用于招聘也适用于所有把大模型接入核心决策链路的场景。7. 实践建议如果要搭一套自己的智能招聘流程如果团队正在考虑把 AI 引入招聘或人才筛选我建议按下面几步推进。7.1 先画好决策链把招聘流程拆成“信息收集—信息处理—决策”三段明确哪些环节允许 AI 直接输出结果哪些环节只允许 AI 辅助。环节AI 可以输出AI 不应该输出候选人在线咨询常用问题回答、流程指引岗位匹配结论简历初筛关键词对比、语义相似度排序是否进入面试的最终结论笔试环节自动运行测试、代码风格检查技术深度评价面试问题清单、记录整理、摘要录用决策数据沉淀面试过程数据分析、漏斗转化率对候选人的能力画像这张表的核心思想是AI 负责让信息更完整、更结构化人类负责让决策更有判断力。7.2 保留一份“最小人工复核集”不要把人工复核放在所有简历上那样团队根本受不了。更有效的方法是让 AI 把简历按“明显不匹配”“待复核”“高匹配”分桶然后由人工只处理“待复核”和“高匹配”里的高风险案例。这样既保留决策质量又不至于让流程慢下来。7.3 对 AI 筛选结果建立“可申诉机制”如果 AI 在初筛阶段发挥了较大作用一定要给候选人一个被人工复议的通道。比如候选人可以主动补充说明或者申请人工复核。这不是形式主义而是对 AI 决策不可解释性的必要兜底。技术团队在设计这个通道时要保证它真的能到达人工而不是被另一个 Agent 自动拦截。7.4 持续记录 AI 决策日志任何用 AI 做招聘决策的系统都应该有决策日志哪个模型、哪个版本、什么提示词、看到了什么输入、输出了什么结果、谁做的最终判断。这样出现争议时才能回溯也才能持续优化。8. 总结与延伸思考DeepMind 在招聘中“避开自家 AI”与其说是对 AI 的怀疑不如说是对 AI 使用边界的诚实判断。在代码生成、数据分析、文档总结这些可验证场景里AI 明显能提高效率但在“评估一个复杂人类是否适合一个复杂岗位”的场景里AI 目前更适合当一个信息助理而不是最终裁决者。真正专业的 AI 应用不是把所有任务都交给模型而是清楚每个环节什么时候该用 AI、什么时候该用人并为每一个自动化决策保留人工兜底。如果你正在做招聘系统相关的开发可以从一个最小改动开始把“AI 直接判定通过/不通过”改成“AI 生成结构化摘要 人工复核”。这个调整看起来不如全自动筛选炫酷但它能在早期避免掉很多同质化、误判和候选人体验问题。如果想继续深入建议研究三个方向第一针对候选人的“对抗性文本生成”如何检测第二如何在保持 AI 辅助效率的同时让评估结果对人类可解释第三如何用小型评测集持续监控招聘模型在不同岗位上的性能衰退。这三块任何一块做透了都会是很有价值的工程积累。