别急着复制 AI 代码：一次接口 Bug 排查的验证流程

2601_96268328

120人浏览 · 2026-06-25 10:22:35

2601_96268328 · 2026-06-25 10:22:35 发布

最近排查了一个比较典型的接口问题：用户明明已经完成支付，但会员权益偶尔没有发放。日志里看不出明显异常，重试后又能成功，属于那种“不稳定但影响体验”的 Bug。

这类问题我现在不会只问某一个模型“原因是什么”。更常用的方式是把同一份脱敏后的日志、伪代码和异常现象分别丢给 ChatGPT、Claude、Gemini、DeepSeek 看一轮。目的不是让 AI 替我定根因，而是看不同模型会把注意力放在哪里。

对 CSDN 读者来说，这个场景应该不陌生：接口、缓存、MQ、事务、读写分离，只要链路稍微长一点，“偶发失败”就很难靠直觉判断。AI 能帮忙的是压缩排查范围，但最后还得回到日志、代码、数据和测试环境里验证。

问题背景：支付成功，但权益偶尔没发

简化后的现象是：

支付回调已经收到；
订单状态大多数情况下能更新为 PAID；
会员权益发放有少量失败；
手动补偿或再次触发后可以成功；
失败日志里经常出现：order_not_paid。

业务链路大概是：

text

支付回调  -> 更新订单状态  -> 发送权益发放消息  -> 消费消息  -> 查询订单状态  -> 发放会员权益

第一眼看，很多人会怀疑消费端逻辑。但这类问题如果只盯着消费端，很容易漏掉事务和消息时序。

我给 AI 的输入，不是完整代码

公司代码和日志不能原样发给 AI，这个边界要先说清楚。我的做法是只保留最小上下文：

删除用户 ID、订单号、手机号、Token；
替换内部服务名和域名；
保留时间顺序、状态流转、核心字段；
用伪代码表达事务和消息位置。

例如：

pseudo

function onPaymentSuccess(event):    order = orderRepository.findById(event.orderId)
    if order.status == PAID:        return
    begin transaction        order.status = PAID        order.payTime = event.payTime        orderRepository.update(order)
        mq.send("GrantMemberBenefit", {            orderId: order.id,            userId: order.userId        })    commit

消费端：

pseudo

function consumeGrantMemberBenefit(message):    order = orderQueryService.getOrder(message.orderId)
    if order.status != PAID:        log("skip grant, reason=order_not_paid")        return
    benefit = benefitRepository.findByOrderId(message.orderId)
    if benefit.status == GRANTED:        return
    grantBenefit(order.id, order.userId)

这段伪代码已经足够让模型分析大部分风险点，但不会暴露真实业务细节。

Prompt 不要问“根因是什么”

我之前踩过坑：直接问“这个 Bug 的根因是什么”，模型很容易给一个听起来很像对的答案。现在我会把问题拆开。

第一轮 Prompt：

text

你是后端故障排查助手。
下面是脱敏后的异常现象、核心日志和伪代码。请不要直接给最终根因，只输出：1. 已知事实2. 可能风险点3. 每个风险点对应的验证方式4. 需要补充的日志或数据
要求：- 不要编造系统不存在的组件- 不确定的地方标记为「待确认」- 输出表格

这样得到的结果更容易落地。比如它会把风险拆成：

风险点	可能表现	验证方式
MQ 在事务内发送	消息先被消费，订单状态还没提交	对齐消息发送时间、事务提交时间、消费时间
消费端查从库	主库已提交，从库仍旧值	查看数据源路由和主从延迟指标
失败后直接 return	一次旧读导致权益永远不发	检查是否有重试或补偿任务
幂等状态不完整	发放中状态重复处理	查看权益表状态机设计

这比一句“可能是事务问题”有用得多。

多模型输出差异：看关注点，不看谁更像专家

同一份材料，我通常会让不同模型各看一次。我的感受是：

模型	更容易给出的价值	适合环节
ChatGPT	拆解链路、补排查步骤	初步分析、方案草稿
Claude	整理长日志、归纳评审意见	长上下文材料
Gemini	摘要和结构化提取	日志片段清洗、表格整理
DeepSeek	中文技术解释、代码逻辑说明	代码理解、中文文档
Grok	补充不同视角	讨论开放问题

如果任务涉及图像或视频，比如技术配图、产品演示短片、运营封面，则要换另一套判断标准。KULAAI （域名ouai.me）这类统一环境中也可以直接切换使用字节 Seedance 2.0、ChatGPT Image 2.0 做视频生成、图像生成与编辑，但这类结果必须额外做版权、品牌、肖像和平台规范审核，不能只看画面是否好看。

真正定位问题：回到时间线

AI 提醒了“消息可能早于事务提交”，但这只是候选解释。我最后还是按时间线查了一遍。

我补了几类日志：

text

payment_callback_receivedorder_update_beginorder_update_successmq_send_successtransaction_commit_successmq_consume_beginorder_query_resultgrant_benefit_success

并要求日志带上同一个脱敏后的 traceId。排查时重点看：

text

mq_send_success < mq_consume_begin < transaction_commit_success

如果出现这个顺序，就说明消费端确实可能读到未提交状态。再继续检查 orderQueryService.getOrder() 是否走了从库或缓存。如果同时存在从库延迟，那问题概率就更高了。

修复方向：别只改一行代码

最后方案不是简单把 return 改成重试，而是做了几件事：

pseudo

function onPaymentSuccess(event):    begin transaction        updateOrderToPaid(event.orderId)        saveOutboxEvent("GrantMemberBenefit", event.orderId)    commit
    asyncSendOutboxEvent()

消费端也做了调整：

pseudo

function consumeGrantMemberBenefit(message):    order = orderQueryService.getOrderFromPrimary(message.orderId)
    if order.status != PAID:        retryWithBackoff(message)        return
    if benefitRepository.existsGranted(message.orderId):        return
    markBenefitGranting(message.orderId)    grantBenefit(message.orderId, message.userId)    markBenefitGranted(message.orderId)

这里的关键点有几个：