HR+AI Builder=?

刘晓坚
我准备好了,你们呢

HR + AI Builder

刘晓坚

HR

9 年人力资源经验

蝉妈妈招聘负责人

AI Builder

半年 AI 开发实践

解决招聘问题 → 解决真实的业务问题
正在实践的工作方式FDE

走进业务,把问题问清楚,做出来,再验证。

也是我接下来持续转型的方向。

我从业务出发,用 CodeNext 把想法做出来

我的起点,是业务现场

先把问题问清楚。

再判断人和 AI 怎么分工。

做出来,再回到业务验证。

CodeNext

公司内部自研、面向全体员工的 AI 开发平台。

用业务语言先把问题
和边界说清楚
AI 协助实现生成页面、逻辑
和自动化代码
回到现场验证边使用、边发现
下一处问题
01

从自己的业务开始

招聘自动化控制器

先解决我每天都在面对的问题

招聘真正难的,是判断和推进一直重复

01理解岗位需求,统一筛选标准定义
02从推荐候选人里找到值得看的人发现
03读简历、做判断、决定是否触达判断
04跟进材料、消息和下一步动作推进

一份可调的岗位画像,驱动两条独立任务

岗位画像不是三条标签,而是一套可以反复调整、保存和复用的筛选策略。

画像与筛选策略

生成岗位画像保存当前配置
城市广州
经验1—3 年
年龄26—33
学历大专
薪资15—30K
性别不限
性别硬性要求可切换
需要作品集可切换
岗位类型关键词组销售 / 商务 / BD / 客户经理 / 大客户代表
必选关键词组SaaS / ToB / 软件销售 / 企业服务 / 电商
扣分关键词门店销售 / 实体店销售 / 与岗位方向偏离的经历
语义必须条件有相关行业经验,客户类型和工作内容达到基本要求
语义加分项同类产品、业务场景或目标客户经验更加匹配
语义扣分项经历证据不足、方向偏差或存在明显风险信号
技能与工具工作经历项目经历材料缺失处理触达策略
保存一套策略两条任务共用

自动寻访

从推荐列表找人、读简历、判断并触达。

分开运行 不抢同一页面

沟通闭环

检查已有会话、材料和状态,持续推进。

为什么拆开? BOSS 页面同一时间只能执行一类操作,分开运行可以避免两条任务相互干扰。

自动寻访找新候选人,沟通闭环推进已有会话

两边都有任务控制、运行指标和候选人明细,但处理的是招聘流程里的不同阶段。

推荐候选人列表

自动寻访

开始自动寻访
最多打招呼500
处理上限500
最多读简历500
已扫描435
已读简历181
模型判断轻 181 / 重 21
已打招呼32
候选人岗位匹配模型来源筛选结果执行状态
候选人 A100 分规则命中通过已打招呼
候选人 B95 分轻模型通过已打招呼
候选人 C72 分重模型待复核交回人工
扫描推荐列表 → 读简历 → 判断 → 符合才触达
已有会话持续检查

沟通闭环

开始持续检查
检查间隔300 秒
最多轮次3
每轮上限200
新候选人持续检查
新交互自动识别
未闭环继续推进
模型判断按需调用
候选人当前状态材料处理结果下一步
已有会话 A闭环-通过简历已收材料已交人工判断
已有会话 B需复核电话缺等待回复稍后检查
已有会话 C沟通中信息不足处理异常人工接管
检查会话 → 看材料和状态 → 推进 → 异常交回人工
一条接住“找人”,一条接住“跟进”。 共用同一套画像,但分开运行。

从“能跑”到“能用”,我改了接近 200 次

截至 2026 年 9 月,项目已经留下 接近 200 次迭代。每次只解决一个真实问题。

第一步

先读得到

验证登录、候选人列表和简历详情能不能被稳定读取。

留下:可靠读取
第二步

再判得准

把 JD 变成岗位画像,让不同链路使用同一把尺子。

留下:统一判断
第三步

做成工作台

补齐任务、历史、恢复和风险提醒,不再是一段一次性脚本。

留下:可用产品
第四步

稳定地快

减少重复读取和无效等待,中断以后也能接着运行。

留下:持续运行

性能优化:同样处理 50 人,系统跑快了多少?

自动寻访|推荐候选人

早期版本37分56秒
优化后5分59秒
系统运行耗时下降 84.2%

沟通闭环|已有会话

早期版本25分07秒
优化后13分18秒
系统运行耗时下降 47.0%
这是系统版本之间的运行对比,不代表招聘岗位整体提效。

任务跑出结果,费用也能控制住

30 人一次寻访样本
9 人完成触达
3 份沟通闭环获得简历

该样本:Flash 初筛 19 次 · Pro 复核 1 次 · 约 4 万 tokens

约 3 元

另一次 500 人自动寻访任务的全部运行费用仅模型费用,无额外平台成本;与上方 30 人样本分开统计。

模型选得合适,比每一步都用最强模型更重要。

现在,我不用再一直盯着 BOSS 直聘

纯人工时

人要一直守在平台上

3—5 个常态岗位
8—10 个忙时岗位

一个岗位至少半天
重点岗位可能需要 2 天

现在

两条任务持续运行

自动寻访 沟通闭环

出现异常,才停下来交给我。

它减少的,是我几乎所有耗在 BOSS 直聘上的持续操作时间。
02

再走进别人的业务

达人自动寻访

先听懂媒介怎么做,再决定 AI 做什么

第二个问题:看了很多达人,能建联的却很少

一天的工作量

正常状态 约 120 人

7 个项目
提报至少 35 人

工作已经很饱和
极限状态 约 230 人

14 个项目
提报约 70 人

通常需要加班

真正难的,不是搜索,而是把客户需求讲清楚

客户给的通常是一段复杂描述,不是一组可以直接勾选的平台字段。

虚构客户需求,供讲解
“推广轻食。要真人出镜,受众以年轻女性为主。最好带过同类产品,表达自然。带货等级和 GMV 达标,报价在预算内,合作前也要核查内容风险。”

创作者画像

真人出镜、粉丝量

内容匹配

轻食经验、表达自然

受众匹配

年轻女性、消费人群

商业匹配

带货等级、月结 GMV

合作约束

报价预算,留待媒介核验

风险管控

内容风险,保留核查要求

如果业务判断没有说清楚,AI 只会更快地做错。

画像整理好,再决定怎么执行

六大画像回答“客户要什么”;执行规则回答“怎么筛、怎么排、哪些留给人”。

客户明确要求

必选项

带货等级、真人出镜、性别、带货类目、月结 GMV、粉丝数量。

没满足,就不进入候选
符合会更加分

加分项

同类竞品经验、带货风格、八大人群、观众年龄等。

用于排序,不冒充硬条件
平台没有可靠字段

人工核验

表达是否自然、调性是否合适,以及需要结合内容判断的要求。

保留给媒介做最终判断

产品界面:把客户需求变成具体执行策略

达人自动寻访 · 策略审核真实流程线框示意 · 虚构需求

客户原话

“推广轻食。
要真人出镜,年轻女性受众。
最好带过同类产品,表达自然。
等级和 GMV 达标,报价在预算内,注意内容风险。”

整理成六大画像

创作者画像

真人出镜

内容匹配

同类经验、自然表达

受众匹配

年轻女性为主

商业匹配

等级、GMV 要求

合作约束

报价预算

风险管控

内容风险要求

生成执行策略

筛选 · 按可用字段设等级、GMV 条件;具体门槛待确认
排序 · 同类经验、受众匹配作为评分依据
核验 · 出镜、表达、预算和风险,缺少证据不硬判
修改 · 媒介检查条件、分值与待核验项
客户原话 → 六大画像 → 执行策略 → 媒介确认确认后,再开始寻访
不是让 AI 猜客户想要谁,而是让它按确认过的策略去找。

产品界面:先看高匹配,再获取微信

产品界面|数据为示意

候选池

按匹配度排序,跨页、跨批次按达人 UID 归并

按匹配度
当前轮次 必选 + 加分 已处理 1 页 候选 5 位
达人匹配信息来源
示意达人 A01demo-a01匹配 92 分|轻食P1
示意达人 A02demo-a02匹配 88 分|健身P1
示意达人 A03demo-a03匹配 83 分|营养P1
示意达人 A04demo-a04匹配 76 分|家庭P1
示意达人 A05demo-a05匹配 71 分|轻食P1

不是抄一份名单,
而是从高匹配开始看。

  • 01系统自动筛选精选联盟达人。
  • 02按匹配度从高到低排列。
  • 03符合要求,进入详情获取微信。
最后打开详情,获取达人微信。

同样看 100 个达人,预计能留下更多微信

估算对比,待试用验证;不是已完成的实测结果。

筛选 100 个达人人工工具
可联系12—18 人20—30 人
获取微信5—6 人10 人以上
所需时间约 2 小时
媒介操作时间
约 30 分钟
工具运行时间
工具在筛选,媒介可以继续跟进其他达人。
建联、报价和撮合仍由媒介完成。
03

从招聘出发,看见新的可能

两个项目,改变了我参与业务的方式。

经验没有清零,能力开始延伸

HR 的积累

听懂需求,问清标准

协调沟通,
做出判断。

AI Builder 的实践

把想法做出来

把经验变成
可执行的方法。

FDE 的方向

走进更多业务

参与实现,
持续验证。

你的过往经验,可以成为新实践的起点。
服务业务的方式变了,自身发展的可能性也更多了。