1. 三天连续运行到底测了什么实验设计与核心思路拆解1.1 为什么选“连续运行三天”这个切入点单次对话生成一段代码和让模型在长时间跨度内持续迭代一个项目完全是两码事。前者考验的是单点能力后者考验的是上下文保持、任务拆解、错误自修复和跨文件一致性。我这次实测的核心动机很简单市面上大量演示都是“一句话生成一个贪吃蛇”但真实游戏开发从来不是一次成型的它需要反复修改、联调、补功能、修Bug。所以我设定了一个相对苛刻的条件——让模型在三天时间里围绕两个完整的游戏项目持续工作中间不重置对话只靠提示词驱动。选择Unity和UE5这两个引擎是因为它们代表了两种典型的工作流。Unity以C#脚本为主生态成熟、文档丰富模型训练语料里占比极高UE5则以蓝图可视化编程和C为双轨蓝图部分对模型来说是“非文本”的需要它输出节点连接逻辑的描述或者直接写C。这两个引擎放在一起对比能很清楚地看出模型在不同抽象层级上的表现差异。三天的运行不是字面意义上的72小时不间断而是分成了若干个工作时段累计有效交互时间大约在20小时左右其余时间用于我人工验证、编译、运行和记录问题。这样安排更贴近真实开发节奏也避免了我自己盯着屏幕崩溃。1.2 两个测试项目的选型逻辑第一个项目我选了一个2D俯视角射击小游戏放在Unity里做。选它的理由很实在玩法逻辑清晰移动、射击、敌人AI、血量、计分涉及的技术点覆盖面广物理碰撞、UI、动画状态机、对象池而且2D项目对美术资源要求低我可以用纯色块和简单图形先跑通逻辑不会被素材卡住。这个项目主要考验模型在C#脚本编写、组件协作和Unity API调用上的准确性。第二个项目是一个第一人称解谜房间放在UE5里做。这个选型是为了测试模型对蓝图逻辑描述和C混合编程的理解。解谜房间包含开关门、物品拾取、灯光触发、简单的机关联动这些在UE5里天然适合用蓝图实现但模型没法直接操作蓝图编辑器所以它必须用两种方式之一来输出要么写详细的蓝图节点连接步骤让我手动连要么直接写C类然后暴露给蓝图。我两种都让它试了后面会详细说哪种更靠谱。两个项目都不大但“麻雀虽小五脏俱全”该有的模块一个不少。这样设计的好处是三天时间里我能把每个模块都跑到而不是卡在某个巨型系统的某一个环节上反复折腾。1.3 提示词策略从“一句话”到“结构化任务书”这三天里我最大的体会是提示词的质量直接决定了模型输出的可用性差距不是百分之几十而是几倍到十几倍。我一开始也试过“帮我做一个Unity射击游戏”这种粗放式提示结果模型给了一堆看似合理但根本跑不起来的代码——类名对不上、API版本不对、缺少必要的组件引用。后来我调整了策略把每个任务拆成结构化的“任务书”包含以下几个要素当前项目状态已经有哪些脚本、场景里挂了什么组件、用的什么版本。本次目标具体要完成什么功能输入输出是什么。约束条件比如“不要用某某个已废弃的API”“保持现有命名规范”“新增代码要能直接编译”。验收标准怎么判断这次输出是对的比如“按下WASD角色移动速度5单位/秒”。这种结构化提示词的好处是模型不需要猜上下文它拿到的是一个明确的工程任务。实测下来同样一个“敌人追踪玩家”的功能粗放式提示的代码首次编译通过率大概三成结构化提示能到七成以上。剩下的三成主要是版本差异和边界情况需要我手动修。提示连续运行的关键不是让模型“记住”所有东西而是你要在每次提示里主动把关键上下文喂给它。模型的上下文窗口再大也不如你把当前状态写清楚来得可靠。1.4 三天时间线的整体安排第一天主要做Unity项目的基础搭建角色控制器、射击逻辑、敌人生成和基本UI。第二天上午继续完善Unity项目加对象池、音效触发、关卡切换下午转到UE5搭建解谜房间的基础场景和交互框架。第三天集中处理两个项目的Bug修复、性能优化和功能扩展同时做交叉验证——把Unity里验证过的逻辑思路迁移到UE5看模型能不能举一反三。这个安排不是拍脑袋定的而是根据模型的能力曲线来的。前两天它的输出质量比较稳定到第三天后期随着对话轮次增多上下文里积累的信息越来越杂模型开始出现“遗忘”和“混淆”——比如把Unity的API用到UE5的C代码里。这个现象本身就是一个很重要的发现后面会专门讲。2. Unity项目实操从零到可玩Demo的核心细节2.1 角色控制器为什么不用CharacterController而用Rigidbody模型第一次给我的角色移动方案是继承MonoBehaviour然后直接改transform.position。这个方案能跑但有个致命问题它绕过了物理系统角色撞墙会穿模碰到带碰撞体的敌人也不会有任何反馈。我让模型重新设计它给出了两个选项用CharacterController组件或者用Rigidbody加力。我选了Rigidbody方案原因是这个项目里角色需要和敌人、子弹、场景道具发生物理交互CharacterController虽然移动手感好但它的碰撞检测是独立的和物理系统的交互需要额外处理。Rigidbody方案虽然需要手动处理速度上限和阻尼但物理交互是原生的省心。模型最终给出的核心代码结构是这样的public class PlayerController : MonoBehaviour { public float moveSpeed 5f; public float acceleration 20f; private Rigidbody2D rb; private Vector2 moveInput; private Vector2 currentVelocity; void Awake() { rb GetComponentRigidbody2D(); } void Update() { moveInput.x Input.GetAxisRaw(Horizontal); moveInput.y Input.GetAxisRaw(Vertical); moveInput moveInput.normalized; } void FixedUpdate() { currentVelocity Vector2.MoveTowards( currentVelocity, moveInput * moveSpeed, acceleration * Time.fixedDeltaTime ); rb.velocity currentVelocity; } }这里有个细节值得说模型用了Vector2.MoveTowards来做加速过渡而不是直接rb.velocity moveInput * moveSpeed。前者让角色起步和停止有一个短暂的缓冲手感更接近商业游戏后者是瞬间响应操作起来很“硬”。这个选择模型没有主动解释是我追问之后它才说明的。这说明模型有时候会做出正确的工程决策但不一定会告诉你为什么。注意Unity 2022之后的版本里Rigidbody2D.velocity已经被标记为过时推荐用linearVelocity。模型在第一天用的是旧API我手动改过来之后后续它才跟着用新的。这说明模型对版本差异的敏感度有限你需要明确告诉它引擎版本。2.2 射击与对象池一个被模型忽略的性能陷阱射击功能本身很简单按下鼠标左键在枪口位置生成一颗子弹给一个向前的速度。模型第一次给的代码是每次射击都Instantiate一颗子弹子弹飞出去之后Destroy掉。这个写法在Demo阶段没问题但连续射击几十次之后GC垃圾回收会频繁触发帧率出现明显波动。我让模型优化它给出了对象池方案。核心思路是预先创建一批子弹对象禁用后放在池子里需要时取出激活用完再放回去。模型写的池子类大致如下public class BulletPool : MonoBehaviour { public GameObject bulletPrefab; public int poolSize 30; private QueueGameObject pool new QueueGameObject(); void Start() { for (int i 0; i poolSize; i) { GameObject bullet Instantiate(bulletPrefab); bullet.SetActive(false); pool.Enqueue(bullet); } } public GameObject GetBullet() { if (pool.Count 0) { GameObject bullet pool.Dequeue(); bullet.SetActive(true); return bullet; } GameObject newBullet Instantiate(bulletPrefab); return newBullet; } public void ReturnBullet(GameObject bullet) { bullet.SetActive(false); pool.Enqueue(bullet); } }这个实现有个小问题当池子空了的时候它直接Instantiate一个新的但没有把这个新对象纳入池子的管理逻辑——也就是说这个新子弹用完之后如果调用ReturnBullet会被加进队列但队列的初始容量已经不重要了因为队列是动态的。这其实不算Bug但模型没有处理“池子无限增长”的情况。如果玩家一直射击而子弹回收不及时池子会越来越大。我在实际项目里加了一个上限判断超过上限就复用最早的那颗子弹。另一个坑是子弹的回收时机。模型最初在子弹的OnTriggerEnter2D里直接调用ReturnBullet但这时候子弹可能还在物理系统的回调里直接禁用会导致一些奇怪的状态。稳妥的做法是用Invoke延迟一帧再回收或者用协程等一帧。2.3 敌人AI状态机比想象中更容易写错敌人AI我要求实现三个状态巡逻、追击、攻击。模型给了一个基于enum和switch的简单状态机逻辑上是对的但有几个地方需要调整。首先是巡逻点的设置。模型用了一个Transform[] patrolPoints数组敌人在Update里判断是否到达当前巡逻点到了就切换到下一个。这个逻辑没问题但它没有处理“巡逻点为空”的情况如果数组没赋值敌人会直接报空引用。我加了一个判空保护。其次是追击的触发条件。模型用的是Vector2.Distance来判断玩家是否进入视野这个计算每帧都在跑敌人多了之后有性能开销。更优的做法是用Physics2D.OverlapCircle配合LayerMask只在玩家进入碰撞范围时才触发追击逻辑。模型在我提示之后改成了这个方案代码量差不多但性能更好。攻击状态有个细节模型让敌人在进入攻击范围后立刻造成伤害然后进入冷却。但实际游戏里敌人应该有一个“前摇”动作给玩家反应时间。我让模型加了一个attackWindup计时器敌人进入攻击状态后先等待0.3秒再造成伤害同时播放一个颜色闪烁的动画作为视觉提示。这个改动让游戏手感提升很明显。2.4 UI与计分模型容易忽略的锚点问题UI部分模型写得中规中矩分数显示、血量条、游戏结束面板都做出来了。但有一个问题它反复犯UI元素的锚点设置。模型生成的代码里UI是通过脚本动态创建的但它没有设置RectTransform的锚点导致在不同分辨率下UI位置会跑偏。我后来改成在编辑器里手动搭好UI层级只让模型写控制逻辑比如更新分数文本、控制面板显隐这样问题就少了很多。这也引出一个经验让模型做它擅长的事逻辑代码把它不擅长的事编辑器操作、资源引用留给自己。模型没法看到你的场景层级它只能根据你描述的文字来推断而文字描述永远不如直接操作准确。计分逻辑本身很简单但模型在“分数变化时更新UI”这个环节用了Update里每帧判断分数是否变化的方式这是不必要的开销。改成事件驱动之后只有分数真正变化时才更新文本代码也更清晰。3. UE5项目实操蓝图与C的混合编程实测3.1 蓝图逻辑描述模型能说清楚但不够精确UE5的解谜房间项目我一开始让模型用纯蓝图方案。模型给出的输出是一段文字描述比如“创建一个Actor蓝图添加一个StaticMesh组件作为门添加一个BoxCollision作为触发区域在Event ActorBeginOverlap时调用Timeline节点控制门的旋转”。这个描述方向是对的但细节不够。比如Timeline节点的曲线怎么设置、旋转的插值用哪个节点、碰撞通道怎么配置这些它都没有说清楚。我按照它的描述去连发现门是能转但转完之后碰撞体没跟着动玩家还是过不去。后来我手动把碰撞体设为门的子组件问题才解决。这说明模型对蓝图的理解停留在“逻辑流程”层面对“组件层级和物理关系”这种空间性的东西把握不准。蓝图本质上是可视化的模型只能通过文字来间接描述信息损耗很大。3.2 C方案模型表现明显更好后来我换了个思路让模型直接写C类然后在蓝图里继承。这个方案的效果好很多。模型写的ADoorActor类大致如下UCLASS() class MYGAME_API ADoorActor : public AActor { GENERATED_BODY() public: ADoorActor(); protected: virtual void BeginPlay() override; UPROPERTY(VisibleAnywhere) UStaticMeshComponent* DoorMesh; UPROPERTY(VisibleAnywhere) UBoxComponent* TriggerBox; UPROPERTY(EditAnywhere, Category Door) float OpenAngle 90.f; UPROPERTY(EditAnywhere, Category Door) float OpenSpeed 2.f; bool bIsOpen false; FRotator ClosedRotation; UFUNCTION() void OnOverlapBegin(UPrimitiveComponent* OverlappedComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult SweepResult); virtual void Tick(float DeltaTime) override; };这个类在构造函里初始化组件在BeginPlay里记录初始旋转在Tick里根据bIsOpen插值旋转门。逻辑清晰编译通过之后直接在蓝图里继承就能用我只需要在编辑器里指定模型和调整参数。对比下来模型写C的准确率远高于写蓝图描述。原因也很直接C是文本模型训练时见过大量UE的C代码蓝图是图形化的模型只能靠文字转述中间隔了一层。所以如果你的项目允许尽量让模型写C或者Unity的C#把可视化编辑的部分留给自己。3.3 双指触摸与输入映射一个跨平台的坑热词里出现了“ue5双指触摸蓝图”我顺便在这个项目里试了一下移动端的输入适配。模型给的方案是用Enhanced Input系统配置InputAction和InputMappingContext。这个方向是对的UE5现在主推Enhanced Input旧的AxisMapping已经逐步淘汰。但模型在描述触摸输入时把双指触摸的检测逻辑说得很模糊。它提到用Touch1和Touch2的Pressed事件来判断但没有说清楚怎么区分“双指同时按下”和“先后按下”。我后来自己查了文档用InputAction的Triggered事件配合ChordedAction来实现才达到预期效果。这个环节给我的教训是模型对平台特定功能的了解往往停留在表面尤其是移动端、触摸、陀螺仪这类它训练语料里相对少的内容。遇到这类需求把模型当做一个“能帮你写模板代码的助手”就好核心逻辑还是得自己把关。3.4 灯光与氛围模型的美学建议意外地靠谱解谜房间需要灯光触发比如玩家拿起某个物品后房间的灯亮起来。模型在写灯光控制逻辑的同时还给了一些氛围建议比如用PointLight配合ExponentialHeightFog来营造神秘感用PostProcessVolume调整曝光和色调。这些建议我试了一下效果确实不错。这说明模型在“常见游戏开发套路”上有一定的积累它知道什么样的场景配什么样的灯光。虽然它没法帮你做美术设计但作为技术实现层面的参考它的建议是有价值的。4. 三天运行中暴露的问题与排查实录4.1 上下文漂移第三天开始“记混”两个项目这是最让我意外也最值得记录的问题。第一天和第二天模型在Unity和UE5之间切换时表现正常能清楚地区分两个项目的技术栈。但到了第三天当我同时讨论两个项目的优化时模型开始出现混淆。比如我让它优化Unity的敌人AI它给出的代码里用了UE5的AActor语法我让它检查UE5的门逻辑它又写了一段C#。这个现象的根源是上下文窗口里的信息太多太杂。三天下来对话历史里积累了大量的代码片段、错误信息和修改记录模型在生成回复时注意力被分散了。它不是在“回忆”当前项目而是在一个混合了两种技术栈的语料池里做概率生成。我的应对方法是在每次切换项目时明确地重新声明当前项目的技术栈和状态。比如“现在回到Unity项目引擎版本2022.3使用C#当前正在处理敌人AI的追击逻辑”。这样一句话就能把模型的注意力拉回来。实测下来加了这句声明之后混淆的概率大幅降低。提示连续运行时间越长越要在每次提示里做“上下文锚定”。不要假设模型记得你半小时前说过什么它可能记得也可能记混了。4.2 API版本差异模型默认用旧版Unity的API在版本之间有不少变化比如Rigidbody2D.velocity变成linearVelocityInput系统从旧的InputManager转向InputSystem包。模型默认输出的代码偏向旧版API这在它训练数据的时间分布上是合理的——旧版API的语料更多。解决办法很简单在项目开始时就告诉模型引擎版本并且在它输出旧API时及时纠正。我一般会在提示词里加一句“使用Unity 2022.3 LTS优先使用当前版本推荐的API”。UE5那边也是类似告诉它用Enhanced Input而不是旧的输入映射。4.3 编译错误的排查思路三天里遇到的编译错误大概有二十多个我整理了一个排查顺序基本能覆盖九成以上的情况错误类型常见原因排查方法找不到类型或命名空间缺少using指令或程序集引用检查文件头部的using确认包是否安装方法不存在API版本不匹配或拼写错误查官方文档确认方法名和参数空引用异常组件未赋值或对象未初始化在Awake/Start里加判空和Debug.Log类型不匹配变量声明和赋值类型不一致检查隐式转换必要时显式转换重复定义多个脚本里有同名类检查命名空间和类名这个表看起来基础但实际排查时按顺序走一遍比盲目改代码效率高得多。模型在修Bug时有时候会“过度修改”把没问题的代码也改掉所以我一般会让它先解释错误原因确认理解正确之后再让它给修改方案。4.4 模型“自信地犯错”的典型场景有一种情况特别值得警惕模型给出一个看起来完全合理、语法正确、逻辑自洽的方案但实际跑起来就是不对。比如它给Unity写了一个“子弹碰撞后反弹”的逻辑代码里用了Vector2.Reflect参数看起来也对但实际运行时子弹的反弹方向是反的。原因是它把入射向量和法线向量的顺序搞反了。这种错误很难通过读代码发现因为代码本身没有语法问题逻辑推导也说得通但物理意义是错的。我的应对方法是对涉及数学计算和物理模拟的代码一定要实际运行验证。不要因为代码“看起来对”就跳过测试。模型在数学直觉上偶尔会出偏差尤其是向量运算和坐标系转换。4.5 长时间运行后的输出质量衰减第三天下午我明显感觉到模型的输出质量在下降。同样的提示词第一天它能给出结构清晰、注释完整的代码第三天给出的代码开始变得零散注释变少有时候还会漏掉一些边界处理。这不是模型“累了”而是上下文里的噪声积累导致的。对话历史越长模型在生成时受到的干扰越多。我的做法是在第三天做了一次“上下文清理”把之前的关键决策和当前项目状态整理成一段简短的摘要作为新的系统提示重新开始。清理之后输出质量明显回升。这个经验对实际项目很有用如果你打算长时间用模型辅助开发不要指望一个对话窗口从头用到尾。定期整理上下文把重要的信息提炼出来该开新对话就开新对话。5. 提示词工程在游戏开发中的实战心得5.1 结构化提示词的模板经过三天的摸索我总结了一个比较通用的提示词模板适用于Unity和UE5的日常开发任务【项目】Unity 2022.3 LTS2D俯视角射击 【当前状态】已有PlayerController、BulletPool、EnemyAI三个脚本 【本次目标】给敌人添加一个“受伤闪烁”效果被子弹击中时角色变红0.1秒 【约束】不改动现有接口新增代码放在EnemyAI里使用SpriteRenderer的color属性 【验收】子弹击中敌人时敌人颜色短暂变红然后恢复这个模板的核心是“约束”和“验收”两部分。约束告诉模型不要做什么验收告诉模型怎么算做对了。有了这两部分模型输出的可用性会高很多。5.2 让模型解释“为什么”比让它直接写代码更有价值我有个习惯在模型给出代码之后会追问一句“你为什么选择这个方案有没有其他方案”。这个追问经常能挖出一些有价值的信息。比如它选择用Rigidbody而不是CharacterController追问之后它解释了物理交互的考量它选择用对象池而不是直接实例化追问之后它说明了GC的性能影响。这些解释本身可能不完全准确但它们提供了一个思考的起点。你可以基于它的解释去查文档、做实验最终形成自己的判断。模型的价值不只是“帮你写代码”更是“帮你快速了解一个你不熟悉的领域的常见做法”。5.3 什么时候该放弃让模型继续改有一个信号很明确当模型连续两次修改同一个Bug都没有修好时就该自己上手了。模型在修Bug时容易陷入“局部调整”的循环比如改一个参数、换一个方法名但没有触及问题的根本原因。这时候继续让它试大概率是浪费时间。我的做法是停下来自己读一遍相关代码定位到具体哪一行有问题然后直接告诉模型“第X行的某个逻辑不对应该改成这样”。这种“人工定位模型执行”的模式效率比让模型自己摸索高得多。5.4 跨引擎迁移模型能不能举一反三第三天我做了个有趣的测试把Unity里验证过的“对象池”思路让模型迁移到UE5的C里实现。模型给出的UE5版本用了TArray和TQueue来管理对象核心逻辑和Unity版本一致但语法和API换成了UE5的。这个迁移过程它完成得不错说明它对“设计模式”层面的东西是有理解的不局限于某个引擎的具体API。但反过来当我让它把UE5的“事件驱动UI更新”思路迁移到Unity时它给出的方案用了Unity的UnityEvent这个选择是对的但它在UnityEvent的绑定方式上出了点小错——它试图在代码里动态绑定一个带参数的方法但UnityEvent的泛型版本需要显式声明参数类型。这个错误不影响理解但需要手动修正。6. 三天实测的结论与后续可扩展方向6.1 模型在游戏开发中的真实能力边界三天跑下来我对模型的能力有了比较清晰的认识。它在单文件逻辑代码、常见设计模式、API调用模板这几个方面表现很好基本能达到“初级开发者”的水平写出来的代码结构合理、命名规范稍作调整就能用。但在跨文件一致性、版本敏感API、数学物理计算、可视化编辑器操作这几个方面它需要人工把关。具体到两个引擎Unity的C#支持明显好于UE5的蓝图描述UE5的C支持又明显好于蓝图。如果你的项目重度依赖蓝图模型能帮你的主要是逻辑梳理和C底层实现蓝图连线还是得自己来。6.2 这套工作流适合什么样的开发者我觉得这套“提示词驱动人工验证”的工作流最适合两类人一是有编程基础但某个领域不熟的开发者比如你写惯了Unity想试试UE5模型可以帮你快速搭出可运行的骨架二是独立开发者或小团队人手有限用模型处理重复性的代码编写和Bug修复能把精力集中在核心玩法和体验上。但如果你是完全零基础指望模型帮你“一键做游戏”那大概率会失望。模型能写代码但它没法帮你理解代码为什么这么写出了问题也没法帮你系统性地排查。基础还是要自己打。6.3 后续可以继续测试的方向这次测试主要覆盖了2D射击和解谜房间两个类型后续我还想试试几个方向一是联网同步逻辑看模型能不能正确处理状态同步和延迟补偿二是程序化生成比如随机地图和关卡测试它在算法层面的能力三是性能优化专项给它一个帧率不达标的场景看它能不能定位瓶颈并给出有效的优化方案。另外这次用的是纯提示词驱动没有接任何插件或工具链。如果配合一些代码检索工具或者引擎的官方文档接口模型的表现应该还能再上一个台阶。这个方向也值得后续折腾。最后分享一个我在三天里养成的小习惯每次模型给出代码之后不管看起来多正确我都会先编译一遍再读逻辑。编译通过不代表逻辑对但编译不通过一定有问题。这个习惯帮我省了不少“读半天代码发现根本跑不起来”的时间。