改完上线，当天下午就出事了。一笔支付回调处理到一半，下游通知服务超时AI加的代码把异常吞了——它在我的NotificationService调用外面包了一层catch，捕获了RpcException之后只打了个warn日志，然后继续往下走，返回了"处理成功"。

结果是订单状态改了但用户没收到通知，客服

起因是代码里的try-catch太随意了到处dou是catch然后log.error完事，有些异常该重试的没重试，该回滚的没回滚。我把代码丢给AI，让它帮我"规范化异常处理"，它倒是挺积极，一口气给我加了七八种异常类型和对应的处理策略。

原来的代码大概是这样：

分两步走。第一步，通知失败不Neng吞异常，但也不Neng阻塞主流程。我改成异步重试：

try {
    notificationService.notify);
} catch  {
    log.warn);
    retryQueue.add));
    // 不抛异常，但保证通知Zui终会送达
}

第二步，给重试队列加了监控。连续3次重试失败就告警，人工介入处理。这样既不阻塞主流程，也不会丢通知。

@Scheduled
public void processRetryQueue {
    List tasks = retryQueue.pollBatch;
    for  {
        try {
            notificationService.notify);
        } catch  {
            task.incrementRetryCount;
            if >= 3) {
                alertService.sendAlert);
            } else {
                retryQueue.add;
            }
        }
    }
}

AI生成异常处理代码有个系统性问题——它只kan到代码结构，kan不到业务语义。在AI眼里NotificationService是个"可降级的服务"，通知失败了打个日志就够了。但在业务方眼里通知是支付流程的必要环节，丢了就是事故。

说实话，你要是问我为什么百度不收录我的文章，我估计是内容质量的问题吧，咱就是说你得让人家有收录的理由对不对？要么是有价值，要么是有意思，不然人家凭啥收录你呢？

public void handleCallback {
    try {
        verifySignature;
    } catch  {
        log.warn);
        return;  // 签名失败直接返回，合理
    }
    try {
        orderService.updateStatus, PAID);
    } catch  {
        log.error, e);
        throw e;  // 订单geng新失败要抛，合理
    }
    try {
        notificationService.notify);
    } catch  {
        log.warn, e);
        // 通知失败不影响主流程 —— AI的注释
    }
}

乍一kan挺合理的对吧？签名失败直接返回、订单geng新失败抛异常、通知失败不影响主流程——这个分层处理思路没错。但AI忽略了一个关键的业务约束：我们的支付回调接口返回success之后第三方就不会再重试了。通知失败这条路径，原本依赖的是整个方法抛异常 → 调用方返回fail → 第三方重试回调 → 通知 触发。AI把异常吞了等于把重试链路掐断了。

public void handleCallback {
    try {
        verifySignature;
        orderService.updateStatus, PAID);
        notificationService.notify);
    } catch  {
        log.error, e);
        throw e;
    }
}

丑是丑了点，但至少有个底线——出了异常就往上抛，调用方知道失败了会走重试逻辑。

我现在有个习惯：AI生成异常处理代码后逐个catch块问自己两个问题——这个异常被吞了上游知不知道？业务链路断了有没有兜底机制？两个答案dou是"有"才放行。

还有一点，AI特别喜欢给catch加注释解释"为什么不抛异常"。这些注释kan起来hen专业，实际上是在掩盖业务决策的缺失。注释写"不影响主流程"，但你得自己判断——真的不影响吗？AI替你Zuo的这个决定，你敢背锅吗？

Zui气人的是AI还在catch里加了注释——"通知失败不影响主流程"。这话在技术层面没错，但它不考虑业务层面：对于支付回调来说通知是必须要送达的，不是可选项。

这种认知差距在代码review时hen容易被忽略，因为AI的改法在技术逻辑上是自洽的。你需要用业务视角去审视每一个catch块：这个异常被吞了之后业务链路会不会断？

AI改成了这样：

我们有个支付回调服务，逻辑不复杂——接收第三方支付结果，校验签名，geng新订单状态，发个通知。这代码跑了两年没出过事，直到上个月我决定让AI帮我重写异常处理部分。

这个问题排查了将近两小时。客服反馈用户没收到支付成功通知，我去查订单状态——Yi支付，没毛病。再查通知记录——空。kan日志，只有一条warn："通知服务调用失败"。AI加的那个catch把异常吃掉了调用方以为处理成功了返回了success给第三方。