用Gemini把IT工单积压变成派工计划

简而言之： 把ManageEngine ServiceDesk Plus里的未结工单导出来，把工单正文连同你的SLA时限、站点清单和备件状况一起给Gemini，让它先把"远程可解决"和"必须到场"分开，再把要到场的工作按路线聚成几趟出车。它几分钟就能排出这一周的计划。但它没法把一名工程师变到二线城市那个分支办公室的附近去。

每一个多站点IT运营团队都有同一个每周二重现的问题：四十来张未结工单，其中一部分需要有人到现场，而必须有一个人来决定这周谁去哪儿。这个决定是对着一张表格、凭着"哪几个站点离得近"的记忆、再加上"哪个SLA最快要爆"的粗略感觉做出来的。

它做得不好——不是因为这个人不上心，而是因为这是一个小型组合优化问题，却要由一个手上还压着六件别的事的人在时间压力下解掉。结果就是：工程师路过一个站点去另一个站点、两周之内为同一栋楼跑两趟，以及一张P2工单悄悄地拖老了，因为从头到尾都没人看出来它其实需要到场。

这件事很适合语言模型，因为难点大半在于读懂非结构化的工单正文、把它变成一个结构化的判断。而一如既往，真正难的那部分，不是排计划。

为什么现场出车总是拼得很差

三个原因，而且是结构性的，不是个人问题。

信号埋在散文里。 工单里没有任何一处会写"需要到场"。它写的是"打印机有摩擦异响"，或者"用户说3号会议室的网口不通"。必须有人逐条读、逐条推断。而在时间压力下，凡是看起来不那么紧急的，这个推断就被跳过了。

地理是靠记的，不是建模的。 排计划的人记得住那些大站点，但对"哪两个工业园区的单元其实只隔十分钟"就不那么可靠了——而浪费掉的路程恰恰累积在这里。

各个约束互相纠缠。 SLA时限、备件可得性、工程师技能、站点可进入时段、路途时间，这是五个约束；靠眼睛去优化，意味着只优化其中一个、其余的听天由命。而这一个几乎总是"最快要爆的那个SLA"——这正是为什么这套计划从结构上就是被动的。

该自动化的两个决定——需不需要到场，以及什么时候去

把它们分开。它们失败的方式不同，需要的输入也不同。

从工单正文里区分"远程可解决"和"必须到场"

ServiceDesk Plus可以导出未结工单清单——工单号、站点、分类、优先级、创建时间、SLA到期时间，以及描述和处理记录。真正要紧的是描述，而它恰恰是任何过滤器都无从下手的部分。

把工单正文给Gemini，要求它对每一张工单给出三种输出之一：远程可解决、需要到场、信息不足——外加一行理由和一个置信度。第三类才是让这套方法真正可用的东西。一个被逼着二选一的模型，会在含糊的那些工单上猜；而含糊的那些，恰恰是猜错要付出"白跑一趟"或"SLA爆掉"代价的地方。让它能说出"描述里没写这台设备能不能开机"，然后把这条派给一通电话，而不是派一辆车。

有两个改进值得花力气。给它你自己的例子——二十张你已经分好类、并写明理由的工单——因为你们这个资产盘子的习惯，比任何关于IT支持的通用知识都更要紧。以及，要求它标出那些正文暗示着更大底层问题的工单：同一层楼来了四张关于网络掉线的工单，那是一次到场加一台交换机，而不是四次到场。这种跨整个积压量的模式识别，一个逐张读工单的人类计划者是很少会做的。

排出计划——SLA时限、站点、备件、技能

现在换一组输入。第二个决定几乎不需要工单正文，而需要全部的运营上下文：这些要到场的工单分别属于哪些站点、站点之间的路途时间或距离、每张工单的SLA时限、所需备件是否有货以及在哪里、工程师的可用性与技能，还有站点的进入约束——比如某个数据中心要求提前48小时报备。

要求它给出一份建议排程：哪位工程师、按什么顺序去哪几个站点、哪一天、每一趟能关掉哪些工单——以及至关重要的一项：哪些工单没有被覆盖，以及为什么。这份未覆盖清单才是最有价值的产出。它把"我们进度落后了"变成"这四张工单本周无法满足，因为那个站点的可达范围内没有工程师"——这是一场带着证据的人手对话，而不是一种感觉。

要求它写出自己的假设，以及每一个决定是被哪个约束卡住的。"B站点排在周四，因为备件周三才到"是一份调度员可以去反驳的计划；一张光秃秃的时间表不是。

一个实际例子——一周的积压变成四趟出车

一个零售IT团队支持着一个都市圈加两个邻省的34家门店和两个配送中心，手上有三名现场工程师。周一的积压是46张未结工单。

分类这一轮把它们大致分成远程可解决、需要到场、信息不足三堆。远程那一堆比团队预想的要大，这是常见结果——好几张被描述成硬件故障的工单其实是配置问题，只是当初根本没有被好好分诊过。信息不足那一堆变成了服务台的一份外呼清单，其中约一半在电话里就解决了，直接从出车计划里消失。

聚类这一轮处理剩下的。九家门店需要到场；其中三家彼此相距二十分钟以内，而在上一周的计划里，它们是被分在三个不同的日子去的。模型提出四趟：两趟单日多店路线、一趟卡着备件到货的配送中心、以及一家路途较远、值得单独跑一趟的门店——因为那里有两张工单已经开了十一天。

未覆盖清单是两张工单，都在同一家偏远门店，都不紧急，都标明了理由：本周没有任何一条工程师路线能在不放弃一个更近的SLA的前提下抵达那个位置。这才是值得拿到的发现。它不是一次排班失败——它是一个覆盖事实，而且每隔几周就会在同一家门店重现一次。

计划者实际做的事是推翻其中大约五分之一。模型不知道某家店的店长在休假、某位工程师不该被派到之前有过投诉的站点、或者那个配送中心更希望上午十点前到访。花十分钟改一份草案，和花一小时从头排一份计划，是两件不同的事。

AI辅助派工计划 vs 现场服务管理软件 vs 派工合作伙伴

读懂非结构化工单正文、判断要不要到场 — AI辅助计划明显胜出。这恰恰是FSM工具压根不去做、而人做得不一致的那部分。
不引入新系统就拿到一份可用计划的速度 — AI辅助计划胜出。一次导出加一段提示词，对上一个采购周期。
路线优化与实时调度机制 — FSM软件胜出。专门做这件事的工具会做真正的优化、支持工程师移动端签到、并在日程变动时重排。
让计划真的被执行 — FSM软件胜出。躺在文档里的计划是一个建议；系统里的计划是一批带状态的已指派任务。
抵达一个你根本没人的站点 — 派工合作伙伴胜出，而且没有别的选项能竞争。排计划变不出一个你在那座城市并不存在的工程师。
合同化的到场保证 — 派工合作伙伴胜出。4小时紧急或次工作日到场的SLA是有人为之背书的承诺；而计划只是一个意图。

有用的读法是：AI辅助计划以很低的成本解决了分诊与拼车的问题，FSM软件解决执行的问题，而两者都不解决覆盖的问题。多数感觉自己有"排班问题"的团队，其实同时混着这三种问题，而搞清楚真正在花你钱的是哪一种，是值得的。

计划假设成立、而现实不成立的地方

四个假设，而它们都会例行破裂。

假设这一天不会变。 早上九点来一张P1，整份计划就得重写。计划真正的价值不在于它能扛住现实的冲击，而在于让重写变得便宜——知道哪两个任务受约束最少，才让你能在五分钟内重排。

假设工单描述的就是问题本身。 用户报告的是症状。一张"显示器不亮"最后查出来是扩展坞坏了，那是另一个备件、另一种技能，很可能还是第二次到场。

假设有人进得去。 站点进入是现场IT里最一贯被低估的约束——门禁审批、陪同人员、房东的货梯预约、一个换班时段不放访客进去的工厂车间。

假设备件在系统说的那个位置。 一份建立在"分部认为自己有货"之上的计划，是一份会在现场失败的计划，而工程师就站在那儿。对计划所依赖的那些备件，请核实可得性，而不是相信那个数字。

把这件事做对——工单数据、站点进入，以及什么时候该让IT介入

在你导出任何东西之前，有三点实务问题。

工单正文里全是个人数据。 描述和处理记录里带着用户姓名、联系电话、工位位置，偶尔还有业务数据的截图。只导出你需要的字段——工单号、站点、分类、优先级、日期、描述——并在文件流向任何地方之前把姓名和联系方式去掉或做假名化。分类依据的是症状，不是报障的人是谁。使用商业版或企业版，并核对你实际所在档位当前的数据处理与训练条款，而不是想当然。

站点信息本身是物理安防信息。 一份带着地址、可进入时段和具名联系人的客户站点清单，本身就是一份值得保护的文件。在你上传的文件里用站点代码，把对照表留在本地。

计划是容易的那一半。 让每一个站点的可达范围内都有一名带着对的技能、对的备件的工程师，并且在一个能满足你签下的SLA的日子里到场，才是难的那一半——而这正是现场IT派工所要解决的：按需工程师，以及覆盖100多个国家的4小时或次工作日合同化到场。我们的AI+支持服务和托管IT支持分列在它的两侧。Brocent自2007年在北京创立以来一直在亚洲提供托管IT服务，总部位于新加坡，并自2016年起设有香港办公室——包括那些自有覆盖恰好用尽的二线城市站点。同样"先把工单正文结构化"的套路，值得和从支持工单起草缺陷报告那篇对照着读。