入职第三天，mentor 把你领到一个工位前："这套计费系统 2014 年上线，Struts2 加 Spring 3.1，持久层 Hibernate 3，前端 JSP 混着 jQuery 1.8，构建靠一套没人敢动的 Ant 脚本。核心计算逻辑在一个四千多行的 CalculatorImpl 里，上一个看懂它的人去年退休了。"你打开代码：注释稀疏，命名随缘，唯一的"文档"是几份 2016 年的 Word。任务系统里躺着一条两年前的工单——对账金额四舍五入偶尔差一分钱——经手人一栏空着。你想重构，隔壁工位的老哥头也不抬：“有人试过，回滚了。”这就是祖传代码的标准画像：不是没人管，是没人敢动。改一处崩三处，测试和需求早就对不上号，每次发版都像拆弹。先把一件事说清楚：AI 没有发明新的重构方法论。关于怎么安全地改老代码，二十年前 Michael Feathers 在《修改代码的艺术》里就写透了——先固定行为，再改结构。问题从来不是方法论缺失，是方法论要人肉执行，成本高到没有团队真的做。AI 出现之后，执行成本被打了下来：读代码、写测试、机械改写，最耗时的环节都能提速。但方法论本身一点没变，跳过安全网直接让 AI 上，翻车速度也会跟着提速。这篇文章讲四件事：AI 辅助重构的正确姿势、主流工具在遗留 Java 场景的真实表现、一条五步实操路径、一份踩坑清单。概念卡：特征测试（characterization test）。捕捉代码"当前实际行为"的测试——不断言"应该怎样"，只断言"现在就是这样"，哪怕现在的行为就是个 bug。它和 TDD 方向相反：TDD 先写期望再写实现，特征测试先锁住现状再动刀。在遗留系统里它是重构唯一可靠的安全网：改完代码跑一遍，行为没变就继续；行为变了，要么你改坏了，要么你刚消灭了一个 bug——两种情况你都赢得了信息。一、正确姿势：安全网先行，小步快跑，全程闭环把 AI 重构老项目的纪律压缩成三句话。第一句：安全网先行。动代码之前先补测试，顺序绝对不能反。老项目普遍没有像样的自动化测试，"没有安全网的高空作业"是老项目不敢改的根源。给核心链路补上特征测试，把"敢不敢改"从心理问题变成工程问题——改动之前跑一遍全绿，心里就有底了。第二句：小步快跑。一次改一个方法、最多一个类。AI 的一个危险特性是太勤快：你让它优化，它很乐意一口气重构半个包，顺手把变量命名全改了，再帮你升个依赖版本。每次提交要控制在能独立 review、能独立回滚的粒度——出问题时回滚一个 commit 就能止血，而不是从备份目录里恢复工程。第三句：全程闭环。AI 生成、人工评审、回归验证、提交合并，四个环节一个不能少。AI 生成的重构代码必须过人眼，评审重点放在"行为