最近业内有一则消息值得关注：谷歌 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(jd=jd, resume=resume)技术层面上，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, key=lambda c: len(c.resume_text), reverse=True) 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 辅助效率的同时，让评估结果对人类可解释；第三，如何用小型评测集持续监控招聘模型在不同岗位上的性能衰退。这三块任何一块做透了，都会是很有价值的工程积累。
