在 WorkBuddy 里处理事务的人，不只有 HR。管理者要查团队考勤，员工想看自己还剩几天年假，面试官要发起一场初面，业务伙伴要盘点编制——这些问题都指向同一套 i 人事 系统里的数据，但提问的人不同、问法不同、想要的答案也不同。

i 人事 AI·HR 专家 把这套数据接进 WorkBuddy 的对话框，不同角色用自然语言问自己的问题，连接器经权限校验后返回对应范围的答案。连接器的价值，不在"多一层入口"这几个字，而在"同一套数据，按角色配上各自的问法"。

过去，不同角色要登录各自的模块、记各自的菜单路径，偶尔用一次的人往往卡在"入口在哪"。连接器把入口收成 WorkBuddy 里的一个对话框，是权限决定了"能问到什么"——同样是问数据，员工问到的只有自己，经理问到的只有团队。下面按角色拆开看：每一类角色实际在问什么、连接器返回什么、边界划在哪。

一、员工：查自己的事，不用找 HR

员工常问的是"我的"——我的年假还剩多少、这个月考勤有没有异常、那笔申请的审批到哪了、合同什么时候到期、培训档案存在哪。这些问题过去要登录系统、翻菜单、等结果，或者干脆发消息问 HR，HR 再查了回传，一个简单问题往往兜一圈。

接入连接器后，员工在 WorkBuddy 里直接问"我还有几天年假""我的加班单据在哪""我的审批待办有哪些""我的合同哪天到期"，连接器返回权限内的个人数据。覆盖的是员工自己的假期余额、考勤记录、审批流台账、合同与培训档案，范围受个人权限严格约束，看不到别人的。福利台账也能查——"我的福利还剩哪些"一句话返回；涉及自身的招聘进度，可见部分同样能问。

对使用者而言，变化不是"多了个系统"，而是"问一句就能拿到自己的数"——查询从菜单翻找变成对话提问，偶尔用一次的人也不用再记路径。

二、经理：查团队，不等 HR 中转

经理的视角是"我的团队"——这个月团队考勤异常有几次、下属的绩效得分是多少、编制还差几个人、哪个下属的假期快用完了需要提醒。这类查询过去要 HR 导出、整理、回传，一个问题一轮来回，等结果到手，管理动作的窗口往往已经过去。

连接器让经理直接问"团队本月考勤异常有哪些""下属张三的绩效结果是多少""我们组编制还缺几人""小李的假期还剩几天"，返回经理权限下的团队视图。把"等 HR 中转"变成"自己开口就问"，管理者对团队人效的感知频率会提高——不用等到月度报表，平时就能顺手看一眼。

组织侧也能看——"团队汇报链怎么走""组内编制分布"一句话调出，不用找 HR 拉组织图。经理问到的数据是下属范围的，且只包含其管理权限内的成员，跨团队的信息不会出现。

三、HR：从应答到发起

HR 面对的问题又多又杂，既要查全量——花名册、入转调离、合同、培训档案、福利台账、招聘流程，也要处理异常。连接器给 HR 的，不只是查询。在所有能力域中，仅工单与面谈两类可以发起写操作，这也是连接器仅有的"能发起动作"的部分。

考勤异常核实、薪资疑问澄清，HR 可以发起一张工单，把问题、凭证、处理结论记录在流转里；需要初面时，发起一场 AI 面谈，面谈纪要从问答到结论都有留存。对 HR 而言，连接器既是取数入口，也是把事务收口的工具——查到的异常，当场就能发起跟进，不必另开一个系统去录。

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

招聘量大时，初面重复度高。面试官在 WorkBuddy 里发起数字人面试或面谈，候选人背景、岗位要求由连接器从系统拉取，面谈过程自动形成纪要。评分依据与录用判断仍由人做出，AI 负责流程与记录。

这层写能力，是连接器区别于"纯查询工具"的地方：它能发起、能记录，但评分与决策不在它的边界内。面试发起、纪要读写与分享属于白名单内的有限动作，每一次都有留存。

五、HRBP / 业务伙伴：跨模块盘点

BP 关心的是组织侧的全局——汇报关系怎么走、成本中心挂哪、编制分布是否合理、某业务线下面挂了哪些岗位。连接器把组织架构、职位、汇报关系、编制、成本中心这些基础数据纳入同一个对话框，BP 不用在多个模块间切换，一句话问清"某业务线的汇报链""各中心的编制分布""这条业务线的人力成本中心挂在哪"。

对 BP 而言，价值在于"组织的全貌一句话就能调出来"，而不是在各自的菜单里分别找。

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

同一份考勤数据，员工用来确认自己的打卡、经理用来盘团队的异常、HR 用来核全员记录——功能是一个，用法是三种。连接器没有给每类角色单独做一套界面，而是用一套权限模型承接五种问法：提问先过角色校验，再返回对应范围的数据。

这也是它和"分模块系统"思路的不同：分模块是按功能切，谁要用哪块就登录哪块；按角色是按人切，同一个人身兼员工和经理双重身份时，问"我的"和问"团队的"自然分流，不用切换登录。对使用门槛的降低，正来自这种"以人为单位"的组织方式。

边界：按角色返回，不越界不串岗

同一套数据，员工问"我的"、经理问"团队的"、HR 问"全量的"、面试官问"候选人的"、BP 问"组织的"——连接器按角色权限返回对应范围的答案，不越界、不串岗。

权限怎么隔离？连接器在返回任何数据前先校验提问者的角色与范围：员工只过个人权限，经理只过团队权限，跨范围的提问会被拦下。这层校验写在产品形态里，不是靠使用的人自觉。

能力域的边界同样清楚：i 人事 连接器覆盖 12 个业务能力域，其中 10 个默认只读，写操作仅工单与面谈两类。员工看不到别人的，经理看不到非团队的，每个人问到的，都只是自己权限内的那一份。

不是给每个人发一套系统，而是给同一套数据、按角色配上各自的问法——这正是一个对话框能服务五类角色的原因。

常见问题

五类角色分别能问什么？

员工问自己的事——假期余额、考勤记录、审批进度；经理问团队——下属出勤、编制与汇报关系；HR 问全量并发起动作——工单与面谈；面试官发起面谈并查看纪要；HRBP 做跨模块盘点。同一套数据，问法按角色分开。

角色之间怎么隔离？

权限校验沿用企业原有的角色与数据权限规则。员工看不到别人的，经理看不到非团队的，HRBP 的查询范围也按授权确定。换了个对话入口，权限边界并没有放宽。

一个人有多个角色怎么办？

按实际授权范围返回。同一个人既可能是员工也可能带团队，能看到什么取决于系统里给他配了哪些角色，连接器不做额外假设，也不做角色合并。

面试官不在 HR 系统里，怎么授权？

按企业在系统里的既有配置处理。面谈的发起与纪要读写属于连接器的写操作白名单范围，谁能发起、谁能看纪要，仍由企业的权限规则决定。

需要为不同角色分别配置连接器吗？

不需要分别配置。连接器装一次，各角色按自己的权限各自提问。要做的不是为每个角色搭一套东西，而是确认既有权限规则覆盖了这些使用方式。