版本说明：本文基于 Martin Fowler《Refactoring》的核心原则，结合 AI 辅助代码重构的实际经验撰写，适用于有一定项目基础的团队。

工具版本：本文涉及工具的版本信息如下——Claude Code 1.0.x、OpenCode latest stable（2025年）、SonarQube 10.x、lizard 1.17.x、jscpd 4.x、radon 6.x、ESLint 9.x。版本号仅供参考，请以实际使用时的最新版本为准。

适用对象：技术负责人、高级开发者、负责代码质量改进的工程师。

前置知识：第16篇代码考古、第20篇测试编写、第34篇老项目增量开发策略。

一、重构与新功能开发：两种不同的AI策略

第34篇讲了在老项目上安全地做增量开发。本篇讲的是一个更系统性的命题：如何用 AI 帮你重构和优化现有代码，让代码质量得到实质性提升。

重构和新功能开发是两种完全不同的工作场景，需要不同的 AI 使用策略：

Martin Fowler 在《Refactoring》中对重构的定义是：重构是对软件内部结构的一种改变，目的是在不改变软件可观察行为的前提下，使其更容易理解、更容易修改 。这个定义中有两个关键词——"不改变行为"和"更容易理解"。

LinearB 的调研显示，AI 编码 Agent 在代码重构场景中的可靠性明显高于从零生成——因为重构有明确的输入（现有代码）和验证标准（行为不变），AI 的"幻觉"空间被大幅压缩 。

二、AI辅助重构的适用场景

2.1 代码异味消除

"代码异味"（Code Smell）是 Kent Beck 和 Martin Fowler 提出的概念，指代码中那些表面上看不出 Bug、但暗示着设计问题的特征 。

常见的代码异味：

SonarQube 是企业级代码异味检测的主流工具 。DeepSource 提供了更轻量的替代方案 。Python 项目可以使用 smellcheck 进行快速异味扫描 。

AI 在代码异味检测中的独特价值在于不仅能发现异味，还能分析根因并给出具体重构方案：

Prompt 示例：

请扫描 CouponCalculationService 类，识别代码异味：

分析维度：
1. 方法长度：哪些方法超过 30 行？
2. 圈复杂度：哪些方法逻辑分支过多？
3. 重复代码：是否有相似逻辑在多处出现？
4. 职责分析：这个类是否承担了过多职责？
5. 依赖分析：是否有不合理的依赖关系？

对每个发现的异味标注严重程度（Critical / High / Medium），
说明为什么是问题，给出重构建议，评估重构风险。

AI 输出示例（Claude Code 分析代码异味）：

扫描 src/main/java/com/example/coupon/ 目录，发现 3 处代码异味：

1. [Critical] CouponServiceImpl.java:85 - 圈复杂度 24（阈值 10）
   方法 calculateDiscount() 包含 8 层嵌套 if-else，涉及满减、折扣、
   会员等级、新人优惠等多重判断逻辑叠加，极易出错且难以测试。

2. [High] CouponController.java:42 - 方法过长（95行）
   createCoupon() 方法同时处理参数校验、业务逻辑、响应构建，
   违反单一职责原则。

3. [Medium] CouponMapper.xml:17 - SQL 过于复杂
   动态拼接了 12 个条件分支，缺少索引使用分析，存在全表扫描风险。

建议优先重构 #1，因为圈复杂度 24 的方法测试覆盖率几乎不可能达标。

2.2 过时模式迁移

项目迭代过程中，技术栈不断演进。一些写法在当时合理，现在已过时：

IBM 指出，AI 辅助代码重构的核心能力之一是模式识别——AI 能快速扫描整个代码库，识别所有使用过时模式的代码位置，并生成迁移方案 。

2.3 性能瓶颈优化

Martin Fowler 在《Is Optimization Refactoring》中明确区分了重构和性能优化 ：重构改善代码结构，性能优化改善资源使用效率。但两者的方法论有重叠——都需要先分析、再逐步改进、最后验证。

AI 分析性能瓶颈的典型场景包括：N+1 查询检测、全表扫描识别、串行操作并行化、热点计算缓存等。