IT 支持 / 技术支持
上班时东西坏了,你最先找到的那个人:把它重置、把它解释清楚,或者弄明白「你说的经过」和「实际的经过」不是一回事。
这不是失业概率。它把「岗位任务中有多少暴露于自动化」与「采用实际走到了哪一步」合成为一个值 —— 只用于在同一套口径下横向比较职业,除此之外不作他用。
覆盖面向内部最终用户的支持 —— 服务台、桌面运维、一线与二线。不覆盖基础设施工程与 SRE(本站另有页面),也不覆盖面向消费者的产品支持 —— 那里来电的是客户而不是同事,经济账也不同。在外包服务台里,工单量指标对这份工作的改变超过任何一件工具。
证据库里已有其他职业的已核实记录,但这个职业还一条都没有。在有之前,下面的分析是对任务结构与已知技术能力的推理 —— 就这个职业而言,它没有可追溯来源支撑。我们宁可直说,也不引用未经核实的东西。这里是空的,是我们覆盖上的缺口,不是关于这份工作的结论。
到底什么在变#
分析单位是任务,不是职位名称。职业不会被整体替代 —— 变的是它的任务构成。
这就是你做的吗?认一下,这一页会缩到只剩与你有关的那一份。
职位名只是一组恰好被打包买走的任务,而没有两个人手里的那一组是一样的。什么都不会被发送出去 —— 它只留在这个浏览器里。
你见过四百次的那张工单
正在自动化≈ 平台推断改密码、解锁账号、申请权限、打印机、VPN —— 那二十个问题构成了队列的大部分。
这是办公室里最清楚的一个自动化目标,而且在任何模型出现之前,它就已经被自助门户做掉了一半:问题窄、解法是一段已知的步骤,而且成败可被机器判定 —— 账号要么解开了,要么没有。最后这条性质正是让系统可以在没有人盯着的情况下重试的那条,也正是「动了的任务」与「没动的任务」之间的分水岭。
把容易的工单拿掉,留下的不是这份工作的缩小版,而是它更难的版本:剩下的是队列的长尾 —— 用户的描述是错的,而故障在两个系统之间的缝里。按工单量定编的团队,如果把量自动化了而编制照旧,就会得到「同样的人在做那个指标已经描述不了的工作」;而建立在「关单数」上的考核,会在工具落地的那一周开始衡量错误的东西。
弄清楚实际发生了什么
仍由人主导≈ 平台推断从一份笃定、善意、但在关键细节上是错的报告里,还原出真实的事件顺序。
这里的诊断输入不是那张工单,而是对那张工单的纠正 —— 问出那个问题,让用户说出他没提、因为觉得不相干的那个动作。一件拿到同一份书面报告的工具,继承的是同一个错误前提;而这个职业的全部本事,就是拒绝接受它。
这里的「由人主导」说的是「谁解得了」,不是「雇了几个人去解」。一个团队如果把容易的那一半自动化、并按那一半缩编,就会把难的那一半交给更少的人 —— 而这个职业的倦怠一直就在难的那一半里。任务活下来,和编制活下来,不是一回事。
走到工位去
仍由人主导≈ 平台推断物理的那一半:换硬件、理线、那间投不出画面的会议室、给新人装机。
没有人在自动化办公室里的换硬件,而原因是经济账而不是难度 —— 任何一栋楼里的量都远不足以养一台机器。真正减少了这项任务的东西根本不是自动化:远程办公和云服务拿掉的是那张工位,不是那个走过去的人。
这一半不会被自动化,正是让整个职业看起来比实际更安全的原因 —— 因为物理那一半本来就小,而且正因为与技术无关的原因在缩小。在把任何安慰读进去之前,先量一下你自己一周里的比例 —— 在多数机构里,它只占少数工时,而且还在下降。
哪些技术在起作用#
四类独立信号。它们刻意不做加总 —— 一个职业暴露于两种技术,不等于风险翻倍。
它是怎么走到这里的#
指数不是一个静态数字。这是自 ChatGPT 以来,每个能力检查点上它大致会落在哪里 —— 回溯重建,并且如实标注。
技术这一组里最陡的一条,而机制是全站最干净的:服务台队列里重复的那一半,是「问题窄、解法是已知步骤、成败可被机器判定」的任务 —— 账号要么解开了要么没有,于是系统可以在无人看管下重试。上行在生成式模型之前就开始了,因为自助门户早已拿走了密码那一半。它在长尾开始的地方走平:一份笃定、而且在关键细节上是错的用户描述,交给工具和交给人得到的是同一个错误前提 —— 而这个职业的全部本事就是拒绝它。这个高度要读成「容易的工单」;并且要注意这条曲线显示不了的东西:难的那一半被留给了一个「按已被自动化的工单量定编」的团队。
曲线平缓不是「安全」的预测。它只是在说:到目前为止,自动化触及了哪些任务 —— 这里动得最少的职业,约束都是物理的或监管的,而这两样都会变。
近期变化#
暂无已核实事件。
这一栏会随着监测流水线采集、去重、分级并关联到上面的任务而逐步填充。这里是空的,意味着我们没有核实到任何东西 —— 不意味着什么都没发生。
「没搜到新闻」不等于「安全」。
这对你意味着什么#
三十年来,这一直是进入技术工作的主要门之一,而它也是自动化机制最清楚地正对着的那一道门 —— 招新人的正是那些容易的工单。穿过去的路径形状没变,但留给你的时间变短了:尽快去做那些没人能写成脚本的工单,并让自己的名字出现在「关掉其余工单的那套工具」上 —— 因为「操作这套自动化」才是这份工作正在被拨款的那个版本。
你所在的机构会按工单量定编,然后把工单量自动化掉。有效的论点不是「这些单子很难」,而是「这个指标已经描述不了这份工作了」—— 而且必须在定编之前说,因为之后你要对抗的是一个已经很好看的数字。
你的选择#
四个方向,每个都写明真实约束和一个本周可验证的动作。继续做下去也是正当选择 —— 只要它是被选择的,而不是被默认的。
去拥有那套自动化,而不是和它比
总得有人决定「系统可以自己关掉哪些工单」以及「它不确定时怎么办」,而唯一知道答案的人,是那个做过这条队列的人。
那是另一份工作、另一个职位名;在很多机构里,它在一个你必须调岗进去、而不是升上去的团队里。
把上个月的工单分成两堆:解决与否可被机器判定的,和不能的。第一堆是路线图,第二堆是你的工作。
转到安全运营那一侧
在多数机构里,服务台是被针对得最多的入口 —— 所以你已经拥有安全团队要花几个月才能获得的那份上下文:这家公司「正常的请求」长什么样。
安全岗通常要求先有一张证书才给面试机会,而它的待命强度比服务台更重。
把这个月每一个让你觉得「不太对」的请求写下来,不管结果如何。如果这张单子不空,那种直觉正是隔壁团队在招的东西。
常见问题#
队列里重复的那一半,拥有办公室任务里最清楚的自动化机制:问题窄、解法是已知步骤,而且成败可被机器判定 —— 账号要么解开了要么没有,于是系统可以在无人看管下重试。长尾没有这个机制,因为它的起点是一份笃定、而且在关键细节上是错的用户描述。结果不是这份工作的缩小版,而是它更难的版本;而按工单量定编、又把量自动化掉的团队,通常会发现这个指标已经描述不了这份工作了。
不给日期。把上个月的工单分成两堆:机器能判断「修好没有」的,和只有人能判断的。第一堆是工具会拿走的,而两堆的比例就是你的暴露度 —— 你今天下午就能算出来,而且它比任何行业数字都有用,因为它讲的是你的队列,不是所有人的平均。
已经做掉了很大一部分,而值得注意的是这件事发生在任何模型出现之前 —— 密码自助已经是标配很多年了。这一点对正确理解当前这一波很要紧:容易的工单本来就已经在被拿走,而语言模型加上的是「处理那些用户没法按门户的分类描述清楚的问题」。方向和过去十年一样,变的是速度。
不会被自动化,这是对的 —— 没有人在造一台换笔记本的机器,而原因是量太小,不是难度。但它在工时里的占比小、而且在缩小;把它缩小的东西同样不是技术:远程办公和云服务拿掉的是那张工位,不是那个走过去的人。在把它当成一个计划之前,先量一下它在你自己一周里到底占多少。
方法与来源#
- 评估日期
- 2026-09-14
- 任务判断的依据构成
- 0 条有证据支撑 · 4 条平台推断 · 0 条证据不足
- 已核实事件
- 0