电商系统的订单状态流转，大概是 if-else 癌变的重灾区。这个方法的作者后来离职了。他留下的遗产是 500 多行的，包含 12 种状态、45 种状态转换。每加一个新状态，要找遍所有 if-else 分支里有没有遗漏。改一行就怕改错十行，上线一次心惊肉跳一次。

别做那种"AI生成完直接commit"的事，我见过同事这么干，code review的时候发现测试里所有的mock都是any()，所有断言都是assertNotNull——这种测试除了拉低覆盖率什么用都没有。返回的是null需要显式类型转换，而AI完全不理解这个坑——它在训练数据里见过argThat的用法，但不了解Java泛型在Mockito里的类型推断限制。我的经验是：涉及Spring容器和测试

绝不让AI一次性重构超过3个策略类。小块小块来，每块重构完跑一遍全量测试，确认没引入回归再继续。AI给的"一口气全重构"的方案看起来很爽，但出了问题你都不知道从哪开始排查。AI生成的所有条件判断必须逐行核验。它可能会遗漏条件、合并不该合并的分支、或者"优化"掉一些看起来不合理但实际有业务含义的逻辑。别偷这个懒。重构前后跑同一组测试用例。这看起来是废话，但实际执行中很容易因为"策略类拆完了肯定没问题

我们有个支付回调服务，逻辑不复杂——接收第三方支付结果，校验签名，更新订单状态，发个通知。这代码跑了两年没出过事，直到上个月我决定让AI帮我重写异常处理部分。起因是代码里的try-catch太随意了，到处都是catch(Exception e)然后log.error完事，有些异常该重试的没重试，该回滚的没回滚。我把代码丢给AI，让它帮我"规范化异常处理"，它倒是挺积极，一口气给我加了七八种异常类型

上周订单导出功能重构，我想着用AI提速，就把需求丢给了Cursor——把原来for循环拼接的逻辑改成Stream并行处理。AI写得很快，三分钟就给我吐了一段看起来很优雅的parallelStream代码，我还觉得挺满意，review了一遍就合了。上线第二天，凌晨告警就来了。订单服务堆内存飙到95%，GC根本回收不掉。翻日志一看，全是"Java heap space"，导出接口超时率从0.3%直接干

上周订单导出功能重构，我想着用AI提速，就把需求丢给了Cursor——把原来for循环拼接的逻辑改成Stream并行处理。AI写得很快，三分钟就给我吐了一段看起来很优雅的parallelStream代码，我还觉得挺满意，review了一遍就合了。上线第二天，凌晨告警就来了。订单服务堆内存飙到95%，GC根本回收不掉。翻日志一看，全是"Java heap space"，导出接口超时率从0.3%直接干

那个凌晨三点的电话- AI给出了"看起来完美"的代码- 锁没续上，业务全乱了- 重新理解Redisson的可重入锁- 给AI加约束条件后重试- 几条经验---

我懒得手写这条跨五张表的统计查询，就把需求描述贴给了AI："写一条MySQL查询，统计近30天每个商品类目的订单转化率，需要关联用户表、商品表、类目表、订单表和订单明细表，按转化率降序排列。那天凌晨两点，手机连续收到四条阿里云RDS告警："CPU使用率超过90%"，"活跃连接数超过200"，"慢查询阈值触发"。AI可以写出正确的SQL语法，但它不具备"这条SQL在生产库上跑会不会出问题"的判断力。

去年接手了一个电商项目的促销模块，打开的那一刻，我脑子里只闪过一个念头：这代码的作者是不是跟公司有仇。整个calculate方法，400 行。没有夸张，真的是 400 行。if-else 嵌套最深的地方有 5 层，缩进已经把代码挤到了屏幕右半边。注释全部是"// 这里加了个临时的判断，后面再优化"——注释的日期是两年前。