AI生代码异常与日志为何保守？H38实战给对策

做内部模块H38的时候我让AI帮我写了一段打通主流程的代码。打开生成结果的那一瞬间我愣了一下几乎所有方法签名上都挂着throws Exception往下一扫日志零星得可怜唯一的一行输出还是入口处的print。说实话我对AI写代码的预期不是这样——我以为它会写得很“全”结果它出奇地克制异常全往上抛日志能省则省边界处理一概不做。用一句话总结我的感受AI在异常处理和日志规范上的保守程度远超我的想象。这个现象让我琢磨了很久。按理说大模型看过海量开源项目应该知道生产级代码长什么样为什么真正落笔的时候却这么“怂”这篇文章我想从现象、原因、代价和对策四个方面把这次H38实战中关于AI编码行为的观察完整记录下来尤其是后半部分如何“逼”AI写出生产可用的异常处理和日志强烈建议正在用AI铺业务代码的同学看一下。1. 现象拆解AI写的异常处理比你想的更“怂”1.1 三个让我意外的保守表现先说最直观的三个表现都属于“你明确不要求AI绝对不主动做”的范畴。表现一异常处理只剩“往上抛”。在Java代码里凡是AI识别出可能有异常的方法第一反应就是加throws Exception然后就没有然后了。它不会去区分这个异常是临时故障还是永久失败不会考虑重试、降级、兜底更不会把业务上下文订单号、用户ID、批次号塞进异常信息里。仿佛异常处理的终极奥义就是把问题甩给上层。表现二日志能省则省。入口参数不打日志出口结果不打日志关键分支不打日志耗时统计更不可能有。即便你明确跟它说“加日志”它也只会非常朴素地在catch里写一行e.printStackTrace()或者logger.error(e.getMessage())完全没有上下文串联的概念。好像只要程序不崩就万事大吉。表现三外部依赖默认“一次成功”。面对HTTP调用、数据库操作、Redis读写这类场景AI默认所有请求都会正常返回超时、连接池耗尽、远端500这种日常故障它从不在代码里体现。我在H38里有一段对接外部同步接口的逻辑AI生成的代码连超时时间都没设置完全是裸调。1.2 对比同样的需求人和AI的写法差异拿H38里一个典型场景举例调用第三方支付接口发起退款然后给用户发通知。这是很常规的业务代码AI的典型输出是下面这样public void refund(Order order) throws Exception { String result paymentClient.refund(order.getOrderNo()); if (SUCCESS.equals(result)) { notifyUser(order.getUserId()); } }这段代码能跑吗能。但在生产环境里它留了三个坑第一paymentClient.refund如果超时怎么办第二退款失败时用户那边完全无感知因为else分支什么都没干第三万一notifyUser抛异常整个调用栈都会挂到外层去可能连退款成功的事实都没有被记录。我期望的生产级版本大概是这个方向public void refund(Order order) { long start System.currentTimeMillis(); try { String result paymentClient.refund(order.getOrderNo()); logger.info(refund response, orderNo{}, userId{}, result{}, order.getOrderNo(), order.getUserId(), result); if (SUCCESS.equals(result)) { notifyUser(order.getUserId()); } else { logger.warn(refund business failed, orderNo{}, result{}, order.getOrderNo(), result); // 这里应该按业务规则决定是否告警或人工介入 } } catch (TimeoutException e) { logger.error(refund timeout, orderNo{}, userId{}, order.getOrderNo(), order.getUserId(), e); // 重试队列或状态标记供后续补偿任务扫描 throw new BizException(ErrorCode.REFUND_TIMEOUT, order.getOrderNo()); } }两段代码放在一起看差距一眼就能看出来。不是说AI不会写后者而是它默认不写。这事细想起来很有意思——AI的训练数据里肯定有大量后者这种优质代码但它就是不主动选。2. 为什么AI这么保守从训练机制到决策逻辑2.1 概率采样决定了“高频路径”胜出大模型生成代码的本质是在词表上做概率采样——每一步都选择上下文条件下概率最高的Token组合。那么问题来了在GitHub上所有Java代码里哪个模式出现得更多是“简单声明throws Exception然后啥也不干”的代码还是“精心catch、分类处理、打满日志”的代码答案显而易见。GitHub上有大量教学示例、Demo、博客配套代码、Stack Overflow片段这些代码绝大多数是“能跑就行”的示范代码异常处理往往就是往上抛日志就是没有。AI在海量这种文本上训练自然会把“相对简陋但安全”的风格判定为高概率路径。它输出的不是“最优解”而是“最常见解”。这解释了一个现象如果你不约束AI它对异常和日志的处理水平大概就是GitHub代码仓库的平均水平——而这个平均水平恰恰低于你在正规公司生产环境里要求的下限。2.2 日志被省略是因为“分歧”让AI不安我曾经想过一个问题相比异常处理加日志只是一行logger.info而已为什么AI也懒得加后来我想明白了加日志看起来只是一行代码实际上需要AI同时做三件事import日志框架、获取logger实例、在正确位置写日志调用。每一步都可能引入错误——类名拼错、变量不在作用域、静态上下文里拿不到logger。任何一个环节出错整段代码的“完成度”就会被打折。换句话说多写代码对AI来说是负收益因为只要引入任何一个小错误它在概率评估中受到的影响比“代码简陋”要大得多。不写日志顶多被评价为“不够完善”写了但写错则会被评价为“不正确的代码”。这个不对称的“惩罚机制”让AI天然倾向于少动、少错。用个生活化的类比一个刚入职的新人领导没交代的事绝对不做——不是没能力做而是怕做错了背责任。AI就是这样一只“不求有功、但求无过”的手。2.3 失败模式决定了“少做”比“多做”更安全还有一个很现实的原因AI在自我评估时更在意生成的内容能不能通过语法和逻辑的基本检查。一个方法体如果只有几行简单调用出错概率极低一旦引入重试循环、降级开关、多分支日志AI就需要处理更多状态组合生成的代码稍有不慎就出现变量越界、异常类型不匹配、死循环之类的低级错误。这些错误在人类看来自查很容易发现但在大模型的概率生成机制里它们都是实打实的“风险点”。所以我观察到一个规律AI在生成短小精悍的代码时质量非常稳定一旦要求它加上完善的异常和日志它就开始出现画蛇添足的错误。这也反过来强化了它的保守倾向——因为保守确实更容易通过基本校验。3. 保守的代价当H38上线之后问题开始暴露3.1 夜间任务失败一行堆栈让人抓瞎H38上线后没多久就遇到了一个典型的例子。这是一个定时触发的外部数据同步任务凌晨跑批时抛了一个异常整个任务中断。当时我们打开日志平台看到的只有这么点信息java.lang.NullPointerException at com.company.h38.SyncWorker.process(SyncWorker.java:47)没有订单号、没有批次号、没有当前处理到第几条数据甚至连是哪家外部渠道的同步都看不出来。这行日志除了告诉你“有个地方空指针了”什么信息都没有。因为AI生成的代码里catch之后只是简单打印了一下异常堆栈业务上下文完全丢失而第47行恰好是一行很长的链式调用根本没法从行号直接判断是哪个对象为空。最后怎么排查的只能临时加日志、改代码、重新部署、再手动触发跑批等它再失败一次才能拿到更多线索。整个排查过程花了一个多小时绕了一大圈。事后我在代码里补日志时发现其实只需要在catch块里把batchId和orderNo带出来这个问题五分钟就能定位。这就是我在前面说的“AI保守的代价”它省掉的那些日志不是在写代码时省掉的而是在你线上故障最需要线索的时候加倍讨回来的。3.2 异常被“包起来”和“全抛出去”的两个极端H38另一个让我纠结的点是AI对异常边界的处理。我观察到一个两极分化的情况在一段代码里如果AI识别出方法签名有throws Exception的空间它就一路向上抛中间不做任何包装。结果就是上层业务代码被迫处理一堆底层异常类型比如SQLException、IOException业务逻辑和基础设施异常完全耦合在一起。在另一段代码里如果AI觉得不应该抛异常比如回调方法、定时任务入口它就干脆把整个方法体包进一个巨大的try-catch然后catch (Exception e)什么都不做或者只打一行日志就吞掉。第一种情况的问题在于异常信息失真的链路太长底层失败的原因在层层传递中被稀释第二种情况更危险静默吞掉异常等于掩盖故障明明系统已经处于错误状态表面却一切正常。对账任务最怕的就是这种“假成功”。大概在第三次处理这类问题时我得出一个结论AI对异常边界的理解基本停留在“要么甩锅、要么装死”的层面它不会主动做“包装、分类、部分恢复”这种精细操作。而这些恰恰是生产级代码最核心的部分。3.3 什么时候AI的保守反而救了场不过我也要说句公道话AI的保守并非一无是处。H38里有几个状态同步场景如果AI自作聪明地在catch里加了降级逻辑、返回一个默认值反而会让数据出现不一致。比如退款状态同步如果没有明确的补偿策略最好的做法就是抛出去、让外层感知、让告警介入而不是悄悄返回一个“看起来成功”的结果。我后来意识到AI默认不做降级、不吞异常其实意味着它选择了一种安全的默认值——至少错误不会被主动掩盖。从这个角度看它的保守是一种“不会把事情搞得更糟”的底线保障。坏消息是这个底线距离生产可用还差得很远。4. 实战对策怎么“逼”AI写出生产级日志和异常处理4.1 在需求描述里写死规则别用“请加日志”这种含糊话和AI沟通最忌讳的是用人类之间心照不宣的模糊表达。你说“代码写规范一点”AI的理解和你心里的标准完全不是一回事你说“请加日志”它可能只在最外层加一行。正确做法是把规则写死、写具体。下面是我后来在H38里实际用的一段提示词模板效果非常明显这是一个生产级定时任务代码请严格遵循以下约束 - 所有方法不得声明 throws Exception如果方法无法就地处理异常请包装为 BizException 并携带业务上下文orderNo/batchId/workerId。 - 每个 catch 块必须使用 logger.error 输出异常信息、当前业务ID、相关请求参数禁止空 catch。 - Logger 统一使用 slf4j logback每个类创建 private static final Logger logger保证入口参数和出口结果有 info 日志。 - 所有外部系统调用HTTP/Redis/RPC必须打印调用参数和调用耗时网络超时类异常必须设置明确的超时时间并进行一次重试。 - 定时任务批处理中单条数据失败不得影响整体批次必须记录 error 后继续并在结束时汇总失败条数。 - 禁止使用 System.out、printStackTrace、e.getMessage() 作为日志主体。我对比过用这段提示词前后的产出差距。约束之后AI生成的代码日志密度和异常处理粒度明显达到了可审查的水平。它不是说做不到而是只有在规则足够明确时它才会调用自己“见过”的高质量代码模式。4.2 给AI吃“范文”把项目里的日志规范模板丢给它有一天我在重写H38的一个基础服务类突然发现“要求AI模仿风格”比“要求AI做到规范”更管用原因在于风格是显式的规范是隐式的。于是我把项目里一段人工编写的老代码直接粘给AI然后说“后续生成的代码请参照这段的日志风格和异常处理方式。”这段老代码里包含了我想要的全部特征日志里有orderNo、requestId、耗时统计异常被统一包装成枚举错误码catch块中不仅有日志还有对错误码的判断。AI看到这个范文之后生成出来的新代码几乎不需要大改就能合入。这是一个很重要的经验大模型对“风格模仿”的把握能力远强于对“抽象要求”的理解能力。与其费劲地描述你要什么不如直接把范例给它。让AI照葫芦画瓢的示例// 参照下面的日志风格和异常处理方式为 orderService 生成同步方法 public void syncOrder(Order order) { long start System.currentTimeMillis(); try { // 业务... logger.info(syncOrder done, orderNo{}, cost{}ms, order.getOrderNo(), System.currentTimeMillis() - start); } catch (BizException e) { logger.error(syncOrder biz error, orderNo{}, code{}, msg{}, order.getOrderNo(), e.getCode(), e.getMessage()); throw e; } catch (Exception e) { logger.error(syncOrder unknown error, orderNo{}, order.getOrderNo(), e); throw new BizException(ErrorCode.SYNC_ERROR, order.getOrderNo(), e); } }4.3 代码评审检查单AI生成后的第一道关卡经过前两个步骤AI能交出基本合格的代码但这不代表你就不用看了。我的习惯是拿到AI生成的代码后不看业务逻辑先按下面这张检查清单过一遍检查项通过标准常见AI翻车点异常是否被吞掉catch块必须有日志或再抛出不允许空catch大段try-catch包入口catch里只打一行异常是否携带上下文异常信息含业务ID、入参关键字段直接new Exception(error)没有细节日志是否有上下文info日志包含键业务信息不是单纯方法名logger.info(done)这类废话日志外部调用是否设超时HTTP/Redis/RPC均有超时配置裸调用完全不设超时时间批处理是否单条隔离单条数据异常不中断整个批次一条脏数据导致全批次回滚敏感信息是否脱敏日志中不出现手机号明文、完整身份证等直接把整个请求体打进日志这张表是我在H38里踩了若干次坑之后逐渐摸出来的现在几乎成了我所有AI辅助编码项目的标配。对AI生成的代码功能测试可以放后面异常和日志的审查一定要放最前面——因为这两块恰恰是AI最敷衍、最容易出隐性问题的区域。4.4 反向描述目标让AI自己推导出细节最后一个技巧从结果出发描述需求而不是从动作出发。比如“帮我加日志”这种描述就不太好改成“我希望这个接口在线上出问题时运维能通过日志直接判断是哪家渠道、哪个订单号、卡在哪一步”AI就能推导出需要打印哪些字段需要记录什么状态远比你告诉它“加几行logger.info”有效得多。我把这个做法叫目标倒推式提示。它利用了AI对场景的理解能力——相比直接生成日志代码让它先“假装自己在排查一个故障”它反而能给出更贴近实际需求的日志策略。5. 一点延伸思考AI的保守其实是面镜子5.1 日志和异常本来就是“看不见的工作”顺着H38这个项目想下去我发现AI的保守本质上暴露了一个更普遍的问题日志规范和异常处理从来都是开发中最容易被忽略的部分。它不像功能代码那样“跑通了就能看见成果”它做得好系统稳定时毫无感知做得不好只在故障现场加倍惩罚你。AI没有经历过线上故障的痛自然不会产生对日志和异常的“敬畏”。这也是为什么我最终觉得不能指望AI主动写出超出你标准的东西它只会贴近你描述出来的标准。你想要生产级的日志和异常就必须在需求里把生产级的标准完整地定义出来再拿着这个标准去审查AI的输出——AI只是在执行你的意图当好一个“快但需要管理”的编写者是它的上限。5.2 把AI的“保守”当成一种特质来管理经过H38这轮摸爬滚打我自己的心态也变了。我不再指望AI一步到位而是把它当成一个写代码很快、但边界感很强、不会主动多做任何事的协作者。它保守我就把要求说得更明确它不写日志我就给范文它吞异常我就用检查单去卡。这就像带一个聪明的实习生你的期望是管理出来的不是自然来的。现在我再拿到AI生成的第一版代码第一件事不是跑功能测试而是先看异常和日志——如果这两块过了我的标准功能通常也不会差到哪去反过来如果一段AI代码连一条像样的日志都没有那它的异常处理边界多半也没想过。写代码的人终究还是我AI只是手快一点的键盘而已。把这个想清楚了AI再保守你也不会被它带到沟里。