夜雨聆风WHY MIGRATE
我为什么要把组件库迁到 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，先来说说这件事。
ORIGINAL PLAN
我原来想的是：发布需求，剩下交给 AI
量这么大，我一开始的思路是搭一套 AI 工作流，把「发布需求」做成最后一步。
流程是这么定的：我发一个组件的迁移需求，它先问我几句把细节敲定，然后自己重写代码，写完了自己验证，验证不过自己整改，整改中还自己截图给我看，最后把每次修复的原因和结果存成一份记录，方便我后来翻。
我想要的就两条：自动化——我不必逐组件盯着；留痕——每步都记得住，改错了能查回当时为什么这么改。听起来很理想，对不对？
但是，理想很丰满，现实很骨感。
TOO SLOW
它确实负责，但快不起来
新鲜劲没撑过一周，问题来了，不是它不肯干，是它干得太慢。
问题全埋在它的「自我验证」那一环。你看它每改一次是怎么做的：先重新起一趟服务，打开页面截图，自己盯着看，不对再改，再来一遍。而且它每轮都是无状态的，跑了这轮忘了上轮，服务每次重开、截图每次重存、记录每次重记，中间全是空转。
打个比方，90 个组件里随便挑一个，它都能给你把完整的重写+验证跑下来，可光是「验证—整改」这个来回，就能耗它大半天。有一次它为了把一行文本在五个端表现调一致，自己来回试了七轮，每轮重启服务、生成新截图、追加一段记录，最后才对上。截图存了一二十张，记录写了一大篇。
更要命的是，这不是偶尔一次，而是常态。一套流程慢，90 个组件就乘 90 倍。照这速度，单靠它这个「自动化」，我怕是得等一年。
最可怕的是：积分的损耗也是加倍的，如下图所示，几十倍的增长，一会不看，差点回到解放前了。
我这才明白：我要的不是「自动但让人干等」，是「自动，还得赶紧完事」，最重要的是还要省 Token。
所以，还是让 AI 再来分析一下。
WHY CHANGE
我为什么会去改它
「流程能跑多快，比的不是你模型多聪明，是你那套自我验证有多顺。」
换个说法——我通过这个慢得出的结论是：流程能在多快，比的不是你模型多聪明，是你那套自我验证有多顺。
它慢，不是它笨，是三处设计得重：
服务每次重新起，它没有「还用上次那个」的意识。
判断靠「截图 + 人眼」，每改一想都得停下来看。
记录和截图每次都重做，为留痕牺牲了速度。
这三样，都是能改的。我为什么决定改？因为如果不改，别说 90 个组件迁不完，就算硬迁完，这套「自动化」也发挥不出它该有的价值——一个让人干等的流程，省的是手，耗的是心，本身就是个伪自动化。
THE FIX
我怎么改的：把最磨的一环接上快车道
我看的就是它最磨的那一环——验证。
服务跑起来就常驻着，告诉它改完直接连上现成的，别回回重启。最重的启动环节，一下没了。
省略号标没标上、组件接口齐不齐、图标和文字是不是同一行——这些都不是玄学，是能写死的样式属性和坐标标准。我给它配了个小脚本，改完跑一遍，直接打出「成没成、哪一项不对」，不用截图也不用猜。
脚本跑完一行行打出结果，这份输出本身就是记录，随跑随存，比它手写的一大篇干净，查起来也快。自动化、留痕、速度，三样我都要。
改完它的自我验证，从「起服务 + 截图 + 人眼看」压成「一条命令跑到底」，一轮大约从四分钟缩到十几秒。
THE RESULT
改完的效果
最直接的数字：一轮验证从约 240 秒降到约 19 秒，十多倍的提升。我连跑两次，一次 18.7 秒，一次 18.6 秒，很稳。
240s→19s
一轮验证耗时
9–16 倍
整体提速
放回迁移工程里看——90 个组件，每个都要过「验证—整改」这么一关。以前一个组件在这关上能磨一下午，现在一个要不了几分钟。原来我预计整库迁完少说要个把月，现在这个数字我敢往下压一半还多。
更有意思的变化在心态上。以前我就给它派那种「稳妥的小需求」，怕它卡住；现在它验证快，我敢给它扔更复杂、更大胆的活，它也敢多想几种方案再动手。速度是会传染的。
我又实测了两次新脚本：18.7s → 18.6s，稳定。旧链路按之前分析取中值约 240s，提速约 9–16 倍。
对今天那类任务的放大效果（circle-progress canvas 反复排查）：
28 分钟
优化前 7 轮×240s
2.2 分钟
优化后同样 7 轮×19s
更少
试错轮次本身也会减少
TAKEAWAYS
能直接抄走的几条
这套东西，换到任何「AI 替你干活、又快不起来」的场景都管用：
能复用的状态，别让它每次从零开始。服务还开着，告诉它直接连，砍掉最贵的重启。
能量化的就别靠人眼看。够没够、对不对、齐不齐，写成可判断的标准让脚本判，别靠截图互相猜。
判断和留痕绑成一条命令。别为了留痕牺牲速度，脚本跑完的结果本身就是记录。
慢的时候先找「哪一环慢」。它慢往往不是它笨，是某一环太重，揪住那一环比催它跑快点管十回。
THE END
结尾
我原来是冲着「自动 + 留痕」去的，等真跑起来才明白，省心的前提是够快。
这次我只让 AI 改了它最磨的一环，成效就已经立竿见影——90 个组件的迁移工程，终于看得到头了，发布日期指日可待了。验证这一环快了，我还打算把别的环节也一件件往这条道上靠。
哪天全接上，这套工作流才算真配得上「全自动」三个字，那也才是我当初想让它帮我把这趟工程跑完的本意。
我是前端梦工厂，热衷于分享 AI 观察与 uni-app 干货。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。