上个月翻移动硬盘找东西翻出来一个2018年写的Unity工程文件名就很直白TaFang_BaoWeiLuoBo_TowerDefense。打开一看2018年那个Unity版保卫萝卜类塔防demo还在路径点寻路、波次生成、炮塔升级、导弹追踪一套逻辑全乎但用的还是Unity 2018.4时代的API连UI都是老版uGUI写的。说实话当时我第一反应是这东西能打开就不错了结果我顺手试了一下从整理工程到用AI辅助改造再到导出WebGL塞进浏览器里跑起来前后大概就花了两个小时。这篇文章就是记录一下我是怎么干的中间踩了哪些坑以及AI在整个过程中到底帮了多少忙。如果你手上有Unity老项目想放到网页上跑或者你好奇AI辅助改代码的真实效率又或者你只是想看看一个塔防游戏Web化要过几道关这篇文章都能给你一个挺直接的参考。1. 整体思路先把“搬进浏览器”这件事拆明白在真正动手之前我先没急着改代码而是花十几分钟把这个2018年的Unity工程结构和要解决的问题列了一遍。这一步很关键很多老项目移植翻车不是死在代码上而是死在思路混乱上。1.1 先盘清楚这个2018年的Unity项目到底有什么我那个demo虽然模仿的是保卫萝卜的玩法但核心就是一个标准塔防框架代码主要分成几块路径点系统敌人沿着路点移动用Transform.position逐个点走简单但管用。波次生成器一个协程每隔几秒生成一波敌人波次之间休息敌人模型是胶囊体和Cube拼的。炮塔系统分为单发炮、范围火焰、减速冰三种每种炮塔有攻击范围检测、目标锁定、子弹飞行逻辑。子弹与伤害用OnTriggerEnter判断命中扣血血条是老版UI Slider。UI与计费金币、生命值、波次信息按键放炮塔用的是uGUI的Button.onClick.AddListener。存档金币和关卡进度用PlayerPrefs存这个在WebGL下反而是最省事的。这个项目当年是照着教程边学边写的代码谈不上优雅但结构还算清晰。为什么要先盘这一遍因为你要让AI帮你改代码你首先得告诉AI这个工程里大概有哪些系统AI才能给出有针对性的修改建议。直接把几千行的整个工程丢给AI让它“帮我搬到浏览器”效果通常很差AI会陷入上下文爆炸给出的回答也会泛泛而谈。1.2 为什么选Unity WebGL而不是用JS重写我一开始确实犹豫过要不要干脆用Phaser或者纯JavaScript重写一遍。毕竟这个塔防玩法不复杂几个类的关系也清楚用Canvas重写也未必慢。但列了一个方案对比之后我果断放弃了重写方案优势劣势预估成本Unity直接导出WebGL逻辑、美术、场景全保留Unity官方维护以后PC端还能接着更新包体较大老API需要适配导出设置有讲究两小时主要花在改API上用Phaser/JS重写包体小加载快代码可控性强所有C#逻辑要重新写一遍UI、动画、资源全重做测试量巨大两天起步连测带调至少一周ReactCanvas自绘当练手没问题大到没边了不推荐所以答案很清楚继续走Unity WebGL是性价比最高的路。Unity 2018年那个阶段WebGL导出已经能用但当时插件时代留下的阴影太深很多人做过一次就被各种报错劝退了。实际上2018.4以后的WebGL支持已经很成熟尤其这几年Unity引擎在浏览器端的内存管理和加载策略都改进了很多只要把老代码里的平台依赖清理干净跑起来是没问题的。1.3 AI到底帮了什么忙很多朋友一听“AI帮我搬项目”以为是AI直接生成一个全新游戏其实不是。我这次的真实体验是AI更像一个读过全部新版文档的老搭档帮我做了三件事API翻译把Unity 2018里已经过时的写法对应翻译成新版Unity我最后用的是Unity 2021.3 LTS能认的写法。编译错误预判在我导出前把常见的老API升级错误提前解决掉省去了一轮轮试错。平台差异排雷比如文件读写、鼠标输入、协程在WebGL下的行为差异AI能提前提醒我哪些代码在浏览器里不工作。后面两章我会详细展开这三件事具体是怎么做的。2. 工程抢救与WebGL导出准备2018年的工程放到今天第一步要解决的是“能不能用Unity打开”。这步没搞定后面全是空谈。2.1 打开一个2018年的Unity工程没那么可怕我遇到的情况是这个工程当初是用Unity 2018.4.0创建的而我电脑上已经装了Unity 2021.3 LTS。直接用新版本打开旧工程Unity会提示升级但经常会有资源丢失或脚本引用断裂的幺蛾子尤其老项目里如果有第三方插件那升级就更头疼了。我的做法是先复制一份完整备份再装一个Unity 2018.4 LTS用它把工程打开确认原始状态能跑起来。然后才从Unity Hub里右键工程选择用2021.3打开让Unity自己跑完升级流程。这个渐进式升级比一步到位跳大版本要稳得多。升级完成后大概率会有几十条编译错误这时候正好轮到AI上场。我把Unity升级后控制台里的报错信息整段复制给AI不问“怎么办”而是问这是我从Unity 2018升级到2021后出现的一批编译错误请按错误类型分组告诉每组错误的共同原因并给出对应的新版API写法。我想先修复所有报错再继续做WebGL导出。请以清单形式输出每一条都标注风险等级。AI给出来的结果说实话比我预想的要靠谱。像UnityEngine.Assertions.Assert命名空间变化、WWW类被UnityWebRequest替代、AudioSource.PlayClipAtPoint行为变化这些它一条条给我列清楚了。我照着改大概四十分钟后工程在2021.3下编译通过了。这个过程中我不是无脑照抄每次改动都是小步提交改完一部分就回Unity里看一眼确认没引入新问题再动下一块。2.2 导出WebGL之前的几个关键设置当工程在新版本下能正常跑之后接下来就是Build Settings切换到WebGL平台。这个操作本身很简单但有几个设置如果没弄对后面会非常折磨人压缩格式默认是Brotli压缩但如果你要部署的服务器没配置对MIME类型和Content-Encoding浏览器会直接解压失败页面白屏。对于新手我建议先在Player Settings里选择“Disabled”或“Gzip”等本地测试通过后再切回Brotli并让服务器配合配置。Code Optimization要把默认的Balanced改成Fastest这样能大幅减少JS体积加载速度能快不少。Enable ExceptionDevelopment Build时建议打开Full Stacktrace方便排查问题但正式发布版本务必关掉否则异常信息会拖慢运行效率。WebGL Memory Size2018年的老项目如果资源比较多默认的256MB可能不够加载时会出现内存溢出。我这次直接设置成512MB反正现在大部分浏览器内存不是瓶颈。Color Space如果项目用的是Gamma且没有处理线性光照导出效果可能在浏览器里出现亮度差异这个需要检查一下。2.3 第一次编译报错的集中处理思路其实把平台切到WebGL之后Unity还会编译一次脚本这次编译针对的是WebGL平台很多之前在Editor下不报错的代码会在这时候暴露问题。我第一次切平台直接蹦出来三十多个错误。我的处理顺序是这样先只看Error忽略Warning把所有报错信息复制给AI。让AI按“报错文件原因建议修改”的格式整理。AI给的修改我也不会全信先挑最危险的几处人工核对比如unsafe代码、多线程、反射这些在WebGL下都是禁用的。改完一批就重新编译分批消化全部解决再进下一步。用这个方法第一次切平台产生的错误大概二十分钟就消掉了。要是不靠AI凭我自己对着文档一条条搜两个小时光编译错误都不一定够。3. AI辅助改造的核心环节实操接下来就是重头戏了怎么让AI真正帮你把这个老Unity项目搬到WebGL。这个阶段我不建议直接问“帮我把这个项目Web化”而是把项目拆成一个一个具体问题逐个击破。3.1 让AI当“老代码翻译官”一个可复制的Prompt流程AI在这类任务里最擅长的是翻译“旧版本的底层假设”到“新版本的实现方式”。你要做的就是给它足够多的上下文。我总结了一个三段式Prompt基本每次都很管用给它身份和目标比如“你是一个Unity老项目迁移专家我正在把一个2018年写的塔防游戏从Unity 2018迁移到Unity 2021并导出WebGL”。贴上具体代码或报错不要让它凭空猜测把具体的类、方法、报错信息贴给它。要求输出格式指定格式比如“请用表格列出每处改动前和改动后的代码并说明为什么这样改”。举个例子我有一段存档代码用的是System.IO.File.WriteAllBytes把文件写到Application.persistentDataPath。这段代码在Editor下没任何问题但WebGL下根本行不通因为浏览器没有完整的文件系统。我直接把这段代码发给AI让它给出WebGL兼容方案。AI很快告诉我WebGL下的Application.persistentDataPath其实映射到浏览器的IndexedDB但因为异步IO限制System.IO.File在WebGL下是不可靠的。建议把存档逻辑改成用PlayerPrefs存字符串或者用Unity的WebGLFileSystem相关API。最后我选了PlayerPrefs因为我们游戏的存档数据本来就小序列化成JSON字符串存进去就够了。3.2 平台差异是重灾区存储、输入、加载WebGL不是一个让你无缝搬家的平台以下三个差异是我这次改造中遇到的最大头。存储差异。在PC上我们可以随便写文件、读文件什么File.Exists、Directory.CreateDirectory都不在话下。但到了浏览器里Unity的C#运行时被编译成了WebAssembly它没有直接操作操作系统文件系统的能力。这时候有两个选择一个是把小数据转成JSON字符串用PlayerPrefs保存另一个是用IndexedDB做异步文件读写要引入UnityEngine.WebGL命名空间下的相关API但用起来麻烦没太多必要。我最终选择统一封装一个SaveManager把所有存档文本都放到PlayerPrefs里代码一下子简单了。输入差异。老项目里很多地方直接用了Input.GetMouseButtonDown(0)这在WebGL下其实也能响应鼠标事件但如果你希望游戏在平板上也能玩纯鼠标API就不够用了。Unity 2021里推荐的做法是检测Input.touchCount来判断是否有触摸输入或者干脆接入新版Input System。我因为是演示demo就保留了老API用鼠标点击也能跑如果以后要触屏优化再改。资源加载差异。2018年的项目里我用过Resources.Load加载预制体这个在WebGL下依然能用但要注意加载时机和内存。另外如果用了AssetBundleWebGL下不支持异步场景流式加载会导致打包体积膨胀。如果只是个小游戏老老实实把所有资源打进Build里反而是最省心的。3.3 实操案例把一段老存档代码改成WebGL兼容拿真实的改动过程来演示一下这样更直观。老代码大概长这样// 2018年写的存档PC上用得很开心 string savePath Application.persistentDataPath /game_save.json; File.WriteAllText(savePath, JsonUtility.ToJson(saveData));这段代码在WebGL下会出问题。我把这段代码发给AI后它给的建议是string saveKey game_save; string json JsonUtility.ToJson(saveData); PlayerPrefs.SetString(saveKey, json); PlayerPrefs.Save();读档则变成if (PlayerPrefs.HasKey(saveKey)) { string json PlayerPrefs.GetString(saveKey); saveData JsonUtility.FromJsonSaveData(json); }改动看起来很小但这是最有价值的改动之一因为如果不改游戏在浏览器里跑起来压根存不了档。我照这个思路改完再在Editor里跑了一遍确认存档数据能正确写入、读取才继续往下。3.4 UI与交互细节点击范围、Canvas、字体这个环节看着小但实际体验影响非常大。老项目里为了做炮塔选择按钮我用的是普通uGUI按钮但按钮尺寸比较小浏览器里用鼠标点击可能还好一旦准备上触屏或者用高DPI缩放点击区域就会显得特别难按。UV现在很多Unity项目会用“扩大按钮点击范围”的思路最简单的方法是在按钮下面放一层透明的Image设置成Raycast Target true这样整个透明区域都能接收点击。具体做法是在按钮节点下加一个子节点挂Image组件把图片像素设为透明图Color的Alpha调到0然后拉大RectTransform到想要的点击范围。这样既不影响显示又能扩大点击热区。Canvas模式也要注意。WebGL导出后Canvas的Screen Space - Overlay模式在大多数浏览器下是OK的但如果你的页面有滚动条或者想把游戏嵌进某个特定页面区域建议使用Screen Space - Camera配合正交相机能避免很多坐标偏移问题。还有字体丢失问题。2018年的老项目如果用了非默认中文字体在浏览器里加载可能会因为字体文件缺失显示成方块。我在导出前把字体文件拖进项目确认Font资源的Font Names列表里有对应字体并且在UI组件里明确指定才避免了中文显示乱码。4. 常见问题与排查技巧实录这个章节是真正拿真金白银换来的经验很多问题都是在浏览器里跑起来后才暴露的比编译错误恶心多了。我把最重要、最容易踩的坑一条条列出来。4.1 问题速查表问题现象根本原因快速解法首次加载白屏控制台报Brotli错误服务器没配置Content-Encoding: br先改用Gzip或Disabled压缩或正确配置服务器游戏能进但存档失败System.IO.File在WebGL下不可用改用PlayerPrefs或IndexedDB异步API浏览器控制台报idbfs写入失败IndexedDB被浏览器阻止或存储配额不足检查隐私模式、第三方Cookie屏蔽、跨域iframe设置游戏画面里阴影乱掉或消失光照贴图/实时阴影在WebGL下表现不同降低Shadow Distance改用实时灯光或简易假阴影按钮点击没反应UI被全屏透明Image拦截了Raycast检查Graphic Raycaster和透明Image的Raycast Target加载速度慢内存高打包体积大、堆内存设置太高开启压缩、删冗余资源、将Memory Size调至合理值页面嵌到自己的网站后游戏无法全屏浏览器限制requestFullscreen权限需要用户手势触发全屏不能自动进入4.2 典型案例idbfs写入失败如果你搜索“unity 发布 webgl 使用 idbfs 写入失败”会发现很多人在问。这个问题的根源是Unity的WebGL运行时在浏览器里实现了一个虚拟文件系统底层的持久化存储依赖的是IndexedDB。Unity官方文档里管这个虚拟挂载点叫idbfs。一旦浏览器不让你写IndexedDBUnity就会把文件系统挂载失败表现就是控制台报错游戏无法正常存档甚至无法启动。我实际遇到的情况是在Chrome正常模式下没任何问题但我把同样部署好的页面放到一个iframe里做内嵌预览后存储就失效了。排查到最后发现是iframe缺少allow-same-origin属性导致页面被浏览器放进了不同的存储环境。另一个常见原因是开启了隐私模式或者浏览器设置了“阻止第三方Cookie”IndexedDB也跟着被限制。排查顺序我建议是这样直接确认控制台里有没有具体的IndexedDB报错。换一个普通无痕窗口之外的新窗口试。查看网站是不是嵌在iframe里检查allow-same-origin和allow-scripts。检查浏览器存储配额如果页面已经存了大量其他域名数据Unity的写入也可能被拒。4.3 阴影和渲染问题WebGL的渲染跟Desktop OpenGL是有差异的尤其是老项目里用到的光照贴图在WebGL下可能不会正常烘焙。我在导出后发现场景里的实时阴影在浏览器里变得很奇怪有的暗面直接变成了纯黑有的炮塔阴影飘起来脱离了地面。这里给三个实用建议如果你的游戏不需要动态阴影直接关掉实时阴影使用假阴影一个半透明黑色圆盘跟着角色转性能好还不会出问题。如果用实时阴影尽量把Shadow Distance调到50以内避免远处物体产生闪烁阴影。光照贴图在WebGL下需要重新烘焙或者干脆改成纯色环境光实时灯光省得出现“亮一块暗一块”的奇怪效果。4.4 性能和加载优化实测导出WebGL之后能不能流畅运行取决于两件事加载速度和帧率。我这做的是一个塔防demo场景不复杂但老项目里塞了一堆没用的测试资源导致首包体积居然到了180MB。这在PC上无所谓浏览器里就是灾难。我用AI帮我扫描了一遍工程里的无用资源把没引用的材质、模型、贴图全部清掉首包从180MB降到了60MB加上压缩设置实际加载体量降到30MB左右差不多12秒能进游戏。内存方面Unity WebGL默认给堆分配的内存是256MB或512MB虽然比桌面程序小但对塔防这类游戏完全够用。关键是要养成好习惯不要动不动就Instantiate一堆子弹又不销毁该用ObjectPool就用对象池。这里再分享一个小技巧在浏览器控制台里你可以用UnityLoader和Module全局变量来调整一些运行时行为但更便捷的方式是用Unity的官方Memory Profiler分析运行时的内存占用看有没有泄漏。4.5 部署到线上的CORS与MIME注意事项本地测试是一回事部署到线上是另一回事。静态服务器上至少要把.wasm、.unityweb这些文件按二进制类型返回把.js、.json这些按文本类型返回。如果服务器的MIME类型配置错了最常见的现象就是浏览器控制台飘红wasm streaming compile failed。还有如果你的游戏要跟其他域名下的API通信比如排行榜记得服务器要开CORS跨域。Unity WebGL的UnityWebRequest默认遵守浏览器的同源策略不配置CORS就会请求失败。我之前有次本地跑来一切都好传到服务器就白屏排查半天才发现是服务器把.unityweb文件当成application/octet-stream返回了Unity加载器没法正确识别压缩数据改完MIME类型后立刻就好了。这个坑很多人第一次WebGL上线都会遇到现在提前写出来希望你能绕过。最后再聊聊我自己的体会这两小时的项目移植让我对AI辅助开发有了新的看法。以前我不太敢把老项目交给AI去弄怕它理解不了我的代码意图实际用下来发现把报错和代码片段喂给它之后它给出的修改方案虽然不能直接用但至少帮我把排查范围缩小了80%。尤其在WebGL这种“文档分散、坑又特别多”的环境里AI的记忆库是真的庞大。当然话又说回来我自己要是不懂塔防逻辑和Unity基本生命周期还是会很容易被AI误导。AI给的建议再正确也要能看懂、能验证才行。真让我总结这次经验的话我会说老项目迁移最值钱的是你的活地图AI是跑得飞快的向导你手里那张地图才是不会迷路的关键。