凌晨两点，手机响了。
“服务500了。”“用户登不上。”“延迟突然飙高。”
你睁着一只眼摸到电脑，连上VPN，打开日志系统，开始grep。十分钟后，屏幕上刷出几万行error，全都在吼，但没有一行说人话。
这不是段子。这是每个on-call工程师的真实夜晚。
很多人已经开始感觉到——日志量在涨，服务在拆，告警在炸，但人的精力没变。过去一个人能盯三个服务，现在三十个服务在跑，日志量翻了十倍，排查时间没变短，反而更长了。
行业里给出的答案叫AIOps。大厂在推，厂商在卖，PPT上写满了“智能根因分析”“秒级定位”“自动修复”。但你真落地试试——日志分散、格式不统一、告警噪声巨大、业务上下文缺失，第一步就卡住了。
所以今天我换了个角度。不聊平台，不聊架构，只聊三件事：3个Prompt，怎么把一个通用大模型，变成24小时盯着日志的“故障福尔摩斯”。
目录
一、告警越多，脑子越乱——故障排查正在失效
二、本质变化：从“人查日志”到“系统先分析日志”
三、3个Prompt的核心机制拆解
四、一个真实案例：订单查询接口的45分钟→3分钟
五、工程落地启示：你现在就能开始
六、一个问题
一、告警越多，脑子越乱——故障排查正在失效
先说一个反常识的事：告警越多，排查效率反而越低。
传统运维的套路很固定：监控面板出红线 → 打开日志系统搜关键词 → 翻异常堆栈 → 对比时间线 → 分析调用链。
这套流程在单体应用时代勉强够用。三个服务、几百行日志每分钟，人工翻一遍也就几分钟。
但现在的系统是什么样？微服务、容器化、云原生，一个用户请求能穿越几十个服务。每天几TB的日志、几千万个指标数据点、数百万条分布式追踪。日志不是问题，读日志才是问题。
更麻烦的是，故障从来不是“一条日志告诉你哪里坏了”。它是一个现象，背后可能涉及数据库连接池、网络抖动、缓存穿透、依赖服务超时、配置变更……你要把不同组件的日志拼成一条因果链，在脑子里做模式匹配，还得判断“这是不是老问题”。
SRE团队平均要花30到60分钟才能定位一次中等复杂度故障的根因。这30分钟里，系统在受损，用户在流失，你在焦虑。
这不是能力问题，是结构问题。人的认知带宽是固定的，系统的复杂度是指数级增长的。
二、本质变化：从“人查日志”到“系统先分析日志”
那AI进来之后，改变了什么？
本质变化只有一句话：排查的起点变了。
过去，起点是“人打开日志系统开始搜”。现在，起点是“系统先把日志分析完，把结论递给人的”。
AI的价值不是替你修bug，是替你省on-call的命。它的工作方式很具体：自动提取异常片段、识别错误类型、统计高频关键词、生成故障摘要、给出可能的根因方向。
换句话说，AI在做“信息归纳”和“异常解释” 。它不负责决策，负责把混乱信息组织成可讨论的结构。
很多人问：这不就是高级版grep吗？
差远了。grep是“搜字符串”，AI做的是“语义检索”。grep只能找到你明确知道要搜的词，AI能回答“有没有类似数据库连接耗尽导致接口超时的问题”。这两者的差距，相当于查字典和问一个懂行的同事。
但这里有个关键问题：AI的能力很强，但你怎么让它稳定输出？
这就回到了今天要聊的核心——Prompt。
三、3个Prompt的核心机制拆解
先亮结论：3个Prompt的本质，是把一次“模糊的AI对话”，变成一套“可重复的故障排查流程”。
很多人用AI做日志分析，上来就甩一堆日志说“帮我看看哪里有问题”。结果AI要么给一堆废话，要么编造不存在的根因。
问题不在AI，在Prompt。Prompt不是聊天开场白，是给AI下发的“操作指令” 。
下面是我反复测试后沉淀下来的3个Prompt。每个解决一个特定问题，组合起来形成一个完整的排查闭环。
Prompt 1：事实提取
第一个Prompt只做一件事：把日志里的客观事实提取出来，不带任何推断。
输入是一段脱敏后的日志片段（建议控制在最近10到15分钟内的ERROR级别日志，大约200到500行）。Prompt的核心结构是：
列出所有出现的异常类型
标注每种异常的出现频次和时间分布
提取所有TraceId、服务名、接口名
标注首次出现时间和最后一次出现时间
这一步的本质是 “建立事实基础” 。AI不猜，不推，只做信息整理。
为什么要这么做？因为大多数排查失败，都源于“在事实不清的情况下开始推断”。先让AI把事实摆整齐，人看一眼就知道“我面对的是什么量级的问题”。
Prompt 2：模式识别
第二个Prompt做的是 “找规律” 。
基于Prompt 1输出的事实，让AI回答三个问题：
这些异常之间有没有时间上的先后顺序
有没有某个异常类型是其他异常的前置条件
哪些异常集中出现在特定服务或特定接口
这一步的本质是 “建立因果关系假设” 。AI不给出最终结论，只给出“A发生在B之前”“C和D高度相关”这类可验证的观察。
这里有个容易被忽略的细节：让AI输出“置信度” 。对于每个观察，要求AI标注“高/中/低”三个置信等级。低置信度的观察不进入下一步。这能有效过滤掉AI的“幻觉”。
Prompt 3：根因假设与验证路径
第三个Prompt做 “生成可执行的排查方案” 。
基于前两步的事实和模式，让AI输出：
最可能的根因假设（不超过3个）
每个假设的验证步骤（具体的命令、查询、检查点）
每个假设的优先级排序
如果验证失败，下一步该查什么
这一步的本质是 “把诊断权交回给人” 。AI给出假设和验证路径，人负责执行验证、做最终判断。
三个Prompt串起来，逻辑链条非常清晰：
这套流程的核心设计原则只有一条：把AI放在“辅助”的位置，而不是“替代”的位置。 AI负责信息整理和假设生成，人负责验证和决策。
四、一个真实案例：订单查询接口的45分钟→3分钟
说一个我上个月经手的真实案例。
线上告警：订单查询接口P99响应时间从300ms飙升到4s。涉及的服务包括order-service、MySQL、Redis、user-service、payment-service。
按照传统流程，我需要：登录日志系统→搜traceId→翻异常堆栈→查MySQL慢查询→看Redis命中率→检查user-service和payment-service的调用链→对比时间线。一套下来，45分钟打底。
这次我用3个Prompt走了一遍。
Prompt 1输出的事实 ：过去15分钟内，order-service有127条超时日志，集中出现在10:27到10:32之间。所有超时日志都关联到同一个TraceId前缀。MySQL连接池有23次获取超时。
Prompt 2输出的模式 ：MySQL连接池超时出现在所有慢请求之前。Redis和下游服务调用正常。时间序列上，连接池超时先于接口超时约200ms。
Prompt 3输出的假设 ：根因大概率是MySQL连接池耗尽。验证步骤：查连接池最大连接数配置、查当前活跃连接数、查是否有慢查询占着连接不释放。
实际验证结果：连接池最大连接数配置为50，活跃连接数在高峰期达到49，有一条慢查询执行时间超过8秒占着连接。问题出在最近一次上线引入的新查询没有走索引。
整个排查过程从打开日志到定位根因，不到3分钟。AI帮我省掉了最耗时的两部分：翻日志找事实、在脑子里拼因果链。
这不是AI比我聪明。是AI比我快。它把45分钟里最枯燥的40分钟接管了，我只做了最后5分钟的判断。
五、工程落地启示：你现在就能开始
说完了方法，说点实在的——你现在就能开始做，不需要等平台采购、不需要等架构升级。
第一，从“异常初筛”开始，别一上来就做“根因分析”。
很多团队做AI运维失败，是因为目标定得太高。根因分析需要大量上下文：调用链、指标、日志、配置变更、发布记录、依赖服务状态。缺任何一块，AI都可能给出看似合理但实际错误的判断。
但异常初筛不一样。它只回答几个基础问题：哪些服务日志异常变多了、哪些错误是新出现的、哪些异常和历史模式不同。这一步看似简单，实际价值巨大——大多数事故不是没有信号，而是信号被噪声淹没了。
第二，本地Agent比云端方案更务实。
日志里有用户手机号、订单号、支付信息、内部IP。直接发给外部大模型，安全和合规风险都很高。
本地Agent的优势在于：数据不出域、和现有系统（ELK、Loki、Prometheus）集成自然、成本可控。它不需要替换现有监控系统，而是定时从这些系统拉数据做二次分析。
第三，先跑通流程，再优化效果。
别一上来就纠结“用哪个模型”“向量库用FAISS还是Milvus”。先用一个通用大模型把3个Prompt跑通，看输出质量能不能帮到你。流程通了，再考虑工程化——日志脱敏、自动触发、结果推送。
我见过太多团队花三个月选型、六个月搭平台，最后发现根本问题不是技术选型，是没有人认真想过“AI在排查流程里到底该干什么” 。
先把“干什么”想清楚，再谈“怎么干”。
六、一个问题
看到这里，我想问你一个很实际的问题：
你现在的系统，从告警触发到定位根因，有没有一个明确的“AI参与节点”？
换句话说，当告警响起时，AI是在你打开日志之前就已经把异常摘要准备好了，还是等你手动翻完日志才开始想“要不要问问AI”？
如果你的答案是后者，那说明你的排查流程里，AI还只是一个“事后咨询工具”，而不是“流程内置组件”。
这两者的效率差距，不是一倍两倍，是数量级的。
你现在就可以做一个实验：下一次告警来了，先别急着grep。把你最近10到15分钟的ERROR日志丢给AI，用上面那3个Prompt走一遍。看看多久能拿到一份可用的异常摘要。
然后告诉我，你的on-call夜，少掉了多少根头发。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
