Java 程序员的 AI 进化论 | AI 写代码再快,这四

Java 程序员的 AI 进化论｜ AI 写代码再快，这四样能力替代不了

上周组里来了个新人，看我用 AI 五分钟撸完一个 Controller，眼睛都直了，说"哥你这太快了吧，那我还学啥"。我当时没接话，因为这个问题我自己琢磨了大半年。

用 AI 写代码这一年多，我最大的感受是：写代码这件事确实变快了，但"会写代码"这个能力的权重在往下掉。真正拉开差距的，反而是 AI 干不好的那几样。今天就把我自己踩过的坑和想明白的事聊聊。

一、系统设计：AI 会写类，画不出边界

我让 AI 设计过一个"订单履约模块"。需求说得挺清楚——下单、支付、发货、收货四个状态流转。AI 给我的方案是这样的：

@Service publicclass OrderFulfillmentService { // AI 把所有逻辑塞进了一个类，480 行 publicvoidpay(Long orderId) { /* 支付 + 库存扣减 + 通知 + 日志 */ } publicvoidship(Long orderId) { /* 发货 + 物流 + 通知 + 日志 */ } publicvoidreceive(Long orderId) { /* 确认收货 + 售后入口 + 日志 */ } publicvoidcancel(Long orderId) { /* 取消 + 回滚库存 + 退款 + 通知 */ } }

代码能跑，单测也能过。但我拿去做架构评审的时候被老张一句话问住了："支付和库存扣减在一个事务里，物流系统挂了你回滚不？"

AI 没考虑这个。它不知道我们物流走的是第三方接口，超时率 3%，一旦物流超时，整个支付事务就卡死。这就是边界设计的问题——哪些该在一个事务里，哪些该拆成异步，哪些该做补偿，这些判断 AI 给不了。

设计任务	AI 表现	人工必须把关的点
单个类的方法实现	好，快且准	命名规范、异常粒度
模块间职责划分	一般，容易堆砌	事务边界、耦合方向
跨服务调用编排	差，不懂你的基础设施	同步异步、补偿机制
长期演进路径	几乎给不了	扩展点预留、废弃策略

踩坑一：我图省事直接用了 AI 给的方案上线，结果物流接口超时把支付事务拖垮，当天下了 17 个异常单。后来拆成"支付同步 + 物流异步 + 补偿队列"才稳。这事让我明白，AI 能帮你把砖搬快，但房子怎么搭，图纸还得自己画。

二、业务理解：代码跑得通，跑的是什么业务它不知道

这块我感受最深。AI 写 CRUD 没问题，但你让它处理"细胞标本管理"这种垂直业务，它就抓瞎。

公司有个细胞标本生命周期系统，标本从入库到销毁有 11 个状态，其中"复核中"和"待复审"是两个完全不同的业务节点——前者是技术员初检，后者是主管抽检。AI 每次写状态机都把这俩搞混，因为它觉得语义差不多。

// AI 生成的状态流转（有业务 Bug） publicvoidsubmitReview(Long specimenId) { Specimen s = repo.findById(specimenId); // AI 直接从"复核中"跳到"已审核"，跳过了主管复审环节 s.setStatus(SpecimenStatus.APPROVED); repo.save(s); } // 正确的流转：技术员复核后 → 主管复审 → 才能审核通过 publicvoidsubmitReview(Long specimenId) { Specimen s = repo.findById(specimenId); s.setStatus(SpecimenStatus.PENDING_SUPERVISOR_REVIEW); repo.save(s); notifySupervisor(s.getLabId()); // 触发主管复审通知 }

这种业务规则，文档里写了一页纸，AI 读了也抓不住重点。为什么？因为业务理解的难点不在"知道有这个规则"，而在"知道这个规则为什么存在"。主管复审这一步，是因为合规要求——涉及人体标本的检测必须有双人复核。AI 不知道这个"为什么"，所以它觉得可以省掉。

业务理解层次	AI 能做到	人必须做的
读需求文档	能读，抓不住重点	提炼隐含约束
知道规则	能复述规则文字	理解规则背后的原因
判断边界场景	容易遗漏	补充反例和异常路径
跨模块业务关联	基本不懂	串通上下游影响

踩坑二：有一次我让 AI 写标本销毁的审批流，它把"销毁不可逆"这个关键约束当普通状态变更处理了，没有加二次确认和审计日志。测试环境没发现，差点带到生产。幸亏 code review 的时候我自己多看了一眼。从那以后，涉及业务核心流程的代码，AI 写完我一定逐行过一遍，尤其是状态流转和权限校验。

三、调试能力：AI 能写 bug，定位 bug 还得靠人

说个真事。上个月线上偶发空指针，一天出两三次，每次栈都不一样。我把异常堆栈丢给 AI，它给了 5 个可能原因：

AI 给的原因	实际情况
返回值未判空	已判空，不是这个
集合元素为 null	有防护，排除
并发修改	有锁，但……
反序列化失败	日志没报错，排除
代理对象问题	不涉及，排除

前 4 个都不是。真正的原因是第 6 个——AI 压根没列出来的那个：一个 @Async 方法拿到的 ThreadLocal 上下文是空的，导致下游取用户 ID 时返回 null，而 null 又被自动拆箱成了空指针。

AI 没想到这个，因为它不知道我们的 UserContext 是基于 ThreadLocal 的，也不知道 @Async 会换线程。这种 bug，你得对整个调用链有全局认知才能定位，不是看一段代码能看出来的。

后来我加了 TaskDecorator 把上下文透传到异步线程，问题才解决：

// 异步线程丢失 ThreadLocal 上下文的修复 @Bean public TaskDecorator contextDecorator() { return runnable -> { UserContext ctx = UserContextHolder.get(); // 主线程捕获 return () -> { UserContextHolder.set(ctx); // 子线程恢复 try { runnable.run(); } finally { UserContextHolder.clear(); // 清理防内存泄漏 } }; }; }

调试这事，AI 能帮你缩小范围，但拍板的还是你自己。你得知道系统怎么跑的、数据怎么流的、哪些组件有坑。这些知识不在代码里，在脑子里。

Bug 类型	AI 定位效果	关键依赖
语法/逻辑错误	好，基本秒定位	读代码即可
空指针/越界	一般，给一堆可能	需要你筛
并发/时序问题	差，不懂你的上下文	全链路认知
环境相关（配置/网络）	几乎没用	运维经验

四、架构思维：AI 看眼前，人看三年

AI 写代码有个特点：它永远在解决你当前问的那个问题，不会替你想下一步。

我做过一个反面案例。智慧农村数据统计表，一开始数据量小，我让 AI 写查询，它直接全表扫描加 group by，能跑。半年后数据涨到 800 万行，查询从 200 毫秒飙到 12 秒。

回头看我当时的决策，问题在于：我只问了 AI"怎么查"，没问"这么查以后会不会慢"。AI 不会主动提醒你加索引、做分区、考虑数据增长。这些是架构思维——你要预判系统半年后、一年后的样子。

后来我按 tx_date 做了 PostgreSQL 按月 RANGE 分区，查询回到 300 毫秒以内。这个方案 AI 给不了，因为它不知道你的数据增长曲线、不知道你用 PG 还是 MySQL、不知道你能不能停机迁移。

还有一类情况更隐蔽——技术债的取舍。有个老模块，AI 建议我"全部重写更干净"。听着挺有道理，但那模块跑了三年，有 14 个隐式依赖藏在注释都没写的地方。全推倒重来，光回归测试就得两周，上线风险不可控。我做的是局部抽接口、逐步替换，花了三周但零故障。AI 不会帮你算这笔账，它只看到代码烂，看不到重写的代价。

思维维度	AI 的视角	架构师的视角
时间跨度	当前这个需求	未来 6-12 个月演进
决策依据	代码能不能跑	性能、成本、可维护性
权衡取舍	倾向"先实现"	在速度和质量间找平衡
技术债	不主动提	主动评估并排期还

说白了，AI 是个执行效率极高的"战术兵"，但"战略规划"这块，它还够不着边。

五、总结

用了一年多 AI，我给自己定了条规矩：让 AI 干执行的活，自己留决策的活。

具体怎么分，我整理成一张清单：

能力	该不该交给 AI	建议
写 CRUD / 模板代码	该交	省时间，但 review 一遍
单个算法实现	该交	补上边界测试
模块边界设计	别全交	AI 出初稿，自己定事务和耦合
业务规则实现	别交	AI 不懂你的业务为什么这样
Bug 定位	半交	AI 缩小范围，你来拍板
架构和技术选型	别交	这是你的核心竞争力

有个事我想明白了：AI 不会淘汰程序员，但会用 AI 的程序员，会淘汰不会用的。而"会用"不是"用得快"，是"知道什么该用、什么不该用、用了之后怎么兜底"。

这些判断力，靠的是系统设计、业务理解、调试经验、架构思维——四样 AI 短期内替代不了的东西。与其焦虑被 AI 取代，不如把这几样练扎实。代码写得快慢，那是工具的事；想得清楚不清楚，才是人的事。

Java 程序员的 AI 进化论 ｜ AI 写代码再快，这四样能力替代不了