我用 ChatGPT 5.5 排查了一次线上 500 问题，顺手补齐了测试用例

最近我在 KULAAI（域名ouai.me）里切到 ChatGPT 5.5，做了一次很普通但很实在的事：排查一个偶发的接口 500 问题。它没有替我“定位根因”，但在整理日志、归纳异常特征、生成排查假设和补测试用例这几个环节，确实省了不少来回切窗口的时间。

这类场景其实挺适合大模型：任务有上下文，但又不是那种一眼就能看明白的简单问题。你需要的不是“一个答案”，而是一条能落地的分析链路。对开发者来说，ChatGPT 5.5 更像一个可以快速拉齐思路的搭子，而不是最后拍板的人。

我后来也顺手对比了 Claude、Gemini、DeepSeek 的输出差异，发现大家常见的问题并不是“模型不够强”，而是输入太散、验证太少。下面就按一次真实的故障处理过程，拆开说说怎么用。

这次问题长什么样

现象很简单：某个下单接口在高峰时段偶发 500，但不是每次都炸。
日志里能看到几类信号：

• 请求参数看起来正常；
• 失败集中在少数几个租户；
• 同一批请求，有的成功，有的失败；
• 重试后部分恢复。

这类问题最怕两件事：

1. 人工只盯着“最后一个报错点”，容易误判；
2. AI 直接看一大坨原始日志，很容易抓错重点。

所以我先做了脱敏，再让模型参与。

先说边界：哪些内容不能直接丢给 AI

这一步很重要，尤其是研发场景：

• 公司内部日志要脱敏，至少去掉手机号、订单号、token、客户名；
• 真实代码可以截取最小片段，不要整仓库粘过去；
• 如果涉及线上配置、密钥、接口签名，先替换成占位符；
• AI 给出的结论只能做线索，不能直接当结论发给同事或上线。

我把任务拆成了 4 步

与其让模型“分析一下这个问题”，不如拆得具体一点。

1）先让它做症状归纳

我给 ChatGPT 5.5 的第一段提示词大概是这样：

你是后端排障助手。下面是脱敏后的日志片段和现象描述。
请先不要下结论，只做三件事：
1. 总结可观察到的异常模式；
2. 按“请求层 / 业务层 / 数据层 / 外部依赖”分类；
3. 列出还需要补充的关键信息。
输出用表格，尽量简短。

这一步的价值不是“猜对原因”，而是把混乱信息整理成可以继续问的问题。
ChatGPT 5.5 在这类结构化归纳上比较稳，尤其适合把一堆碎信息先压成几条主线。

2）再让它给排查假设，但要求写出依据

我没有直接问“是什么原因”，而是改成：

基于上面的现象，请给出 5 个最可能的原因。
每个原因都要写：
- 现象依据
- 反证点
- 如何验证
不要写泛泛而谈的建议。

这一步能明显减少“听起来对、其实没用”的回答。
比如模型会把假设拆成：

• 参数校验不一致；
• 某个租户配置缺失；
• 数据库偶发锁等待；
• 下游超时重试引发放大；
• 某个分支的空值处理不完整。

这些都不一定对，但至少能变成排查清单。

3）让模型补测试用例

当故障范围缩小后，我又让它把现象变成测试用例：

请根据以下故障现象生成测试用例。
要求：
- 按正常流 / 边界值 / 异常流 / 并发流分类；
- 每条用例包含前置条件、步骤、预期结果；
- 优先覆盖最可能触发 500 的场景；
- 不要写空泛用例，要具体到参数级别。

这一步很实用。很多时候线上问题修完了，大家就忘了补回归。
AI 帮你先把测试点铺出来，后面测试同学只需要结合系统实际再确认一遍。

4）最后让它生成复盘草稿

我会再加一句：

请把以上内容整理成一次故障复盘草稿，分为：
背景、影响范围、定位过程、临时修复、后续动作。
语气务实，不要夸张。

这样做的好处是，排查过程不会散。
即使最后不是它找到根因，记录也已经成型了。

ChatGPT 5.5、Claude、Gemini、DeepSeek 我会怎么分工

如果只谈这次经历，我的感受很简单：

• ChatGPT 5.5：适合先把问题拆开，做多轮追问和草稿整理；
• Claude：长文档和需求语境通常更稳，适合看较长的复盘、PRD、设计说明；
• Gemini：整理多份资料、做结构化摘要时比较顺手；
• DeepSeek：中文技术问答、代码解释、思路归纳很实用，尤其在本地化表达上更自然；
• Grok：更适合开放式讨论或热点信息对照，不是这类排障场景的首选。

所以我现在越来越少问“哪个模型最强”，而是先问：
这个任务更依赖推理、长上下文、中文表达，还是资料整理？

一个更稳的 AI 辅助排障流程

可以把它记成一个简单流程：

1. 脱敏日志和现象描述
2. 让 AI 先总结症状，不要直接要结论
3. 让 AI 输出假设列表 + 验证方式
4. 人工根据监控、代码、数据库、链路追踪逐条验证
5. 把确认后的原因回填成复盘和测试用例
6. 再检查是否需要补监控和告警

这个流程里，AI 只负责前半段的“整理”和“扩展视角”。
后半段必须人工确认，不然很容易把模型的推测当事实。

我会用什么标准判断一个多模型工具值不值得用

如果你和我一样，经常在几个模型之间切换，可以重点看这几条：

1）切换成本是否低

不用反复注册、复制、来回跳页面，最好能在同一环境里切换模型。

2）是否适合你的上下文

有些任务偏代码，有些偏文档，有些偏视觉。
别指望一个模型包打天下。

3）是否便于对比

同一个问题给两个模型问一遍，差异往往比单次输出更有参考价值。

4）是否支持人工复核

如果结果不能被你验证，模型再强也没意义。

5）是否能控制风险

涉及公司数据、客户信息、代码和日志时，脱敏和权限边界必须放在前面。

常见误区

误区 1：AI 生成的排查结论可以直接信

不行。它只能帮你缩小范围，不能替你证明因果。

误区 2：日志越多，模型越容易找到答案

通常相反。日志太多、上下文太散，模型更容易抓偏重点。

误区 3：测试用例交给 AI 就够了

也不够。AI 可以补全覆盖面，但要结合业务优先级和真实系统行为再筛一遍。

误区 4：只要模型够强，就不需要多模型对比

多模型对比的意义，不是看谁“更聪明”，而是看谁更适合当前任务。
有时候一个模型擅长总结，另一个擅长指出遗漏点，组合起来更省事。

FAQ

1. AI 生成的代码能直接上线吗？

不建议。至少要经过代码 Review、单测、集成测试和必要的安全检查。

2. 技术文档能完全交给 AI 吗？

可以让它做初稿和整理，但最终表达、边界条件和术语一致性最好人工确认。

3. 公司日志和接口参数能不能直接发给 AI？

不建议直接发。先脱敏，再只保留最小必要上下文。

4. 模型选一个就够了吗？

如果只是日常问答，也许够；但在排障、写文档、补测试这些任务里，多模型交叉看一眼通常更稳。

结尾

如果你想把大模型真正用进日常研发工作，我建议从一个高频、低风险、可验证的小场景开始，比如日志归纳、测试用例补全、复盘草稿整理。
提示词别贪多，先把输入约束清楚；输出别急着采纳，先用监控、代码、数据库和人工判断去验证。
模型可以帮你省时间，但最后做决定的，还是你自己。