AI 时代，大家现在都是怎么重构老项目的？

[Paxton886]

目前有一些运行多年的 Java / Spring Boot 项目，随着业务不断迭代，逐渐积累了不少典型问题：

• Service 越写越大，一个类几千行
• 历史逻辑很多，不敢轻易删除
• 模块之间耦合越来越严重
• 重复代码比较多
• 一些早期设计已经不太适合现在的业务
• 单测覆盖率不高，导致重构风险比较大
• 很多业务逻辑只有看代码甚至问老开发才能理解

以前做这种项目的重构，基本都是人工：

读代码 → 梳理业务 → 找问题 → 设计新结构 → 小范围修改 → 测试 → 再继续改

现在 Codex 、Claude Code 这类 Coding Agent 已经可以直接理解和修改整个 Repo ，所以比较好奇，大家有没有真正把 AI 用到大型存量项目重构上？

最近看到的一些思路

比如给 Agent 配置专门的 Skill / Rules ，然后让 Agent 按类似下面的流程工作：

扫描项目 → 分析架构和依赖 → 找 Code Smell → 生成重构 Plan → 人工确认 → 分模块修改 → 编译 / 单测 → Diff Review

感觉相比直接跟 AI 说一句：

「帮我重构这个项目」

这种方式可能更可控。

另外也看到有人使用 OpenRewrite + AI Agent，让 AI 负责分析和决策，OpenRewrite 负责 AST 级别的批量重构。

比较想请教大家

1. 现在大家会让 Codex / Claude Code 直接参与老项目重构吗？
2. 有没有比较成熟的 Java / Spring Boot Refactoring Skill 、Prompt 、Rules 或 Workflow 推荐？
3. 对于几十万甚至上百万行的项目，AI 怎么建立足够完整的项目上下文？
4. AI 重构最大的坑是什么？业务逻辑误改、上下文不足，还是测试覆盖率？
5. 有没有团队已经形成「 AI Code Review → Refactoring Plan → 自动修改 → Test → Review 」这样的工程化流程？
6. AI 时代还有没有必要专门投入人力做一次“大重构”，还是更适合让 AI 在日常需求开发过程中持续渐进式重构？

目前我的感觉是：

AI 最大的价值可能不是“帮忙写重构后的代码”，而是把过去成本很高的“理解老代码 + 找问题 + 制定重构方案 + 验证修改”这条链路大幅压缩。

不知道大家实际用下来怎么样，有没有踩过坑或者比较成熟的实践方案？

尤其想听听真正拿 AI 重构过生产环境 Java 老项目的经验。

[dingwen07]

感觉关键在于这个项目有没有充足的测试用例，复杂还没有足够的测试那 AI 顶多能做到重构完之后跑起来

有一说一，让 AI 直接整个重写和去重构哪个更好呢

[lmmlwen]

无非是先做项目分析，我的流程和你说的其实大差不差，之不过我的`扫描项目 → 分析架构和依赖 → 找 Code Smell`直接使用 Understand-Anything 这东西

[Paxton886]

@dingwen07 确实，我觉得测试覆盖才是 AI 重构的基础。没有足够的测试，AI 能保证的更多是编译通过、服务能启动，但很难证明业务行为没变，尤其是历史项目里很多规则其实只存在于代码和线上数据里。至于重写还是重构，我觉得得看项目和其他模块耦合程度

[sentinelK]

我认为在业务功能完全不变的前提下，利用 AI 重构项目价值不大。

更有价值的是“重制”。也就是把老项目基于当时的预算、人力、技术等造成的各种缺陷、技术债、业务妥协彻底梳理透彻，并重新实现。

基于此，TDD 我认为是重制老项目的关键。也就是说需要先定义业务的最终边界，只有完整定义了业务边界，AI 才能实现合理的技术选型和反复迭代。

[foryou2023]

非必要，不重构，如果只是满足自己的内心重构，完全没有必要，浪费时间和精力，重构带来了业务风险，没有冒着风险干重构，仅仅把代码搞的好看漂亮。

[showmeyourmoney]

直接重写

[lel020]

我是让 AI 写个大 skill 让另一个 AI 用 skill 提炼项目`知识`再给另一个 AI 重写，
skill 毙了好几版一直没成果， 但还是想走这个方向，核心是希望写代码的 AI 不用看原项目代码，

[apkapb]

我自己的项目，反正是重写的，也很快。

主要是之前也尝试过重构，后端可能好点。前端，特别样式组件完全重构很难，直接完全从 0 开始写（叫 AI 参考旧版），2 天就完成 85-90%，后面就是一些细节，叫 ai 慢慢改就行

[Betsy]

非必要，不重构。重构代码没任何收益，改出问题了还得背锅。相当不划算

[zuokanyunqishi]

恰好重构了自己项目好几个核心模块.以下是 codex 自己总结的.

把重构当作行为迁移，而不是代码整理。

1. 先限定范围
明确目标、非目标、负责人、影响入口和停止条件，避免改着改着变成全盘重写。

2. 先查事实，再谈抽象
直接看源码、依赖和真实运行结果。分清哪些已经验证，哪些只是推断，哪些还需要决策。

3. 把现状和目标分开
用特征测试记录当前行为，用红测描述目标行为。不要拿设计假设冒充现状。

4. 先做最小纵切
先打通一条完整链路，确认方案能跑通，再向同类路径扩散。

5. 按风险切片
只读、写入、非幂等、异步、并发、跨服务协议分别处理，不按目录批量横扫。

6. 每一步都能独立回退
一个切片只解决一个问题，并且可以独立测试、提交、验收和撤销。

7. 不要迷信单一绿灯
单测、静态检查、契约测试、真实入口验证和 Review 各自证明不同的问题，不能互相替代。

8. 最后一定要收口
删除兼容层和临时豁免，把迁移期的约束升级为严格门禁。否则只是新旧两套系统同时存在。

最重要的是这三条：

> 事实先于抽象。
> 测试证明行为，但不能替代架构判断。
> 重构要按风险和可观察结果切片。

[lujiaosama]

老项目就别想着重构了。最靠谱的方案就是 A/B 项目同时启用，蚂蚁搬家，服务级别进行隔离。

[ntgeralt]

重构需要花费巨量额度
当然 github 优秀的老项目都看到陆续被 Opus5 Python/ rust 重构
拿着你的 max claude 账号，和 Opus5 说 审查整个项目 剩下的他就会帮你了

[kamilic]

让 ai 按照《重构》来重构

[cz5424]

我还在 vue2 ，用 ai 升级 vue3 我都不敢搞

[jackOff]

不重构老项目

[Lemonyi]

看多老的项目了，像政府和国企事业单位十几年老项目，就不用考虑重构这种问题了

[zigaai]

跑得好好的重构来干嘛，有这时间摸会鱼不好？

[bahuite]

重构还不如新开发

[lucays]

我认为 Java 的项目的那些公司，几乎不会提出重构的需求吧

[8355]

90%的重构实际风险绝对大于项目收益.
真有收益的不是重构而不是起一个新项目把老项目的局部高收益迁出,老的逐步降配,边缘化直到下线.

[crocoBaby]

@cz5424 我也不敢,安装 uniapp 老出错

[JoJoWuBeHumble]

其实你这个 skill 模式看起来是重构，其实应该是重写。
像我们项目里面原本有很多设计不合理的地方，没有考虑到未来应用变化和复杂度，很多地方都是修修补补。
现在有 AI ，让 AI 充分过一遍项目，生成一个完整重写的方案，自己和 AI 都提不合理的地方，然后整个进行重写。
当然，这只是适合小一点项目

[andie]

/improve-codebase-architecture

[AddIce]

非必要，不重构。尤其是公司的项目。

[ionfev]

旧项目一般不值得重构，除非要复用，直接在新项目上对照旧项目迁移重构，AI 很适合，解决技术债，现在有了 AI 可以做了。

[yyfjj]

@sentinelK 兄台所言极是

[hehebo]

@apkapb 85%-90%那是代码量。实际，你的细节工作量，是 90%以上。

[sxguka]

感觉这个问题都是 AI 写的