微信小游戏 AI 工程化：包体、沙箱与端侧推理三约束
微信小游戏是检验 AI 落地能力的最佳验证器：30M 与 4M 主包上限、开放数据域单向隔离、Worker 唯一并发、文件系统 200MB 额度，把能不能做从模型问题变成工程问题，端侧窄任务推理、云侧大模型、构建期 AI 辅助是三个真正可落地的位置。
约 42 分钟阅读12,456 字9 次阅读博主
微信小游戏是检验 AI 落地能力的最佳验证器：30M 与 4M 主包上限、开放数据域单向隔离、Worker 唯一并发、文件系统 200MB 额度，把能不能做从模型问题变成工程问题，端侧窄任务推理、云侧大模型、构建期 AI 辅助是三个真正可落地的位置。
把大模型塞进游戏，桌面端有成熟的推理管线，移动端有成熟的 ONNX Runtime 生态，引擎侧也有 Unity ML-Agents、Sentis 这类官方方案。可微信小游戏几乎是被所有 AI 落地叙事默认忽略的那一端：它没有本地文件系统的完全写权限，没有后端服务器集群，也没有可以随便塞模型的包体空间。
但恰恰因为限制密集，微信小游戏是检验一条 AI 工程链路是否真的可落地的最佳验证器。一条链路如果在桌面端跑通、在小游戏上跑不通，问题一定不在模型能力，而在约束处理：包体预算怎么切、进程边界怎么划、沙箱里哪些 API 根本不能用、代码从生成到合规走什么路径。
本文不讲模型选型的通用方法论，只讲一件事：微信小游戏这个容器里，AI 到底能跑在什么位置、跑起来要付什么代价、哪些环节是纯工程约束而非算法问题。
先给结论。微信小游戏里的 AI 只有三个真正可落地的位置：端侧轻量推理（wx.createInferenceSession，仅限 ONNX）、云侧大模型（wx.cloud.extend.AI）、以及构建期与运营期的 AI 辅助（生成适配代码、文案、关卡、审核）。除此之外的 AI NPC 对话、实时 AI 陪玩，在没有后端算力预算和交互延迟余量的前提下，多数是演示效果而非可上线功能。
要谈 AI 怎么落地，先得把这四条边界写死，因为后面每一条都会反过来决定 AI 的可行架构。
微信小游戏官方代码包文档写得很明确：代码包总大小不能超过 30M，单个分包不限制大小，主包不超过 4M。分包加载文档补充了更细的口径：整个小游戏所有主包加分包不超过 30M，主包不超过 4M，单个普通分包不限制大小，单个独立分包不超过 4M。
还有一条容易被忽略的白名单约束：只有后缀在白名单内的文件才能被上传，编译后 *.js 与 game.json 无法直接访问。白名单包含 png、jpg、jpeg、gif、svg、js、json、cer、obj、dae、fbx、mtl、stl、3ds、mp3、pvr、wav、plist、ttf、fnt、gz、ccz、m4a、mp4、bmp、atlas、swf、ani、part、proto、bin、sk、mipmaps、txt、zip、tt、map、ogg、silk、dbbin、dbmv 等。这条白名单直接决定了 3D 资产管线的可选格式：.fbx、.obj、.dae 能进，但 glTF 不在名单里，意味着导入与导出都得先做格式归一。
对 AI 而言，包体边界的含义比看起来更尖锐：一个 7B 量化模型放不进 30M，一个 100MB 的扩散模型也放不进。端侧 AI 在小游戏里只能是小模型、小输入、窄任务形态，这是包体约束的直接推论，不是选型偏好。
开放数据域是微信小游戏最特殊的运行时结构。官方文档定义它为一个封闭、独立的 JavaScript 作用域，通过在 game.json 中配置 openDataContext 指定目录来启用。
约束清单如下，每一条都会影响 AI 的部署位置：
require，双向都不行。sharedCanvas 是全局单例，一旦使用其中一种模式，将不能再切换到另一种模式。sharedCanvas 的宽高只能在主域设置，重设宽高会清空画布内容，需要通知开放数据域重绘。toDataURL 以及 toTempFilePath(Sync)。wx.getUserCloudStorage、wx.getFriendCloudStorage、wx.getGroupCloudStorage 只能在开放数据域中调用。排行榜、好友超越这类社交玩法必须把关系链数据放在开放数据域里渲染，这意味着排行榜 UI 的渲染逻辑天然被隔离在一个既不能调 wx 全量 API、又不能反向传消息的独立作用域里。
多线程 Worker 文档给出了几条硬限制：Worker 运行于单独的全局上下文与线程中，不能直接调用主线程的方法，也不具备渲染能力；Worker 与主线程之间的数据传输使用 postMessage 与 onMessage，传输的数据并不是直接共享，而是被复制的；Worker 最大并发数量限制为 1 个，创建下一个前必须先 terminate()；Worker 内不支持 wx 系列的 API；Workers 之间不支持发送消息；Worker 目录内只支持放置 JS 文件。
最后两条对 AI 部署是致命的：Worker 里跑不了 wx.createInferenceSession（它是 wx API），也跑不了 wx.request（云侧调用）。所以端侧推理只能发生在主域，而主域同时还要负责渲染，推理的耗时直接砸在帧预算上。
微信小游戏文件系统文档给出明确限额：用户数据目录上限 200MB（可申请扩容），单个文件上限 100MB。JS 层与 C++（WASM）层的文件访问机制互相独立：C++ 层写入的文件 JS 层可以直接读取，JS 层写入的文件 C++ 层默认无法访问，需要调用 syncCreateFile 同步后才能访问；官方明确禁止同时通过 JS 和 C++ 写同一个文件，因为两层各自维护独立的写入状态，并发写入会导致文件内容紊乱。
200MB 是能放模型的地方，30M 是不能放模型的地方。这两个数字之间的落差，决定了模型文件、缓存、玩家存档必须分层安置。
盘完边界才能盘点能力。把微信官方在 AI 方向提供的接口摊开看，可用的其实只有三层。
这是唯一能在小游戏里做本地推理的官方通道。API 文档写明：基础库 2.30.0 开始支持，低版本需做兼容处理；model 为必填参数，是模型文件路径，目前只支持后缀为 .onnx 的格式，支持代码包路径和本地文件系统路径；precisionLevel 默认值为 4，有效值 0 到 4，一般来说等级越低推理速度越快，但可能带来精度损失，官方建议在效果满足需求时优先使用更低精度以提高推理速度、节约能耗。
这个接口的设计已经把小游戏的具体约束内建进去了：模型路径同时接受代码包路径和本地文件系统路径，正好对应 30M 包体放不下、200MB 存储能放下的现实；precisionLevel 的分级则对应端侧算力差异。
精度换速度的代价，官方 8bit 量化指南给了可对照的实测数字：基于官方工具 wechat-miniprogram/xnet-miniprogram 的 nncs 目录做量化感知训练后，MobileNetV2 浮点模型精度 71.82，QAT 微调之后精度 71.52。也就是说在官方示例这个量级上，Int8 量化的精度损失约为 0.3 个百分点，而官方同时明确指出量化可显著提升模型推理性能并减小模型的存储和计算开销。这个 0.3 个点可以作为能否上线的初始判据参考，但具体到你的任务模型必须自己实测，因为官方 demo 是图像分类，游戏里的输入分布完全不同。
还有一个容易踩的坑：Worker 内不支持 wx 系列 API，所以推理 session 只能建在主域。想把推理挪到 Worker 就没有官方路径，只能自建 wasm 推理运行时，而那要吃掉本就不宽裕的包体。
微信云开发文档说明，微信小程序与小游戏在基础库 3.15.1 及以上版本，可通过微信云开发的 wx.cloud.extend.AI 扩展接口调用 cloudbase 提供的 DeepSeek、混元、Kimi、GLM、Minimax 等模型，文档中给出了 wx.cloud.extend.AI.createModel() 的用法。
这条通道解决的是大模型能力，代价是网络往返与后端计费。小游戏里调用云侧模型的现实约束是：它运行在主域且是异步的，所以任何用它驱动游戏玩法的设计都必须接受几十到数百毫秒的延迟预算；它消耗的是网络流量与云开发额度，而不是包体；它涉及玩家数据出域，必须过合规审查，把玩家聊天记录、行为数据发往云端模型做处理，与个人信息保护法相关的用户明确同意要求直接相关。
前两层是运行时，第三层不占运行时资源，却是独立开发者真正能拿到的稳定收益：用 AI 生成适配层胶水代码、批量生成多语言文案与合规话术、生成关卡配置的候选方案、辅助素材的压缩与格式归一、把美术资源批量转成符合压缩算法要求的尺寸。
这层的价值恰恰被 AI 落地的叙事忽略了。AI 生成代码在微信小游戏里有特殊的合规含义：小游戏代码包是要过平台审核的，AI 生成的代码如果引入了违规内容，责任在开发者。所以第三层的正确形态是 AI 产出候选、人工审核、静态检查门禁，而不是 AI 产出直接合入。
明确了 AI 的位置，剩下的工程量大多落在怎么把资源切进 30M 里。
wx.loadSubpackage 触发分包下载与加载，加载完成后通过 success 回调通知，返回 LoadSubpackageTask 可获取下载进度。基础库 3.4.9 及以上版本支持 wx.preDownloadSubpackage 预下载，官方明确了两者的区别：前者只下载代码包、不自动执行代码，后者下载完代码包后会自动执行代码。这个区分对 AI 资源调度非常有用，大模型文件适合预下载但延后实例化，逻辑代码包适合在切场景时整体加载。
分包预下载加延后加载，正好是端侧大模型的落地节奏：模型文件走预下载，玩家还在加载动画时把模型拉进本地存储，切到 AI 功能时再 createInferenceSession，把建 session 的初始化开销从首帧路径上挪走。
老版本兼容也有明确规则：微信后台会编译两份代码包，一份分包后代码、一份整包兼容代码，老客户端会下载整包代码启动；基础库 2.1.0 以下不存在 wx.loadSubpackage，需要用 require 触发分包入口文件加载；微信 6.6.7 以下客户端的开发版与体验版因历史兼容问题无法打开分包小游戏，正式发布版不受影响。
独立分包是微信客户端 7.0.13、基础库 2.12.1 及以上版本支持的特性，可以独立于主包和其他分包运行。以独立分包路径启动小游戏时，客户端仅下载独立分包并启动游戏，不会下载主包，以此实现部分场景下快速启动。
独立分包的官方用例正好是排行榜分享与打开，把只包含排行榜逻辑的独立分包路径配到 game.json，通过 wx.shareAppMessage 参数或 wx.onShareAppMessage 回参传入 path 值即可。这给 AI 功能一个干净的架构选项：把 AI 玩法模块做成独立分包，玩家从特定分享卡片进来时只下载这个小模块，不必拉全量主包。
但独立分包的约束必须一起记住：一个小游戏中可以有多个独立分包；独立分包启动只对冷启动有效；独立分包中不能依赖主包和其他分包中的内容，包括 js 文件和资源文件。这意味着 AI 模块如果是独立分包，它的模型文件、推理代码、UI 资源必须全部自包含，不能指望主包里的公共库。
官方适配方案的性能优化段落给了具体建议：采用合理资源拆分策略，建议 1 到 4MB，避免读取超大包或者频繁读取超小包；进入关卡时打开资源文件后及时读取完数据然后关闭，避免在游戏过程中频繁操作文件系统读取数据；涉及批量资源文件读取时建议采用 TAR 包打包成一个整体，载入内存后再批量访问 TAR 包内的文件，避免直接批量读取微信磁盘文件。
1 到 4MB 这个区间，和独立分包不超过 4M 是同一个数量级，这不是巧合，而是平台存储与内存行为的物理约束在起作用。把 AI 模型文件、推理资源按这个粒度切分，既能进独立分包，又不会因为小包过多造成频繁 I/O。
WASM 体积则走压缩路径。官方列出的 WASM 加载优化第一条就是减小 WASM 包大小、压缩 WASM 文件。这一层的工具是成熟的，WebAssembly/binaryen 仓库提供 wasm-opt 等工具链，实测 2026-10-26 该仓库 8664 星、Apache-2.0 协议，最近推送 2026-10-24。
如果游戏主体是 C/C++（Unity WebGL、LayaAir、Egret、团结引擎），就必须经过微信的通用适配方案。这套方案的技术原理文档描述了三层结构：WebAssembly 运行时、JavaScript 胶水代码、适配层。
适配层解决浏览器 API 与微信小游戏 API 的差异，官方给出的映射是明码的：XMLHttpRequest 对应 wx.request 自动转换，WebSocket 对应 wx.connectSocket 封装适配，localStorage 有对应实现。
官方明确标注已由转换工具自动适配、无需额外集成的内置能力里，两条值得单独记。
SDL 音频适配的原理是将标准 Web Audio API 的 AudioContext 替换为微信小游戏的 wx.createWebAudioContext()，技术细节包括自动拦截 window.AudioContext 构造函数返回微信 WebAudioContext 实例，监听小游戏 onHide 与 onShow 事件自动暂停与恢复音频上下文，并针对 iOS 17.5 及以上设备做特殊处理，在 onShow 时重建音频上下文以确保兼容性。首次播放音频需要用户交互触发。AI 生成音频、配音类功能在这个环境里要吃这条约束。
Canvas 与 WebGL 适配的原理是将 Canvas 和 WebGL 上下文获取逻辑重定向到微信小游戏的 Canvas 对象，findCanvasEventTarget 函数始终返回 Module["canvas"]，自动处理 WebGL 上下文创建并支持 WebGL 1.0 与 2.0，在 viewport 设置时进行边界检查防止渲染异常，并适配 document.fullscreenEnabled 属性在小游戏环境下始终返回 true。
对 AI 生成的音频驱动型玩法，比如实时生成 BGM 或语音，音频上下文重建这条会导致状态机需要重新初始化，属于典型的平台约束倒逼 AI 侧代码设计的例子。
官方对 WASM 线性内存的表述相当强：强烈建议设置 -s ALLOW_MEMORY_GROWTH=0 禁用内存动态增长，并通过 -s INITIAL_MEMORY=805306368 预设合理的初始内存大小（768MB，游戏根据自身内存占用设置合适值）；启用 ALLOW_MEMORY_GROWTH=1 会导致运行时频繁的内存重分配，带来显著的性能开销，在小游戏环境中尤为明显，不建议使用。
也就是说小游戏里的 WASM 内存是启动时定死的。对 AI 尤其关键：推理运行时，尤其是自带内存池的 wasm 推理后端或自研运行时，其堆需求必须提前算进 INITIAL_MEMORY，而不是等运行时增长。一个 768MB 的初始内存预留在低端机上就是一次失败开局。
官方列明：Emscripten 版本仅支持 3.1.10 和 3.1.51，最低支持 3.1.8；微信基础库推荐版本 2.19.0 及以上；WebGL 2.0 对基础库有更高要求。Unity WebGL 转换方案的最佳实践里也直接建议依赖团结引擎内置的 Emscripten 工具进行转换，并说明理由是不会有版本问题。
这意味着我本地用最新版 Emscripten 编译一下这类做法在小游戏上直接不可用。跨 wasm 运行时的 ABI 假设、bulk-memory 指令集支持、SIMD 支持在 3.1.10 这个相当老的版本上都有边界，AI 相关的 wasm 推理后端尤其容易踩到，因为很多推理库默认使用较新的 LLVM 后端特性。
微信官方的 Unity 多线程实践文档给出了一个可对照的架构，这套结构恰好也是把重计算挪出主线程的通用范式，对 AI 推理同样适用。
它的分层是：表现层跑在主线程（Unity C#，负责场景管理、渲染、事件消费），逻辑层跑在 Worker（构建成独立的 C-wasm，负责战斗逻辑、物理计算、帧步进），两者通过 ShareArrayBuffer 共享数据交互。
数据通道的细节值得抄：每帧数据传输的 SAB 通道采用 SPSC 单生产者单消费者无锁环形缓冲区，用于 Worker 到主线程的帧结果传输，示例工程有 8 个固定大小 Slot 组成环形队列，resultSAB 约 512KB；RingBuffer 依赖 Atomics.store（release）和 Atomics.load（acquire）进行读写，writeIdx 由 Worker 独占修改表示下一个要写入的 Slot 位置，readIdx 由主线程独占修改表示下一个要读取的位置，如果有同时写入的情况则需要加互斥锁。
C# 与 JS 的桥接走 [DllImport("__Internal")] 加 .jslib 机制，在微信小游戏 WebGL 环境下 C# 无法直接调用小游戏的 JavaScript API，需要通过该机制打通 C# 到 JS 到 Worker 的调用链；Unity 构建 WebGL 时底层使用 Emscripten 工具链将 C#（IL2CPP 转 C++）编译为 WebAssembly，.jslib 文件内容通过 Emscripten 的 --js-library 被链接进 webgl.framework.js；wasm 构建采用 MODULARIZE=1 模式导出具名模块，通过 -s EXPORTED_FUNCTIONS 显式导出 C 函数符号以避免 dead code elimination。
性能数据是官方实测的：场景为放置塔防，场景实体数 700 以上，测试机型 OPPO FindX，配置 GLX 与 WebGL 2.0，测试时长 10 分钟，结论是使用 Worker 多线程后 FPS 有明显提升，能够稳定在 30 帧以上。
对 AI 的直接启示是，这套结构的核心收益来自逻辑与表现分离。端侧 AI 推理完全可以套用同一形态，把推理放到 Worker 的 wasm 侧，主线程只消费结果。但这与 3.1 节的结论构成张力：wx.createInferenceSession 是 wx API，Worker 内不支持 wx 系列 API，所以官方推理 session 只能在主域。想在 Worker 里跑推理，必须自建 wasm 推理运行时，并自己承担 INITIAL_MEMORY 预留、wasm 体积、以及版本被锁在 Emscripten 3.1.10 与 3.1.51 的代价。
这里有一处官方文档之间的口径差异值得单独指出：通用适配方案的技术原理明确建议 ALLOW_MEMORY_GROWTH=0 并预设 INITIAL_MEMORY，而 Unity 多线程最佳实践的 wasm 构建配置里用了 -s ALLOW_MEMORY_GROWTH=1。两处都是微信官方文档，适用场景不同，后者是 Worker 内独立 wasm 模块的构建，内存增长发生在 Worker 侧而非主线程，但对做技术选型的人来说，这恰恰说明在小游戏里讨论内存增长策略必须先说清楚是主域还是 Worker 域，否则结论无法互相套用。
前面提过开放数据域的结构约束，这里单说一个工程判断：随着 AI 参与度上升，开放数据域的合规风险是上升的，不是下降的。
原因很直接。开放数据域是唯一能拿到关系链数据的地方：wx.getFriendCloudStorage 获取当前用户也玩该小游戏的好友的用户数据，wx.getGroupCloudStorage 从群聊分享卡片进入时获取当前群聊的群名与群内同玩成员的用户数据，wx.getPotentialFriendList 获取当前用户对游戏感兴趣的未注册好友名单，基础库 2.9.0 开始支持。用户的段位、战绩等游戏业务数据通过 wx.setUserCloudStorage 托管在微信后台，只有被托管过数据的用户才会被视为玩过该小游戏。
现在把 AI 放进这条链路，有几种典型玩法：AI 生成玩家战绩摘要、生成好友对比文案、AI 帮玩家写分享文案、AI 给排行榜做智能推荐。每一项都要回答同一个问题：这份数据在什么作用域里被处理、经过了什么模型、输出会不会回流到开放数据域。
一个具体的坑：如果为了做 AI 生成排行榜文案而把玩家数据发往云侧大模型处理，那么这段数据就经过了外部服务，而它原本的托管位置是微信后台的云存储。数据的处理路径和责任主体都变了，用户的明确同意、可撤回、以及生成内容的审核责任都需要重新设计。开发者工具的 wx.shareAppMessage 分享路径、独立分包的冷启动入口、云端模型调用，这三件事叠在一起时，数据流向图会比普通小游戏复杂一个量级。
反过来，开放数据域的封闭性其实提供了天然的隔离价值：它不能向主域发消息、不能调 wx 全量 API、不能被主域 require。如果 AI 生成的排行榜渲染逻辑放在开放数据域内，它拿不到主域的任何状态，这既是保护，也意味着不要指望在开放数据域里跑 AI，它连推理 session 都建不起来。
把前面的约束和盘点合起来，可以给出一个明确的落点清单。
适用场景：输入小、任务窄、对延迟敏感、不能容忍网络抖动。典型的是局内行为分类、异常检测、新手难度自适应、简单的视觉小模型。
落地路径是 wx.createInferenceSession：模型用 ONNX 格式，通过 precisionLevel 在 0 到 4 之间选档，模型文件放本地文件系统路径，在 200MB 额度内，session 建在主域，用完调 destroy() 释放内存。
三个必须提前验证的点：一是这个任务的输入在低端机上推理耗时是否落在帧预算内，注意这是主域，主域还要渲染；二是量化后的精度损失要自己测，官方 71.82 到 71.52 那组数字是图像分类任务的；三是基础库 2.30.0 是最低线，低版本需要做兼容处理。
适用场景：需要语言能力、输入输出是文本、交互本身是异步的。典型的是 AI 陪玩对话、AI 生成关卡剧情与文案、AI 客服与新手引导问答。
落地路径是 wx.cloud.extend.AI，基础库 3.15.1 及以上，可以调用 DeepSeek、混元、Kimi、GLM、Minimax 等模型。
三个必须提前设计的点：一是延迟预算，云侧调用是网络往返，必须在 UI 上给异步留位置而不是假装同步；二是数据出域的合规链路，玩家数据发往云端模型需要处理用户同意与最小化；三是计费模型，云开发额度是持续成本，要和 AI 功能的留存收益做对照。
适用场景：开发者侧与运营侧，不影响运行时。
这一层在独立开发者身上收益最直接，而且没有运行时风险。用 AI 生成适配层胶水代码，因为适配层的映射是明码的（XMLHttpRequest 到 wx.request、WebSocket 到 wx.connectSocket、localStorage 等），这类代码生成的成功率相当高，且生成结果可以用静态检查与真机冒烟测试兜底。用 AI 批量处理美术资源，把非 2 的 N 次幂尺寸的图批量规整到符合 ETC1 与 PVRTC 要求的尺寸。用 AI 生成多语言文案与合规话术初稿，再走人工审核。
微信小游戏的代码包要过平台审核，AI 生成的代码不能直接合入。工程上至少需要三道门：静态检查，禁用高危 API、禁止引入违规内容相关的依赖与字符串；体积门禁，生成物进包前跑一遍包体预算，超预算直接拒收；真机冒烟，至少一台低端 Android 真机跑通首启与核心循环。
这三道门对非 AI 代码同样有价值，但 AI 生成代码把它们从可选的质量实践变成了必需的风险控制。
如果要把上面这些变成一份可执行的排期，按依赖顺序应该是这样。
先做包体与运行时的测绘，因为它是所有决策的输入：统计当前代码包构成，看主包有多少、哪些资源在主包里；确认基础库最低版本策略；确认哪些逻辑在主线程跑。这三件事不需要任何 AI 就能做，且做完之后才有资格判断哪些 AI 功能可行。
然后建立体积预算机制。把 30M 总量和 4M 主包写成 CI 门禁而非口头约定，用官方建议的 1 到 4MB 粒度做资源拆分单元，把 WASM 体积压缩纳入构建流程。WebAssembly/binaryen（实测 8664 星、Apache-2.0）与 bytecodealliance/wasm-tools（实测 1805 星、Apache-2.0）是这条链路上可直接采用的工具。
再决定 AI 的落点。用 7.1、7.2、7.3 的判据逐项过：输入是否小、延迟是否可接受、是否涉及玩家数据出域、是否需要运行时资源预算。如果一个 AI 功能四条里占了两条以上，优先考虑挪到构建期。
最后是收益量化。真正可量化的指标有这么几个：主包体积与首屏时间的下降幅度，尤其是把非首屏资源挪进分包后的差值；端侧推理在目标机型上的 P95 耗时，用低端机而非旗舰机；云侧模型的单次调用成本除以日活调用量；AI 生成内容过审率与人工修改率；包体预算门禁拦截的超预算次数，这个数字会告诉你团队的真实资源画像。
一个值得记的对比来自 AI 资产侧：ComfyUI 仓库实测 143005 星，GPL-3.0 协议，最近推送 2026-10-25，说明端侧生成能力的生态热度远高于它在游戏包体约束下的可用性。生态热度不能替代约束可行性，这大概是微信小游戏这个容器给 AI 工程最实在的一课。
顺带一个实测发现的坑，给做 AI 集成的人提个醒：如果你在资料里看到 Unity-Technologies/com.unity.ml-agents，要留意它的实际路径。2026-10-26 实测该路径返回 200 但只有 10 星、最后推送停在 2024-10-17；真正在维护的是 Unity-Technologies/ml-agents，实测 19800 星、最后推送 2026-10-23。AI 生态里路径存在但已废弃和路径不存在是两种不同的失败，值得在选型脚本里区分处理。
三个需要诚实说明的局限。
第一，本文覆盖的是官方文档与公开仓库可验证的部分。不同品类小游戏的实际包体构成、实际机型性能分布差异极大，官方给出的 70% 图形内存下降、30 帧以上等数字来自官方特定场景的实测，不能直接外推到你的项目。纹理压缩那条的 176MB 降到 118MB 是官方示例工程的数据，而它同时提醒了压缩纹理资源体积偏大、Android 的 ETC1 不支持 alpha 通道、PVRTC 要求长宽相等且为 2 的 N 次幂这类代价，收益和代价必须一起算。
第二，端侧推理在微信小游戏里的可行性高度依赖具体任务。官方演示的是图像分类，游戏里的输入分布、时延要求、内存占用都不同，量化精度必须自测。
第三，AI 生成代码进小游戏这条路的合规责任仍然完全在开发者。平台审核的是最终代码包，不是它的生成来源。截至本文写作时，未见公开的、可查证的、小游戏场景下 AI 辅助开发对留存或成本有具体量化影响的数据，任何声称具体提升幅度的说法都应当被质疑。
一句话摘要：微信小游戏是检验 AI 落地能力的最佳验证器，因为它的包体 30M 与 4M 主包上限、开放数据域的单向隔离、Worker 唯一并发且不可调用 wx API、文件系统 200MB 额度共同把能不能做从模型问题变成了工程问题，在这四道边界之下，端侧窄任务推理、云侧大模型、构建期 AI 辅助是三个真正可落地的位置，而任何不先算清体积、作用域与数据出域就开工的 AI 功能，最终都会撞在同一堵墙上。
说明：文中涉及的仓库 star 数、许可证与最近推送时间均为 2026-10-26 通过 GitHub API 实测所得，引用路径已逐条确认可访问。文中标注实测的数据均来自对应引用源，未做二次估算。
Conversation
0 条