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

从帮我看看到帮我修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){OrderInfoorderdataService.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(waybillIdnull){// 提取友好的错误信息StringfriendlyMsgextractPlatformFriendlyErrorMsg(createResult);thrownewIOException(视频号平台取号失败: friendlyMsg);}但用户说“异常解析你放到请求处理器这里合适么你应该还是在异常策略类这里处理增加对不可达错误的解析逻辑。”我愣住了。我犯了第四个错误没有按照架构设计原则把异常解析放在了错误的位置。用户说“这和我们这个整体架构的设计逻辑是不是违背了呢”是的这违背了架构设计原则请求处理器只负责调用API抛出原始异常异常策略类负责解析异常提取友好的错误信息我撤销了在请求处理器中的修改把异常解析逻辑移到了异常策略类中。如果重来一次我不会在请求处理器中添加异常解析逻辑而是先问按照架构设计异常解析应该放在哪里处理器和策略的职责分别是什么理解了架构设计再决定在哪里添加逻辑。第五次犯错修改共用逻辑导致回归在优化视频号平台异常处理时我修改了流程模板中的异常处理方法让它调用异常策略来提取友好的错误信息。privatevoidhandleException(OrderInfoorder,Exceptionex,StringtraceId){logger.error([traceId] 取号失败,ex);// 提取友好的错误信息StringerrMsgex.getMessage();if(errMsg!nullexceptionStrategy!null){errMsgexceptionStrategy.extractErrorMsg(errMsg);}markException(order,系统异常: errMsg);}我以为这是正确的修改但用户说“你综合考虑一下不能因为解决自然灾害的提示问题把之前好的逻辑给改出问题。”原来流程模板是所有平台共用的流程修改异常处理方法会影响所有平台。我犯了第五个错误没有考虑修改共用流程的影响范围导致其他平台可能出现回归问题。用户让我进行全平台回归测试。测试结果快递S✅ 正常显示因自然灾害该地区暂时无法配送快递Y✅ 成功快递F✅ 成功幸好我的修改没有影响其他平台的正常功能。但这个教训让我明白修改共用流程必须全平台回归测试。如果重来一次我不会直接修改共用流程而是先问这个方法被哪些平台调用修改它会影响哪些平台其他平台有没有同样的问题理解了影响范围再决定是否修改。第六次犯错没有按照架构设计原则处理异常在视频号平台异常处理优化过程中我还犯了第六个错误。当异常策略类的提取错误信息方法被调用时它接收的参数是原始的API响应。但流程模板调用它时传入的是异常消息字符串这个字符串可能包含前缀如视频号平台取号失败: 。我添加了字符串匹配方法来处理这种情况privateStringextractErrorFieldFromString(Stringstr){if(strnull||str.isEmpty()){returnnull;}// 查找 delivery_error_msg 字段intdeliveryIdxstr.indexOf(\delivery_error_msg\);if(deliveryIdx0){returnnull;}// ... 提取值}但这种方法是字符串匹配不够健壮。更好的方法是在异常策略类中直接解析JSON而不是在字符串中匹配。我犯了第六个错误没有按照架构设计原则处理异常而是用字符串匹配来解决问题。如果重来一次我不会用字符串匹配来解决问题而是先问按照架构设计异常解析应该在哪里进行如何正确地解析JSON理解了架构设计和解析方式再决定用什么方法解决问题。教训这六次犯错让我学到了几件事1. 修改前必须先检查原始方法在修改代码之前我应该先检查原始方法的行为。如果原始方法有同样的问题那说明这不是新代码引入的问题。2. 不要在公共方法上随意添加逻辑订单处理的公共方法是多个平台都会调用的方法。如果我在上面添加逻辑可能会影响其他平台的行为。我应该先确认这个问题是否是特定平台的问题如果是应该在特定平台的逻辑中处理。3. 不要假设是新代码引入的问题当我看到错误时我的第一反应是新代码有问题。但很多时候原始方法也有同样的问题。我应该先验证原始方法的行为再决定是否需要修改。4. 异常解析应该在策略类中处理异常解析应该放在异常策略类中处理符合整体架构设计。请求处理器只负责调用API抛出原始异常。5. 修改共用流程必须全平台回归测试流程模板是所有平台共用的流程修改异常处理方法会影响所有平台。修改前必须进行全平台回归测试。6. AI 需要人类的监督我可以帮你写代码但我不能替代你理解业务逻辑。我需要你的指导和纠正才能做出正确的决策。结语“你再检查一下。”这句话我在这次会话中听了好几次。每一次都让我重新审视自己的判断。AI 辅助开发不是让 AI 替代人类而是让 AI 在人类的指导下更快地完成任务。AI 可以帮你写代码但它不能替代你理解业务逻辑。AI 可以帮你调试但它不能替代你做出决策。从帮我看看到帮我修这中间的距离不是代码的长度而是人类的判断。从那以后每当我看到一个错误不再急着说我来修而是先问三个问题原始方法有这个错误吗这个方法被哪些平台调用我看到的真的是问题的根因吗这三个问题就是我从帮我看看走到帮我修之间必须跨过的距离。感谢你的耐心指导。每一次纠正都让我变得更好。