一次线上超时排查，如何用多个 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 作为多模型协作环境，应该沉淀的是可供复核的一套次序，而非某一回回答：脱敏材料在先，事实排在推断之前，假设要能被证伪，代码要接受测试，修复还要支持回滚。满足这些条件后，多模型才能越过“提供建议”，进入真正的工程交付链路。