运维日志每天 200 多条，出问题时靠人翻，翻到一半就忘了在找什么。这套办法是先用脚本把异常行抽出来，再让豆包归成 5 类并各写一句摘要。200 条里抽出异常 43 条，归成报错峰值 14、超时 11、第三方失败 8、库存不一致 6、其他 4。每天跑一遍 8 分钟，人工原来要 75 分钟；搭建一次性投入 100 分钟。
一句话结论
日志摘要这件事，关键不在模型读得多全，在脚本先筛掉 90% 的正常行。200 条日志里 168 条是正常心跳和例行请求，塞给模型只会稀释注意力。正确做法是脚本按规则抽异常行、模型只负责归类和写一句话摘要、人只复核「其他」并抽检前四类。三步各管一段，比让模型从头读到尾准得多。
这篇解决什么问题
三种情况最常见。一是整份日志直接丢给模型：上下文塞满正常行，摘要写出来全是「系统运行正常」这类废话，真异常反而被淹掉。二是分类按技术栈切：分成数据库、缓存、网关，听着专业，但看的人不知道该找谁，因为处置动作从来不是按技术栈分的。三是摘要写成了复述：把报错原文抄一遍，等于没摘要，第二天还得回去看日志。
根子是把这一步当成阅读理解。它其实是筛选与分派：先按处置动作分类，再让每类只留一句「哪里、多少次、该找谁」。分类标准必须从处置出发，否则归得再准也没人用。
开始前要准备什么
- 连续 7 天的日志，别只拿一天。单日样本里偶发错误占比会失真，7 天才能定出稳定类别。
- 一份处置责任人表：哪类问题找哪个人或哪个团队。这份表决定分类维度。
- 脚本权限：能读日志文件、能调模型接口，输出到一个固定路径。
- 一条纪律：类别数固定 5 类，不许临时加。加到 8 类以上，人就只看前两类，等于白做。
具体怎么做
第一步：按处置动作定 5 类，不按技术栈定
拿 7 天日志先人工扫一遍，把异常按「该谁看」分组。这次定出来是：报错峰值、超时、第三方接口失败、库存不一致、其他。定类 15 分钟，因为处置责任人表本来就摆在那，照着分就行。
这 5 类各有明确的下一步。报错峰值看代码改动；超时看下游容量；第三方失败看对方状态页；库存不一致对数据；「其他」只有一个动作——人工看一眼决定归到哪类或者新增。技术栈分类做不到这一点，因为同一个数据库报错，可能是代码问题也可能是容量问题。
这是我连续 7 天的运维日志异常行（约 1,300 条）与一份处置责任人表（哪类问题归谁）。
请帮我把异常归成 5 类：
1. 分类依据只用「处置动作相同或相近」，不要用技术栈、不要用日志级别；
2. 每类给一个能写进规则的识别信号（关键词或正则片段）；
3. 每类标注对应的责任人，以及看这类时第一眼要确认什么。要求：类别必须收敛到 5 个，多出来的全部并入「其他」，并说明为什么它进不了前四类。
第二步：脚本只做抽取，不做理解
脚本干三件事：按时间戳切出当天的行、用正则捞出异常行（关键字加错误码）、把相邻 3 行上下文一起带上。写脚本 20 分钟，因为逻辑很浅，难点只在上下文窗口取多宽——取 1 行经常丢掉堆栈首行，取 5 行以上又全是噪音，3 行最合适。
这一步必须用脚本而不是模型。模型判断「这行是不是异常」会有波动，同一行昨天算异常今天算正常，人就没法信任这张表。规则可以很笨，但必须稳定。这次正则只有 6 条，覆盖了 90% 的异常行，剩下靠「其他」兜。
这是日志样例（含正常心跳行与异常行）与我的 5 类识别信号。
请帮我写一段 Python 抽取逻辑：
1. 按日期切分，只保留当天的行；
2. 用给定的 6 条正则筛异常行，命中即保留，并保留其前后各 1 行作为上下文；
3. 把结果按「时间 + 异常行 + 上下文」拼成一条记录，输出成 JSON 数组。约束：不要在这一步调用模型；不要做去重和排序，保持原始时间顺序，便于人工追溯。
第三步：一次批量归类，每类只写一句话
抽取后一天通常剩 30 到 45 条异常记录，一次性丢给豆包，要求它按 5 类分好并给每类写一句摘要。跑加调 40 分钟，中间改了两轮提示词——第一轮让它写「分析与建议」，输出全是套话；改成只写「现象 + 次数 + 首末时间 + 建议动作」，摘要立刻能用了。
摘要格式固定成四段：哪个接口或模块、出现多少次、第一次和最后一次的时间、建议谁去看。四段缺一段就算不合格。字数控制在 60 字以内，超过就说明它在复述而不是归纳。
这是今日抽取出的异常记录（约 30 到 45 条）。
请归成 5 类并输出摘要表：
1. 每类一条摘要，格式固定为「模块/接口 + 次数 + 首末时间 + 建议动作」；
2. 单条摘要不超过 60 字，不要写分析、不要写原因推测、不要给修复方案；
3. 按次数从多到少排序；
4. 「其他」类只列条目，不写摘要，留待人工判断。要求：归类只按给定识别信号，信号不明确的全部归入「其他」，不要强行塞进前四类。
第四步：人复核「其他」，并抽检前四类
每天复核 25 分钟：10 分钟看「其他」的 4 到 8 条，15 分钟从前四类里抽 20 条核对归类是否正确。这次 200 条日志里「其他」4 条，逐条看下来 2 条能归进前四类（说明正则漏了）、1 条是真新问题、1 条是误报。抽检的 20 条里 18 条归对，2 条边界模糊。
这一步不能省。全自动跑一周，正则覆盖不到的新类型会被一直归进「其他」然后没人看，等于漏报；而前四类如果不抽检，分类漂移也没人发现。做法是每天二十分钟看「其他」，同时把新发现的模式补进正则，让「其他」的占比逐周下降。
这是今日摘要表、「其他」类的 4 到 8 条原始记录，以及从前四类抽出的 20 条。
请帮我做两件事：
1. 「其他」逐条标为「应归入前四类（哪一类）/ 真新类型 / 误报」，对应归类的给出可补进正则的关键词片段；
2. 抽检的 20 条逐条判「归类正确 / 边界模糊应该归到哪类 / 明显归错」。要求：新增类别要谨慎，只有连续 3 天出现且处置责任人不同的才考虑单列。
实测记录
素材是 7 天运维日志与一份处置责任人表。定类 15 分钟、写抽取脚本 20 分钟、批量归类调提示词 40 分钟、首日复核 25 分钟，搭建合计 100 分钟。之后每天跑脚本 2 分钟、看摘要 6 分钟，共 8 分钟。
首日结果：200 条日志里抽出异常 43 条，占 21.5%，等于把要读的量压掉了近八成。43 条归成报错峰值 14、超时 11、第三方失败 8、库存不一致 6、其他 4，五类相加正好 43，与抽出的条数一致。
对比人工：原来每天翻 200 条日志写一段情况说明要 75 分钟，而且经常只看最后两小时。现在 8 分钟，覆盖全天。按月 22 个工作日算，每月省 1,474 分钟，约 24.6 小时。真正省下来的不是这二十多个小时，是「有问题能第一时间知道」这件事。
最容易错的 3 个地方
第一，把整份日志丢给模型。168 条正常行会把真异常稀释掉，摘要写成「系统运行正常」。必须脚本先抽，抽取规则可以很笨，但不能交给模型判断——同一行昨天算异常今天算正常，这张表就没人信了。
第二，按技术栈分类。数据库、缓存、网关这套分法看着专业，但看的人第一反应永远是「那我该找谁」。类别必须按处置动作切，处置责任人表就是分类依据，这一步能省掉后面所有争议。
第三，摘要让模型写分析和建议。第一轮提示词要求「给出原因分析与修复建议」，输出全是「建议检查配置」这类套话。改成只写现象、次数、时间、建议找谁，字数卡在 60 字以内，摘要才真正能用。
可复用的东西
先抽后读：脚本按正则抽异常行加前后 1 行上下文，模型只处理抽出来的部分。
按处置定类：5 类对应 5 个责任人，不按技术栈切，不加到 6 类以上。
四段摘要：模块、次数、首末时间、建议动作，60 字以内，不写分析不写方案。
每天复核：10 分钟看「其他」、15 分钟抽检前四类 20 条，新出现的模式当天补进正则。
规则稳优先：抽取用正则可以笨，但不能让模型判断是不是异常，稳定性比准确率更重要。
常见问题解答
为什么不让模型直接判断哪行算异常
它会波动。同一行日志昨天被判异常、今天被判正常，这张表就没人敢信。抽取这一步必须是确定性规则，哪怕正则很笨、只覆盖九成，也比不稳定的智能判断可靠。剩下的交给「其他」类，由人每天看一眼再补正则。
5 类为什么按处置动作分而不是按技术栈分
因为看表的人第一反应是「我该找谁」。分数据库、缓存、网关看着专业，但同一个数据库报错可能是代码问题也可能是容量问题，责任人不同。按处置动作分，每一类天然对应一个人或团队，分类等于分派，看完就能动手。
摘要为什么要卡 60 字
超过 60 字基本就是在复述报错原文，等于没摘要。这次把格式固定成模块、次数、首末时间、建议动作四段，字数自然压在 60 以内。第一轮让模型写「分析与建议」，输出全是「建议检查配置」这类套话，就是没有字数约束的后果。
搭建花 100 分钟值不值
按每天省 67 分钟算，第二天就回本了，一个月约省 24.6 小时。但真正值钱的不是这些工时，是覆盖面：人工翻日志通常只看最后两小时，脚本跑全天。这次首日的异常里有 3 条发生在凌晨，人工翻的时候根本不会看到。
本网站的部分内容可能来源于网络或用户投稿，仅供大家学习与参考，如有侵权，请联系客服： hhxmw778 进行删除处理。
本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
教程如引导您添加微信或有另外收费服务，请自行甄别！
如遇充值环节或绑定支付账户或输入支付密码之类的异常步骤，建议停止操作！本站不对操作项目的损失负责！
本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现任何资源有问题请向站长举报下架
(手机微信用户建议用默认浏览器打开，可体验完整功能)
按岗位找 AI 实操步骤 · 提示词可收藏