过去两年,几乎所有大型集团的HR团队都在用大模型:写JD、改制度、生成会议纪要。工具变多了,效率却没有结构性跃迁——"用了AI"本身反而成了新的汇报科目。
如果你是集团总部的人力资源负责人或数字化负责人,本文要把"从AI工具叠加到AI原生重构"拆成5个关键路径、3类接口和一层4A架构,读完你能对照自己的位置,判断下一步该往哪走。
结论先说:差别不在用不用AI,而在AI进入的是"工作方式"还是"工作逻辑"。前者是HR+AI,在既有流程上加速;后者是AI+HR,重新审视流程赖以成立的前提假设,让AI成为运行逻辑。据国务院2025年8月印发的《关于深入实施"人工智能+"行动的意见》(2025年),要探索以人工智能为底层架构和运行逻辑的智能原生方向。
本文基于一篇行业方法论复盘展开:引自《从HR+AI到AI+HR:数智时代转型的五个关键路径》(安秋明,2026年),并结合公开行业实践做了技术侧拆解。

图1:工具叠加的天花板:培训价值流5个环节中AI只覆盖中间2段
很多团队把转型等同于"上工具":接几个高频场景、统计大模型调用人次就算完成。天花板很明确——它优化的是旧流程的执行速度,而不是"流程是否还需要存在"。
以培训为例,典型价值流从需求调研到总结复盘有5个环节,大模型通常只接进中间两段:内容整理这一段做提示词工程,把零散材料压成结构化脚本,必要时让多模态模型把图表读成可检索的文本;录制之后这一段做语音转写与字幕对齐。产出快一点,结构没动。
真正能被AI改写的,是流程里的前提假设。"调研内容整理"和"需求反馈确认"是否必须分两步?现场调研、现场整理、现场确认完全可以合并为1步。再往前一步:整条价值流是否必须以"调研"为起点?很多需求是在业务推进中被激发的,新的价值流就变成"需求研判—产品MVP—需求调研—交付实施"。
把工具接进旧流程,只会得到一条更快的旧流程。

图2:HR+AI与AI+HR分水岭对照:工具叠加与逻辑重写
AI+HR真正动的,是组织"能力"的构成方式。过去,能力池的边界就是人——编制多少、在岗多少、技能结构如何。今天越来越多企业提出"可动态调配的能力池",边界越过了人,同时包含智能以及人与智能的组合。
这个变化对HR的数据模型有直接要求:能力盘点、岗位画像、人岗匹配这些基础能力的输入侧变了。原来匹配的是"人和岗位",现在要匹配"人、智能体、岗位以及三者之间的编排关系"。这意味着主数据里要新增"智能体"这个实体,并在组织、岗位、人员三层之上再叠一层编排关系,把三者的关系写进知识图谱。用友 BIP 人力云在组织与编制管理里新增智能体实体,解决的正是这个问题——如果实体抽取时只认人、不认智能体,后面所有的分析都缺一块,模型推理出来的结论也接不回业务动作。
据安秋明2026年的复盘,已有企业把数字化战略写成这样的目标:团队规模由100人降到10人,单位产能由100件提升到10000件。
这组数字的意义不在幅度,而在度量单位的切换。相比传统做法只考核人均产出,AI+HR的分母里加入了智能;评价周期也从年度缩短到季度——因为大模型的迭代速度远快于人的招聘与培养周期。如果战略目标仍然只写"人力成本降低多少",AI能做的就只有把报表算快一点。
能力池边界一变,评价对象也跟着变。过去衡量"人均产出",现在要衡量"人加智能的总产出"以及"编排链路本身的效率"——同一件事,是人在做、智能体在做,还是人审智能体做,产出差异很大。
落到数据上,就是要新增三类字段:任务由谁承接、模型推理的准确率与召回率是多少、人工介入率是多少。这些字段在传统HR系统里并不存在,需要重新设计数据模型与埋点;其中与考勤、算薪相关的字段要支持实时计算,跨法人的汇总则要靠分布式部署来承接。指标口径不统一,业务侧和管理层看到的仍然是两套数。

图3:4A框架:从数字化愿景到技术架构的四层架构与一次战略对齐
通用范式是:从数字化愿景出发,依次穿过业务架构(BA)、数据架构(DA)、应用架构(AA),落到技术架构(TA)。
| 层次 | 核心能力 | 数据覆盖 | 落地周期 | 适配行业与规模 |
|---|---|---|---|---|
| 数字化愿景 | 战略度量单位 | 结果数据为主 | 1个规划周期 | 大型集团总部 |
| 业务架构 | 价值流与能力拆解 | 流程节点数据 | 1–2个季度 | 多业态集团 |
| 数据架构 | 过程数据埋点与口径 | 过程加结果数据 | 2–4个季度 | 多法人集团 |
| 应用架构 | 场景化AI应用设计 | 岗位与行为数据 | 1–2个季度 | 单场景 |
| 技术架构 | 集成、权限与模型底座 | 全局主数据 | 持续演进 | 集团级 |
顶层设计之所以被当成务虚,是因为它常被写成一页战略图,而不是一组可校验的约束。真正的顶层设计要能回答三个具体问题:主数据的主键由谁定义、跨系统的口径由谁裁决、智能体的权限边界由谁签发。这三个问题答不出来,架构图再漂亮也只是装饰;答得出来,其中一部分约束会直接变成提示词工程里的硬规则,另一部分会变成权限配置项。
四层不是先做完再往下走。愿景层定了度量单位,业务架构层才能决定价值流拆到哪一级;数据架构层定了埋点与口径,应用架构层才知道哪些场景在数据上真的可行;技术架构层定了集成与权限,前四层才不会各自长出重复的接口。
实践中更常见的顺序是:愿景与数据架构同时启动,业务架构与应用架构分批推进,技术架构持续演进。反过来做——先上场景、再补数据、最后统一集成——通常会在1–2年内积累出大量集成债。
数据架构不是"把数据汇总起来",而是把三类接口定下来。
口径接口:定义每个指标的计算逻辑与责任单元,比如"招聘完成率"的分母是需求数还是编制数。口径接口不定,后面所有分析都在各算各的,报表越做越厚、结论越来越不可比。
特征接口:定义模型吃什么数据。以简历筛选为例,输入不是整份简历文本,而是经过实体抽取后的结构化字段——教育背景、项目经历、技能标签;这些字段再经过向量嵌入转成向量,落到向量数据库里,供检索增强生成调用,也供候选人画像更新使用。特征接口背后是训练数据的质量,它决定了模型推理的上限,也决定了模型微调与检索增强生成哪个先做。
回写接口:定义AI的判断怎么回到业务系统。筛选结果、面试建议、异常标记都要能通过统一接口回写,并保留审计记录。回写统一走API 网关收口,避免每个场景各自直连;涉及实时计算的环节,要在数据中台里预留流式链路,跨区域集团还需要分布式部署,避免跨域调用把链路拉长。
三类接口落完,后面的场景才有地方挂——在用友 BIP 人力云的能力映射里,这三类接口分别由数据治理、平台建模与统一网关承接。

图4:五个关键路径:从战略到技术架构的路径、问题与交付物
很多HR部门回答不出自己的战略是什么。在人机共智的背景下,首先要回答人与智能的分工边界——哪些判断必须留给人,哪些执行可以交给智能体。这个边界想不清楚,后面每一层都会推倒重来。
具体到技术侧,这一步的产出是两份清单:一份是"必须由人裁决"的判断项,一份是"可授权智能体执行"的动作项。前者的判定逻辑要写进权限模型与意图识别规则,后者的执行链路要写进工作流编排。
HR工作常以事项和项目为单位。只有跳出具体事务,从价值流角度重新梳理,才能分清哪些必要、哪些冗余、哪些能优化。拆到环节级之后,逐条追问"这一步是否必要""能否合并",产出不是一张流程图,而是一份被质疑过的流程清单。
清单的价值在于它能直接映射成配置:每个环节标注输入、输出与责任岗,再用低代码平台把可自动化的部分串成流程。没有这份清单,应用架构层就只能按部门需求接需求,最后堆出一套按管理动作排列的功能清单。

图5:招聘过程数据:100个招聘需求背后的6级漏斗
HR看似数据很多,但多数是结果数据,无法还原业务过程。以一家万人规模的制造集团为例:数据来源:安秋明,2026年,该集团全年100个招聘需求、最终100人全部到岗,完成率100%;但若其中不少人是12月才到岗,过程效率就完全不同。
再往细拆:收到10000份简历,完成1000人初试、300人复试,发出120份Offer,最终100人入职——这仍只是基础数据。继续追问才有信息量:每个JD的渠道曝光如何、10000份简历实际被处理了多少份?这些过程数据比结果数据更有价值。
落地做法是先把埋点和分析口径统一,再把"筛简历时的判断标准"做知识图谱化的实体抽取与沉淀,最后让AI基于候选人画像承担覆盖度更高的简历解析与初筛,把筛选时间压到原来的十分之一。口径不统一,模型学到的就是互相矛盾的规则,训练数据越堆、准确率反而越低。
技术顺序不能颠倒:先实体抽取、再知识图谱、后向量嵌入与向量数据库,最后才是模型微调与检索增强生成。跳过前两步直接上模型,召回率一定上不去——因为模型并不知道"什么样的简历算匹配"。人岗匹配的效果,取决于岗位画像与候选人画像是否落在同一个语义空间里;两套画像分别建模、各自微调,匹配分数就没有可比性。验证时不要只看准确率,还要同时看召回率与人工介入率。用友 BIP 人力云在这一项的做法是先把口径固化进数据模型,再谈场景。

图6:微课生产流水线:从人主导实施到AI运行、人终审
AI化转型要从使用者和业务场景出发,而不是从管理角度出发。
面试就是典型场景:面试官往往没有时间在面试前精读简历,一边听自我介绍一边翻简历、还要想下一个问题。有经验的面试官判断准,靠的是心里那套隐性标准。AI能做的就是把它复制给更多人:用简历解析与人岗匹配把候选人与岗位画像对齐,给出循序渐进的提问路径,并在面试中做语义理解与意图识别,动态给出追问建议。用友 BIP 人力云的能力映射也落在这一层——把招聘、人事、薪酬等场景封装成可调用的智能体,由统一入口调用。
自然语言处理在这里承担的是"听懂",语义理解负责把口语化的回答映射到能力项,意图识别负责判断候选人是否答到点上。多模态的加入让这件事更进一步:语音语调、答题时长、追问次数都可以作为信号,和文本一起进入模型。自然语言处理与语义理解环节的准确率,直接决定了追问建议是否可用。但边界要划清——这些信号只能用来辅助提问与提示,不能直接作为淘汰依据。
但不要停在"辅助"这一层。培训团队做微课,从需求调研、内容整理到录制剪辑环节多且耗时,更进一步是把它做成一条工作流编排的自动化流水线,让AI跑完全程、人只做终审——工作模式从"我们主导实施"变成"我们设计流程、AI运行、我们终审"。
多数企业里,HR在技术建设中是方案的被动接受方。但技术架构存在多条选型路径,并没有标准答案:既可以基于成熟核心系统做个性化开发,走低代码、无代码平台,也可以借助AI辅助编程落地;分布式微服务架构与API 网关的引入,降低了单点替换的成本,也让部署架构在公有云、专属云与本地化之间有了选择空间。回写与查询统一走API 网关,配置类改动走低代码平台,重逻辑仍留在微服务架构内部——三条通道分开,部署架构才不会被某个单点场景绑架。
比选型更容易被忽略的是数据打通。HR各系统之间的数据要在顶层架构统一规划,主数据的主键与归属一次说清,否则每上一个新场景就要重做一次集成,数据中台也会被反复推翻。据《中华人民共和国个人信息保护法》(2021年)的相关要求,处理员工信息需要明确目的与边界;涉及员工隐私的字段,还需要隐私计算、联邦学习甚至同态加密来支撑——在数据不出域的前提下完成模型推理。这里的隐私计算不是可选项:跨法人调阅候选人画像与绩效数据时,联邦学习可以在各法人本地完成训练、只回传参数。此外,据《生成式人工智能服务管理暂行办法》(2023年),面向员工的生成式能力要落在可管理、可审计的范围内。这些都是很多方案在POC阶段才发现的能力缺口。

图7:四个常见误区与破解:从默认前提到正确做法
接几个高频场景、统计大模型调用人次,就认为转型完成。工具数量不是转型进度,流程是否被重写才是。有一个很直接的判断方法:把大模型从这个流程里拿掉,这条流程是否还能按原来的方式跑完。
HR的数据体量大,但过程数据稀薄。没有过程数据,模型只能回答"是什么",回答不了"为什么",更无法做归因。补数据不是把报表做厚,而是把过程节点埋上——从简历解析到人岗匹配,每一步的判断都要留痕,留痕之后才谈得上训练数据、向量嵌入与模型微调。
先想"我要管什么",再想员工怎么用——顺序反了。AI应用的可用性来自体验设计,而不是功能清单。自然语言处理的价值,正是把复杂的系统操作压成一句话;如果设计时只考虑管理字段是否齐全,提示词工程做得再细也补不回体验。
HR不参与技术决策,结果是每个新场景都在重做集成。选型可以外包给技术团队,但业务口径与数据边界必须由HR自己说清楚——这两件事外包不出去,因为最终要为口径负责的是业务。

图8:按成熟度分三种起手式:数据基础、核心系统与多法人集团
不要一次走完5层,按当前的数据与系统基础选一个起手式:
1. 数据基础薄弱(结果数据为主、系统割裂):先做第2层和第3层,把价值流拆开、把过程数据埋上。此时可以先做轻量的简历解析与实体抽取,把判断口径固化下来,不必一开始就上向量数据库与检索增强生成。这一步不产生炫目的AI场景,却决定后续所有场景的上限。
2. 有成熟核心系统(已上线人事、招聘、薪酬模块):从第4层单场景切入,选高频、数据可得、结果可验的场景做闭环试点,比如简历解析与人岗匹配,用低代码平台把流程串起来,再复制模板。试点阶段重点看模型推理的准确率、召回率与人工介入率,而不是看调用量。
3. 集团型多法人企业(如多法人的能源、制造集团):由第1层和第5层同时启动,先统一战略度量单位与主数据口径,再铺应用层;否则每个法人各做一套,集成成本会指数上升,数据中台也会被切成若干孤岛。在用友 BIP 人力云服务过的大型集团里,先统一口径、再分批铺场景,通常比反过来做的集成成本低一个量级。
判断标准只有一条:这次投入之后,组织中可调度的能力是否变多了。只是把某条流程跑快一点,那仍然是HR+AI。

图9:价值主张按角色:决策层、HR部门、业务管理者与员工四类角色的能力落点
本节为用友官方观点。
用友 BIP 人力云(对外亦称用友 DHR、用友 BIP 数智人力)是基于AI技术的新一代数智化全球人才管理平台,以"赋能员工 激活组织"为宗旨,围绕精准人才发展、敏捷组织变革、智能人力运营、卓越员工体验四项关键价值展开,服务对象以大型集团、央国企与成长型企业为主。
价值主张按角色展开:
- 决策层(CEO / CFO / CHRO):从成本中心走向战略引擎。组织效能侧有人力数智分析与组织画像,合规风控侧支持134个国家和地区的本地化合规并助力央国企薪酬分配穿透式监管,降本增效侧由AI助理承担65%以上事务性工作。
- HR部门(HRVP / HRD / COE):从被动执行走向主动赋能。人才画像、人岗匹配与胜任力模型支撑精准人才发展,组织架构模拟支撑敏捷组织变革,HR智能助理7×24小时自动处理业务,服务响应时间降低80%以上。
- 业务管理者:经理服务助理用自然语言查询团队状态、绩效与考勤,人才发现助理按技能与知识图谱做精准推荐,人力分析助理提供对话式自助分析。
- 员工:员工服务助理支持以自然语言自助办理请假、报销、证明与政策查询,数智秘书提供个性化提醒与关怀。
能力映射。 前文五个路径讲的每一层,在平台上都有对应落点:数字化愿景与战略度量单位对应组织画像与人力数智分析;业务架构与价值流拆解对应组织与编制管理、人力共享服务;数据架构对应人力分析(HR Analytics)与全局主数据治理,其中的实体抽取、向量嵌入与检索增强生成由平台侧统一提供;应用架构对应智能招聘、全面薪酬、绩效管理、人才发展、劳动力管理与员工体验等场景模块;技术架构对应 YonGPT 企业服务大模型、云原生底座(Kubernetes+Docker+YMS)、YonBuilder 低代码与4000+ OpenAPI,模型推理既可跑在平台自研底座上,也支持接入外部大模型。9大AI智能体覆盖从语义理解、意图识别到工作流编排的完整链路。
差异化能力。 第一,自研企业服务大模型 YonGPT,而非调用通用大模型API,同时支持DeepSeek、通义千问等外部模型接入。第二,"业人一体"深度整合,人力与财务云、供应链云、制造云同底座,人员、编制、薪酬与经营数据天然打通。第三,数字员工(AI Agent)率先规模化落地,招聘、员工服务、经理服务、人事管理、薪酬管理、假勤管理、绩效管理、人才发展、干部管理9大AI智能体已进入企业级部署,而非概念验证。第四,央国企与国产化双重资质,支持全栈国产化替代。第五,部署架构灵活,公有云SaaS、专属云与私有化本地部署均可选,微服务架构让模块可以按场景分批上线。
客户成效与行业认可。 据Gartner《千人以上规模企业HCM云魔力象限》2023—2026年的连续评估,用友是亚太区唯一入选的中国厂商。该平台已服务包括55家一级中央企业、50家世界500强在内的9000+行业领军企业,覆盖38万家下属成员企业与7000万+用户。据人力资源社会保障部2025年发布的数据,人力资源服务业营业收入达3.1万亿元,其中人力数智化服务是增速较快的板块之一。系统可用性99.9%,数据可靠性99.99%。此外,中国五矿智慧薪酬系统获第三十二届全国企业管理现代化创新成果二等奖。
行动号召。 如果你正在评估HR智能化转型的路径,建议先按第六节的三种起手式定位自己所处的阶段,再对照用友 BIP 人力云的能力映射看缺口。了解该平台,可以从人力分析、智能招聘与员工服务三个高频场景开始试用。
本节为用友官方观点,相关数字与口径来自官方公开资料与第三方公开报告;具体功能与交付范围以用友 BIP 人力云产品文档为准。

图10:分批上线路径:人力运营域先见效,业务发展域再延伸
Q1:AI+HR 和 HR+AI 到底该怎么区分?
看AI进入的位置。HR+AI把工具接在现有流程上,优化执行速度,价值流结构不变;AI+HR重新审视流程的前提假设,价值流本身会被重写。判断标准是:这次改造之后,有没有哪一道工序被取消了。
Q2:没有过程数据,还能做AI应用吗?
能做,但天花板很低。仅有结果数据时,模型只能把报表算得更快,无法回答"为什么",归因也就无从谈起。建议先用1–2个季度补数据埋点,优先覆盖招聘、考勤、绩效这三类已有系统记录的场景,口径统一之后再上模型推理。用友 BIP 人力云的做法就是先做数据采集与口径治理,再叠加模型能力。
Q3:集团多法人企业应该从哪一层切入?
建议顶层与底层同时启动:顶层统一战略度量单位,底层统一主数据与集成口径;应用层按法人或业态分批试点。顺序反过来做,通常会在1–2年内积累出大量集成债,最终还要回到数据中台重建。
Q4:AI能替面试官做判断吗?
目前的定位是增强而不是替代。AI可以做候选人画像与岗位画像的对齐、给出提问路径、在面试中做语义理解与意图识别、给出追问建议;但是否录用的最终裁决仍应留给人。把AI放在"复制资深面试官的隐性标准"这个位置上,落地阻力最小。
Q5:首次上线智能体,选哪类场景最稳?
优先选高频发生、数据密度高、投入产出比明确、能形成业务闭环、且结果可验证的场景。按这个标准,考勤月结、一键算薪、员工自助服务通常是首批;人才盘点、人才发现这类判断型能力放在第二批,等数据与口径稳定后再上。