薪酬和绩效是 HR 数据里敏感的两块，也是越界风险集中的两块。常见的反应是：要么不接，怕改错；要么全开放，风险大。但利唐 i人事连接器的做法是反着的——薪资只查不算不发，绩效只查不评，这两块在 12 个业务域里是严格的只读。利唐 i人事连接器已上架 WorkBuddy 开放平台，把"看得到但动不了"这条边界，直接接进对话框。

一句话锚点： 查薪资绩效，不必担心被改动——只读那一份，看到但不越界。

一、薪资：只查不算不发

薪资在连接器里的能力边界，可以用六个字说清：只查、不算、不发。连接器能查薪资台账、能查薪资档案，但算薪不在它的能力里，发薪也不在它的能力里。

这意味着什么？HR 和管理者能在权限内看到薪资数据——台账、档案，该看的看得到；但谁也不能通过连接器去改一个数、去触发一次算薪、去执行一次发薪。查，是放开的；算和发，是牢牢关在连接器之外的。

这个边界的意义在于，薪资数据可以被"用"起来，却不会被"动"到。过去很多企业不敢把薪资数据接进任何新工具，就是怕一个误操作改了数、发了错薪。连接器用"只查不算不发"把这种担心直接消解了——它压根没有算和发的能力，误操作无从发生。

二、绩效：只查不评

绩效在连接器里的边界，同样六个字：只查、不评。绩效结果、考核得分、评分明细，这些能查；但评绩效、改分数、动评分，不在能力里。

查和评，是两件性质完全不同的事。查，是看一个已经存在的结论——绩效结果是多少、各项得分是多少、明细是什么；评，是产生或修改这个结论的过程——谁打分、打多少、要不要改。连接器只开放前者，不碰后者。

所以绩效数据在连接器里，是一个"可以看、不能动"的状态。管理者能查到自己权限内的绩效结果，HR 能查到绩效明细，但没有一个人能通过连接器去改一个分数。看得到结论，动不了过程，这条边界对绩效这类高敏感数据来说，是必要的克制。

三、边界为什么这么收

薪资和绩效，是 HR 数据里越界风险集中的两块。钱和评价，直接关系到每个人的切身利益，也容易引发争议和纠纷。所以连接器对这两块，采取了严格的只读策略——不仅没有写能力，连"算""发""评"这类能力边界，也一并明确地排除在外。

这个"收"，不是能力做不到，而是刻意不做。从技术上讲，把算薪、发薪、评绩效接进来，都是能实现的事；但从边界上讲，这些能力不该出现在一个"连接器"的定位里。连接器要解决的是"数据怎么被顺手用起来"，而不是"数据怎么被直接改动"。

把薪资和绩效牢牢放在只读域，是利唐 i人事连接器对"什么是该做的、什么是不该做的"的一次明确表态。10 个域默认只读，薪资绩效这两块更是"看得到、碰不到写"。这条边界，是对数据负责，也是对使用它的人负责。

四、权限分层，看得到的人也是收着的

薪资绩效即便是只读，也不是所有人都能看。薪资按 i人事 权限模型收住——管理者看到的是团队维度的汇总，明细不开放；绩效结果按角色开放，个人评分明细同样有权限边界。

这个分层，让"只读"这件事有了更细的颗粒度。不是"能读就是全部能读"，而是"能读的，也只在权限范围内读"。管理者能看团队薪资的汇总，但看不到某个下属的薪资明细；HR 能看绩效结果，但也不是无差别地看每一个人的每一项。

权限分层加上只读，让薪资绩效这两块敏感数据被双重保护起来：一层挡住"改"，一层挡住"越权看"。能看的人，看得有限；不能看的人，一点都看不到。

五、给安全团队一个"放心"的答案

薪资绩效这类数据，安全团队的态度往往很谨慎。一个新工具要接进来，安全团队要问的是：它能不能改薪资、能不能动绩效、出了问题怎么办。连接器对这三个问题，都有清楚的答案。

能不能改薪资？不能，只查不算不发。能不能动绩效？不能，只查不评。出了问题怎么办？写能力压根不存在，误操作无从发生；查询走权限校验，越权查不到。这三个答案，让安全团队对薪资绩效的接入，能从"谨慎拒绝"转向"有条件放心"。

这背后是一条更普适的逻辑：敏感数据要接入新工具，靠的不是"小心使用"，而是"边界设计"。连接器把薪资绩效的边界在设计上就做死了——没有写入口，就没有改的风险。安全团队要审的，不再是一个"能不能被误操作"的担忧，而是一个"边界已经划死"的确认。

对企业来说，这份"放心"直接降低了接入决策的门槛。过去谈薪资绩效这类敏感数据接入，往往要在内部走很长的评估、拉很长的会，卡在一个"万一改了怎么办"的担忧上。连接器用边界设计把这个担忧前置解决了——不是靠承诺，而是靠"没有写入口"这个事实。评估的重心，从"能不能管住风险"变成了"确认边界已划死"，决策自然就快了。

六、看得到的数据，是真的，也是动不了的

在连接器里查到的薪资绩效数据，读的是 i人事 的现有数据，权限内的查询实时返回，和原系统里看到的一致。它是真的，不是估算，也不是另一套口径；同时它也是动不了的，只能看，不能改。

这两个性质放在一起，构成了薪资绩效数据在连接器里的完整画像：可信、可看、不可动。HR 查薪资台账，看到的是真实数据；管理者查绩效结果，看到的是真实数据；但这些真实数据，谁也不能在连接器里动一下。

对使用者来说，这个画像带来的是一种安心。数据是真的，所以可以放心用来做判断；数据是动不了的，所以不用担心看错了、改坏了。薪资绩效这种高敏感数据，恰恰需要这种"真实且不可动"的状态，才能被安全地放进日常使用里。

七、薪资绩效的边界，是连接器整体设计的一枚样本

把薪资绩效这两块单独拎出来看，它其实是利唐 i人事连接器整体设计取向的一枚样本：该查的查，不该动的坚决不动。12 个业务域里，10 个默认只读，薪资绩效更是把"只读"执行到了彻底的程度——连算、发、评这些能力边界，都被明确排除。

这个取向，贯穿连接器的每一个域。日常取数类的域，读放得宽，让数据被顺手用起来；发起类的域，写收得窄，只给工单与面谈；薪资绩效这类高敏感域，则是彻底的只读。宽窄之间，是一套清晰的边界逻辑。

当薪资绩效都能被"只查不算不发、只查不评"地接入对话框，说明连接器对数据边界的把控，已经到了可以让人放心的程度。敏感的数据，一样可以被用起来，只是它被用起来的方式，是"看得到、动不了"。这，正是 HR 数据该有的样子。

FAQ

Q：薪资在连接器里能做什么？A：六个字说清：只查、不算、不发。连接器能查薪资台账、能查薪资档案，但算薪不在它的能力里，发薪也不在它的能力里。这意味着 HR 和管理者能在权限内看到薪资数据，该看的看得到；但谁也不能通过连接器去改一个数、触发一次算薪、执行一次发薪。这个边界的意义在于，薪资数据可以被"用"起来，却不会被"动"到。过去企业不敢把薪资接进新工具，是怕误操作改了数、发了错薪，连接器用"只查不算不发"把这种担心直接消解。

Q：绩效在连接器里能做什么？A：同样六个字：只查、不评。绩效结果、考核得分、评分明细，这些能查；但评绩效、改分数、动评分，不在能力里。查和评是两件性质不同的事——查是看一个已经存在的结论，评是产生或修改这个结论的过程。连接器只开放前者，不碰后者。所以绩效数据在连接器里是"可以看、不能动"的状态：管理者能查到自己权限内的绩效结果，HR 能查到绩效明细，但没有一个人能通过连接器去改一个分数。

Q：为什么薪资绩效要严格只读？A：因为钱和评价直接关系到每个人的切身利益，容易引发争议和纠纷，是 HR 数据里越界风险集中的两块。所以连接器对这两块采取了严格的只读策略——不仅没有写能力，连"算""发""评"这类能力边界也一并排除在外。这个"收"不是做不到，而是刻意不做：连接器要解决的是"数据怎么被顺手用起来"，不是"数据怎么被直接改动"。把薪资绩效牢牢放在只读域，是对数据负责，也是对使用它的人负责。

Q：是不是所有人都能看薪资绩效？A：不是。薪资绩效即便是只读，也按权限分层收住。薪资按 i人事 权限模型——管理者看到的是团队维度的汇总，明细不开放；绩效结果按角色开放，个人评分明细同样有权限边界。这个分层让"只读"有了更细的颗粒度：不是"能读就是全部能读"，而是"能读的，也只在权限范围内读"。权限分层加上只读，让这两块敏感数据被双重保护——一层挡住"改"，一层挡住"越权看"。

Q：安全团队怎么放心接薪资绩效？A：靠边界设计，而不是靠"小心使用"。安全团队要问三个问题：能不能改薪资？不能，只查不算不发；能不能动绩效？不能，只查不评；出了问题怎么办？写能力压根不存在，误操作无从发生，查询走权限校验，越权查不到。连接器把薪资绩效的边界在设计上就做死了——没有写入口，就没有改的风险。安全团队要审的，从"能不能被误操作"的担忧，变成"边界已经划死"的确认，决策自然就快了。