1. 项目起点：form-generator升级背后的真实动机
先交代一下背景。form-generator这个项目，熟悉低代码或者表单开发的朋友应该不陌生，它是一款基于Vue2的开源表单设计器，核心能力是拖拽式生成表单、维护JSON配置、一键生成代码。很多团队拿它做后台管理系统的表单引擎，也有人在里面二次开发，接自己的业务组件。我这次要做的，是把这套老项目整体升级到Vue3，而且整个升级过程不是纯手工改造，是全程在Trae这款AI IDE里，配合Skills机制来完成的。
先说为什么要升级。一是我这边的技术栈已经整体迁移到Vue3 + Vite + TypeScript，老的form-generator还停在Vue2 + Webpack，维护成本越来越高。二是团队新人在Vue3环境下改老代码，心智负担很大，与其继续打补丁，不如一次性把底子换掉。三是form-generator本身的设计其实非常依赖Vue2的某些特性，比如$children遍历、$listeners透传、slot作用域传参、mixins复用逻辑，这些在Vue3里要么被移除，要么行为完全不同，升级难度并不低，不是改改依赖版本号就能跑起来的。
这次升级我给自己定了一条规矩：所有代码改动尽量通过Trae的对话和Skills流程来完成，人工只负责审查、纠错和决策。也就是说，我要把“升级老项目”这个活，变成一套“AI协作流程”，让模型替我读代码、改代码、排查报错，我做把关人。整体做下来，周期大概一周，对比我之前纯手改一个类似的Vue2项目，效率提升还是相当明显的。这篇文章就把整个过程拆开讲一遍，包括改了什么、为什么这么改、Trae和Skills在里面到底起了多大作用，以及那些文档里不会写明白的坑。
适合来看这篇内容的人，我猜大概是三类：一类是自己手里有Vue2老项目要升Vue3，想找个参考路线；一类是想把AI IDE真正用进日常项目里，但不满足于让它写点零散函数的人；还有一类是玩过Trae但还没搞明白Skills怎么落地、怎么和真实项目结合的人。我会尽量把操作细节写得具体，你照着走能少走不少弯路。
2. 升级前的准备：拆解老代码和规划迁移路径
2.1 先盘点form-generator到底依赖了哪些Vue2特性
在让Trae动手之前，我先自己把仓库完整翻了一遍，搞清楚这个项目的技术债集中在哪里。form-generator的代码结构大体分三块：表单设计器主体、渲染器、组件库。设计器主体里最核心的是拖拽面板和JSON Schema的编辑逻辑，渲染器负责把保存的JSON配置实时渲染成表单页面，组件库则是一系列内置表单项，比如输入框、下拉选择、日期选择、上传、子表单等。
依赖的Vue2特性我列了个清单：
$children：设计器里多处用来直接拿子组件实例，比如拖拽后刷新组件列表。$listeners和$attrs：组件库里的包装组件大量使用，把事件和属性透传给原生组件。.sync修饰符：弹窗显隐、表单值同步都有用到，Vue3里合并到了v-model。- 全局事件总线：组件之间通信用的是
Vue.prototype.$bus = new Vue()这种经典写法。 - mixins：公共逻辑抽成了好几个mixins，比如表单校验逻辑、下拉数据加载逻辑。
slot-scope：设计器渲染组件配置项时用了大量作用域插槽。- 过滤器
filter：一些展示格式化用了全局过滤器。 Vue.extend和动态注册组件：动态渲染表单组件时依赖了这类API。
我不建议一上来就新建一个Vue3项目然后把代码拷进去，那样报错会铺天盖地，根本无从下手。比较合理的做法是，先逐项确认项目里用了哪些API，再对照Vue3的断崖式变更清单，把它们分成三类：可直接替换的、需要改写的、需要重新设计的。
2.2 迁移方案选型：为什么选渐进式迁移而不是推倒重来
方案上我考虑过两条路。第一条是推倒重来，用Vue3 + TypeScript完整重写一遍form-generator，保留核心交互和JSON Schema规范，代码全部新写。第二条是渐进式迁移，也就是先让老项目在Vue2.7上跑通，把mixins、$children、$listeners等过时写法清理干净，再整体切到Vue3。
选渐进式是因为form-generator的业务逻辑很重，尤其是拖拽排序、JSON Schema联动、组件配置面板这三个模块，有大量边界逻辑和兼容处理，推倒重来意味着这些暗坑要重新踩一遍，而且无法用Git对比保证功能完全一致。渐进式迁移可以分模块逐步推进，每个模块迁移完都能用现有测试数据去验证，回归成本小得多。
Trae在这里面扮演的角色很有意思，它不是简单帮我改代码，而是可以理解整条迁移路线。我在项目根目录建了一份迁移说明文档，把上面说的依赖清单、迁移顺序、每个阶段的验收标准全部写了进去。Trae的Skills机制可以关联这份文档，让AI在每次改代码前先理解全局约束，而不是孤立地处理单个文件。这一点后面单独讲，先继续说我怎么用Trae做代码诊断。
2.3 用Trae先跑一遍全仓库扫描，拿到“问题地图”
我在Trae里建了一个会话，任务很简单：扫描整个form-generator仓库，统计所有Vue2弃用API的使用位置和数量。得益于Trae能读取整个项目目录的上下文，它不像传统搜索那样只做关键词匹配，而是会结合代码语义去判断，比如$children出现在什么场景下、被用来做什么、能不能安全替换。
第一轮扫描结果出来，比我自己预估的还要多。除了常见的$children、$listeners、.sync之外，还有一堆隐蔽问题，比如某些组件依赖了Vue.prototype.$set做响应式新增属性，这在Vue3里完全不需要了，但写法和思维惯性还在；再比如全局过滤器在模板里的调用，升级后必须改成函数调用或者computed。
这轮扫描帮我把迁移范围精确到了文件级。我让Trae输出了一份Markdown格式的“问题地图”，每个文件对应列出：问题类型、影响范围、建议改法、优先级。这份文档后来成了整个升级过程的施工图，也让后面所有Skills的针对性更强。我强烈建议你迁移前先做这一步，不管用Trae还是手动检索，先把债理清楚再动手，效率差距非常大。
3. 核心细节拆解：Vue2到Vue3的关键升级点
3.1 响应式体系的迁移：$set、$delete和Vue.observable的替代
form-generator里有一段很典型的老代码，往对象上动态添加字段时用的this.$set(this.someObject, key, value)。这段逻辑在Vue2里是必须的，因为Vue2的响应式是基于Object.defineProperty，新增属性不会被拦截，必须用$set手动触发更新。Vue3换成了Proxy，对象本身是响应式的，新增删除属性天然就能被捕获，所以这些$set理论上可以直接去掉，直接赋值就行。
但实操里有个容易踩的坑：有些逻辑是在组件内部往一个已经被赋值过的数组里塞对象，对象内部的字段是后面才动态加的。升级的时候要确认这个对象是处在reactive还是ref容器里。如果你是reactive，则直接加字段没问题；但如果你习惯性把对象塞进了ref里再赋值，那就要格外小心，ref包裹的数据你要通过.value访问，整个引用被替换时是响应式的，但内部已有对象如果没有用reactive转一层，依然会有失去响应式的风险。
Trae在迁移这块最大的价值在于，它能自动识别出那些“其实可以简化”的老代码。比如某个watch里还在配合$set做深拷贝、再赋值的老套路，模型会告诉我这在Vue3里可以直接用结构替换加赋值，代码量少一半。你要做的就是逐处审查这个建议是否符合业务逻辑，而不是依赖模型一键替换。响应式这个问题，属于“看起来很简单，实际上水很深”的类型，建议升级时专门留出时间，一段一段审查每个对象和数组的使用场景。
3.2 组件通信重构：事件总线、$listeners和$attrs的处理
form-generator设计器里，组件之间的通信用了事件总线，大概是this.$bus.$emit('some-event', payload)这种。Vue3移除了实例上的$on、$off、$once方法，官方推荐的替代方案是推荐改用mitt这个微型事件总线库，或者干脆改用provide/inject和props。
实际迁移时我选了mitt，因为form-generator里的总线事件至少有二十多种，全部改成provide/inject工程量大，而且事件总线的松耦合特性在这个场景里其实是合理的。用mitt改造成本极低，把原来main.js里的Vue.prototype.$bus = new Vue()改成import mitt from 'mitt'加一个全局单例，再把所有调用处的API换掉即可。注意，emit和on的参数顺序、解绑方式几乎和原版一致，所以这块的迁移基本是机械工作，很适合丢给Trae处理。
然后是$listeners。Vue2里父组件给子组件绑定的事件监听器，可以通过$listeners拿到再透传给孙组件；Vue3里$listeners被移除了，事件监听器会和其他属性一起被并入$attrs，并且框架层会自动把onXxx开头的attrs当作事件传给子组件根节点。所以迁移form-generator里的包装组件时，最省事的方式是：在组件上声明inheritAttrs: false，然后统一用v-bind="$attrs"往下传，丢弃原来手写的v-on="$listeners"。
这块我在Trae里明确配置了一条规则：“遇到$listeners全部改写成v-bind="$attrs"，遇到.sync修饰符改写成对应update:propName事件”。Trae执行得很快，但审查时我发现一个边界情况：有的组件主动消费了$attrs里的部分class，又往下传递，命名有可能会重。遇到这种就手动调整一下，把消费掉的属性显式声明为prop，避免透传时被覆盖。
3.3 组件声明与注册方式：Vue.extend、动态组件的替代
form-generator的动态表单渲染器，核心逻辑是用Vue.extend把一个组件定义转成构造器，再配合一个渲染函数动态实例化。这种写法在Vue3里完全行不通了，因为Vue3组件定义是普通的JavaScript对象，不再有“类”和构造器的概念。
迁移这部分时，我把原来的Vue.extend创建方式，改成了用一个组件注册表加resolveComponent的方式：提前把所有内置组件在应用实例上注册，或者用defineAsyncComponent做按需加载，然后在渲染器里通过组件的字符串名称动态解析。这样既保留了form-generator“通过JSON里的componentName映射到真实组件”的机制，又完全走Vue3官方推荐的组件解析链路。
这里有一个值得注意的细节：Vue3的渲染函数虽然可以直接通过h(resolveComponent('SomeComponent'))来动态渲染，但如果你在<script setup>里使用，模板内部的组件解析范围会限定在当前文件，动态字符串组件无法被自动解析到。必须用resolveComponent显式获取，或者把组件列表全局注册。我在form-generator升级时是做了一个统一入口，把所有表单组件、布局组件、自定义组件集中到一个registerComponents.ts文件里全局注册，渲染器只依赖这个全局注册表，这样才保证了动态渲染的可靠性。
3.4 mixins到composables的演进：逻辑复用方式重写
form-generator里有一批mixins，比如表单校验逻辑、级联加载逻辑、远程选项数据逻辑。Vue3虽然还保留mixins，但官方推荐用Composition API组合逻辑。迁移时我做了这样一个判断：短期能跑的，mixins继续留着也能运行；但长期维护和团队认知统一，最好还是改写成composables。
我在Trae里给了一个比较具体的重构方向：把原来mixins里的data、computed、methods拆成对应的ref、computed和普通函数，统一放进useXxx.ts文件，返回一个可解构的对象。比如原来一个remote-options-mixin，负责从远端加载下拉选项、处理加载态和错误态，重构成useRemoteOptions之后，输入参数变成接口地址和请求参数，返回值变成options、loading、error、loadOptions方法。
这个改写过程其实非常适合AI来完成，因为逻辑是平移，不涉及重新设计。Trae读取了原始mixin后，生成的composable基本可以直接用，我只做了少量修正，比如变量命名风格统一、类型定义补全。但我要提醒一点，composables和mixins在数据共享上有个本质区别：mixin里你可以直接通过this.xxx访问组件其他数据，而composable的“共享”是通过入参传进去的，设计时要显式定义好入参和返回值，否则很容易写出隐式依赖，前期省事，后期维护爆炸。
3.5 路由和全局API的调整：Vue.prototype、全局过滤器的清理
form-generator项目里除了核心设计器，还有展示端和示例页面，这块用到了路由。Vue3的路由从vue-router@3升到vue-router@4，API变化不算大，主要是new Router()变成了createRouter()，模式设置、路由表写法基本兼容。我在升级时把路由配置表单独抽出来，做成了routes.ts，方便Trae和团队审查。
更琐碎的是全局API的清理。form-generator原来的main.js里有大量Vue.prototype.xxx = xxx的挂载，比如全局的请求实例、工具函数、事件总线、常量配置。Vue3里对应的做法是用app.config.globalProperties.xxx = xxx。但这里我走了另一条路：除了少数必须挂在实例上的，比如$http、$message，其他工具函数一律改成ES Module按需导入。这是因为globalProperties上的东西在TypeScript里类型扩展很麻烦，为了体验更顺手，尽量少挂全局。
还有全局过滤器。form-generator里做了几个展示用的过滤器，比如时间格式化、金额千分位。Vue3移除filter选项后，我在升级时统一把它们改成了工具函数，模板里的写法从{{ value | formatTime }}改成了{{ formatTime(value) }}，相应地在组件里import { formatTime } from '@/utils/format'。如果你项目里有大量全局过滤器，可以考虑通过app.config.globalProperties挂载成方法，或者用computed在组件内预处理，但无论哪种，模板语法都要改，这点没有捷径。
3.6 插槽和作用域插槽：slot-scope到v-slot的收尾
form-generator的组件配置面板里，大量使用了作用域插槽来渲染自定义配置项，老写法基本是<template slot="xxx" slot-scope="{ row }">。Vue3统一改成<template v-slot:xxx="{ row }">，缩写是#xxx="{ row }"。这块的迁移虽然机械，但涉及文件多、嵌套深，容易出错。
我的建议是分两步：先让Trae做全局替换，把slot="xxx"和slot-scope语法统一转成v-slot；再人工审查那些插槽名是动态拼接的场景。form-generator里就有这种写法：插槽名是根据组件类型动态生成的，比如slot="config-${componentType}"。v-slot不支持动态插槽名直接用字符串拼接，必须用中括号语法：#[config-${componentType}]。这些细节如果依赖全局替换，很容易被漏掉，审查的时候要重点翻一翻。
4. 结合Trae和Skills的实操过程：把AI协作真正落地
4.1 Trae里的Skills到底是什么，怎么配置才不白配
Trae的Skills，简单理解就是给AI定义“角色、知识、工作流”的一套机制。它类似Claude的Skills概念，通过在项目目录里放.skills或skills文件夹，里面用Markdown格式的SKILL.md描述一个技能的定义、规则、步骤，AI会在对话时自动感知并加载这些技能。对于form-generator升级这种特定项目，Skills可以把“这个项目的历史背景、技术约束、迁移规范”固化下来，每次让AI干活前，它都能按这套规范来执行。
第一次用Skills的人容易犯的错，是把SKILL.md写得像一本大而全的百科全书，什么都说，结果AI什么都没记住。真实有效的Skills应该是“一份能直接指导行为的操作手册”，要明确命令、约束、输出格式。我建了一个叫vue3-migration的Skill，内容大致包括：
- 角色设定：告诉AI它是一名Vue3迁移专家，熟悉form-generator的代码结构。
- 背景信息：简要说明这个项目是做什么的、升级范围在哪里、不能动哪些逻辑。
- 规范约束：明确禁止使用哪些Vue2 API，遇到时应当如何改写。
- 工作流步骤：要求AI在处理任务时先读指定文档，再逐文件改动，每次改动后输出变更说明。
- 输出格式：要求AI用中文回复，代码展示带文件路径，复杂改动分步说明，不要一次性输出过长的未经解释的代码块。
配置好之后，我在Trae对话里的体验变化非常明显。没有Skills时，每次都要反复解释项目背景、约束条件，AI还是容易给出泛泛的方案，甚至会改到一半把不相关的逻辑动掉。有了Skills，AI相当于被“约束”在了这个项目的语境里，回答质量和代码改动准确率提升了一个层级。
4.2 一个典型任务的完整流程：从“迁移某个mixin”到合入代码
我用一个具体的例子说明整个流程是怎么转的。任务是升级upload-mixin.js，这个mixin原本负责表单上传组件的数据处理和上传状态管理。
我打开Trae的对话窗口，新建子会话，在输入框里直接描述任务：“把src/mixins/upload-mixin.js迁移成Vue3的composable，输出到src/composables/useUpload.js，注意保持对外API不变，upload方法参数和回调逻辑不能改。”
因为已经加载了vue3-migration这个Skill，Trae会自动理解它面对的是一个Vue3迁移任务，会按照Skill里定义的步骤执行。它先读了这个mixin的完整代码，然后给出迁移方案说明，再写出新的useUpload.ts。整个过程中我可以随时打断追问，比如我问“原来的success回调在composable里怎么传递更合理”，AI会基于代码上下文给出方案。
关键的一步是：AI改完代码后，我不会直接信任。我会让AI自己输出“这个改动涉及到哪些调用方、影响哪些组件”，然后我再全局搜索原来的mixin引用，确认没有遗漏。确认OK后，才让AI执行替换文件、清理旧引用的操作。
这里还说一个实操心得：在Trae里，不要一个会话干太多事。我一般一个子会话只处理“一个模块或一个主题”，比如“迁移所有mixin”就太宽泛了，AI容易漏；细分到“迁移upload-mixin”这种粒度，AI的专注度更高，审查也更容易。一次任务结束，我会要求AI总结变更摘要，形成一条待测试清单，方便后面统一回归。
4.3 让Trae执行全局替换和批量修改的边界在哪里
Trae在这种合并类项目里最强的其实是批量修改能力。比如全仓库的.sync改v-model:xxx、全局过滤器的调用替换、$listeners的改写，这些工作如果手工做，量大且容易漏，AI帮你改就高效得多。但边界也明显：批量修改容易出现误伤，尤其是同名属性在不同文件里有不同含义时，AI可能沿用统一策略导致问题。
我的经验是，全局替换类任务分两轮。第一轮让AI只做“找到全部”的工作，输出所有需要改动的位置清单和匹配摘要，不去改动。人工审一眼清单，确认没有特殊情况，或者告诉AI哪些位置排除。第二轮再让AI根据确认过的清单执行替换。这样虽然多花了一点时间，但能最大程度避免AI过度自信地改坏代码。form-generator升级中，我大概做了十几次这种批量操作，只有一次因为某个组件里正好用了同名的自定义事件，出现了小范围误改，其他基本一次到位。
另外，每次AI批量改完，我都会让Trae自动跑一遍项目的静态检查（比如vue-tsc、eslint）和关键页面的冒烟测试。Trae内置的终端可以执行命令，AI能根据报错自动修复，这个闭环很重要。没有这个闭环的话，等合入代码再被CI拦下来，定位问题的成本就高很多。
4.4 Skills的迭代：边升级边把新规范固化回去
我这次升级过程中，至少把vue3-migration这个Skill迭代了三版。一开始它只有泛泛的规范，比如“禁止使用Vue2 API”，但发现AI在执行中还经常用一些不太合适的模式，比如把所有响应式数据都用reactive包一层、对简单数据类型也用reactive而不是ref。我就在Skill里加了明确说明：“基础类型状态统一使用ref，复杂嵌套数据才用reactive；对象数组使用reactive或ref时保持一致性即可，但不要混用导致行为不可预期。”
再比如，form-generator里有很多组件是函数式组件，Vue3里函数式组件虽然还存在，但性能优势和写法习惯都变了。AI第一次遇到时会纠结要不要保留。我在Skill里加了规则：“函数式组件如果只是为了透传props和事件，统一改写成普通组件；如果确实需要无状态高性能渲染，用defineComponent里的setup返回渲染函数。” 这就给了AI一个明确的决策依据，不会每次都在那里反复权衡。
Skills不只是给AI用的，它也是团队知识沉淀的载体。升级做完之后，我把这份SKILL.md留在了项目里，新成员进来读一遍，就能理解“这个项目升级过、当前有哪些写法约束、遇到某某类型问题怎么处理”，比单独的文档更贴近实际开发语境。
5. 升级过程中遇到的高频问题与解决方案实录
5.1 常见报错与排查思路速查
我整理了一份升级期间频繁遇到的报错和排查思路，放在这里作为参考：
| 问题现象 | 根因 | 解决方案 |
|---|---|---|
| 组件渲染后子组件数据不同步更新 | Vue3响应式特性变化，$set未移除导致重复触发或数据未深度代理 | 移除$set，直接赋值；检查对象是否被ref或reactive正确包裹 |
事件总线$emit不再触发 | Vue3移除了$on/$off/$once | 统一改用mitt，注意在onUnmounted时解绑监听 |
编译报错：slot-scope已废弃 | Vue3模板语法变更 | 全局替换为v-slot，动态插槽名使用中括号语法 |
| 动态组件无法渲染 | resolveComponent未正确使用或组件未注册 | 建立全局组件注册表，用resolveComponent显式解析 |
渲染函数里h函数报错 | Vue3的h函数需要从vue显式导入 | 检查导入语句，import { h } from 'vue' |
| v-model自定义参数不生效 | Vue3的v-model合并了.sync，但参数名也需要调整 | 统一使用v-model:propName，子组件内使用update:propName |
TypeScript编译报错：Vue.prototype不存在 | Vue3全局API挂载方式变更 | 使用app.config.globalProperties，或改用依赖注入 |
| 项目启动非常慢 | 可能还保留了Webpack相关配置 | 升级到Vite，并检查依赖是否有Vue2版本混入 |
5.2 一个隐蔽的坑：defineComponent和Options API混用时的类型问题
form-generator老代码里都是export default { ... }的对象写法。Vue3里这种对象写法本身还能用，但在TypeScript场景下属性自动提示会丢。所以我让Trae分批把所有组件出口包了一层defineComponent。听起来简单，实际操作时发现一个隐藏问题：如果组件里使用了this.$refs.xxx访问子组件，并且子组件是用defineComponent定义的，TypeScript能正确推导；但如果是老式对象，$refs类型就很弱，容易导致模板里调用方法时报错。
这属于升级过程里“不报错但体验差”的类型。解决方案是在升级核心组件时，顺手把defineComponent的泛型参数补上，用defineComponent<PropsType>()的方式声明props类型，让$refs和模板里的上下文推断更准确。这个过程靠AI也能完成，前提是你在Skill里定义清楚目标。
5.3 边界场景：拖拽排序库的兼容问题
form-generator的拖拽能力依赖一个老的拖拽库（实际项目里用的vuedraggable）。这个库升级Vue3后，必须使用vuedraggable@4版本，API有变化，比如list属性改成了modelValue，拖拽结束事件名从@end变成@update:modelValue或@change。这个坑比较经典，我在升级时专门让AI检查了所有拖拽容器的绑定事件，逐一替换，否则会出现拖拽后列表不更新的问题。
同时要注意，vuedraggable@4的内部实现依赖了sortablejs的版本，如果你项目里对sortablejs有二次封装，要确认没有同时存在多个版本，否则会出现一些奇怪的拖动异常。建议统一锁定sortablejs的版本号，避免依赖解析时出现重复实例。
5.4 排查问题的效率秘诀：把报错上下文完整丢给Trae
升级过程中我遇到一个比较棘手的飞线——表单设计器里的子表单组件，在拖入新行后，该行绑定的校验规则没有实时生效，但刷新后又有。这种“运行时状态异常”最难定位，因为你不知道是响应式问题、事件触发问题，还是渲染时序问题。
我的排查方法是：先把复现步骤、期望行为、实际行为，以及相关组件的代码，一起丢给Trae，要求它“先别改代码，按假设驱动的方式列出所有可能原因，并按概率排序”。Trae会结合代码上下文，整理出几条线索，比如可能和v-for的key值有关、可能和深层响应式对象的监听时机有关、可能和组件内watch的flush时机有关。然后我按它的线索逐个验证，最终定位到问题是子表单组件的watch默认在pre时机触发，导致新增行数据还没更新完就执行了校验，把flush: 'post'加上就解决了。
这个过程中Trae的价值不是替你猜答案，而是提供了一套结构化的排查思路，并且能快速调取相关代码片段。这也验证了“AI辅助编程”在复杂项目里的正确姿势：它适合做知识检索、代码理解、方案枚举、批量改写，而最终决策和逻辑确认还是需要人来完成。
6. 用Trae+Skills升级项目的整体复盘与实用建议
整个form-generator升级Vue3的过程，如果让我用一句话总结：和传统手工迁移相比，最大的变化不是“快”，而是“试错成本变低了”。传统迁移中，遇到不确定的API行为，我可能得写段demo去验证，或者在社区搜半天；而在Trae里，直接让AI基于代码上下文给我讲清楚这个API在新版本里的行为边界，还能立刻改一段示例代码验证效果，这个交互方式对迁移类项目极其友好。
Skills的作用，前期我低估了。最初我以为它只是一个“提示词预设”，但实际用下来，它更像一份项目级别的“军规”，能把隐性知识显性化。尤其是在批量任务里，它保证了AI的行为一致性——无论你开多少个会话，AI对“什么是可以改的、什么是不能动的”都有统一的判断基准。这一点在多人协作或长时间项目里尤其重要。
几个经验建议，写给准备做类似事情的人：
- 迁移前先出问题清单，把全仓库的Vue2特性扫描一遍，让AI帮你生成施工图，别急着改代码。
- Skills不要一次性写大而全，边做边迭代，把踩过的坑实时固化进去。
- 一个会话干一件事，任务粒度要细，AI的完成质量和可审查性都会提升。
- 批量替换不要一步到位，先让AI列清单，确认后再执行。
- 每次改动后让AI自己跑一遍静态检查，形成“改代码-检查-修复”的闭环，不要攒一堆错误到最后才处理。
我在实际开发和项目复盘里还有一个深切的感受：像form-generator这种老项目，代码里有很多“当时为了绕过某个Vue2限制而写出的绕行方案”，在Vue3时代已经不再是问题。升级的真正价值不是把一个项目从旧版搬到新版，而是借这个机会，把那些历史包袱和绕行方案一并清掉。这种清理不是AI能独自完成的，它需要人对业务逻辑的理解，而AI的意义是帮你加快理解速度、降低清理成本。
最后一小段实操补充：如果你也想把Trae的Skills用在类似项目里，建议先从一个很小的规范开始，比如只规定“Vue2到Vue3的API替换对照表”，然后跑几个小任务验证效果，再逐步增加项目背景、代码约束、工作流步骤。不要一上来就追求完美，Skills是长在真实任务上的，越用才越顺手。这次升级结束了，但这套“Trae+Skills改造老项目”的工作方式，我后面大概率会在其他项目里继续用，毕竟尝过甜头之后，再让我回头纯手工改代码，确实有点回不去了。
