慢接口排查这件事，大模型很容易做成“看起来很懂”的分析报告。尤其是材料一多：Nginx 日志、应用日志、SQL 片段、APM 截图、线程栈、最近发布记录，全塞进去以后，模型会给出一串常见原因：索引缺失、连接池耗尽、缓存穿透、外部依赖超时。每条都可能对，但也都可能只是套话。

更合理的做法是拆成几步：先收敛现象，再整理证据，再生成排查假设，最后才写修复建议。

这篇只讲一个具体场景：一个 Ja va 后端服务的订单列表接口，在工作日上午 10 点后 P95 从 300ms 涨到 2.8s，偶发 504。团队准备用 ChatGPT 5.6 系列辅助整理排查材料，但不让模型直接拍板“根因是什么”。

先把“慢”定义清楚

很多排查一开始就跑偏，是因为大家说的“慢”不是同一件事。

有人看接口总耗时，有人看 SQL 耗时，有人看前端页面加载，有人看网关超时。模型如果拿到一堆混杂描述，很容易把不同层面的慢混到一起。

一般可以先让 GPT-5.6 Terra 帮忙整理一张现象表，但输入只给经过处理后的指标摘要，不给原始敏感日志。

这张表不复杂，但很有用。它能防止模型和人一起陷入“可能是缓存”“可能是网络”“可能是数据库”的泛泛讨论。

ChatGPT 5.6 系列在排查里的分工

这类问题不会只用一个模型从头问到尾。ChatGPT 5.6 系列里，几个版本适合的位置不太一样。

Sol 更适合看复杂关联，比如“前一晚发布改了查询条件，第二天峰值慢查询增加，执行计划从索引扫描变成全表扫描”。但它越能推理，越要约束输出格式：只能给假设和证据，不允许直接写“根因确定”。

Terra 适合做主力整理，特别是把杂乱材料变成时间线、检查清单、PR 说明。Luna 可以用来做日志格式归类，速度快，但不要让它独立判断复杂根因。

日志先脱敏，再压缩成样本

线上日志不能直接复制给模型。里面可能有手机号、账号、订单号、token、内部 IP、请求头、客户名称。即使只是排查性能，也要先处理。

下面是一个很粗的日志处理脚本，只演示思路。实际项目要按公司规范补规则。

import re
from pathlib import Path
from collections import Counter

MASK_RULES = [
    (r'1[3-9]d{9}', ''),
    (r'[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}', ''),
    (r'(?i)(token|authorization|secret|password)[=: ]+[^s,;]+', r'1='),
    (r'bd{10,}b', ''),
    (r'b(?:d{1,3}.){3}d{1,3}b', '')
]

def mask_line(line: str) -> str:
    for pattern, repl in MASK_RULES:
        line = re.sub(pattern, repl, line)
    return line

def collect_slow_logs(file_path: str, keyword="order/list", limit=80):
    lines = []
    for line in Path(file_path).read_text(encoding="utf-8", errors="ignore").splitlines():
        if keyword in line and ("cost=" in line or "timeout" in line.lower()):
            lines.append(mask_line(line))
    return lines[-limit:]

if __name__ == "__main__":
    samples = collect_slow_logs("app.log")
    Path("slow_order_logs_sample.txt").write_text("n".join(samples), encoding="utf-8")

通常不会把几万行日志交给模型，而是给它三类材料：

• 慢请求样本 50～100 行；
• 错误日志按类型聚合后的数量；
• 同时间段关键指标摘要。

例如先在本地做一层聚合：

def count_error_types(lines):
    counter = Counter()
    for line in lines:
        if "SQLTimeoutException" in line:
            counter["SQLTimeoutException"] += 1
        elif "Read timed out" in line:
            counter["ReadTimeout"] += 1
        elif "Connection is not a vailable" in line:
            counter["ConnectionPool"] += 1
        elif "504" in line:
            counter["Gateway504"] += 1
        else:
            counter["Other"] += 1
    return counter

给模型的是聚合结果和脱敏样本，不是原始日志。这一点省不了。

提示词别问“根因是什么”

如果直接问：

这些日志显示接口变慢，请分析根因。

模型很容易给出一个完整故事。问题是，完整不等于真实。

更建议这样问：

下面是已经脱敏的慢接口排查材料，包括：
1. 指标摘要；
2. 最近发布记录；
3. 慢请求日志样本；
4. SQL 和表结构摘要；
5. 部分执行计划。

请不要直接给最终根因。
请输出：
- 已确认事实；
- 可能假设；
- 每个假设对应的证据；
- 还缺少什么验证材料；
- 下一步验证动作。

要求：
1. 推测必须标为“假设”；
2. 不要补充材料中没有出现的信息；
3. 不要建议直接改生产配置；
4. 涉及 SQL 优化时必须说明需要执行计划验证；
5. 输出 Markdown 表格。

这样输出通常更可用：

这比一段“可能是数据库索引问题”的结论有价值。因为它把下一步该做什么写清楚了。

SQL 优化建议必须回到执行计划

这次排查里，真正可疑的是一个新增条件。简化后的 SQL 类似这样：

SELECT id, order_no, buyer_id, status, amount, created_at
FROM orders
WHERE tenant_id = ?
  AND status IN (?, ?)
  AND buyer_id LIKE CONCAT('%', ?, '%')
  AND created_at BETWEEN ? AND ?
ORDER BY created_at DESC
LIMIT ?, ?;

旧版本只按 tenant_id + status + created_at 查，新版本为了支持后台模糊搜索，加了 buyer_id LIKE '%xxx%'。模型看到这里，一般会建议加索引。但这句话太粗。

更合理的问法是让它列出检查点：

请只检查这段 SQL 的潜在性能问题，不要直接给最终优化方案。
请输出：
1. 哪些条件可能影响索引使用；
2. 需要查看哪些执行计划字段；
3. 哪些优化方案需要压测验证；
4. 哪些方案可能影响业务结果。

可能得到这样的清单：

这里有个不太“讨喜”的观察：模型给出的 SQL 优化建议，很多只能算候选项。比如“加联合索引”听起来正确，但索引顺序、字段选择、数据分布、写入成本都要看实际情况。不能因为模型说了，就直接上生产。

修复方案要写回滚条件

排查到后面，如果确认是模糊搜索导致索引不可用，修复可能有几种：

• 限制 buyer_id 只支持精确查询；
• 改为后缀不带通配的查询；
• 增加专门的搜索字段；
• 引入搜索服务；
• 对后台查询增加时间范围限制；
• 增加合适的组合索引。

这些方案不是纯技术选择。比如限制搜索方式会影响运营使用习惯；增加索引会影响写入；引入搜索服务会增加系统复杂度。可以让 GPT-5.6 Terra 帮忙整理方案对比，但要明确输入条件和验收标准。

最终 PR 描述也可以让模型起草，但内容必须基于已验证结果：

本次改动：
1. 订单列表 buyerId 查询由模糊匹配调整为精确匹配；
2. 查询时间范围限制为 90 天；
3. 补充订单列表导出和查询回归用例；
4. 增加慢查询监控标签。

验证结果：
- 测试环境 50 万订单数据下，P95 从 2.4s 降至 420ms；
- 执行计划使用 idx_tenant_status_created；
- 未发现分页结果顺序异常。

回滚条件：
- 客服后台无法按既有口径查询订单；
- 订单列表错误率超过阈值；
- 数据库写入延迟明显升高。

这种说明比“优化了订单查询性能”更适合进入代码评审。

模型比较要控制变量

如果要比较 ChatGPT 5.6 系列和其他模型在排查任务上的表现，别只看谁写得更像专家。至少固定这几项：

实际使用下来，Sol 更适合生成排查路径，Terra 更适合整理证据和修复说明，Luna 适合做格式化和日志分类。不同模型可以切换，但排查链路不能断：事实、假设、验证、结论，要分层保存。

哪些结论不能让模型定

慢接口排查里，模型可以帮忙整理材料、提示遗漏、生成检查清单、起草 PR 说明。但下面这些内容不适合让它直接决定：

• 生产数据库是否加索引；
• 是否调整连接池、线程池、超时配置；
• 是否改变查询语义；
• 是否扩大字段可见范围；
• 是否对外解释事故原因；
• 涉及金融、医疗、政务、教育、合同等业务的正式口径。

如果系统处理的是金融交易、医疗记录、政务办理、教育评价或合同数据，AI 只能做辅助整理。对外说明、合规材料、客户通知必须由专业人员确认。

如果排查材料里涉及截图、录屏、用户头像、证件图片或运营素材，使用图像、视频、多模态模型前，也要确认版权、隐私、肖像权、商用授权和平台规范。技术排查不等于可以忽略这些边界。

最后看它有没有减少返工

用 ChatGPT 5.6 系列排查慢接口，最有用的不是让它说出一个“根因”，而是让它把排查过程整理得更清楚：

现象定义
  ↓
材料处理
  ↓
事实表
  ↓
假设清单
  ↓
验证动作
  ↓
修复方案
  ↓
回归测试
  ↓
复盘说明

这条链路里，每一步都要能被人复核。日志要脱敏，SQL 要看执行计划，代码要在测试环境验证，监控要有前后对比，修复方案要有回滚条件。

模型给出的内容“可用”，只代表它能帮你省一点整理时间；能不能交付，还要看证据是否完整、验证是否跑过、影响面是否评估清楚。线上问题最怕的不是没有建议，而是建议来得太快，结论下得太早。