上下文给足，AI 就能排查生产问题。

生产排查的本质是证据链的组织。过去一年我最大的体会是：只要把上下文给足——日志、源码、监控、数据，AI 就能完成一次合格的生产问题排查。本文不谈具体案例，只分享我设计 AI 排查 Skill 时的思考：上下文怎么给、给到什么程度、为什么"给足"比"聪明"更重要。

一、凌晨两点的告警群

凌晨两点，生产群的告警又响了。排查的过程永远似曾相识：有人在群里发日志截图，有人说"我这边看着没问题"，有人开始翻代码，最后总会有一个人被 @ 出来——“这个系统只有他最熟”。

我们嘴上管这叫团队协作，实际上这是个人英雄主义：排查能力长在某些人的脑子里，他们是团队的"排障单点"。他们休假，故障就悬着；他们离职，系统就裸奔。

这篇文章想聊一个问题：生产排查，能不能不再依赖"老师傅"？我给出的答案是一个 AI 排查 Skill——不是让 AI 变聪明，而是把老师傅找证据的路子，变成机器能走的流程。

二、排查的本质：不是猜，是组织证据链

先问一个看起来简单的问题：生产排查到底在干什么？

一个故障从现象到根因，中间要回答的其实只有三个问题：发生了什么（监控和日志）、为什么会发生（源码和数据）、还有谁受影响（存量和影响面）。所有排查动作，无非是在各种系统里翻找证据，再把它们串成一条能自洽的链。

那老师傅强在哪？不是智商，是他知道证据在哪：哪个日志在哪个平台、那段逻辑在哪个服务、这个字段是三年前谁埋的。所谓经验，就是一张存在脑子里的"证据地图"。

这就是问题的关键：排查的瓶颈从来不是"分析能力"，而是"上下文获取成本"。一个新人和老师傅面对同一个故障，差距不在推理，在老师傅十分钟能拿到的东西，新人要翻三天。

想通这一点，AI 的位置就清楚了。大模型最强的就是分析和推理——它缺的从来不是脑子，是眼睛和耳朵。所以让 AI 排查生产问题，核心动作只有一个：把散落在各处的上下文，用工具喂到它面前。上下文给足，AI 就是一个推理能力顶配、还永远不用睡觉的排查员。

三、上下文到底给什么：四个维度的证据源

既然核心是"给足上下文"，那下一个问题就是：上下文到底包括什么？在我的实践里，一次完整的生产排查需要四个维度，缺一个，结论就可能站不住。

第一维：生产日志。回答"发生了什么"。请求什么时候进来、在哪个服务报错、参数是什么、影响到了谁。日志是排查的第一现场，也是老师傅经验最密集的地方——哪个平台查、按什么字段过滤、traceId 怎么串，这些都要变成 AI 可以直接调用的工具，而不是教会 AI 去网页上点来点去。

第二维：线上源码。回答"为什么会发生"。注意，是线上实际运行的版本对应的源码，不是你本地 master 的最新代码——生产事故里最常见的弯路，就是拿着新代码分析旧问题。源码给 AI 的方式也有讲究：不是整个仓库扔给它，而是用代码知识图谱，让它按调用链精准定位到相关函数，而不是靠 grep 大海捞针。

第三维：监控与运行状态。回答"系统当时处于什么状态"。CPU、内存、慢查询、线程池、连接数——很多故障的真相不在某一行报错日志里，而在指标曲线的拐点里。

第四维：数据与存量。回答"还有谁受影响"。确认根因之后，顺手做一次存量扫描：这是个案还是系统性隐患？影响面有多大？这一步是"排查"和"修 bug"的分水岭——修 bug 的改完一个点收工，排查的要回答整个面。

四个维度备齐，AI 手里的证据就和一个老师傅十分钟能收集到的东西对齐了。剩下的推理，是它的主场。

四、Skill 的架构：让 AI 编排证据，而不是让 AI 猜答案

有了证据源，怎么组织 AI 去用它们？我的 Skill 里有几条设计原则，每一条都是踩过坑后留下的。

原则一：AI 做编排，工具做执行。Skill 不期望 AI 凭记忆回答任何问题，它的职责是决定"下一步该查什么"：先看日志定位异常请求，再顺着 traceId 找服务，再翻源码找逻辑，最后回扫存量。每一步都落到具体工具的调用上。AI 给方向，工具给证据。

原则二：子代理干活，主代理拿结论。排查过程会产生海量明细——几百行堆栈、几千条日志。如果全部塞进主上下文，AI 很快就会被细节淹没。所以明细交给子代理消化，主代理只接收"结论加证据指针"：结论是什么，证据在哪个文件的哪一行、哪条日志的哪个 traceId。主上下文保持干净，推理质量才能保持在线。

原则三：每条结论必须带指针。这是整套体系里最不可妥协的一条。AI 给出的每一个判断，都必须能被读者独立验证——文件行号、commit 记录、日志原文、时间窗口。没有证据的结论，和猜没有区别。这份信任不是对 AI 的信任，是对证据的信任。

原则四：结论要标注置信度和边界。报告里必须写清楚：哪些是日志直接证实的，哪些是源码推断的，哪些本次没有验证手段（比如未直接查库，由日志反证）。知道结论的边界，比结论本身更重要。

原则五：只读优先。整个排查过程对生产环境零写入——查日志、读源码、看监控，全部是只读操作。让 AI 接触生产，权限的底线比能力的天花板更重要。

这五条合起来，Skill 的角色就清楚了：它不是一个"更聪明的排查员"，而是一套把老师傅的排查路径固化下来的流程。AI 在流程里跑，人在流程外验收。

五、写在最后：老师傅应该去做更值得的事

这套 Skill 用到现在，我最深的体会是：AI 排查的价值，不在于它比人快多少，而在于它把"排查"从一种个人手艺，变成了一种组织能力。

以前，一个团队的生产稳定性，系在几个最熟系统的人身上。他们随叫随到，救了一个又一个火，也一年一年地把自己耗在重复的查证里。现在，证据采集和初步分析交给 Skill，人只做两件事：确认证据链是否完整，拍板处置方案。老师傅从消防员变回了工程师——他们的经验不再是每天被动消耗的资本，而是用来打磨流程的资产。

还有人问过我：你不担心 AI 查错吗？我的回答是：我担心，所以每一条结论都必须带证据指针。这套体系信任的从来不是 AI 的判断力，而是"结论必须可被验证"这条纪律。AI 会犯错，但证据不会撒谎。

系统会越来越复杂，人不会越来越多，这个趋势不会回头。生产排查的尽头，不是更多的老师傅，而是更好的流程。

上下文给足，剩下的交给 AI。救火的事交给流程，造未来的事，留给人。

—— 一个想让自己少接点告警电话的工程师