摘要：老系统用新语言重构，是企业数字化过程中绕不开的难题——系统运行数十年不能停机，掌握老技术栈的人员逐年流失，而标准 AI 工具只能提供单点能力，难以拼凑出一套完整的迁移方案。本文以一个真实的军工企业案例，说明这类重构为何必须依赖定制化的 Agent，以及 aiXcoder 如何针对这家企业的存量系统、业务规范与迁移约束，定制出一个能够读懂老代码、守住不停机底线、把产出做到可上生产程度的迁移智能体，最终将一套运行十余年的 JSP 老系统，平稳迁移到 Vue3 前后端分离架构。

---

再讲一个实际的落地案例，也顺便回答一个被问得最多的问题：老系统用新语言重构，AI 到底靠不靠谱？

结论先放这儿：能扛，但有前提。下面是前阵子我们单位刚做完的一件真事——把一套跑了十几年的 JSP 老系统，迁到 Vue3 前后端分离架构。整个过程没停机、没出乱子。

---

一、老系统重构，难在哪

我们这套系统，是当年 JSP 最火的时候建的，Spring Boot 加 JSP，跑了十几年。业务一天都不能停，但问题已经压不住了：前后端耦合、页面和程序代码混在一起，改一点牵一发动全身；更要命的是，会这套老技术的人一个个退休、转岗，新人没人愿意碰，维护成本一年比一年高。

迁到 Vue3 是明确的方向，但对军工单位来说，这件事比一般企业难得多，难在三个地方：

第一，老代码没几个人真懂了。 十几年的 JSP 系统，业务逻辑和前端逻辑混在一起，接口没有标准化约束，很多"为什么这么写"的理由，随着老同事的离开已经没人说得清。要把这套东西迁走，第一步不是写新代码，是先把老代码读懂。

第二，迁移必须做到不停机、不中断。 我们的业务没有"停机窗口"这一说。新旧系统得并行跑，任何对原有业务代码的误改，都可能引发线上故障。这对"迁移"这件事的容错率，几乎是零。

第三，数据不能出内网，是硬约束。 系统跑在物理隔离的内网里，军工单位的涉密数据不能出网、不能上云。整个迁移过程，包括用的工具，都得在本地闭环里完成，没有捷径可走。

这三点，决定了这次迁移容不得半点闪失。

---

二、为什么标准 AI 编程工具用不了，必须定制

标准 AI 编程工具的功能已经相当齐全——代码补全、智能问答、单文件重构、单元测试生成，看似应有尽有。但当面对"把一套运行十余年的 JSP 老系统整体迁移到 Vue3"这类大任务时，这些单点能力就显得力不从心。

原因很简单：标品的功能是散的，而迁移是一个系统工程。

老系统迁移不是"改几行代码"，而是一连串必须连贯的动作——先读懂整个系统的业务和架构，把任务拆开，按节奏逐模块开发，边开发边验证，最后新旧系统并行切换。每一步都连着上一步，漏一步、乱一步，整个迁移就可能卡住。

标准工具提供的是一个个单点能力：可以补全一段代码、解答一个技术问题、重构一个文件，但它并不掌握迁移的整体推进路径，也无法将"理解 → 拆解 → 开发 → 验证 → 切换"这一整套动作串联起来、持续推进。将这类碎片化功能简单拼凑，并不能构成一个能够系统化完成迁移的方案。

这就是必须定制的原因：不是标准产品不好，而是它的能力是散装的，解决不了"系统化完成一个大问题"这件事。 我们要的，是一个能针对我们这套系统，从头到尾把迁移完整跑下来的智能体。

所以这次，我们是和 aiXcoder 团队一起，针对我们这套老系统、我们的业务规范和迁移约束，定制了一个专门的迁移智能体。

---

三、这个定制智能体，具体干了什么

这个 aiXcoder 为我们定制的迁移智能体，不是拿个通用模型套用，而是把我们的代码资产、接口范式、编码规范、安全红线都灌了进去。落到这次迁移，它干了这么几件事：

读懂老代码。 它先主动分析项目结构，梳理业务分层、数据交互逻辑、分页规则和认证机制，把十几年的老系统摸清楚。这一步看着不起眼，但恰恰是迁移里最耗人、也最容易出错的地方。

按我们的规范干活。 它不按"通用最佳实践"来，而是按我们单位的编码规范、接口约定来生成代码。前后端分离要建的接口规范、响应格式、前端工程，都是按我们的要求搭的，不是它自己的一套。

双端并存、底层共享。 这是"不停机"的关键。它没有重写原有业务逻辑，而是复用已有的业务服务和数据访问逻辑，只在上面新增一层 REST API，给 Vue3 前端提供独立的数据服务。老系统继续跑，新前端逐步接，业务一点没断。

边开发边自己验证。 每做完一部分，它就自己编译、测试、验证。自测时它发现用户管理模块的分页处理有个类型转换问题，自己定位、自己修掉了——这种问题放在人工流程里，通常要等联调甚至上线才暴露。

双端并存验证。 最后它把原系统前端、Vue 新前端、后端接口三条链路分别做了校验，确认新旧系统并行期间，登录、认证、数据都能正常通。

---

四、结果：这活以前要好几个人干几周

老系统迁移，传统模式通常是前端、后端、架构师好几个人协作，历时数周甚至数月。

这次用定制智能体跑下来，最大的变化不是"快"，是省心：代码理解、任务拆解、自动化验证这些重活，都被它接过去了，我们的研发人员把精力放在了架构决策和业务确认上。沟通成本和工程风险，都实打实降下来了。

---

结尾

回到开头那个问题：老系统用新语言重构，AI 到底靠不靠谱？

我们这次的经验是：能靠谱，但要分情况。 如果企业有明确的老系统迁移需求、有清晰的业务规范，同时能找到具备定制能力的团队，那么通过定制化，AI 是可以系统化地完成这类迁移的——读懂老代码、守住不停机的线、把产出做到能上生产的程度。反过来，如果只是拿通用工具直接套用，期望它自行理解业务、自行串起整个流程，结果就未必可控。

这也是"领域化"落地的又一次验证：通用 AI 会写 Vue3，但只有懂你这套 JSP 老系统、懂你业务和安全的智能体，才敢动它。

如果你也在头疼类似的老系统重构，欢迎一起交流。