使用claude code重构复杂if-else为策略模式的实践

我曾在一个支付路由项目里亲眼看着一段 if-else 从 47 行长到 840 行，用了十一周。那段代码没有一个超过 60 行的函数，但每个函数都嵌套着三四层条件判断，每次上线都要祈祷“别影响到那条不常用的分期通道”。后来我用 Claude Code 把它拆成了策略模式实现，重构过程的感受很分裂，AI 确实快，但你得知道该让它快在哪里。

这篇文章不会跟你讲“策略模式的定义是将一系列算法封装起来使它们可以互相替换”这种话。我要讲的是 Claude Code 到底能替你做什么、不能替你做什么，以及你该怎么指挥它完成一次不会后悔的重构。

一、先给结论：Claude Code 的定位不是“代码搬运工”，而是“设计决策加速器”

很多人对 AI 辅助重构的期待是：把一坨 if-else 扔进去，它给我吐出来一套策略模式代码，我直接提交、上线、下班。但我做的六次复杂条件重构下来，真实情况是：Claude Code 能帮你把从“理解业务到可交付代码”的时间压缩 60-70%，但它做不到 100% 自动化，也不该做到。

具体来说，它能做的三件事：

1. 识别条件分支中隐含的策略边界：你把一段几百行的条件逻辑给它，它能比大多数中级工程师更快地归纳出“这里有 7 种折扣策略、3 种运费计算规则”。
2. 生成符合接口约束的样板代码：策略模式的核心是接口定义和实现类的结构，这部分 Claude Code 几乎是零出错率的。
3. 生成重构验证所需的单元测试骨架：这部分可能是它最大的价值，我们后面细讲。

它做不到的三件事：

1. 判断“该不该用策略模式”：这件事只有人能做，因为它需要理解业务的演变方向。
2. 处理隐式依赖和副作用：那些写在 if-else 里的日志打点、缓存更新、事件发布，AI 会忽略或粗暴迁移。
3. 保证重构后的行为等价：没有测试保护的 AI 重构，就是在赌命。

所以这篇文章的核心观点是：AI 不会替你思考架构，但它会让你思考架构的速度快十倍。 下面我把我六次重构踩过的坑和方法论完整展开。

二、你的 if-else 真的需要策略模式吗？一个决策框架

1. 我先踩过的最大的坑

2024 年 11 月，我接手一个营销活动发券模块。核心逻辑大概是：根据用户等级、注册时长、近 30 天消费金额、是否新客、活动类型，判断发哪种券、发几张、有没有叠加资格。代码里一个processCoupon()方法 280 行，里面嵌套着 11 层 if-else。

我当时想都没想，直接让 Claude Code 把它重构为策略模式。AI 很听话，拆出了 14 个策略类，一个 CouponContext，一个 StrategyFactory。代码看起来很漂亮。

然后灰度上线第一天，老用户领券成功率跌了 36%。

排查下来发现，原代码里有一段逻辑是：如果用户等级为 VIP 且活动类型是“限时抢购”，则在发券前需要同步调一个用户画像服务更新标签，这个调用藏在一大段嵌套 if-else 的第 7 层，没有任何注释。Claude Code 把它当作“普通条件分支”拆到了某个策略类里，但忽略了它其实是一个前置的副作用操作，应该在所有策略执行前触发。

教训很简单：不是所有 if-else 都适合拆成策略模式，更不是所有代码都适合交给 AI 去理解业务意图。

2. 一个自己用得起的判断框架

我现在判断一段 if-else 要不要策略化，会先回答三个问题，而不是直接看代码行数：

问题一：分支数量是否稳定增长？

如果这段代码的分支在过去三个月里增加了两次以上，并且业务方明确说了“下季度还要加三种场景”，那信号已经很明确了。策略模式解决的核心问题是“扩展”，不是“复杂度”。如果分支数一年不变，别动它。

问题二：每个分支的逻辑是否相对独立？

这是 Claude Code 帮不上忙的部分，你得自己看。如果分支之间存在大量共享的中间变量、相互依赖的中间计算结果，说明这些分支的职责没有真正分离。强行拆策略模式只会让代码从一个 500 行的大文件变成 15 个 70 行的小文件，但整体复杂度不降反升，因为阅读成本从“纵向滚动”变成了“横向跳转”。

问题三：是否已经有针对这段代码的业务级测试？

如果你没有测试，或者只有几个覆盖主流程的冒烟测试，先别动架构。 这是我用一次线上事故换来的教训。你应该先让 Claude Code 帮你补测试，然后再重构。顺序不能反。

三、重构前的“摸底”：用 Claude Code 理解老代码，而非直接改

1. 先做代码考古，别上来就写策略接口

我的标准做法是：把那段复杂 if-else 的代码文件喂给 Claude Code，然后不问“这段代码怎么重构”，而是问三组问题：

第一组：逻辑提取

“请列出这个方法中所有的 if-else 分支条件，按业务含义归类，不要列出纯技术性的空值判断和参数校验。”

这一步的目的是让 AI 帮你做“分支归并”。人的大脑在处理超过 7 个条件分支时，归类和记忆能力会显著下降。Claude Code 不会漏，也不会因为“这段逻辑太绕”而跳过。

第二组：依赖分析

“请分析这个方法内部调用了哪些外部服务、数据库操作、缓存操作，以及它们与条件分支的对应关系。”

这一步会暴露出前面提到的“隐藏副作用”。比如某个分支里读到一半突然更新了用户标签，这本身就是设计问题，应该在重构前被显式地标记出来。

第三组：测试覆盖分析

“请基于这段代码的逻辑，列出哪些分支路径缺少单元测试覆盖，并给出补测优先级。”

这一步是我现在做重构的强制前置步骤。我会让 Claude Code 直接生成缺失测试的代码骨架，我只需要写断言。

2. 一个真实摸底案例

今年三月份我重构过一个用户评分引擎。输入是用户的 12 个行为维度得分，输出是一个综合等级（S/A/B/C/D）。原代码是一个 340 行的calculateLevel()方法，里面有 19 个 if-else 分支，相互之间有优先级关系。

让 Claude Code 做摸底分析后，它输出的归类结果是这样的：

• 维度权重计算类分支：7 个（直接映射到策略）
• 等级边界判定类分支：5 个（可以用策略，但要引入优先级排序）
• 异常降级与兜底类分支：4 个（不应该拆，这是容错逻辑）
• 已废弃但未删除的分支：3 个（AI 标记为“可能未使用”，我人工确认后直接删了）

这个摸底结果直接改变了我的重构方案。原本我想全部策略化，后来我只拆了前两类，后两类保持原样但加了注释和隔离。

这就是一个很重要的认知：人负责做“架构层面的归类”，AI 负责做“模式识别层面的归纳”。 你把分类决策权交给 AI，它一定会拆出一些看起来很对但跑起来炸的东西。

四、怎么给 Claude Code 下重构指令？Prompt 的核心不是“what”，而是“constraint”

1. 最常见的错误 Prompt

“帮我把这段 if-else 代码重构为策略模式。”

这个 Prompt 的问题在于你给了 AI 无限的自由度。它会用最教科书式的方式做重构，给你一个 Strategy 接口、一堆 ConcreteStrategy 类、一个 Context 类。代码能跑，但你接不住。

为什么会接不住？因为 AI 不了解你的项目结构、包命名规范、依赖注入方式、异常处理规范、日志格式要求。它吐出来的代码你要大改才能合入项目。而“大改”意味着引入新 bug 的风险。

2. 我逐渐收敛出的指令结构

现在我的重构 Prompt 是分三层输入的：

第一层：约束条件（最重要）

我把项目的技术约束先列清楚，不留给 AI 自由裁量空间：

• 策略接口命名为XxxStrategy，放在strategy包下
• 所有策略类通过 Spring 的@Component注册，禁止手动 new
• 异常统一抛出自定义的BizException，不得吞异常
• 日志使用@Slf4j，关键分支必须打印入参和结果
• 必须有空值保护，禁止返回 null

第二层：业务语义说明

简短说明这段代码的业务目的。不用写注释那么详细，但要给 AI 一个理解代码的“锚点”，它需要知道这段代码在业务上到底要干什么，才能做出合理的拆分。

第三层：重构后验证要求

要求它在生成重构代码的同时，基于原逻辑生成对比测试，用同样的输入分别跑原方法和新方法，对比输出一致性。这一步我后面会展开讲。

3. 一个被低估的技巧：要求 AI 先输出“策略清单”

在真正生成代码之前，我会多加一步：“先输出你识别到的策略清单，格式为：策略名称、触发条件、对应原代码行号范围、是否包含外部调用。”

这个步骤的作用有两个：

第一，让我能在代码生成前做一次逻辑把关。如果 AI 把三个本应合并的策略拆成了六个，或者把一个不应该拆的异常处理分支当成了策略，我在这步就能纠正，不用等代码生成后再去读十几个类。

第二，这份清单本身就是重构文档。项目里其他人看不懂新架构的时候，这份清单比任何注释都管用。

五、实战全流程：一个完整的重构案例

下面用我最近做的一个案例来演示完整流程。场景是一个电商订单的价格计算引擎，核心方法是calculatePrice(OrderContext context)，输入订单上下文，输出最终价格。原代码 470 行，包含 23 个 if-else 分支。

业务背景： 价格受会员等级折扣、满减活动、优惠券叠加、区域加价、大促特殊规则五种因素影响，优先级不同，部分因素互斥。

Step 1：摸底分析

我把代码喂给 Claude Code，要求输出三样东西：分支归类、外部调用清单、测试缺口。

输出结果让我发现了一个之前没注意到的 bug：满减活动的计算逻辑里，有一段对“已参与其他活动商品”的跳过判断，但这段逻辑因为三次迭代后变量命名不一致，已经失效了至少两个月，线上一直在多算满减。这个 bug 如果不是为了重构去做摸底，大概率会继续潜伏。

Step 2：策略清单确认

Claude Code 输出了 8 个策略候选：

1. 普通会员折扣策略
2. VIP 会员折扣策略
3. 满减活动策略
4. 优惠券抵扣策略
5. 区域加价策略
6. 大促统一直降策略
7. 限时秒杀价格覆盖策略
8. 兜底原价策略

我检查后发现 1 和 2 可以合并为一个“会员等级折扣策略”，通过等级参数做内部区分。6 和 7 的执行优先级有问题，大促直降和秒杀不能叠加，但原代码里因为 if-else 的顺序问题，在某些边界条件下两个都命中了。我在这一步修正了策略清单和优先级规则。

Step 3：定义策略接口

这一步我来做，不让 AI 做。接口设计是整个重构的核心，决定了未来扩展的灵活性。

我定义的接口很简单：

public interface PriceStrategy {
    boolean supports(OrderContext context);
    BigDecimal calculate(OrderContext context, BigDecimal currentPrice);
    int getPriority();
}

supports负责判断是否命中策略，calculate接收当前价格并返回计算后的价格，getPriority控制执行顺序。这个接口设计的关键决策是：策略之间是链式传递的，而不是互斥选择的。 也就是说一个订单可以依次经过多个策略的计算。这个决策是我根据业务场景判断的，价格计算通常是多层叠加的，会员折扣叠加优惠券再叠加满减，而不是“命中一个策略就结束”。

Step 4：生成策略实现

把策略清单和接口定义给 Claude Code，让它逐个生成实现类。这一步我的指令重点是：输出时标注每个策略在原代码中对应的行号范围，并在关键计算逻辑处保留原注释。

AI 生成完 7 个策略类后，我逐个人工 review。发现的问题有：

• 满减策略的阈值判断用了硬编码数字，应该是从配置读取
• 优惠券策略的错误处理吞了一个超时异常，应该向上抛出
• 两个策略的getPriority()返回值不合理，需要调整顺序

这些问题如果我不 review，AI 生成的代码也能跑，但会在特定边界条件下出问题。

Step 5：生成 Context 和工厂类

策略模式的 Context 负责组装策略链并执行。这部分逻辑很标准化，Claude Code 生成基本不会出错。我的 Prompt 里指定了：策略链按 priority 排序执行，遇到价格小于等于 0 的情况中断并报警。

Step 6：生成对比测试

这是我整套方法论里最核心的步骤。我让 Claude Code 做了两件事：

第一件事：生成“行为快照”测试。 从现有代码的测试用例和历史订单数据中采样 200 组输入，用原方法生成输出结果作为“黄金标准”，存储为 JSON 文件。

第二件事：生成对比测试代码。 用同样的 200 组输入，跑新的策略链，逐一对比输出是否与黄金标准一致。

这一步帮我抓住了两个 bug：一个是在某个边界条件下策略执行顺序和原逻辑不一致，导致价格差了 0.01 元（浮点数精度问题）；另一个是大促策略的日期判断逻辑在原代码里用的是服务器本地时间，而 AI 生成的代码默认用了LocalDate.now()，时区表现不同。

没有这 200 组对比测试，这两个 bug 上线后才会被发现。

六、重构验证的“双重保险”方法论

1. 行为快照对比：我最重要的经验

传统重构依赖两种验证手段：单元测试和代码审查。

单元测试的问题在于它测的是“你认为应该怎样”，不是“原代码实际上怎样”。 原代码里很可能有一些你根本不知道的行为，前面提到的用户画像标签更新就是典型。单元测试覆盖不了这些未知行为，因为写测试的人压根不知道它们存在。

代码审查的问题在于人的注意力有限。 面对 7 个新增的策略类，你能逐行比对出所有的行为偏差吗？很难。尤其是浮点数精度、时区处理、异常传播这些细节。

行为快照对比的做法：把原方法当黑盒，灌入大量真实或构造的输入，记录输出。然后用同样的输入灌入重构后的方法，对比输出。不一致的地方就是“行为的净变化”，你需要逐一判断这些变化是“预期内的修正”还是“非预期的退化”。

Claude Code 在这个环节的价值是：它能非常快地生成那些覆盖边界条件的测试输入，空值、零值、极大值、过期时间、并发场景模拟。

2. 灰度与监控：为 AI 重构多加一层保险

即使对比测试全过，我还是会在灰度阶段多做一些事：

• 新老逻辑双跑：上线初期同时执行新旧两套逻辑，以老逻辑的结果为准，新逻辑的结果只做对比记录。对比一致率达到 99.9% 以上才切到新逻辑。
• 关键指标监控：对于支付、价格这类核心链路，我监控的不只是报错率，还包括数值分布，如果重构后价格分布的整体均值或分位数发生了位移，即使没有报错，也要排查。

七、哪些坑我帮你们踩过了

坑一：AI 生成的策略接口太“标准”了

Claude Code 默认生成的策略接口往往是这样的：一个execute(Input input)方法，返回Output。看起来很干净，但它忽略了一个关键问题：策略之间是否需要上下文传递？

在价格计算场景里，策略之间需要传递“当前已计算的价格”，所以接口需要设计为链式传递。在另一个“文件导出”场景里，策略之间完全独立，互斥选择即可。接口怎么定义，应该由人根据业务场景决定，不要让 AI 选。

坑二：枚举和映射表的过度自信

AI 特别喜欢用枚举加映射表来替代 if-else。这在分支条件简单且稳定时很好，但如果条件判断有优先级、有互斥、有短路逻辑，枚举映射会导致逻辑丢失。我见过一个案例：Claude Code 把一段有短路逻辑的 8 分支 if-else 换成了一个Map<Condition, Handler>，外观上看起来好多了，但短路特性没了，原本命中第一个条件后不执行后续分支，现在变成所有条件都会被执行一次。

坑三：异常处理被“标准化”了

AI 在生成策略实现类时，倾向于给每个类加上统一的 try-catch。这听起来很好，但实践中会导致两个问题：一是不同策略的异常处理策略本应不同（有的要重试，有的要降级，有的要抛出阻断），统一处理会丢失这层语义；二是异常被吞掉后，上层感知不到子策略的失败，容易造成静默错误。

我的处理方式是：在 Prompt 里明确指出“异常处理策略不要统一，保留原代码的异常传播行为”。

八、什么情况下用策略模式会后悔

我明确说三种我自己踩过坑的场景：

第一种：分支条件本身不稳定。 如果 if-else 的条件表达式每个月都在变（比如运营规则频繁调整），策略模式会变成灾难，每次条件变了，你不仅得改判断逻辑，还得调整策略类的supports方法，甚至要改策略选择器。这种场景下，规则引擎（比如 Drools 或者简单的表达式解析器）比策略模式更适合。

第二种：策略数量很少且未来也不会增加。 2-3 个分支的场景，拆成策略模式只会增加文件数量、增加跳转次数、增加新同学的理解成本。小于 4 个分支的 if-else，如果你能用一个清楚的注释说明每个分支的业务含义，那就别动。

第三种：分支之间有严格且复杂的执行顺序，且顺序本身是业务规则的一部分。 这种场景下策略模式的“可插拔”特性其实是劣势，你会希望执行顺序是显式维护的，而不是藏在策略选择器的优先级排序里。责任链模式加上显式的链构建代码，可能更合适。

九、下一步行动指南

如果你读到这里打算开始做一次 AI 辅助的重构，我建议你按这个顺序来：

第一步：选一个“小但典型”的目标。 别一上来就挑项目里最复杂的那段几千行的 if-else。选一个 100-200 行、逻辑能看懂、但有 5-10 个分支的场景。目标是建立人机协作的 muscle memory，不是一次解决所有技术债务。

第二步：先别让 AI 写代码，先让它做分析。 把你的代码给 Claude Code，按前面说的三组问题做摸底。你会发现光这一步就值回票价，AI 在“看代码”这件事上比人仔细。

第三步：你自己决定接口。 策略接口的定义是人类专属的工作。想清楚策略之间的关系是链式还是互斥、需要传递什么上下文、异常如何传播。

第四步：让 AI 生成策略清单，你审核后再让它生成代码。 控制节奏，不要一步到位。策略清单是你最后的低成本纠错机会。

第五步：生成对比测试，跑行为快照。 老代码当黑盒，新老对比。这是 AI 辅助重构最大的独特价值，传统重构很难做到这个量级的对比测试，AI 能高效地生成测试数据和测试代码。

第六步：灰度双跑，看数据说话。 不要相信任何“看起来没问题”的感觉，用数据切流。

当 AI 能把样板代码的生成时间从两小时压缩到两分钟，它释放的不是你离开键盘去喝咖啡的时间，而是让你把认知资源投入到真正需要判断力的地方：这段代码到底该不该拆、接口该怎么设计、边界条件如何覆盖、异常如何处理。以后能拉开工程师差距的，不再是“代码写得快不快”，而是“指挥 AI 指挥得对不对”。 而指挥得对不对，取决于你自己对架构、业务和风险的理解有多深。

所以，从你项目里那个最小的、让你不舒服的 if-else 开始。别想着一次做对，先做一次，拿到真实的 AI 协作体验，你会有自己的判断。这篇文章的方法论是地图，但路得你自己走。