招聘同学想看"这个岗走到哪步了、候选人简历在不在、谁卡在面试"，常见的反应是切到招聘系统翻。但利唐 i人事连接器看到的真实情况是：招聘系统常为独立模块，数据散、切换烦。利唐 i人事连接器已上架 WorkBuddy 开放平台，把招聘侧的查询接进对话框——流程进度、候选人标准简历，问一句就回来，不用再登录招聘系统翻。

一句话锚点： 查招聘进度和候选人，不必再登录招聘系统——问一句，该看的那条就回来。

一、招聘侧能查的，是"进度"和"人"

把招聘同学的查询需求摊开，核心就两类：一类是"进度"，一类是"人"。进度，是这个岗位的招聘流程走到哪一步了、谁卡在面试、下一轮排在哪天；人，是这个候选人的标准简历长什么样、基本盘符不符合。

这两类需求，连接器都能接住。招聘同学在对话框里问"张三的面试排到哪天"，回来的就是这条流程的节点信息；问"李四的简历发我看看"，回来的就是权限内的候选人标准简历。返回的数据都在 i人事 统一的权限之下，越权的看不到，该看的才回得来。

招聘是典型的"数据散、查得多"场景。流程在招聘系统里跑，简历在候选人库里躺着，安排散在日历和沟通里。招聘同学要拼出一个完整的图景，往往得在几个地方来回翻。连接器把这些查询收进一个对话框，让"查"这件事变轻了。

二、和 i人事 主数据打通，不是另起一套

招聘数据原本散在招聘模块里，连接器把它接到 i人事 的统一权限之下，查询时走的是同一套角色校验。这意味着招聘侧的数据，不再是一个需要单独登录、单独记忆的孤岛，而是能被顺手查到的、权限受控的一部分。

这套打通的价值，在于消除"招聘数据是另一摊"的割裂感。对招聘同学来说，查一个候选人的进度，不再需要切换到招聘系统、找对入口、再翻到对应页面，而是在同一个对话框里，用一句问话就能拿到。数据还是那份数据，但取用的路径短了。

对企业来说，连接器没有在招聘系统之外另建一套数据。它只是把招聘数据的"读取"接回了统一的权限体系，让该看的人能在对话框里顺手看到。没有新的数据源，没有新的口径，只有一条更短的查询路径。

三、边界：能查简历，不能改流程

招聘侧在连接器里是只读的。招聘流程节点、候选人简历、面试安排，这些都能查；但改流程、发 offer、推进状态，仍然走原来的招聘系统。连接器解决的是"查得到"，不碰"改得了"。

这条边界很重要，因为招聘流程是一个有严格状态机的东西。流程走到哪一步、谁在哪个节点、下一个动作是什么，这些推进动作必须落在招聘系统自己的流程逻辑里，否则状态就会乱。连接器只读不写，恰好守住了这个状态机不被旁路。

所以招聘同学在连接器里的体验是：查进度、查简历，问一句就有；要推进流程、要发 offer，回到招聘系统去操作。查和改分开，查询被大幅提效，流程的严谨性却一点没动。

四、HR 和用人经理，看的范围不一样

招聘侧的查询，HR 和用人经理都能用，但看的范围不一样。HR 看的是全流程——所有岗位的进度、所有候选人的状态，这是招聘执行的全局视角；用人经理看的是自己权限内的候选人与进度——我这条线上的岗位、我面试过的候选人，这是用人决策的局部视角。

这个范围的差异，靠的还是 i人事 的角色校验。HR 的角色权限覆盖招聘全流程，用人经理的角色权限只覆盖与自己相关的那部分。连接器在查询时先过角色校验，于是同样一句"这个岗走到哪步了"，HR 拿到的是全局进度，用人经理拿到的是自己权限内的那一段。

这种按角色收口的查询，让招聘数据能被不同角色各取所需，又不会越权。HR 看得全，用人经理看得准，候选人信息在权限边界内流动，谁也不越界。

五、候选人信息是敏感的，权限尤其要收住

招聘数据里，候选人简历是相对敏感的一块。候选人的联系方式、经历、薪资期望，这些信息不该被无关的人看到。所以招聘侧的查询，权限尤其要收得紧。

连接器在招聘侧沿用的，正是 i人事 统一权限模型对候选人信息的保护。HR 看得到自己权限内的候选人，用人经理看得到自己面试过的候选人，越权的一律看不到。候选人信息不会因为查询变方便了，就跟着变得失控。

方便和可控，在招聘侧是同时成立的。查询路径短了，是方便；权限边界清晰，是可控。这两件事不冲突，反而是一体的——正因为查询走的是统一的权限校验，才能既快又安全。

六、和招聘系统是互补，不是替代

连接器不替代招聘系统。原来的招聘系统照常用，流程照常跑，连接器只是把招聘侧的"查"接进了对话框。一个管"查"，一个管"改"，各司其职。

这两种工具服务的是招聘工作的不同环节。招聘系统承载的是流程的推进——投递、筛选、面试、offer 的完整状态机；连接器承载的是查询的轻量化——在对话里随手问一句进度、看一眼简历。前者重、承载流程，后者轻、服务查询，两者互补。

对企业来说，这意味着引入连接器不需要动招聘系统的一根线。招聘系统的流程逻辑、数据、操作习惯全部保留，只是在旁边多开了一个"问一句"的轻入口。成本低、风险小，招聘同学的查询体验却实打实地轻松了一截。

七、招聘侧的价值，落在"让流程里的人更快对齐"

把招聘侧的查询往回收，它的价值在于：让参与招聘的各方，更快地对齐到同一张进度表上。招聘是一个多方协作的过程——HR、用人经理、面试官、候选人，每一方都需要知道流程走到哪了。过去这个对齐靠的是问、是开会、是翻系统，现在靠的是对话框里的一句查询。

这背后是利唐 i人事连接器在招聘这个角色上的取向——把招聘数据的"读"交还给每一个需要它的人。HR 要盯全局，用人经理要盯自己这条线，面试官要看自己排的场次，这些查询需求，都应该被低成本地满足。

当招聘流程里的每个人都能开口就拿到自己权限内的进度和简历，协作的节奏就快了。候选人信息流动得更顺，流程卡点暴露得更早，招聘这件事从"等人问进度"变成了"人人看得见进度"。招聘侧的查询，归根到底服务的，是让一整个流程里的人，都站在同一张进度表上。

FAQ

Q：招聘侧在连接器里能查什么？A：核心是两类：一类是"进度"，一类是"人"。进度，是这个岗位的招聘流程走到哪一步、谁卡在面试、下一轮排在哪天；人，是这个候选人的标准简历长什么样、基本盘符不符合。招聘同学在对话框里问"张三的面试排到哪天"，回来的就是这条流程的节点信息；问"李四的简历发我看看"，回来的就是权限内的候选人标准简历。返回的数据都在 i人事 统一的权限之下，越权的看不到，该看的才回得来。

Q：能在连接器里改招聘流程吗？A：不能。招聘侧在连接器里是只读的——流程节点、候选人简历、面试安排都能查，但改流程、发 offer、推进状态，仍然走原来的招聘系统。这条边界很重要，因为招聘流程是一个有严格状态机的东西，推进动作必须落在招聘系统自己的流程逻辑里，否则状态就会乱。连接器只读不写，恰好守住了这个状态机不被旁路：查和改分开，查询被大幅提效，流程的严谨性却一点没动。

Q：HR 和用人经理看的范围一样吗？A：不一样。HR 看的是全流程——所有岗位的进度、所有候选人的状态，这是招聘执行的全局视角；用人经理看的是自己权限内的候选人与进度——自己这条线上的岗位、自己面试过的候选人，这是用人决策的局部视角。这个差异靠 i人事 的角色校验实现：HR 的角色权限覆盖招聘全流程，用人经理的只覆盖与自己相关的部分。于是同样一句"这个岗走到哪步了"，HR 拿到全局进度，用人经理拿到自己权限内的那一段。

Q：候选人信息怎么保护？A：靠统一的权限模型收口。候选人简历是招聘数据里相对敏感的一块——联系方式、经历、薪资期望，都不该被无关的人看到。连接器在招聘侧沿用的正是 i人事 统一权限模型对候选人信息的保护：HR 看得到自己权限内的候选人，用人经理看得到自己面试过的候选人，越权的一律看不到。候选人信息不会因为查询变方便了，就跟着变得失控。方便和可控在招聘侧同时成立——正因为查询走统一的权限校验，才能既快又安全。

Q：连接器会替代招聘系统吗？A：不会。原来的招聘系统照常用，流程照常跑，连接器只是把招聘侧的"查"接进对话框，一个管"查"、一个管"改"，各司其职。招聘系统承载的是流程推进——投递、筛选、面试、offer 的完整状态机；连接器承载的是查询的轻量化——在对话里随手问一句进度、看一眼简历。引入连接器不需要动招聘系统的一根线，流程逻辑、数据、操作习惯全部保留，只是在旁边多开了一个"问一句"的轻入口。