企业官网建设流程全解析

1. 三天连续运行到底测的是什么：先把实验边界划清楚

很多人看到"连续运行3天"这个说法，第一反应是"模型会不会崩""会不会忘事""上下文会不会爆"。这些担心都合理，但如果不先把实验边界定义清楚，测出来的结论就是一笔糊涂账。我在动手之前，先花了大半天时间把这次实测的变量固定下来，否则三天跑完你根本不知道哪个因素导致了结果差异。

1.1 为什么是"纯提示词驱动"而不是"AI辅助"

这里有个关键区分。市面上大量所谓"AI做游戏"的案例，本质是人在写代码，AI在旁边补全几行，或者人搭好工程骨架，AI填几个函数。这种模式里，人的架构能力仍然是主导，AI只是个高级自动补全。

而"纯提示词驱动"的意思是：我不打开Unity编辑器手动拖拽任何组件，不手写任何一行C#或蓝图节点，所有工程结构、脚本、场景配置、材质参数，全部通过自然语言描述让模型输出，我再把输出结果落到工程里。这个约束非常苛刻，因为它逼着模型去理解"一个能跑起来的游戏工程"到底需要哪些东西，而不是只生成一段看起来对的代码片段。

我选择这个约束的原因很直接：如果允许我手动搭骨架，那测出来的其实是"我+AI"的协作效率，而不是模型本身对游戏开发全流程的理解深度。我想知道的是，当把架构决策权也交给模型时，它能走多远。

1.2 三天时间是怎么分配的

连续运行不等于连续生成。我把三天拆成了几个阶段，每个阶段有明确的产出目标：

这个分配不是拍脑袋定的。Unity和UE5各占一半左右的时间，是为了做横向对照——同一个玩法需求，两个引擎的提示词策略差异在哪里，哪个引擎对提示词驱动更友好，这是本次实测最有价值的部分之一。

1.3 评测标准：什么叫"做出来了"

"能做出什么"这个问法太模糊。我给自己定了四条硬标准，任何一条不满足就不算成功：

• 可编译：生成的代码和蓝图能通过引擎的编译检查，没有语法错误和缺失引用。
• 可运行：打包或在编辑器内点击运行后，核心玩法循环能跑通，不崩溃。
• 可交互：玩家输入能正确驱动游戏状态变化，不是个静态场景。
• 可复现：换一台机器，按同样的提示词序列能重建出接近的结果。

这四条里，"可复现"是最容易被忽略但最重要的。如果每次生成结果都天差地别，那这套方法就没有工程价值，只能当玩具。

提示：做这类长周期实测，一定要在开始前把评测标准写下来。否则跑到第二天你会不自觉地降低标准，最后得出一个"好像还行"的模糊结论，没有任何参考价值。

2. 第一天：让模型先当架构师，而不是先当码农

第一天的核心心得只有一句话：别急着让模型写代码，先逼它把工程结构想清楚。我见过太多人一上来就说"帮我写一个角色控制器"，结果模型给出一段孤立的代码，你放进工程发现缺输入系统、缺相机引用、缺动画状态机，根本跑不起来。

2.1 需求拆解阶段的提示词设计

我用的第一版提示词大致是这样的结构：

你是一名资深Unity技术负责人。我要做一个俯视角动作游戏原型，核心玩法包括： 1. 角色八方向移动，带加速度和摩擦力 2. 三段连击的近战攻击，每段有独立的判定窗口 3. 敌人AI：巡逻、追击、攻击三个状态 4. 血条UI和伤害数字飘字 请先不要写任何代码。请输出： - 完整的模块划分和每个模块的职责 - 每个模块需要的脚本清单及脚本之间的依赖关系 - 推荐使用的Unity版本和关键Package - 你认为最容易出问题的三个技术点

注意最后那句"你认为最容易出问题的三个技术点"。这是我加的一个私货。让模型主动暴露风险点，比我自己去猜要高效得多，而且它列出的问题往往能提醒我一些没想到的坑。

实测下来，模型给出的模块划分相当合理：输入层、角色控制层、战斗系统、AI系统、UI系统、数据配置层，六层结构清晰。它推荐的Unity版本是2022 LTS，Package方面提到了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.Publish<T>(T evt) / EventBus.Subscribe<T>(Action<T> 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 两个引擎的提示词驱动适配度对比

跑完两边，我整理了一个对比：

结论是：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（按实际选一个） 已有核心接口：[粘贴契约文档] 本次任务：[具体需求] 约束：只使用上述接口，不重新定义已有类型；代码需可编译；如有性能隐患请标注 先输出你的实现思路和风险点，我确认后再写代码。

这个模板的核心是最后那句"先输出思路，确认后再写代码"。它把"生成"变成了"先对齐再生成"，返工率大幅下降。你可以直接拿去用，根据自己的项目改接口部分就行。