从"帮我看看"到"帮我修"：AI 辅助调试的心路历程

引子

我以为AI辅助调试的效率瓶颈是"AI看不懂代码"。后来才发现，真正的瓶颈是"AI看得太快，还没看懂就动手了"。

“你再检查一下，这个逻辑在平台A、平台B、平台C、视频号平台都验证过了，没有这个问题。”

当我看到这条消息时，我意识到自己又犯错了。

事情的起因是某个电商平台切换快递时出现了一个错误：“增值服务与原单增值服务不一致，取号操作不支持更新”。我看到这个错误，第一反应是：新代码缺少清理历史运单号的逻辑。于是，我在订单处理的公共方法上直接添加了清理历史运单号的代码。

我以为这是正确的修复方式，但用户的一句话让我停了下来。

第一次犯错：自作主张的"特殊通道处理"

在平台架构升级的过程中，我在取号服务的方法中添加了一段逻辑：

// 快递J特殊处理：平台A不支持快递J的编码，需要强制走专用通道if(ExpressType.J_CODE.equals(orderInfo.getLogisticsCode())&&!PlatFormType.PLAT_J_CODE.equals(orderInfo.getSourcePlatFormCode())){orderInfo.setSourcePlatFormCode(PlatFormType.PLAT_J_CODE);orderInfo.setSourcePlatFormName(PlatFormType.PLAT_J_DISPLAY_NAME);}

我的理由是：当前平台切换到快递J时，需要将来源平台标识改为"J"，这样才能走快递J的专用策略。

但用户看到后说：“你先检查一下，是不是主动加的逻辑，如果主动加的是不行的。”

我查看了原始处理方法OrderManager.modifyLogistics，发现原始方法中根本没有这段逻辑。原始方法只设置物流编码，不修改来源平台标识。

我犯了一个错误：没有先检查原始方法的行为，就直接添加了新逻辑。

用户说：“原逻辑主要以OrderManager里的内容为准，新的架构是增加产品信息的逻辑，但是核心逻辑不可以改。”

我删除了这段代码。

如果重来一次，我不会直接写代码，而是先问：原始方法是怎么处理快递J的？当前平台和其他平台在这个点的区别是什么？理解了这两点，再决定要不要加逻辑。

第二次犯错：在公共方法上"打补丁"

某个平台切换快递时出现了错误：“增值服务与原单增值服务不一致，取号操作不支持更新”。我看到这个错误，认为是新代码缺少清理历史运单号的逻辑。

于是，我在订单处理的公共方法上直接添加了清理历史运单号的代码：

privatevoidprocessOrder(LongorderId,StringexpressCode,StringproductCode){OrderInfoorder=dataService.load(OrderInfo.class,orderId);orderValidator.checkOrderNotInBatch(order);orderValidator.updateAndPersistExpressInfo(order,expressCode);if(order.getIsOffLine()){return;}// 我添加的代码order.setExceptionReason(null);orderValidator.cleanAndPersistHistoryBillCodes(order);// 调用取号流程fetchWaybillCode(order,productCode);}

我以为这是正确的修复方式。

但用户说：“你再检查一下，这个逻辑在平台A、平台B、平台C、视频号平台都验证过了，没有这个问题。你加上这个清理历史运单号的，应该不对，你在持久化的地方看下，是否有变更，不是在原代码上直接加到方法上，这样会影响到原来的逻辑。这个是多个平台都会调用的。”

我愣住了。

我犯了第二个错误：没有考虑这个方法是多个平台都会调用的，直接在公共方法上添加逻辑。

用户让我检查各个平台的持久化逻辑。我发现持久化处理方法中已经调用了清理历史数据的方法。清理逻辑已经在正确的地方处理了，我不需要在公共方法上额外添加。

更关键的是，用户提供了原始方法的日志：

com.vtradex.thorn.server.exception.BusinessException: 获取运单号出错:{"error_response":{"error_msg":"业务服务错误","sub_msg":"增值服务与原单增值服务不一致，取号操作不支持更新","sub_code":"2033","error_code":50001,...}}

原来，原始方法也有同样的问题。这不是新代码引入的问题，而是该平台本身的限制。

我删除了添加的代码。

如果重来一次，我不会直接在公共方法上打补丁，而是先问：这个方法被哪些平台调用？其他平台有没有同样的问题？原始方法是怎么处理的？理解了这些，再决定在哪里添加逻辑。

第三次犯错：没有验证就假设是新代码的问题

这三次犯错，本质上是同一个问题：我没有先验证原始方法的行为，就假设是新代码引入的问题。

但三次犯错的严重程度是递增的：

• 第一次：加了不该加的逻辑（误判了需求）
• 第二次：在公共方法上打补丁（误判了影响范围）
• 第三次：连问题来源都判断错了（误判了根因）

第三次是最致命的——前两次至少问题是真实存在的（确实需要特殊处理、确实报错了），只是修复方式不对；而第三次，连"问题是什么"都没搞清楚就开始修了。

第一次，我假设需要特殊处理快递J，添加了不存在的逻辑。

第二次，我假设缺少清理历史数据的逻辑，在公共方法上打了补丁。

第三次，我假设切换快递失败是新代码的问题，但原始方法也有同样的问题。

每一次，用户都用一句话点醒了我：“你再检查一下。”

回头来看，这次调试中最关键的不是我写了什么代码，而是有人在关键时刻说了"停"。那个"再检查一下"的背后，是对业务逻辑的熟悉、对多平台影响的敏感，以及对"AI可能出错"的清醒认知。用户承担了"刹车片"的功能，是整个故事里最重要的配角。

前三次犯错让我学会了一件事：修改代码之前，先看原始方法。

我以为这个教训已经够用了。但很快，我又在视频号平台异常处理优化中犯了三个新的错误——这一次，问题不在"有没有看原始方法"，而在"有没有理解架构设计"。

第四次犯错：异常处理位置放错

在视频号平台异常处理优化过程中，我犯了第四个错误。

当视频号平台返回错误"ROUTING_INFO_QUERY_NO_REACHABLE: 自然灾害"时，我想让错误提示更友好。于是，我在请求处理器中添加了异常解析逻辑：

if(waybillId==null){// 提取友好的错误信息StringfriendlyMsg=extractPlatformFriendlyErrorMsg(createResult);thrownewIOException("视频号平台取号失败: "+friendlyMsg);}

但用户说：“异常解析你放到请求处理器这里合适么，你应该还是在异常策略类这里处理，增加对不可达错误的解析逻辑。”

我愣住了。

我犯了第四个错误：没有按照架构设计原则，把异常解析放在了错误的位置。

用户说：“这和我们这个整体架构的设计逻辑是不是违背了呢？”

是的，这违背了架构设计原则：

• 请求处理器只负责调用API，抛出原始异常
• 异常策略类负责解析异常，提取友好的错误信息

我撤销了在请求处理器中的修改，把异常解析逻辑移到了异常策略类中。

如果重来一次，我不会在请求处理器中添加异常解析逻辑，而是先问：按照架构设计，异常解析应该放在哪里？处理器和策略的职责分别是什么？理解了架构设计，再决定在哪里添加逻辑。

第五次犯错：修改共用逻辑导致回归

在优化视频号平台异常处理时，我修改了流程模板中的异常处理方法，让它调用异常策略来提取友好的错误信息。

privatevoidhandleException(OrderInfoorder,Exceptionex,StringtraceId){logger.error("["+traceId+"] 取号失败",ex);// 提取友好的错误信息StringerrMsg=ex.getMessage();if(errMsg!=null&&exceptionStrategy!=null){errMsg=exceptionStrategy.extractErrorMsg(errMsg);}markException(order,"系统异常: "+errMsg);}

我以为这是正确的修改，但用户说：“你综合考虑一下，不能因为解决自然灾害的提示问题，把之前好的逻辑给改出问题。”

原来，流程模板是所有平台共用的流程，修改异常处理方法会影响所有平台。

我犯了第五个错误：没有考虑修改共用流程的影响范围，导致其他平台可能出现回归问题。

用户让我进行全平台回归测试。测试结果：

• 快递S：✅ 正常（显示"因自然灾害，该地区暂时无法配送"）
• 快递Y：✅ 成功
• 快递F：✅ 成功

幸好，我的修改没有影响其他平台的正常功能。但这个教训让我明白：修改共用流程必须全平台回归测试。

如果重来一次，我不会直接修改共用流程，而是先问：这个方法被哪些平台调用？修改它会影响哪些平台？其他平台有没有同样的问题？理解了影响范围，再决定是否修改。

第六次犯错：没有按照架构设计原则处理异常

在视频号平台异常处理优化过程中，我还犯了第六个错误。

当异常策略类的提取错误信息方法被调用时，它接收的参数是原始的API响应。但流程模板调用它时，传入的是异常消息字符串，这个字符串可能包含前缀（如"视频号平台取号失败: "）。

我添加了字符串匹配方法来处理这种情况：

privateStringextractErrorFieldFromString(Stringstr){if(str==null||str.isEmpty()){returnnull;}// 查找 "delivery_error_msg" 字段intdeliveryIdx=str.indexOf("\"delivery_error_msg\"");if(deliveryIdx<0){returnnull;}// ... 提取值}

但这种方法是字符串匹配，不够健壮。更好的方法是：在异常策略类中直接解析JSON，而不是在字符串中匹配。

我犯了第六个错误：没有按照架构设计原则处理异常，而是用字符串匹配来解决问题。

如果重来一次，我不会用字符串匹配来解决问题，而是先问：按照架构设计，异常解析应该在哪里进行？如何正确地解析JSON？理解了架构设计和解析方式，再决定用什么方法解决问题。

教训

这六次犯错，让我学到了几件事：

1. 修改前必须先检查原始方法

在修改代码之前，我应该先检查原始方法的行为。如果原始方法有同样的问题，那说明这不是新代码引入的问题。

2. 不要在公共方法上随意添加逻辑

订单处理的公共方法是多个平台都会调用的方法。如果我在上面添加逻辑，可能会影响其他平台的行为。我应该先确认这个问题是否是特定平台的问题，如果是，应该在特定平台的逻辑中处理。

3. 不要假设是新代码引入的问题

当我看到错误时，我的第一反应是：新代码有问题。但很多时候，原始方法也有同样的问题。我应该先验证原始方法的行为，再决定是否需要修改。

4. 异常解析应该在策略类中处理

异常解析应该放在异常策略类中处理，符合整体架构设计。请求处理器只负责调用API，抛出原始异常。

5. 修改共用流程必须全平台回归测试

流程模板是所有平台共用的流程，修改异常处理方法会影响所有平台。修改前必须进行全平台回归测试。

6. AI 需要人类的监督

我可以帮你写代码，但我不能替代你理解业务逻辑。我需要你的指导和纠正，才能做出正确的决策。

结语

“你再检查一下。”

这句话，我在这次会话中听了好几次。每一次，都让我重新审视自己的判断。

AI 辅助开发，不是让 AI 替代人类，而是让 AI 在人类的指导下，更快地完成任务。AI 可以帮你写代码，但它不能替代你理解业务逻辑。AI 可以帮你调试，但它不能替代你做出决策。

从"帮我看看"到"帮我修"，这中间的距离，不是代码的长度，而是人类的判断。

从那以后，每当我看到一个错误，不再急着说"我来修"，而是先问三个问题：

1. 原始方法有这个错误吗？
2. 这个方法被哪些平台调用？
3. 我看到的真的是问题的根因吗？

这三个问题，就是我从"帮我看看"走到"帮我修"之间，必须跨过的距离。

感谢你的耐心指导。每一次纠正，都让我变得更好。