这一年用 AI 查日志后，我写了一个 Skill
最近这一年，我在工作里越来越频繁地使用 AI 来辅助查日志和定位线上问题。
一开始我对这件事的想法很简单：既然 AI 能读代码、能总结文本，那我把报错日志贴给它，它是不是也能帮我快速判断问题出在哪里？
实际用下来，答案是：能，但不能直接这么用。
如果只是把一大段日志复制给 AI，它确实能总结出一些东西，也能帮你从里面挑出比较明显的报错。但是线上问题排查并不只是“看见一条 ERROR 日志”这么简单，更多时候真正麻烦的是：这条 ERROR 到底是不是根因？这个错误发生在哪个服务？它是不是下游服务返回的二次包装？用户给的 taskId 和日志里的 requestId 怎么关联？一个失败任务背后到底经过了多少个系统？
这些问题，单靠把日志丢给 AI 是解决不了的。
所以最近我把这一年用 AI 查日志的经验整理了一下，写成了一个 Skill，项目地址在这里：Mercer-Lee/loghound (opens new window)。
# 为什么会想到写这个 Skill
以前排查线上问题，大概是这样的流程：
- 客服或者同事丢过来一个 taskId、uid、requestId，或者更极端一点，只有一个用户截图。
- 打开日志平台，凭经验判断应该先查哪个服务。
- 用关键词搜一遍，看看有没有 ERROR 或 WARN。
- 如果入口服务只是提示“下游调用失败”，再去找下游服务的日志。
- 如果下游又调用了另一个服务，那就继续追。
- 最后把能看懂的部分整理成一段话，告诉对方是什么原因、能不能重试、是不是用户素材问题、是否需要技术介入。
这个过程其实很依赖经验。
比如同样是任务失败，有的错误是入口服务参数校验失败，有的是异步队列执行失败，有的是渲染服务失败，有的是文件下载失败，有的是第三方回调失败。日志平台里看到的第一条错误，很多时候只是表象，不是最终原因。
而且现在很多项目并不是只在一个云服务上。有些日志在阿里云 SLS，有些在腾讯云 CLS，有些在火山引擎 TLS，还有一些工作流类系统只能通过 Webhook 或接口查状态。再加上有时候还要去 MongoDB 或 SQL 里反查用户、任务、素材记录，整个链路会变得很碎。
人当然可以慢慢查，但每次都这样查，其实挺累的。
AI 在这里很有价值，但它需要一个稳定的工作台，而不是每次临时复制粘贴一坨日志。
# 直接让 AI 看日志的问题
刚开始用 AI 查日志的时候，我踩过几个很典型的坑。
第一个问题是，AI 很容易把“现象”当成“原因”。
比如入口服务里有一条日志写着“任务执行失败”，AI 可能会直接总结说任务失败的原因就是执行失败。但这句话对排查没有太大价值，因为它只是告诉你失败了，并没有告诉你为什么失败。
真正有用的线索可能在下游服务里，例如下载素材 403、文件格式不支持、回调地址超时、某个参数解析失败，或者某个第三方接口返回了明确错误。只有追到这一层，结论才比较可靠。
第二个问题是，日志太多会把上下文冲散。
一次线上排查里，经常会搜出几十条甚至上百条日志。如果全部丢给 AI，它会消耗很多 token，而且很容易被重复日志、INFO 流程日志、无关 WARN 干扰。最后输出看起来很丰富，但不一定抓到了最关键的那条。
第三个问题是，AI 不知道我们的系统拓扑。
人查日志的时候，脑子里其实有一张隐形地图：这个服务负责入口，那个服务负责队列，某个 taskId 前缀代表某类任务，某个错误一般要去另一个服务继续追。如果不把这些经验告诉 AI，它只能在单次输入里猜。
所以我后来意识到，问题的关键不是“让 AI 查日志”，而是要把排查经验结构化，让 AI 按一套固定流程工作。
# 我想沉淀的不是脚本，而是排查方法
loghound 这个项目表面上看是一个日志查询工具，但我真正想沉淀的是排查方法。
我把它分成了两层：
- 脚本层：负责查询日志、查询数据库、标准化结果、提取错误信号、聚类去重。
- 分析层：负责判断问题类型、沿着服务链路追踪、区分现象和根因、生成面向内部或客户的结论。
脚本层解决的是“证据怎么拿”的问题。
它支持阿里云 SLS、腾讯云 CLS、火山引擎 TLS、Webhook 工作流引擎，也支持从 MongoDB 和 SQL 里按用户 ID、任务 ID 之类的信息反查记录。不同平台的查询方式不一样，返回结构也不一样，所以需要先统一成 AI 更容易理解的格式。
分析层解决的是“拿到证据之后怎么判断”的问题。
这一层就是 Skill 的价值。它会要求 AI 先判断用户反馈属于哪类问题：是故障排查、质量异常、状态查询、模糊反馈、批量问题，还是审计类问题。不同问题的排查方式是不一样的，不能所有问题都按“找 ERROR”处理。
然后它会按照标识符优先级来查：
traceId / requestId > taskId > uid / userId > 用户侧 ID
如果入口服务查不到，或者日志和用户描述不一致，就会尝试用 uid 反查最近一段时间的异常；如果日志里出现下游调用失败，就继续提取下游的 taskId、traceId 或 requestId，再根据服务拓扑去下一跳服务查。
这套流程听起来不复杂，但它解决了一个很重要的问题：AI 不再是“看一眼日志然后猜”，而是被约束在一个排查流程里做推理。
# 一个典型的排查链路
假设用户反馈一个任务失败，只给了一个 taskId。
第一步，不应该马上下结论，而是先确认问题类型。如果用户只是问“这个任务现在怎么样了”，那它可能只是状态查询，不需要生成事故结论。如果用户明确说“任务失败了”或者“结果异常”，才进入故障排查或质量问题排查。
第二步，用 taskId 去入口项目里查 ERROR 和 WARN。这里查到的可能是任务失败，也可能只是收到任务、创建任务、调用下游失败。
第三步，如果入口项目的日志里出现了下游服务的任务 ID 或 requestId，就继续往下游查。这个时候服务拓扑就很重要，因为 AI 需要知道当前服务调用了哪些服务，每个服务大概负责什么。
第四步，追到某个服务出现明确硬错误为止。比如下载文件失败、参数格式错误、网络超时、第三方接口返回失败、媒体解析失败等。这类日志通常比“任务执行失败”更接近根因。
第五步，把结论整理成固定格式：
- 问题结论
- 关键证据
- 影响范围
- 处理建议
- 客服或用户回复话术
这样做的好处是，排查过程和输出口径都会稳定很多。哪怕换一个人来查，或者隔几天再查类似问题，也不会完全依赖当时的手感。
# Skill 里我特别在意的几个点
第一个点是，必须区分“状态查询”和“故障排查”。
很多时候别人只是想问任务有没有完成，并不是要你分析事故。如果这时 AI 上来就开始写根因、责任服务、客户话术，反而会显得很奇怪。所以 loghound 在流程最前面就要求先判断问题类型。
第二个点是，查询日志只是取证，不是结论。
脚本返回的结果只能说明某个时间点查到了哪些日志，不能直接当成最终根因。AI 必须结合上下游链路、错误位置、日志级别、失败阶段来判断。
第三个点是，不能停在业务包装错误上。
很多系统都会把下游错误包装成统一的业务错误，例如“任务失败”“生成失败”“处理异常”。这些日志虽然是 ERROR，但它们不一定是根因。只要日志里还有下游线索，就应该继续追。
第四个点是，输出要能直接给人用。
排查的最后一步不是展示一堆日志，而是要告诉对方：这个问题是什么原因、有没有用户侧因素、是否可以重试、是否需要研发处理。尤其是给客服同学看的结论，不能写得像堆栈分析报告。
# 目前它能做什么
现在 loghound 大概能覆盖这些场景：
- 从多个云日志平台查询同一个 taskId 或 requestId。
- 根据项目配置识别不同服务的日志源和环境。
- 对日志进行标准化、聚类和错误信号提取。
- 根据服务拓扑追踪下游服务。
- 通过 MongoDB 或 SQL 把用户侧 ID 转成内部 ID。
- 查询 Webhook 类工作流任务的状态和错误详情。
- 让 AI 按固定 Skill 流程生成根因分析和回复话术。
它不是一个开箱即用的万能事故机器人。因为每个公司的服务拓扑、日志格式、任务 ID 规则都不一样，所以它一定需要配置项目、配置日志源、配置调用关系。
但这也是我觉得它有价值的地方。
如果一个工具完全不理解你的系统，它最多只能做通用日志总结；只有把项目拓扑、日志规则、排查经验都喂进去，它才有机会变成真正能参与排查的助手。
# 写这个 Skill 后的一点感受
过去我一直觉得，查日志是很典型的经验活。
有经验的人看到一个错误，会知道这条日志要不要信、要不要继续往下游追、这个 ID 应该去哪个库里反查、什么样的错误可以直接回复用户，什么样的错误必须拉研发继续看。
AI 出现之后，我对这件事的理解有一点变化。
经验活并不是不能被 AI 辅助，关键是要把经验拆出来。不要只告诉 AI “帮我看看这个日志”，而是要告诉它：
- 先判断问题类型。
- 先找最强标识符。
- 查不到时怎么降级。
- 看到下游失败时继续追。
- 不要把包装错误当根因。
- 输出结论必须带证据。
这些规则一旦沉淀下来，AI 的表现会稳定很多。
所以 loghound 对我来说，不只是一个工具，也算是这一年使用 AI 排查线上问题之后的一次整理。它把很多原本藏在脑子里的判断路径写成了 Skill，让 AI 不只是“会读日志”，而是尽量按照一个工程师真正排查问题的方式去工作。
# 结语
这一年用 AI 查日志，我最大的感受是：AI 不会天然懂你的系统，也不会天然知道什么是根因。
但如果我们愿意把系统拓扑、日志查询方式、错误判断规则和输出格式都整理出来，它就能承担掉很多重复、琐碎、容易疲劳的工作。
写 loghound 的过程，也像是把自己查日志时的习惯重新审视了一遍。哪些判断是有证据的，哪些只是经验猜测；哪些流程可以自动化，哪些地方必须保留人工确认。这些东西整理清楚之后，工具本身反而只是结果。
后面如果继续迭代，我希望它能在更多日志平台、更多项目拓扑和更多真实事故场景里继续打磨。毕竟线上问题不会因为我们不想看日志就消失，但至少，我们可以让查日志这件事变得没那么痛苦一点。