AI 错误摘要：把 500 条报错压成 3 条结论

日志有了，结论没跟上

接入日志平台之后，团队最常说的新抱怨不是「查不到」，而是「查到太多」。一次发布故障，error 级别日志几分钟内能涌进来几百上千条，堆栈、异常、超时混在一起，值班的人只能一条条翻，靠经验猜到底哪条是先出问题的。

更麻烦的是，第一条报错往往不是根因，它多半是十分钟前、隔了几个服务的某个上游故障的症状。顺着原始日志按时间读，解决不了这个问题，只会把值班工程师的夜越熬越长。

AI 错误摘要就是针对这个场景做的：它把一段时间内的一组错误日志做聚类、去重、提炼，最后输出几句人话结论，而不是让你盯着原始日志看。

它具体做了三件事

处理流程分三步：

1. 聚类：按异常类型、堆栈指纹、服务名把错误归成若干簇，同一个空指针崩溃的 400 条日志会合成一簇；
2. 摘要：为每个簇生成一句自然语言描述，例如「order-service 在 14:02 之后出现大量 NullPointerException，集中在 createOrder 方法」；
3. 排序：按影响面（错误数、涉及服务数、持续时间）排序，把最可疑的簇排到最前。

最终输出更像一份分诊记录，而不是日志堆：

1. order-service — 412 条错误，最早 14:02
   新券发布后 paymentMethod 为空导致的 NullPointerException
2. pay-service — 88 条错误，最早 14:04
   调用 channel-gateway 超时，源于同一次上游故障

输出的不是含糊的「可能有问题」，而是「这条堆栈指向订单服务下单方法里对空对象的解引用」。

为什么搜索解决不了这个问题

有人会说，日志搜索做得好就够了。差距在于：搜索要求你先知道自己要找什么。故障当下，你并不知道该查哪个异常类型、哪个服务、哪个时间切片，只能一条条试探性地查，再手工把画面拼起来。

摘要把这个流程反过来：平台负责探索，你负责判断。差别就像「给我 14:00 之后的 error」和「告诉我 14:00 左右出了什么事」。

什么时候值得用它

• 发布后五分钟：新版本上线后，用摘要判断要不要回滚，比盯着滚动日志快得多；
• 凌晨被叫醒：先看摘要，再决定要不要真的爬起来；
• 历史故障复盘：对过去 24 小时的 error 拉一份摘要，快速定位共性根因。

它不替代人工，只是把「读日志」的前置成本降下来，让人把精力放在真正的判断上。

使用建议

摘要质量取决于日志是否规范，三条建议：

1. 异常要带堆栈，裸的 ERROR: failed 没什么可摘要的；
2. 服务名和 trace id 要打全，聚类和关联都靠它们；
3. 阈值可调，告警触发后自动跑摘要，把结论跟着告警一起推出去。

在控制台「故障分析」页，选定时间范围和服务，一键生成摘要，结果可以直接复制进工单当排查依据。