当AI遇上游戏开发，一场关于控制权与创造力的博弈正在上演。一位3A大厂地编人员尝试用AI工具链开发独立游戏，却陷入技术黑箱与创作失控的困境。本文通过UE5实际案例，揭示AI在游戏开发中的能力边界——从结构体识别盲区到节奏感缺失，从协作区划分到禁区警示，为创作者提供一份避开AI陷阱的实战指南。
前几天半夜十一点多，一个 3A 游戏公司做地编的朋友突然找我，跟我聊他自己的 UE5 项目。
他白天在大厂里摆场景、调灯光、拼素材。晚上想做一个自己的 FPS 线性解谜游戏。原本规划的是 CRPG，已经精简到这了，他说后续还得继续减，不然做不出来。
他用字节的 Trae，通过 MCP 接 UE5.5。文件能遍历，但大部分 structure 读不到。AI 全给他写 C++。他原话：”我 Python 都用得半拉柯基，C++ 细节怎么调？”
他研究 UE5 外部 vibecoding 一个礼拜了。问我：”不知道 Claude 是不是能解决全部问题啊。”
我也不知道。但我半年前从数据开发转 AI 产品经理，这段时间反复跟 AI 测边界，能告诉他的是：第一个项目这么干，大概率死。
朋友说，就算这个游戏半拉柯基做完了，对他来说也是个黑箱。优化、迁移到其他平台、改 Bug，全得交给 AI 托管。
“我连自己写的东西都看不懂，这还是我的游戏吗？”
游戏不是一锤子买卖。你做完了得调手感，得适配，得改 Bug。代码全是 AI 写的、你自己看不懂的话，AI 一抽风，项目就废了——而 AI 抽风是经常的事。
这个问题不是技术问题，是项目生命周期的问题。
他之前已经有过几次 0 到 0.几 死掉的经历——定位不明，技术力和需求差距过大。这次他想用 AI 抹平那个差距。但 AI 抹平的不是差距，是控制权。
更现实的一层是时间。他研究怎么给 UE5 架外部 vibecoding，已经一个礼拜了。剧情、策划、美术原本就都是他自己来。本来研究系统本身时间就不够，压力就大，再分一块去搞 AI 工作流——挫败感比真正的开发挫败还大，因为你不知道自己到底是在做游戏还是在做工具链。
他说：”非得消耗掉热情就好了。”这句话是他原话。
为了帮他确认，我也跑了一遍。Trae 接 MCP 进 UE5.5。
文件目录能遍历。蓝图和 C++ 的代码文本能读。模块化的 Actor 能写，DataTable 的配置能填。第一次跑通的时候挺爽。
然后问题来了。
Structure 读不到。 大部分结构体它看不见。意味着你工程里那些定义好的数据格式，它只能凭文件名和上下文猜。猜对了是运气，猜错了你后面调 Bug 的时候根本定位不到根源——因为它给你写的代码假设了一个不存在的字段。
这点对我特别有感。数据开发出身的人最在意 Schema 清晰，但 AI 在这一层是半盲的。
DYN 模型调不了。 朋友场景里很多 DYN 模型，有些是 scriptable 的，有些带骨骼和动画数据。这些资源在 UE5 里不是纯代码能描述的，依赖引擎内部的资源引用、骨骼权重、动画蓝图状态机。AI 能写”播放这个动画”的代码，但调不了融合权重，修不了碰撞体积。运行时根据物理反馈微调更不用想。
这些东西没有在引擎里反复点开调试过，光看代码根本搞不定。地编做久了的人对这种东西敏感，知道哪个参数动了会塌房；AI 不知道。
剧本只描述状态改变。 朋友试过让 AI 写剧本和关卡。他的评价是：AI 只能描述角色或事物状态上的改变，写不了观念上的变化。
“主角打开了门，进入了房间，捡起了钥匙”——这种状态描述 AI 写得飞快。但”玩家在转角看到影子，心跳漏了一拍”那种节奏感，写不出来。剧本没有激烈的加速感，关卡没有情绪的张力曲线。
朋友的原话是：”非常吃感受，节奏感很差。”
这三条问题里，第三条最致命。前两条还可以期待模型迭代解决——MCP 协议补一下，结构体迟早能读；引擎 API 一次次开放，AI 调动画也只是时间问题。第三条目前看不到解决路径。
聊到这里，我和朋友梳理了一张图。游戏开发的能力需求大概可以分成三层。
AI 区。 DataTable 配置、配置型 Actor、标准化脚本、面向对象那种模块化组件。功能单一，接口清晰，出问题能快速拔掉换一个。朋友的原话是：”让 AI 完成插槽类型的 Actor 和 data。”这层交给 AI 没问题——重点是出错的时候你可以快速拿掉，让 AI 重新迭代，不影响主循环。
协作区。 代码框架的草稿、UI 布局的初版、素材的批量处理。AI 打第一稿，人审核。
但这里有个隐藏前提：你得看得懂它写了什么。这条对朋友不成立。他看不懂 C++。所以对他来说，原本应该是协作区的事情，实质上滑进了禁区——AI 写的东西他没法审，只能整段接受。
这就是为什么”AI 能力边界”不是一张全行业通用的图。它取决于你这个具体的人有什么能力。 同样是写 C++ 框架，一个 C++ 老手在协作区，朋友在禁区。
禁区。 GameMode、GameState、存档、玩家状态机、关卡流送、动画蓝图调试、剧情、灯光氛围。这些决定游戏”是什么”的东西，AI 帮不上。
朋友的判断是：”大的 system 还得是人搞。”我同意。GameMode 的循环逻辑、关卡之间的流送、什么时候给玩家压力什么时候给喘息——这些吃的是设计感，不是代码能力。AI 写出来的版本对，但没意思。
朋友最后说，ART 和 DESIGN 他都不要求 AI 帮忙了，CODE 能解决就行。这句话听着像让步，其实是这次聊天里最清醒的一句。它等价于：”我把禁区里的东西重新拿回自己手里，只让 AI 待在 AI 区。”
行业里真正用 AI 做整套游戏的，就一小部分人在试 vibecoding。连人宅那种级别的大佬都没把 AI 全推进工作流。朋友的原话：”你老师要是能全流程搞定，丁磊就要了。”——意思是这件事如果真做成了，那是网易级别的人物会出手买的。还没到那一步。
我跟他说，你蓝图已经能抓物体了。这是你第一个游戏项目，非得换 C++ 干嘛？
他想了想，说蓝图回退也行。
这不是退步。前苏联有个学科叫系统工程，核心是控制论——用成熟技术做系统优化，达到看起来更好的效果，而不是上来就追先进技术。
道理放在游戏开发里也成立：当先进技术还没展现出明确优势的时候，老办法就是最好的办法。做 APP、排 PPT、写文案，AI 已经有明确优势了，用。UE5 全流程、带剧情、带物理、带动画的线性游戏，AI 还没有。
如果做的是 HTML 小游戏，那为啥不用 vibecoding？场景本来就不一样。
生产产品不是搞科研，也不是玩 AI 斗兽棋。原本传统模式可以稳定生产的东西，你整个流水线一次性替换成另一种不可控的模式，结果就是：可控的流程变得不可控，可预期的交付变成赌博。
第一个作品最赌不起。
朋友的项目，我们最后梳了一下，思路是这样的：
蓝图先把原型跑通。抓取物体这一环他已经做出来了——这是核心玩法的一环。不依赖 AI、不依赖 C++，游戏已经能跑了。这时候最该做的事不是升级技术栈，是把原型跑通、跑稳、跑出乐趣。
模块化拆分，只把可插拔的部分交给 AI。GameMode、PlayerController、关卡流送、存档系统这些是大动脉，必须人控。DataTable、部分配置型 Actor、标准化脚本是毛细血管，交给 AI 填充，出了问题可以快速拔掉。
朋友的原话：”让 AI 完成插槽类型的 Actor 和 data。”
这种架构的好处是：AI 的不可控性被关在笼子里。就算 AI 某天抽风生成了一堆垃圾代码，也只会影响一个插槽，不会让整个项目崩盘。
第一个项目的唯一 KPI 是完成。
做个逛 gai 模拟器也得成。
哪怕做出来是个 1 分钟流程的 demo，只要从头到尾能跑、能让人玩、有自己的判断在里面，就是赢。
朋友最后说了一句话我印象很深：
“我之前在大厂做地编，觉得自己是螺丝钉，所以想靠 AI 一键脱离螺丝钉身份。但现在我发现，如果连自己项目的代码都看不懂，我连做螺丝钉的资格都没有，我只是 AI 的挂件。”
他还说：”这次一定得成。不成就回去研究股票了。”
游戏开发不是写 PPT，是系统工程——这句话不是金句，是他做了几年地编的真实判断。
我跟 AI 这半年也打了不少交道。半路上有一个事我越来越确信：AI 产品经理真正要做的事，不是让 AI 替代人，而是帮人弄清楚自己不可替代的部分在哪里。在哪些环节上人是不能被替换出去的，在哪些环节上人是可以适当退出让 AI 接手的。这个边界判断本身，比单纯堆 AI 工具值钱得多。
游戏正好是这种边界感最强的产品形态之一。AI 能写出对的台词，但写不出有节奏感的台词。AI 能拼出对的关卡，但拼不出有情绪曲线的关卡。这些东西非常吃”感受”——而感受，目前任何大模型都替代不了。
朋友把蓝图捡回来了。
他说项目重新跑起来，还是一堆 Bug。但每个 Bug 他都知道去哪找，每个功能他都知道怎么改。
Claude 的事他还没问。说明天去问。
本文由 @灵艺 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。