一段需求零素材，33个AI代理如何从零构建3D动作游戏原型

1. 从一句话需求到可玩原型：这个项目到底在做什么

先把这个项目的核心讲清楚。标题里说的“一段需求、零素材”，指的是整个项目的起点只有一段自然语言描述——大致意思是“做一个3D动作游戏，角色能跑能跳能打，有敌人、有场景、有基本战斗反馈”。没有现成的模型文件，没有贴图，没有音效，没有关卡设计文档，甚至连技术选型都没定。所有东西都是从这段文字里“长”出来的。

而“派了33个代理”这个说法，指的是用Claude Code这类具备多代理编排能力的AI编程工具，把一个大任务拆成33个子任务，每个子任务交给一个独立的代理去执行。这些代理有的负责生成3D模型，有的负责写角色控制器，有的负责搭场景，有的负责做UI，有的负责调物理参数。它们并行工作，最后把产物拼成一个能跑起来的游戏原型。

这个项目解决的核心问题是：当一个人既没有美术资源、也没有完整策划案、时间又极其有限的时候，能不能靠AI代理集群把一个3D动作游戏从零推到“可玩”状态。答案是可以，但过程远没有标题看起来那么轻松。它适合三类人参考：一是想了解多代理AI编程到底能做到什么程度的开发者；二是手里有创意但缺素材缺人力的独立创作者；三是想评估AI辅助游戏开发真实效率的技术负责人。

我先把结论放在前面：33个代理不是噱头，但也不是每个代理都在干“有意义”的活。真正决定项目成败的，是任务拆解的质量、代理之间的接口约定、以及人类在关键节点的干预。下面我会把整个项目的设计思路、核心细节、实操过程和踩坑记录全部拆开讲。

2. 整体架构与任务拆解思路

2.1 为什么选择多代理而不是单代理串行

单代理串行做3D动作游戏，最大的问题是上下文窗口会被迅速撑爆。一个3D动作游戏涉及的技术栈至少包括：3D建模与动画、场景搭建、角色控制、物理碰撞、战斗系统、敌人AI、UI系统、音效管理、关卡逻辑。如果让一个代理从头写到尾，写到战斗系统的时候，前面建模的细节早就被挤出上下文了，它只能靠“猜”来保持一致性，结果就是角色控制器和动画状态机对不上，物理碰撞体和模型尺寸对不上。

多代理的核心优势在于关注点分离。每个代理只负责一个明确的子领域，它的上下文里只需要装这个子领域的规范、接口和产物。比如负责角色控制的代理，不需要知道场景里有多少棵树，它只需要知道角色的碰撞体尺寸、移动速度范围、动画状态机的接口。这样每个代理的输出质量都会显著高于单代理串行。

但多代理也带来了新问题：代理之间怎么通信？产物怎么合并？接口怎么约定？这些问题如果不在拆解阶段解决，33个代理就会变成33个各说各话的孤岛。

2.2 33个代理的任务分配逻辑

33个代理不是随便拆的。实际拆解时遵循了一个原则：按“产物类型”拆，而不是按“功能模块”拆。因为功能模块之间有大量交叉依赖，而产物类型之间的依赖关系更清晰。

具体分配大致是这样的：

这个分配的关键在于：每个代理的输入和输出都是明确的文件或代码接口，而不是模糊的“你去做个战斗系统”。比如动画组的输出是标准化的动画状态机文件，程序组只需要按约定好的状态名去调用，不需要关心动画是怎么做的。

2.3 代理之间的接口约定

这是整个项目最容易被忽视但最致命的部分。33个代理如果各自用不同的命名规范、不同的坐标单位、不同的动画状态名，最后整合时就是灾难。

实际采用的方案是：在启动代理之前，先由人类定义一个接口契约文件，内容包括：

• 坐标单位统一为米，Y轴向上
• 角色碰撞体用胶囊体，半径0.4米，高度1.8米
• 动画状态名统一为：idle、run、attack_01、attack_02、hit、death
• 角色移动速度范围：2.0到6.0米每秒
• 攻击判定用球形检测，半径0.8米，持续0.2秒
• 所有资源文件放在assets目录下，按类型分文件夹

这个契约文件会作为每个代理的“系统提示”的一部分注入，确保所有代理在同一个规范下工作。实测下来，这一步花的时间不到半小时，但省掉了后面至少三小时的整合调试。

注意：接口契约一旦确定，中途不要轻易改。改一个参数，可能意味着多个代理的产物都要重新生成。如果确实要改，先评估影响范围，再决定是局部重跑还是全局重跑。

3. 核心环节实操：从零素材到可玩原型

3.1 3D模型与动画的生成方案

零素材意味着没有现成的fbx或glb文件。实际采用的方案是：用代码生成程序化模型，再通过骨骼绑定和关键帧生成动画。

角色模型方面，代理会生成一个基于基本几何体组合的人形模型。具体做法是用胶囊体做躯干，球体做头部，圆柱体做四肢，然后通过蒙皮算法把这些几何体绑定到一套标准人形骨骼上。这套骨骼的关节命名遵循通用规范，方便后续动画代理直接使用。

动画方面，代理会为每个状态生成关键帧数据。以跑动动画为例，代理需要定义：

• 一个完整跑动周期的帧数（通常24到32帧）
• 每个关键帧上各关节的旋转角度
• 根骨骼的上下起伏曲线
• 手臂和腿的摆动相位差

这些数据以JSON格式输出，再由整合代理转换成引擎可识别的动画文件。实测下来，程序化生成的动画在流畅度上不如手工K帧，但对于原型验证来说完全够用。如果后续要提升品质，可以在这个基础上做人工精修。

实操心得：程序化动画最容易出问题的地方是“脚底打滑”。原因是根骨骼的位移速度和腿部的摆动频率不匹配。解决办法是在生成动画时，根据角色移动速度反推步频，确保一个跑动周期内角色前进的距离等于两步的步长。

3.2 角色控制器的实现要点

角色控制器是3D动作游戏的手感核心。代理在实现时，需要处理以下几个关键问题：

移动与转向的解耦。很多新手会把移动方向和角色朝向绑死，导致角色只能朝前走。正确的做法是：移动方向由输入决定，角色朝向由移动方向插值决定。这样角色可以边跑边转向，手感更顺滑。

跳跃的土狼时间与输入缓冲。土狼时间指的是角色离开平台后仍然可以起跳的短暂窗口，通常0.1到0.15秒。输入缓冲指的是玩家在落地前按下跳跃键，系统会记住这个输入并在落地瞬间执行。这两个机制是动作游戏手感的关键，代理在生成代码时需要显式实现。

攻击的前摇、判定、后摇。攻击不能是瞬间生效的。一个完整的攻击动作分为三段：前摇（角色做出攻击姿势但还没有判定）、判定（攻击框激活）、后摇（角色收招，不能立即行动）。代理需要为每种攻击定义这三段的时间参数。以轻攻击为例，前摇0.15秒，判定0.1秒，后摇0.2秒。

受击反馈。角色被击中时需要有硬直、击退和无敌帧。硬直时间通常0.3到0.5秒，击退距离根据攻击力度决定，无敌帧在受击后0.5秒内生效，防止被连续击中。

这些参数不是拍脑袋定的，而是参考了同类动作游戏的常见数值范围，再根据原型的手感做微调。代理在生成代码时会把这些参数放在一个独立的配置文件里，方便后续调整。

3.3 敌人AI的行为树设计

敌人AI不需要太复杂，但也不能是站桩靶子。实际采用的方案是一个简化版行为树，包含以下节点：

• 巡逻：在指定范围内随机移动
• 察觉：当玩家进入视野范围（默认8米）且角度在120度内，切换到追击
• 追击：向玩家移动，保持攻击距离
• 攻击：当距离小于攻击范围（默认2米）时，执行攻击动作
• 撤退：当自身血量低于30%时，有概率后撤

行为树的每个节点都有明确的进入条件和退出条件，代理在生成时需要确保状态切换不会出现死循环。比如追击和攻击之间的切换，需要有一个冷却时间，防止敌人在边界距离上反复横跳。

常见问题：敌人卡在场景障碍物后面。原因是寻路算法只考虑了直线距离，没有考虑障碍物。解决办法是在追击节点中加入简单的避障逻辑，比如检测前方是否有障碍物，如果有则向侧面偏移。

3.4 场景搭建与光照配置

场景搭建代理的任务是根据概念设计生成一个可玩的关卡。零素材的情况下，场景由程序化生成的地形和道具组成。

地形方面，代理会生成一个高度图，然后用网格生成算法把它转换成3D地形。高度图的参数包括：地形尺寸（默认100米乘100米）、高度范围（默认0到10米）、平滑度（默认0.5）。这些参数决定了地形的起伏程度。

道具方面，代理会在地形上随机放置一些基本几何体作为掩体和装饰，比如立方体箱子、圆柱体柱子、球体石头。放置时会检测地形高度，确保道具不会悬空或埋在地下。

光照配置相对简单，一个平行光作为主光源，一个环境光作为补光。平行光的强度默认1.0，角度45度，环境光强度0.3。这个配置能保证场景不会太暗也不会过曝。

3.5 整合与测试流程

所有代理的产物生成完毕后，整合代理会执行以下步骤：

1. 检查所有资源文件的命名和路径是否符合接口契约
2. 把模型、动画、场景、UI按依赖顺序加载到引擎中
3. 运行一个自动化测试脚本，验证核心功能是否正常
4. 输出一份问题清单，记录哪些功能通过了、哪些失败了

测试代理会模拟玩家输入，执行一系列操作：移动、跳跃、攻击、被击中、击败敌人。每个操作都会检查预期结果是否达成。比如按下跳跃键后，角色是否在0.1秒内离地，跳跃高度是否在1.5到2.0米之间。

实测下来，第一轮整合通常会有20%到30%的功能出现问题，主要集中在接口不匹配和参数越界。这些问题会在第二轮修复中解决。

4. 常见问题与排查技巧实录

4.1 代理产物接口不匹配

这是最高频的问题。表现是：程序代理调用的动画状态名是“run”，但动画代理生成的状态名是“running”。或者程序代理假设角色碰撞体半径是0.5米，但模型代理生成的碰撞体半径是0.4米。

排查思路：先检查接口契约文件是否被正确注入到每个代理的上下文中。如果契约没问题，再检查代理是否在生成过程中“自作主张”改了命名。解决办法是在整合阶段加一个校验脚本，自动比对所有产物的命名和参数是否符合契约。

避坑技巧：在接口契约中，对每个关键参数都给出“允许范围”而不是“固定值”。比如移动速度允许2.0到6.0，代理可以在范围内自由选择，但不能超出。这样既给了代理灵活性，又保证了兼容性。

4.2 动画与物理不同步

表现是角色跑动时脚底打滑，或者攻击时判定框和动画不匹配。

排查思路：先检查动画的根骨骼位移曲线是否和角色控制器的移动速度一致。如果不一致，需要重新生成动画或调整移动速度。攻击判定不匹配的话，检查判定框的激活时间是否和动画的关键帧对齐。

解决办法：在整合阶段加入一个“同步校验”步骤，自动比对动画时长和物理参数。比如跑动动画的一个周期是1秒，角色移动速度是4米每秒，那么一个周期内角色应该前进4米。如果动画根骨骼位移只有3米，就说明不匹配。

4.3 敌人AI卡死或抖动

表现是敌人在某个位置反复切换状态，或者卡在障碍物后面不动。

排查思路：先检查行为树的状态切换条件是否有重叠。比如追击和攻击的距离阈值如果都是2米，敌人就会在2米边界上反复横跳。解决办法是给两个状态之间加一个“迟滞区间”，比如追击到1.8米才切换到攻击，攻击到2.2米才切回追击。

卡在障碍物后面的话，检查寻路算法是否考虑了障碍物。简单的解决办法是在追击节点中加入射线检测，如果前方有障碍物，就向侧面偏移一个角度再继续移动。

4.4 资源加载失败或丢失

表现是游戏运行时某些模型或动画不显示，控制台报“资源未找到”。

排查思路：先检查资源文件的路径是否和代码中引用的路径一致。常见问题是大小写不匹配，比如代码里写的是“Assets/Models/Character.glb”，但实际文件是“assets/models/character.glb”。解决办法是统一路径规范，全部用小写，用下划线分隔。

另一个常见问题是资源文件格式不被引擎支持。比如代理生成了obj格式的模型，但引擎只支持glb。解决办法是在接口契约中明确指定资源格式。

4.5 性能问题与优化方向

33个代理生成的产物合并后，可能会遇到性能问题。常见表现是帧率下降、加载时间过长。

排查思路：先用性能分析工具定位瓶颈。如果是模型面数过高，需要做减面处理。如果是动画数量太多，需要做动画合并或LOD。如果是场景道具太多，需要做批处理或剔除。

优化方向：对于原型来说，帧率稳定在30以上就够用了。如果达不到，优先降低模型面数和动画采样率，这两个对性能影响最大。

5. 多代理AI编程的真实效率与边界

5.1 哪些环节AI代理做得比人快

程序化生成3D模型和动画，AI代理的速度远超人类。人类建模师做一个角色模型可能需要几小时到几天，代理生成一个基本人形模型只需要几分钟。虽然品质粗糙，但对于原型验证来说，时间成本几乎可以忽略。

代码生成方面，角色控制器、敌人AI、UI系统这些逻辑明确的模块，代理的产出速度也很快。一个熟练开发者写角色控制器可能需要半天，代理几分钟就能生成一版可用的代码。

场景搭建和光照配置也是代理的强项。程序化生成地形和道具，比手动摆放快得多，而且可以快速迭代参数。

5.2 哪些环节AI代理仍然吃力

手感调优。动作游戏的手感是非常主观的东西，需要人类反复试玩和微调。代理可以生成一套参数，但“这个跳跃高度是否舒服”“这个攻击后摇是否太长”这些问题，只有人类能判断。

创意决策。代理可以生成一个场景，但“这个场景是否有趣”“敌人放在这里是否合理”这些创意层面的判断，代理做不了。它只能按照预设的规则生成，无法评估生成结果是否好玩。

跨模块的深度整合。虽然接口契约可以解决大部分整合问题，但一些深层次的耦合问题仍然需要人类介入。比如动画状态机和战斗系统的交互，如果出现边界情况，代理往往找不到根因。

5.3 人类在循环中的关键作用

这个项目能跑通，人类在三个节点上的干预至关重要：

第一，任务拆解和接口定义。33个代理怎么分、每个代理的输入输出是什么、接口契约怎么定，这些决策直接决定了项目能否整合成功。代理自己拆解的话，往往会拆出大量重叠或遗漏的任务。

第二，关键参数的决策。移动速度、跳跃高度、攻击范围这些核心手感参数，需要人类根据经验给出初始值，代理再在这个基础上微调。

第三，整合阶段的调试。当多个代理的产物出现冲突时，人类需要判断是改接口还是改产物，这个决策代理做不了。

实操心得：不要指望代理一次生成就能用。实际流程是“生成、验证、修复、再验证”的循环。第一轮生成能跑通60%的功能就算不错了，剩下的40%需要人类介入修复。但即便如此，整体效率仍然比从零手写高得多。

6. 如果你想复现这个项目，我会建议你这样起步

先不要一上来就开33个代理。从最小的可玩闭环开始：一个角色、一个场景、一个敌人、一套攻击。用3到5个代理把这条链路跑通，验证接口契约和整合流程是否可行。这一步大概需要半天到一天。

跑通之后，再逐步扩展代理数量。每增加一组代理，先定义好它的输入输出和接口，再启动。不要一次性把所有代理都开起来，那样出了问题很难定位是哪个代理的产物导致的。

接口契约文件要作为项目的核心资产维护。每次修改都要记录版本和影响范围。这个文件的质量直接决定了多代理协作的效率。

最后，保留人类试玩的环节。代理生成的游戏，最终是给人玩的。手感好不好、节奏对不对、难度是否合理，这些只有人类能判断。代理可以帮你省掉大量重复劳动，但“好玩”这件事，仍然需要你自己把关。

我在实际跑这个流程的时候，最大的体会是：多代理AI编程的上限不取决于代理本身有多强，而取决于你把任务拆得有多清楚。拆得越清楚，代理的产出越可靠；拆得越模糊，整合阶段就越痛苦。33个代理不是目的，把一个大问题拆成33个可独立解决的小问题，才是这个项目真正有价值的地方。