1. 先说结论为什么值得把PSD扔到一边如果你做过一段时间的游戏客户端八成经历过这样的日子设计师上午丢过来一张PSD说“主界面今天上线”然后你打开Cocos Creator对着图层一个个拖Sprite、设锚点、摆坐标、调字号再给每个按钮挂上点击事件。一个不算复杂的页面轻松去掉半天。中间要是设计师改了尺寸、换了按钮文案你还要把节点树里的坐标重新拉一遍纯手工活零技术含量但特别耗人。我自己的转折点是某个月排了三个新手引导界面实在拖不动了于是尝试让Codex一个能理解语义并生成代码的AI助手直接根据UI布局描述生成Cocos预制体。结果第一次跑通时我愣了半天一个包含背景、标题、按钮、进度条的预制体以前要一两个小时现在几十秒生成剩下的时间只花在校验和微调上。这篇文章不写原理层面的空话直接分享我用Codex生成Cocos预制体的完整路线预制体本质是什么、两种可落地的生成方案、踩过的坑以及怎样搭一条“UI描述→预制体”的流水线。不管你是Unity转Cocos的新人还是被UI还原折磨已久的老手这套思路都能给你一个减负的方向。2. 预制体到底是个什么东西Codex能下手的底层逻辑很多人觉得“让AI生成预制体”很玄其实拆开看就一句话Cocos的.prefab本质上是一个带类型信息的JSON序列化文件。Codex能写代码当然也能写JSON——只要它足够了解Cocos的序列化规则。2.1 组件树和序列化格式Cocos Creator 3.x里一个预制体通常由一组JSON对象组成对象之间通过__id__引用建立关系。简单理解就是一个节点对象有_name、_children、_components组件对象挂到节点上比如cc.Sprite、cc.Button、cc.Label。整体是一棵节点树根节点是一个cc.Prefab类型对象。看一个最小示例会直观很多[ { __type__: cc.Prefab, _name: UIRoot, _objFlags: 0, _native: , data: { __id__: 1 } }, { __type__: cc.Node, _name: UIRoot, _active: true, _parent: null, _children: [ { __id__: 2 } ], _components: [], _prefab: { __id__: 3 }, _lpos: { x: 0, y: 0, z: 0 }, _lrot: { x: 0, y: 0, z: 0, w: 1 }, _lscale: { x: 1, y: 1, z: 1 }, _layer: 33554432 } ]注意真实的Cocos预制体还包含很多细节字段比如_id、_globals、_prefab里的instance信息以及组件的_enabled、_materials等。但这些细节是死规则只要给Codex喂一个同版本的.prefab样例它完全能模仿着写出来。2.2 两种生成路线直接写JSON vs 写编辑器脚本理解了序列化结构就明白有两种路线可以让Codex参与路线一直接让Codex输出.prefab文件。你给它一份UI描述它照着标准格式生成JSON你保存成.prefab拖进项目。优点是路径最短缺点是Cocos的资源引用依赖UUID脚本组件和图片资源都必须有正确的__uuid__一旦UUID对不上导入后就是一片报错。路线二让Codex写一个Cocos Creator编辑器扩展脚本脚本读UI描述通过场景API动态创建节点树再调用编辑器API把节点保存成预制体。这条路多写一层代码但绕开了手写JSON的坑因为节点和组件都是引擎API创建出来的序列化由编辑器自己完成几乎不会出现格式错误。如果你是一开始接触我强烈建议走路线二。别被“直接生成”四个字迷惑稳定落地比看起来炫酷重要得多。后面实操我会把两条路都讲清楚但重点放在路线二。3. 实操让Codex生成第一个Cocos预制体先定一个小目标一张PSD上面有一个背景图、一个标题、一个按钮我们要用Codex把它变成Cocos预制体并让按钮能响应点击。3.1 准备UI描述文件PSD本身是图层文件Codex没法直接读所以第一步是把PSD里的关键信息抽出来整理成一份结构化的UI描述文档。格式随意JSON最方便。我习惯这样写{ name: MainMenu, designResolution: { width: 720, height: 1280 }, nodes: [ { name: background, type: Sprite, imagePath: res/background, x: 360, y: 640, width: 720, height: 1280 }, { name: title, type: Label, text: 勇者传说, fontSize: 72, x: 360, y: 900 }, { name: startBtn, type: Button, imagePath: res/btn_start, x: 360, y: 400, width: 400, height: 120, targetScript: MainMenuPanel } ] }这个文件就是“中间表示层”。设计师改PSD时只要把图层信息重新导出成这个JSON后续生成流程完全不用改。导出这一步可以半自动。用PS的动作脚本或者导出插件按图层名识别类型批量生成坐标和尺寸。我目前常用的是把PSD按图层切图同时让脚本输出一个类似上面的JSON。不用100%完美只要结构正确、坐标能对上Codex就有东西可吃。3.2 指令编写和运行接下来把这份JSON丢给Codex配上生成指令。指令不要只写“生成预制体”要给它足够上下文。我一般这样写你是Cocos Creator 3.x编辑器插件开发专家。请开发一个编辑器扩展脚本该脚本读取我给的外部JSON文件JSON结构如附件所示。要求遍历nodes数组为每个节点创建对应的Cocos场景节点。type为Sprite时添加cc.Sprite组件并根据imagePath从assets目录中找到对应的SpriteFrame资源。type为Label时添加cc.Label组件设置string、fontSize。type为Button时添加cc.Button组件和cc.Sprite组件。所有节点根据x、y设置位置设计分辨率与Canvas分辨率一致。最后通过编辑器API将节点树保存为名为“MainMenu”的预制体文件。 使用TypeScript编写符合Cocos Creator 3.x扩展规范。Codex会生成类似下面这样的代码简化版import { Editor } from cc; import { readFileSync } from fs; import { join } from path; export function createPrefabFromJson(jsonPath: string) { const data JSON.parse(readFileSync(jsonPath, utf-8)); // 创建根节点 const root new cc.Node(data.name); // 遍历节点 data.nodes.forEach((item: any) { const node new cc.Node(item.name); node.setPosition(item.x, item.y, 0); // 根据类型添加组件 if (item.type Sprite) { const sprite node.addComponent(cc.Sprite); sprite.spriteFrame getSpriteFrame(item.imagePath); } // ... root.addChild(node); }); // 保存为预制体 Editor.Message.request(scene, create-prefab, root); }这段代码不用完全照抄核心思路是让Codex帮我们把“机械化的节点创建逻辑”写出来。生成代码后在Cocos Creator里打开编辑器扩展菜单运行一遍项目资源管理器里就会多出一个MainMenu.prefab。3.3 把输出变成预制体如果你走的是路线一让Codex直接输出JSON那么需要把它保存为.prefab文件。但必须处理两个关键点图片资源的UUID引用和脚本组件的UUID。Cocos Creator中每个资源都有一个.meta文件里面记录了该资源唯一的uuid。预制体里引用图片时不是写路径而是通过cc.SpriteFrame的__uuid__字段引用。所以要么在描述JSON里提前填入所有资源的UUID要么让Codex生成一个“查找并填充UUID”的辅助脚本。实际做法先把需要用到的图片拖进Cocos Creator资源管理器让引擎生成.meta文件然后从.meta文件里复制UUID填到UI描述JSON里。Codex输出时它会把这个UUID原样写入.prefab。脚本组件更麻烦。比如我们希望点击按钮后执行一个名为MainMenuPanel的脚本逻辑预制体里必须挂上这个脚本组件并且脚本的__uuid__要和项目中MainMenuPanel.ts的meta一致。解决办法先手动创建一个临时脚本MainMenuPanel.ts让Cocos生成meta再把meta里的UUID提供给Codex。这样最终生成的预制体导入后就能正确关联。3.4 加入交互逻辑有了预制体不等于功能完成。按钮的点击事件有两种挂法一种是在预制体里直接添加cc.Button的click事件绑定绑定目标为挂载在根节点上的脚本组件另一种是预制体挂一个通用交互脚本由脚本在运行时动态注册按钮事件。我更推荐第二种。因为预制体里的event绑定同样依赖UUID如果脚本组件在生成时尚未编译或meta有变动事件绑定很容易丢。改成动态注册的话预制体只需要保证节点名字和结构正确交互在一个控制脚本里集中处理import { _decorator, Component, Node, Button } from cc; export class MainMenuPanel extends Component { start() { const startBtn this.node.getChildByName(startBtn); if (startBtn) { startBtn.getComponent(Button).node.on(Button.EventType.CLICK, this.onStart, this); } } onStart() { console.log(Start Button Clicked); } }这样就算Codex生成的预制体里没有预绑定事件只要节点命名符合约定控制脚本就能在运行时找到并监听。4. 进阶搭一套“UI描述→预制体”流水线单次生成解决了“这一个界面”的问题但游戏里界面几十个如果每个界面都让Codex手动跑一遍效率依然有限。所以下一步是把整个流程固化下来形成一套内部工具链。4.1 定义UI中间表示层这套工具链的核心是一个稳定的UI描述Schema。我目前用的是JSON Schema包含节点类型、层级、尺寸、锚点、资源路径、文本样式、脚本绑定等信息。定义好Schema后设计师或不熟悉代码的人也能在可视化编辑器里填写界面结构然后导出成一个标准JSON。Schema里可以定义的类型不要太多够用就行类型必需字段说明SpriteimagePath, x, y, width, height普通图片节点Labeltext, fontSize, x, y, color文本节点ButtonimagePath, x, y, width, height, target可点击按钮ProgressBarimagePath, x, y, width, height, percent进度条WidgetContainerlayout, children容器节点支持横向或纵向排列类型越少生成器的维护成本越低。如果项目里确实需要特殊组件再逐步扩充Schema。4.2 用Codex维护生成器脚本有了固定Schema生成器脚本本身也不需要每次重写。让Codex根据Schema文档生成一版V1的生成器之后Schema演进时直接把变更说明丢给Codex让它同步修改生成器。我试过一个比较顺的协作方式把生成器脚本、Schema样例、一个已经手工做好的预制体样例放进同一个目录Codex在修改代码时会对照样例输出保证生成结果和手工预制体风格一致。这等于给AI配了一个“质检标准”它能自己发现“生成的prefab里少了个Layer字段”这类问题。另外生成器脚本最好支持“批量生成”。把整个游戏的所有UI描述JSON放到一个目录下运行一个命令生成器逐个处理自动创建.prefab。某些团队甚至做成一键导入美术更新了PSD导出JSON后生成器自动覆盖旧的预制体并保留节点命名程序侧无需手动干预。4.3 从“生成”到“还原”的反向校验流水线跑起来后你会发现最常出问题的不是生成而是“改版”。设计师更新了界面如果直接重新生成整个预制体会覆盖掉程序后来加的运行时逻辑和少量手工微调。我的做法是让Codex同时生成一份“节点树比对报告”。生成新预制体前先读取旧预制体的节点树对比新增、删除、修改的节点生成差异预览。例如[CHANGED] startBtn position (400, 300) - (400, 280) [ADDED] titleLabel [REMOVED] versionLabel有了这份差异程序可以逐个判断是否接受改动避免一键覆盖酿成大错。Codex写这种差异分析脚本并不难关键是想起来加这个环节。5. 常见问题与避坑实录把这类“自动生成预制体”的方案推到实项目后会遇到不少让人头秃的报错。下面是我自己踩过且验证过解决方案的几条整理成速查表你能少走一半弯路。5.1 导入报错UUID不存在或资源失效现象生成的prefab拖进场景后控制台报错uuid not found或图片显示紫红色。原因预制体里引用的是图片资源UUID但项目里并没有生成这个UUID通常是因为资源路径写错、图片尚未导入或者.meta文件被删除。排查打开资源管理器确认资源确实存在。检查.meta文件确认UUID一致。在预制体JSON里搜索__uuid__看是否与.meta中一致。规避UI描述JSON里的imagePath不要填“想象中的路径”而是从资源管理器里复制实际路径再用脚本读取meta自动填充UUID比人工复制可靠得多。5.2 生成的节点坐标和设计稿对不上现象所有节点位置都跑偏尤其是不同分辨率下错位严重。原因设计稿坐标和Canvas的实际原点不对齐。PSD通常以左上角为原点Cocos的setPosition以节点中心为原点并且配合父节点的锚点。解决统一约定UI描述JSON里的坐标一律使用设计稿分辨率下的绝对坐标。生成器里做一次坐标转换比如const x item.x - designWidth / 2; const y item.y - designHeight / 2;这样坐标原点就变成屏幕中心和Cocos Canvas默认原点一致。5.3 脚本组件丢失或类型消失现象预制体导入后挂在节点上的自定义脚本组件不见了。原因序列化脚本组件时需要脚本的UUID。如果脚本meta文件尚未生成或脚本类名与文件不匹配Cocos无法完成反序列化。解决写完脚本类之后先让Cocos编辑器打开项目并等待编译完成确保meta文件生成。生成器脚本中通过资源管理器按文件名查询UUID再把UUID写入预制体。在预制体里保留脚本的__type__为项目脚本类型名同时提供__uuid__。5.4 版本迁移引发的格式差异现象项目从Cocos Creator 2.x迁移到3.x后原先写好的生成器生成的prefab导入3.x直接报错。原因2.x和3.x的prefab序列化结构差异很大尤其是资源引用方式、组件类型名、节点层字段。解决不要试图写一个兼容两个版本的生成器。维护两套生成器或者迁移时先用官方工具升级一个旧prefab然后用升级后的prefab作为Codex的新样例让Codex按新版格式重写生成器。提示让Codex生成预制体时必须明确告知它你用的Cocos Creator具体版本。同一个项目里3.6和3.8的序列化规则都有细节差异版本不对生成出的文件就是一个废文件。5.5 批量生成时覆盖了手工改动现象重新生成某界面预制体后之前手动加的Tween动画组件、自定义模板都没了。原因生成器默认“全量重建”把整个节点树推倒重来。解决生成器改成“增量更新”遍历旧节点树只更新同名节点的属性不删除额外组件。或者把手工改动抽离成独立脚本运行时再动态附加到节点上保证预制体本身足够“纯”方便随时重新生成。6. 个人体会和一点经验总结用Codex生成Cocos预制体这件事能做到什么程度完全取决于你怎么定义“AI替代手工”的边界。至少在我这边它已经把UI还原从“一两个小时的手工劳动”压缩到“几秒钟的生成几分钟的检查”。这个收益是实打实的。我最大的体会是与其说Codex在“生成预制体”不如说它在帮我们维护一个从“界面描述”到“引擎资源”的高效编译器。你需要做的是先定义清楚描述语言Schema再让Codex去实现和演化编译器。预制体本身只是编译产物真正值钱的是那套“让美术和程序都能轻松编辑的中间描述体系”。另外别指望AI一次生成的预制体完全符合所有人的标准。第一次跑通后我花了差不多一个下午去调生成器的细节——资源路径、锚点、坐标转换、脚本UUID填充——但一旦调完后面每个界面都在复用这套能力。前期的投入差不多两三个界面就能回本。最后分享一个小技巧在让Codex写生成器之前先手工用Cocos Creator制作一个标准的预制体项目导出成.prefab和.meta把它作为“参照物”一起放到Codex的工作目录里。Codex会自觉地去模仿这个参照物的序列化格式生成结果能少九成的低级报错。这个方法我用得很顺手也推荐你试试。