今年上半年，我们团队做了一个比较大的项目：把一个维护了五年的老旧前端系统，迁移到全新的技术栈上。

这个旧系统，用的是jQuery + Bootstrap，代码量很大，有将近200个页面，维护起来非常痛苦。新系统，我们决定用Vue 3 + TypeScript + Element Plus，配合Vite构建。

如果按照传统的方式，纯人工迁移，至少需要三个人做三个月。但这次，我们尝试了"AI化迁移"——用AI编程工具（主要是Cursor和GitHub Copilot）辅助开发，最终只用了一个人一个半月就完成了。

这篇文章，就来分享这次前端AI化迁移的完整实战经历，包括方案设计、AI辅助开发的流程、遇到的问题和解决方案，以及AI在前端迁移中的作用和局限。

项目背景

先说说这个旧系统的情况。

这是一个企业内部的管理后台，2019年开始开发，用的是jQuery + Bootstrap + 后端模板渲染的方式。五年下来，功能越堆越多，代码越来越乱。

主要问题有：

  • 技术栈老旧，jQuery操作DOM的方式和现代前端开发理念脱节
  • 没有组件化，大量重复代码，一个功能改了，要在好几个地方同步修改
  • 没有类型检查，JavaScript的动态类型导致很多运行时错误
  • 构建工具老旧，用的是Gulp，构建速度慢，不支持热更新
  • 新人上手困难，代码结构混乱，没有文档，全靠口口相传

团队早就想重构了，但一直因为工期紧、人手不够而搁置。今年年初，公司终于批了重构的预算和时间，我们决定趁这个机会，彻底迁移到新技术栈。

但问题是，团队只有三个前端，其中两个还要维护旧系统和做新需求，只能抽出一个人来做迁移。一个人，200个页面，三个月的工期，听起来几乎是不可能完成的任务。

这时候，我们想到了AI。2024年，AI编程工具已经比较成熟了，Cursor、GitHub Copilot这些工具，在代码生成、代码转换、代码解释方面都有不错的表现。我们决定，用AI来辅助迁移，看看能不能把不可能变成可能。

迁移方案设计

动手之前，我们先做了详细的方案设计。

第一步，是梳理旧系统的结构。我们花了一周的时间，把旧系统的200个页面做了分类：

  • 表单类页面：大约80个，主要是数据录入和编辑
  • 列表类页面：大约60个，主要是数据展示和查询
  • 详情类页面：大约40个，主要是数据详情展示
  • 复杂交互页面：大约20个，有比较复杂的前端逻辑

分类之后，我们发现，大部分页面都是比较标准化的表单和列表，这些页面的结构比较固定，很适合用AI来批量迁移。只有20个左右的复杂交互页面，需要人工重点处理。

第二步，是搭建新系统的基础框架。我们用Vite + Vue 3 + TypeScript + Element Plus搭建了基础项目，配置了路由、状态管理、请求封装、权限控制等基础功能。这部分是人工写的，因为基础框架的质量直接影响后续所有页面的开发。

第三步，是制定迁移规范。我们写了一份详细的迁移规范，包括：

  • 目录结构规范：页面、组件、工具函数、接口定义放在哪里
  • 代码风格规范：命名、注释、格式
  • 组件使用规范：用哪些Element Plus组件，怎么封装公共组件
  • 接口调用规范：怎么定义接口类型，怎么调用接口
  • 状态管理规范：哪些状态用Pinia，哪些用组件内部状态

这份规范，既是给人看的，也是给AI看的。我们把规范作为上下文，喂给AI工具，让AI按照规范生成代码。

第四步，是确定迁移策略。我们采用的是"增量迁移"的策略，而不是"大爆炸"式的一次性迁移。具体来说：

  • 先迁移公共组件和工具函数
  • 再迁移简单的表单和列表页面
  • 然后迁移复杂的交互页面
  • 最后做整体联调和优化

每个页面迁移完成后，立即进行测试，确保功能正常。这样，即使迁移过程中出了问题，影响范围也有限。

AI辅助开发的流程

方案确定之后，就开始了正式的迁移工作。我们用的AI工具主要是Cursor，辅助用GitHub Copilot。

AI辅助迁移的流程，大致是这样的：

第一步，给AI提供上下文。在Cursor中，我们把旧系统的代码、新系统的规范、相关的组件文档，都作为上下文提供给AI。具体做法是：

  • 把旧页面的完整代码复制到对话中
  • 把迁移规范的关键部分也放进去
  • 告诉AI这个页面对应的新系统中的路由和接口
  • 明确告诉AI输出的要求：Vue 3 + TypeScript + Element Plus，使用Composition API，使用<script setup>语法

第二步，让AI生成初步代码。AI会根据上下文，生成新页面的Vue代码。通常，一个页面的代码，AI能在几秒钟内生成出来。这比人工写快了几十倍。

第三步，人工审查和修改。AI生成的代码，通常能达到70%-80%的正确率，但还不能直接用。需要人工审查，修改以下问题：

  • 接口调用的参数和返回值，需要和后端确认
  • 复杂的业务逻辑，AI经常理解错，需要人工修正
  • 样式和布局，AI生成的通常比较粗糙，需要调整
  • 类型定义，AI有时候会用any，需要补充具体类型
  • 边界情况和错误处理，AI经常遗漏，需要补充

第四步，测试和调试。把修改后的代码跑起来，测试功能是否正常。发现bug，再让AI帮忙定位和修复。

第五步，代码审查和提交。完成一个页面后，做一次代码审查，确保代码质量符合规范，然后提交到代码仓库。

这个流程，看起来和传统开发差不多，但因为有了AI的辅助，效率提升了很多。传统方式下，一个简单的列表页面，人工写可能需要半天；用AI辅助，从生成到修改到测试，大约两个小时就能完成。

不同类型页面的迁移效果

不同类型的页面，AI迁移的效果差异很大。

表单类页面，AI的表现最好。因为表单页面的结构比较固定：几个输入框，一个提交按钮，加上表单验证。AI能很准确地把旧的jQuery表单转换成Vue 3的表单，包括数据绑定、验证规则、提交逻辑。80个表单页面，大部分只需要少量修改就能用。

列表类页面，AI的表现也不错。列表页面通常是一个查询表单加一个表格，AI能正确地生成查询逻辑、表格渲染、分页功能。但有些复杂的表格，比如合并单元格、自定义列、行内编辑，AI生成的代码经常有问题，需要人工修改。

详情类页面，AI的表现一般。详情页面主要是数据展示，结构不复杂，但有时候会有一些特殊的展示逻辑，比如根据状态显示不同的内容、根据权限显示不同的按钮。这些逻辑，AI经常理解错，需要人工仔细检查。

复杂交互页面，AI的表现最差。比如有拖拽排序、多级联动、实时计算、文件上传等复杂功能的页面，AI生成的代码经常有逻辑错误，有时候甚至需要重写。20个复杂页面，我们花了将近一半的时间来处理。

总的来说，页面越简单、越标准化，AI迁移的效果越好；页面越复杂、越有特殊逻辑，AI迁移的效果越差。这也符合我们的预期：AI擅长处理模式化的工作，不擅长处理需要深度理解业务逻辑的工作。

遇到的问题和解决方案

在迁移过程中，我们遇到了不少问题，这里分享几个典型的。

第一个问题，AI生成的代码风格不统一。虽然我们给了规范，但AI有时候还是会按照自己的"习惯"来写代码，比如用Options API而不是Composition API，或者用不同的命名方式。

解决方案：我们在项目中配置了ESLint和Prettier，强制统一代码风格。AI生成的代码，先跑一遍lint和format，大部分风格问题就能自动修复。剩下的问题，人工修改。

第二个问题，AI生成的类型定义不准确。TypeScript的类型定义，AI经常会写错，比如把string写成number，或者漏掉可选属性。这会导致编译错误，或者运行时错误。

解决方案：我们先把后端的接口定义整理成TypeScript的类型文件，作为上下文提供给AI。这样，AI在生成代码的时候，就能引用正确的类型，减少类型错误。同时，我们开启了TypeScript的严格模式，编译时就能发现类型错误。

第三个问题，AI"幻觉"出不存在的API。有时候，AI会调用一些Element Plus组件不存在的属性或方法，或者调用一些不存在的工具函数。这会导致运行时错误，而且错误信息有时候不太明显。

解决方案：我们把Element Plus的官方文档作为上下文提供给AI，减少AI"幻觉"的概率。同时，在代码审查的时候，特别注意检查组件的属性和方法是否正确。对于不确定的，查官方文档确认。

第四个问题，旧系统的业务逻辑不清晰。旧系统的代码，很多地方没有注释，业务逻辑全靠猜。AI在迁移的时候，经常会误解业务逻辑，生成的代码功能不对。

解决方案：对于业务逻辑复杂的页面，我们先花时间理解旧代码的逻辑，把逻辑用自然语言描述清楚，再让AI根据描述生成代码。而不是直接把旧代码扔给AI，让它自己理解。这样，准确率会高很多。

第五个问题，AI的上下文窗口有限。旧系统的有些页面代码很长，加上规范和文档，超出了AI的上下文窗口。这时候，AI只能看到部分代码，生成的代码就不完整。

解决方案：对于长页面，我们把它拆分成多个组件，逐个迁移。先迁移主页面的框架，再逐个迁移子组件。这样，每次给AI的代码都不会太长，AI能完整理解。

AI在前端迁移中的作用

经过这次实战，我们对AI在前端迁移中的作用，有了比较清晰的认识。

AI的作用，主要体现在几个方面：

第一，代码转换。把一种技术栈的代码转换成另一种技术栈，这是AI最擅长的。jQuery转Vue，JavaScript转TypeScript，旧组件转新组件，这些转换工作，AI做得又快又好。

第二，样板代码生成。表单、列表、详情这些标准化的页面，有大量的样板代码。AI能快速生成这些样板代码，开发者只需要关注业务逻辑部分。

第三，代码解释。旧系统的代码，很多地方写得很晦涩，新人看不懂。AI能解释代码的功能和逻辑，帮助开发者快速理解旧代码。

第四，测试用例生成。AI能根据页面的功能，生成测试用例，帮助我们更全面地测试迁移后的页面。

第五，文档生成。迁移完成后，AI能根据代码生成文档，包括组件文档、接口文档、使用说明等。

但AI也有明显的局限：

第一，业务逻辑理解不足。AI能理解代码的语法，但不一定能理解代码背后的业务逻辑。对于复杂的业务逻辑，AI经常会理解错。

第二，上下文有限。AI的上下文窗口是有限的，对于大型项目，AI无法看到全部代码，只能看到部分。这会导致AI生成的代码和项目的其他部分不一致。

第三，创造力不足。AI擅长模仿和转换，但不擅长创新。对于需要创造性解决方案的问题，AI的表现不如人类。

第四，需要人工监督。AI生成的代码，不能直接用，必须经过人工审查和修改。如果完全信任AI，不做审查，一定会出问题。

所以，我们的结论是：AI是一个强大的辅助工具，但不能完全替代人类开发者。在前端迁移中，AI能把效率提升2-3倍，但最终的质量，还是取决于人的审查和把控。

迁移后的效果

经过一个半月的努力，我们终于完成了全部200个页面的迁移。

迁移后的效果：

  • 页面加载速度提升了约40%，因为新系统用了Vite构建，代码分割和懒加载更高效
  • 开发效率提升了约50%，因为新系统有组件化和类型检查，改bug和加新功能都更快了
  • 运行时错误减少了约70%，因为TypeScript的类型检查在编译时就能发现很多错误
  • 新人上手时间从两周缩短到三天，因为新系统的代码结构清晰，有文档

更重要的是，团队的开发体验好了很多。以前改一个功能，要在jQuery的代码里翻半天，还要担心会不会影响其他地方。现在，组件化的代码，改一个组件只需要关注这个组件本身，不用担心副作用。

这次迁移，也让我们对AI编程有了更深的理解。AI不是要取代程序员，而是要把程序员从重复的、机械的工作中解放出来，让程序员能更专注于业务逻辑和架构设计这些更有价值的工作。

一些经验和建议

基于这次实战，给想做类似迁移的团队一些建议。

第一，先做方案，再动手。不要一上来就开始用AI生成代码。先梳理旧系统的结构，制定迁移规范，确定迁移策略，然后再开始。好的方案，是成功的一半。

第二，基础框架要人工写。项目的基础框架，包括构建配置、路由、状态管理、请求封装、公共组件，这些一定要人工写，确保质量。AI可以用来写业务页面，但基础框架不能交给AI。

第三，规范要详细。给AI的规范越详细，AI生成的代码质量越高。不要只说"用Vue 3写"，要说清楚用Composition API、用<script setup>、用哪个UI库、怎么命名、怎么组织代码。

第四，从小处开始。不要一开始就迁移最复杂的页面。先从简单的页面开始，熟悉AI的使用方式，积累经验，然后再处理复杂的页面。

第五，人工审查不能少。AI生成的代码，一定要人工审查。不要因为AI生成得快，就跳过审查环节。代码质量，最终还是要靠人来保证。

第六，测试要充分。迁移后的页面，一定要充分测试，特别是业务逻辑复杂的页面。AI迁移可能会引入一些隐蔽的bug，只有充分测试才能发现。

写在最后

这次前端AI化迁移，是一次很有意义的尝试。

它让我们看到了AI在软件开发中的巨大潜力。一个人一个半月，完成了原本需要三个人三个月的工作，这在以前是不可想象的。

但它也让我们看到了AI的局限。AI不是万能的，它不能替代人的思考和判断。在可预见的未来，AI更可能是程序员的"超级助手"，而不是程序员的"替代品"。

AI时代的程序员，需要学会和AI协作。把重复的、机械的工作交给AI，把创造性的、需要深度理解的工作留给自己。只有这样，才能在AI时代保持竞争力。

希望这次实战的经验，能给大家一些参考。如果你也在做类似的迁移，或者在用AI辅助开发，欢迎交流分享。