• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Paxton886
V2EX  ›  程序员

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

  •  
  •   Paxton886 · 18h 47m ago · 3206 views

    目前有一些运行多年的 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 老项目的经验。

    33 replies    2026-08-25 22:48:56 +08:00
    dingwen07
        1
    dingwen07  
       18h 40m ago
    感觉关键在于这个项目有没有充足的测试用例,复杂还没有足够的测试那 AI 顶多能做到重构完之后跑起来

    有一说一,让 AI 直接整个重写和去重构哪个更好呢
    lmmlwen
        2
    lmmlwen  
       18h 37m ago
    无非是先做项目分析,我的流程和你说的其实大差不差,之不过我的`扫描项目 → 分析架构和依赖 → 找 Code Smell`直接使用 Understand-Anything 这东西
    Paxton886
        3
    Paxton886  
    OP
       18h 30m ago
    @dingwen07 确实,我觉得测试覆盖才是 AI 重构的基础。没有足够的测试,AI 能保证的更多是编译通过、服务能启动,但很难证明业务行为没变,尤其是历史项目里很多规则其实只存在于代码和线上数据里。至于重写还是重构,我觉得得看项目和其他模块耦合程度
    sentinelK
        4
    sentinelK  
       18h 16m ago   ❤️ 1
    我认为在业务功能完全不变的前提下,利用 AI 重构项目价值不大。

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

    基于此,TDD 我认为是重制老项目的关键。也就是说需要先定义业务的最终边界,只有完整定义了业务边界,AI 才能实现合理的技术选型和反复迭代。
    foryou2023
        5
    foryou2023  
       18h 14m ago
    非必要,不重构,如果只是满足自己的内心重构,完全没有必要,浪费时间和精力,重构带来了业务风险,没有冒着风险干重构,仅仅把代码搞的好看漂亮。
    showmeyourmoney
        6
    showmeyourmoney  
       17h 35m ago
    直接重写
    lel020
        7
    lel020  
       17h 35m ago
    我是让 AI 写个大 skill 让另一个 AI 用 skill 提炼项目`知识`再给另一个 AI 重写,
    skill 毙了好几版一直没成果, 但还是想走这个方向,核心是希望写代码的 AI 不用看原项目代码,
    apkapb
        8
    apkapb  
       17h 24m ago
    我自己的项目,反正是重写的,也很快。

    主要是之前也尝试过重构,后端可能好点。前端,特别样式组件完全重构很难,直接完全从 0 开始写(叫 AI 参考旧版),2 天就完成 85-90%,后面就是一些细节,叫 ai 慢慢改就行
    Betsy
        9
    Betsy  
       17h 15m ago via iPhone   ❤️ 1
    非必要,不重构。重构代码没任何收益,改出问题了还得背锅。相当不划算
    zuokanyunqishi
        10
    zuokanyunqishi  
       17h 8m ago
    恰好重构了自己项目好几个核心模块.以下是 codex 自己总结的.

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

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

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

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

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

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

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

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

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

    最重要的是这三条:

    > 事实先于抽象。
    > 测试证明行为,但不能替代架构判断。
    > 重构要按风险和可观察结果切片。
    lujiaosama
        11
    lujiaosama  
       15h 40m ago
    老项目就别想着重构了。最靠谱的方案就是 A/B 项目同时启用,蚂蚁搬家,服务级别进行隔离。
    ntgeralt
        12
    ntgeralt  
       15h 15m ago
    重构需要花费巨量额度
    当然 github 优秀的老项目都看到陆续被 Opus5 Python/ rust 重构
    拿着你的 max claude 账号,和 Opus5 说 审查整个项目 剩下的他就会帮你了
    kamilic
        13
    kamilic  
       15h 8m ago
    让 ai 按照《重构》来重构
    cz5424
        14
    cz5424  
       14h 59m ago
    我还在 vue2 ,用 ai 升级 vue3 我都不敢搞
    jackOff
        15
    jackOff  
       14h 49m ago   ❤️ 1
    不重构老项目
    Lemonyi
        16
    Lemonyi  
       14h 44m ago
    看多老的项目了,像政府和国企事业单位十几年老项目,就不用考虑重构这种问题了
    zigaai
        17
    zigaai  
       14h 27m ago
    跑得好好的重构来干嘛,有这时间摸会鱼不好?
    bahuite
        18
    bahuite  
       14h 4m ago
    重构还不如新开发
    lucays
        19
    lucays  
       14h 2m ago
    我认为 Java 的项目的那些公司,几乎不会提出重构的需求吧
    8355
        20
    8355  
       13h 44m ago
    90%的重构实际风险绝对大于项目收益.
    真有收益的不是重构而不是起一个新项目把老项目的局部高收益迁出,老的逐步降配,边缘化直到下线.
    crocoBaby
        21
    crocoBaby  
       13h 39m ago
    @cz5424 我也不敢,安装 uniapp 老出错
    JoJoWuBeHumble
        22
    JoJoWuBeHumble  
       13h 15m ago
    其实你这个 skill 模式看起来是重构,其实应该是重写。
    像我们项目里面原本有很多设计不合理的地方,没有考虑到未来应用变化和复杂度,很多地方都是修修补补。
    现在有 AI ,让 AI 充分过一遍项目,生成一个完整重写的方案,自己和 AI 都提不合理的地方,然后整个进行重写。
    当然,这只是适合小一点项目
    andie
        23
    andie  
       12h 55m ago
    /improve-codebase-architecture
    AddIce
        24
    AddIce  
       12h 47m ago
    非必要,不重构。尤其是公司的项目。
    ionfev
        25
    ionfev  
       12h 9m ago
    旧项目一般不值得重构,除非要复用,直接在新项目上对照旧项目迁移重构,AI 很适合,解决技术债,现在有了 AI 可以做了。
    yyfjj
        26
    yyfjj  
       11h 56m ago
    @sentinelK 兄台所言极是
    hehebo
        27
    hehebo  
       10h 58m ago
    @apkapb 85%-90%那是代码量。实际,你的细节工作量,是 90%以上。
    sxguka
        28
    sxguka  
       10h 30m ago via Android
    感觉这个问题都是 AI 写的
    ylsc633
        29
    ylsc633  
       9h 22m ago
    确实如楼上说的,非必要不重构

    但是我今年就重构了

    一个非常老的项目,java 的,本地都起不来,里面一堆 if else ,项目已经交接 N 手了
    我去年就想重构了,因为实在不想写这个 java ,一个接口,我点了十层,还没看到逻辑代码

    说我怎么重构的
    1. 梳理业务,必须知道要重构的系统涉及的业务,包括上下游、同步的、异步的,都得知道,否则给自己挖大坑
    2. 重新设计架构,包括 领域、实体关系等等,老系统架构是不是不能满足当前的业务了,是不是不好扩展了,你得结合未来系统支持的业务发展,一并考虑,你的系统设计
    3. 考虑新老系统怎么转换,数据怎么迁移,对使用方( B 端、C 端、M 端)怎么尽量无感
    4. 定好新系统大概的框架,然后从某个方向开始让 AI 阅读老项目,再出设计方案,没问题就开始写

    我就是这么搞的
    sir283
        30
    sir283  
       8h 11m ago
    重构之前先备份,不然血泪不止。不过老项目除非推到重来,不然没事不要去动,继续堆屎山就完事了。
    Thorc
        31
    Thorc  
       7h 46m ago
    @cz5424 没问题的,vue3 刚出的时候我都是手动重构的,涉及到写法/用法变更的还是蛮少的,AI 读一遍文档自己就会改写了,项目结构也不用动
    shakoon
        32
    shakoon  
       7h 33m ago
    如果没有新需求要进行大的变动,真没必要重构。我这儿还有好多 VB6 写的小程序,用得挺顺手的,毫无升级动力
    yidinghe
        33
    yidinghe  
    PRO
       6h 32m ago
    人是核心,下面几点只有人知道,AI 不知道:
    1. 重构的原因,问题来自哪些用户,哪些业务部门,这些都是人去沟通,AI 做不了。
    2. 重构的目标,做到什么程度算是适可而止,算是兼顾成本和效率,其依据很多来自系统之外,AI 做不了。
    3. 有了目标之后,如何阶段性的实施,这个也要考虑各个部门的工作方式,业务场景间的依赖,AI 做不了。

    把上面这些定下来了,你要整理成几十上百页的文档喂给 AI ,让 AI 跟你的想法对齐,而且必须是顶级的 AI ,你才能放手让 AI 做剩下的事。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   947 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 78ms · UTC 21:21 · PVG 05:21 · LAX 14:21 · JFK 17:21
    ♥ Do have faith in what you're doing.