线上故障复盘这件事，最容易走向两个极端：要么是把监控截图、日志片段、发布记录一股脑贴进去，篇幅拉得很长，但读下来找不到主线；要么是写得干净利落，“原因、影响、措施”一应俱全，读起来倒是顺，可仔细一看，证据链是断的，甚至把推测直接写成了结论。

一个更稳妥的做法是，把 ChatGPT 5.6 系列放在复盘的前半段来用——整理时间线、归类日志、拆分假设、生成待验证项，而不是直接让它一口气写完最终的复盘报告。当然，如果需要在同一份脱敏故障材料上对比不同模型的输出，也有对应的工具环境，但它在其中只是辅助整理的角色，最终拍板还是得靠研发、运维、安全或业务负责人。

下面用一个比较普通的接口超时故障来举例：某订单查询接口在一次发布之后，P95 延迟突然升高，部分请求出现超时，告警持续了 18 分钟。我们要交付的不是一篇“看起来像复盘”的文章，而是一套清晰完整的东西：时间线、证据表、影响范围、原因候选、修复验证、长期措施和待确认事项。

输入越多，越要限制模型先别下结论

故障复盘的材料通常非常杂乱：

• 监控平台里的延迟、错误率、QPS 曲线；
• 应用日志里的异常栈；
• 网关日志里的状态码和耗时；
• 数据库慢查询记录；
• 最近一次发布的 commit 列表；
• 配置变更记录；
• 群里的临时处置消息；
• 用户反馈或工单摘要。

如果直接让模型“根据这些材料写一份复盘”，它大概率会写出一份看起来很完整的报告：故障背景、影响范围、根因分析、处理过程、改进措施全都有。但这类输出有个隐患——模型会主动填补中间的缺口，把“发布时间接近告警时间”写成“发布导致故障”，把“日志里出现连接池等待”写成“连接池配置不足”。

所以第一轮提示词必须压住它的冲动：

下面是已经脱敏的故障材料，包括监控摘要、日志片段、发布记录和处置记录。

请只整理事实，不要写复盘结论。
输出以下内容：
1. 按时间排序的事件线；
2. 每个事件对应的证据来源；
3. 材料中明确出现的异常现象；
4. 只能算推测、需要验证的点；
5. 缺失但复盘需要补充的信息。

要求：
- 不判断根因；
- 不把时间相近写成因果关系；
- 不扩展材料中没有出现的系统或组件；
- 涉及用户、订单、账号、IP、内部域名的信息只保留脱敏后的占位符。

这一步不是为了省事，而是为了防止后面的复盘建立在“顺滑但没证据”的文本之上。

ChatGPT 5.6 系列适合分段处理

故障复盘对模型的要求，从来不是能不能写长文——而是能不能把事实、假设和结论分清楚。ChatGPT 5.6 系列可以用，但不要把所有环节一次性丢给它。

Sol 适合用来发散排查方向，比如接口变慢可能来自数据库、缓存、下游依赖、线程池、网关限流、配置变化。但它也容易给出看起来确定但未必成立的判断，所以要求它每条都要带上“验证方式”和“反证条件”。

Terra 更适合做表格、归档和脚本。Luna 可以把确认后的结论写成更清楚的复盘文本，但不适合单独承担根因判断的角色。

先做一张时间线，不要先写原因

故障复盘里，时间线应该比原因分析更早出现。原因可以晚点定，但时间不能乱。

示例时间线可以这样整理：

这张表里绝对不要写“10:02 发布导致 10:05 延迟升高”。它们只是相邻事件，真正的因果关系需要更多证据来支撑。

还可以继续让模型生成“时间线缺口”：

请检查上面的时间线，列出复盘仍缺少的信息。
每条包含：缺失信息、可能影响、应该从哪里补。
不要判断根因。

常见缺口包括：发布内容是否涉及该接口、发布前后流量是否变化、数据库是否有同步任务、缓存命中率是否下降、下游服务是否同时抖动。

日志要脱敏后再交给模型

日志里经常夹杂真实用户 ID、订单号、手机号、内部 IP、traceId、接口路径、SQL 参数，甚至偶尔会有 token 或密钥。给模型之前必须做脱敏和裁剪，只保留排查所需的关键字段。

原日志不宜直接使用：

2026-04-18 10:08:11.321 ERROR user=13800138000 order=OD202604180001
host=10.12.3.45 token=xxxxxx query timeout, sql=...

可以处理成：

2026-04-18 10:08:11.321 ERROR user= order=
host= token= query timeout, sql=

如果日志量比较大，可以先写个脚本做简单统计，再把统计结果喂给模型，而不是把整段日志直接上传。

下面是一个简化的 Python 脚本，用来统计脱敏日志中的异常类型和分钟级数量。真实项目要根据日志格式调整，不能直接用于生产日志链路。

import re
from collections import Counter, defaultdict
from pathlib import Path

LOG_FILE = "app-sanitized.log"

ERROR_PATTERNS = {
    "db_timeout": re.compile(r"query timeout|SQLTimeout", re.I),
    "pool_wait": re.compile(r"connection pool wait|wait timeout", re.I),
    "rpc_timeout": re.compile(r"rpc timeout|ReadTimeout", re.I),
    "null_pointer": re.compile(r"NullPointerException", re.I),
}

def minute_of(line):
    match = re.match(r"(d{4}-d{2}-d{2} d{2}:d{2})", line)
    return match.group(1) if match else "unknown"

def classify(line):
    for name, pattern in ERROR_PATTERNS.items():
        if pattern.search(line):
            return name
    if "ERROR" in line:
        return "other_error"
    return None

def main():
    by_type = Counter()
    by_minute = defaultdict(Counter)

    for line in Path(LOG_FILE).read_text(encoding="utf-8", errors="ignore").splitlines():
        error_type = classify(line)
        if not error_type:
            continue
        minute = minute_of(line)
        by_type[error_type] += 1
        by_minute[minute][error_type] += 1

    print("ERROR TYPE SUMMARY")
    for k, v in by_type.most_common():
        print(f"{k}: {v}")

    print("nMINUTE SUMMARY")
    for minute in sorted(by_minute.keys()):
        items = ", ".join(f"{k}={v}" for k, v in by_minute[minute].items())
        print(f"{minute}: {items}")

if __name__ == "__main__":
    main()

脚本输出后，可以让模型整理异常趋势：

下面是脱敏日志统计结果。
请只描述异常类型随时间变化的现象，不要判断根因。
输出：异常类型、峰值时间、持续时间、与告警时间线是否重叠、需要补充的验证材料。

这样做的好处是，模型看到的是统计结果和样例，而不是完整的敏感日志。

根因候选要有“反证条件”

复盘里最容易出的问题就是：原因写得太早，但证据跟不上。可以让 GPT-5.6 Sol 把原因拆成候选项，每个候选项都要有明确的验证方式和反证条件。

这张表比“根因分析”这四个字更有价值。它允许复盘在证据不足的时候保持“未完成”状态，而不是为了文档的完整性硬凑一个结论。

影响范围不能只写“部分用户”

“部分用户受影响”这种描述太粗糙了。复盘里的影响范围至少要能回答：哪个接口、哪段时间、多少请求、错误类型是什么、有没有数据不一致的情况、是否波及外部客户或内部任务。

可以做成这样的表：

如果涉及金融、医疗、政务、教育、合同等敏感业务场景，AI 只能辅助整理影响描述，绝对不能做最终的影响认定。对外说明、监管报送、客户公告这类内容，必须由专业人员和负责人亲自把关。

修复措施要区分临时止血和长期改进

模型生成复盘时，常常把“扩容”“回滚”“优化 SQL”“补监控”放在同一个层级上。实际评审的时候，最好把它们拆开来看。

这里尤其需要注意：模型生成的 SQL、脚本、配置修改，绝不能直接进生产环境。必须经过代码评审、测试环境验证、压测或灰度观察。

复盘草稿只在最后写

等时间线、证据、影响范围、根因候选都经过人工确认之后，再让 GPT-5.6 Luna 帮忙压缩成复盘草稿，这样更稳妥。

提示词可以这样写：

下面是已经人工确认的故障复盘材料。
请整理成面向研发团队内部评审的复盘草稿。

要求：
- 只使用“已确认”的内容写结论；
- “待验证”的内容放到待办项；
- 不夸大影响，不弱化风险；
- 不出现真实用户、订单、IP、密钥、内部域名；
- 修复措施按临时止血、根因修复、防复发拆开。

这样生成的文本仍然需要人工修改。特别是故障责任、影响范围、客户说明、合规措辞这些内容，绝对不能交给模型做最终判断。

多模型对比时，看谁更少乱下结论

如果用统一的模型调用环境来对比不同模型处理复盘材料的表现，建议不要只看谁写得更像正式报告。更好的比较方式是固定变量：

从实际经验来看，复盘场景里，最擅长写完整报告的那个模型不一定最好。能把“证据不足”这四个字留在文档里的模型，反而更接近工程实际。

最后留下可追溯的材料

一次线上故障复盘，最好留下这样一条完整的链路：

脱敏原始材料索引
  ↓
事件时间线
  ↓
证据表
  ↓
影响范围说明
  ↓
根因候选与验证记录
  ↓
修复措施
  ↓
防复发任务
  ↓
最终复盘文档

ChatGPT 5.6 系列在这个过程中能有效减少整理成本，也能帮忙把散乱的日志、监控、发布记录转成结构化的材料。但它并不知道某个操作是不是临时应急，也不知道某条日志背后有没有特殊的业务逻辑。

所以，在故障复盘这件事上，“可用”和“可交付”完全是两回事。模型整理出来的时间线和草稿是“可用”的；经过脱敏、证据核对、测试验证、负责人确认以及后续任务跟踪之后，才勉强接近“可交付”。复盘真正要留下的，不是一段漂亮的文字，而是一条以后还能被复查的证据链。