把故障复盘资料拆成 4 步后，Gemini 3.5 Flash 的输出稳定了很多

文章摘要：本文以“支付回调延迟导致订单状态异常”的线上故障复盘为例，介绍如何用 Gemini 3.5 Flash 辅助处理告警、监控、日志、发布记录和群聊纪要等零散资料。文章将复盘流程拆为事实归档、时间线整理、证据问题清单、报告草稿生成和人工验证，强调 AI 适合做结构化整理与辅助分析，不能替代日志校验、代码审查和根因判断。同时讨论多模型交叉检查、资料脱敏、安全边界与改进项验收标准，适合研发、SRE 和测试团队参考。

线上故障复盘最耗时间的地方，往往不是写最后那份报告，而是把零散资料拼起来：告警截图、监控曲线、发布记录、群聊结论、工单备注、接口日志、用户反馈、回滚操作……每个人手里都有一部分事实，但没有人一开始就拿到完整时间线。

我最近更倾向于把 Gemini 3.5 Flash 放在这类“资料初筛和结构化整理”环节。它的优势不是替 SRE 或研发负责人下结论，而是速度快，适合把大量脱敏文本、会议纪要、操作记录整理成可讨论的草稿。如果团队需要在同一任务下比较 ChatGPT、Claude、Gemini、DeepSeek、Grok 以及多模态模型的输出差异，也可以了解镜像站，如 https://ouai.me，这类多模型聚合工具；它支持多个主流模型切换，并已集成字节 Seedance 2.0 和 ChatGPT Image 2.0，可直接用于视频生成、图像生成、图片编辑和视觉素材制作。不过工具只是辅助，故障复盘最终仍要回到日志、监控、代码和人工 Review。

本文以一次“支付回调延迟导致订单状态更新不及时”的复盘为例，记录一个比较适合技术团队落地的 AI 辅助流程：先整理事实，再生成问题清单，然后形成复盘报告草稿，最后用可验证证据逐条校验。

场景：支付回调延迟引发的订单异常

假设某业务在一次版本发布后，出现部分订单支付成功但页面仍显示“待支付”的问题。客服反馈用户投诉增加，监控上看回调消费延迟升高，研发群里也出现了多个判断：

• 可能是 MQ 消费堆积；
• 可能是支付回调接口响应慢；
• 可能是新版本改了订单状态流转；
• 可能是某个租户的流量异常；
• 回滚后延迟下降，但仍有少量订单未修复。

这类问题如果直接让 AI “帮我写一份故障复盘”，结果很容易看起来完整、实际不可靠。更稳的做法是把任务拆成四步：

1. 事实归档；
2. 时间线整理；
3. 原因假设与证据绑定；
4. 复盘报告生成与人工验证。

Gemini 3.5 Flash 更适合前两步和部分第三步，尤其是把杂乱记录转成结构化表格。

第一步：先让模型只做事实整理

输入给模型前，资料必须脱敏。生产日志中的用户 ID、手机号、订单号、支付流水号、IP、Token、内部域名都应替换成占位符。比如：

真实订单号：202506261234567890
脱敏后：ORDER_001

真实租户：某某集团
脱敏后：TENANT_A

第一轮 Prompt 不要问原因，只要求整理事实：

你是一个 SRE 复盘资料整理助手。

下面是一次支付回调延迟事件的脱敏资料，包括告警记录、发布记录、群聊纪要、监控摘要和人工操作记录。

请只做事实整理，不要推断根因，不要生成复盘结论。

输出要求：
1. 按时间顺序整理事件时间线；
2. 每条记录标明来源：告警、监控、发布、日志、人工操作、用户反馈；
3. 标出信息是否完整；
4. 对不确定内容标记为“待确认”；
5. 不要补充原文没有出现的信息；
6. 使用 Markdown 表格。

资料如下：
【粘贴脱敏后的资料】

一个可用的输出大概长这样：

这里的价值不是让模型“判断谁的问题”，而是把散落在多个渠道里的事实先放到同一张表里。CSDN 的读者大多经历过类似场景：复盘会开不下去，不是因为没有人发言，而是大家对事实基线不一致。

第二步：生成“证据绑定”的问题清单

时间线整理完后，可以让 Gemini 3.5 Flash 生成问题清单。但要注意，不是让它猜根因，而是让它把每个假设需要什么证据列出来。

基于上面的事件时间线，请生成故障分析问题清单。

要求：
1. 按系统层面分组：应用、MQ、数据库、发布变更、外部支付渠道、补偿任务、灰度策略；
2. 每个问题都要给出需要验证的证据；
3. 标注优先级 P0/P1/P2；
4. 不要直接给根因结论；
5. 不要使用“可能是系统问题”这类泛泛表述。

输出示例：

这一步很适合快速准备复盘会材料。它能帮主持人把讨论从“我感觉是哪里慢”拉回到“我们需要看哪组证据”。

第三步：让模型生成复盘草稿，但必须保留证据字段

很多团队的复盘报告最大问题是结论写得很顺，但证据链不清楚。建议让模型输出时固定包含“证据”和“待补充证据”。

请基于已确认的时间线和证据，生成一份故障复盘报告草稿。

已确认事实：
- 10:05 支付回调消费延迟升高；
- 10:20 新版本发布完成；
- 10:31 MQ 堆积达到峰值；
- 10:45 执行回滚；
- 11:05 延迟下降，但仍有部分订单未恢复；
- 已确认新版本修改了订单状态更新逻辑；
- 已确认部分消息消费失败后未进入补偿队列。

输出结构：
1. 事件概述；
2. 影响范围；
3. 时间线；
4. 根因分析，必须包含证据；
5. 处置过程；
6. 遗留问题；
7. 改进项；
8. 待补充证据。

不要编造具体数据，没有数据的地方写“待补充”。

比起一次性生成完整报告，这种写法更适合团队协作。研发、测试、SRE、产品都能在各自负责的字段里补证据，而不是围绕一篇“看起来很像复盘”的文章争论。

一个可复用的处理流程

技术团队可以把这套流程固化成一个轻量脚本或内部规范：

pseudo

function buildIncidentReview(rawMaterials):
    sanitized = sanitize(rawMaterials, rules=[
        "remove_user_info",
        "mask_order_id",
        "mask_token",
        "mask_internal_domain",
        "replace_customer_name"
    ])

    timeline = ai.extractTimeline(sanitized, constraints={
        noRootCauseGuess: true,
        markUncertain: true,
        sourceRequired: true
    })

    questions = ai.generateEvidenceQuestions(timeline, groups=[
        "application",
        "mq",
        "database",
        "release",
        "external_service",
        "compensation_job"
    ])

    evidence = humanCollectEvidence(questions)

    draft = ai.generateReviewDraft(timeline, evidence, constraints={
        noFakeData: true,
        evidenceRequired: true,
        missingDataAsTodo: true
    })

    verified = humanReview(draft, checks=[
        "logs_match",
        "metrics_match",
        "code_diff_match",
        "timeline_match",
        "owner_confirmed"
    ])

    return verified

这个流程里，AI 主要负责整理和生成草稿。证据收集、根因确认、责任边界、改进项优先级，仍然需要工程团队判断。

模型能力对比：Gemini 适合快，不代表所有环节都交给它

在故障复盘场景里，多模型对比的意义不是评选“谁更聪明”，而是看谁更适合某个环节。

如果故障比较复杂，我会让 Gemini 先整理事实，再用 Grok 或 Claude 做反向质疑：有没有忽略外部依赖？有没有把相关性误当因果？最后让熟悉系统的人回到监控和代码确认。

AI 输出怎么验证

1. 时间线必须能对应原始记录

每个时间点都要能找到来源：告警平台、监控截图、发布系统、日志查询、人工操作记录。找不到来源的内容不能写成事实，只能标记为“待确认”。

2. 根因必须有证据链

一条合格的根因结论至少应该包含：

• 触发条件；
• 代码或配置变更；
• 指标变化；
• 日志证据；
• 复现或推演结果；
• 为什么回滚有效或无效。

如果只有“发布后出现问题，所以是发布导致”，这还不是根因，只是时间相关。

3. 改进项要能落到负责人和验收标准

复盘里常见的空话是“加强监控”“完善测试”“优化流程”。建议改成：

AI 可以生成初稿，但验收标准要由团队确认，否则复盘很容易停留在文档层面。

多模型工具的判断标准

选择多模型 AI 工具时，我更关注这些实际能力：

1. 是否能在同一份材料上快速切换不同模型；
2. 是否支持较长文本输入和多轮上下文；
3. 是否方便保存 Prompt、输出版本和人工修改记录；
4. 是否能稳定输出表格、时间线、任务清单；
5. 是否支持文本、图像、视频任务衔接；
6. 是否便于团队进行脱敏、归档和复核；
7. 是否能帮助比较不同模型对同一问题的差异，而不是只给一个答案。

对故障复盘来说，工具的价值是缩短资料整理时间，不是替代工程判断。

风险边界

使用 AI 处理故障资料时，边界要非常明确：

• 不上传未脱敏的生产日志；
• 不上传 Token、密钥、Cookie、数据库连接串；
• 不上传真实用户隐私、订单信息、支付流水；
• 不上传客户名称、合同信息、内部 SLA 等敏感资料；
• AI 生成的根因结论必须由研发和 SRE 验证；
• 涉及安全、资损、合规的问题，不能只依赖模型判断；
• 如果使用 AI 生成复盘配图、流程图或培训视频，需要检查版权、商标、内部信息暴露和平台规范。

特别要注意，模型会把不完整信息组织得很有条理。条理清楚不等于结论正确。

FAQ：几个常见误区

1. Gemini 3.5 Flash 能直接写最终复盘报告吗？

可以生成草稿，但不建议直接发布或归档。最终报告必须经过日志、监控、代码 diff、发布记录和相关负责人确认。

2. 故障日志能不能直接粘给 AI？

不建议。至少要先脱敏，去掉用户信息、订单号、Token、内部域名、IP、客户名称等敏感内容。必要时只提供摘要和指标变化。

3. 单一模型够不够？

普通资料整理通常够用。涉及复杂根因、多个系统交互或资损问题时，建议使用不同模型交叉检查，再由工程团队验证。

4. AI 生成的改进项为什么经常很空？

通常是输入缺少约束。Prompt 里要要求输出负责人、验收标准、依赖系统和完成证据，否则模型容易生成“加强治理”这类不可执行内容。

5. 多模态模型在复盘里有什么用？

可以用于生成故障时间线图、流程图、培训视频分镜等，但只能作为表达层素材。技术准确性、内部信息脱敏、版权和平台规范仍需人工审核。

总结

Gemini 3.5 Flash 适合放在故障复盘的前半段：整理资料、生成时间线、归类问题、辅助形成复盘草稿。它能减少重复劳动，但不能替代根因分析、代码审查、监控验证和团队决策。

比较稳的落地方式，是从高频、低风险、可验证的任务开始：先让 AI 整理事实，不让它急着下结论；再让它列证据问题，而不是猜根因；最后把生成的报告草稿逐条回到原始记录验证。重要故障可以引入多模型交叉检查，但最终结论一定要建立在真实证据和工程验证之上。