AIHR 的关键，不是让所有人问同一个答案，而是让不同角色问到自己该看的答案。

在企业里，很多 HR 问题并不是 HR 自己在问。

员工想知道自己还剩几天年假，经理想看团队考勤异常，面试官要发起一场初面，HRBP 要盘一条业务线的编制和成本中心。过去这些问题看似简单，却经常要在系统、表格和 HR 消息之间来回转。

这些问题来自同一套 i人事系统数据，但提问的人不同，能看的范围不同，想要的答案也不同。i人事AI·HR专家接入 WorkBuddy 后，把这件事放进了同一个对话框：先识别角色和权限，再返回对应范围内的答案。

同一套 HR 数据，按角色配上各自的问法。员工问“我的”，经理问“团队的”，HR 问“全量的”，面试官问“流程里的”，HRBP 问“组织侧的”。

一、员工自助：问“我的”，不用再找 HR

员工常问的是“我的”：我还有几天年假、这个月考勤有没有异常、那笔申请批到哪一步了、合同什么时候到期、培训档案存在哪。

这些问题过去要么登录系统翻菜单，要么发消息问 HR。HR 查完再回传，一个简单问题往往要兜一圈。

接入连接器后，员工在 WorkBuddy 里直接问“我还有几天年假”“我的加班单据在哪”“我的审批待办有哪些”“我的合同哪天到期”，返回的是自己权限内的那一份：假期余额、考勤记录、审批流台账、合同与培训档案。

福利台账也一样，“我的福利还剩哪些”一句话返回。员工看不到别人的，也查不到团队数据。

对使用者来说，变化不是“多了个系统”，而是“问一句就有答案”。偶尔用一次的人，也不用再记入口藏在哪一层菜单。

二、经理自助：问“团队的”，不等 HR 中转

经理关心的是团队日常管理：这个月团队考勤异常有几次、谁的假期快用完了、哪条审批卡住了、下属本月加班是否偏多。

这类查询过去大多要经过 HR 导出、整理、回传。一轮来回下来，管理动作的窗口往往已经过去。

连接器让经理直接问“团队本月考勤异常有哪些”“小李的假期还剩几天”“本周还有哪些审批待处理”“团队加班时长是否偏高”，返回经理权限下的团队视图。

管理者看团队人效的频率会自然提高：不必等到月度报表，平时就能顺手看一眼。看到下属本月加班偏多，及时安排调休；发现某条审批卡在环节上，直接发起工单跟进。

三、HR：从应答到发起

HR 的问题又多又杂，既要查全量数据，也要处理异常。花名册、入转调离、合同、培训档案、福利台账、招聘流程，都可能在一天里被反复问到。

连接器给 HR 的，不只是查询。在所有业务能力域中，只有工单与面谈两类可以发起写操作，这也是连接器仅有的“能发起动作”的部分。

考勤异常要核实、薪资有疑问要澄清，HR 可以当场发起一张工单，把问题、凭证、处理结论都记在流转里；需要初面时，也可以发起一场 AI 面谈，纪要从问答到结论都有留存。

换句话说，HR 查到的异常，不用切到另一个系统去录。查询和发起在同一个对话框里形成闭环。

这也是连接器区别于“纯查询工具”的地方：它能发起、能记录，但评分与决策不在它的边界内。

四、面试官：发起与记录，判断仍归人

招聘量大时，初面重复度高。面试官需要快速拿到候选人背景、岗位要求和招聘流程进度，也要把面谈过程沉淀下来。

面试官在 WorkBuddy 里发起数字人面试或面谈，候选人背景、岗位要求由连接器从系统拉取，面谈过程自动形成纪要，并按权限留存、查看和分享。

候选人标准简历、招聘流程进度同样在只读范围内，问一句就能拿到，不必再回招聘系统翻。

同一套数字人能力也可以用于面试官自己的演练：正式对话前，先用陪练把开场和追问过一遍，纪要一样沉淀下来。

这里的分工很清楚：AI 承接流程与记录，评分依据与录用判断由人做出。面试发起、纪要读写与分享属于白名单内的有限动作，每一次都有留存。

五、HRBP：从组织数据里看编制、岗位和成本中心

HRBP 关心的不是某一个人的请假或打卡，而是组织侧的全貌：汇报关系怎么走、成本中心挂在哪、编制分布是否合理、某条业务线下面有哪些岗位。

连接器把组织架构、职位、汇报关系、编制、成本中心这些基础数据收进同一个对话框，一句话问清“某业务线的汇报链”“各中心的编制分布”“这条业务线的人力成本中心挂在哪”。

在组织调整期，HRBP 还要盘某业务线下面挂的岗位数、关键岗位是否空缺、编制余量还有几个。这些数据过去要跨多个模块拼凑，现在可以按组织问题直接问。

对 HRBP 而言，价值不是少打开一个页面，而是组织判断可以更快落到数据上：问业务条的人力结构、问编制变化、问汇报线归口，都不离开 WorkBuddy 这个对话框。

六、为什么按角色组织，而不是按功能

同一份考勤数据，员工用来确认自己的打卡，经理用来盘团队异常，HR 用来核全员记录。功能是同一个，用法却是三种。

企业 AI 入口真正难的，不是回答问题，而是知道谁能问、能问到哪一层。

连接器没有给每类角色单独做一套界面，而是用一套权限模型承接五种问法：提问先过角色校验，再返回对应范围的数据。

这也是它和“分模块”思路的区别。分模块是按功能切，谁要用哪块就登录哪块；按角色是按人切，同一个人既是员工又带团队时，问“我的”和问“团队的”自然分流，不用切换登录。

边界同样清楚：i人事连接器覆盖 12 个业务能力域，其中 10 个默认只读，写操作仅工单与面谈两类。薪资只查台账与档案，不算薪、不发薪；绩效只查得分与评分明细，不执行考核动作。

员工看不到别人的，经理看不到非团队的，每个人问到的，都只是自己权限内的那一份。

七、一个对话入口的简化

企业里账号切换是常见的摩擦。同一名员工今天还是个人贡献者，明天就带了一个小组，过去要在“个人视图”和“团队视图”之间手动切换。

HR 自己查全量是一种操作，替员工问一句又是另一种操作。连接器按角色权限组织之后，这些切换在背后自动完成：身份不变，问法变，权限跟着变。

这层简化，是同一套 HR 数据可以被同一对话框承接的关键，也是 WorkBuddy 把它作为一个连接器去做的原因。

八、接进去之后，多了什么

i人事连接器已上架 WorkBuddy Connector UI。安装授权后，企业原有的 i人事系统保持不变：数据不迁移，模块不替换。

多出来的，是同一个对话框里的五种问法：员工问“我的”，经理问“团队的”，HR 查全量并在白名单内发起工单与面谈，面试官发起并记录，HRBP 一句话调出组织全貌。

这不是给 HR 多加一个入口，而是把原本分散在员工、经理、HR、面试官、HRBP 手里的 HR 问题，放回同一个受控的对话框里。

每个人仍然只看到自己该看的范围，但不必再为了一个简单问题，在系统、表格和消息之间来回切换。

要问 HR 问题的人本来就不只有 HR。连接器真正简化的，是不同角色使用同一套 HR 数据的方式。