AI独立游戏开发笔记(二):AI为你写代码时,你也要教AI写代码听起来很潇洒对吧。实际写起来，三天之后我的项目变成了一座shi山。不是说 AI 会丢上下文——它能连续聊很多轮，记性不差。但当代码量上来了、模块多起来之后，它就容易忽略那些边边角角的小模块。你让它改一个 bug，它东墙补上了，西墙又塌了，改完这个，那个又坏了。这就是单人用 AI 做开发最真实的痛：代码一多，你教不过来，它也就顾不过来。后来我才想明白：AI 在教你写代码的同时，你得先教会它怎么写你的代码。
先说说模型。这个项目从六月初开始码，到现在也快两个月了，能用的模型我基本都试过一圈。最后当主力的是 DeepSeek V4 Pro。它写代码的手感最稳，平时我直接把需求丢给它就行，它接得住大部分活。但真正超级难的任务——那种要跨一堆文件重构、逻辑绕得让人头疼的——我会换 GLM 5.2，它在这种硬骨头上更顶得住。也试过别的。Kimi 2.7 长上下文是优势，整个项目丢给它做全局重构确实能看全，但就是太慢了，等它写完我都想去泡杯咖啡了，而且动不动就进入死循环，卡住出不来。MiniMax M3 倒是能用，可输出时间整体偏长，遇到疑难任务还是搞不定。还有几个试过就放下的，不是它们不好，是没对上台。我现在的用法是：一个模型写初版，另一个模型 review，第三个模型做交叉检查。听起来很浪费，但比"一个模型写到死然后全部推翻"省时间多了。
第一，代码模块化。别把所有东西塞一个文件里。AI 的上下文窗口再大，你给它一个几千行的文件它也容易懵。拆成小模块，每个模块干一件事，AI 改起来才精准。第二，多写注释。不是给未来的自己看的，是给 AI 看的。你写一句"这个函数是用来控制怪物眨眼频率的，参数是毫秒间隔"，AI 改起来就不会乱动别的地方。注释是 AI 的导航仪。第三，让 AI 先写设计文档再写代码。我现在的流程是：先让 AI 输出一份"这个模块要做什么、接口长什么样、依赖哪些其他模块"的文档，我确认没问题了，再让它动手写。省得它写到一半方向跑偏，改起来比重写还痛苦。第四，备份文档目录。每次让 AI 做大改动之前，我会先让它把当前项目的文件结构和模块关系输出一份文档存下来。万一改崩了，至少我知道原来长什么样。第五，多模型交叉检查。一个模型写完的代码，丢给另一个模型问"你觉得有什么问题"。它们经常能互相抓出对方的低级错误。这招特别好用，尤其是对那种"能跑但逻辑微妙地不对"的 bug。总结下来就一句话：你教得越清楚，AI 写得越像话。
游戏之外我还单独写了一套代码——关卡生成器，跟游戏本体不在同一个项目。逆向构造引擎、形状模板、四种扰动策略、查重机制、难度评估公式……这些逻辑比游戏本身复杂得多。AI 能帮上忙，但骨架完全得自己搭。有些东西复杂到连它也没法替你写，你得自己先想清楚，再教它。AI 出图这件事，我本来以为是最轻松的部分。结果是最心累的。出图就像抽卡，慢的不是出图本身，是你得反复试、反复调提示词——风格总算对上了，构图、细节又不对，改完再出，再试。更费时间的还在后头：好不容易抽到一张能用的，切图、抠图全得自己手动做。我当然尝试过AI来切图抠图，自己还写了一个agent，但AI 切出来的边缘经常有问题，对齐更是灾难——眼睛往上挪一点、身体往左偏一毫，这个资源就不能用了。背景图也走了弯路。一开始想用几张图拼出完整场景，但拼接缝怎么都消不掉——不同分辨率下像素对齐的问题，技术上不太好解决，每换一张图就要重新对齐地平线，折腾了很久。最后干脆改掉方案，回到最简单的：一张整图，居中铺满，超出的裁掉，不够的加黑边。适配各种屏幕，一劳永逸。不切图，那动画怎么办？纹理图又贵又难切，与其跟它死磕到底，不如干脆不用纹理——纯靠数学，让怪物的部位自己动起来。
它最初的出发点特别朴素，跟审美一点关系没有——纯粹是想省事。小怪物要眨眼，常规路子有两条：要么用视频模型生成 GIF 动图，要么做帧动画。两条都试过，都耗时得可怕，每个动作都要手动处理一大堆美术资源，时间成本高到离谱。所以最后我想，干脆用代码把动画写出来：省掉所有美术加工，还能捎带手把客户端性能提上去。客户端这边没挂任何引擎，就是 Canvas + JS 原生。眨眼这个动作，本质上就是"竖直方向缩放到接近零，再恢复"。一条 transform 曲线，零纹理开销——所以哪怕场上怪物很多、一堆动画同时播，也不会卡顿。这其实是为了追求极致：既极致省事，也极致流畅。设计思路也顺着这个方向定了下来：用眼睛代替小怪物身体的运动。点击某个小怪物，同色的会一起睁眼看向它；下落的时候眼睛睁开；消除的时候也有眼睛的反馈。整个游戏几乎不用做身体动作，所有情绪全靠一双眼睛来表达——既简洁，实现也相对简单。然后控制眨眼的时机。不是随时眨，是待机状态下随机触发，自然错开。动画本身用了懒加载。怪物不在屏幕里的时候，动画状态直接挂起，不占渲染资源。这套东西写完之后，性能确实好了。百个怪物同屏也不炸。性能稳了之后，我就在这套数学上越玩越上头。眼睛不只是会眨——被消除的瞬间突然瞪大，像在喊"啊！"；掉落的时候惊讶地睁圆，像在说"我在飞！"；同色的那只被选中，"一家人"会一起睁眼看向它；有同伴被消掉掉下去，旁边的还会行个注目礼。每一处情绪，都是几何参数在变，零纹理开销。不是那种"设计出来的可爱"，是那种"它好像真的在思考要不要眨一下眼"的生动感。因为眨眼是随机的、有间隔的、偶尔会连续眨两下——这些微小的不规则，让它看起来像个活物而不是个贴图。我女儿路过的时候又凑过来了。这次她说："它在看我。"最后给它取了个名字：萌眼叠叠消。小怪物睁着可爱的眼睛叠在一起、消掉——就是这么个游戏。眼睛不止救了性能，还成了整个游戏的灵魂。
最后说一嘴 AI 美术工具。现在这个阶段，AI 出图能用，但离"好用"还差得远。我也试过一些专门为游戏做美术资源的 AI 工具，常见的功能都有，但都还不够好，切图、分层、动画适配还是得靠人肉。不过工具迭代的速度摆在那——从只能出一张图，到能保持角色一致性，再到能输出带透明通道的素材——正一步步往"直接能用"的方向走。这里肯定会出现新的工具、新的机会。到那时候，美术不是瓶颈了，瓶颈会变成"你想让怪物用什么方式眨眼"。AI 教你写代码，你也得教它写代码。这场双向教学，没有终点。
夜雨聆风