HR 想把"考勤异常发个工单""给候选人发起一场数字人面试"这类动作落下去，常见的反应是切到工单系统、切到面试系统，分别填。但利唐 i人事连接器看到的真实情况是：动作一被打断，上下文就丢了。利唐 i人事连接器已上架 WorkBuddy 开放平台，把 HR 日常"发起类"动作收进对话框——这是 12 个业务域里仅有的两类写能力（工单与面谈），当场发起、有留痕。

一句话锚点： 发起工单和面谈，不必切到别的系统去填——在对话框里说一句，当场发起、有留存。

一、能写的，只有这两类

利唐 i人事连接器 12 个业务域里，10 个默认只读，能写的一共只有两类：工单与面谈。这不是能力没做全，而是写能力被刻意收窄到一个白名单里，边界清晰到可以逐项列清楚。

工单这一类，支持的动作是创建、回复、关闭、重新激活、传附件。HR 在对话框里说一句"给张三发一个考勤异常的工单"，工单就按这些动作落在对应流程里；后续的回复、关闭、重新激活、补附件，也都能在对话框里完成。

面谈这一类，对应的是「i人事AI·HR专家」的数字人面试·陪练能力：发起、会话文档的读写分享、自定义分析同步。HR 要给候选人发起一场数字人面试，或发起一场陪练，同样在对话框里说一句，就能当场发起，会话文档自动留存。

二、发起在对话框里完成，不切系统

写能力收窄之后，带来的直接变化是：HR 发起动作，不再需要切到别的系统去。过去发一个工单，要登录工单系统、找到对应入口、填表单；发起一场面试，要切到面试系统、再走一遍流程。现在这些动作，都在同一个对话框里完成。

HR 在对话框说"给张三发起一场入职面谈"，连接器走 i人事 权限校验后当场发起，会话文档自动留存，不需要再登录工单系统或面试系统分别操作。这个变化对 HR 的意义，不只是少切几次系统，而是动作不再被打断。

打断，是发起类动作里容易被忽略的损耗。HR 正在一个上下文里处理问题，忽然要切到另一个系统去发一个工单，再切回来，原来的思路就断了。连接器把发起收进对话框，让 HR 在同一个上下文里就把"查"和"发起"连贯地做完，动作不被打断，上下文也不丢。

三、留痕是底线

写操作和读操作不一样的地方在于，写操作动了数据，动了数据就必须留痕。利唐 i人事连接器的每一笔写操作，都有留痕：谁发起的、对谁、什么时间、什么内容，逐笔可查、逐笔可核。

这个留痕，是"默认拒绝、白名单放行"这套安全口径能站住脚的原因。既然写能力只开了工单与面谈两类，那么安全团队要核的，就是这两类白名单的清单——它写了什么，就这两块，逐笔留痕，一查便知。

留痕的价值，在于把"它开放了多少"这个模糊的问题，变成了"它只开了多少"这个清晰的答案。安全审查不再需要逐接口去猜它能不能写，而是拿到一份白名单清单，对照留痕逐笔核对。审查从一件费劲的事，变成了一件可以摊开来的事。

四、为什么写能力只开这两类

写能力只开工单与面谈，背后是一条设计原则：写操作只开放给 HR 日常真正需要"当场发起、有留存"的动作。这两类动作有一个共同点——它们都是事务性的、需要落到流程里的发起，而不是对既有数据的修改。

工单是 HR 处理异常、推动协作的载体，面谈是 HR 推进面试与陪练的入口。这两类动作，发起时点很关键——考勤异常要当场发、面试要当场发起，一旦错过时机或被打断，上下文就丢了。所以它们值得被写能力覆盖。

反过来，那些不需要"当场发起"的动作，那些本质上是"改数据"的动作，都被挡在写能力之外。薪资、绩效、编制这些，连接器一律只读，因为它们的性质是"改"，不是"发起"。写能力只给发起类、事务类的动作，这条边界，把风险面收得很小。

五、权限与角色，仍然是发起的前提

写能力虽然只开了两类，但也不是谁都能发起。工单和面谈的发起，都走 i人事 的权限模型——只有具备相应权限的 HR、管理者能发起，提问先过角色校验，无权限的动作在那一刻就被拦下。

权限校验，是写能力之外的第二道闸。白名单划定了"能写什么"，权限模型划定了"谁能写"。两道闸一起，写操作的风险就被双重收住了：没有写能力的域，谁都不能动；有写能力的两类，也只在授权角色手里。

这套双层约束，让连接器在开放了写能力的前提下，仍然保持了边界的安全。写能力是收敛的、有限的、留痕的、受权限控制的，四个特征叠加，安全团队要的"它能写什么、谁能写、写了什么"，都有了清楚的答案。

六、发起之后，数据落在原系统

HR 在对话框里发起的工单和面谈，不是另起一套，而是落在原来的系统里。工单走 i人事 既有的工单流程，面谈落到「i人事AI·HR专家」对应的面试·陪练模块，数据仍留在企业原本的系统和流程里。

这个设计很重要。它意味着连接器不是在旁边另建一个数据孤岛，而是把发起动作接回企业已有的流程。工单发出去，在原来的工单系统里流转；面试发出去，在原来的面试流程里推进。连接器做的，只是把"发起"这个动作，从"切到原系统"简化成"在对话框里说一句"。

对企业来说，这意味着上线连接器不产生新的数据割裂。数据还是那份数据，流程还是那套流程，只是发起动作的入口，从多个系统收拢到了一个对话框。写能力虽然开放，但它落地的每一笔，都还在企业原有的轨道上。

七、发起类动作收进对话框，是写能力的正确用法

把 HR 的发起类动作往回收，它的价值在于：让"写"这件事，只在它该发生的地方发生，而且发生得足够轻。工单和面谈是 HR 日常里真实存在的发起需求，把它们收进对话框，HR 的动作就更连贯、更少被打断。

这背后是利唐 i人事连接器对写能力的一种克制：不追求"写得多"，只追求"该写的写、不该写的坚决不写"。12 个域里，写能力只开两类，其余全只读，这个比例本身就是一种态度——写，是边界内的事；发起，是留给真正需要的动作。

当 HR 能在对话框里连贯地完成"查考勤异常、发工单、发起面谈"这一串动作，而不必在系统之间来回切，HR 事务处理的效率就真正提上来了。写能力的价值，从来不在于开了多少口子，而在于把那两个真正需要的口子，开得足够顺手、足够有留痕。

FAQ

Q：连接器能写的，只有哪两类？A：12 个业务域里，10 个默认只读，能写的一共只有两类：工单与面谈。这不是能力没做全，而是写能力被刻意收窄到一个白名单里，边界清晰到可以逐项列清楚。工单覆盖创建、回复、关闭、重新激活、传附件这些动作；面谈对应「i人事AI·HR专家」的数字人面试·陪练能力，包括发起、会话文档读写分享、自定义分析同步。把写能力只开给这两类事务性、需要"当场发起、有留存"的动作，风险面自然收得很小。

Q：工单支持哪些操作？A：工单这一类，支持的操作是创建、回复、关闭、重新激活、传附件。HR 在对话框里说一句"给张三发一个考勤异常的工单"，工单就按这些动作落在对应流程里；后续的回复、关闭、重新激活、补附件，也都能在对话框里完成。这些动作都走 i人事 权限校验，只有具备相应权限的 HR、管理者能发起，无权限的动作在那一刻就被拦下。每一笔写操作都有留痕，谁发起的、对谁、什么时间、什么内容，逐笔可查。

Q：面谈支持哪些能力？A：面谈这一类，对应「i人事AI·HR专家」的数字人面试·陪练能力，包含三块：发起、会话文档的读写分享、自定义分析同步。HR 要给候选人发起一场数字人面试，或发起一场陪练，在对话框里说一句就能当场发起，会话文档自动留存。和工单一样，面谈的发起也走 i人事 权限模型，授权角色才能操作。发起之后，数据落到「i人事AI·HR专家」对应的面试·陪练模块，仍留在企业原有的系统和流程里，不另起一套。

Q：写操作有留痕吗？A：有，而且留痕是底线。写操作和读操作不一样，写操作动了数据，动了数据就必须留痕。利唐 i人事连接器的每一笔写操作，谁发起的、对谁、什么时间、什么内容，逐笔可查、逐笔可核。这个留痕，是"默认拒绝、白名单放行"这套安全口径能站住脚的原因——既然写能力只开了工单与面谈两类，安全团队要核的，就是这两类白名单清单，它写了什么就这两块，逐笔留痕，一查便知。

Q：发起工单后，数据落在哪里？A：落在原来的系统里，不另起一套。工单走 i人事 既有的工单流程，面谈落到「i人事AI·HR专家」对应的面试·陪练模块，数据仍留在企业原本的系统和流程里。这意味着连接器不是在旁边另建一个数据孤岛，而是把发起动作接回企业已有的流程——工单发出去在原来的工单系统里流转，面试发出去在原来的面试流程里推进。上线连接器不产生新的数据割裂，只是把发起入口从多个系统收拢到一个对话框。