P-01
不同 HR，筛出来的人完全不一样
同一个岗位：A HR 看学历、B HR 看大厂背景、C HR 看关键词数量。最后进入面试的人差异非常大。
客户内部第一次意识到：招聘标准并没有被真正结构化。
/ 00项目是怎么开始的
问题一开始很简单 ——
「HR 团队已经 看不过来 简历了。」
2025 年底，这家拥有多条业务线的集团客户同时开启新一轮技术岗扩招。最开始的解法很朴素：加人。但很快他们发现 —— 人数增加，并没有解决问题。
01
同时开放岗位
Java · 前端 · 测试 · 数据
4 条技术线同步扩招
02
投递渠道
BOSS · 智联 · 猎聘 · 邮箱
多平台并发涌入
03
新增简历
12,000+
两周内 / 含重复与脏数据
04
首次查看等待
> 72h
最严重时 Java 岗位平均
/ 现场切片
每天早上，HR 团队先做的不是筛简历。
而是把大量时间，消耗在"整理简历"这件事上。真正进入筛选环节时，新的问题才开始浮现。
- 01登录不同招聘平台
- 02下载附件、重命名文件
- 03去重 / 合并 / 分类
- 04转发到对应业务部门
/ 01客户真正卡住的不是简历数量
而是 ——「技术岗位，已经超出了
传统 HR 的判断边界。」
JD 里写着「高并发 / 微服务 / 分布式缓存」，候选人却写着「秒杀系统 / Spring Cloud 重构 / Redis 热点」。对技术团队是同一类能力，对非技术 HR 而言，几乎无法在几十秒内做出判断。
JD 里这样写
候选人简历里这样写
- 高并发系统经验做过秒杀系统
- 微服务架构Spring Cloud 重构
- 分布式缓存优化过 Redis 热点 Key
- 消息队列Kafka 削峰
P-02
传统 ATS 开始失效
搜 "Go 开发"，写 "Golang / 云原生后端 / 微服务开发" 的人根本不会被召回；搜 "用户增长"，写 "Growth / 增长运营 / 裂变策略" 的简历也大量漏掉。
ATS 能找到「写得像 JD 的人」，但找不到「真正合适的人」。
P-03
技术部门开始不信任 HR 初筛
业务团队频繁反馈"很多不错的人根本没进来"；技术主管不得不重新参与第一轮筛选 —— HR 效率下降、技术团队被迫重复劳动、招聘周期继续拉长。
最严重时，一个 Java 岗位首次查看等待 > 72 小时。
/ 02为什么没有 All in 大模型
客户曾提出 ——「能不能直接用 GPT 自动筛简历？」
我们没有这么做。
纯大模型方案在真实生产环境中很快暴露出三个明显问题。这一次工程判断，决定了整个项目后续的方向。
· 01
分数不稳定
同一份简历，不同时间、不同 Prompt，评分会出现明显波动。HR 没办法建立信任 —— 信任成本，是 AI 工具上线的第一道门槛。
· 02
可解释性差
HR 最常问的不是「为什么是 82 分」，而是「为什么他比另一个人高」。无法解释技能来源、经验关联、岗位依据，HR 最终还是会人工再筛一遍。
· 03
成本无法控制
十万级简历库下，全部走完整大模型推理 —— 延迟、Token 成本、并发稳定性都会成为问题。AI 反而变成新的负担。
/ 03重新定义问题
这不是一个「聊天 AI」问题。
而是一个 高召回 · 高一致性 · 可解释 的搜索系统问题。
/ 最终路线
语义召回+规则评分+ LLM 增强
让不同模块分别做自己最擅长的事：规则负责稳定、向量召回负责覆盖、LLM 负责理解上下文。 AI 不再"一票否决"，而是作为评分体系的一部分参与决策。
/ 04最终方案是怎么工作的
整个系统被拆成 四条主链路 ——
每一条，都对应一个曾经卡住客户的真实痛点。
工程化 ≠ 调用大模型。我们把整套招聘流程重新拆解，让每个模块只做它最擅长的事，让 AI 真正可控、可解释、可信任。
Pipeline · 一份简历的完整旅程
STEP 01
先解决「简历根本收不上来」
这是最容易被忽略的部分。第一步不是 AI，而是 RPA + OCR + 格式归一：从多平台抓取、自动去重、识别 PDF / Word / 图片，进入同一套标准数据结构。
RPA 抓取OCR 解析字段归一去重合并
STEP 02
语义搜索，而不是关键词搜索
当 JD 写"高并发经验"，系统会同时理解 Redis / Kafka / 秒杀系统 / 分布式缓存 / 服务治理 之间的上下文关系。匹配的不是「词」，而是「这个人有没有真正做过类似事情」。
向量召回意图理解岗位语义图
STEP 03
五维评分，不让 AI 一票否决
最初我们让模型直接输出分数，但波动大、不稳定、难解释。最终改成「规则主导 + AI 辅助」：技能 / 经验 / 语境深度 / 逻辑结构 / 岗位契合 五维加权，AI 负责理解上下文，而不是拍板。
规则主导可解释五维加权
STEP 04
面试题生成 —— 真正让客户惊讶的地方
候选人写"做过高并发优化"，传统 HR 很难继续追问。系统基于项目经历、技术栈、岗位要求自动生成「缓存击穿怎么处理？」「Kafka 分区为什么这么设计？」这种继续往下挖的问题。
项目追问架构追问风险追问
客户后来评价："以前技术主管要帮 HR 一起做初筛，现在终于能拆开了。"
/ 05一份简历，在系统里 10 秒走完
这是客户第一次 真正"理解 AI" 的时刻。
我们把一份真实简历（脱敏后）完整跑了一遍：3 页 PDF、格式混乱、口语化表达 —— 整个过程小于 10 秒。
- STEP 01~2s
OCR + 结构化解析
提取技能、项目、时间线、教育背景、工作轨迹。
- STEP 02~3s
语义理解
识别 "Redis + Kafka 优化" 对应分布式缓存 / 消息队列 / 高并发治理，并与岗位需求做向量匹配。
- STEP 03~2s
五维评分
技能 / 经验 / 语境深度 / 逻辑结构 / 岗位契合 加权后形成雷达图。
- STEP 04~3s
生成面试提纲
技术追问 + 项目追问 + 架构问题 + 风险问题，直接交给面试官。
/ 候选人画像demo
82
/ 100 综合匹配分
Java 后端 · 5 年 · 分布式经验匹配
技能
88
经验
74
语境深度
81
逻辑结构
70
岗位契合
85
/ 09实际系统截图
不是设计稿，
是真正在客户那里跑起来的系统
从简历入库、人才库管理，到智能搜索、深度分析、面试题生成 —— 完整的五个关键界面，对应案例正文中的五条主链路。
gskjai · AI Recruit Console
STEP 01 · 让数据先跑起来
多渠道简历自动入库
Outlook / Gmail / 网易邮箱 / QQ 邮箱 / 企业微信 等 5 类来源一键打通，RPA 持续监听新邮件、自动解析附件、统一字段，再进入下游处理 —— 这是「简历收不上来」问题真正被解决的入口。
- 5 类邮箱 / IM 渠道接入
- RPA 持续监听 · 自动入库
- 字段归一 · 自动去重
01/05
/ 06真正难的不是 AI
是 工程化 ——
因为真实世界里的招聘数据，非常脏。
这些问题，比「调用大模型」复杂得多。它们决定了一套 AI 系统能不能真正跑在生产环境里。
01
图片简历
扫描件 / 截图 / 拍照
02
重复投递
同人多渠道，多版本
03
多平台字段不统一
学历 / 工作年限 / 项目结构
04
同人多版本
对外 / 对内 / 海投 / 定投
05
非标准命名
「最终版-终.终.终.pdf」
06
PDF 解析错误
字体 / 表格 / 双栏
07
技能表达极度口语化
「搞过」「弄过」「碰过」
/ 07上线之后，发生了什么
客户没有裁掉 HR。
HR 反而重新回到「判断人」这件事本身。
整个招聘流程，第一次真正形成「人机协同」。
/ AI 负责
收集搜索召回初筛生成建议
把"看完第一轮世界"这件事交给系统 —— 让规则负责稳定，让模型负责理解，让评分可以解释。
/ HR 负责
最终判断文化匹配风险识别沟通推进
HR 回到她们最该做的工作 —— 与人对话、判断契合、推进沟通、识别风险。这是 AI 替代不了的部分。
首次查看等待
72h → 10s
高峰期 Java 岗位
两周新增简历
12,000+
RPA 自动入库
评分维度
5 维
规则主导 · AI 辅助
新增 HR 名额
0
靠系统而不是加人
/ 08复盘金句
「招聘不是筛关键词，
而是在理解人。」
所以最后真正有效的，不是「AI 替代 HR」。 而是 ——「AI 先帮 HR 看完第一轮世界。」
/ 可迁移同一套底层能力
底层真正复用的不是「招聘」，
而是 大规模非结构化人才信息理解
校招筛选猎头人才库蓝领招聘内部转岗推荐灵活用工平台
