像这种问题千万别自己动手，否则你可太看不起 AI 了

大家好，我是前端梦工厂，一个在前端 + uni-app 生态里摸爬滚打多年的开发者。

目前主要在做一个 uni-app 开源组件库的开发和升级：

uView Pro 提供了 80+ 高质量组件、多主题切换、暗黑模式、多语言国际化，算是 uni-app 社区里比较活跃的组件库项目

我业余时间就是维护组件、修 bug、写文档，偶尔用 AI 工具帮自己提效，我今天分享的就是前两天用 TRAE Work 解决的一个真实问题。

一个被忽略的坑

uView Pro 开源组件库覆盖表单、导航、反馈等常用场景，使用的人有不少，但有个问题一直被用户提问：目前并不支持单组件导入。

什么意思呢？正常用 uView Pro，你得在 pages.json 里配 easycom 自动导入：

json 复制代码

"easycom": {
    "autoscan": true,
    "custom": {
        "^u-(.*)": "@/uni_modules/uview-pro/components/u-$1/u-$1.vue"
    }
}

配完之后，模板里写 <u-icon>、<u-button> 就能直接用，不用 import，不用注册。听起来挺方便的。

但问题是，有些项目不想用 easycom。比如你只想用 u-modal 这一个组件，按理说直接 import UModal from 'uview-pro/components/u-modal/u-modal.vue' 就行了对吧？

不行。

因为 u-modal 内部用了 u-popup 和 u-loading，但它的代码里压根没有 import 这两个组件。整个组件库 99 个文件，没有一个写了显式导入声明，全部依赖 easycom 帮忙。

你把 u-modal 单独拎出来用，一跑可能就会报问题------u-popup 没注册，u-loading 没注册。

这个坑其实从一开始就存在，但因为大多数人都在用 easycom，一直没暴露，直到有用户想在引用单个组件，但这根本行不通。

49 个组件，82 条导入声明

要修这个问题，逻辑很简单：哪个组件在模板里用了别的组件，就在 <script setup> 里加上对应的 import。

比如 u-alert-tips 用了 u-icon，就加一行：

typescript 复制代码

import uIcon from '../u-icon/u-icon.vue';

听着不难，但实际操作起来，99 个组件要逐个排查模板，找出内部引用了哪些其他组件，再生成对应的 import 语句。

我粗略估了一下，手动干这事大概要花大半天------打开文件、看模板、找到用了哪些组件、写 import、检查拼写、确认路径，一个组件至少 3-5 分钟，49 个组件就是 3-4 个小时。而且这种重复劳动特别容易出错，漏一个、多一个、拼错一个变量名都是常有的事。

所以，业务简单是 AI 编码的优势，如果这种要自己动手就属于看不起 AI 了... 基本不需要二次对话，就能一次修改成功。

让 TRAE Work 来干

我打开 TRAE Work，输入了需求：

排查 uView-Pro/src/uni_modules/uview-pro/components 下所有组件，组件内部如果使用了其他组件，需要导入声明。

我并没有让 TRAE Work 直接动手改代码，而是先进入 Plan 模式。它做了几件事：

扫描组件目录 ，列出 99 个组件，逐个读取 .vue 文件内容。

检测依赖关系 ，用正则匹配每个组件模板里的 <u-xxx 标签，找出 49 个组件存在内部依赖。还把完整的依赖映射列了出来------u-modal 依赖 u-loading 和 u-popup，u-city-select 依赖 5 个组件，u-popup 自己也依赖 u-icon 和 u-mask。

发现边界情况 ，比如 u-steps 模板里有 <u-icon> 和 <u-line>，但它们被包在 HTML 注释里（被注释掉的旧代码），不应该算。u-calendar 和 u-upload 有嵌套的 <template> 标签，用非贪婪正则提取会导致内容截断，得换提取方式。

制定方案，写一个 Node.js 脚本自动完成，支持 dry-run 预览，支持幂等执行。

方案写成了一个 plan 文件，我看了一遍，依赖映射没问题，边界情况也都考虑到了，确认通过。

然后 TRAE Work 开始执行：

先以 --dry-run 模式跑了一遍，输出 49 个组件的依赖关系和将要插入的 import 语句，我确认无误
正式执行，49 个文件全部修改完成，共插入 82 条 import 语句
再跑一遍验证幂等性------第二次执行显示"已修改 0，已存在 49"，没有重复添加
最后跑 npm run type-check，零新增类型错误（已有的 17 个报错全在 demo 页面，跟这次改动无关）

整个过程，从扫描到验证完成，几分钟。

几个值得说的细节

正则的前瞻断言 。u-step 和 u-steps 这两个组件名是前缀关系，直接匹配 <u-step 会把 u-steps 也匹配上。脚本用了 (?=[\s/>]) 前瞻断言，确保匹配到的是完整标签名后面跟着空格、> 或 /，才不会误匹配。

模板提取方式 。一开始用 <template>([\s\S]*?)</template> 提取，结果 u-upload 里有十几个嵌套的 <template v-if>，非贪婪匹配在第一个 </template> 就截断了，导致丢失大量依赖。后来改成"取 <script 之前的所有内容"，问题解决。

注释里的组件不算 。u-steps 把旧的渲染逻辑注释掉了，里面包含 <u-icon> 和 <u-line>。脚本先移除 HTML 注释再做匹配，所以这两个不会被误加 import。u-select 同理，注释里有个 <u-icon> 也被正确排除了。

import 插入位置 。每个组件的 <script setup> 里已有一些 import（vue 的、项目内部的），新加的组件 import 放在现有 import 块的末尾，保持代码风格一致。

手动 vs 自动

这件事如果手动做，我大概率要花一个下午。49 个组件逐个打开、读模板、找依赖、写 import、检查有没有遗漏。干完还得自己跑一遍验证，万一哪个写错了又得回头查。

TRAE Work 几分钟搞定，而且比人靠谱------它不会拼错变量名，不会漏掉嵌套 template 里的组件，不会把注释里的标签也算进去。脚本还支持重复执行，以后新增组件再跑一遍就行。

让我比较感慨的一点是：TRAE Work 不是"帮我写段代码"这种粒度的工具。你给它一个明确的工程任务，它会自己分析现状、发现边界情况、制定方案、执行验证。你要做的是审阅方案、确认方向，而不是逐行盯着它写代码。

那个 plan 文件是我觉得最有价值的部分------在动手之前把要改什么、怎么改、有哪些坑都想清楚了，可能比闷头就改要靠谱得多。这个工作流对任何批量重构任务都适用：先扫描、再分析、出方案、确认后执行。

像这种类似问题真的不再需要人工，如果你都自己干了，AI 还干什么？并且 Trae Work 处理的比你要好太多。

放过自己，交给 AI。