我为什么要把组件库从 Vue 迁到 uni-app x
先说为什么有手上这摊活？我在维护 uView Pro，一个 90 多个组件的跨端组件库，本来跑在 uni-app Vue3 上，最近我正在把它整体迁到 uni-app x 上。
为什么要迁移？ 是我自找的...，但也是必须要做的
uni-app 的组件库它只认 Vue 那一套语法，而 uni-app x 直接编译成原生，App、小程序、H5 多个平台一套代码都能跑，性能还比原来好。社区一直催生，但这是不得不做的升级，不是锦上添花。
但迁移不是我改个后缀那么简单。一个组件的 TypeScript 要换成 UTS，CSS 要改 UCSS，Vue 要改成 uvue。写法、限制、编译规则全变了，90 多个组件，一个组件要过重构、建示例页、注册路由、添加入口四关，等于把整个库重写一遍，最难的是 API 对齐还要前端能跑。
这是件工程量大、又极度重复的事------恰好是我想交给 AI 干的活。
但是却没有想象的那么简单。关键是 AI 不懂那些 uts，uvue，ucss 的写法，这都是谁来创造的？？就不能用标准的 ts，js，css，vue 语言吗？
我觉得现阶段 AI 写 uni-app x 效果不好的原因是市面上案例太少了，知识库和经验太少了，上下文不足，AI 想检索都找不到相关案例。但是我想问最懂 uni-app x 的 uni-agent，尽然效果也不尽如人意。我让你修复问题时，你老给我删除代码是什么意思？
这对吗？
我一度想要放弃...
如何写对 uni-app x，我的方案也不完善。目前我创建了大量的规则 skill 来限定 AI，告诉它如何书写 uts、ucss、uvue 语法，尽量不飘，最大限度的保证一次写对，真不会写就问我，严禁自我发挥...
本篇文章先不讲 AI 如何写 uni-app x，先来说说这件事...
我原来想的是：发布需求，剩下交给 AI
量这么大，我一开始的思路是搭一套 AI 工作流，把"发布需求"做成最后一步。
流程是这么定的:我发一个组件的迁移需求，它先问我几句把细节敲定，然后自己重写代码，写完了自己验证，验证不过自己整改，整改中还自己截图给我看，最后把每次修复的原因和结果存成一份记录，方便我后来翻。
我想要的就两条：自动化 ------我不必逐组件盯着;留痕------每步都记得住，改错了能查回当时为什么这么改。听起来很理想，对不对？
但是...理想很丰满，现实很骨感...
它确实负责，但快不起来
新鲜劲没撑过一周，问题来了，不是它不肯干，是它干得太慢。
问题全埋在它的"自我验证"那一环。你看它每改一次是怎么做的：先重新起一趟服务，打开页面截图，自己盯着看，不对再改，再来一遍。而且它每轮都是无状态的，跑了这轮忘了上轮，服务每次重开、截图每次重存、记录每次重记，中间全是空转。
打个比方，90 个组件里随便挑一个，它都能给你把完整的重写+验证跑下来，可光是"验证---整改"这个来回，就能耗它大半天。有一次它为了把一行文本在五个端表现调一致，自己来回试了七轮，每轮重启服务、生成新截图、追加一段记录，最后才对上。截图存了一二十张，记录写了一大篇。
更要命的是，这不是偶尔一次，而是常态。一套流程慢，90 个组件就乘 90 倍。照这速度，单靠它这个"自动化"，我怕是得等一年。
最可怕的是：Trae Work 的积分损耗也是加倍的，如下图所示，几十倍的增长，一会不看，差点回到解放前了：
我这才明白：我要的不是"自动但让人干等 "，是"自动，还得赶紧完事"，最重要的是还要省 Token。
所以，还是让 Tare Work 来分析一下：
我为什么会去改它
换个说法------我通过这个慢得出的结论是：流程能在多快，比的不是你模型多聪明，是你那套自我验证有多顺。
它慢，不是它笨，是三处设计得重：
- 服务每次重新起，它没有"还用上次那个"的意识;
- 判断靠"截图 + 人眼"，每改一想都得停下来看;
- 记录和截图每次都重做，为留痕牺牲了速度。
这三样，都是能改的。我为什么决定改？因为如果不改，别说 90 个组件迁不完，就算硬迁完，这套"自动化"也发挥不出它该有的价值------一个让人干等的流程，省的是手，耗的是心，本身就是个伪自动化。
我怎么改的：把最磨的一环接上快车道
我盯的就是它最磨的那一环------验证。
（1）复用状态，别让它每次从零开始。 服务跑起来就常驻着，告诉它改完直接连上现成的，别回回重启。最重的启动环节，一下没了。
（2）把"人眼看"换成"脚本判"。 省略号标没标上、组件接口齐不齐、图标和文字是不是同一行------这些都不是玄学，是能写死的样式属性和坐标标准。我给它配了个小脚本，改完跑一遍，直接打出"成没成、哪一项不对"，不用截图也不用猜。
（3）让"判断"和"留痕"绑一起，而不是互相拖累。 脚本跑完一行行打出结果，这份输出本身就是记录，随跑随存，比它手写的一大篇干净，查起来也快。自动化、留痕、速度，三样我都要。
改完它的自我验证，从"起服务 + 截图 + 人眼看"压成"一条命令跑到底"，一轮大约从四分钟缩到十几秒。
改完的效果
最直接的数字：一轮验证从约 240 秒降到约 19 秒，十多倍的提升。我连跑两次，一次 18.7 秒，一次 18.6 秒，很稳。
放回迁移工程里看------90 个组件，每个都要过"验证---整改"这么一关。以前一个组件在这关上能磨一下午，现在一个要不了几分钟。原来我预计整库迁完少说要个把月，现在这个数字我敢往下压一半还多。
更有意思的变化在心态上。以前我就给它派那种"稳妥的小需求"，怕它卡住；现在它验证快，我敢给它扔更复杂、更大胆的活，它也敢多想几种方案再动手。速度是会传染的。
我又实测了两次新脚本：18.7s → 18.6s ，稳定。旧链路按之前分析取中值约 240s，提速约 9--16 倍。
对今天那类任务的放大效果（circle-progress canvas 反复排查）
- 优化前：7 轮 × ~240s ≈ 28 分钟纯验证 + 反复试错
- 优化后：同样 7 轮 × ~19s ≈ 2.2 分钟，且断言能快速定位"哪一项不对"，试错轮次本身也会减少
能直接抄走的几条
这套东西，换到任何"AI 替你干活、又快不起来"的场景都管用：
-
能复用的状态，别让它每次从零开始。 "服务还开着"这事，告诉它直接连，砍掉最贵的重启。
-
能量化的就别靠人眼看。 够没够、对不对、齐不齐，写成可判断的标准让脚本判，别靠截图互相猜。
-
判断和留痕绑成一条命令。 别为了留痕牺牲速度。脚本跑完的结果本身就是记录，又准又好查。
-
慢的时候先找"哪一环慢"。 它慢往往不是它笨，是某一环太重。揪住那一环，比催它跑快点管十回。
结尾
我原来是冲着"自动 + 留痕"去的，等真跑起来才明白，省心的前提是够快。
这次我只让 Trae Work 改了它最磨的一环，成效就已经立竿见影------90 个组件的迁移工程，终于看得到头了，发布日期指日可待了。验证这一环快了，我还打算把别的环节也一件件往这条道上靠。
哪天全接上，这套工作流才算真配得上"全自动"三个字，那也才是我当初想让它帮我把这趟工程跑完的本意。