如果你最近也在用AI做游戏估计你和我有同样的感受这个圈子的“版本答案”更新得比游戏版本还快。半年前大家还在讨论怎么用AI辅助写Unity的C#脚本三个月前风向变成了AI帮你策划需求、整包生成玩法现在你看各种游戏开发群里聊的已经变成“AI Agent怎么拆任务”“多AI协作怎么排管线”连“Godot还是Cocos”这种引擎选择题都开始往AI适配度上靠。这个变化很有意思我最近刚好把整套流程自己跑了一遍正好可以聊聊。这篇文章不跟你讲虚的也不做“未来展望”就是把最近我自己验证过的一套AI游戏开发工作流原样摊开引擎怎么选、Agent怎么拆、提示词怎么喂、AI写出来的代码怎么修以及最后怎么把一个原型落到微信小游戏上。适合谁看独立开发者、小团队、准备做微信小程序游戏的半路出家程序员还有想用更少人手接更多活的游戏公司打工人。如果你连Unity和引擎是啥都还没搞清也能看我会尽量把为什么选这个、为什么那样写讲明白。1. “版本答案”又变了AI游戏开发到底进入了哪个阶段1.1 版本1.0时代AI只是个加强版搜索引擎先说个暴露年龄的事。我第一次拿AI做游戏是让它帮我写一个“鼠标跟随物体旋转”的函数。那时候AI的定位非常明确当搜索引擎用。不会查文档就去问AIAI给你一段函数你复制进工程能跑就算赢。这个阶段里游戏开发的主体还是人AI只是帮你节省了翻API文档、逛技术论坛的时间。说白了你问的问题越具体AI给的答案越靠谱你要是问“帮我做个游戏”它顶多给你一个控制台里跑的猜数字。这个阶段的核心价值是把“查找资料”这件事自动化了。它对游戏开发的改变是有的但远没有到“重写生产流程”的程度。大多数人用完AI之后还是会按照老路径去搭项目人定玩法、人写系统、人调美术。1.2 版本2.0时代AI成了结对程序员但人还在当“总监”大概从大模型编程能力变得能用开始工作流进入了2.0AI不再只是帮查资料而是直接坐在你旁边当一个永远不摸鱼的结对程序员。你在IDE里装个AI插件写代码时它会自动补全遇到不会的函数描述一下它就能生成你干的是“拆需求、审代码、修报错”的活。这个阶段最明显的特点就是个人开发者的产能一下子被拉上来了。我以前做一个微信小游戏光功能代码就要写两三天保险起见测试还得留一天用上AI之后一个下午就能把核心玩法的代码撸完剩下的时间基本花在改UI和对需求上。很多人觉得“AI游戏开发”就是从这里开始的但实际上这套流程依然是人主导AI写代码人做结构决策。1.3 版本3.0时代AI Agent开始排流程人退到导演位最近这轮变化才是真正让我觉得“版本答案”变了的核心原因。AI从“写代码的辅助”升级成了“排流程的Agent”它可以自己拆任务、调用工具、按顺序执行多步操作甚至多个AI之间还能互相协作。举个例子以前做一个接金币小游戏我得自己把需求拆成玩法设计、角色控制、碰撞检测、计分逻辑、UI显示、结束条件然后一项一项让AI写。现在你可以让一个“策划Agent”先把设计文档写出来再让“代码Agent”照着文档写代码让“测试Agent”跑冒烟清单最后把报错结果反馈给前面的Agent修改。人在这里面的角色更像导演而不是流水线工人。所以“版本答案又变了”这句话我的理解是最优工作流已经从“人选工具人指挥AI”变成了“AI编排管线人验证方向”。工具仍然是那些工具但用法完全不一样了。2. 引擎选型被重写Godot、Cocos还是Unity答案要看AI2.1 怎么判断一个引擎适不适合AI辅助开发以前选引擎大家看的是生态、招人难度、全平台支持、商店素材。但在AI辅助开发时代有一个很容易被忽略的新变量这个引擎的代码和知识AI到底学得够不够多、生成出来的代码能不能直接用。你可以把大模型想象成一个读过海量资料的实习生。它写C#和TypeScript是因为网上Unity和Cocos的代码、教程、问答太多了它写GDScript虽然资料少一些但语法简单模型反而容易写出结构正确的代码。反过来如果一个引擎特别冷门它的API在AI训练数据里出现得少AI生成的代码就会经常出现“看起来合理、跑起来报错”的离谱情况。所以我判断一个引擎适不适合AI辅助开发只看三件事文档和社区资料是否足够多脚本语言是否简洁且模型熟悉以及引擎的工程文件是否容易被AI理解和写入。按这个标准Godot和Cocos是目前最靠前的两个选择Unity是“还行但包体和商业许可争议让人犹豫”其他一些商业引擎则要看团队是否已经有固化的工作流否则从AI适配度上说并不划算。2.2 Godot的优势与坑免费、轻量、AI写GDScript很顺手先说说我为什么对Godot评价这么高。第一它完全免费且开源没有版税、没有商业门槛这对独立开发者和想做免费商用小游戏的人来说非常友好。第二编辑器本身很轻电脑配置一般也能流畅跑打开一个项目只需几秒钟特别适合AI辅助时反复迭代试错。最关键的一点是GDScript的语法贴近Python结构非常直观。AI天生擅长生成这类“缩进表达逻辑”的代码写出来的东西可读性极高。而且Godot的场景文件也是纯文本的.tscn格式这意味着AI不仅能帮你写脚本连场景节点、资源引用、动画配置等都能通过文本形式生成和修改。这一点Cocos也能做到一部分但Godot的文本化程度更彻底。当然坑也不是没有。如果你要把Godot做的游戏发到微信小游戏平台官方并没有一键导出方案需要借助Web导出再加小游戏适配层来跑流程比Cocos麻烦。另外国内中文社区的教程虽然这几年多了很多但和Cocos这种“微信小游戏亲儿子”比起来还是偏少。如果你想做重3D项目Godot的资产管线也比Unity成熟度低需要自己踩更多的坑。2.3 Cocos的优势与坑TypeScript语料足小游戏生态稳再聊Cocos。Cocos Creator在国内最大的优势就是微信小游戏生态做得最强。官方提供了非常顺滑的小游戏发布通道从构建到预览到真机调试几乎不需要绕路。游戏开发中那些烦人的登录、支付、分享、开放数据域接口Cocos都有现成模块这在AI辅助时代等于省掉了一堆“让AI去猜平台API”的麻烦。脚本语言用的是TypeScript这也是AI训练数据里的大头。实测下来你让AI写一个Cocos组件只要提示词里写清楚“Cocos Creator 3.x TypeScript”它生成的代码基本能直接跑通需要修的通常只是节点路径和资源生命周期这类细节。而且国内社区沉淀了大量问题记录AI在回答Cocos相关问题时语料质量明显比一些冷门引擎高。但Cocos也有让人头疼的地方。它是商业闭源引擎免费商用有一些条款限制虽然个人小游戏基本碰不到付费门槛但你要是想改引擎底层行为就只能憋着。还有一点Cocos的API版本迭代非常快Creator 2.x和3.x的写法差异极大AI如果不小心背了老版本的接口代码一贴就是一片红色报错。2.4 只做微信小游戏我的选择如果你的目标很明确——只上线微信小游戏不打算以后迁移到Steam或者PC也不想折腾奇奇怪怪的适配流程那我建议直接用Cocos Creator。原因很简单官方支持就是最大的省心AI生成代码 官方一键构建 微信开发者工具调试整条链路最短踩坑最少。但如果你想要的不是“只做一个能上线的游戏”而是“快速做一堆原型验证手感顺便跑全平台”那Godot更适合你。它免费开源、轻量快速、AI生成代码质量高做完一个原型再决定要不要搬到Cocos是更高效的做法。Unity也可以做只是对小游戏赛道来说包体和授权问题会拖后腿。我给一个比较实用的组合思路用Godot做玩法原型AI帮你快速验证十几个点子哪个好玩再花时间用Cocos做正式的小游戏版本。这样既吃到了Godot的AI红利又不用在小游戏发布环节硬刚适配层。我个人现在跑的就是这套流程。3. 多AI协作工作流把游戏开发拆成一条Agent流水线3.1 为什么单个AI聊着聊着就崩了很多人的习惯是开一个AI对话窗口往里面疯狂贴需求让AI又当策划又当程序又当美术。结果就是聊到后面AI开始忘上下文你让它改计分逻辑它把之前的碰撞代码顺便改坏你让它输出场景文件它输出了另一套风格。这不是AI变笨了而是单个会话的上下文窗口撑不住整个游戏工程的信息量。我后来学乖了与其让一个AI干所有事不如把项目拆成多个AI角色每个角色只负责一个窄范围的任务。它们之间通过文档和文件来通信就像真实团队里的策划、程序、美术靠需求文档对齐一样。这就是多AI协作的核心思路也是我要说的“Agent流水线”。3.2 策划Agent的提示词模板先拿设计文档第一个要设的Agent是策划。别上来就写代码先把玩法设计对齐。我常用的提示词模板是这样的你是一名休闲小游戏策划经验丰富。请根据以下需求输出一页纸设计文档包含玩法一句话描述、核心循环、3个关键系统、数据字段表、失败与成功状态、新手引导建议。不要写数值成长细节不要展开商业系统保持每个部分不超过200字。需求一个接金币小游戏玩家控制碗接住从天上掉落的金币接不到会扣命扣完三次游戏结束。为什么要写成这样第一限定了角色AI不会跑偏成“万能专家”第二限定了输出结构每一部分都有明确边界方便后续其他Agent阅读第三明确了“不要什么”这比说“要什么”更重要。AI是话痨你不限制它能给你写出四千字世界观设定对做游戏原型一点用都没有。3.3 代码Agent怎么写版本和约束一起写进提示词拿到设计文档之后再开一个新的对话窗口写代码Agent。注意必须新开会话不能让策划Agent和代码Agent共享同一个上下文否则AI会为了“保持风格一致性”干出奇奇怪怪的事。我常用的代码提示词模板你是Godot 4.3专家请用GDScript实现以下需求玩家通过左右方向键控制碗移动碗使用CharacterBody2D移动速度500屏幕边界限制。金币从屏幕顶部掉落使用Area2D检测与碗的碰撞接到金币加分并播放音效。掉落出屏幕底部则扣除一条命命数归零时切换结束界面。要求核心逻辑写在player.gd和coin.gd两个文件里公共参数用export关键逻辑加中文注释。先输出完整代码再附上1分钟自测清单。这里最关键的是开头那句“你是Godot 4.3专家”。版本号一定要写具体因为Godot 3和4的API差别大到AI自己也容易搞混Cocos的2.x和3.x同理。第二个关键是“先输出完整代码再附上自测清单”这能逼AI在你动手前先自查一遍实测能减少一半的低级报错。3.4 美术与音频Agent生成之后必须人工把关游戏不只有代码还有美术和音频。现在的AI图片生成能力大家都有目共睹一张效果图直接扔给文生图模型就能出角色立绘、UI素材、背景图。文生图原理说起来也不复杂扩散模型先给纯噪声图片逐步去噪再用文本提示词约束方向最后生成一张符合描述的图。生成时最忌讳的是上来就喊“画一个游戏背景”你要给这个模型更具体的规格。我常用的美术Agent提示词模板生成2D游戏UI图标风格为扁平卡通风主题是金色硬币画布512x512透明背景主体居中不要加文字和边框。色板以金色、黄色、深棕为主光源从左上方来风格参考休闲手机游戏。输出之后除非你只是做内部原型否则不要直接拿去商用。AI图片模型用的底模有一套训练数据里面可能夹着不明确的版权信息商用之前要确认模型的授权条款或者选用明确允许商用的模型。音频也一样可以用AI生成简单的音效和背景音乐但涉及空间化音效、立体声定位这种操作时小游戏里用左右声道的pan值加音量衰减就能模拟个七七八八没必要一上来就上复杂方案。3.5 测试Agent让AI自己找自己写的bug很多人忽略测试环节觉得有AI写代码就不需要测试了。实际上AI写的代码bug率并不低尤其是逻辑边界、资源释放、生命周期这些环节。我的做法是再加一个测试Agent给它明确的输入项目目标、关键文件的代码、自测清单。然后让它输出一份“冒烟测试清单”并逐项打勾。这个方法听着简单但效果非常明显。AI自己写的代码让它自己挑毛病往往能发现一些你根本没注意到的细节比如碗的移动速度在低帧率手机上会显得飘金币生成间隔没做随机导致节奏机械又或者结束画面出现时玩家还能继续移动角色。这些细节正好是游戏手感好坏的关键测试Agent能帮你省掉大量“真机试玩才能发现”的时间。4. 手把手演示用AI从零做“接金币”微信小游戏原型4.1 环境准备和路线选择我挑了“接金币”这个玩法来演示不是因为高档而是因为足够小、逻辑闭环完整适合讲清楚整套工作流。环境准备如下表工具用途说明Godot 4.3快速做原型免费、文本场景文件、AI生成友好Cocos Creator 3.8微信小游戏正式构建官方一键发布TypeScript生成AI编程工具生成代码和文档代码能力强的大模型即可微信开发者工具预览、调试小游戏接收Cocos构建产物文生图工具生成金币、背景、UI图标确认商用授权路线很简单先用Godot把玩法跑通、手感调舒服然后对照同等逻辑用Cocos Creator实现一遍最后直接构建发布微信小游戏。如果时间紧也可以直接用Cocos从零做只是我在原型阶段更喜欢Godot的速度。4.2 第一步生成设计文档把第3章里的策划Agent提示词原样跑一遍AI输出了一份简短设计文档我挑重点说玩法一句话是“控制碗接金币三命一局”核心循环是“金币下落、玩家移动、接取加分、漏掉扣命”三个关键系统是碗的移动系统、金币生成与碰撞系统、生命计分与结束系统。这个文档不用特别细致够代码Agent看懂就行。我当时故意没有让它写数值因为数值一定是要靠实际试玩去调的策划文档里写再精确都是纸上谈兵。真正跑起来之后你会发现碗的移动速度、金币下落速度、金币大小这几个参数直接决定游戏好不好玩不试不知道。4.3 第二步AI写核心玩法代码把代码Agent的提示词模板发给AI它会返回类似下面的GDScript。我简化一下核心部分你感受一下AI生成代码的质量extends CharacterBody2D export var move_speed: float 500.0 export var screen_margin: float 50.0 func _physics_process(delta: float) - void: var direction : Input.get_axis(ui_left, ui_right) velocity.x direction * move_speed move_and_slide() var viewport_width : get_viewport_rect().size.x global_position.x clamp(global_position.x, screen_margin, viewport_width - screen_margin)这段代码直接放进去基本就能跑。但注意两个问题第一AI默认用了Input.get_axis(ui_left, ui_right)这个对应的是Godot内置的输入映射如果你的项目没配置这两个动作方向键是没反应的第二screen_margin这种边界限制是AI自己加的说明它确实理解“碗不能飞出屏幕”的需求。金币部分AI用了Area2D加碰撞检测大概长这样extends Area2D export var fall_speed: float 120.0 func _physics_process(delta: float) - void: position.y fall_speed * delta if position.y get_viewport_rect().size.y 50: queue_free() GameEvents.life_lost.emit()这里有个小坑是AI很容易把“金币飞出屏幕”和“金币被碗接到”两种情况的信号混在一起。我第一次跑的时候金币飞出屏幕后扣命计数被触发了两次因为Area2D的body_entered信号在金币与碗分离瞬间又被检测了一次。后来我让测试Agent检查很快定位到是缺了一个状态标记加一行if already_counted: return就解决了。4.4 第三步AI处理场景与UI场景文件方面我建议别让AI直接生成整个.tscn至少在项目初期先手动搭一个最小场景让AI只管脚本。为什么AI生成的.tscn里资源路径、节点ID、内置属性经常和你的项目对不上一旦引用错误场景加载会直接黑屏。而手动搭场景只花几分钟核心玩法脚本却是最花时间的把AI的算力用在刀刃上。UI部分倒是可以让AI多出力。比如让AI生成一个简单HUD脚本负责显示当前得分和剩余生命再让它把结束画面用一个CanvasLayer节点挂上。这类UI逻辑模板化很强AI写得又快又稳。我唯一要人工改的地方是字体资源小游戏环境里字体和渲染适配比PC复杂AI并不知道你的运行环境所以我会自己指定一个内置字体路径。4.5 第四步从原型到微信小游戏这是最容易翻车的环节。Godot目前没有官方微信小游戏导出方案要发到微信一般是先用Godot导出WebAssembly再通过社区适配层把Web包塞进小游戏容器。这条路能跑但初始化时间、包体积、兼容性都要额外花精力处理。所以我才说如果你的主战场就是微信小游戏正式版请用Cocos Creator。用Cocos发布微信小游戏的流程会顺很多安装Cocos Creator从编辑器顶部菜单打开“构建发布”面板平台选“微信小游戏”填好小游戏AppID点构建。构建产物直接出现在项目目录的build文件夹里再用微信开发者工具打开该目录就能调试。AI在这里能做的就是帮你把Cocos版的组件代码写出来比如用input事件监听左右滑动用instantiate动态生成金币预制体。你把“Godot版逻辑”翻译成“Cocos版代码”交给AI它基本能完成80%的翻译工作剩下的替换节点引用、挂组件属于体力活。4.6 小游戏性能和包体优化微信小游戏有个硬性指标首包不能太大启动要够快。Cocos构建时可以把用不到的引擎模块关掉纹理压缩选WebPUI图片能合图的就合图。按我的经验一个接金币这类轻度休闲游戏Cocos构建出来的首包控制在500KB以内没有压力。Godot的Wasm包通常就大一些这也是我不建议正式包用Godot硬扛小游戏的原因之一。另一个优化点是代码里的“每帧获取节点”。AI生成代码时为了可读性经常会写这类操作在小游戏这种CPU相对弱鸡的环境里就是卡顿元凶。建议在提示词里直接加一句“性能敏感代码避免每帧重复获取节点请使用onready缓存引用”。AI听得懂这句话生成出来的代码性能会好很多。5. AI游戏开发常见问题与避坑实录5.1 AI写的代码“黑盒化”结构越来越乱先说你一定会遇到的情况AI生成的每个文件都挺像模像样但整个工程越来越乱。它可能会把一个几千行的单文件扔给你也可能在五个文件里重复定义了同一个常量。这种问题不是靠“让AI更聪明”能解决的而是靠约束。我现在的做法是在项目开始时就让AI写一个“技术结构说明文档”把目录规划、每个文件的职责、模块之间的依赖关系一次性定下来后续每个新功能的提示词里都带上这个文档的摘要。AI有了边界之后乱扩展的概率会低很多。5.2 报错日志太长AI上下文被撑爆AI写代码最常用到的场景是修bug但很多人会把几百行报错日志一股脑扔给AI结果AI读日志读到一半就开始胡说八道甚至把本来正确的代码也一起改坏。报错日志不是越长越好要学会“提纯”。把错误类型、出错文件、行号、关键描述复制出来就够了一句话最多两行剩下的让AI关注你描述的行为表现。如果项目聊太久导致AI忘了之前的约定不要犹豫新开会话。新会话里把“项目背景、目标、当前文件路径、具体报错”四项写清楚AI基本能无缝接上。你可以把它当成新入职的程序员交接给他工作的第一件事就是写清上下文而不是让他读你的聊天记录。5.3 素材版权与平台审核风险AI生成图片、音频都给游戏制作带来了很大便利但商用之前必须检查授权。底模训练数据里的版权问题不同平台、不同模型的处理方式不一样有的明确允许商用有的只允许学习研究。建议优先选择条款明确允许商用的模型不要图省事直接用来路不明的整合包。微信平台对内容本身也有审核要求AI生成素材要注意内容边界别踩雷区把控好游戏素材的合规性。5.4 API版本错位AI背老手册的记忆太深这个问题在Godot和Cocos上都常见。Godot 3.x和4.x的API变化大AI有时会把KinematicBody2D这种老写法直接生成出来给你制造一堆不必要的工作。Cocos 2.x和3.x的差异也很大。我的解决办法是每次提示词都写清楚版本号并且开头第一句就执行“你是XX版本专家”的角色设定。还有一个土办法就是把引擎官方示例代码片段复制给AI当参考让它照着示例的API风格写。AI有现成范本之后代码质量能提升一个档次。5.5 性能陷阱看起来优雅的代码其实很慢AI写代码有个习惯追求“清晰”胜过“性能”。每帧调用get_node找节点、每帧新建临时数组、把不需要跨帧保存的数据强行封装成对象这些代码在PC上跑起来毫无压力可一旦放到微信小游戏的移动环境里就是掉帧卡顿的来源。我整理了一个简单的对照你自己体会一下# 不推荐每帧都在找节点 func _process(delta): $HUD/ScoreLabel.text str(score) # 推荐缓存节点引用 onready var score_label: Label $HUD/ScoreLabel func _process(delta): score_label.text str(score)这种优化在AI辅助开发时特别容易做因为你在提示词里加一句约束就够了“关键节点请使用onready缓存不要在_process里重复获取。”AI会照做而且它不会嫌你要求多。关于AI游戏开发我目前最深的体会是工具换了一茬又一茬但“谁掌握流程编排谁就掌握效率”这件事没变。今天你用Godot加AI能三天跑完三个原型明天微信多了一个新玩法后天又冒出一个新的AI能力唯一不变的是你能不能让AI按你的想法干活。我自己的习惯是每个阶段都用AI快速做一个小而完整的原型从策划到代码再到测试逼着自己把整条Agent流水线练熟。这套流程看着简单真正跑顺之后你就会理解“版本答案变了”这句话的分量。