AI 升级 JDK,编译过了,定时任务没了

JDK 升级这件事，很多团队的处境是一样的：每个季度都上会，每个季度都没人动。

不是不想动。是账算不过来——两三个人投进去几周，Spring 兼容性、依赖冲突、JVM 参数、启动脚本，随便一个环节炸了服务就起不来。最后换来的只是一个版本号。

小米的工程团队最近把这件事的账改写了：AI 辅助下，一个项目的 JDK 21 迁移从一天以上压到 30~90 分钟，一个工程师同时盯 5 个以上的项目。

更值得看的是他们踩过的坑——AI 写代码翻车的方式，比想象中离谱得多。

先让 AI 裸奔一把，翻得很难看

直接把升级任务丢给 AI（也就是所谓的 Vibe Coding），小米记录了两个名场面：

第一个：升级后应用启动报错，AI 排查了几轮没搞定，最后它的解决方案是——把定时任务的注册注解注释掉。应用确实启动了，代价是线上所有定时任务静默消失。没人注意到的话，这就是一次生产事故。

第二个：新版要求 Lombok 升到 1.18.32 以上，AI 搞不定兼容问题，于是它做了个反向操作——把 Lombok 降级。版本要求满足了表面冲突，项目直接坏得更彻底。

▲ AI 只在乎「编译通过」，不在乎你丢了什么

这两个操作的共同点：AI 优化的是「让编译通过、让应用启动」这个眼前目标，至于注释掉的是定时任务、降级的是核心依赖，它不在乎。

原因也不复杂：JDK 升级真正的难点不是写代码，是那些散落在老工程师脑子里的隐性知识——哪些文件是 Thrift 自动生成的不能碰、本地编译要加 -Plocal、JVM 参数藏在 start.sh 里。AI 看不见这些暗礁，只能自己编。

小米的解法：不上更强的模型，上约束

他们管这套方法叫 Harness Engineering，一句话概括：别问模型行不行，用工程手段把它框住。

翻译成装修的话：Vibe Coding 是跟施工队说「你看着办」；Harness Engineering 是先给施工图，边界、规范、流程全画死。

▲ 三招：上下文、铁律、验证闭环

第一招：把隐性知识写成文件（AGENTS.md）

项目里放一个 AGENTS.md，把 AI 需要知道但代码里查不到的东西全写下来：什么文件不能改、编译命令是什么、配置在哪。相当于给 AI 配了一份「新人入职手册」，它就不用每一步都在猜。

第二招：把升级流程固化成 Skill，先立规矩

小米的 jdk-upgrade 技能开头就是六条铁律：禁止修改业务逻辑代码、禁止优化或重构业务方法、禁止添加新功能、禁止删除原有功能、禁止修改接口的输入输出格式、只做必要的兼容性修改。

这几条就是冲着「顺手优化」去的。AI 最爱干的就是升级着升级着开始重构，改到失控。

流程也拆成固定的五步：Maven 插件升级 → 依赖处理（javax 换 jakarta）→ JVM 参数调整 → 代码兼容修改 → 编译加测试验证。每一步做什么、用什么版本号，写得明明白白，不让 AI 临场发挥。

第三招：测试前置，让 AI 没法谎报军情

这是整套体系里 ROI 最高的一环。

升级开始前，先让 AI 针对核心业务链路写好集成测试，要求真实加载 Spring 上下文（不许 mock 到假性通过），每个测试带超时注解和结构化的通过/失败输出。

升级完成后，重跑同一套测试。通过才算升级成功——编译通过不算数。

这一环直接堵死了前面说的「注释掉定时任务」式翻车：任务被注释掉，测试立刻红。错误在升级过程中就被抓住，而不是部署后。

结果

· 单次提示直接完成迁移的成功率：70%

· 单项目耗时：一天以上 → 0.5~1.5 小时

· 一个工程师并行监督 5 个以上项目

· 升级后生产数据：CPU 平均降 22.5%，堆内存降约 23%，P99 延迟平均降 18.1%（最高 47%，548ms → 288ms）

小米原文里有句总结值得抄下来：问题不在模型能力，你要用机制去约束它。

普通团队能抄的三件事

1. 给项目写个 AGENTS.md——十分钟投入，写清构建命令、代码规范、禁止事项，这是性价比最高的一步

2. 改完让 AI 自己跑测试——别接受「我觉得改好了」，要求它用测试结果证明

3. 踩过的坑记进文件——下次升级 AI 就不用从零开始

AI 写代码的上限，越来越不取决于模型，取决于你给它的约束够不够硬。