微信小游戏要上春节活动运营提前两天提需求整套 UI 换皮肤。主界面、弹窗、按钮、活动横幅加起来几十个资源。设计师给的是 Figma 和 PSD 原文件图层、尺寸、命名、切图标注都在里面但按老办法开发得手动逐张导出、缩放、压缩、命名再塞进游戏工程里反复对尺寸、路径和九宫格。于是有人开始尝试用 Codex 接入这套流程让 AI 根据原文件图层自动生成微信小游戏需要的美术资源并继承图层的尺寸和命名把换皮肤从“按天计算”压缩到“按小时计算”。我的判断很明确Codex 在这里真正解决的问题不是“AI 一秒画出一张新图”而是把“设计稿到游戏资源的确定性转换”固化成一个可复用、可批量、可追踪的工程流程。这套流程想跑通关键不在于 prompt 写得多花哨而在于资源规范是否清晰、图层尺寸能否被结构化解构、以及有没有建立从单样本验证到批量生成的节奏。1. 先搞清楚 Codex 在这里不是“画图”是“把设计稿变成工程资源”1.1 传统 UI 换皮肤为什么这么慢大多数微信小游戏在 UI 换肤时走的还是手工流水线设计师在 Figma 或 Photoshop 里完成一套节日皮肤导出 PNG 或切图到本地开发拿到文件后把按钮、弹窗背景、活动入口图标等资源挨个放到对应目录再用图片压缩工具处理一遍如果游戏用了字体、九宫格或多分辨率适配还要额外确认参数。这套流程的最大瓶颈不是美术创作而是重复转换。一次节日活动少则十几个资源多则几十个每个资源都有尺寸要求、命名要求、路径要求。手工操作时命名错一个字母、切图忘勾选透明通道、按钮多了一个像素的白边都会在真机预览里暴露出来。更麻烦的是一个按钮通常有普通态、按下态、禁用态三张图都要一一对应。这类工作技术上不难但极其消耗时间而且容易在重复劳动中出错。工作室越大接入的游戏版本越多这种“转换成本”就越不可忽略。1.2 Codex 的本质是编码 agent不是绘画模型很多人一听到“AI 生成美术资源”会本能地以为是让 AI 凭空画一套皮肤。实际上Codex 作为编码代理擅长的不是自由创作而是执行确定性任务读取文件、遍历目录、按规则处理数据、调用工具、写出结果。在这个场景里Codex 要做的是读取 Figma 导出数据或 PSD 图层信息按照定义好的命名规则从原文件中找出对应图层根据图层原始尺寸导出资源不重新缩放、不改变坐标基准生成微信小游戏可用的图片文件和资源配置把重复劳动写成可复用的脚本或 prompt 模板。换句话说它更像一个“严格按照设计稿施工的自动化产线”而不是“自由发挥的美术外包”。这也是为什么标题里“继承图层的尺寸”才是核心——AI 不是凭感觉生成一张相似图片而是必须从原文件中拿到精确的图层尺寸、位置和可见性信息。1.3 主判断规则越清晰AI 执行越稳定我观察到的现象是用 Codex 做这类任务效果好坏的分水岭往往不在模型能力而在任务被定义得是否清楚。给一句“帮我生成一套春节皮肤”大概率会得到一堆不可控结果但如果给出“读取 design/spring/ 目录下的画板把名为 btn_confirm 的图层导出为 196x72 的 PNG放到 assets/ui/spring/ 下命名保持 btn_confirm.png”任务就变成了可执行、可验证的工程操作。所以主判断可以收束成一句话Codex 在 UI 换肤中的价值是把“设计稿到游戏资源”的转换规则固化下来规则越清晰批量执行越稳定节日运营的响应速度才真正提得上。2. 一次可落地的流程从 Figma/PSD 原文件到微信小游戏资源2.1 先统一设计稿和资源规范否则一切免谈在让 Codex 处理任何设计稿之前第一件事不是写 prompt而是定规范。常见实践里我会先检查三件事画板命名每个界面或弹窗是否有独立画板画板名字是否和游戏界面模块对应图层命名按钮、背景、图标、文字图层是否分开命名是否包含中文、空格、特殊符号尺寸策略设计稿里的基准尺寸是多大目标平台的资源需要按 1 倍、2 倍还是 3 倍导出。下面是一份常见的资源规范示例可以直接拿去调整资源类型命名规范尺寸要求导出格式普通按钮btn_confirm_normal按画板原始尺寸PNG 透明通道按压按钮btn_confirm_press与普通态一致PNG 透明通道弹窗背景popup_bg按画板原始尺寸PNG 或 JPG图标icon_coin建议统一 64x64PNG 透明通道活动横幅banner_spring按画板原始尺寸PNG为什么要做这一步因为 Codex 能不能稳定找到图层取决于图层的可识别性。命名一旦混乱AI 只能靠猜靠猜的结果就是资源错位、漏切、文件名不对。2.2 让 Codex 拿到设计稿数据而不是“看图”这一步是整个流程的关键。Codex 要精确切出资源不能只靠视觉理解一张大图它需要拿到结构化的图层数据。如果你的设计稿在 Figma 里常见路径有两条通过 Figma 的 MCP 服务让 Codex 直接读取画板、图层的结构信息通过 Figma 的导出功能把图层信息整理成 JSON 或设计 token再交给 Codex 处理。如果设计师交付的是 PSD 原文件通常会先用解析脚本读取图层组、切片、图层尺寸和可见性输出一份中间 JSON。Codex 再基于这份 JSON 去裁剪、导出、命名。我建议的通用中间格式大致长这样{ source: design/spring/, canvas: { width: 750, height: 1334 }, layers: [ { name: btn_confirm_normal, width: 196, height: 72, x: 277, y: 620, visible: true, type: image } ] }有了这种结构化数据Codex 才能做到“继承图层尺寸”而不是靠截图后自己估算像素范围。这里要注意如果原始材料里没有明确给出某个格式的官方支持说明那么最稳的做法是先把图层导出成中间 JSON再用通用脚本处理而不是直接依赖某个闭源工具链。2.3 把 prompt 当成“任务说明书”来写和 Codex 协作时prompt 不是作文而是一份任务说明书。我会把任务拆成三个部分输入、处理要求、输出约束。一个最小可用的 prompt 模板大致是任务读取 design/spring_festival 下的图层 JSON按照 resources/skin_spring.json 中的配置生成微信小游戏 UI 资源。 处理要求 1. 只导出配置中出现的图层 2. 导出尺寸必须等于图层原始 width/height 3. 输出文件名统一使用配置中的 name 字段 4. 生成 assets/ui/spring/ 目录下的资源文件 5. 同时生成一份 skin_spring.json记录每个资源的名字、路径、宽高。 输出格式PNG透明通道保留。这类 prompt 看起来不花哨但它把 AI 的行为边界锁住了。Codex 能写出错误执行代码但如果你给它明确检查项它就会在完成前自行核对尺寸和路径。更建议的做法是在 prompt 末尾加一句“完成后列出每个资源的原始尺寸与导出尺寸的对照结果”这样后续检查就有一份现成记录。2.4 先用一个弹窗跑通样本不要急着批量生成很多人一开始就想着“让 Codex 把所有资源全部生成”这是一个容易翻车的做法。正确的第一步是选一个中等复杂度的弹窗包含背景、按钮、关闭图标、文本图层先完整跑一遍。验证内容至少包括导出 PNG 是否能正常打开透明通道是否正确尺寸是否等于原图层尺寸多倍资源是否按预期缩放文件名和配置里的 name 是否完全一致放进微信小游戏工程后界面是否保持在设计稿预期的位置。只有这个样本完全通过再去扩展批量任务。这个“先单样本、再小批量、后全量”的顺序在任何自动化流程里都值得坚持。Codex 不是不能一次跑很多而是当任务量级变大时错误也会同步放大先跑通一个样本能大幅降低排查成本。3. 为什么“继承图层尺寸”是这套方案最关键的设计约束3.1 尺寸一旦漂移游戏内表现会立刻失控在微信小游戏里UI 资源的位置、大小、点击区域都依赖精确的宽高和坐标关系。一个按钮如果在设计稿里是 196x72但导出后变成了 200x80热区就会扩大视觉上可能看不出来手指点击时却会偶尔点错。一个弹窗背景如果被压缩了 2 个像素文字边缘可能就会出现 1 像素的裁切。这也是为什么“AI 生成美术资源”不能简单理解为“用一张看起来像的图替换原来的图”。游戏资源不是海报不要求像素级完全一致但要求位置、尺寸、命名、透明通道、九宫格这些工程属性全部正确。尺寸漂移表现就会偏离设计稿预期后续所有适配都会跟着偏。3.2 Codex 怎么做到尺寸继承从工程经验看尺寸继承的本质是让 Codex 操作的是“图层对象”而不是“整张位图”。代码逻辑上它需要读取每个图层的 x、y、width、height、visible、图层类型等字段然后以这些字段为依据做导出。一个典型的处理链路是原始图层信息 - 裁剪目标图层 - 按原始尺寸导出 - 生成资源配置 - 游戏内引用在这个过程中Codex 还会做一件事把所有资源的关键信息写入配置文件。这样后续换皮肤时游戏代码不需要改动只需要加载新的资源配置即可。源图层字段导出资源配置文件字段name文件名后缀namewidth / height图片尺寸width / heightx / y位置参考offsetX / offsetYvisible是否导出visibleopacity透明度opacity这也解释了为什么“继承图层的尺寸”不是一句营销口号而是决定方案能不能用的工程前提。3.3 尺寸偏差通常出现在哪里即使流程跑通了尺寸偏差依然可能出现在几个环节设计稿 DPI 和导出 DPI 不一致Figma/PSD 里的自动布局让图层实际渲染尺寸不等于图层定义尺寸导出时按 3 倍缩放但游戏内只用了原始坐标导致位置偏移图层带有旋转、缩放变换导出时没有做矩阵换算中文字体缺失导致文字图层导出后变大或变窄。排查这类问题我的顺序是先看输入 JSON 里的 width/height 是否正确再看导出脚本是否直接使用这些字段再看游戏内引用的是不是配置里的数值最后看真机预览而不是只在编辑器里看。3.4 建议的检查链路从源字段到真机预览如果你遇到资源尺寸不对或者界面对不上可以按这个链条排查检查中间 JSON 中的图层 width/height确认它和设计稿画板面板上的数值一致检查裁剪脚本是否使用了“图层实际渲染区域”而不是“画板整体”检查导出时是否无意做了 2 倍或 3 倍缩放检查资源配置文件是否真的记录了导出尺寸而不是用了设计稿默认尺寸在微信开发者工具里看坐标再用真机预览确认。注意不要只看一张图“看起来差不多”就跳过配置校验。UI 资源最怕的不是画错而是坐标、尺寸和实际显示不一致。4. 节日运营的一键换肤把单次替换升级成可复用流水线4.1 一键换肤的本质是“更换资源配置”如果只是临时做一个春节皮肤那手动处理也还能忍。真正让团队下定决心用 Codex 的是节日运营的“高频重复”春节、元宵、情人节、周年庆、暑期活动几乎每个月都要换一次。一键换肤的本质不是“自动重画”而是把皮肤抽象成一套资源配置。Codex 每次做的事其实是基于新的设计稿生成一套皮肤映射表然后按照映射表输出资源。游戏代码本身不感知皮肤只读取当前配置。一个简化版皮肤配置大概是{ skin: spring, resRoot: assets/ui/spring/, items: [ { name: btn_confirm_normal, path: btn_confirm.png, width: 196, height: 72 }, { name: popup_bg, path: popup_bg.png, width: 580, height: 780 } ] }Codex 生成完整个目录和配置后开发要做的事情就是切一个开关游戏里自动加载这套皮肤。4.2 把 prompt 模板沉淀成项目资产这时最有价值的一件事是把每次使用的 prompt 沉淀成模板并和设计稿规范放一起。模板里固定的是任务边界、目录结构、命名规则、输出检查项可变的是活动名称、设计稿路径、输出皮肤名。建议的工程目录结构是project/ design/ spring_festival/ summer_carnival/ resources/ skin_spring.json skin_summer.json scripts/ export_ui.py resize_check.py prompts/ export_skin_template.md每次运营活动开始时从前一个活动的皮肤复制一套替换设计稿路径和皮肤名跑一遍样本再全量生成。这种做法的好处是经验被留在了项目里而不是停留在某个人的聊天记录里。4.3 团队分工设计师定视觉Codex 做转换开发做验收一键换肤不等于全自动上线。合理的分工是设计师负责设计稿、图层命名、画板规范Codex负责资源转换、命名整理、配置生成开发负责资源审查、坐标确认、真机验证和版本发布。关键资源主按钮、弹窗背景、入口图标建议人工过一遍。其他批量小图标、分隔线、装饰元素可以在自动化校验后使用。引入一个简单的校验脚本也会很有帮助比如检查输出的 PNG 尺寸是否和配置一致目录中是否有缺失文件。4.4 运营发布节奏提前一天、小流量灰度、可回滚即使 Codex 把资源生成速度提上来了发布节奏依然要稳。我更建议先提前一天完成资源生成然后在开发者工具里做一次冒烟验证再用“小流量灰度”方式发布。微信小游戏有完整的版本和灰度能力不需要一次全部切换。注意保留旧皮肤配置。一旦新资源在真机上出现位置偏移、点击异常或加载报错能第一时间切回上一版本而不是现场重新生成资源。5. 最容易出问题的五个环节排查链路与工程化边界5.1 先按这个顺序排查输入、环境、权限、参数、日志我在使用 Codex 做资源导出时遇到过的问题大多集中在这几个层级。排查时不要跳着查按顺序可以少走弯路输入层设计稿是否导出成功JSON 是否生成图层是否被正确命名环境层Codex 版本、Node/Python 依赖、MCP 服务连接是否正常权限层目标目录是否有写入权限文件是否被占用参数层导出比例、命名规则、资源路径是否和模板一致日志层Codex 的执行日志是否有关键报错输出目录是否有半成品文件。如果 Codex 在请求过程中报错比如 API 请求失败或响应中断优先检查网络、账号状态和版本匹配再重试。重试前先降低批量任务数避免反复触发同样的问题。5.2 三类常见报错分别怎么处理MCP 连接类Codex 连不上 Figma MCP 时先检查设计稿访问 token 是否有效、服务地址是否可访问、Codex 配置里是否绑定了正确的 MCP 端口。改完配置后需要重启会话再试。文件读写类路径带中文、文件名带空格或特殊符号最容易导致脚本找不到图层或输出失败。遇到这类问题先统一改成英文和下划线命名。输出异常类导出的图片尺寸不是预期值优先看裁剪逻辑是否按图层原始尺寸执行资源为空优先看图层 visible 属性和命名匹配是否准确。5.3 哪些资源适合全自动哪些必须有兜底不是所有美术资源都适合交给 Codex。基于资源类型和出错风险可以做一个简单分类适合自动化需要人工兜底按钮普通态/按下态创意主视觉、节日海报弹窗背景复杂动效、粒子特效图标、分隔线、横幅涉及版权或敏感素材多尺寸切图需要人工判断情感的交互反馈图判断标准很简单如果这个资源“尺寸正确、命名正确、文件格式正确”就等于完成那就可以自动化如果还需要创意判断、情感表达或合规确认那就要人参与。5.4 长期维护版本锁定、资源入库、保留回滚点工具链一旦跑通长期维护要考虑的不再是“能不能生成”而是“生成的东西可不可追溯、可不可回滚”。我的建议是锁定 Codex 版本和所使用模型的配置不要每次升级后默默改变行为把 design 目录、resources 配置、prompt 模板全部纳入版本管理每次批量导出前先保存一次“执行前状态”方便回滚把输出日志和资源清单一起提交后续出问题时可查。把这些做好之后节日换皮肤就从“一次临时开发任务”变成了“一个可重复调用的内部工具”。运营提需求设计师给文件Codex 按模板输出资源开发做验收。回到最初那句判断Codex 解决的不是“让 AI 画画”而是“把设计稿变成微信小游戏资源”这条重复、琐碎、容易出错的路径真正变成一条自动化流水线。它的价值不在一次生成多惊艳而在每一次生成都可预期、可复用、可追溯。如果想尝试建议不要一上来就做整套皮肤。先挑一个弹窗把设计稿 JSON 准备好让 Codex 导出一张按钮、一张背景检查完尺寸和命名后再铺开。先跑通最小样本再谈批量最后才有资格谈一键换肤。