这个系列的第一篇发出来之后不少朋友在评论区点名要策略与塔防篇。原因不难猜——策略塔防几乎是3D游戏开发里最吃“系统设计”的品类寻路、波次、数值、AI行为、相机手感哪个环节单拎出来都够写几千行代码。而这些东西偏偏又最适合交给大模型来打底稿。这一篇我整理了10条我自己在Unity和Godot项目里反复调过、真正能落地的提示词不是那种一问就给你甩一大段理论废话的写法而是每条都带着明确的输出约束和边界条件。看完你可以直接复制去用也可以按我说的方法改成自己项目的版本。我自己试过最舒服的使用姿势是先用这10条把项目从零快速搭出一个可玩的demo再花时间在真正的调参和玩法打磨上。毕竟策略塔防的乐趣在“设计”不在“打字”。1. 先聊思路策略塔防的“AI肥肉”在哪提示词怎么咬得动很多人用AI写游戏代码最大的误区是把大模型当成搜索引擎问一句“怎么写塔防游戏”然后等着它给你糊一坨万能代码。结果大概率是拿回来一个在空场景里跑通、一到真实项目里就崩的“教学示例”。我在实际项目里的做法完全不一样我会先把一个策略塔防游戏拆成若干能独立描述、独立测试的系统然后针对每个系统写一条专门的提示词。1.1 策略塔防项目里最耗时、最适合AI介入的四块内容做策略塔防最花时间的绝对不是建模也不是某一个炫酷特效而是下面这四块敌人寻路与路径生成网格寻路、路径点插值、多路线分支这部分逻辑很标准、很模式化AI非常擅长。塔的数值体系伤害、射程、攻速、升级曲线、多技能组合本质上是一张巨大的配置表AI能把数据结构设计得明明白白。波次与敌人行为刷怪节奏、敌人类型搭配、Boss技能、状态Buff管理这些是事件驱动逻辑有固定模式可循。相机与交互手感3D策略游戏常见的RTS式相机、框选、拖拽、射线检测这类代码网上示例多得是AI基本没有知识盲区。这四个方向恰好也是AI提示词最容易发挥优势的地方因为它们都满足同一个条件需求可以被精确描述输出可以被验证。你告诉AI“寻路要避开高度差大于2格的区域”它能给你实现你告诉AI“做出好玩的游戏”它只会给你一堆正确的废话。1.2 一套提示词的通用写法角色设定 目标约束 输出格式 边界条件我总结了一套提示词公式这次系列里的10条基本上都是照着这个框架写的角色设定告诉AI你希望它以什么身份来回答资深Unity塔防主程、技术策划。任务描述要解决的具体问题是什么每一步要做什么越具体越好。约束条件限定语言、引擎版本、性能预算、不能用什么方案。输出格式要求它输出完整代码、配置表、伪代码还是设计文档。边界情况明确告诉它哪些情况要处理比如敌人卡住、塔被摧毁后引用丢失。这套写法看起来简单但大部分人对AI提示词的失败都源于前两步没做好。很多人说的是“给我一段敌人寻路的代码”而我通常会在提示词里写“给我一个适用于3D塔防的敌人寻路组件使用Unity NavMesh敌人需要沿着路径点移动当目标点不存在时回到上一个路径点并输出警告日志”——差别就在这里。2. 十把钥匙策略与塔防篇的提示词全量拆解这一节我把10条提示词按实际开发顺序排列从项目骨架到具体功能最后落到性能优化。每一条我都会给出可直接复制的提示词模板再讲清楚代码背后的核心逻辑和常见坑点。编号提示词定位解决的问题推荐优先级1核心玩法说明书建立塔防循环与系统边界先做2敌人寻路组件路径点移动与异常处理先做3塔基类与子弹系统攻击逻辑统一抽象核心4数值与升级曲线平衡性数据驱动核心5波次刷怪控制器事件驱动的波次管理重要6技能与Buff系统减速/溅射/穿透等效果重要7RTS相机控制3D场景观察与交互手感重要8关卡可读性检查摆塔位、路线、视野进阶9AI敌人Boss/精英行为树与技能切换进阶10性能预算方案DOTS/对象池/帧率优化收尾2.1 从产品骨架开始用一条提示词生成塔防核心玩法说明书先别急着写代码。我用过的所有项目里前期最值钱的就是一份清晰的核心玩法说明书。它能帮你和AI后续对话建立同一套词汇体系也能让你在写具体功能提示词时直接引用里面定义好的术语。提示词1核心玩法生成器你是一名拥有10年经验的塔防游戏技术策划正在为一个3D策略塔防项目编写核心玩法说明书。 项目基础设定低多边形卡通风格玩家建造炮塔抵御敌人从入口到水晶基地的进攻。 请输出以下内容 1. 核心玩法循环用“建造-战斗-收益-升级”四步描述 2. 系统边界哪些功能属于玩法系统、哪些属于战斗系统、哪些属于经济系统 3. 敌人类型表至少5种包含名称、定位、特殊能力、设计意图 4. 塔类型表至少5种包含名称、定位、攻击方式、升级方向 5. 资源经济曲线初始资金、杀敌奖励、波次奖励、升级消耗的增长逻辑 要求每个系统之间用短横线分隔不要输出任何代码只输出设计文档总字数控制在1500字以内。这条提示词的设计思路是先建立领域语言再谈实现。当你后续问AI“帮我写一个带减速效果的塔”时AI会自动引用这套说明书里你已经定好的“冰霜塔”设定而不是自己发明一套新东西。如果你跳过这步直接把AI当作代码生成器很容易出现不同脚本里名词对不上、同一个功能在System A里叫SlowField、在System B里叫FrostZone的问题。实际跑完这条之后你会得到一份可以直接放进开发wiki里的设计文档。我在项目里还会额外要求它输出一份“名词-模块对照表”方便之后在每一条功能性提示词里直接引用。2.2 敌人寻路、塔基类、子弹系统、数值曲线、波次管理——从零搭建塔防战斗循环这一小节的五条提示词是整个系列的核心。它们解决的是塔防游戏里“敌人能走、塔能打、数值能调、波次能出”的最小可玩闭环。我只挑最关键的部分讲每条提示词后面都是可以直接用的模板。提示词2敌人寻路组件在Unity 2022.3中为一个3D塔防游戏创建敌人寻路组件。 要求 1. 使用NavMesh作为寻路基础但敌人必须沿预先设定的路径点PathPoint移动不使用NavMeshAgent的自动寻路完成整个路径。 2. 敌人脚本包含以下字段移动速度、当前路径点索引、到达判定距离。 3. 当敌人到达最后一个路径点时调用生命值扣除接口、触发基地受击效果、销毁自身。 4. 当NavMesh路径计算失败或路径点丢失时输出明确错误日志并让敌人停留在原地而不是随机乱走。 5. 提供C#完整代码包含必要的Unity生命周期方法。注意我特意强调“输出明确错误日志并停留在原地”这是实际项目里最容易踩的坑。如果你不给AI限定异常行为它默认的写法往往是让敌人停在原地或者干脆销毁停原地没有日志你在测试阶段根本不知道出了问题销毁更是直接让Bug被隐藏。让敌人停下来并大声报错错误才能早点暴露。这条提示词产出的代码结构大概会包含一个EnemyMovement脚本核心逻辑是GetNextPathPoint()和MoveToNextPoint()两个方法。我一般会在拿到代码后立刻做两件事把移动方式改成transform.position Vector3.MoveTowards(...)以规避物理引擎的干扰再手动加一个DrawGizmos()方法把路径点连线在Scene视图里画出来。后者对关卡设计极其有用你一眼就能看出哪条敌人路线不合理。提示词3塔基类与子弹系统设计一个3D塔防游戏的塔基类TowerBase和子弹系统Bullet。 要求 1. TowerBase使用抽象类包含攻击力、射程、攻速、目标锁定四个核心属性以及Attack()、UpdateTarget()两个虚方法。 2. 子弹Bullet使用普通类飞行速度可配置命中敌人后调用敌人受伤接口。 3. 塔在空闲状态时进行缓慢旋转用于表现索敌开火时暂停旋转命中后恢复。 4. 子弹飞行采用直线运动不追踪目标生成时朝目标方向发射。 5. 使用对象池管理子弹禁止频繁实例化和销毁。 6. 输出C#完整代码并标注性能关键点。这里的关键决策是子弹不追踪目标。很多新手写塔防时容易把子弹做成追踪弹但策略塔防的乐趣恰恰在于“预判”和“站位”——如果所有子弹都带追踪玩家绕后摆放的意义就弱了一半。我是故意在提示词里限定成直线弹道这样才符合传统塔防的玩法直觉。对象池也是显式要求如果让AI自己发挥它九成会为一个子弹一个Prefab Instantiate几百发打出去移动端直接卡成幻灯片。拿到代码后我建议你自己再加一个“塔头转向速度”和“开火前摇”参数。这两个数据对3D塔防的手感影响极大AI不会自己想到但你在提示词里提一句它就能很靠谱地实现。提示词4数值与升级曲线生成一份塔防游戏数值策划表使用JSON格式输出。 需求 1. 包含5种塔的基础数据攻击力、射程、攻击间隔、溅射范围、基础造价。 2. 每种塔有3级升级升级只提升攻击力、射程、攻击间隔中的一个或多个属性每级提升系数在1.2到1.5之间。 3. 敌人的生命值成长曲线第1波为100此后每波提升8%每5波出现一次精英怪生命值为同波普通怪的4倍。 4. 玩家初始资金为200普通怪击杀奖励波动范围为5到15精英怪固定奖励50。 5. JSON格式必须包含每个字段的中文注释。这条提示词适合所有想做平衡性的项目。我把它放在核心循环里是因为数值结构必须先行——一旦你写了十几二十个塔脚本才发现数值表设计得不行改起来就是灾难。JSON格式是我个人偏好的数据驱动方案它比ScriptableObject更通用也能直接在Excel里二次编辑方便策划同事动手。拿到输出后你会得到一份结构严谨的数值表但这里我必须提醒AI给的经济曲线大概率是线性拟合的不一定好玩。它的价值在于提供了一个可调整的基线你需要自己去跑几次试玩根据实际难度调整系数。我的经验是AI给的初始资金通常会偏多因为它在设计时默认AI的塔全部满级输出但真实玩家不可能做到。提示词5波次刷怪控制器实现一个3D塔防的WaveController。 要求 1. 支持波次配置从JSON读取每个波次包含敌人ID列表、生成间隔、生成位置、每波之间的等待时间。 2. 波次状态机包含4个状态Idle、Spawning、InProgress、Completed。 3. 波次开始后每隔一个可配置的时间间隔从刷怪点生成一个敌人生成间隔随波次递减但有限制下限。 4. 当场上敌人数量归零且本波敌人全部生成完毕后波次进入Completed状态。 5. 提供Unity事件OnWaveStarted、OnWaveCompleted、OnAllWavesCompleted。 6. 输出C#完整代码要求能直接挂载到空物体上使用。波次系统最容易出的Bug是“上一波都打完了下一波死活不来”——多半是状态机里InProgress到Completed的转换条件写错了。AI默认会遇到这个问题所以你干脆在提示词里一次写清楚转换到Completed必须同时满足“生成完毕”和“场上无敌人”两个条件少一个都不行。用UnityEvent暴露波次事件这一条也非常重要它让你的UI、音效、背景音乐系统都能挂在这个控制器上不需要在WaveController里写死任何表现层逻辑。我在实际项目里给这条提示词还额外加了一句话“在敌人全部生成完后用一个协程每0.5秒检查一次场上敌人数量而不是每帧检查。”AI非常吃这种具体指令——你喂的约束越细它输出的代码就越接近工程级质量。2.3 技能Buff、RTS相机、可读性、AI敌人、性能预算——让塔防从“能玩”到“好玩”如果说前面四条是骨架这一节五条就是肌肉和皮肤。它们不一定决定游戏能不能跑起来但决定了游戏有没有策略深度、观感是否专业、长期玩下去会不会卡。提示词6技能与Buff系统为3D塔防设计一个灵活的技能与Buff系统。 要求 1. 使用接口IBuff定义Buff行为包含BuffType减速/中毒/灼烧/穿透标记、Duration、TickInterval、OnApply、OnTick、OnRemove方法。 2. 敌人身上的Buff列表由BuffManager组件管理同一类型的Buff不重复叠加刷新Duration。 3. 子弹命中时通过BuffManager附加Buff支持一弹多Buff。 4. 减速Buff的效果可叠加但存在上限上限为80%移速。 5. 输出C#完整代码并附带一个冰霜塔使用该Buff系统的示例。Buff系统是策略塔防里最容易写成一团乱麻的部分。核心难点在于“管理”——谁添加Buff、谁负责移除、Buff过期后属性要不要还原、同类型Buff怎么处理这些边界条件AI不提示就一定会漏。我在提示词里显式写了“同类型不叠加、刷新Duration”这是因为实际游戏里冰霜塔往往不止一座如果两座塔同时攻击一个敌人不能让减速变成叠加到减速105%那敌人都倒着走了。拿到代码后我建议你重点检查OnRemove这个方法的实现。AI写Buff系统时最常见的Bug是Buff移除时没有把敌人的移速还原导致敌人被永久减速。这个Bug表现得很隐蔽因为单次战斗时间短你很难注意到某个敌人移速不对。提示词7RTS相机控制实现一个3D塔防游戏使用的RTS相机控制器。 要求 1. 支持鼠标右键拖动视角平移、滚轮缩放。 2. 相机始终指向地面点俯仰角限制在30度到70度之间。 3. 相机不能穿过场景中的地面和障碍物使用SphereCast检测碰撞。 4. 使用Cinemaachine的Framing Transposer作为基础实现。 5. 支持键盘WASD平移速度随缩放距离动态变化。 6. 输出C#完整代码和场景搭建步骤。3D策略游戏的相机手感是“玄学”级别的难题。Camera还做不好轻则玩家晕3D重则根本没法精确摆塔。我用的是Cinemachine方案——它已经帮你处理好了平滑跟随和碰撞你只需要关注输入映射和限制条件。提示词里写“速度随缩放距离动态变化”很关键否则你缩放到最高处时拖动视角会慢得让人抓狂。有一个细节我特意让AI处理了相机碰撞用SphereCast而不是普通的LineCast。因为相机离地面太近的时候LineCast只检测一个点很容易出现穿墙SphereCast用半径模拟相机体积效果自然很多。如果我直接要求AI“不要穿模”它会自己选一种射线方案可不一定是最适合的。提示词8关卡可读性检查设计一个3D塔防关卡摆塔检查工具。 要求 1. 通过射线检测判断鼠标悬停的位置是否允许摆塔地面必须有TowerSlot标签。 2. 塔与塔之间不能重叠使用SphereCollider检测半径可配置。 3. 塔的射程范围在摆塔时以半透明圆环显示。 4. 若鼠标悬停位置的塔位与敌人路径距离过近小于可配置的安全距离显示红色警告标识。 5. 输出C#完整代码。这条提示词直接服务关卡设计。很多塔防Demo看起来简陋不是美术不行而是“能不能摆塔”这件事本身就很模糊——玩家点一下没反应也不知道为什么不能摆。这个工具的核心价值在于三个可视化反馈可以摆高亮、不能摆红色、射程预览圆环。这就够了。“与敌人路径距离过近”这个检查项是我个人很看重的设计——它防止玩家把塔堵在敌人行进路线上让关卡设计者能直观地看到走廊宽度是否合理。AI一开始可能会忽略这个需求所以我在提示词里显式写出来。最终它输出的代码里会有一个OnDrawGizmos方法这个方法是整个工具的灵魂。提示词9AI敌人生成器为一个3D塔防游戏设计精英敌人和Boss敌人的AI行为。 要求 1. 使用简单的状态机包含Idle、Move、Attack、Skill、Return五个状态。 2. 精英敌人具备技能冲锋加速冲向基地冷却时间12秒。 3. Boss具备技能召唤小怪每10秒召唤2只当前波次的普通怪。 4. 状态切换需要满足条件且带有冷却禁止同一帧内反复切换。 5. 使用协程实现技能动作技能期间敌人可以继续移动但移动速度降低50%。 6. 输出C#完整代码。塔防里的敌人AI和动作游戏完全不同——它的“智能”体现在技能设计与行为切换而不是寻路。这条提示词我也花了不少心思在设计状态切换的条件上。AI写状态机时如果状态转换条件不清晰会出现“抽搐式移动”——每帧在Move和Idle之间反复横跳。所以我在提示词里写明了“带有冷却、禁止同一帧内反复切换”。技能期间“移动速度降低50%”是我后来加的因为实际试玩时发现Boss放技能如果还可以全速移动玩家会感觉特别不公平。这个调整非常小但对玩家体验的改善非常明显。提示词10性能预算与对象池对一个Unity塔防项目进行性能预算分析并给出优化建议。 假设项目规模同时在场敌人上限50个塔30座子弹200发使用URP渲染管线。 要求 1. 列出场景中可能成为性能瓶颈的5个关键点。 2. 对每个瓶颈给出具体的解决方案优先推荐ECS/DOTS、GPU Instancing、LOD、对象池等技术。 3. 针对大量子弹和敌人的场景给出一个使用Job System进行位置更新的代码示例。 4. 性能预算目标移动端保持30FPS。 5. 输出格式问题描述、原因分析、解决方案、代码示例。这一条是整个系列里唯一不直接生成功能代码的提示词但它的价值不亚于前面任何一条。性能问题在塔防里极其常见——50个敌人50个GameObject、30座塔30个粒子系统、200发子弹200个实例化一层层叠下来移动端必卡。我故意在提示词里给了非常具体的假设数据因为性能优化没有上下文就是空谈。AI的输出质量很大程度上取决于你给的约束有多具体。直接问“怎么优化Unity塔防性能”得到的是“减少DrawCall、使用对象池”这种百科全书式回答但当你告诉它“50个敌人30座塔200发子弹目标30FPS”它就能告诉你“Update里不要用Transform.position赋值改用Job System批量处理位置计算”。这个差距就是工程级答案和教程级答案的差别。3. 提示词怎么在真实项目里落地工作流才是关键拿到十条提示词只是第一步。接下来我聊一下我是怎么把这套提示词嵌入日常开发流程的免得你复制过去之后发现代码和项目“八字不合”。3.1 让AI输出你能直接用的代码先要懂得“投喂上下文”大模型没有记忆这是它最大的短板。你上一条让它设计了塔基类下一条让它写子弹系统如果第二条不主动告诉它你已有TowerBase这个类它很可能重新发明一个TurretController出来。所以我每次写提示词都有一个固定动作先粘贴相关脚本的关键声明和字段再提需求。比如在跑子弹系统之前我会先把敌人脚本里TakeDamage(int damage, IBuff buff)这个方法的签名粘给AI再让它写子弹命中逻辑。这一步看似繁琐但能省掉你后来大量的“接口对接”工作。我见过太多开发者从AI手里拿到代码结果发现函数名对不上反而要自己改半天接口——那还不如自己写。3.2 配合IDE与Git的工作流AI生成内容如何安全融合另一个我很坚持的做法是从AI手里拿到的代码先放进Assets/AIGenerated/目录不直接覆盖项目里已有文件。跑得通了、确认和现有架构兼容之后再挪到正式目录然后立即提交一个Git版本。这看起来多此一举但好处是万一AI代码搞坏了某个模块你的回滚成本是零。除此之外我在Unity里还会把AI生成的脚本都挂在一个临时测试场景里跑验证以下三件事再往正式场景迁移生命周期方法没有报错OnEnable/OnDisable成对出现编辑器模式下不产生异常日志引用关系没有断比如塔射出来的子弹撞到自己这套流程听起来保守但实际用起来很顺手。AI是效率工具不是替你拍板的人。你花3分钟验证它的输出比事后花30分钟改Bug划算多了。4. 实战中绕不开的坑与排查技巧最后聊聊我用这些提示词在真实项目里踩过的坑。虽然每条提示词都加了约束但AI毕竟是概率模型输出翻车在所难免。这一节我列几个典型的案例附上我的排查思路和修复方法。4.1 常见的四种翻车现场及修复方法现象根因排查思路修复方法敌人卡在墙角不停抖动寻路逻辑每帧重算目标点查看日志是否有重复的Move指令增加到达判定距离路径点切换加最小间隔塔发射的子弹穿模子弹移动用Transform每帧累加碰撞体没开Continuous观察子弹在高速移动时是否会跳过碰撞改用Rigidbody.MovePosition或开启碰撞检测Continuous波次刷出一半就停了判断“场上无敌人”时把未生成的敌人也算进去了检查WaveController的状态转换日志明确区分“已生成敌人”和“应生成敌人”高速移动物体出现阴影闪烁阴影距离参数过大ShadowMap分辨率不足查看Profiler中Shadow相关开销调整Shadow Distance和Shadow Cascades先说第一个敌人卡墙角是我在所有塔防项目里遇到最多的AI翻车现场。如果你让AI自己实现路径点跟随它大概率每帧都朝着当前路径点移动一旦路径点被其他碰撞体挡住敌人就会卡在原地不停抖动。排查时打开日志看有没有“到达路径点”的重复输出然后直接把到达判定距离从0.1改成0.5多数情况下立竿见影。第二个子弹穿模问题在3D游戏里尤其常见因为子弹飞行速度一快每帧位移就超过了碰撞体的厚度。我一般会在提示词里直接要求“子弹使用刚体而非Transform移动”如果AI漏了你自己加一行Rigidbody.MovePosition就行。4.2 让AI提示词的输出效果更稳定的三个习惯最后分享几个能显著提高AI输出稳定性的使用习惯都是我反复试错之后留下的每一条提示词都要求输出“注意事项”章节让AI自己告诉你它哪里可能不完善这样你测试时会更有针对性。对AI生成的代码保持“怀疑但友好”的态度第一版代码永远只是初稿你必须完整读一遍再合入项目。把好用的提示词沉淀到团队共享文档里配合实际项目修改和迭代。我自己的提示词库已经迭代了三个版本每一版都比上一版多出一堆“边界条件”和“约束细节”这也让AI生成的质量越来越高。跑完这一整套流程之后你会发现AI提示词的效果不取决于你用了哪个大模型而取决于你愿意把多少项目上下文喂给它。一段带完整上下文和明确约束的提示词产出的代码质量几乎是“裸问”的十倍以上。我个人现在比较习惯的做法是每次新建一个系统前花15分钟把该系统的背景、数据结构、已知边界条件写进提示词然后让AI生成第一版再花30分钟读代码、改接口、补齐极端情况。这其实比从零手写快得多更关键的是它能逼着你在动工前想清楚“这个系统到底需要什么”——写提示词这个动作本身就是一次设计梳理。如果你也正在做策略或塔防方向的3D项目不妨直接用这10条去跑一轮跑不通的地方再回来对照这篇文章里的排查思路多半能省掉不少弯路。