跨项目迁移的AI协作实践：从反复返工到一次成功
你说得对！我来重新整合，把两篇的优点结合起来，同时修正不准确的表述。
跨项目迁移的AI协作实践：从反复返工到一次成功
前言
我一直很好奇一个问题：AI到底能不能帮我在两个不同的项目之间迁移功能？
正好手头有两个技术栈完全不同的前端项目：
- A项目：Vue CLI + Vue 2 + Element UI + Vuex，某个功能模块只有菜单配置，页面没做
- B项目：Vue 3 + Vite + Element Plus + Pinia，同样的功能模块完整可用
于是我用这个场景做了一次实验：看看AI能不能帮我把B项目的功能"搬"到A项目里。
我不懂前端开发，正好可以测试——在不熟悉的领域，AI到底能帮到什么程度？需要我提供多少信息？需要反复调试多少次？要消耗多少Token？
这篇文章记录了我的实验过程和最终结论。
一、背景
项目情况
- A项目（目标项目）：旧技术栈（Vue CLI + Vue 2 + Element UI + Vuex），目标模块完全不可用（只有菜单配置，前端页面都没做）
- B项目（源项目）：新技术栈（Vue 3 + Vite + Element Plus + Pinia），目标模块功能完整可用
- C项目（后端）：同时服务于A、B两个项目
核心诉求
让A项目的目标模块也能正常使用，B项目就不再需要了。
我的困境
我不太会前端开发。这意味着：
- 我不知道代码应该放在哪里
- 我不知道路由怎么配置
- 我不知道接口前缀是什么
- 我无法判断AI给的方案是否可行
- 我只能不断让AI试错，消耗大量Token
二、五次尝试，四次失败
第一次尝试：直接迁移
想法：最简单直接，把B项目的功能模块复制到A项目。
做法：让AI分析AB项目的代码框架，罗列迁移清单。
结果：AI分析后发现两个项目技术栈差别太大——Vue2 vs Vue3、Element UI vs Element Plus、Vuex vs Pinia，基本无法直接复制。放弃。
教训：技术栈不同，不能硬搬。
第二次尝试：升级A项目
想法：既然B项目技术栈更新，不如把A项目升级到Vue3，保持跟B一样，然后直接把B迁移过来。
做法：评估升级A项目的可行性。
结果：升级涉及面太广——Vue CLI升级Vite、Vue2升Vue3、Element UI换Element Plus、Vuex换Pinia，还要考虑大量依赖兼容性。不确定因素太多，风险太大。放弃。
教训：为了一个模块升级整个项目，得不偿失。
第三次尝试：自动代码转换
想法：让AI在迁移代码时，自动将Vue3代码转换成Vue2代码。
做法：使用AI工具直接转换B项目的Vue3组件为Vue2。尝试了Trae、Kiro、Cursor等工具（Cursor额度用超了也没成功）。
结果：迁移后效果很不理想。两边项目风格差异太大，转换后的代码要么页面丢失，要么点击没反应。换了好几个AI工具都不行。
教训：自动代码转换在技术栈差异大的情况下效果很差。
第四次尝试：完整迁移方案
想法：让AI先分析两边项目框架差异，决定迁移哪些模块代码，自己给出完整迁移方案。
做法：让AI制定详细的迁移计划，包括UI组件转换、状态管理转换、公共组件处理、工具函数迁移、路由和权限配置等。
结果：AI给出的方案非常复杂，涉及大量转换工作。虽然都是AI在处理，但中间只要有一个环节出问题，整个系统就容易崩溃。调试成本极高。
教训：方案太复杂，环节太多，任何一个环节出错都可能导致整体失败。
第五次尝试：只参考，不迁移（最终成功）
想法：不迁移B项目的代码，只参考B项目的样式和功能，在A项目中用A项目的技术栈重新写一遍。
做法：我不会前端，只能按照AI给的方案，不断操作和测试。遇到问题就让AI处理，中间换了好几个AI工具，消耗了大量Token，最后总算完成了。
结果：成功了！最终实现了A项目的目标模块，功能完整，代码风格与A项目一致。
成功关键：不是"迁移代码"，而是"参考设计，重新实现"。
三、核心洞察：问题不是AI不够聪明
在反复失败和调试的过程中，我逐渐意识到一个关键问题：
我一直在问错误的问题。
错误的问题 vs 正确的问题
| 我原来问的 | 实际上应该问的 |
|---|---|
| 怎么把B项目迁移到A项目？ | 怎么让A项目拥有B项目的功能？ |
| 怎么转换Vue3代码到Vue2？ | A项目现有的代码是怎么写的？ |
| 怎么处理组件库不兼容？ | 用A项目的组件库怎么实现同样的界面？ |
| 怎么让AI自动完成迁移？ | 我需要给AI提供哪些信息才能一次成功？ |
真正的难点
这个任务真正的难点，不是"技术栈转换"，也不是"代码迁移"，而是：
我是一个不会前端的人，却要让AI帮我在一个不熟悉的项目中实现功能。
这就导致了几个核心问题：
1. 我不知道什么信息是关键的
我不知道文件应该放在哪里、路由应该怎么配置、接口前缀是什么。这些在懂前端的人看来是基础信息，但对我来说完全是盲区。
2. 我无法判断AI的方案是否可行
AI给出一个方案，我看不出哪里可能出问题。只能先让AI做，等出错了再回来调试。
3. AI需要大量猜测
因为我没有提供足够的信息，AI只能自己猜。猜文件放哪里、猜路由怎么配、猜接口前缀是什么。每次猜错，就要返工一轮。
4. 我需要消耗大量Token来"试错"
每次AI猜错，我就要消耗Token让它重新分析和修复。一个错误可能来回好几轮。
核心问题的本质
AI需要猜测的信息太多了。
每次AI需要猜测，就可能猜错，猜错就要返工。而我又不会前端，只能不断让AI调试修复，消耗大量Token。
这不是AI不够聪明，而是我没有给它足够精确的信息。
AI需要猜测的信息清单
| 信息类型 | AI会怎么猜 | 结果 |
|---|---|---|
| 文件放哪里 | 按常规放在src/views/system/user/ | 菜单接口要求的是user目录，页面找不到 |
| 路由路径 | 自己拼一个路径如/system/user | 与菜单接口返回的路径不匹配 |
| 代码风格 | 混用两个项目的写法 | 代码风格不统一 |
| 接口前缀 | 可能用B项目的前缀 | A项目用不同的前缀，接口调不通 |
| UI组件 | 混用两个UI库的组件 | 组件不兼容，页面报错 |
用数据说话
我在Kiro上做了对比测试：
第一次尝试（让AI自己摸索）
- 消耗：15%的Token额度
- 结果：只完成了第一个模块，而且过程中多次返工、调试
- 问题：AI每次都要猜测文件位置、路由配置、接口前缀，猜错一次就返工一轮
第二次尝试（提供完整信息清单）
- 消耗：1%的Token额度
- 结果：顺利完成一个模块，代码一次通过
- 原因：AI不需要猜测任何信息，直接按照清单执行
15倍的差距，就是"消除AI猜测"带来的效率提升。
这也解释了为什么很多人觉得AI"烧Token"——不是AI的问题，是我们没有给它足够的信息。
四、问题的根源
通过这次经历，我发现问题的根源是：
我不知道需要给AI提供什么信息，AI也不会主动问我需要什么。
每次我开始一个任务，我会按照自己的理解给AI一个指令。AI根据这个指令开始工作，遇到信息缺失就自己猜测。猜对了还好，猜错了就开始出错。我看到了错误，再回来纠正。如此反复。
这个过程的核心问题是：AI的猜测和我预期的结果之间，存在一个"信息差"。
这个信息差包括：
- 项目结构信息差：我不知道文件应该放哪里，AI也不知道
- 配置信息差：我不知道路由怎么配，AI也不知道
- 代码风格信息差：我知道A项目有自己的写法，但没告诉AI
- 接口信息差：我知道两个项目的接口前缀不同，但没告诉AI
每次信息差存在，AI就必须猜测。每次猜测，就有概率出错。
五、解决方案：消除信息差
最终的解决方案很简单，但我是通过不断试错才悟出来的：
把所有AI需要猜测的信息，都明确地告诉它。
具体需要提供的信息
经过多次试错，我总结出了跨项目迁移必须提供的核心信息：
| 信息项 | 说明 | 如何获取 |
|---|---|---|
| 文件存放目录 | 根据菜单接口的component字段决定 | 让AI读取菜单接口返回的数据 |
| 路由path | 菜单接口返回的具体路径 | 让AI读取菜单接口返回的数据 |
| 接口前缀（A项目） | A项目的API代理前缀 | 查看A项目的配置文件 |
| 接口前缀（B项目） | B项目的API代理前缀 | 查看B项目的配置文件 |
| 参考风格文件 | A项目中指定一个现有文件作为代码模板 | 选择一个功能类似的页面 |
| 参考功能文件 | B项目中要模仿的具体文件 | 指定B项目的目标模块路径 |
成功的关键
成功的关键不是"让AI先告诉我需要什么"，而是：
我通过不断的试错，终于知道了AI需要什么信息。
然后把这些信息整理成一个清单，在每次迁移前填写好，AI就能一次成功。
换句话说：我用Token买到了"需要提供什么信息"这个知识。
六、最终的方法论
1. 核心原则
把所有AI需要猜测的信息，都明确地告诉它。目录、路径、前缀、参考文件，一个都不能少。
每让AI猜测一次，就可能多一轮返工，多消耗一次Token。
2. 跨项目迁移的信息清单
每次迁移前，填写这个清单：
## 迁移前必须提供的信息 ### 基础信息 - [ ] A项目路径：_________________ - [ ] B项目路径：_________________ - [ ] 要迁移的模块名称：_________ ### 代码风格参考（A项目） - [ ] 参考文件路径（页面结构）：_________________ ### 业务功能参考（B项目） - [ ] 参考文件路径（主页面）：_________________ ### 路由和目录信息 - [ ] 菜单接口component字段值：_________ - [ ] 菜单接口path字段值：_________ - [ ] A项目接口前缀：_________ - [ ] B项目接口前缀：_________ ### 转换规则 - [ ] 接口前缀转换规则：_________ → _________ - [ ] UI组件库转换：_________ → _________3. 各方案对比
| 方案 | 工作量 | 风险 | 结果 |
|---|---|---|---|
| 直接迁移 | 小 | 高 | ❌ 技术栈不兼容 |
| 升级A项目 | 极大 | 极高 | ❌ 不确定因素太多 |
| 自动代码转换 | 中 | 高 | ❌ 转换效果差 |
| 完整迁移方案 | 大 | 中 | ❌ 环节太多易崩溃 |
| 参考重写+信息清单 | 中 | 低 | ✅ 成功 |
4. 成功的提示词模板
## 任务：从B项目迁移[模块名称]到A项目 ### 项目信息 A项目（目标）：[名称] 路径：[路径] 技术栈：[Vue2+Element UI] B项目（源）：[名称] 路径：[路径] 技术栈：[Vue3+Element Plus] ### 关键信息 1. 代码风格参考：A项目 `[具体文件路径]` 2. 功能参考：B项目 `[具体文件路径]` 3. 文件存放目录：`src/views/[component值]/`（component = [值]） 4. 路由path：`[菜单接口返回的path]` 5. 接口前缀：B项目用 `[前缀1]`，A项目用 `[前缀2]` ### 转换规则 - 接口路径：替换前缀，其余不变 - UI组件：B项目的Element Plus → A项目的Element UI - 语法：B项目的Composition API → A项目的Options API ### 执行要求 1. 先读取两个参考文件，输出分析报告 2. 确认无误后，再生成完整代码 3. 代码完全遵循A项目的风格七、写在最后
这次经历让我深刻体会到两件事：
第一件：问题不是AI不够聪明
以前我总觉得AI不够智能，需要反复调教。现在我明白了：问题是我不知道如何与AI协作。
在一个我不熟悉的领域，我不知道什么信息是关键的，也不知道AI需要什么。我只能不断试错，用Token买经验。
第二件：知识是有代价的
最终总结出的这个"信息清单"，看起来很简单。但这是我用4次失败、无数Token、好几个AI工具换来的。
如果我一开始就知道需要提供这些信息，可能一次就能成功。
但问题是，一开始我根本不知道需要提供什么。这个知识本身，就是通过实践获得的。
给后来者的建议
如果你也在做类似的跨项目迁移：
- 不要直接迁移代码，要参考重写
- 提前准备信息清单：目录、路由、接口前缀、参考文件
- 让AI先分析，再实现
- 把这次的经历记下来，下次就知道需要什么了
希望这篇文章能帮你少走弯路，少消耗Token。
附录：快速参考卡
## 跨项目迁移三步走 ### 第一步：准备信息 - [ ] A项目参考文件（代码风格） - [ ] B项目参考文件（业务功能） - [ ] 文件存放目录（component字段） - [ ] 路由path（菜单接口返回） - [ ] 接口前缀（两个项目各是什么） ### 第二步：让AI分析 "请先读取两个参考文件，输出分析报告，不要写代码" ### 第三步：执行迁移 "基于以上分析，按照信息清单实现"