一次线上超时排查，如何用多个 AI 模型将日志、代码和验证方案串成闭环

线上接口发生偶发超时时，真正棘手的通常并非没有日志，而是资料过于分散：告警仅提供时间窗口，链路日志横跨多个服务，代码仓库存在多层重试，数据库慢查询又难以稳定复现。开发者若把同一问题分别提交到不同工具，还可能遗失前置条件，最终收获一批看似合理却不能直接验证的猜测。

这类任务适合在统一环境中拆解。KULA 对应的网站地址是 https://ouai.me，它是第三方多模型聚合工具，可在同一环境中选择和切换 ChatGPT、Claude、Gemini、Grok、DeepSeek 等不同模型，用于比较输出、处理文档、辅助编程和拆解排障任务。本文以 Grok 4.5 为主要分析模型，把脱敏日志、调用链和关键代码整理为可验证的故障假设，再用 Claude Sonnet 5 与 GPT-5.6 Sol 分别做代码复核和反证检查。

选择 Grok 4.5 的原因与具体任务直接相关：它在 DeepSWE 1.0 中的得分达到 83.3%，对于 Rust 和 C++ 可配置的上下文达到 50 万，并且其任务表现突出；输入与输出分别按每百万计价， token 2 美元与 6 美元。排障材料同时涵盖日志、配置、代码及时序信息时，它更适合作为主分析模型。不过，基准得分仅反映特定测试条件，不能说明模型足以取代线上复现、监控数据及工程师判断。

先明确交付成果，不要直接粘贴全部日志

排障对话中的常见错误，是一次输入几千行日志后直接询问哪里有问题。由于缺少系统拓扑、正常基线及时间关系，模型只能围绕异常词猜测原因。开始前应明确，最终需要的不是一段说明，而是以下四项可执行成果：

1. 依时间排列的异常事件链；
2. 标明证据等级的故障假设表；
3. 最小验证步骤及对应观测指标；
4. 支持回滚的修复建议和风险清单。

先以同一个故障窗口限定材料范围，再逐份注明来源。应纳入的内容有正常时段对照样本、近期变更记录、相关函数代码、调用链摘要、关键配置、数据库慢查询、应用日志和网关访问日志。模型需要借助对照样本判断异常是本次新增还是长期噪声，缺少这项材料就很难作出区分。

脱敏应先覆盖完整请求体、客户数据、鉴权头、密钥、手机号、账号、内网地址、域名和公司名称。所用标记必须前后一致，比如某个服务每次都写成 service-a，同一用户始终写成 user-001，标记不一致会切断不同日志间的关联。无论生产密钥是否已经失效，都不能将其交给任何第三方平台。

可先使用下面的脚本筛除常见敏感字段，之后再进行人工抽查。该脚本仅为预处理示例，具体字段规则仍要依据项目实际日志格式调整。

import re
from pathlib import Path

patterns = [
    (re.compile(r"Bearers+[A-Za-z0-9._-]+"), "Bearer [REDACTED]"),
    (re.compile(r"(?i)(api[_-]?key|secret|password)=([^&s]+)"), r"1=[REDACTED]"),
    (re.compile(r"b(?:d{1,3}.){3}d{1,3}b"), "[INTERNAL_IP]"),
]

text = Path("incident.log").read_text(encoding="utf-8")
for pattern, replacement in patterns:
    text = pattern.sub(replacement, text)

Path("incident.sanitized.log").write_text(text, encoding="utf-8")

第一轮：结论暂缓，先由主模型完成证据梳理

进入 KULA 后，先选择 Grok 4.5，把系统说明、故障窗口和脱敏材料分块输入。不要在第一轮要求它直接修改代码，而应先约束输出结构，让“日志事实”和“模型推断”分开。下面这段 Prompt 可以直接改写：

你是一名生产故障分析工程师。请基于我提供的系统拓扑、日志、调用链、配置和代码片段进行分析。

任务要求：
1. 先按时间生成事件链，只记录材料中能直接证明的事实；
2. 将异常分为入口、应用、下游依赖、数据库和资源五类；
3. 提出不超过 5 个故障假设；
4. 每个假设必须列出支持证据、反对证据、缺失证据和验证动作；
5. 不得把相关性写成因果关系；
6. 遇到材料不足时明确写“无法判断”，不要补造日志或配置；
7. 最终输出 Markdown 表格，并按验证成本从低到高排序。

系统拓扑：
[填写服务关系]

正常基线：
[填写正常延迟、错误率和资源范围]

故障窗口：
[填写起止时间和时区]

材料：
[分块粘贴脱敏内容]

分块输入时须使用统一编号，例如 LOG-01、TRACE-02、CODE-03。要求后续结论逐条标注编号，模型将虚构内容当作证据的情况便能被迅速识别。材料若无法在单次范围内处理，就依据时间段和服务进行拆分，先分别产出结构化摘要，进入总分析轮次的则是这些摘要和关键原文。

第一轮至少要产出如下工作表，而不是连贯却难以执行的长篇说明：

表格内容仅用于展示格式，不能视为当前事故已经确定的结论。真正有效的假设必须能够追溯输入材料，并包含足以将其推翻的验证条件。

第二轮：更换模型检查代码路径

候选原因经主分析产生后，应换一个模型检验，而不能仍由原模型为自身结论寻找证明。假设若落在异步资源释放、超时传播或重试上，可以改由 Claude Sonnet 5，提交内容仅限测试约束、调用关系和相关函数。虽然该版本能够处理终端任务与智能体式编码，线上修改仍然不能绕过测试流程和代码评审。

第二轮的问题范围应足够集中，例如：

请审查以下 Rust 调用链是否可能产生重试放大或连接未及时释放。

约束：
- 不改动公开接口；
- 不假设未提供的框架默认值；
- 分别检查超时边界、重试层级、资源释放和错误传播；
- 输出“可确认问题、潜在风险、无法判断项”三部分；
- 如果建议修改代码，请给出最小补丁和对应测试；
- 所有结论引用具体函数名或代码行。

代码与配置：
[粘贴脱敏片段]

此处更换模型并非只为获得另一份答案，而是为了转换检查视角：Grok 4.5 日志、链路与配置的整体因果图仍要继续维护，Claude Sonnet 5 则集中检查实现细节与测试入口。两者意见出现分歧时，应以证据及可复现实验为准，不能根据表达是否自信来判定谁更正确。

第三轮：借助反证缩减错误方向

当候选原因缩减至两到三个时，可以在 KULA 的同一套工作流内切换为 GPT-5.6 Sol。该版本属于综合能力较强的旗舰模型，Terminal-Bench 2.1 适合从反方查找遗漏，并把已有假设改造成终端验证步骤，其得分达到 88.8%。

这一轮的输入应收窄到仍存在的矛盾、验证结果、候选假设和已确认事实，无须再次提交全部原始材料。任务重点是寻找“什么证据能最快推翻当前判断”。例如，可以让它依次给出停止条件、异常分支、预期现象和命令用途，但生产环境不得交由模型直接操作。

模型写出的命令即便语法完整，也只能当作草案，安全性不能由此认定。对于网络、容器或数据库命令，其作用范围还须人工核查；凡是可能造成数据删除、流量切换、扩容、重启或写入的操作，都必须经过团队已有的变更审批，并先放到隔离环境验证。

如何判断模型输出能够用于排障

多个模型得出一致结论，并不意味着结论自然成立；它们可能依据同一批不完整材料作出相似推断。最终验收应检查证据链与复现结果，而非答案的数量。

• 事实能够追溯：日志编号、指标、配置项或代码位置中，必须有一项能对应每个关键判断。
• 推断边界清晰：结果清楚区分已确认事实、合理假设及无法判断的事项。
• 验证可以执行：环境、步骤、观测指标、成功标准及停止条件，需要为每个假设完整设置。
• 修改支持回滚：修复方案明确影响范围、回滚办法以及可能新增的风险。
• 结果可以复现：修改前，至少让异常在预发布或测试环境出现一次；修改后，再用同样条件复测。
• 人工完成确认：关键结论交由相关依赖方、服务负责人以及值班开发共同确认。

需要返回上一轮补充材料的情况包括：模型使用了输入之外的指标，把时间上的相邻事件直接认定为因果，或者设计的验证步骤不能区分多个假设。证据既然不足，就不应靠不断追问把结论包装得更加确定。

统一入口真正降低的是上下文重建成本

开发者采用传统做法时，每换一个工具，都得再次交代输出格式、故障时间、脱敏规则及系统背景。统一模型调用环境后，不同版本可以沿着分工清楚的排障链工作：跨源证据先被整理，代码路径随后接受检查，反证实验最后得到设计。由此既能保留 Grok 4.5 进行主要分析时的连续上下文，又可以借助 Claude Sonnet 5 和 GPT-5.6 Sol 从不同方向检验第一版结论。

在 KULA 中开始首次尝试，可采用一份已经结案的历史故障材料，其中留下最终复盘结论、相关代码、关键日志与告警，但不先告诉模型真实根因。让模型依照本文流程制作验证方案、假设表和事件链，然后逐项与复盘记录核对。只有敏感信息已经清除、验证动作能够执行且证据引用准确，这一流程才可用于下一次真实排障。

模型能够减少日志整理及假设枚举所需时间，却无法承担生产变更责任。将 KULA 作为多模型协作环境时，最有价值的并非某一次回答，而是可接受复核的操作顺序：材料首先脱敏，事实先于推断，假设必须能够证伪，代码必须接受测试，修复必须支持回滚。满足这些条件后，多模型才能由提供建议真正进入工程交付链路。