“测试全绿”这四个字我盯着CI面板看了十秒钟心里的石头几乎要落地。《清单之外》这个微信小游戏从玩法算法到界面交互开发全程大量使用AI辅助写代码核心逻辑的单元测试覆盖率做到了85%所有用例一次通过。我甚至已经开始琢磨版本号应该定1.0.0还是1.1.0了。然后我把构建产物导进微信开发者工具第一屏白屏Console抛出一行冷冰冰的红色报错ReferenceError: localStorage is not defined。那一刻我才意识到测试全绿和能上线是两个次元的事。这篇复盘就是记录《清单之外》从“测试全绿”到“进Cocos构建后失败”的完整过程到底哪里崩了、为什么单测没拦住、AI辅助开发在这个过程中埋了什么雷以及我们最后怎么把坑填平还顺手建了一套防再犯的检查机制。如果你也在做Cocos小游戏尤其是用AI帮忙写代码这篇值得看完。1. 项目复盘AI辅助开发《清单之外》我为什么敢信“全绿”1.1 玩法与模块划分清单选择驱动规则演化《清单之外》的核心玩法不复杂玩家每天拿到一张自动生成的待办清单每一件待办可以选择“完成”或“忽略”而这个选择会直接影响第二天清单里事项出现的概率和排序方式。把话说直白一点它就是一个带规则引擎的待办游戏重点不在操作而在背后那一套会自我调整的生成算法。为了不让代码搅成一锅粥我把项目拆成了四个独立模块清单生成模块根据权重表、历史选择记录、日期因子生成当天的待办列表。状态机模块管理每条待办的“未处理 / 已完成 / 已忽略”流转。数据存储模块负责本地存档包括玩家历史选择、生成过的清单、统计信息。统计模块计算完成率、连续选择偏好等用于后续调整权重。这种划分给AI辅助开发提供了很好的上下文窗口我可以在提示词里点名“只改状态机模块”AI产出的代码基本不会跑到别的文件里去动全局变量。1.2 测试方案的源头Mock出来的“安全网”既然玩法核心是规则引擎第一反应就是把规则逻辑全部用单元测试锁死。我用的是Jest测试策略非常朴素凡是涉及wx、Cocos引擎接口、文件I/O的地方一律Mock掉让测试跑在“纯逻辑环境”里。具体来说我在测试文件里写了一个简易的wxMock覆盖了setStorageSync、getStorageSync、getUserInfo这些我们用到的方法然后用jest.mock把项目里的wx全局替换成这个Mock对象。测试用例本身写得也勤快权重边界、空清单处理、连续三天忽略某事项后权重衰减……一共一百多个用例CI流水线上全绿。站在当时的视角代码里最复杂的部分都被覆盖了甚至有些AI生成的函数我都没完全看懂但只要Mock一到位测试就是能过。后来我在复盘笔记里给这段经历起了个名字Mock出来的安全网。它在逻辑层面确实是安全网但在环境层面它是一堵完全透明的空气墙。我当时太依赖于“全绿”这个信号忽略了绿灯背后其实有一整套“假设”——假设wx存在、假设存储接口返回的是字符串、假设所有数据加载都是同步的、假设任何异步资源在onLoad阶段都已经就位。2. 进Cocos构建再适配微信小游戏失败现场全记录2.1 白屏、报错、数据丢失一个也没跑掉Cocos Creator的构建在预览器里一切正常。我用浏览器模拟调试了很多次UI没问题交互没问题核心玩法的体验也没问题。构建流程本身也是绿的状态资源被打包、脚本被压缩没有一条错误提示。所以我当时把问题完全锁定在“微信开发者工具的环境配置”上先怀疑基础库版本又怀疑ES6转ES5没开。结果换成微信开发者工具打开构建产物看到的是启动白屏页面完全没有渲染出任何内容。Console第一行报错是ReferenceError: localStorage is not defined但这个报错下面还跟了一大串来自引擎内部的报错属于典型的“首错引发连锁”。藏着几个完全不相关的白屏某个AI生成的数据读取函数在拿到undefined后直接抛异常异常中断了后续的初始化流程。看起来像是几个问题实际上是一根链条第一个环境API调用崩了后续所有依赖它的模块全部炸掉最终表现成白屏。这个链条在单元测试里完全无法复现因为我的Mock里wx.getStorageSync总是返回我预置好的字符串。2.2 数据丢失和异步时序比直接报错更难缠的问题等把白屏问题临时修掉第二批问题马上暴露出来这批不是显式报错而是静默失败。首先是存档丢失。玩家在某一局里选择了三件事次日再进游戏选择记录清零。查日志发现是wx.setStorageSync写入失败但失败没有进入catch而是被当成一次“正常返回”处理了。原因是AI生成的存储模块写得比较粗糙直接用了localStorage.setItem和localStorage.getItem数据体积一大或者写入时机不对就出现覆盖和丢失的情况。其次是异步时序问题。玩家点开某条待办详情时偶尔会触发“未定义属性”的错误。排查后确认是分包加载导致的详情页放在分包里玩家在主页快速点击进详情时分包脚本和资源还没加载完详情页的初始化代码却已经在执行了。这种时序问题是单元测试完全测不出来的因为Jest环境里所有模块都是同步require不存在加载延迟。第三个是分享回调拿不到参数。分享功能本身能用但分享后回到游戏回调事件里带上的一些自定义参数在我们的代码里怎么都读不到。原因也很典型AI实现分享时用了wx.showShareMenu加wx.onShareAppMessage但回调里读取参数用的键名和分享时放进去的键名不一致而且它把参数藏进了某个自己臆想出来的全局变量里。这个在测试环境里没法查因为Mock的分享回调只是返回一个固定对象。3. 顺着报错挖根因完整排查链路复盘3.1 从“怀疑构建配置”到翻构建产物版本的完整排查我一开始走了不少弯路。最先怀疑Cocos构建面板的参数把“MD5 Cache”“Source Map”“Polyfills”全部过了一遍甚至还试过换基础库版本完全没用。顺着localStorage is not defined字样在网上搜了一圈发现大家都说是老问题但每个人给出答案都不是针对我们这个项目形态的看了半天反而更晕。真正有效的一步是把构建产物翻出来直接看。微信小游戏构建出来的JS位于build/wechatgame目录下。我打开目录里最大的那个js文件搜索localStorage一下就定位到了问题代码。那行代码来自AI生成的一个工具函数函数名叫getClientTime里面顺带做了个“顺便把今天的选择计数暂存一下”的操作用的就是localStorage.setItem。而AI生成这段代码时参考的恐怕是大量Web项目的语料——浏览器里当然有localStorage但微信小游戏运行环境没有。看到这里所有“构建配置”的怀疑都消失了。问题很明确我们的代码用了一个微信小游戏环境根本不存在的全局对象。3.2 用全局搜索把环境依赖一个个揪出来找到第一个问题后我意识到这绝不可能只有一处。于是开始在构建产物里做全文本搜索把所有浏览器环境专属的全局变量全部捞出来。搜索词包括但不限于window.document.localStoragesessionStorageperformance.navigator.XMLHttpRequestalert(结果非常刺激。构建产物里一共有12处引用了这些环境专属对象分布于6个模块。其中4处是AI生成的2处是我自己早期从Web项目里拷贝过来的历史代码。这些调用在微信开发者工具里每一处都是潜在的运行时炸弹。只是它们不一定都以“is not defined”的形式立刻爆炸有的藏在某个回调函数里只有在特定用户操作触发时才炸。我还额外检查了Date相关的时区假设好在没踩坑。但performance.now()确实是踩中了在某个统计模块里AI为了追求高精度时间戳用了performance对象而在微信小游戏环境里这个对象不是默认提供的。我们测试环境用的Node版本自带performancepolyfill所以跑用例时压根没报错。你看这就是“全绿”为什么不可信的最好证据连测试运行环境本身都可能和线上环境不一致。3.3 顺着生命周期和存储接口定位另外两处暗雷环境全局变量清完之后白屏和首错问题被解决但数据丢失和时序问题还在。这两类问题无法靠搜索全局变量找出来因为它们不报错只产生错误结果。于是我开始逐条跟踪“存储写入”和“页面初始化”两条链路。存储这条链路最终定位到两个坑。第一个坑是AI生成的数据序列化格式统一性问题。某段代码写入时会先JSON.stringify再存但另一段代码读取时直接JSON.parse读出来的原始值如果wx.getStorageSync返回的是一个已经反序列化过的对象JSON.parse就会抛异常如果不巧抛异常代码也没做兜底直接返回了null于是玩家记录被当成“无记录”处理。第二个坑是微信存储的容量限制。单测里Mock的存储是无限内存永远不会触发容量告警。真机上的wx.setStorageSync对单key和总容量都有上限要求一旦超过写入直接失败。而AI生成的代码把整个统计历史放在了同一个key下面数据量一大就静默失败。生命周期这条链路则更微妙。页面onLoad阶段会先尝试读取某些配置数据但这些数据其实是分包里的脚本运行后才写入的。在开发者工具本地调试时因为本地资源加载快时序歪打正着地躲过去了真机上分包加载稍慢就出现偶尔读到空数据的偶发Bug。4. 测试全绿但环境失败三类典型盲区拆解4.1 过度Mock你测的其实不是你要发布的那套代码第一类盲区也是最常见的一种就是测试环境被人为“修得太好”。单元测试的本质是把被测单元的依赖替换成可控替身从而聚焦在逻辑本身。这个思路本身没有问题但当我连wx、存储、引擎生命周期都要Mock掉时测试就已经从“验证代码在真实运行环境里能不能工作”变成了“验证代码在Mock里能不能工作”。某种意义上Mock就像是给代码定制了一件安全服穿上它的时候所有行为都符合预期脱下来面对真实环境时处处都是意外。我后来总结了一句口诀Mock只该管“外部副作用”不该管“环境基础能力”。存储、请求、分享、文件系统这些都是环境能力与其Mock不如在测试里引入真实的兼容层封装让测试跑在更接近真机的实现上。当然这不是让测试连微信SDK而是让Mock的返回值、返回类型、失败场景都尽量贴近真实API的行为。4.2 AI训练语料的“浏览器惯性”越“标准”的代码越危险第二类盲区属于AI辅助开发的专属问题AI生成代码时默认掉进了浏览器语料的惯性里。这很容易理解——整个互联网上开源的JavaScript代码绝大多数都跑在浏览器环境里。window、document、localStorage、performance这些都是AI见过一万次的写法它们出现在生成结果里的概率天然就高。更有意思的是AI写出来的这类代码通常还非常“标准”看起来就是一本正经的教科书写法放在Web项目里完全没毛病。但微信小游戏不是网页。它运行在特殊的脚本环境里没有BOM和DOM没有window也没有localStorage。问题出在一个训练语料以Web为主的模型不会主动意识到“当前环境是微信小游戏”除非你在提示词里非常明确地掐死这些边界。AI不会怀疑localStorage是否存在它只会认为这是最普通的参数。我在复盘时给这种现象起了个名字叫“越标准越危险”——AI写的函数读起来越规范、越无可挑剔越说明它很可能在生搬硬套浏览器的标准环境。4.3 时序、资源配额、系统API差异静态单测测不出的边界第三类盲区是单测天然测不到的那些“运行时有形条件”。我把它们放在了一起异步加载时序、资源体积配额、平台专属API差异。这些条件有一个共同点——它们不在代码逻辑里而在代码的运行环境里。逻辑正确代表的是“如果一切条件都按预期出现则结果正确”但真实环境里条件经常不按预期出现。微信小游戏的运行环境是一个受限容器存储有配额、单包有体积上限、分包加载有延迟、渲染性能有天花板这些限制没有任何一个会被Jest用例捕捉到。比如我们遇到的详情页闪进闪出。在本地测试中所有分包脚本都随主包一并加载资源瞬间就位。但在真机上分包加载也许需要几百毫秒玩家如果在这个窗口期内触发依赖分包数据的操作就会得到未初始化的数据。再比如canvas的toDataURL在微信小游戏里根本不受支持得用toTempFilePath这种API差异在单元测试里无法体现必须真机验证。三类盲区我总结成一张表方便大家对照自己项目里的情况盲区类型单元测试环境表现微信小游戏真实环境表现过度MockMock的存储永远有空间返回类型固定存储有上限写入可能静默失败AI语料惯性代码里的window/localStorage没被发现直接ReferenceError引发白屏链时序与配额所有模块同步加载资源即时可用分包有延迟资源有体积压力性能有天花板你如果把这张表贴在自己的冒烟测试清单旁边会发现它能预判掉大量“全绿但上线挂”的坑。5. 修复落地从补丁式修复到建立防再犯机制5.1 存储模块统一收口平台差异被关进一个文件第一波修复很直接把所有直接调用localStorage、window的地方全部改掉。但靠人工逐个改肯定治标不治本所以我把存储功能统一收口到一个storage.js模块里未来谁都不许绕过它直接碰平台API。// storage.js —— 平台差异统一收口 import { sys } from cc; function getNativeStorage() { if (typeof wx ! undefined wx.getStorageSync wx.setStorageSync) { return wx; } return null; } export function save(key, value) { const str JSON.stringify(value); const nativeStorage getNativeStorage(); if (nativeStorage) { try { nativeStorage.setStorageSync(key, str); } catch (e) { console.warn(存储写入失败, key, e); } return; } sys.localStorage.setItem(key, str); } export function load(key, fallback null) { const nativeStorage getNativeStorage(); let raw null; if (nativeStorage) { raw nativeStorage.getStorageSync(key); if (raw || raw undefined || raw null) { return fallback; } raw typeof raw string ? raw : JSON.stringify(raw); } else { raw sys.localStorage.getItem(key); } try { return JSON.parse(raw) ?? fallback; } catch (e) { return fallback; } }这个模块的设计思路是先判断wx是否存在存在就走微信原生接口不存在就走Cocos封装的sys.localStorage保证预览器和开发者工具都能跑。写入前统一JSON.stringify读取时对非字符串类型做兼容处理因为在微信接口下某些版本会直接返回对象直接JSON.parse反而会炸。读取失败一律返回fallback绝不让数据异常中断初始化流程。这个模块只做一件事让“存储”这个词在代码里只对应一个稳定的接口。以后AI生成的任何代码我都要求它必须引用这个封装不许再碰底层API。5.2 把环境依赖检查做成构建前置门禁只靠代码审查约束AI是不可靠的所以我写了一个静态扫描脚本专门检查构建产物里是否残留浏览器环境专属调用。它被挂进构建流程只要扫到就fail掉构建。// scan-env-deps.js const fs require(fs); const path require(path); const distDir path.join(__dirname, build/wechatgame); const bannedPatterns [ /\bwindow\./, /\bdocument\./, /\blocalStorage\b/, /\bsessionStorage\b/, /\bperformance\./, /\bnavigator\./, /\bXMLHttpRequest\b/, /\balert\(/ ]; let found 0; function walk(dir) { for (const file of fs.readdirSync(dir)) { const full path.join(dir, file); const stat fs.statSync(full); if (stat.isDirectory()) { walk(full); } else if (full.endsWith(.js)) { const content fs.readFileSync(full, utf8); for (const pattern of bannedPatterns) { const match content.match(pattern); if (match) { found; const line content.slice(0, match.index).split(\n).length; console.log([环境依赖] ${full}:${line} - ${match[0]}); } } } } } walk(distDir); if (found 0) { console.log(发现 ${found} 处环境依赖调用请在代码中修复。); process.exit(1); }别小看这个脚本它把“环境合规检查”从人工环节变成了自动化环节。每次构建都像有一双眼睛盯着代码一旦AI写出一行window.xxx构建就会当场失败而不是等微信开发者工具跑起来才发现。5.3 测试策略重新划界逻辑归逻辑环境归冒烟修复完代码后我重新调整了测试策略。核心原则是单元测试只承担逻辑验证环境验证交给另一层测试。单元测试继续保留但Mock策略升级存储模块不Mock改成引用真实的storage.js只把最底层的wx接口替换成一个状态完整的假实现让测试能感知到写入、读取、失败的状态变化。所有和生命周期、异步资源加载相关的逻辑一律不写单测改成集成用例。凡是依赖环境API的代码必须经过真实环境冒烟测试。冒烟测试的做法是在微信开发者工具里跑一份自动化脚本覆盖“初始化、生成清单、完成一项、忽略一项、退出再进入、分享回调”这6条核心路径。Cocos项目跑开发者工具自动化脚本稍微麻烦一点但好处是它能真正验证代码在微信运行时的表现。这层测试没法进CI我把它做成了每次发版前的固定动作。这么一来“全绿”这个词的含义就变了它只代表逻辑正确不代表环境正确。而环境正确性的信号由另一套机制给出。6. AI辅助开发复盘以后我再也不会被“全绿”骗了6.1 AI为什么总在环境边界上保持乐观这次踩坑下来我对AI辅助开发的理解比之前务实了很多。AI确实提效尤其在写纯逻辑、纯算法、纯数据处理的时候质量高、速度快因为有大量公开代码样本可以参照。它的短板在于环境边界——AI没有“我当前正在写一个微信小游戏脚本”这种上下文感知它更倾向于复用最常见的Web通用写法。更让我警惕的是AI在不确定环境是否支持某个API时会选择自信地直接写出来而不是先问一句“这里环境对吗”。这可能是因为训练语料里“直接使用localStorage”的例子数量碾压“先判断环境再使用”的例子数量。所以我的提示词里从此多了一条硬性规则不确定某个API在当前平台是否存在时先说明风险不要自行脑补兼容层。6.2 我们总结的AI辅助开发防坑清单每次让AI生成新模块我都会在提示词里贴一段环境约束说明效果非常明显。这段说明后来被我们小组起名为“小游戏环境咒语”运行时没有window、document、localStorage、performance、navigator。持久化数据优先使用项目内的storage.js禁止直接调用底层存储接口。跨端能力一律使用项目内的平台封装模块未封装的功能先询问。生成的代码要能在微信开发者工具的基础库环境下运行不能依赖浏览器特性。涉及异步资源加载时默认按“资源可能还没就绪”来写防御逻辑。除了提示词我们还定了两条审查规矩第一AI生成的代码必须做“环境审查”专门检查有没有平台专属API的误用和逻辑审查分开因为眼睛在看逻辑时很容易放过环境问题第二不要因为测试全绿就给AI代码放行全绿只是入场券。6.3 一点关于工具链的想法回到标题里的那个问题测试全绿为什么进Cocos还是失败现在我们有了明确的答案——因为测试全绿验证的是“逻辑在Mock环境里成立”而进Cocos构建、进微信小游戏环境失败是因为它验证的是“代码在受限环境中成立”。两者之间的差值就是所有坑的藏身之处。如果非要给AI辅助开发下的工具链提点建议我强烈建议大家把“环境静态扫描”和“真机冒烟用例”当成标配而不是可选项。AI写代码的能力越强这些防御机制就要越重。因为AI不会记住平台边界它只会顺着语料的惯性走而你需要用机制帮它踩刹车。这次修完《清单之外》之后我把扫描脚本和提示词咒语都存进了团队模板库下次新项目直接用。至少到现在我们新的小游戏项目已经连续跑了好几轮真机预览没再出现过“全绿但白屏”这种让人血压拉满的情况。如果你也在用AI帮自己写Cocos小游戏第一件事不是催它写功能而是先把环境合规的门禁立起来。