1. 三天连续运行到底测的是什么先把实验边界划清楚很多人看到连续运行3天这个说法第一反应是模型会不会崩会不会忘事上下文会不会爆。这些担心都合理但如果不先把实验边界定义清楚测出来的结论就是一笔糊涂账。我在动手之前先花了大半天时间把这次实测的变量固定下来否则三天跑完你根本不知道哪个因素导致了结果差异。1.1 为什么是纯提示词驱动而不是AI辅助这里有个关键区分。市面上大量所谓AI做游戏的案例本质是人在写代码AI在旁边补全几行或者人搭好工程骨架AI填几个函数。这种模式里人的架构能力仍然是主导AI只是个高级自动补全。而纯提示词驱动的意思是我不打开Unity编辑器手动拖拽任何组件不手写任何一行C#或蓝图节点所有工程结构、脚本、场景配置、材质参数全部通过自然语言描述让模型输出我再把输出结果落到工程里。这个约束非常苛刻因为它逼着模型去理解一个能跑起来的游戏工程到底需要哪些东西而不是只生成一段看起来对的代码片段。我选择这个约束的原因很直接如果允许我手动搭骨架那测出来的其实是我AI的协作效率而不是模型本身对游戏开发全流程的理解深度。我想知道的是当把架构决策权也交给模型时它能走多远。1.2 三天时间是怎么分配的连续运行不等于连续生成。我把三天拆成了几个阶段每个阶段有明确的产出目标时间段主要任务产出物第1天上午需求拆解与工程规划功能清单、模块划分、技术选型文档第1天下午至第2天Unity侧核心玩法实现可运行的角色控制、战斗、UI第3天上午UE5侧对照实现同类玩法的蓝图与C混合方案第3天下午联调、优化与问题复盘性能数据、踩坑记录、可复用提示词模板这个分配不是拍脑袋定的。Unity和UE5各占一半左右的时间是为了做横向对照——同一个玩法需求两个引擎的提示词策略差异在哪里哪个引擎对提示词驱动更友好这是本次实测最有价值的部分之一。1.3 评测标准什么叫做出来了能做出什么这个问法太模糊。我给自己定了四条硬标准任何一条不满足就不算成功可编译生成的代码和蓝图能通过引擎的编译检查没有语法错误和缺失引用。可运行打包或在编辑器内点击运行后核心玩法循环能跑通不崩溃。可交互玩家输入能正确驱动游戏状态变化不是个静态场景。可复现换一台机器按同样的提示词序列能重建出接近的结果。这四条里可复现是最容易被忽略但最重要的。如果每次生成结果都天差地别那这套方法就没有工程价值只能当玩具。提示做这类长周期实测一定要在开始前把评测标准写下来。否则跑到第二天你会不自觉地降低标准最后得出一个好像还行的模糊结论没有任何参考价值。2. 第一天让模型先当架构师而不是先当码农第一天的核心心得只有一句话别急着让模型写代码先逼它把工程结构想清楚。我见过太多人一上来就说帮我写一个角色控制器结果模型给出一段孤立的代码你放进工程发现缺输入系统、缺相机引用、缺动画状态机根本跑不起来。2.1 需求拆解阶段的提示词设计我用的第一版提示词大致是这样的结构你是一名资深Unity技术负责人。我要做一个俯视角动作游戏原型核心玩法包括 1. 角色八方向移动带加速度和摩擦力 2. 三段连击的近战攻击每段有独立的判定窗口 3. 敌人AI巡逻、追击、攻击三个状态 4. 血条UI和伤害数字飘字 请先不要写任何代码。请输出 - 完整的模块划分和每个模块的职责 - 每个模块需要的脚本清单及脚本之间的依赖关系 - 推荐使用的Unity版本和关键Package - 你认为最容易出问题的三个技术点注意最后那句你认为最容易出问题的三个技术点。这是我加的一个私货。让模型主动暴露风险点比我自己去猜要高效得多而且它列出的问题往往能提醒我一些没想到的坑。实测下来模型给出的模块划分相当合理输入层、角色控制层、战斗系统、AI系统、UI系统、数据配置层六层结构清晰。它推荐的Unity版本是2022 LTSPackage方面提到了Input System、Cinemachine、TextMeshPro这些都是标准选择没有跑偏。2.2 脚本依赖关系为什么必须提前定这里要展开讲一个很多人踩过的坑。Unity工程里脚本之间的引用关系如果没提前规划后期会出现大量循环依赖和空引用。比如角色控制器需要调用战斗系统战斗系统又需要回调角色控制器播放动画两边互相引用编译能过但运行时容易出问题。我在提示词里明确要求模型输出依赖关系图用文字描述不是画图并且规定依赖必须是单向的不允许双向引用。模型给出的方案是用事件中心解耦角色控制器发出攻击输入事件战斗系统监听并处理处理完再发出播放动画事件角色控制器监听。这样两个系统之间没有直接引用通过事件总线通信。这个设计不是模型独创的是Unity社区的标准做法但关键在于模型能主动选择这个方案说明它对工程可维护性有基本认知。这一点比我预期的要好。2.3 第一段可运行代码的诞生过程到了下午我开始让模型逐个模块输出代码。第一个是输入处理层。我给的提示词是基于Input System写一个输入处理脚本要求 - 支持键盘WASD和手柄左摇杆 - 输出一个Vector2表示移动方向 - 输出攻击按钮的按下事件 - 不要直接引用任何角色控制器通过事件或接口暴露模型给出的代码用了PlayerInput组件配合C#事件结构干净。但我发现一个问题它默认用了SendMessage模式这个模式性能差且难调试。我追问了一句为什么用SendMessage而不是UnityEvent或C#原生事件模型承认SendMessage是它见过的旧教程里的常见写法并主动改成了C#事件方案。这个细节让我意识到模型的默认输出往往偏向网上最常见的写法而不是最佳实践。你必须通过追问去逼它升级方案。这是纯提示词驱动开发里一个非常重要的技巧——不要接受第一版答案。2.4 第一天结束时的工程状态到第一天晚上工程里已经有了输入层、角色移动、相机跟随、基础场景。角色能在场景里跑动相机平滑跟随但还没有战斗和敌人。代码总量大约800行全部由模型生成我只做了复制粘贴和一次编译错误修复一个命名空间引用缺失。这个进度不算快但结构是干净的。我特意没有追求第一天的功能数量而是把架构地基打牢。后面两天的经验证明这个选择是对的——因为架构清晰第二天加战斗系统时几乎没有返工。3. 第二天战斗系统与AI提示词开始打架的地方第二天是整个实测里最混乱也最有收获的一天。混乱的原因是当功能复杂度上升后模型开始出现前后不一致的情况——它在第一个脚本里定义的接口到第五个脚本里就忘了导致引用对不上。3.1 三段连击的判定窗口怎么描述才准确近战连击的核心是判定窗口——每段攻击有一个特定的时间段内才能触发下一段。这个东西用自然语言描述很容易含糊。我第一版提示词写的是三段连击每段有时机要求模型给出的实现是简单的计时器按一下等0.5秒再按第二下完全没有窗口概念。我改成更精确的描述攻击分三段。每段攻击动画时长0.8秒其中第0.3秒到第0.6秒是连击输入窗口。 如果玩家在这个窗口内再次按下攻击键立即进入下一段如果窗口内没按动画播完后回到待机。 第三段攻击有更大的伤害倍率和更长的硬直。这次模型给出的实现就对了用动画事件Animation Event标记窗口开始和结束在窗口内监听输入。这个方案是Unity里做连击的标准做法模型能根据精确的时间描述选对方案说明提示词的精度直接决定输出质量。3.2 敌人AI的状态机为什么模型第一版总是写错敌人AI我要求三个状态巡逻、追击、攻击。模型第一版给了一个巨大的if-else嵌套逻辑上能跑但完全没法维护。我追问如果我要加第四个状态逃跑你这个结构要改多少地方模型自己承认需要改动核心逻辑然后主动重构为状态机模式。这里有个经验模型不是不知道状态机而是它的默认输出倾向于最短路径。对于简单需求if-else确实更短。但当你在提示词里明确这个系统后续会扩展它就会切换到可扩展的方案。所以提示词里一定要包含未来会怎样的信息。重构后的状态机用了接口状态类的方式每个状态一个类切换逻辑集中在状态管理器里。加新状态只需要新增一个类不用动现有代码。这个结构我直接沿用了。3.3 提示词之间的记忆断裂问题这是第二天最大的坑。当我让模型分别生成战斗系统和AI系统时两个系统都需要访问角色的生命值。战斗系统里模型定义了一个Health类AI系统里它又定义了一个EnemyHealth类两个类功能重复但接口不同导致伤害传递时类型对不上。根本原因是长对话中模型对早期定义的记忆会衰减。虽然上下文窗口够大但它的注意力会偏向最近的内容。我的解决方案是建立一个接口契约文档。每生成一个新模块前我先把已有的核心接口贴进提示词当前工程已有以下核心接口请严格复用不要重新定义 - IHealth { int Current; void TakeDamage(int amount); event Action OnDeath; } - IDamageable { void ApplyDamage(DamageInfo info); } - EventBus.PublishT(T evt) / EventBus.SubscribeT(ActionT handler)加上这段之后接口冲突问题基本消失了。这个契约文档后来成了我整套提示词模板里最重要的组成部分。3.4 伤害数字飘字一个被低估的UI难点伤害飘字看起来简单实际涉及对象池、世界坐标转屏幕坐标、动画曲线、层级管理。模型第一版直接用了Instantiate和Destroy每次伤害都创建销毁对象。我指出这个游戏一秒可能触发几十次伤害模型立刻改成对象池方案。但对象池的实现它第一版写错了——回收时没有重置动画状态导致复用的飘字对象位置错乱。这个bug我调了大概二十分钟才定位到。教训是对象池的重置逻辑必须显式要求模型写出来它默认只会写获取和回收容易漏掉状态重置。4. 第三天UE5对照实测蓝图与提示词的适配差异第三天我把同样的玩法需求搬到UE5上。这一天的核心发现是UE5对提示词驱动的友好度和Unity完全不同差异不在模型能力而在引擎本身的设计哲学。4.1 蓝图为什么比C#更难用提示词描述Unity的C#是纯文本模型生成文本我粘贴进脚本文件流程顺畅。但UE5的蓝图是可视化节点图模型没法直接生成蓝图文件只能生成两种东西要么是C代码要么是蓝图搭建步骤的文字描述。我两种都试了。C路线的问题是UE5的C样板代码极其冗长一个简单的Actor类光构造函数和头文件声明就上百行模型生成的代码经常在宏定义UCLASS、UPROPERTY上出错。蓝图描述路线的问题是模型描述的节点连接顺序经常和实际蓝图编辑器的操作逻辑对不上比如它说把A节点的输出连到B节点的输入但实际这两个节点的引脚类型不兼容。4.2 双指触摸蓝图移动端适配的提示词策略热词里提到了ue5双指触摸蓝图我顺手测了一下移动端输入。UE5的增强输入系统Enhanced Input对触摸的支持需要通过Touch输入映射。模型给出的方案是创建Touch1和Touch2的输入动作然后在蓝图里读取触摸位置计算缩放和旋转。这里有个细节模型一开始搞错了它把双指缩放直接映射到了相机FOV但正确的做法应该是移动相机位置或调整弹簧臂长度。我指出FOV变化会导致透视畸变后模型改成了调整弹簧臂。这说明模型对视觉正确性的理解需要人来把关它知道怎么实现功能但不一定知道哪种实现视觉上更合理。4.3 开关门蓝图一个暴露模型想当然的案例ue5蓝图实现开关门是热词里的常见需求。我让模型描述实现步骤它给出的方案是用时间轴Timeline驱动门旋转用触发器Trigger Box检测玩家进入。听起来没问题但它漏了一个关键点门的旋转轴心。UE5里静态网格体的默认轴心在物体中心如果直接旋转门会绕中心转而不是绕门轴转。模型完全没提这一点。我追问后它才补充需要调整静态网格体的轴心位置或使用场景组件嵌套。这个案例很典型模型能给出功能逻辑但对引擎的物理直觉类细节容易想当然。这类问题在Unity里相对少因为C#代码里轴心问题会以明显的视觉错误暴露出来而蓝图描述阶段你根本看不到。4.4 两个引擎的提示词驱动适配度对比跑完两边我整理了一个对比维度UnityUE5代码生成直接可用度高C#文本直接落地低C样板多蓝图无法直接生成提示词描述精度要求中代码本身有结构高需要描述节点连接和参数模型出错的主要类型接口不一致、漏状态重置轴心、引脚类型、宏定义调试反馈速度快编译错误明确慢蓝图错误需要手动排查适合提示词驱动的模块逻辑层、系统层简单交互、原型验证结论是Unity更适合纯提示词驱动的完整开发UE5更适合提示词辅助人工搭建的混合模式。这不是引擎优劣是工作流适配问题。5. 三天跑下来提示词工程到底哪些技巧真正有用这部分是我最想分享的。网上讲提示词工程的文章很多但大部分是通用技巧放到游戏开发这个具体场景里真正管用的其实就那么几条。5.1 接口契约文档长周期开发的命根子前面提过这里再强调一次。三天里我维护了一份不断更新的接口文档每次生成新模块前都贴进提示词。这份文档包括核心接口定义、事件名称规范、命名空间约定、已有的工具类清单。没有这份文档第二天开始就会出现大量重复定义和接口冲突。有了它模型的输出一致性提升了非常多。我的建议是这份文档不要超过一屏只放最核心的契约太长了模型反而抓不住重点。5.2 先问风险再要代码的提问顺序这个技巧我在第一天就用了效果贯穿全程。每次让模型实现一个复杂功能前先问这个功能最容易出问题的三个地方是什么等它回答完再让它写代码并且在提示词里加上请特别注意你刚才提到的第X个风险点。这样做的效果是模型在生成代码时会主动规避它自己识别出的风险。实测下来这种方式能减少大约一半的低级错误。5.3 拒绝第一版答案的勇气模型的第一版输出永远是最安全的常见写法不是最适合你项目的写法。三段连击、状态机、对象池这三个例子都证明了这一点。你要做的是追问这个方案在什么情况下会出问题如果我要扩展X功能这个结构要改哪里。追问两到三轮模型的输出质量会有明显跃升。但要注意追问要有针对性泛泛地问还能更好吗没用要给出具体的扩展场景或约束条件。5.4 把编译错误原样贴回去Unity的编译错误信息很详细包含文件名、行号、错误类型。我遇到编译错误时直接把完整错误信息贴给模型它几乎每次都能一次修好。不要自己翻译错误信息原样贴模型对编译器输出的理解比对人话的理解更准。UE5的C编译错误更复杂模板报错经常几百行。这种情况我会先自己定位到出错的宏或类型只贴相关的那几十行效果更好。6. 那些没人告诉你但一定会踩的坑6.1 模型会忘记你用的是哪个版本Unity 2022和Unity 6的API有差异UE5.0和UE5.4的增强输入系统也不一样。模型默认可能混用不同版本的API。我的做法是在每次提示词开头固定加一句当前使用Unity 2022.3 LTS请只使用该版本支持的API。这一句话省了我大量排查版本兼容问题的时间。6.2 命名空间和程序集定义容易被忽略Unity的项目一旦用了程序集定义文件asmdef脚本的命名空间和引用关系就变得严格。模型生成的代码经常忘记加命名空间或者引用了不该引用的程序集。这个问题在项目变大后才会暴露前期不痛不痒后期改起来很烦。建议在接口契约文档里就把命名空间规范写死。6.3 性能问题模型不会主动提模型生成的代码默认是功能正确优先性能优化需要你主动要求。比如Update里的频繁GetComponent、每帧的字符串拼接、没有用对象池的频繁实例化这些模型都不会主动避免。我的做法是在关键模块生成后追加一句请检查这段代码有没有性能隐患特别是每帧执行的部分。6.4 三天连续运行的上下文管理经验虽然模型支持长上下文但实际使用中对话太长后模型的响应质量会下降表现为开始重复之前的建议、忘记接口约定、生成越来越啰嗦的代码。我的应对策略是每完成一个模块就开一个新对话把接口契约文档和当前模块需求重新贴进去。这样每个对话都是短上下文高信息密度输出质量更稳定。这个经验可能和很多人的直觉相反——大家觉得一个长对话能保持连贯性。但实测下来主动切分对话比维持长对话效果更好代价是你要维护好那份契约文档。7. 三天实测的最终产出与我的真实判断三天结束时Unity侧有一个可运行的原型角色能移动、三段连击能触发、敌人能巡逻追击攻击、血条和伤害飘字正常。代码约2500行全部由模型生成我手动修改的部分不超过50行主要是修编译错误和调整参数。UE5侧有一个简化版实现了移动和开关门交互蓝图部分是我根据模型描述手动搭的。关于GPT-6连续运行3天能做出什么这个问题我的真实判断是它能做出一个结构清晰、可运行的原型但做不出一个可发布的完整游戏。差距不在代码量而在那些需要视觉判断手感调优性能权衡的地方——这些是模型目前给不了你的必须人来把关。但这已经足够改变工作流了。以前做一个原型要一周现在三天能出可运行版本而且架构质量不差。省下来的时间可以全部投入到玩法打磨和手感调优上这才是提示词驱动开发真正的价值所在。最后分享一个我用了三天后固定下来的提示词开头模板它帮我省了大量重复沟通当前项目Unity 2022.3 LTS / UE5.4按实际选一个 已有核心接口[粘贴契约文档] 本次任务[具体需求] 约束只使用上述接口不重新定义已有类型代码需可编译如有性能隐患请标注 先输出你的实现思路和风险点我确认后再写代码。这个模板的核心是最后那句先输出思路确认后再写代码。它把生成变成了先对齐再生成返工率大幅下降。你可以直接拿去用根据自己的项目改接口部分就行。