一个 HR 的日常：在 WorkBuddy 里写方案、对需求、推进事项，中途要一条数据——某位员工的加班单批了没、部门里谁的审批还压着、试用期到期的名单。标准动作是切出去：登录人事系统、按菜单一层层找、设筛选、导出，查完再切回来。数据都在系统里，但要用的时候，得专门走一遍取数流程。

变化已经在产品形态里了。WorkBuddy 平台提供连接器（Connector）能力，让 HR 系统的数据与事务接入 AI 工作台的同一个对话框。IDC 市场跟踪显示，到 2029 年近 40% 的 HCM SaaS 应用将由自主或高度智能化的 AI 系统主导——HR 系统把能力接进 AI 工作台，可以看作这条预测在供给端的注脚。

这层变化值得拆开看：它是什么、它怎么做、边界划在哪。

一、要解决的问题：数据在系统里，成本出在"用"的环节

这层变化要解决的问题，先看清楚。

HR 数据的痛点，多数不在"有没有系统"，而在用数据的环节：切出去查一次，登录、翻菜单、设筛选、导出、切回来，一个来回几分钟起步；标准报表覆盖不了的问题，要走报表配置甚至 IT 排期，一个"看看上个月加班情况"的需求可能等两周；考勤异常对应的薪资影响这类跨模块问题，要分别取数、手动核对。单次成本不大，乘以人数和频次，就成了 HR 与员工两头每天都在付的固定支出。

传统的开放路线解决的是"系统能被调"：开放 API、单点登录、字段同步，让别的应用来集成。这条路线成熟，但交互方式没有变——业务人员想查一个数，还是走系统菜单，或者提需求给 IT。API 是给开发者用的，不是给 HR 用的。

连接器换的是交互这一层。在 WorkBuddy 平台上，连接器（Connector）做的事是：在不替换企业现有系统的前提下，把已有系统接入同一个对话框，用自然语言统一查询、触发有限动作。数据不动、系统不动，动的是入口。

二、连接器在 WorkBuddy 上做什么

WorkBuddy 平台引入连接器（Connector）形态，目的是让企业已在用的 HR 系统不必改造、原样接入 AI 工作台。HR 用户在 WorkBuddy 里用自然语言提问，连接器经权限校验调出数据返回——访问路径本身没变，数据从系统菜单进到了对话框。

以运行于 WorkBuddy 平台的 i 人事 官方连接器「i 人事 AI·HR 专家」为例：它以 CLI 形式运行于平台之上，经 Connector UI 完成安装与授权，连接企业已经在使用的 i 人事 系统。系统原样不动，多出来的是一个能对话、能发起的入口。

三、i 人事 连接器：一句话问清，一句话发起

把能力分成两个动词看：问清，和发起。

一句话问清——11 个只读域。**权限校验之后，日常取数的高频问题直接问：

• 考勤与假期：考勤日报、加班单据与月报、调休额度、假期余额、打卡记录、排班；

• 人与组织：花名册、入转调离、合同、异动、培训档案；组织架构、职位、汇报关系、编制、成本中心；

• 流程与结果：审批流台账、待办与已办盘点；绩效结果总览、考核得分与评估人评分明细；薪资台账、薪资档案（只查，不算薪、不发薪）；福利台账与档案；招聘流程与候选人标准简历；以及主数据解析、选人等基础组件。

一句话发起——2 类写操作。**工单：创建、回复、关闭、重新激活、附件上传下载；面谈会话：数字人面试与陪练、发起面谈与会议、会话文档读写与分享。每一笔操作可追溯——工单从创建到关闭的每次流转、每份纪要的读写与分享，都有记录可查。

这套能力的用法，也不止 HR 一个角色：

• 员工查自己："我的加班单批了没""调休还剩多少"——不必事事找 HR 代查；

• 经理查团队："部门里谁的审批还压着""上季度团队考勤异常有几次"——不必等 HR 出报表；

• HR 管全景：跨模块的取数与核对收进一个入口，工单与面谈开口就能发起。

四、问得多，边界也要写得清

能力覆盖面广的 AI 工具，落地时往往先被问到的是安全：AI 能改什么？改了谁负责？

i 人事 连接器把这层边界写进了产品形态：13 个能力域中 11 个为只读查询，写操作仅工单与面谈会话两类，每笔操作可追溯。薪资仅支持权限校验后的只读查询——查台账、查档案，不算薪、不发薪；绩效仅查询考核得分与评分明细，不执行考核动作。

这种"默认只读、写操作白名单"的设计，对落地的影响是具体的：IT 与安全团队审查的，是一个边界预设好的连接层，而不是一批需要逐个评估、持续监控的开放接口。审查范围窄、评审周期短，上线阻力相应更小。安装与授权统一经 WorkBuddy 平台完成，谁能用、用到什么程度有统一的控制面，"谁查了什么、什么时候查的"全程可审计。

五、从问清到发起：AI 面谈的闭环

发起类能力里，AI 面谈是一条完整的链路：

**发起前，问清背景。**连接器先经权限校验调出该员工的考核得分与评估人评分明细，面谈人带着完整背景进入对话，不必现场翻系统。

**发起面谈。**数字人面试承接开场与标准化提问；同一套数字人也用于面试官自身的陪练演练，正式对话前先过一遍。

**沉淀纪要。**会话文档自动生成，可读写、可分享给相关管理者，全程留痕、可回看。

三个环节里，AI 负责流程与记录；评分依据与录用判断，始终由人做出。对招聘量大、初面重复度高的企业，面试官的时间可以集中到需要专业判断的复面环节。

六、哪些团队适合先接

• 已在用 i 人事、日常在 WorkBuddy 里协作的团队：数据在对话框里随问随答，事务开口就能发起；

• 取数高频、临时问题多的团队：制造企业的考勤与薪资核对、连锁门店的排班与调休盘点，都是"单次不重、频次极高"的典型场景；

• 对写权限敏感的团队：默认只读、白名单写入的边界设计，让安全评审的对象清晰可控。

结语

AI 工作台能否真正帮到 HR，决定于一件事：系统里的数据，怎么在用的环节被顺手取到。

i 人事 连接器的做法是：一句话问清 11 个只读域，一句话发起 2 类写操作；边界写在产品形态里，已有的系统原样保留。

常见问题

连接器运行在什么环境里？

以 CLI 形式运行于 WorkBuddy 平台，通过 Connector UI 完成安装与授权。安装授权与登录态都在平台层管理，企业不需要为它单独维护一套账号体系。

问一句话，查的是哪里的数据？

查的是企业已经在用的那套 HR 系统里的真实数据，不是模型生成的内容。自然语言负责把问题翻译成查询条件，取数由业务系统完成，返回的是系统里的字段值。

除了查询，连接器还能做什么？

还能发起有限动作，只有两类：一是工单——创建、回复、关闭、重新激活；二是面谈会话——数字人面试与陪练、发起面谈、纪要读写与分享。其余能力域均为只读。

权限是怎么校验的？

沿用企业在原系统里已经配置好的权限规则。谁能看什么、看到什么范围，由系统原有的角色与数据权限决定，连接器不另设一套授权逻辑。在对话框里问不到你在系统里看不到的东西。

哪些团队适合先接？

适合先接的是取数频次高、问题重复度高的团队：HR 的日常应答、管理者的团队盘点、员工的自助查询。共同特征是数据已经在系统里，卡点在"取一次很麻烦"，而不是系统功能不够。