我的文章目录

前言

虽然 Vibe Coding 已经不是什么新鲜词了，但目前网上的案例大多集中在 Web 和 App 领域，游戏圈里的深度分享相对少一些。

我早几年就尝试过把 AI 引入工作流，但当时的工具链实在太难用，工具调用什么的经常失灵，综合效率甚至比不上去对话框里手动复制粘贴。但最近半年重新尝试后，我发现现在的模型能力在工程环境下已经可以出活了，能帮我解决掉大量繁琐的杂活。这篇分享只讲我一些经验，以及它到底怎么帮我省下的时间。

警告：我目前是一个人在做独立游戏，因此会存在大量欺师灭祖的操作，很多东西是完全自己怎么爽怎么来，很多操作公司里大概是不让搞的。另外如有谬误欢迎指正。

用到的工具和一些环境配置

我用的IDE是Rider，然后AI用的是Kilo Code插件+重活gemini+轻活GLM。当然，IDE无所谓，VSC也一样，用Rider主要是因为引擎用的UE。

Kilo：主流的Claude Code和CodeX什么的我当然也都用过，主要还是Kilo开源免费（当然API不是免费的）而且定制起来更加简单一些。而且我用的是IDE插件版本，不是CLI，主要是因为插件的集成度会比CLI要好一些，比如可以很简单的在IDE里跳转。

Gemini：一般Gemini用来做策划和一些需要较大上下文任务，最开始的时候我用GLM做策划，后来发现不太行，指令遵循有点太强了，缺乏策划应该有的脑洞，换到了Gemini之后发现emmmm好像都不太行，但Gemini胜在上下文大，可以直接让他用浏览器借（huan）鉴（pi）其他游戏的资料，GLM很容易就爆了。

GLM：GLM就负责把文档翻译成脚本，或者脚本翻译成文档，因为我随时都有可能修改两者，而它就是用来处理这种简单的脏活累活，而且这种活由于上下文充裕且明确可以说成功率非常高。这样我就可以在一个时间只专注于一件事情，同时还可以避免诸如“文档，注释，代码命名，代码功能各说各的”这种事。用它主要是因为便宜的多，在我小半年的提示词迭代下+精细控制上下文的情况下他已经可以胜任了，当然更详尽的提示词配合opus4.5等更强的模型，用起来也确实会比GLM更加省心（自主能力更强，嘴遁次数少）一点（当然也贵的多，一个小时干掉几十块常有）。

MCP我只配了playwright和一个计算器，拿来操作浏览器查资料和处理一些简单的数学计算（毕竟众所周知大模型不会算数也不会数数），别的大多也都用不太上，还会白占上下文。

自定义的Agent我只做了一个主策划，大多数时候已经够用了，主策用来设计系统，创建表头，填表等等等等，最开始我还做了个数值策划用来调数据，后来发现直接做成主策的SKill就可以了，多出来个Agent完全没必要。

表格和文档一律使用MarkDown，当然我知道在国内游戏开发有很多奇怪的路径依赖，比如Excel导表，然后写成吨成吨的导入导出插件来尽可能的让策划不写代码，成吨成吨的枚举等等，甚至在Excel里写lua等各种匪夷所思的操作。但对于当下的AI来说，这一大堆流程其实都可以砍掉了，具体流程后面会讲，而且Excel和Word这些办公软件都太重了，装个Skill支持Excel可能并不如直接修改MD来的简单快捷。

至于画流程图这种，绝大多数MarkDown渲染器都支持Mermaid和PlantUML以及LaTeX，AI可以把这些写好，但大多数时候AI并不会主动写这些，需要在提示词中提及，如果不提及的话AI大概就不会用他们，而且我们完全不用学习如何写这些，只需要看写出来的结果对不对就可以了，并且AI也可以理解对应的结构化文本。

这样下来，嘴遁的时候完全不需要离开IDE了。

主要工作流程

策划先行，单一系统

如果最开始跟AI说那种一句话需求，你比方说：“给我写个RPG游戏策划案，要二次元的”，结果一定是叽里呱啦喷出来一大堆似是而非的东西，咋一看挺好，但细看会发现什么都没说，所有的内容都会处于一种流于形式的状态。虽然这个案子直接给程序Agent一样可以产出一些东西，但一定会把屎山开局就堆得很高，以至于后续完全无法维护。

所以我的经验是，最开始先从单一核心系统开始，而不是直接设计整个架构。

在这里引用猴叔打过的一个比方，一个游戏好比是一家医院，我们一次关注构建的系统只仅仅是一个科室，然后不同的科室通过一些“小纸条”链接起来，比如耳鼻喉科需要拍片子就给患者一个小纸条，凭此小纸条就可以去影像科拍片子了，这些不同的科室功能组合起来成为了一个医院。

而游戏呢，移动系统处理移动的时候发生了碰撞，经过检查发现是子弹命中了玩家，这种时候我们就可以提交一个小纸条给伤害系统，各种不同的系统组合起来成为了一个游戏。

当我们制作的时候先从单一系统开始，比如我们在设计移动系统（碰撞，挤开，沿边滑动等）是完全不考虑伤害系统的，也就是俗称的解耦，软件工程学同样适用于AI。

设计的时候遵循ECS架构，这种结构对游戏逻辑非常友好，至于具体细节可以看我另一篇文章开发杂谈:在UE5使用ECS驱动游戏逻辑，这里不再赘述架构细节。

如何抽象?

我在与一些朋友交流的时候会发现，有些时候我们会知道这个系统的功能，比如移动系统，显然移动系统是处理移动的，但是代码怎么写，抽象不出来怎么办？（虽然我从来没有过这种困惑，我一般读完需求脑子里自动出现流程图）根据我与朋友们的交流在这里可以分享一些经验，如何思考和抽象：

针对游戏场景，我们最常见的一种情况就是Tick，说人话就是这一帧应该做什么，就比如还是最简单的移动系统，这种时候先考虑我一般会先考虑数据结构，也就是处理移动的时候通常需要哪些数据，或者说哪些数据很明显是跟移动相关的，此时我们可以拍脑袋即答：位置和速度，而且功能也可以具体化为这一帧的位置通常可以根据上一帧的速度和位置计算出来。这里我们简单的判定速度和位置是两个向量，那直接创建一个结构体就好了，它就是Component，然后System就一行location+=velocity*delta，这样一个单一核心系统就做好了。

没错，刚开始就是可以这么简单的，完全不需要考虑其他，因为软件肯定是要迭代维护的，后面一定会再加东西，比如加速度，角速度，质量等，然后就是初中物理知识，我相信大家都会，绝大多数Gameplay代码都只需要计算这些初中内容就可以了。

函数作为类的数据(委托,Lambda etc.),而不是类的功能(成员函数)

但软件开发还有一种情况比较特殊，就是函数。比如有一种情况，有一种角色buff每走10米恢复1HP（你怎么知道我最近在玩海克斯大乱斗）。很明显，这时移动跟一大堆东西耦合起来了，这种情况我直接讲最佳实践吧，就是在MovementComponent中添加一个多播委托OnMove，函数参数为角色实体和一个float delta（也就是当前这一帧移动了多少）在移动完成的时候广播这个委托，然后buff被添加的时候直接给这个多播委托绑定一个函数，函数的功能就是根据移动直接加血，buff被移除的时候删掉这个绑定。这样就等效于，buff系统侵入式的修改了移动系统的处理流程，但不影响移动系统的逻辑干净程度，也就是开洞，因为在移动系统的视角，我只是在移动完成的时候广播通知我移动了，至于我移动了会造成什么影响，移动系统并不关心。

表头怎么设计

通常做完一个单一功能的运行时系统之后，就可以上手设计对应的表头了，一般表头可以直接从上述数据结构中提取出来，如何分辨也非常简单，不是运行时特有的数据基本就可以判定为填表数据，比如当前的血量肯定不是填表数据，这个一定是根据运行时环境计算出来的，而升一级加多少血就是填表数据。

表结构一般来讲是分两种，一种我通常称之为二维表，显然就是Excel那种形式，另一种我大概会称之为json表或者XML表，区别就是填写各种各样的字段或者说键值对，而不是二维的形式。一般来讲第二种形式的表达能力会比单纯的Excel强很多，可以设计层次结构还可以塞数组（但好像大多数策划都不喜欢配json）

但这些现在来看都有点拘于形式了，完全没有必要再像之前一样拉表，我们可以用更直接的方式，直接使用编程语言创建一个结构体实例然后直接指定对应的变量值，最后作为常量存放到一个单例里，OK，这就是填表数据了，本质的作用跟之前一样的同时表达能力最强，可以直接绑委托可以直接写算式甚至还能吃到编译期优化，AI和人用起来都更顺手。

而且这跟编程语言是无关的，至于Lua，C#，还是TS什么都可以（我用的C++），AI都能写，而且直接写代码的话上下文也会更加精准，AI可以直接搜索函数引用等等等等。

但是编程语言，又有一些太自由了，AI随随便便就给你胡乱继承组合那么几次就会导致屎山再次喷发，或者创建那么百八十个枚举（这些习惯都从哪学的），所以在配表这一环节是禁止AI创建新的结构体新的类的，只能在一些地方（比如游戏启动的时候初始化的时候）创建类的对象或者结构体的实例，然后对这些对象和实例进行修改后存为填表数据。

题外话：但其实本来资深策划就都是会写代码的（尽管我认为只要是策划就应该会写），之前的方案大多更像是一种为了让那些不会写代码的策划也能工作，但现在策划的想法与实际落地的编程之间的鸿沟已经被AI抹掉了很多，这些流程都可以砍掉了，只需要看AI写的对不对就可以，甚至在严格规定写法+提供样例的情况下AI几乎不会配错（我目前在这套流程下AI几乎没怎么看见配错的情况了），连着一步都可以省掉。

填表又怎么填？先做多，再精简

这一步很多时候我喜欢叫“拍脑袋”环节，AI也可以在这一方面进行加速。

一般我的流程是先直接让AI写文档，AI很容易就喷出来一堆乱七八糟的东西，而且会有大量的模糊地带，比如他会写XX技能的效果是让目标受到电击，让目标感电，等等等等，但AI不会写感电是什么效果，被电了是不能攻击不能移动还是什么，都有什么区别完全没有。

这种情况我会直接不管，先让AI继续喷射，比如先让AI做100个敌人，要求多样化。等AI喷射结束大概扫一眼删掉那些明显有问题的，然后让AI逐个词条进行详细设计，并且分门别类，去除重复的，注意一点在分门别类和去除重复的时候一定要给样例，不可重复逼供，不然AI一定会原地打转，他会认为自己设计的完美无缺，然后列出一项项成果给自己打出五星评价。

就拿LOL举例子，击飞和眩晕这两个buff的区别就是击飞不能解除，也就意味着比如有一个bool变量bCanCleanse的值这两个buff一定是不一样的，这样AI才会往对应的方向思考，并真正有效的迭代文档。

等文档精确度达到一定水平，就可以将其翻译为代码了，再接下来就是反复迭代的工作了。

这样下来综合效率确实比之前要高不少，因为我很喜欢拍脑袋，然后做出来玩发现不满意又删掉，而且还喜欢拖延，曾经一个月就憋出来三四个敌人（不包含美术资源），导致我之前的开发效率很低，后来尝试工作流接入AI，一个星期就做了20多个敌人（中途抛弃的恐怕得有几百个），然后心安理得的玩了半个多月游戏，即便如此综合效率依然可以说翻倍。

AI提示词迭代

好用的工具肯定是迭代出来的，任务完结的时候，我经常会根据我不爽的地方修改提示，目前发现最管用的方案就是提供样例，曾经我尝试过让AI自己根据任务历史修改提示词的方法让AI自动迭代，但是很快就会发现AI并不能从中吸取错误，而且还会让提示词重复一些废话浪费上下文，我推测是AI其实对任务的实际目标缺乏方向感（毕竟只是一个上下文匹配机），所以这一步还是得人来做。

美术资产制作？

todo：

原文发表于知乎。