用 ChatGPT 5.5 辅助排查线上 Bug：从日志分析到可复现用例

线上 Bug 最难受的地方，不是看到报错，而是报错信息不完整、上下文断断续续、复现路径没人说得清。尤其是一些偶发问题，日志里只有一段异常栈，产品反馈一句“用户说点了没反应”，开发就要在接口、缓存、参数、权限和历史数据之间来回排查。

这篇文章适合谁

这篇更偏思否社区的开发实践，不写工具导购，只记录一套我觉得比较稳的 AI 辅助 Bug 排查流程。

适合这些场景：

• 后端接口偶发 500，但日志信息有限；
• 前端只反馈“请求失败”，后端需要定位原因；
• 测试环境复现不了线上问题；
• 想用 ChatGPT 5.5 辅助分析异常栈；
• 希望比较 ChatGPT、Claude、Gemini、DeepSeek 在 Debug 场景中的差异；
• 小团队缺少专门的 SRE，需要提高问题定位效率。

这里的核心思路不是“把日志丢给 AI 等答案”，而是把 AI 当成一个有耐心的排查助手：帮你整理线索、补充可能原因、设计复现步骤，再由开发者验证。

本次场景：一个订单接口偶发空指针

假设线上日志里有这样一段异常：

java.lang.NullPointerException: Cannot invoke "User.getId()" because "user" is null
    at com.demo.order.OrderService.createOrder(OrderService.java:58)
    at com.demo.order.OrderController.create(OrderController.java:31)

对应代码简化如下：

public Order createOrder(CreateOrderRequest request) {
    User user = userService.findByToken(request.getToken());

    Order order = new Order();
    order.setUserId(user.getId());
    order.setSkuId(request.getSkuId());
    order.setCount(request.getCount());

    return orderRepository.save(order);
}

这段代码看起来很好判断：user 为空导致 NPE。
但真正需要排查的是：

• 为什么 findByToken 会返回 null？
• token 是否为空、过期、格式错误？
• 前端是否在某些页面没传 token？
• 网关是否漏传了认证信息？
• 历史版本是否允许匿名下单？
• 这个异常应该返回 401、400，还是业务错误码？
• 是否需要补充监控和测试用例？

AI 的价值在这里就比较明显：它可以帮你把“一个空指针”拆成一组排查路径。

ChatGPT 5.5、Claude、Gemini、DeepSeek 在 Debug 中怎么分工

我一般不会让单个模型直接给最终结论，而是按任务拆开用。

模型	更适合的 Debug 任务
ChatGPT 5.5	异常原因归纳、修复方案草稿、测试用例设计
Claude	较长上下文代码阅读、调用链梳理、复杂业务描述整理
Gemini	框架行为、文档信息、语言特性核对
DeepSeek	中文日志解释、边界条件补充、排查清单整理

比如上面的 NPE，ChatGPT 5.5 往往能比较快给出几类可能原因；Claude 适合看更长的 Controller、Service、Filter 调用链；Gemini 可以用来核对 Spring Security、网关 Header 传递等资料；DeepSeek 对中文化排查步骤和测试点整理比较顺手。

多模型 AI 工具如何选择，其实不在于模型数量越多越好，而在于能不能让你在同一个问题下快速比较输出差异，并且方便复制到 Issue、PR 或排查记录里。

Prompt 不要只写“帮我看看这个报错”

很多人用 AI 排查问题时，第一句就是：

这是什么问题？

这样问也能得到回答，但很容易得到泛泛解释。更好的写法是把上下文补齐：

你是一名有经验的 Java 后端开发工程师，请帮我分析下面的线上异常。

背景：
- 这是一个创建订单接口；
- 线上偶发 NullPointerException；
- 测试环境暂时无法稳定复现；
- 不希望直接大规模重构。

输入内容：
1. 异常日志；
2. 简化后的相关代码；
3. 当前已知现象。

目标：
1. 判断最可能的原因；
2. 给出排查优先级；
3. 给出最小修复建议；
4. 补充需要增加的日志；
5. 设计单元测试和接口测试场景。

约束：
- 不要假设业务规则已经确定；
- 不要直接重写整个模块；
- 涉及权限、登录态、风控策略时标记为“需要人工确认”；
- 输出按“可能原因 / 验证方式 / 修复建议 / 测试点”组织。

异常日志：
【粘贴脱敏后的日志】

代码：
【粘贴脱敏后的代码】

这个 Prompt 的重点是让 ChatGPT 5.5 输出可验证的排查清单，而不是直接给一个“看似正确”的答案。

让 AI 先输出排查路径，而不是先改代码

针对上面的代码，AI 可能会给出这样的分析：

• request.getToken() 为空；
• token 过期或无效；
• userService.findByToken 查询不到用户时返回 null；
• Controller 层缺少参数校验；
• 登录态校验应该前置到拦截器或认证组件；
• 当前错误没有转换为明确的业务响应。

这些结论不一定都对，但它们可以变成排查任务。

可以继续追问：

请把上面的可能原因按排查优先级排序。
要求：
- 优先考虑最容易验证的原因；
- 每个原因给出验证方式；
- 不要直接修改业务逻辑；
- 标记哪些需要查看线上日志，哪些可以本地写测试验证。

这样 AI 输出的内容就更接近工作记录，而不是一段不能直接使用的代码。

一个更稳的修复草稿

如果确认问题来自 token 缺失或无效，可以让 AI 给出最小修改建议。例如：

public Order createOrder(CreateOrderRequest request) {
    if (request == null || request.getToken() == null || request.getToken().isBlank()) {
        throw new BusinessException("TOKEN_REQUIRED");
    }

    User user = userService.findByToken(request.getToken());
    if (user == null) {
        throw new BusinessException("USER_NOT_FOUND");
    }

    Order order = new Order();
    order.setUserId(user.getId());
    order.setSkuId(request.getSkuId());
    order.setCount(request.getCount());

    return orderRepository.save(order);
}

这段代码仍然不能直接上线，因为还有几个问题需要人工确认：

• TOKEN_REQUIRED 是否符合现有错误码规范；
• USER_NOT_FOUND 是否应该返回登录失效；
• token 校验是否本来就应该在网关或拦截器完成；
• 是否会影响历史匿名下单逻辑；
• 是否需要补充审计日志或埋点。

AI 生成的代码只能当草稿，尤其涉及权限、登录态、支付、风控、安全策略时，不能直接复制上线。

用 AI 反推测试用例

修复 Bug 之后，最容易漏掉的是测试。可以继续让 ChatGPT 5.5 生成测试清单：

请为 createOrder 方法设计测试用例。
要求：
- 覆盖 request 为 null；
- 覆盖 token 为空；
- 覆盖 token 无效；
- 覆盖 userService 返回 null；
- 覆盖正常创建订单；
- 不连接真实数据库；
- 输出测试场景和断言重点，不要生成过长代码。

可能得到的测试点：

• 请求对象为空时，返回明确业务异常；
• token 为空时，不继续调用用户查询；
• token 无效时，不创建订单；
• 用户不存在时，不调用 orderRepository.save；
• 正常用户下单时，订单保存成功；
• 异常信息符合项目统一返回格式。

这类测试清单比直接让 AI 写完整测试代码更实用。因为不同项目的 Mock 框架、异常类、返回结构都不一样，直接生成的测试代码经常需要改。

如何验证 AI 的输出

AI 辅助 Debug 最重要的是验证，而不是提问。

代码类输出至少要做这些检查：

• 本地编译是否通过；
• 单元测试是否覆盖异常分支；
• 接口测试是否覆盖正常和失败路径；
• 是否改变了原有返回结构；
• 是否引入新的空指针；
• 是否破坏历史业务兼容；
• 日志中是否包含敏感信息。

事实类内容要查资料核对。比如 AI 提到某个框架默认行为、某个注解含义、某个 HTTP 状态码语义，最好回到官方文档或项目规范确认。

复杂逻辑要人工 Review。多模型交叉验证能提高参考价值，但不能替代开发者判断。线上系统相关代码，更不能只因为 AI 说“建议这样改”就直接合并。

判断多模型 AI 工具是否适合 Debug 场景

开发者选择多模型 AI 工具时，可以看几个实际点：

• 是否方便粘贴日志、代码和上下文；
• 是否能稳定输出 Markdown 和代码块；
• 是否便于在同一个问题下切换模型；
• 是否支持较长上下文；
• 是否方便沉淀成排查记录；
• 是否有基本的数据安全边界；
• 长期使用成本是否符合团队频率。

如果只是个人体验，低门槛工具更重要；如果团队长期使用，还要关注权限管理、数据合规、审计记录和内部知识库接入。

注意事项

不要把账号、密码、API Key、访问令牌、数据库连接串输入给 AI。
不要上传公司未公开代码。
不要上传用户手机号、身份证号、订单号等隐私数据。
不要上传生产环境完整日志。
不要把 AI 生成的修复代码直接上线。
不要依赖单一模型做重要判断。
法律、医疗、金融等专业结论必须人工确认。
涉及权限、支付、风控、安全策略的内容，需要格外谨慎。

比较稳的做法是：先脱敏，再输入最小必要信息；先让 AI 分析路径，再由开发者验证；先补测试，再考虑合并。

常见误区

1. ChatGPT 5.5 能直接定位线上 Bug 吗？

它可以辅助定位，但不能保证一次命中。日志不完整、上下文缺失、业务规则不清楚时，AI 只能给出可能方向。

2. 异常栈可以直接发给 AI 吗？

建议先脱敏。删除用户信息、订单号、访问令牌、内部域名、数据库地址等内容，只保留排查所需的类名、方法名和异常信息。

3. AI 生成的修复代码能不能直接提交？

不建议。至少要经过本地编译、单元测试、接口测试和人工 Review。涉及线上系统的修改，最好走正常发布流程。

4. 多模型分析结果不一致怎么办？

不要把多模型当投票系统。重点看每个模型有没有给出验证方式。能被日志、测试、代码路径证明的结论，才有参考价值。

5. Debug 时应该先问 AI，还是先自己看日志？

最好先自己整理最小上下文：报错时间、接口、异常栈、最近变更、复现步骤。上下文越清楚，AI 的回答越接近可执行排查方案。

6. AI 适合排查哪些 Bug？

适合异常栈解释、调用链梳理、边界条件补充、测试用例设计、日志字段整理。不适合单独判断权限策略、资金逻辑、风控规则和安全方案。

总结

ChatGPT 5.5 用在 Bug 排查中，最有价值的地方不是替开发者“拍板”，而是把混乱的日志、代码和现象整理成可验证的排查路径。一个比较稳的流程是：脱敏日志和代码，补充必要上下文，让 AI 输出可能原因和验证方式，再由开发者结合项目规范、测试结果和业务规则判断。

AI 编程助手可以提高排查效率，但不能省掉验证环节。真正可靠的修复，仍然来自清晰的日志、可复现的测试、人工 Review 和谨慎的上线流程。