AI 辅助 Java 代码重构：让臃肿 Service 安全地瘦下来

在很多 Java 老项目里，最难的不是写新功能，而是改旧代码。一个几百行的 Service 里混着参数校验、折扣计算、数据库调用和日志输出，改一处就怕牵一发而动全身。AI 在这里的价值，不是“一键重构出漂亮代码”，而是把一次高风险的大改，拆成一系列可验证的小步。

先定一条铁律：行为不变，测试先行

重构前，先把现有行为“钉住”。如果项目已有单元测试，先跑通；如果没有，让 AI 根据现有分支先生成特征测试：覆盖正常、边界和异常分支，断言输出而不是实现细节。只有测试先变绿，后面的每一步才有回退依据。没有这一步，AI 给出的任何“更优雅”写法都不可信。

给 AI 一份可执行的约束，而不是一句“帮我优化”

模糊的提示只会换来风格化的改写。更有效的做法，是在提示里写清：不改变公开方法签名和返回值语义；不引入新依赖；不把多个职责合并到一个新类；每一步只做一件事，改完给出 diff 摘要和受影响的测试。还要明确禁止它“顺手”修掉看似多余的分支——很多看似死代码的分支，往往是线上真实场景的兜底。

一个具体例子：把折扣 if-else 换成策略表

下面是常见的臃肿写法：用户类型一多，if-else 就不断膨胀，新增一种用户就要改核心方法，还容易漏掉默认分支。重构的目标，是把“算折扣”抽成纯函数，让它不依赖数据库和外部服务，从而可以单独测试。

import java.util.Map;

public class RefactorDemo {
    record Order(String userType, double amount) {}

    interface DiscountPolicy {
        double apply(double amount);
    }

    static class DiscountCalculator {
        private static final Map<String, DiscountPolicy> POLICIES = Map.of(
                "VIP", amount -> amount * 0.85,
                "NEW", amount -> amount * 0.90
        );

        double calculate(Order order) {
            return POLICIES.getOrDefault(order.userType(), amount -> amount)
                    .apply(order.amount());
        }
    }

    public static void main(String[] args) {
        DiscountCalculator calculator = new DiscountCalculator();
        check(calculator.calculate(new Order("VIP", 1000)), 850);
        check(calculator.calculate(new Order("NEW", 1000)), 900);
        check(calculator.calculate(new Order("NORMAL", 1000)), 1000);
        System.out.println("全部通过");
    }

    private static void check(double actual, double expected) {
        if (Math.abs(actual - expected) > 0.0001) {
            throw new AssertionError("期望 " + expected + "，实际 " + actual);
        }
    }
}

运行后输出“全部通过”。新增用户类型时，只需在策略表里加一行，不用再碰计算逻辑；想给某个策略加满减或叠加规则，也可以单独写一个实现类，而不是在主流程里再嵌套一层 if。

小步落地的三个步骤

第一步，抽取纯函数：先把计算逻辑从 Service 里搬出来，调用点保持不变，测试全绿再继续。第二步，替换数据结构：用 Map 或枚举注册策略，删除重复分支，并用测试覆盖未知类型走默认分支。第三步，收敛调用点：确认没有其他地方复制了同一段折扣逻辑，再把旧方法标记为废弃，而不是立刻删除，给灰度留出时间。

AI 最容易犯的三个错

一是偷改语义，例如把四舍五入改成截断，或者把未知类型默认折扣从原价改成九折。二是过度抽象，为只有两种分支的逻辑引入一整套框架，反而增加理解成本。三是编造 API：对不熟悉的库，AI 可能给出不存在的方法，凡是涉及新 API 的改动，都要先查官方文档或让编译器验证。

验收清单：重构完成前先自问

公开接口是否没变？所有旧测试是否通过？新增分支有没有对应测试？未知输入是否走了明确的默认路径？代码是否比原来更容易定位问题？只有这些答案都是肯定的，这次重构才算真正完成。AI 可以帮你写得更快，但“行为不变”这条底线，始终要由人和测试来守住。