先说几个核心判断。很多人用 AI 排查 Bug，第一句话就是：“这是日志，帮我分析原因。”
听起来没问题吧？但这个 prompt 其实很容易让模型陷入一种“表面合理但未必可靠”的推理模式。为什么呢？因为日志往往是孤立的。它缺少关键的上下文：比如服务当前的拓扑结构、代码的发布时间、请求的完整链路、错误的占比高低、是否有灰度策略、配置是否刚改过、下游依赖是否稳定……这些信息一缺，模型就只能基于常见故障模式去“猜”一个最像的结论。
所以，我个人的习惯更倾向于把大语言模型放在排障流程的“前半段”，专门干三件事：
- 把杂乱的材料结构化：将日志、报警、工单、群聊里的各种信息碎片，整理成有条理的事实清单。
- 帮我们拆出可验证的假设：把可能的原因，拆成“支持它的证据是什么”“反对它的证据是什么”“怎么去验证它”。
- 生成复盘文档的初稿和修复清单：让后续的团队讨论和技术沉淀都有个扎实的起点。
当然，最后的结论，一定还得靠监控曲线、链路追踪、数据库指标、压测结果、代码 Review 和测试来拍板。这个定位明确了，后面的路就好走了。
一、一个看似普通的接口超时
这次碰到的场景比较典型，是一个 Java 后端服务的查询接口，在晚高峰的时候 P95 延迟突然飙升，还有少量请求直接返回了 504。业务方先炸了，说“页面偶尔打不开”；紧接着网关报警也响了；开发群里有同事提到“最近刚上线改过查询条件”。
我们手里当时就攒了这么一堆材料：
- 网关的 504 日志
- 应用侧的 error log
- 数据库的慢查询日志
- 最近一次发布的 Git diff 记录
- 监控系统里的关键时间点截图
- 测试同学整理出来的复现步骤
- 群里大家七嘴八舌的排查讨论记录
如果直接把这些东西一股脑丢给 AI 让它“总结原因”，它大概率会给你一个看起来像模像样的事故报告，但一深究就露馅。比如，它会写：“初步判断为数据库慢查询导致接口超时。” 这句话可能对，也可能只是“看起来最像”的那个。
所以，我处理的第一步是：明确要求它只整理事实，不许擅自下结论。
二、核心模块一：先把材料压成“时间线 + 证据表”
1. 输入前先脱敏
在技术社区里得反复强调：公司的任何敏感信息——代码、日志、客户ID、手机号、订单号、Token、内部IP、域名、表名等等——都别直接扔给任何 AI 工具。这不仅是规范，更是安全的底线。
我一般会做简单的脱敏处理：
- 用户ID → U_001、U_002
- 订单号 → ORDER_001
- 内部服务名 → service-a、service-b
- 接口路径 → /api/query/resource
- 数据库表 → table_main、table_relation
- IP → 10.x.x.x
- TraceId → trace_001
如果日志量大，千万别一次性全塞进去。先抽样，重点看这几个时段：错误发生前5分钟、错误高峰期、错误恢复后5分钟。每种类型挑上3-5条，再带上慢查询 Top 5 和发布代码的 diff，信息密度就够了。
2. Prompt 示例：只整理，不推理
下面这个 prompt 是我常用的，核心就一个要求：只提取事实，所有分析全靠边站。
你是后端故障复盘助手。下面是脱敏后的日志、报警和发布信息。
要求：
1. 只提取事实，不要推断根因；
2. 按时间线整理事件；
3. 把每条事实关联到证据来源；
4. 标记信息缺口；
5. 如果材料之间存在冲突，请单独列出。
输出格式：
- 时间线
- 关键指标变化
- 错误类型分布
- 已知变更
- 信息缺口
- 冲突点
材料如下：
【粘贴脱敏后的日志、报警、发布说明】
Gemini 3.5 Flash 在这一步的表现确实不错，响应快，能很快把零散的内容整理成清晰的表格。特别是当材料来源很杂，手动翻群聊和日志很费时间的时候，它能帮你省下不少功夫。
最有价值的其实是“信息缺口”那一栏。它会主动提醒你：
- 缺少数据库连接池指标
- 缺少异常请求与正常请求的参数差异
- 缺少发布前后的 QPS 对比
- 没看到下游服务错误率
- 慢查询日志与网关超时的时间点不完全重合
这些提醒听起来不复杂，但能在排障初期帮你避开不少盲区。
三、核心模块二：让模型生成“假设树”，而不是直接给根因
事实整理清楚后，我不会去问“根因是什么”，而是换个方式，让它生成一个假设树。
Prompt 示例：拆成可验证假设
基于上面的事实表，请生成故障假设树。
要求：
1. 每个假设必须包含：支持证据、反证、需要补充的数据、验证方法；
2. 不要把相关性直接写成因果关系；
3. 按验证成本从低到高排序；
4. 输出时区分：
- 高概率但需验证
- 中概率
- 低概率但风险较高
5. 不要给最终结论。
这个输出里最有用的不是“猜测项”，而是配套的“验证方法”。比如：
| 假设 | 支持证据 | 反证 | 验证方法 |
|---|---|---|---|
| 新增查询条件导致索引失效 | 发布后延迟升高，慢查询出现 | 并非所有请求都慢 | 对比执行计划；回放相同参数；查看索引命中 |
| 连接池耗尽 | 高峰期超时集中 | 日志中未见明显连接失败 | 查看 HikariCP 活跃连接、等待线程、超时计数 |
| 下游服务抖动 | 网关有 504 | 应用侧多数时间卡在查询阶段 | 查链路追踪 span 分布 |
| 大客户参数触发大结果集 | 少量请求超时 | 需要请求参数分布 | 对异常 TraceId 反查参数特征 |
这种表格的好处是，团队讨论时不再停留在“我觉得是数据库”或“可能是网关”这种模糊的层面，而是能直接分工去验证。
四、核心模块三：把修复方案拆成短期止血、中期修复、长期治理
根因确认之后，AI 依然有用，但角色变了：它不负责做最终决策，而是帮你把方案的颗粒度拆得更细。
假设最终确认，是新增的筛选条件导致部分参数组合无法命中合适的索引，同时大客户请求又正好命中了这个组合，返回数据量太大，引发慢查询和网关超时。这时候可以让模型来生成一个结构化的修复清单。
Prompt 示例：生成工程化修复清单
已确认根因：
新增筛选条件导致部分参数组合无法命中合适索引；
部分大客户请求返回数据量过大，查询耗时超过网关超时阈值。
请生成修复方案，要求：
1. 分为短期止血、中期修复、长期治理；
2. 每项包含负责人角色、验证方式、回滚方案、风险点；
3. 不要给出无法验证的空泛建议；
4. 需要包含测试用例、监控指标和发布观察项；
5. 输出适合放进故障复盘文档。
比较理想的输出会像这样分三层：
短期止血
- 对高风险参数组合增加临时限制或分页保护
- 对异常客户请求进行灰度降级
- 调整查询超时时间前先评估线程堆积风险
- 发布后观察 P95、P99、慢查询数量、连接池等待数
中期修复
- 补充组合索引或改写 SQL
- 对大结果集改为分页或异步导出
- 增加参数边界校验
- 用生产脱敏样本做回放测试
长期治理
- 建立慢查询发布前检查
- 高峰流量压测纳入发布门禁
- 对核心接口增加 TraceId 级别的问题样本沉淀
- 在需求评审阶段加入数据量级评估
这些内容人工当然也能写，但 AI 能帮你更快地补齐那些容易遗漏的细节，特别是测试、监控、回滚这些在复盘文档里经常被一笔带过的部分。
五、辅助模块一：用 AI 生成测试用例，但不能省掉执行
故障修复后，测试用例的编写往往很赶。Gemini 3.5 Flash 可以根据根因和修复方案，快速生成一个覆盖清单。
请基于以下故障根因和修复方案，生成回归测试用例。
要求：
1. 覆盖正常参数、边界参数、大客户数据量、异常参数；
2. 包含性能验证和功能验证；
3. 每条用例包含：前置条件、输入、操作步骤、预期结果、验证指标；
4. 标记哪些用例适合自动化，哪些需要人工观察；
5. 输出表格。
但这里有个小坑：AI 生成的测试用例经常“看起来很全面”，实际上会漏掉核心业务路径。比如它会覆盖空参数、超长参数，却忽略某个特定客户类型的业务逻辑。我的做法是，让测试同学再补上三类样本：
- 历史线上出过问题的真实脱敏样本
- 大客户或高频客户的典型数据
- 产品经理确认过的核心业务路径
AI 负责打底，人负责补齐业务经验，这才是最高效的协作模式。
六、辅助模块二：把复盘文档写得更像工程文档，而不是流水账
很多故障复盘到最后就变成了一行记录：“20:10 收到报警，20:20 开始排查，21:00 修复上线。” 这只是记录，远算不上复盘。一个合格的复盘文档，应该包含：影响范围、用户表现、时间线、根因、为什么监控没提前发现、为什么测试没覆盖到、修复动作、遗留风险、后续 Owner 和截止时间。
可以让 Gemini 3.5 Flash 根据我们整理的材料，生成一个初稿：
请根据以下时间线、根因分析和修复清单，生成一份故障复盘文档初稿。
要求：
1. 面向研发、测试、产品和管理者，避免过度口语化；
2. 根因部分必须区分直接原因和深层原因；
3. 后续行动项必须可追踪，包含 Owner、截止时间和验收标准；
4. 不要夸大影响，不要省略未确认信息；
5. 对不确定内容用“待确认”标记。
这里我特别强调“标记不确定内容”。复盘文档最忌讳的就是把猜测写成事实，一旦后面发现方向错了，整个文档都会误导后续的治理和优化。
七、辅助模块三：多模型交叉验证适合用在什么地方
虽然主要用 Gemini 3.5 Flash，但在实际工作中，对于重要结论，我不建议只看一个模型。多模型对比不是为了评出个一二三名，而是为了发现单个模型可能存在的盲区。
适合交叉验证的环节包括：根因假设是否有遗漏、测试用例是否覆盖了边界情况、复盘文档是否存在逻辑跳跃、对外说明是否夸大了事实、以及合规或隐私风险是否被忽略。
不太适合用多模型交叉验证的环节包括：让多个模型同时去猜根因、用少数服从多数的方式决定技术结论、不看监控和代码只信模型分析、以及把模型输出直接当作事故定责的依据。
如果团队要选一个统一的模型调用环境，我会关注几个很实际的点：是否能方便地保存 Prompt 模板、是否能保留上下文以便连续对话、是否支持文件和图片输入、是否能方便地对比不同模型的输出、是否有清晰的数据处理说明、以及是否方便团队在复盘时复用同一套输入。工具只是环境，关键的还是我们自己梳理的流程。
八、一个简单的验收表：判断 AI 输出能不能进入团队讨论
目前我常用一张小表来判断 AI 的输出是否达到了“可用”的标准。不是分数越高越好，而是为了避免把漂亮的文本直接当成技术结论。
| 检查项 | 合格标准 |
|---|---|
| 事实与推断是否分离 | 能明确区分日志事实、模型推测、人工确认结论 |
| 是否引用证据 | 每个关键判断能对应日志、监控、代码或测试结果 |
| 是否列出反证 | 不只支持某个结论，也说明哪些现象不支持 |
| 是否可验证 | 每个假设都有验证步骤 |
| 是否可执行 | 修复建议有 Owner、风险、回滚和验收标准 |
| 是否脱敏 | 不含客户隐私、内部密钥、敏感业务数据 |
| 是否经过人工复核 | 技术负责人或相关 Owner 已确认 |
只要里面有两三项明显不合格，我就不会把它直接放进最终的复盘文档。
九、风险边界：这些内容不要交给 AI 直接决定
AI 在故障复盘中很适合做“助理”，但一定不适合做“裁判”。有几个边界必须牢记：
- 不要输入未脱敏的敏感信息：客户资料、合同、订单、密钥、Token、内部账号、医疗或金融数据等。
- 不要让 AI 直接判断责任归属：它可以整理事实和时间线，但无法替代团队的管理判断和事后定责。
- 不要把 AI 生成的 SQL 或代码直接上线：必须经过严格的 Review、测试、灰度部署和回滚预案。
- 不要把模型推断写成确定结论：复盘文档中要明确标注“已确认”“待确认”“推测”这三种状态。
- 涉及客户影响的对外说明需要人工审核：特别是在服务等级、数据安全、金融医疗政务等高敏场景下。
十、常见误区
1. AI 能不能直接帮我定位根因？
不建议这么用。它可以提出假设、整理证据、生成验证步骤，但最终的根因必须依靠监控、日志、代码、链路追踪和测试结果共同确认。
2. Gemini 3.5 Flash 适合写代码吗？
可以辅助生成脚本、测试样例、排查命令，但绝对不能跳过运行和验证。尤其是涉及生产环境命令、数据库变更、并发逻辑时，必须由人工仔细检查。
3. 多模型对比是不是浪费时间？
小任务不一定需要，但对于复杂故障、合规文档、重要对外说明、关键技术方案，用多模型交叉检查可以很好地发现盲区，但最终判断还是要落到人身上。
4. Prompt 写得越长越好吗？
不是的，关键在于约束得是否清晰。要让模型明确知道哪些是事实、哪些不能推断、输出格式是什么、判断标准是什么。一个长但逻辑混乱的 Prompt，反而会让输出结果不稳定。
结语：从低风险、可验证的环节开始用 AI
如果你是技术团队的一员，想把大模型引入故障排查流程，建议不要一上来就追求“自动排障”或“自动出方案”。更稳妥的起点，是从那些高频、低风险、且容易验证的任务开始：
- 整理日志和时间线
- 生成故障假设树
- 补充测试用例
- 改写复盘文档
- 检查修复清单是否遗漏了监控、回滚和验收标准
这些任务既容易融入现有的研发流程，也能让你快速感受到 AI 带来的效率提升。
说到底，AI 真正能提升效率的地方，不在于替我们拍板做决定，而在于它能帮我们把杂乱的信息变得可以讨论，把直觉判断变得可以复核，把复盘沉淀变得更为完整。而最终的结论，终究还是要回到工程证据上：日志、指标、代码、测试和人工 Review。用好它，它就是一个靠谱的研发助手，而不是一个只会写漂亮报告的猜测机器。
