过去两年，AI 这个词出现在了几乎所有软件厂商的产品路线图里，ITSM 系统也不例外。

每家 ITSM 厂商都在说自己的产品"接入了 AI"，但具体接入了什么、怎么用、解决了什么问题，说法五花八门，让人难以分辨哪些是真正有价值的能力，哪些是蹭热点的营销话术。

这篇文章不做产品评测，而是从实际的 IT 服务管理场景出发，梳理 AI 在 ITSM 系统里真正能产生价值的几个方向，以及它改变了哪些以前做不到的事情。

---

一、AI 在 ITSM 里不是万能的：先说它解决不了什么

在说 AI 能做什么之前，先说清楚它做不了什么，可以帮助大家建立更理性的预期。

AI 替代不了流程设计。 ITSM 系统的核心价值，在于把 IT 服务管理的各个流程规范化、自动化。这个流程设计本身，需要有人想清楚：事件管理的优先级怎么定，变更管理的审批节点是什么，SLA 的时限如何设置……这些是组织层面的决策，需要 IT 负责人、业务部门、管理层共同确认，AI 给不了答案。

AI 解决不了数据质量问题。 很多 ITSM 系统里的 AI 功能，依赖的是工单历史数据、CMDB 数据、知识库数据的质量。如果工单记录普遍是"已解决"三个字，知识库空空如也，CMDB 数据三个月没更新，AI 能做的事情就非常有限。数据质量是 AI 能力发挥的前提，不是 AI 能解决的问题。

AI 不能消除人的判断。 在 IT 服务管理里，很多决策需要人的专业判断和责任承担：这次变更风险是否可接受，这个 P1 事件的根因是什么，这个系统该不该报废……AI 可以提供参考信息和建议，但最终的决策和责任仍然在人。

明确了这些边界，再来看 AI 真正能贡献价值的地方。

---

二、工单分类和路由的智能化：从规则引擎到语义理解

传统的工单自动分类，依赖规则引擎：如果工单标题包含"密码"这个关键词，分类为"账号管理"；如果包含"网络"，分类为"网络问题"。这套逻辑对标准化的描述有效，但遇到用户描述不规范的工单（"我的东西打不开了""系统一直在转"），规则引擎就无能为力。

基于自然语言处理的 AI 分类，理解的是用户描述的语义，而不是关键词匹配。"我点了那个图标没有反应"和"应用无法启动"，在语义上是同一类问题，AI 可以把它们分到同一个类别，规则引擎做不到。

这个能力在几个场景下有明显价值：

提升分类准确率，减少误分配。 工单被错误分配到不对的团队，然后再转手，每一次转手都是时间的损耗。AI 分类的准确率比规则引擎高，误分配率下降，工单更快到达正确的处理团队。

支持多语言和非标准描述。 企业里用户的技术背景不同，描述问题的方式差异很大。AI 的语义理解能力可以处理这种差异，而规则引擎需要为每种描述方式单独配规则，维护成本极高。

优先级自动判断的准确性提升。 优先级判断不只看工单内容，还要看提单人的职级（CEO 提的单优先级可能更高）、涉及的系统（核心交易系统的问题比内部工具的问题更紧急）、提单时间（大促期间的工单优先级整体上调）……AI 可以把这些维度综合考量，给出比单纯规则更准确的优先级建议。

---

三、智能知识推荐：让工程师不用搜索就能找到答案

知识库对 IT 服务台效率的提升，在理论上是清晰的——但实际使用中有一个摩擦点：工程师需要主动去搜索，而在处理紧急工单时，搜索这个动作往往被跳过。

AI 的知识推荐，把搜索变成了推送：工程师打开一张工单，AI 分析工单的内容，主动在工单界面里展示最相关的知识库文章，不需要工程师离开工单去搜索。

这个场景听起来简单，但对使用效率的影响是显著的。研究表明，相关知识主动出现在工作流程里，比需要主动搜索的知识，被实际使用的概率高 3 到 5 倍。

更进一步，AI 可以在知识推荐的基础上提供智能诊断建议：根据工单描述和历史相似工单的处理记录，生成一个初步的排查建议——"根据类似问题的历史记录，这类问题 80% 是由 XX 原因导致的，建议先检查 YY"。这不是直接给出答案，而是给工程师一个有根据的方向，缩短诊断时间。

对一线工程师来说，这个能力相当于给每个人配了一个"老工程师助手"，随时可以查阅历史经验，新工程师的上手速度也会因此加快。

---

四、异常检测和预测性运维：从被动响应到主动预防

这是 AI 在 ITSM 里潜力最大、也是技术难度最高的方向。

传统的 IT 监控是基于阈值的：某个指标超过设定的阈值，触发告警。这种方式的问题在于：阈值设置需要经验，阈值太高会漏报，阈值太低会产生大量误报（告警疲劳），而且对"渐进式恶化"类型的故障不敏感——某台服务器的内存使用率在过去两周缓慢上升，没有超过任何阈值，但趋势指向了两周后的崩溃。

基于机器学习的异常检测，学习的是系统的正常行为模式，而不是固定的阈值。当指标的变化偏离了正常模式，即使绝对数值还在"安全范围"内，也能被识别为异常。这种能力对渐进式恶化类型的故障，比阈值告警更灵敏。

预测性运维更进一步：基于历史数据，预测某台设备在未来某个时间点出现故障的概率。磁盘的 SMART 数据显示某块硬盘正在积累不可恢复读取错误，历史数据表明这类磁盘在接下来 30 天内有较高的故障概率——提前触发更换流程，在数据丢失发生之前完成迁移。

这类能力在企业实践中的落地，需要几个前提：足够长的历史监控数据，数据质量够高，以及 IT 团队有能力响应预测性告警并采取行动。预测性告警如果得不到响应，和没有一样。

---

五、AI 辅助的根因分析：缩短故障定位时间

大规模故障的根因分析，是 IT 运维里最耗时的工作之一。工程师需要在海量的日志、监控数据、变更记录里，找到导致故障的那条线索。这个过程高度依赖经验，也高度依赖运气。

AI 在这个场景里可以做几件事：

关联分析。 故障发生时，系统自动关联事件发生时间前后的所有相关事件：监控告警、变更记录、部署日志、外部依赖的状态变化……把这些信息汇聚在一个时间线视图里，供工程师快速浏览，减少手动翻查各系统的时间。

相似故障匹配。 把当前的故障特征（告警模式、受影响组件、用户表现）和历史故障数据库做相似性匹配，找出历史上最相似的几次故障，展示它们的根因和解决方案。如果当前故障和历史某次高度相似，工程师可以优先验证历史根因，大幅缩短排查时间。

日志智能摘要。 故障发生时，相关系统可能产生海量的错误日志。AI 可以对这些日志做智能摘要：识别出最异常的日志条目，过滤掉噪音，把最值得关注的信息高亮出来，让工程师不需要逐行阅读几千行日志。

这些能力不能完全替代工程师的分析判断，但可以把工程师从繁琐的信息收集工作中解放出来，让他们把时间花在真正需要专业判断的环节。

---

六、对话式 IT 支持：AI 接管一线简单请求

最直接面向用户的 AI 应用，是对话式的 IT 支持助手。

用户遇到问题，不是打开工单系统填表单，而是在企业微信或者钉钉里，直接和 AI 助手对话："我的 VPN 连不上了。"AI 助手先问几个诊断问题，然后根据用户的回答，从知识库里检索相关的解决步骤，以对话的形式引导用户一步一步操作，直到问题解决。

对于有标准解决方案的常见问题，AI 助手可以全程自主处理，不需要工程师介入。只有当 AI 判断问题超出自己的处理范围，才自动创建工单，把对话记录作为工单描述，转交给工程师处理。

这个模式的优势明显：用户的使用门槛极低，只需要正常对话；工程师从大量简单重复的请求里解放出来；用户得到响应的速度更快，满意度更高。

劣势也很明显：AI 助手的能力取决于知识库的质量，知识库里没有的问题，AI 助手要么给出错误答案，要么只能转人工。维护一个高质量的知识库，是这类 AI 能力发挥价值的前提。

---

七、理性评估 ITSM 系统的 AI 能力

面对各家 ITSM 厂商的 AI 宣传，几个问题值得在选型或评估时专门测试：

数据从哪里来？ AI 能力的效果，很大程度上取决于训练数据的质量和规模。是用通用的公开数据训练，还是在你自己的历史工单数据上做了微调？后者的效果通常更贴合实际场景。

可解释性怎么样？ AI 给出一个分类建议或者诊断建议，能不能告诉工程师"我为什么这么判断"？可解释性对工程师建立对 AI 的信任非常重要，一个只给结论不给理由的 AI，很难被工程师真正接受。

错误率是多少？ AI 的分类或者推荐如果错误率太高，不只没有帮助，还会误导工程师。要求厂商提供在真实场景下的准确率数据，而不是在理想测试集上的数字。

人工纠错机制是否完善？ AI 判断出错时，工程师如何纠正？纠正的反馈是否被系统学习，用于改进后续的判断？一个有完善人机协作机制的 AI，会随着使用时间越来越准确；一个只能接受 AI 输出但无法反馈纠正的系统，错误会持续存在。

---

AI 正在改变 ITSM 系统的能力边界，但不是在颠覆它的基础逻辑。流程规范、数据积累、人的判断——这些依然是 ITSM 体系的核心，AI 做的是在这个基础上提升效率、降低重复劳动、增强决策支持。对于正在评估 ITSM 系统 AI 能力的团队，关注的重点应该是：这些 AI 功能在你们的实际场景里能不能真正用起来，而不是功能列表有多长。

ManageEngine ServiceDesk Plus 持续在 AI 能力上进行投入，包括工单智能分类、知识库自动推荐、相似工单匹配等功能，帮助 IT 团队在现有流程基础上提升效率。对于想了解当前 AI 功能覆盖范围和实际效果的团队，可以申请试用并在真实环境中评估。