Weapp-vite: 对小程序工程化的重新思考

这几年大家聊小程序工程化，常见写法是“能力罗列”：支持 Vue、支持分包、支持热更新、支持某某插件。

但做过中大型项目的人都知道，真正让团队每天付出成本的，往往不是“有没有这个功能”，而是“这些能力能不能被组织成一套稳定流程”。

weapp-vite 想解决的，正是后者。

第一件事：AI 协作必须进入工程上下文

AI 写代码已经不稀奇。稀缺的是让 AI 在你项目里“可控地工作”。

weapp-vite 在文档里把这件事拆成了三层：Skills 提供稳定流程，MCP 暴露仓库能力，llms.txt 统一上下文入口。它不是让 AI 猜项目，而是给 AI 接口。

从源码看，这套能力也不是“贴在文档里的建议”：mcp 默认可用，weapp-vite mcp 可以直接启动服务，支持 stdio 和 streamable-http。这意味着 AI 可以真正进入你的日常研发链路，不再只当外部聊天工具。

第二件事：原子化样式不是审美问题，是维护问题

当页面规模起来以后，样式维护会迅速变成团队负担。原子化样式真正的价值不是“class 很酷”，而是把样式治理从“文件复制粘贴”变成“规则复用”。

weapp-vite 在这块很克制：不重新造样式 DSL，而是把 weapp-tailwindcss 纳入默认工作流。

• 脚手架创建项目时会自动补齐 weapp-tailwindcss 依赖版本。
• 开发态下可自动 touch app.wxss 触发开发者工具热重载。
• 配置层面提供 weapp.hmr.touchAppWxss，并支持 auto 模式。

这类细节很小，但它决定了原子化样式在日常开发里到底是顺手还是反复“手动刷新”。

第三件事：分包不是开关，而是策略

很多工具都“支持分包”，但工程上要回答的是另一个问题：共享代码到底落主包还是落分包。

weapp-vite 的默认策略是 duplicate，把跨分包共享 chunk 复制到各分包，优先分包首开体验；你也可以切到 hoist，把共享代码提炼进主包，优先控制总体体积。

它的价值不在“多两个配置项”，而在于把取舍变成显式策略：你可以按业务阶段选择“更快首开”或“更小总包”，而不是接受一个黑箱结果。

第四件事：热更新速度，核心是稳定快

rolldown-vite 带来了一次明显提速，这点在升级文档里已有量化数据。

但更重要的是后续实现：weapp-vite 的 HMR 在 auto 策略下会判断共享 chunk 导入关系，能局部更新就局部更新，只有在可能造成共享导出不一致时才回退全量发射。

这让“快”从偶发幸运变成可预期体验。对团队来说，这比一次跑分更有意义。

第五件事：语法重写必须和运行时一起做

weapp-vite + wevu 的重点从来不是“可以写 .vue”，而是“写法升级后，运行模型依然贴合小程序”。

编译侧会把 v-if、v-for、v-model、<script setup> JSON 宏等能力做结构化转换；运行时则坚持 diff + setData 的路径，把优化重点放在 payload 体积和更新频率上。

这也是它没有把 createRenderer 当主路线的原因。小程序的核心语义不是 DOM 节点操作，而是数据快照下发。抽象不对齐，就会平白增加一层成本。

最后

如果要用一句话概括这篇文章，我更愿意这样说：

weapp-vite 做的不是“多支持几种语法”，而是把小程序工程化里最痛的几件事，重新接成一条可验证、可协作、可持续演进的链路。

这条链路里，AI、样式、分包、热更新和语法重写，不再是五个孤立功能，而是一套能一起工作的系统。