去年开始，我在工作里越来越多地拿 AI 查日志。最开始的想法特别朴素：AI 能读代码、能总结长文，那把报错日志贴过去，它总能帮我看出点东西吧。
试下来发现，能看，但也就到“能看”为止了。
你把一大段日志复制给它，它确实能总结，也能挑出里面的 ERROR。可线上排查真正麻烦的从来不是“看见一条 ERROR”，而是这条 ERROR 到底是不是根因：它发生在哪个服务，是不是下游服务包了一层又抛上来的，用户给的 taskId 和日志里的 requestId 怎么对上，一个失败任务背后到底串了多少系统。这些光靠贴日志，它答不上来。
所以后来我把这一年踩过的坑整理成了一个 Skill，项目在这：Mercer-Lee/loghound。
以前查日志有多累
没 AI 之前，我查一个线上问题基本就是一套固定动作：
- 客服或者同事丢过来一个 taskId、uid、requestId，极端点的只有一个用户截图。
- 打开日志平台，凭感觉决定先查哪个服务。
- 搜关键词，看有没有 ERROR 或 WARN。
- 入口服务如果只说“下游调用失败”，就再摸去下游服务。
- 下游要是还调了别的服务，就继续追。
- 最后把能看懂的部分拼成一段话，告诉对方是什么原因、能不能重试、是不是用户素材的问题、要不要拉研发。
这套流程非常吃经验。同样是“任务失败”，入口参数校验失败、队列执行失败、渲染失败、文件下载失败、第三方回调失败，长得都很像，但处理方式完全不一样。日志平台里第一条 ERROR 很多时候只是表象。
再加上现在日志也不在一个地方。阿里云 SLS 一份，腾讯云 CLS 一份，火山引擎 TLS 一份，有些工作流系统只能走 Webhook 或者接口查状态。偶尔还要去 MongoDB、SQL 里反查用户、任务、素材记录。每次手动来一遍，是真的累。
AI 干这个活有价值，但它得有个固定的工作台，而不是每次临时粘贴一坨日志。
直接让 AI 看日志的几个坑
我刚用 AI 查日志时踩过三个坑。
第一个，它特别容易把“现象”当成“原因”。入口服务写着“任务执行失败”，它就告诉你“原因是任务执行失败”。这话说了跟没说一样。真正有用的线索都在下游：下载素材 403、文件格式不支持、回调超时、参数解析挂掉、第三方接口返回了明确错误。得追到那一层，结论才算数。
第二个，日志一多，上下文就被冲散了。一次排查搜出几十上百条日志，全丢给 AI，它很费 token，还容易被重复日志、INFO、无关 WARN 带偏。最后输出看着挺丰富，最关键那条可能没抓住。
第三个，AI 不知道我们的系统拓扑。人查日志时脑子里有张地图：哪个服务管入口，哪个服务管队列，taskId 什么前缀代表哪类任务，哪个错误一般要继续去哪个服务追。我常查的那个视频生成项目，入口、异步队列、回调、定时任务、原子数据服务拆开，光日志源就十几个，不把这些告诉 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 得知道当前服务调了哪些服务、每个服务大概干什么。
追到某个服务冒出明确硬错误为止，像下载文件失败、参数格式错、网络超时、第三方接口失败、媒体解析失败。这类日志比“任务执行失败”离根因近得多。
最后把结论整理成固定格式：问题结论、关键证据、影响范围、处理建议、客服或用户回复话术。这样不管是换个人查，还是隔几天查同类问题，输出都不会太飘。
拿一个真实问题举例
前阵子有个问题我印象很深，测试环境有人反馈：一个短视频编辑接口，用户说没拦住，但按规则应该拦住。
按老习惯，第一反应是去日志里搜 ERROR。结果入口服务什么报错都没有，只有一些任务进入编辑、重新触发的正常日志，权益检查那几条关键日志一条都关联不上。
如果停在这里，很容易得出“接口漏校验”的结论。实际上后来按 loghound 的流程追，发现请求确实被拦了，只是没走报错，而是被更前面的“内容时长上限”检查拦下，接口返回了一个成功响应里带提示的形态。也就是说，问题不是没拦，而是拦截后没有按错误抛出来。
这个 case 最后能收敛，靠的是几件事：先确认问题类型（这不是“任务失败”，而是“应该拦截但看起来没拦”），再从入口日志里找到对应请求，顺着代码路径把“时长检查 → 权益检查 → 扣减”的顺序对上，最后才敢下结论。中间日志一直查不到权益检查，是因为代码走到时长上限就 return 了，后面根本没执行。
整个过程大概花了五分钟。放以前，光是把这几条日志和代码路径对齐，我可能就得来回翻半天。
我特别在意的几个点
第一，先分清“状态查询”和“故障排查”。 很多时候别人只是问任务完成没有，不是要你分析事故。AI 要是一上来就写根因、责任服务、客户话术，就很莫名其妙。
第二，查日志只是取证，不等于结论。 脚本返回的东西只能说明某个时间点查到了什么，不能直接当根因。AI 得结合上下游、错误位置、日志级别、失败阶段一起看。
第三，别停在业务包装错误上。 很多系统会把下游错误包成“任务失败”“生成失败”“处理异常”。这些是 ERROR，但不一定是根因。只要日志里还有下游线索，就继续追。
第四，输出要能直接给人用。 排查到最后不是甩一堆日志，而是告诉对方：什么原因、有没有用户侧因素、能不能重试、要不要研发处理。给客服看的结论尤其不能写成堆栈分析报告。
它现在能做什么
现在 loghound 能覆盖这些场景：
- 从多个云日志平台查同一个 taskId 或 requestId
- 按项目配置识别不同服务的日志源和环境
- 日志标准化、聚类、错误信号提取
- 按服务拓扑追下游
- 通过 MongoDB 或 SQL 把用户侧 ID 转成内部 ID
- 查 Webhook 类工作流任务的状态和错误
- 让 AI 按固定 Skill 流程生成根因分析和回复话术
它没做成开箱即用的万能事故机器人，因为每家公司拓扑、日志格式、任务 ID 规则都不一样，肯定要配项目、配日志源、配调用关系。
但这恰好是它有价值的地方。一个完全不懂你系统的工具，顶多做个通用日志总结；把项目拓扑、日志规则、排查经验都喂进去，它才可能真帮上忙。
写在最后
我以前一直觉得查日志是典型的经验活。有经验的人一看错误，就知道这条日志要不要信、要不要往下追、这个 ID 去哪个库反查、什么错能直接回用户、什么错必须拉研发。
用了一年 AI，我的想法有点变化：经验活不是不能交给 AI，关键是把经验拆出来。别只说“帮我看看这个日志”，要告诉它先判断问题类型、先找最强标识符、查不到怎么降级、看到下游失败继续追、别把包装错误当根因、输出必须带证据。这些规则一沉淀，AI 的表现会稳定很多。
所以 loghound 对我来说就是个整理：把原来藏在脑子里的判断路径写成 Skill，让 AI 不只是“会读日志”，而是尽量按一个工程师查问题的方式干活。后面如果能继续迭代，我还想让它多接几个日志平台、多跑几个真实事故，把没覆盖到的边角补上。