接手一个跑了七八年的老系统第一感觉就像走进一间堆了十年的杂物间。我上个月刚碰一个订单服务入口 Controller 一千多行一个生成报价的私有方法五百行里面还藏了三个标志位交叉判断。新需求排期永远估不准改一行日志都可能触发线上报警。老项目的问题从来不在某一个文件“写得脏”而在于没人能说清楚哪一块可以被安全改动。这种局面下“AI 代码整洁器”这个词最近频繁出现。很多团队开始尝试用 AI 辅助重构、整理老代码。我自己的体会是它不能一键把屎山变成花园但配合合理的流程它能把以前需要花两周试探性梳理的工作压缩到一个下午。这篇博文就来聊聊我实际怎么用 AI 给老项目“减负”包括工具选型、分步操作、踩坑实录以及哪些场景我坚决不让 AI 碰。1. 先摸清“屎山”的家底老项目到底烂在哪1.1 屎山代码不是“脏”是“失控”很多人提到屎山代码第一反应是缩进不对、命名混乱、注释太少好像找几个格式化工具跑一遍就能解决。但真正让你头疼的往往不是表层问题而是结构上的失控。这类项目最常见的三个反模式上帝类、超长方法、重复代码蔓延。上帝类动辄几千行字段几十个方法十几个每一个方法都能访问全局状态改一个字段影响一片逻辑。超长方法则是把一个业务流程从参数校验一路写到数据库操作中间没有任何拆分任何一步出问题只能靠人肉 debug。重复代码更不用说很多老系统里同一个“计算折扣”的逻辑可以在十个地方各写一份每份还稍微不一样。我当时处理的那个订单服务一个核心类就有 6000 多行其中十几个字段在代码里被赋值过但有些从没被读取过。它们就像房间里堆了十年的旧报纸你不敢扔因为你不知道底下压着的发票是不是还有用。这种代码库根本问题不是“脏”而是没人能安全地动它已经处在失控状态。也不要把责任全推给谁。屎山往往是业务高速迭代、人员流动、工期紧张共同堆出来的结果。需求永远在变最开始的架构设计在业务膨胀之后早就失真后来的人只能不断打补丁补丁多了项目自己也开始长胖。这不是某个人的道德瑕疵而是软件工程的常态所以我们才需要系统性的整理手段而不是指望谁突然“讲武德”。1.2 技术债的账单为什么越拖越不敢动老项目最典型的恶性循环是代码越乱改动成本越高团队越不敢重构然后代码变更乱。我见过很多团队对老模块的态度是“少碰为妙”。新需求能绕开就绕开实在绕不开就在外面包一层。这个策略短期内能降低风险但长期看是在给技术债加利息。如果我没有记错有个线上项目就因为某次改了一个看似无关的 getter 方法结果在月末结算时把库存校验的顺序弄反了最后全链路返工。越拖越不敢动的核心原因有两个一是缺少测试兜底二是调用关系不透明。很多老模块压根没有单元测试连最基础的 smoke test 都没有你改了代码之后唯一能确认的就是“编译能过”。编译能过但不代表行为正确这正是重构时最害怕的。另一方面老项目的方法调用链往往很长一个工具方法可能被十几个业务场景共用你根本不知道改它会牵连到哪一块。这里可以用个生活化的类比老代码就像老房子的电路当初布线的时候就没有图纸后来还加装了各种电器。你只是想把一个插座换掉但墙里那根线可能连着隔壁的灯。如果没有专业的思路和工具你大概率会直接把墙凿开然后后悔。技术债的账单不会惠顾任何人它只是在未来某一天被加倍要求偿还。所以在引入 AI 工具之前必须先把老项目的问题摸清楚知道烂在结构还是烂在细节才能决定如何动手。1.3 什么样的老项目适合用 AI 先排雷不是所有“屎山”都适合直接上 AI 重构工具。根据我的经验符合下面这些条件的项目用 AI 介入的效果会好很多判断项适合用 AI暂时不适合能否编译通过可以至少主链路能跑通编译都过不了到处都是基础错误版本控制有 Git有提交历史连版本库都没有改动无法回溯测试基础有一些关键路径测试或手动回归步骤完全没有验证手段改了只能靠预感模块边界有清晰入口比如 Controller-Service-Mapper模块之间互相 new、全局单例满天飞目标预期局部清理、逐步重构想一句话让 AI 把整个系统重写如果项目连编译都过不了先别谈 AI。这时候最优先的任务是把项目恢复到可构建状态包括补齐依赖、修好基础配置否则 AI 的很多建议都是空中楼阁。尽快让老项目达到一个基本稳定的状态之后再让 AI 承担“排雷”的工作。我见过一些团队一上来就要求 AI“帮我重构整个订单模块”结果 AI 给出的方案再完美他们也跑不起来。原因很简单AI 没有运行环境不知道你的项目到底还有多少隐藏的编译错误。与其这样不如把老项目的状态先修到一个能跑的水平再谈后续优化。基础不稳工具再好也没有用武之地。2. AI 代码整洁器怎么选工具定位和取舍要搞明白2.1 再厉害的 AI 也只是辅助先明确工具类型市面上现在能用于代码整洁的 AI 工具大致分两类一类是 IDE 插件形式的 AI 编程助手另一类是本地部署的开源模型。两类目标一致都是帮你理解、生成、修改代码但使用场景和边界区别很大。IDE 插件类的代表很多。比如 GitHub Copilot 可以直接在编辑器里给出补全和重构建议看看我强调“建议”这个词它本质是实时预测你下一步要写什么而不是真的理解整个项目架构。Cursor 这类编辑器则擅长对话式操作你可以把多个文件拖进上下文让模型跨文件分析调用关系这对重构来说很实用。JetBrains 系的 AI Assistant 也类似适合重度 IDEA 用户。我自己在 Java 老项目里用得最多的其实是局部重构提示选中一个超长方法让 AI 给我拆分成几个私有方法并保持原有行为不变。这种操作不需要模型理解全部业务只需要它在有限范围内给出合理拆分建议IDE 插件的效率就很高。多文件、跨模块的改动我会切到 Cursor 这类对话式工具先把调用链梳理清楚再动手。不建议新手同时装一堆插件。工具不在多在于能形成稳定工作流。装一个你熟悉的主力工具先用透比什么都新鲜、最后都只会点“自动格式化”要强得多。2.2 本地部署模型专治代码不能出内网的场景做老项目重构时最敏感的问题是很多公司代码不允许上传到外部 API。银行、医疗、电商、内部管理系统都有这个限制。这种情况下本地部署一个开源模型是相对稳妥的选择。我一般推荐用 Ollama 这类工具快速拉起一个开源模型配置过程很轻量。比如拉一个适用于代码任务的中等尺寸模型本地跑起来之后配合 Continue 这类开源插件直接在 VSCode 里用本地模型做代码解释、重构建议。模型大小会影响显存需求没有特别高配的机器也可以选择量化版本在效果和资源消耗之间做平衡。本地模型的准确率相比顶级云端模型会有一些差距尤其在复杂语义理解上。但对于“解释这个方法在干什么”“按某种风格改写”“找出明显的重复代码”这类结构化任务完全够用。更重要的是数据不出内网合规风险大幅降低这对老项目改造来说是硬指标。在我实际处理过的场景里本地模型帮我们把一个供应商模块的调用关系整理成了文档全程代码没有出过内网。虽然中间需要人工校对但至少打开了“安全触碰老代码”的第一道门。如果你所在的项目同样有代码出网限制建议优先把本地部署方案跑通再谈后续效果。2.3 AI 工具只能给建议不能背锅我见过很多团队对 AI 重构有过高期待以为像“一键格式化”一样按个按钮代码就变干净了。现实完全不是这样。AI 没有运行环境不知道编译器的报错更无法承担业务正确性的责任。它生成的重构建议本质上是对语料库模式的一种概率预测。在你输入“拆分这个方法”之后它能给出看起来合理的输出但代码在你们的业务里到底意味着什么它并不真正知道。同样一个方法在 A 项目里拆成两步没问题在 B 项目里可能因为共享状态直接爆炸。我现在的习惯是把 AI 定位成“结对初级工程师”。它速度极快擅长总结和搜索候选但决策必须由人来做。给它清晰的任务边界让它输出候选方案你负责评审、实施和最终回归。这个过程里AI 能帮你省掉大量耗时的阅读和理解工作但绝不会替你兜底。也就是说把 AI 当作效率放大工具而不是自动化的清洁工人。工具本身没有好坏的绝对之分关键看你怎么定义它的职责。3. 实战记录用 AI 给老项目做第一轮“微创手术”3.1 第一步让 AI 先画一张代码地图在动手改任何代码前我做的第一件事是让 AI 生成一张“代码地图”。所谓地图不是画 UML而是理清当前项目有哪些核心模块模块之间的依赖关系长什么样哪个类最容易出问题。这一步很简单但也容易忽略。我会把项目目录树复制一份粘贴给 AI要求它输出每个顶层模块的职责说明和明显的依赖环。比如请阅读这个项目的目录结构帮我输出 1. 每个顶层模块大概负责什么业务 2. 哪些模块之间存在明显依赖 3. 哪些模块看起来是核心链路不宜轻易改动 4. 有没有重复职责的模块 项目结构如下 [粘贴目录树]AI 给的回答不一定完全准确但能快速提供一个“地图草稿”。你可以把这份草稿贴在项目 Wiki 里团队后续讨论会轻松很多。这个动作本身不产生业务风险却能让所有人都知道哪里危险、哪里相对独立。做完这一步我通常会挑几个高风险的互斥模块重点看比如“结算服务”和“优惠券服务”把它们的入口类、核心 service、DAO 之间的关系让 AI 再细化一遍。这样后面做重构时就不会两眼一抹黑。3.2 第二步拆解千行大函数一次只切一刀前面提到那个 500 行的生成报价方法是我当时改造的重灾区。它内部做了参数校验、折扣计算、税费计算、组装明细、写日志五件事每一步都根本不缺“代码”而是缺“边界”。我采取的方案是让 AI 把方法按职责拆分成多个私有方法但要求它先输出拆分思路而不是直接给我最终代码。比如我会这样跟模型沟通下面是一个长方法它本身承担了至少5个职责。请先输出每个职责对应代码块的起止行号再给出提取为私有方法后的方法签名和调用顺序不要直接生成完整代码。我需要在确认拆分方向后再动手。这种方式非常有效。它逼着 AI 先把逻辑分层说清楚而不是直接丢给我一坨“看起来合理”的代码。拿到拆分方案后我一个个手动抽取。每抽取完一个方法立即编译、跑一遍测试再继续下一个。整个过程像微创手术一次只切一刀保证病人状态始终可控。拆完之后那 500 行变成了一个清晰的主流程外加五个小方法阅读成本明显下降。最明显的变化是后来新需求进来时我能直接定位“改税费计算只需要改一个方法”而不需要拖拽整页代码从头看到尾。3.3 第三步合并重复代码但要小心“过度抽象”年轻的时候做重构我特别喜欢抽象看到两段代码长得像就忍不住抽成公共方法。后来在一个老项目里吃过亏才知道“过度抽象”也是一种犯罪。AI 很适合帮我们找出重复代码它会按相似度把可疑片段列出来。我当时用 AI 扫了一遍订单模块发现至少有 3 处“创建订单基本信息对象”的逻辑高度重复每一处都各自维护着一份字段复制代码。看到这个结果常规思路肯定是抽一个公共构造方法这没问题。但危险在于两段代码表面上相似实际运行语义可能不同。我第一次让 AI 合并的时候它把“有优惠券”和“没有优惠券”的两个分支合并了结果在某个特殊场景下优惠金额被重复计算。因为老代码里某些字段只在特定组合下才有意义简单合并等于丢失了隐含分支。所以我现在处理重复代码时遵循一条规则先让 AI 列出相似片段然后人肉看差异只有在语义完全一致的前提下才允许合并。如果需要合并的分支有隐性逻辑就先给每个分支写清楚测试再动刀。宁可多做一小步也不要让抽象成为新的破坏点。3.4 第四步顺手补测试和文档别把老项目当黑盒重构老项目最怕的是“改了之后不知道有没有改坏”。为了给后续的改动兜底我通常在动代码之前就先让 AI 生成一轮“特征测试”也就是把当前行为先固化下来。所谓特征测试就是照着现有代码行为写测试不管逻辑对不对先确保重构后的行为和重构前一致。你可以把核心方法的实现贴给 AI然后要求它生成测试用例请根据下面的方法实现生成一组单元测试要求 1. 覆盖正常路径、异常路径、边界条件 2. 生成的数据结构尽量独立不依赖外部服务 3. 对于无法直接构造的依赖使用 null 或简单的 stub 4. 标注出模棱两可、你无法确定语义的地方AI 生成的测试能覆盖大部分 happy path但在老代码里真正有风险的是隐式状态和外部依赖。比如一个方法内部用了静态工具类生成测试时根本没有注入口这就得靠人来设计可测试性改造。这个阶段我会把 AI 生成的测试当作草稿然后手工补充那些“让代码更可测”的改动比如让依赖通过构造方法传入而不是在方法里 new 一个对象。文档方面也用 AI 补了很多。老项目最难懂的就是“当初为什么这么写”AI 不可能知道历史但可以根据代码逻辑反推一份“现状说明”。我把生成结果当作一种“别人眼中的代码描述”再让人工补充业务背景最后放到模块目录下。这样一来新同事接手时至少不用从头去猜。4. 现场踩坑AI 重构最常见的 6 个翻车现场4.1 一跑编译报错几十条AI 改代码最让人头疼的问题不是思路不对而是它的输出经常是“部分正确”。有一次它帮我合并两个相似方法生成的代码里漏了两个 import还把一个类名拼错了导致整个模块编译失败。编译错误一多人就容易慌一慌就容易回滚重构白做。经验是把改动范围压到最小。每次最多让 AI 在“单个文件 明确的步骤目标”下输出建议不要一次给一整个模块让它随便改。拿到 AI 的输出后先不着急使用让它在编辑器的 diff 里逐行过一遍确认没有删除不该删的 import也没有引入不存在的依赖。另外编译报错时不要直接让 AI“帮我修复所有错误”这会触发一串连锁修改反而更难控制。正确做法是把错误信息贴给它然后问它“这个错误和刚才的改动有什么关联”先定位到根因再决定下一步。4.2 模型只会加码不会删码用过一段时间后我发现大模型天然倾向于生成新代码而不是删除旧代码。让它“提取公共方法”它往往会保留原来的方法体然后新增一个同名方法调用旧方法结果代码量不降反升。看起来像是重构了其实是套了一层壳。这种“加壳式重构”好几个场景都会出现。有一回我让它把一段重复代码抽出来它给我的结果是在原文件中新增了一个私有方法但是原来的调用点一个都没改。代码变得更冗长维护成本也更高。解决办法是我先给出明确的指令“请输出重构后该文件的完整内容原始方法体要删除新的调用点要同步更新。”如果模型依旧犹豫不决那就先让它列出“应该删除的方法体”和“应该更新的调用点”我手动删对照检查。整个过程中“删除”这个动作必须由人来执行AI 负责校验这和让 AI 直接生成一个完整文件相比安全性高很多。4.3 行为悄悄变了测试却还是绿的测试通过不代表行为没变。有次 AI 帮我重写一个排序方法把原本数组元素的原地排序改成了流式操作结果单元测试里的断言恰好只关心返回结果没有检查原数组是否被修改。在测试层面看全都通过了可调用这个方法的业务代码却因为原数组内容被改变而崩溃。这是重构里最隐蔽的问题隐式副作用。老代码里特别爱用可变对象方法会修改入参、会访问全局单例、会依赖静态变量。AI 在“优化”时根本没意识到这些隐性契约它只看到“可以简化”的表面。我的建议是在重构前先让 AI 明确列出这个方法“对外部状态的读写点”比如它改了哪些入参、访问了什么静态变量、是否依赖线程局部变量。确认所有副作用之后再让 AI 动手。改完之后除了跑测试还要专门做一次“diff 行为审查”逐行确认没有丢掉任何副作用。4.4 上下文塞满模型开始胡编老项目代码量大很多人为了省事会把好几百行代码一股脑塞给 AI然后问它“这段代码是什么意思”。结果模型经常会把类 A 的方法说成类 B 的甚至把参数名都编错了。因为上下文窗口虽然大但内容一多注意力就会被稀释模型更容易给出“最像正确答案”的幻觉。我自己的习惯是喂给模型的代码要够聚焦。单个请求最多包含一个类或一个方法的完整实现同时把类名、方法名、关键字段在请求里显式写清楚。如果模型给出的解释和实际代码明显对不上大概率是它在硬猜这时候不要继续追问而是缩小范围重新定向。还可以在提示词里加一句“如果你不确定请直接说不知道”。这听起来有点傻但实际很有效。它能让模型少一些一本正经的胡说八道把不确定的地方暴露出来安全风险反而下降。4.5 循环依赖和隐藏状态AI 绕不清一些老项目里存在明显的循环依赖A 调用 BB 又调用 A甚至中间还夹着静态单例。让 AI 对这种代码做重构几乎必然翻车。因为 AI 看到的是静态代码但静态代码无法反映运行时真正的调用时序尤其当全局状态在多个方法里被反复读写时AI 给出的“最优化方案”往往会让行为整体漂移。我遇到过最离谱的一次是 AI 建议把两个相互调用的 Service 合并成一个理由是“减少循环依赖”。从静态结构看它说得有道理但这两个 Service 实际上属于不同的业务模块一个负责订单一个负责库存合并之后如果后续要拆分布式代价反而更大。这种模块耦合问题建议少让 AI 出“结构性方案”。AI 可以做信息整理和候选枚举最终的设计决策必须由人来把控。如果项目里已经有循环依赖最直接的方式是先引入接口、打破直接依赖而不是把两个类合并在一起把一个环变成一个大泥球。4.6 性能敏感区被“优化”坏AI 很喜欢把循环改成 Stream把 if-else 改成 switch 表达式把显式循环改成递归。但在老项目的性能敏感路径上这种做法可能带来灾难性后果。简单提一个小例子有一个对账逻辑需要遍历几十万条数据原代码用传统 for 循环加 break 条件提前结束。AI“优化”后改成了 Stream不仅代码可读性没有本质提升还因为拆箱装箱产生大量临时对象内存占用直接翻倍。对于已经跑得很紧张的服务这就是线上事故。我现在给 AI 划了条红线性能核心路径上的代码尤其是涉及大数据量、高并发、锁、批量写入的场景不允许 AI 随意改写。如果一定要用 AI也只能让它做“解释”和“局部变量改名”这类不影响语义的微小整理真正改动要保留在人工手里。5. 把 AI 重构纳入团队日常落地流程与红线5.1 从一个小模块试点不要搞“全库重构日”团队最怕的是一拍大腿宣布“本周我们用 AI 把系统重构一遍”。这话听着热血实际上风险巨大因为老系统没有足够测试大规模改动必然失控。我建议的落地方式是从一个小而独立的模块开始比如一个工具类、一个不常变动的 Service或者一个没有太多外部依赖的上游组件。先让这个模块跑通“AI 识别问题 - 人在 diff 里修改 - 测试验证 - 小组 review”的完整流程记录耗时和效果再逐步扩大范围。试点目标一定要具体。比如“把这个类里超过 100 行的方法拆掉 3 个”“把所有重复的公共逻辑抽出一个统一入口”“给核心方法补上单测”。不要用“优化代码质量”这种无法验收的说法。有了明确的验收标准团队才知道这次实验成功还是失败。5.2 AI 重构评审清单每个改动都要有人签字我建议团队内部执行一套简单的“AI 重构评审清单”每条改动都过一遍负责人签字确认。下面是我目前认为比较实用的检查项检查项通过标准编译通过本地或 CI 完整编译无错误测试通过相关单元测试、集成测试全部通过行为差异说明能列出本次改动涉及的所有行为变化点副作用检查确认没有新增或丢失对外部状态的读写风格规范通过团队的 Lint 和格式检查人工 review至少一位资深成员确认改动合理这些条目本身并不复杂但能有效防止“AI 生成代码CI 全绿上线后出问题”这种事故。关键是每个检查进度的反馈都必须真实没有人为跳过。我们在刚开始执行时因为“行为差异说明”一栏写不清直接卡住了两三个改动后来发现都是 AI 引入了不易察觉的边界变化提前暴露了问题。5.3 哪些场景坚决不让 AI 碰我会把下面这些场景列为红线原则上不推荐让 AI 直接重构资金计算、权限校验、加密解密、并发锁、数据迁移、与外部系统的协议对接。理由很简单这些场景的共同点是“错误代价极高且正确性很难快速验证”。AI 可以帮你生成测试用例也可以帮你梳理调用关系但生成的新逻辑方案必须经过严格的、可审计的验证。资金少算一分、权限放开一个口子、并发出现一个死循环都不是靠“Regenerate”能挽回的。当然不是说这些代码永远不能重构。我的做法是先让 AI 只做“文本级别的分析”比如“列出这段加密逻辑依赖了哪些类”“这段并发控制用到了哪些锁”把信息梳理好然后由资深工程师基于梳理结果手工设计重构方案。也就是说AI 在这些场景里只是一个提词器不是执刀者。5.4 长期维持整洁把 AI 变成日常习惯而不是大扫除项目整洁不是一次重构的终点而是持续演化的过程。与其每年搞一次大扫除不如把 AI 整理代码变成日常开发的一部分。我目前的做法是在每天的开发工作里固定留出一小段时间用 AI 处理“看得见的小问题”某个方法太长了就让 AI 给拆分建议某个类重复代码多就让 AI 扫描相似块某段逻辑看不懂就让 AI 先用通俗语言解释一遍。每次改动不大但一个月下来整个模块的可读性会有明显提升。配合 CI 里的复杂度检查会更稳妥。比如在 Java 项目里用 Checkstyle 限制方法行数和圈复杂度在 TypeScript 项目里用 ESLint 复杂度规则一旦超过阈值就给出提示。AI 可以在这些检查结果的基础上给出具体修改方案。日拱一卒和“重构日”的突击式处理相比效果差距非常大。还有个容易被忽略的点团队的代码评审习惯同样需要更新。成员提交的 diff 里如果出现“AI 重构后的代码”评审人不能只看最终结果还要要求提交者写清楚改动背景和验证方式。这套流程跑顺之后即使团队换了人新成员也能通过 commit 记录和 AI 辅助理解老代码不至于每次都在屎山里重新摸爬滚打。我个人在实际操作中的体会是AI 代码整洁器真正改变的不是“让代码自动变干净”而是把识别问题、分析结构这些最耗时的部分压缩掉了。以前接手老项目光想搞清每个方法是谁在调用就要翻大半天。现在 AI 可以把候选方案摆到桌面上你仍然需要对每一行删改负责但整个流程的起点和速度都不一样了。先把项目变得越来越可改、可测、可交付比“让 AI 直接给我一个干净的仓库”要靠谱得多。