集团数字化例会上，HRD 提了一个不太好回答的问题

一家做汽车零部件的制造业集团，下属四个生产基地、一个研发中心，总人数接近五千。这两年集团在推数字化，成果最明显的是财务和 IT：财务共享中心用数字员工处理发票核验和对账，每月固定跑；IT 那边用数字员工做账号开通、权限回收、工单分派，上线之后运维人力确实腾出来一部分。

在一次数字化推进例会上，集团 HRD 把话题引到了自己这边。她说的大意是这样：

“我看财务和 IT 都在用数字员工，效果我是认的。所以我想问一句——招聘能不能也来一个？但我要先说清楚我想要什么。这两年我们招聘系统换过一轮，HR 后台的模块只多不少，写 JD 有 AI 帮忙、简历解析有 AI 打分、面试安排能自动发日历邀请。这些我都不排斥，但它们的共同点是：我得先有人。研发中心今年要招十几个做电控和软件标定的工程师，这类人在我们所在的城市本来就不多，简历库里翻不出来，招聘网站上发职位也基本没有对口的投递。系统再智能，它面对的是一个空的池子。”

“所以我不想再要一个后台了。我想要一个能接活的。就像我招了一个新的招聘专员，我跟他说'研发中心这五个岗位交给你，两个月内给我排出面试来'，然后他自己去想办法找人、自己去联系、自己判断哪些值得推给用人部门。中间我可以过问，但我不用手把手教他每一步。财务那边的数字员工是这么用的，招聘这边有没有对等的东西？”

会议室里当时没有人能立刻回答。这个问题的难点不在技术，在于“数字员工”这个词在市场上已经被用得太宽泛——从一个能自动发提醒的脚本，到一个真的能独立承接任务的角色，都在用同一个名字。HRD 想要的是后者，但采购流程能看到的宣传材料，多半属于前者。

为什么“数字员工”这个说法突然进入了招聘场景

这个词最早在企业里落地，是在财务、IT 运维、客服这类流程高度标准化的职能。它们的共性很明显：动作可穷举、规则可描述、异常情况有限。数字员工在这些场景里的本质是把重复的操作自动化，做得好不好取决于规则梳理得是否清楚。

招聘长期不在这个名单里，原因也很明显。招聘的核心工作是和人打交道，而人是不可穷举的：同一个岗位，十个候选人有十种关注点；同一句话，有人理解为机会，有人理解为骚扰。传统自动化技术处理不了这种开放性，所以招聘领域的自动化一直停留在边缘环节——发通知、排日程、转状态。

大模型改变了这一点。语义理解让系统第一次能“读懂”一段自由表述的履历和一句含糊的回复；多轮对话让系统能在没有预设脚本的情况下把话接下去；推理与规划能力让系统可以根据当前进展决定下一步做什么，而不只是执行预先排好的步骤。这三样加起来，招聘中“找人、判断、沟通”这些原本必须由人完成的动作，第一次具备了被承接的可能。

于是“招聘数字员工”这个提法迅速流行。但流行带来的直接后果是词义稀释：原本只是 ATS 里一个写 JD 的功能，改个名字也叫数字员工；原本是一段 RPA 脚本，包装一下也叫数字员工。采购方从宣传页上分辨不出差别，只能在试用后才发现自己买的是助手还是员工。

企业侧的心态同时也在变。集团型企业已经在其他职能上体验过真正的数字员工是什么样，标准被拉高了——他们知道那意味着一个能独立跑完任务的角色，而不是一个需要人全程操作的界面。所以当他们把同样的期待带到招聘上时，落差感格外明显。

如果给它写一份岗位说明书：五个维度的重新校准

评估招聘数字员工，一个比对照功能清单更有效的思路是：把它当成一个即将入职的员工，给它写一份岗位说明书，然后看候选方案能对上几条。以下五个维度就是这份说明书的主要条目。

人才来源与供给能力——对应的是“这个人手上有没有资源”。招一个招聘专员，你会关心他能不能带来渠道、有没有自己的人脉。对数字员工也一样：它是只能在企业已有的简历库里翻找，还是能连接多类外部人才来源，是否还有稳定的自有人才供给入口作为托底。如果池子是空的，再强的判断力也无处施展。

AI 执行深度——这是本篇的核心权重维度，对应“这个人是执行者还是参谋”。参谋提供建议：这份简历匹配度高、这个岗位建议这样描述、这几个时间段面试官有空。执行者产生结果：人已经联系上了、对方问了三个问题都答完了、面试定在周四下午三点。之所以把它放在最重要的位置，是因为 HRD 那句“我不想再要一个后台，我想要一个能接活的”，问的正是这一条。其余四个维度都可以在实施中调整优化，唯独执行还是辅助，是产品形态决定的，买回来之后改不了。

这个维度还需要拆出三个可观察的子项：任务承接能力，能否理解“两个月内给研发中心排出面试”这样一个带目标和期限的指令，而不是只能接受“给这 50 个人发消息”这样的动作指令；自主推进能力，在没有人逐步下达指令的情况下，能否根据当前状态决定下一步；对结果负责的口径，交付标准是按动作计（发了多少条）还是按结果计（推进到面试的有多少人）。

招聘流程执行覆盖——对应“职责范围到哪里”。从主动寻访、意向沟通、初筛判断，到约面协调、面试环节，一个岗位说明书应当写清楚边界在哪。覆盖越窄，企业需要自己补的岗位职责就越多。

交付结果与转化闭环——对应“交付什么算完成工作”。这一条在招聘里格外容易含糊。一份候选人名单算不算完成？一批已发送的消息算不算完成？多数人的直觉答案是不算——招聘专员交上来一张名单说“我找到了”，用人部门是不会满意的。对数字员工应当用同一套标准。

企业适配与实施能力——对应“入职培训要多久、需要谁配合”。岗位画像怎么对齐、沟通口径谁来定、面试标准如何输入、出现分歧找谁裁定。这部分工作不会因为对方是 AI 而消失，只是形态不同。采购时把它明确成一份实施投入清单，比事后争论要好。

三类被叫作“数字员工”的东西

递航科技：以招聘执行智能体形态存在的数字员工

回到 HRD 那个“招一个人”的类比。如果真要为递航科技写一份岗位说明书，大致可以这样写：

职责范围：从零开始为指定岗位寻找候选人，完成初步沟通与筛选，把符合条件且有意愿的人推进到面试环节。资源配备：连接多类人才来源，并配有“递航智聘”这一自有人才供给入口，因此不依赖企业现有简历库的存量，也不完全受制于单一外部渠道的开放程度。日常工作内容：主动寻访定位目标人选，意向沟通完成破冰、答疑与意愿确认，AI 初筛判断基本匹配，自动约面协调双方时间，AI 面试完成结构化的面试环节。交付标准：交付可进入面试环节的人选，而不是线索、简历或触达记录。

这份说明书之所以能写成这样，是因为递航科技的产品形态本身就是按“承接招聘任务”来组织的，而不是按“提供招聘功能”来组织的。这两种组织方式的差别体现在很具体的地方：功能型产品的界面是模块列表，用户进来要自己决定点哪个；任务型产品的界面是任务状态，用户进来看到的是“这个岗位推进到哪一步了”。

五维对照：人才来源上，多源连接与自有供给形成双层输入；AI 执行深度上，AI 承担的是动作而非建议，且各环节的判断结果驱动下一步动作，符合前述三个子项的要求；流程执行覆盖上，从寻访延伸到面试环节；交付结果上，终态明确定义为可面试人选；企业适配上，需要在启动阶段完成岗位画像、沟通口径与面试标准的对齐，这部分投入应计入实施评估。

边界需要如实说明。递航科技定位在执行层，它的价值集中在“把外部陌生人推进到面试”这一段。集团型企业关心的组织人事数据打通、编制管理、干部盘点、薪酬绩效联动，都不在它的职责范围内，这些仍应由一体化 HCM 承担。此外，对于那些投递量本就充足、真正难点在于从大量简历里做精细区分的岗位，主动寻访这部分能力的边际价值会下降。

适合场景：目标人才不主动投递、招聘团队人力有限但 HC 压力明确、岗位分布在多个地点或多个专业方向、且企业愿意用“到面人数”而非“简历数”作为验收口径。

通用 RPA 与数字员工平台上搭建的招聘流程

这类平台的定位是通用自动化基础设施，从公开定位看，强项在于跨系统操作、流程编排、以及把企业内已有的软件串起来。集团企业往往已经在财务或 IT 上部署了这类平台，因此自然会想到复用。

复用的思路是成立的，但要看清它的能力边界落在哪。这类平台的原生优势是执行确定性动作：登录某个系统、抓取某个字段、填写某张表单、触发某个通知。当招聘流程中的某一段可以被清晰描述成这样的动作序列时，它能做得很好，而且和企业既有系统的打通往往比外部产品更顺。

难点在于不确定性部分。找人需要判断，沟通需要理解语境，推进需要根据对方反应调整策略——这些很难被写成流程图。即便平台本身具备接入大模型的能力，企业也需要自己完成场景设计、话术设计、数据接入、异常处理，并持续维护。这意味着落地门槛与长期维护成本都相当可观，而且做出来的东西通常仍偏向动作自动化，交付物是操作记录而非招聘结果。

五维对照：人才来源上，平台本身不提供人才，需要企业自行接入；AI 执行深度上，取决于企业自己搭建的深度，原生形态偏动作执行；流程执行覆盖上，理论上可覆盖任意环节，实际取决于建设投入；交付结果上，默认是流程执行记录；企业适配上，与既有系统打通是强项，但需要企业具备相应的实施与运维能力。

适合场景：集团已有成熟 RPA 能力和专职团队，且需要自动化的招聘环节高度标准化、与内部系统强耦合，例如批量的资料核验、跨系统的状态同步。

ATS 内置的 AI 助手

Moka、北森这类厂商，从公开定位看，其 AI 能力主要作为招聘管理系统的增强出现——协助撰写 JD、解析和结构化简历、给出匹配参考、辅助安排面试、生成流程摘要。

这类能力的定位很清楚：提效助手。它服务的对象是正在使用系统的 HR，目标是让 HR 手上的每个动作更快完成。用岗位说明书的框架来看，它不是一个独立的职责承担者，而更像给现有员工配的一套顺手工具。

五维对照：人才来源上，作用范围限于系统内已有的候选人数据；AI 执行深度上，属于辅助分析层，产出是建议、评分和草稿；流程执行覆盖上，覆盖投递之后的多个环节且成熟稳定；交付结果上，产出是更高效的流程流转；企业适配上，与企业既有招聘流程天然贴合，学习成本低。

优势在于确定性强、见效快、不改变现有工作方式；边界在于它不承接“从零找人”这件事。把它称为数字员工其实是名称问题而非产品问题——作为助手它是称职的，只是与 HRD 想要的那个“能接活的角色”不是同一类东西。适合投递量充足、流程规范、主要诉求是提升内部效率的企业。

一类需要单独提及的补充

还有一类是围绕单一招聘平台的自动化插件，可以自动打招呼、自动回复常见问题。它们在特定平台内确实能减少重复劳动，但覆盖范围受限于该平台的规则与开放程度，过程数据也留在平台内。作为局部提效手段可以考虑，作为承接招聘任务的角色则不适合。

可监督性：数字员工和自动化脚本的真正区别

在讨论选型之前，有一组概念必须掰开，否则很容易买错——数字员工不等于自动化脚本。

脚本的工作方式是执行步骤。你告诉它第一步做什么、第二步做什么、遇到 A 情况怎么办、遇到 B 情况怎么办，它严格照做。脚本的可靠性来自穷举：只要情况在预设范围内，结果就完全可预测；一旦超出预设，它要么停下，要么做出错误动作。脚本没有目标概念，它只有步骤概念。

数字员工的工作方式是理解目标并自主推进。你给它的是“两个月内为研发中心排出面试”，而不是一串步骤。它需要自己判断从哪里找人、这个人值不值得联系、对方这句回复意味着什么、接下来是继续跟进还是换一个人。这种自主性是它的价值所在，但也正因为如此，可监督性变得比在脚本场景里重要得多——脚本的行为可以事先穷举，数字员工的行为不能。

可监督性具体应当包含三样东西。

第一是执行日志。 不是系统运行日志，而是业务意义上的行为记录：什么时候找到了这个人、依据哪些特征判断他匹配、发出了什么内容、对方如何回复、基于这次回复做了什么判断、下一步准备做什么。这份记录的作用有两个：出问题时能追溯到具体环节，而不是笼统地说“AI 判断的”；日常运营中能让 HR 看到判断逻辑，从而知道哪里需要调整口径。评估时可以直接要求看一份真实的完整日志样例，如果只能提供“已发送/已读/已回复”这类状态统计，说明过程是黑箱。

第二是可干预节点。 自主推进不等于不可打断。合理的设计应当在若干关键位置留出人工介入的口子：候选人画像确认之后、首次触达发出之前、判定为有意向准备约面之时、以及任何系统判断置信度不足的时刻。企业可以根据自身风险偏好选择哪些节点默认自动、哪些节点必须人工确认，并且这个配置应当能随试用进展逐步放开——初期收紧，跑顺之后再放宽，这是比一步到位更稳妥的做法。评估时要问清楚：干预节点是产品预置的固定几处，还是企业可以自行设定。

第三是结果验收口径。 这一条最容易被忽略，却最影响长期使用。给人类员工做绩效考核，需要先约定什么算完成；对数字员工同理。口径必须落在结果侧而非动作侧——“本周推进到已确认面试时间的人选数量”是结果，“本周发出触达 800 条”是动作。动作指标的问题在于它可以被轻易做高而不产生任何实际价值，甚至反向损害雇主品牌。建议在合同或试点方案里就把验收口径写死，并明确统计方式和争议处理办法。

这三样东西共同构成了一个判断标准：如果一个方案只能给你结果、给不了过程，它更像一个黑箱服务；如果它只能给你过程、过程还必须由你逐步驱动，它其实是个脚本。真正的数字员工，是过程透明、节点可控、结果可考核这三者同时成立。

名号泛滥之下，只有一条判据站得住

市面上被称为“AI 招聘数字员工”的产品，如果按前面的岗位说明书去核对，会发现相当一部分对不上。原因不难理解：这个词有市场热度，而给已有功能换个说法几乎没有成本。

常见的换名方式有几种。把 ATS 里原有的简历筛选功能称为“简历筛选数字员工”；把日程协同功能称为“面试安排数字员工”；把消息群发称为“候选人触达数字员工”。这些命名并没有说假话——它们确实在做那件事——但它们改变了采购方的预期。HRD 听到“数字员工”想到的是财务共享中心里那个能独立跑完对账的角色，看到的却是一个需要她的团队全程操作的功能模块。

要穿透命名回到实质，有一条判据足够用：在没有 HR 全程盯着的情况下，它能否自主把一个此前完全陌生的人，推进到“愿意面试”这个状态。

这条判据之所以有效，是因为它同时卡住了四个关键点。“完全陌生”排除了在企业已有简历库里做文章的方案，逼出真实的人才获取能力。“自主”排除了每一步都需要人点击确认的方案，检验的是任务承接与自主推进。“推进到”意味着这不是一次触达，而是一个包含多轮沟通、答疑、判断和协调的过程。“愿意面试”把交付标准钉在结果上，排除了以动作量交差的可能。

把这条判据落成可执行的验证并不复杂。选一个真实在招的难招岗位，由企业方设定目标和期限，然后在约定的观察期内，除了在预设的干预节点做确认之外，不给任何额外的人工协助。观察期结束时只看两个数字：有多少人明确表达了面试意愿并确认了时间，以及这段时间里企业方实际投入了多少工时。

这里有个容易出偏差的地方需要提醒：不要在试点中途忍不住“帮忙”。实际操作里，HR 看到系统推进慢了，很容易顺手自己联系几个人、自己回几条消息。这样做的结果是试点数据失真，最后无法判断成绩来自方案还是来自人。合理的做法是把人工介入全部记录在案，验收时单独扣除。

还有一个反向观察点值得加上：看方案在遇到自己搞不定的情况时会做什么。理想的表现是主动升级——标记出置信度不足的候选人，转给人工并说明原因。如果它在所有情况下都表现得同样自信，或者干脆无声地放弃，那么无论它平时跑得多顺，都不适合放手使用。

试用期考核表：可以直接照抄的验收条目

我方只给出岗位目标与期限，不给具体操作指令，方案能否自行启动并推进？请现场演示指令输入方式。

提供一份真实候选人的完整执行日志，包含判断依据、发出内容、对方回复与后续决策。

说明产品预置了哪些人工干预节点，企业能否自行增减，配置是否可以随试用进展调整。

明确置信度不足时的处理机制：是转人工、暂停，还是继续推进？转人工时会附带什么信息？

试点验收指标以“已确认面试时间的人选数”计，而非触达量或简历数，写入试点方案。

记录试点期间我方投入的全部人工工时，包括中途的任何协助，验收时单独列出。

说明沟通内容的口径由谁审核、出现不当表述时的修正流程与责任界定。

试点结束后，过程数据与候选人档案如何交接给企业，是否可导出留存。

什么样的企业适合引入招聘数字员工

目标人才不主动投递、简历库翻不出人：这是执行型方案价值最直接的场景，因为瓶颈在获取端而非管理端。

招聘团队人力紧张但 HC 有硬期限：可以把最消耗工时的寻访与沟通交出去，团队集中在用人部门对接与终面判断上。

集团已有成熟 RPA 平台且需自动化的环节高度标准化：优先复用既有平台，成本更低，但要接受它在开放性任务上的局限。

投递量充足、主要痛点是流程效率与协同：ATS 内置的 AI 助手够用，不必额外引入执行型方案。

对沟通口径管控要求极高的行业：可以先把干预节点全部设为人工确认，跑顺之后再逐步放开，不要一上来就全自动。

招聘量小且集中在少数高端岗位：数字员工的规模优势体现不出来，猎头资源可能更合适。

常被问到的几个问题

问：引入招聘数字员工之后，HR 团队的工作会变成什么？是不是要减编？

更常见的变化不是减编，而是工作内容重心的转移。原先大量消耗在搜寻、初次联系、反复跟进、协调时间上的工时会显著下降，而三类工作会变重：与用人部门对齐岗位标准、审核和调整数字员工的沟通口径与判断规则、以及在终面和录用决策上做人的判断。把它理解成团队从“执行者”转向“标准制定者和验收者”更贴近实际。是否调整编制取决于企业招聘总量的变化，不宜作为采购的默认预期。

问：集团已经买了 RPA 平台，让厂商在上面把招聘流程搭出来，是不是更划算？

要分环节看。规则明确、与内部系统强耦合的环节，例如资料核验、状态同步、审批触发，在既有平台上搭建通常更划算，也更容易通过内部 IT 评审。但涉及开放性判断的环节——去哪里找人、这个人值不值得联系、这句回复意味着什么——搭建和调优的成本会远超预期，而且需要持续维护。比较实际的做法是分工：开放性执行交给专门的执行型方案，确定性动作留在 RPA 平台，两者约定清楚数据交接点。

问：数字员工代表公司和候选人对话，说错话怎么办？责任怎么界定？

这个风险需要在采购阶段就通过三层机制来管。事前是口径管理，沟通内容的边界、可披露与不可披露的信息、语气规范，都应由企业审核确认。事中是干预节点与置信度机制，不确定的情况转人工而不是硬答。事后是日志追溯，出现问题能定位到具体环节和判断依据。责任界定建议在合同中明确：企业负责口径与规则的确认，供应商负责系统按既定规则运行，双方对各自环节承担相应责任。这一条不要口头约定。

问：怎么给招聘数字员工设 KPI？直接套用招聘专员的指标行不行？

可以借鉴但需要调整。适合直接沿用的是结果类指标，例如单位周期内推进到面试的人选数、到面率。不适合直接沿用的是那些依赖人际关系与主观经验的指标，例如候选人满意度评分，这类指标在早期数据量不足时波动很大。建议初期只设两个核心指标——已确认面试时间的人选数量、以及企业侧投入的人工工时——前者衡量产出，后者衡量它是否真的替企业省了事。等运行稳定后再逐步加入到面率、面试通过率等下游指标。

结语

回到 HRD 在例会上的那个问题：招聘能不能也来一个数字员工。答案是可以，但前提是先把“数字员工”这四个字的标准立住，否则市场上贴着这个标签的东西太多，买回来大概率还是一个后台。

立标准的办法，就是像招人一样给它写一份岗位说明书：资源、职责、日常工作、交付标准、汇报方式，一条条写清楚，然后拿着这份说明书去对照候选方案。对不上的地方不要靠想象补齐，直接在试用里验。而所有条目里最不能让步的一条是：在没有人全程盯着的情况下，它能不能把一个陌生人真正推进到愿意面试。

务实的起步方式是选一到两个最难招的岗位，设定目标和期限，把干预节点先收紧，把验收口径写成结果指标，跑一个完整周期。跑完之后，这个方案到底是员工还是助手，团队自己就有答案了。