AI工作流技巧—100%vibecoding完成gamejam

本文系用户投稿，不代表机核网观点
本文含有AI生成，请注意甄别
最近参加了 BOOOM jam，和艺术家弗兰克在 21 天内做了一个俯视角射击游戏《茫室》。游戏的核心机制是敌人在光照下无敌，玩家只能在阴影中击杀它们，主打一个预判杀敌战斗爽。欢迎在 itch.io 或机核网在线试玩我们的游戏。

这是我们首次 100% vibe coding 制作游戏，开发由我指挥 Cursor 和 Codex 生成代码，音乐音效靠 ElevenLabs AI 生成，美术和关卡都是 Frank 手工制作。这篇文章会介绍我在这次 jam 里使用 AI Agent 的具体案例：不仅包括如何在游戏开发中驾驭 Agent，也包括 Agent 如何改善团队协作。正式进入这些工作流之前，我想先用一些数据展示 Agent 带来的效率变化。
十倍工程效率，人也变得更忙
我参加过三次 BOOOM Jam，因为制作周期都接近 21 天，所以很适合通过代码量来对比工程效率。这次统计时，我只计算 Assets/Scripts 下的代码量，也就是排除插件后的项目代码，并用 Cursor 自带的 Canvas skill 生成了以下统计数据和图片。
这次在完全 vibe coding 的情况下，代码量增长确实十分可观，去年项目是 4 千行，今年 3.1 万行，相比 2022 年的 CATO 项目是十倍提升。我让 Agent 分析了这次代码库为什么那么大，大概是我这次抛弃了不少第三方插件，如 Top Down Engine，所以游戏最主要的逻辑——人物控制器还有敌人行为，都是靠 Agent 堆出来的，代码量自然就上去了。
这次项目后期的代码量增长甚至没有放缓，因为我全程在「边造车边开车边修车」。一年前我不可能有信心在倒数第二天边修 bug、边加新细节、然后让 Codex 跑 profiling 分析性能，毕竟对 game jam 来说，花时间解决优化问题简直太奢侈了。

从 Git Commit 提交数量的角度看，22 年和 25 年都在 400 次提交左右，今年有了 Agent 帮我写 commit 我养成了更勤快的提交习惯，结果是约 1000 次，毫无疑问，更加原子化的 commit 对 Agent 理解与维护项目更有帮助。
从番茄时钟数据来看，今年 gamejam 的实际投入时间在 100 小时左右，是去年时间投入的两倍。除了因为去年还在忙 CATO 的工作，今年这次 Agent 给予的正反馈实在太强，最后几天我亢奋到睡不着，一路干到凌晨五点，也算是 AI 让我更忙的证明。
虽然本文的大部分案例都来自这次 21 天的 game jam，但都依赖于我这半年来 vibe coding 积累的直觉与手感。我会尽量避开那些难以复现的震惊案例，更多分享一些真正能进入日常开发流程的方法。
市面上关于 Agent 写代码的技巧已经不少，所以接下来我想先从团队协作讲起，介绍在工程交接时，Agent 到底能帮我们省掉哪些体力活。
让 Agent 接手模糊转译
这几个月我们实践出了一套反直觉、但非常顺手的工作流，美术 Frank 在生产资产时，可以先用最自然、最啰嗦的方式命名文件，例如 Reload GUI 指示物开启.png、收集探测器成功的声音.wav。在合并 Frank 的资产时，我直接让 Agent 把它们重新规范命名，并移动到合适的文件夹目录下，甚至直接找到对应配置替换 reference。
这直接解决了几个很具体的问题：英文命名头疼、文件容易打错字、目录整理混乱、改配置时容易眼花。过去这些事都不难，但会持续打断开发节奏；现在它们可以被 Agent 串成一个完整流程处理掉。
我觉得这是一种模糊转译，而 Agent 相当擅长这类工作。如下图的换 UI 任务，我直接把 Frank 的 UI 资产发给 Codex，它完成了导入工程、重命名、替换场景中的 UI、修复错误，最后打包上传到我的手机，整个流程半小时不到，一站式完成。

游戏开发里，很多填写配置的工作，本质上也是一种转译：把人类自然语言写成机器能读取的结构化数据。
这次项目里有一些简单对白。一开始，Frank 只是把剧情对白写在 Notion 文档里。我让 Agent 直接读取 Notion，把对白转成游戏内配置；同时把文档里的立绘附图扒进工程，再根据对白中的人物注释决定显示哪张立绘。整个流程没有打开 Unity，也没有手动填写配置。

这种转译并不只适用于文档到配置，也可以是不同工具和数据格式之间。
到了游戏文本翻译阶段，我让 Agent 收集所有游戏内对白，包括分散的教学提示语，Agent 翻译后生成一个 Notion 对照表格，方便朋友 YangMann 直接校对。等校对完成后，再让 Agent 把修改后的内容从 Notion 倒回游戏配置。因为 game jam 的需求足够简单，通常这种场景会选择手动复制内容而不是使用专业本地化工具。而有了 Agent 转译，整个项目无需引入任何新插件，也不需要修改原本的数据格式。
我觉得游戏开发的大部份体力活其实都是在做数据搬运和转译，善用 Agent 可以减少这部份工作提高开发效率。相比于创造新内容，Agent 在这些体力活上的协助经常被忽视，但它恰恰很适合处理这些琐碎、重复，又需要一点注意力的工作。
让 Agent 串起工具
如果希望 Agent 参与到工作流，文档、素材、甚至聊天记录最好放在它能读取的开放工具里。否则 AI 再强，也只能停留在你手动复制给它的上下文里。所以这里推荐对 AI Agent 十分友好的 Notion 和 Dropbox。
合作了这么多年，如无必要我们基本没有看板和设计文档的习惯。但我们都会在开会后维护自己的 todo 或 checklist。Frank 作为美术，checklist 肯定会更偏视觉化。这次我尝试用 GPT Image 2 给 Frank 传递美术需求，先让 Codex 粗略整理游戏内的资产需求，等我校对完成后，再直接在 Codex 内调用 GPT Image 2，生成一张美术清单，用更清晰的方式传达需求。

在项目后期 BUG 和打磨细节激增，我只能靠不断修改 todo list 和纸上涂画来标记问题，我让 Agent 毫不费力地接通我的小票打印机，并写好 skill，可以把我的 todo 打印出来，对我来说，不看电子屏幕的 todo 也是一种降低脑负荷的效率提升方式。（这里推荐 Memobird 打印机，二次开发友好，打印纸也比较环保安全）
到了项目后期，BUG 和打磨细节激增，只靠 todo 小票已经有点不够用了。大部分口头需求都没有被结构化，很容易在聊天里溜走，根本来不及整理进 todo。最后冲刺几天，我用上了 Discrawl 这个 skill，让 Agent 可以读取我的 Discord 聊天记录，靠它帮我从聊天记录里扒出 Frank 提过的优化建议，避免漏掉任何工作细节。

Agent 提供看待数据的新视角
Agent 特别擅长找文件、找数据，也提供了一种看待数据的新视角。比如我要调整多个敌人的走路速度时，往往需要在多个 prefab 之间来回切换。重复劳动和数据过载叠在一起，眼花、配错数据都是常有的事。现在我会让 Agent 收集这些数据用表格呈现，全局宏观地对比调教这些数据。在我看来这极大提升了有效信息的信噪比。
gamejam 在做音效时，最头疼的就是上网找的音效音量不一致，这回直接让 Agent 做音频归一化就特别高效，根据我们的初步听感，我用 Cursor 去分析一番并生成 Canvas 图表，直接批量筛出不合格的音频，再根据筛选结果去继续打磨音频。

在项目协作时候，最头疼的就是 Unity Scene 冲突，用再贵的 git 客户端也读不懂 diff，因为 yaml diff 本身缺少语义化信息。Agent 完美解决这个问题，我最近习惯让 Agent 分析冲突原因，它便会用自然语言叙述，然后我再告诉它你要留下什么，丢掉什么，现在解决 scene 冲突的过程，有种做手术的快感。
解决场景冲突往往有个土办法，就是把场景复制一份，分开编辑，但真正头疼的是后续合并功能时，很容易错搬、漏搬。现在这类苦力活交给 Agent 就很合适，而且它还能顺手修复合并过程中导致的 reference 丢失。
让 Agent 接管 Git 里的脏活
除了上文所提的 Agent 解决 scene 合并冲突，开发全程我也让 Agent 帮忙不少 Git 操作。这次有了 Agent 帮我写 commit 我养成了更勤快的提交习惯，而且更加详细和原子化的 commit 对 Agent 理解与维护项目更有帮助。
Agent 像是一种可以用自然语言交互的 Git 客户端。合并 Frank 的美术内容时，我也懒得再手动操作，直接让 Agent 先叙述 Frank 新增了哪些资产、修改了哪些内容，再帮我完成合并和冲突处理。这招用来回忆自己上周做过什么也很好用，与其翻一堆 commit 和文件变动，不如直接让 Agent 总结最近的工作内容。
这次 jam 还遇到过一个渲染 bug。通常这种问题要用二分法，一步步夹逼出突然导致错误的 commit。有了 Agent 接管 git 操作，我只需要模糊描述大概出错的时间段，Agent 就能帮我跑 git bisect 逐步排查。我只负责在 Unity 里验证当前版本的渲染是否正常。三五轮下来，Agent 就能定位到出错的提交，并进一步修复问题。
我以前一直觉得 git worktree 在游戏开发里的作用不大，但这次 jam 做 WebGL build 时，它反而大大派上了用场。我直接让 Agent 在新的 worktree 里解决 WebGL shader 问题，并通过 Unity Batch Mode 编译 WebGL 版本自行验证。这样不会打断我当前的 Unity 编辑器进程，Agent 也能在另一个工作区里把问题闭环解决。

Deeplink：马看到什么是人决定的
半年前和 Agent 协作，还需在上下文提供修改文件的相对路径，而现在第一梯队的 Agent 已经能快速定位我的需求，比如「那个拿手枪敌人的脚本」。这可能归功于 continual learning，这次 gamejam 我做了个实验不再自己维护 AGENTS.md, 而是靠 Cursor 官方的 memory 插件：continual learning，让它自行理解我的游戏项目，保存我的设计偏好，效果似乎不错，它总能定位到我模糊描述的对象。
但 Agent 也有看不到的时候，通常因为相似实体过多不容易定位，比如场景有几十个敌人，每个敌人都有六七级深度的骨骼结构，当你要指定其中一个敌人的武器时就很难描述。所以我让 Agent 写了个 deeplink 功能，它可以选中若干 gameobject 复制其 GlobalObjectId，给 Agent 作为上下文，达到精确定位的目的。

这在 Agent 生成 prefab 时候尤为实用，对于层级复杂的 prefab 我会在场景搭出一个框架，使用 deeplink 给它指出关键 gameobject 的职责，再交由 Agent 补全剩余的内容生成脚本和 Prefab，这能解决 prefab 叫什么名字、放在哪里、脚本挂在哪、reference 需要手动拉等等烦恼。
编辑关卡时也有类似技巧。关卡中的元素往往更难定位，能复制物体的绝对 ID 给 Agent 指路就很重要。像 LDtk 这样的关卡编辑工具，就能方便地复制这类信息。
例如这次遇到一个需求，需要批量替换某个房间内的某类敌人。换以前，只能靠鼠标重复劳动，一个个手动替换。有了 Agent 之后，我直接拉了一张「网」把要替换的内容覆盖住，只需把网的 ID 传给 Agent 然后告诉它：把这张网覆盖到的敌人都替换成新的实体，同时把语义近似的属性也还原上。这个过程减少了不少重复劳动，也降低了人为出错的概率。

Unity MCP：Agent 闭环的关键
这半年来纯 vibe coding 最大的感受是，无论使用多顶尖的模型它都会犯错，避免的办法就是把它扔进可以自我验证的闭环之中，而 Unity MCP 就是让 Agent 闭环的关键。
我有一个 skill 叫 compile and fix，它会在所有代码改动之后，使用 Unity MCP run command 触发 Asset Refresh，等编译脚本完再 get console logs 检查所有错误日志修复，修复后还会进入 play mode 进行冒烟测试，重复这个过程直到没有错误为止。
当然，游戏逻辑验证还是比冒烟测试更难闭环。但对于游戏导出和打包来说，Agent 几乎就是完美的粘合剂。比如打安卓包时，Agent 甚至可以在手机上模拟点击，做一些基础冒烟测试；海量的手机运行日志对 Agent 来说也不是负担。
对于 iOS 打包来说，这更是解放双手，我全程没有打开过 Xcode。遇到 plist 问题，Agent 可以自己修复；部署到 iPhone 或上传 TestFlight，也没离开过 Cursor。

Debug Mode：拒绝盲猜
我一直离不开 Cursor 的原因之一，就是它强大的 Debug Mode。理论上，Debug Mode 也只是一种思路，靠 prompt 也能模拟出来；但 Cursor 把交互体验打磨得足够好，所以用起来特别顺手。
Cursor Debug Mode 的 prompt 里应该有类似「拒绝盲猜」的指令，因为我经常看到它这样行动，当我描述一个 bug 之后，它不会立刻凭空猜测并直接修复，而是先列出可能的假设，把 debug log 植入代码中，然后要求我去复现。等它拿到 log 之后，再根据证据分析问题并修复。
这个 Debug Mode 也适用于真机和正式包。过去最痛苦的是把设备日志取出来，再从里面筛出真正有效的错误信息；而现在 Cursor 可以通过 ssh 直接和我的 Steam Deck 形成闭环。我只需要在 Deck 上复现问题，剩下的日志分析和修复都交给它处理。
同样，Unity Editor 崩溃日志、Profiler 采样数据，也都可以作为输入交给 Agent。它可以从海量数据中提取有效信息，而不是靠直觉盲猜。这让我在 game jam 期间修复了一些极端 bug，甚至也完成了部分性能优化。

如果什么都要自己动手，说明动手能力不行
标题这句话，是 Agent 刚火时候流行的一句笑话，但在实践中，我确实也习惯了口头让 Agent 修改一个简单的参数而懒得动手。
在单独调整一个对象的时候，让 Agent 操作确实比不上直接编辑器手调，目前多少有点脱裤子放屁。但如果想在 runtime 批量操作一批实例化的 prefab，这种编辑的优势就很明显，而且还能随时让它批量应用回预置体，避免不小心退出 play mode 丢失 runtime 数值的事故，这招对实例化的材质调整也相当实用。
除了修改配置参数，我还探索了其它「动口不动手」的边界，比如完全让 Agent 搞定动画状态机。调整动画时候，我会把把「每次开枪从第一帧重播、结束后衔接 reload」类似这样的需求传达给 Agent，然后它根据我的设计意图翻译成状态机和过渡设置。我不指望未来 Agent 能完全接管我的 Animator，但这次 gamejam 的需求强度下我确实没打开操作过 Animator 意大利面。
在这里我也推荐使用 Cursor 的 Composer fast 模型。这类模型不太适合复杂任务，但指令执行速度快得惊人，很适合处理这种动口不动手的体力活。

放手让 Agent 做实验
Agent 让做实验的门槛大大降低，这次项目很多惊喜都是在休息时间实验出来的，我经常把低优先级需求扔给它不断试探边界。
以前 gamejam 会优先丢弃的 game juice 细节，现在居然有空加入最终打磨。例如这次 Agent 在 15 分钟内就把脚步声系统实现，而且还是双声道的，而这个系统又影响了游戏的 gameplay，激发了我们其它机制的设计。Agent 带来的效率提升，不只是省时间，也确实让整个作品变得更完整。
Frank 在做美术效果时候偶尔会需要 C# 脚本配合，这经常需要我们来回对齐功能与效果。现在 Frank 也可以借助 Agent 实验，直接让它生成一个粗糙但可运行的效果，我再接手优化脚本和性能。这大大增强了我们异步协作的能力。
对工具的不满也可以随时修改。后期我密集编辑关卡时，使用的关卡编辑器 LDtk 总有一些 quality of life 上的不便，于是我让 Agent 下载编辑器源码，直接优化功能来适应我的工作流。Agent 让使用开源工具这件事变得更有意义：不顺手就改到顺手。
我们甚至尝试让 AI 做关卡，毕竟 LDtk 的关卡不过就是 json 文件，丢给 Codex 工作了半小时后，结果十分惊喜，关卡没那么好看，但确实能玩，当然了这也是因为我们的战斗关卡摆放逻辑够简单，如果是解谜关卡它肯定无法搞定。

还有一个特别魔幻的例子。我 shader 知识很差，所以只能祈祷 Codex 帮我修复 WebGL 的渲染问题。它烧光了我好几次 5 小时额度，最后还真定位到了问题：一个 subshader 的版本兼容问题。只需要把一个 4.5 改成 3.5，渲染问题就全部消失了。
虽说和 Agent 协作当然不应该完全交出方向盘。但偶尔把一些低优先级、试错成本低的需求交给它自动驾驶，确实会获得一些意外惊喜。
ElevenLabs AI 音效生成
目前 game jam 版本的所有音乐和音效都由 ElevenLabs AI 生成。我直接把 ElevenLabs API 丢给 Codex，写下音效埋点需求，Codex 一站式完成，打开游戏就能体验。更意外的是，我在使用 ElevenLabs 生成音效时，不小心把 dark synth BGM 的需求混进了 AI 的 todo list，结果打开游戏后，竟然获得了一首非常有氛围的合成器 BGM。

由于我一开始限制 Codex 只生成音效，所以这首 BGM 其实只能通过音效 API 生成一段 10 秒的合成器音频循环。但结果相当惊喜，反而加强了游戏紧张刺激的氛围。这种 Aesthetic 层面的定调，又进一步引导我们打磨游戏机制和体验。不过就目前 AI 生成艺术资产的体验来说，它仍然更像抽卡，而不是稳定生产。
在以前 game jam 习惯中，我对音效的追求基本是能响就行，这次有 Agent 干体力活，我们花了更多时间打磨音效：比如给敌人加上脚步声双声道系统，BGM 在战斗中提升音量和低音，甚至有空把 AI 生成的 BGM 做出 intro / loop / outro 三段式响应。这些音效动效等等 game juice 的打磨，是 AI 赋予我们的奢侈。
AI 解决不了的：体验与美学
因为 AI 改变了开发节奏，这次我过于自信，拖了很晚才正式对接美术。前期工程推进有多顺利，后半程发现体验拼不起来时，就有多沮丧。AI 太擅长搭机制、做原型，以至于它让我产生一种无敌的幻觉。
从游戏的 MDA 理论来看，光有机制并不足以定义一款完整的游戏。Mechanics 只是起点，一个好游戏还包括 Dynamics 中不断浮现的体验，以及 Aesthetics 层面最终传达给玩家的美学、感受。
以前 MDA 理论都是拿来拆解别人的游戏，但这一次，我亲眼见到 Mechanics、Dynamics、Aesthetics 三元素是如何在我面前一点点组装、融合，并最终使作品完整，这也刷新了我们两人对 MDA 的认知。关于我们如何解决这一部分问题，欢迎阅读《茫室的美学与设计》（还没写完）。

结尾
《茫室》是我们首次彻底的 AI native 项目，回看过去一年 AI Agent 的变化，我发现自己丢掉了很多原本以为离不开的旧习惯。
在一年前我以为我会永远离不开 VS Code，为了让编码更顺手，我花过不少时间磨合插件、快捷键等等工作流；我也以为自己离不开维护多年的开发工具箱，那些工具不只是提高效率，也在一定程度上形成了我自己的游戏风格。
而在完全抛弃手写代码的这半年，我再也没打开过 IDE，工作时我面对的只有 Agent 的对话界面；压箱底的工具宝箱也完全放弃，更别提前年介绍的《CATO》使用的 20 款 Unity 插件已经丢掉了一半，全都被 Agent 的定制化能力解决。
写稿期间，AI Agent 的实时语音控制、电脑操作、自动测试能力还在继续进化，可以想象，未来 Agent 对游戏开发工程效率的提升还会更大。
但这次 game jam 也让我更确定另一件事，AI 改变的是生产效率，而非游戏质量本身。它能让机制更快跑起来，让资产更快进入项目，让 bug 更快暴露，也让很多低优先级的打磨有机会进入成品。但游戏最后是否成立，仍然要回到体验、审美、测试和人的判断。所以我喜欢 game jam，它给游戏制作提供了一个更早获得反馈的机会，人和 Agent 一样离不开闭环。
这也是我对游戏行业仍然有信心的地方。越是工程被加速，越能看清哪些东西不是单靠工程效率就能解决的。游戏的特别之处，也许正藏在这些暂时无法被 Agent 自动验证、也无法被指标完全量化的部分里。