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 = GetComponent<Rigidbody2D>(); } 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 Queue<GameObject> pool = new Queue<GameObject>(); 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变成linearVelocity，Input系统从旧的InputManager转向InputSystem包。模型默认输出的代码偏向旧版API，这在它训练数据的时间分布上是合理的——旧版API的语料更多。

解决办法很简单：在项目开始时就告诉模型引擎版本，并且在它输出旧API时及时纠正。我一般会在提示词里加一句“使用Unity 2022.3 LTS，优先使用当前版本推荐的API”。UE5那边也是类似，告诉它用Enhanced Input而不是旧的输入映射。

4.3 编译错误的排查思路

三天里遇到的编译错误大概有二十多个，我整理了一个排查顺序，基本能覆盖九成以上的情况：

这个表看起来基础，但实际排查时按顺序走一遍，比盲目改代码效率高得多。模型在修Bug时有时候会“过度修改”，把没问题的代码也改掉，所以我一般会让它先解释错误原因，确认理解正确之后再让它给修改方案。

4.4 模型“自信地犯错”的典型场景

有一种情况特别值得警惕：模型给出一个看起来完全合理、语法正确、逻辑自洽的方案，但实际跑起来就是不对。比如它给Unity写了一个“子弹碰撞后反弹”的逻辑，代码里用了Vector2.Reflect，参数看起来也对，但实际运行时子弹的反弹方向是反的。原因是它把入射向量和法线向量的顺序搞反了。

这种错误很难通过读代码发现，因为代码本身没有语法问题，逻辑推导也说得通，但物理意义是错的。我的应对方法是：对涉及数学计算和物理模拟的代码，一定要实际运行验证。不要因为代码“看起来对”就跳过测试。模型在数学直觉上偶尔会出偏差，尤其是向量运算和坐标系转换。

4.5 长时间运行后的输出质量衰减

第三天下午，我明显感觉到模型的输出质量在下降。同样的提示词，第一天它能给出结构清晰、注释完整的代码，第三天给出的代码开始变得零散，注释变少，有时候还会漏掉一些边界处理。

这不是模型“累了”，而是上下文里的噪声积累导致的。对话历史越长，模型在生成时受到的干扰越多。我的做法是：在第三天做了一次“上下文清理”，把之前的关键决策和当前项目状态整理成一段简短的摘要，作为新的系统提示重新开始。清理之后，输出质量明显回升。

这个经验对实际项目很有用：如果你打算长时间用模型辅助开发，不要指望一个对话窗口从头用到尾。定期整理上下文，把重要的信息提炼出来，该开新对话就开新对话。

5. 提示词工程在游戏开发中的实战心得

5.1 结构化提示词的模板

经过三天的摸索，我总结了一个比较通用的提示词模板，适用于Unity和UE5的日常开发任务：

【项目】Unity 2022.3 LTS，2D俯视角射击 【当前状态】已有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射击和解谜房间两个类型，后续我还想试试几个方向：一是联网同步逻辑，看模型能不能正确处理状态同步和延迟补偿；二是程序化生成，比如随机地图和关卡，测试它在算法层面的能力；三是性能优化专项，给它一个帧率不达标的场景，看它能不能定位瓶颈并给出有效的优化方案。

另外，这次用的是纯提示词驱动，没有接任何插件或工具链。如果配合一些代码检索工具或者引擎的官方文档接口，模型的表现应该还能再上一个台阶。这个方向也值得后续折腾。

最后分享一个我在三天里养成的小习惯：每次模型给出代码之后，不管看起来多正确，我都会先编译一遍再读逻辑。编译通过不代表逻辑对，但编译不通过一定有问题。这个习惯帮我省了不少“读半天代码发现根本跑不起来”的时间。