项目 1 · 产品策划案
关联PR：#2
一、Windup 是什么
Windup 是面向缺乏美术产能的个人开发者与小型团队的 2D 角色素材生成资产工作台,覆盖从角色构思、动作生成、逐帧质检到引擎导入的完整链路。用户提供文字描述或参考图,即可为指定角色生成成套动作,并将其作为可长期管理、可复用的资产留存;最终交付物为一个可直接放入游戏项目使用的资源包,免去手工去背、切帧与对齐等重复工序。
与现有工具的根本区别在于"交付的是资产,而非图片"。现有产品止步于"生成完":交付图片或动图后责任即终止,角色资产的管理、迭代、复用与进入引擎均留给用户,其形态中只有"一次生成"、没有"角色资产"。Windup 将"从生成到进入引擎"的整条纵深做全——主界面是一个常驻的角色资产库,角色、造型、动作、帧以资产树长期留存,当日生成的角色可于日后回来补充动作、修正缺陷帧、重新导出,生成记录均可追溯;交付的是可直接进入项目、可持续迭代的角色资产。
在此基础上,Windup 面向国产小游戏生态进行适配。微信小游戏以 Cocos 为主力引擎,故适配 Cocos 即服务于微信等小游戏:导出资产按 Cocos 的图集格式、命名与导入规范组织,导入即可播放。同时,以角色母版约束保障跨动作、跨批次的视觉一致性,由工程系统而非模型概率输出保障;并保持开源、中文原生与生成模型 / 路线的可替换,不绑定单一厂商。
Windup 的底层逻辑是"母版约束生成 + 确定性工程后处理",并由统一工作流按动作类型调度生成路线。基于该架构,产品可延伸至非角色素材与长期资产复用管理,并可接入 Godot、Unity 等引擎。
二、背景与战略决策
2.1 背景与机会
生图模型已能稳定产出高质量的角色原画,"能否画出"基本得到解决;但从一张角色图到游戏引擎可直接调用的资产之间——动画生成、去背、切帧、按引擎规范导入、素材复用与项目管理——仍存在完整的工程链路空白,"能否用上"是当前真正的难点,其手工返工成本可达生成环节的十倍以上。该空白对目标用户具体表现为四个痛点:
- 交付止步于图片:工具产出的是单张图片而非可用资产;从图片到进入引擎,需手工完成去背、切帧、脚底线对齐、批量命名与引擎导入,该环节耗时远高于生成本身。
- 质量与成本双重失控:同一角色扩展为多帧、多动作时外观发生漂移(配饰位移、配色偏移、比例变化),结果往往是彼此相似却非同一角色;此类问题无法通过调整提示词稳定纠正,只能反复重试,而每次生成均产生费用,质量与成本同步失控。
- 质量缺乏检验:细微偏差(如脚底线数像素漂移)肉眼难以察觉,进入引擎播放后表现为抖动;工具不提供质检,缺陷帧混入交付物;且"一次生成"的形态中不存在"单帧不合格"的概念,发现问题只能整段重新生成。
- 生产不可持续:游戏素材需持续迭代(补充新动作、随版本重做),而现有工具只有"一次生成"、没有"角色资产"的概念;若需在既有角色上继续生产,只能重新描述、重新导入、从头执行整条流程。
骨骼动画路线在当前技术条件下尚不成熟:视觉模型难以准确理解图像坐标,导致部件拆分与锚点设置失准、骨架层级混乱(有公开失败记录);其可覆盖的资产类型有限(像素风、复杂动画难以实现);且资产质量缺乏客观判据,无法建立自动质检。此为本项目不采用骨骼路线的依据之一。
竞品方面,海外垂类产品(Ludo.ai、Meowa、PixelLab 等)已能生成可用的单段动画,其中 Ludo、Meowa 最为成熟。但以"从生成一张图到进入引擎可用"为轴衡量,现有产品均止于左端:它们选择横向铺开品类,与纵深方向天然冲突。因此,"从生成贯通至进入引擎"的纵深尚无人做全,此为第一个空白。
第二个空白在国内小游戏生态:据中国音数协游戏工委《2025 年中国游戏产业报告》(2025 年 12 月发布),小程序游戏年收入 535 亿元,且全行业年度增长中过半来自小游戏。国内 2D 游戏的主要分发渠道为微信、抖音等小游戏平台;以微信为例,官方口径开发者规模约五十万、其中八成为三十人以下团队,开发管线高度集中于 Cocos 引擎(其小游戏畅玩榜前 100 中 Cocos 占约 61%)。然而现有素材工具中,无一针对该生态进行适配。
2.2 目标用户与核心问题
主用户为国内小游戏赛道的个人开发者与微型团队中的程序、策划及非专业美术成员:具备引擎使用与游戏逻辑开发能力,但缺乏美术产能;常见于横版动作、平台跳跃、Game Jam、独立原型及微信小游戏开发。首期优先服务已有角色设定或参考图、需快速补齐基础动作、并使用 Cocos Creator / 微信小游戏或 Web 预览链路的用户。
核心问题:如何以较低成本,将 AI 生成的视觉设定转化为符合国内小游戏工程规范、可直接进入引擎运行的连贯动作资产,并支持其后续的持续管理与复用。
2.3 战略决策与边界
一句话决策:放弃泛用型动画生成路线,以国产小游戏(微信 / Cocos)为主线,在八周内打通单一链路——从一句角色描述到可直接进入引擎播放的角色资产。该链路的完整性在于:生成仅为第一步,其后的管理、质检、资产复用、成本与效率权衡直至引擎导入,均属于同一套工作流,亦为多数竞品尚未覆盖的部分。基于此,确立四项决策:
- 决策一 · 只做人物资产。备选为横向覆盖全品类素材,或纵向专注人物。选择人物:人物是玩家直接操纵的对象与交互体验的核心,重要性最高;其难度亦最大——场景、道具以静态图即可满足,人物须动态呈现并在多帧、多动作间保持同一性,恰为当前 AI 尚未充分解决的部分。全品类为竞品已有路径,且与纵深方向冲突。
- 决策二 · 采用序列帧,不做骨骼动画。备选为骨骼动画(输出 Spine 等)或序列帧。选择序列帧:骨骼路线依赖模型从单图反推结构,是视觉模型的已知弱项;可覆盖的资产类型有限;骨骼资产的修复要求绑定、蒙皮等专业知识,超出目标用户能力;且质量缺乏客观判据、无法建立自动质检。序列帧则全引擎原生支持、质量可完全转化为自动检查,唯一代价为帧间易漂移,而这正由母版约束与自动质检控制。
- 决策三 · 首发微信 + Cocos。备选为初期即通用适配多引擎,或首发做深单一环境。选择后者,依据为 2.1 的生态调研。需说明:导出的逐帧 PNG、图集与元数据为全引擎通用格式,Unity、Godot 可直接手动导入;首发将 Cocos 一条链路做至"进入项目即可使用",属适配的优先级排序,而非将资产锁定于 Cocos。
- 决策四 · 成本与质量按动作类型选择路线。备选为全部动作采用低成本逐帧生成、全部采用高成本视频生成、或按动作类型分配路线。选择按动作类型分配:多数角色使用同一批默认动作(idle、walk、jump 等),数量有限,可预先将其生成工作流优化到位(姿势设定、参考提供、提示词),采用逐帧生成(image-to-image)这一低成本路线即可满足质量要求——质量来自预先优化,而非更高成本的模型;定制动作(如拔刀、拔枪)无法预先优化,若沿用低成本路线则需反复重试、总成本更高,故改用图生视频加抽帧(image-to-video)这一高成本但一次成型的路线,总体成本反而更低。另设三渲二(3D-to-2D)为备选扩展路线。三条路线最终收敛至同一交付物——序列帧,这也是更换路线无需改动产品的原因。
本期范围:单角色、单造型,支持默认动作(idle、walk、run、jump 等)的生成与验收,以及项目视角模式(侧视 / 俯视 / 2.5D)的多视角生成。
明确延后与不做:
- 降级支持:Godot、Unity 等引擎的自动化适配延后。
- 不做:骨骼动画(不输出 Spine 数据);UI、场景、道具、tileset、宣传图及 3D 等非角色类资产;完整引擎插件。风格不锁定,生成模板为架构中的可替换配置;本期先在像素风格域内将质量收敛至可用。
三、基本概念
3.1 项目(Project)
项目是组织角色的顶层单位,对应一款游戏或一次 Game Jam,类似工作区,于创建时设定。
- 记录三项独立信息:题材(如横版动作)、美术风格(如像素)、视角模式(侧视 / 俯视 / 2.5D)。
- 项目级的风格与视角约束作用于其下所有角色,新建素材默认继承,以保证多角色间的一致性。
- 视角模式决定角色所需母版数量;题材与风格作为生成约束。
边界:项目内的角色与资产管理为核心能力;同一角色或资产的跨项目复用为后续。
3.1.1 资产模型总览
核心思路:角色代表"一个人"(身份稳定),其外观由造型与穿戴拼装;穿戴与动作均为可独立复用的资产。资产库(Asset Library)为常驻主界面,以下资产在其中长期存在、可持续回溯扩展。
信息结构:
项目
├─ 角色（稳定身份 + 名下一个或多个造型；与动作无关）
│ └─ 造型（角色 + 一套穿戴资产 → 拥有独立母版）
│ └─ 动作实例（造型 + 动作，按视角分别存在 → 帧）
├─ 穿戴资产库（服装 / 服饰 / 装备，独立成卡，可跨角色复用）
└─ 动作库（动作定义，可复用的规格模板）
3.2 角色(Character)
角色代表"一个人"而非单张图片:其自身记录跨造型稳定的信息——名字、面部、年龄、体型、关键标志(如断刃、独眼)、参考图,并在名下持有一个或多个造型。同一人物更换造型后仍为同一角色:无论着装如何,只要是同一人物即为同一角色。角色与动作无关。
行为:
- 创建角色:输入描述或上传参考图 → 产出稳定信息与首个造型的母版候选 → 用户确认后锁定。
- 锁定后,角色的稳定信息与既有造型母版转为只读;修改形象即新建或修改造型,原造型及其已生成动作不受影响。
- 每帧生成以「角色稳定信息 + 所属造型母版」为约束,自动质检据此逐项比对。
这样做的考虑:
- 将"人物本身"与"着装、动作"分离,同一角色方可拥有多套造型并复用同一批动作;否则每套着装只能作为互不相关的新角色处理。
- 命名约定:"稳定信息 + 名下全部造型"的整体即为角色,身份为其属性,不再单独命名。
边界:角色仅服务于视觉约束,人设背景、世界观等叙事内容暂缓;本期仅做单角色 · 单造型,多造型 / 换装为后续延伸(数据模型预留接口)。
3.3 造型与穿戴资产(Outfit & Wearable)
造型是角色着一套具体穿戴后的形态(相当于角色的皮肤),即「角色 + 一组穿戴资产」,每个造型拥有独立母版。同一角色可有多个造型(常态、金甲、受伤态等),换装即切换或新建造型。
穿戴资产是构成造型的可复用组件——服装、服饰、装备(如长剑、红围巾),各自独立成卡,可跨角色、跨造型复用,创建一次即可多处套用。
这样做的考虑:资产的可提取、可迁移、可复用是贯穿全模型的原则;将角色拆分为身份与可复用组件,正是为使同一件穿戴资产可供多个角色使用。
边界:本期为单造型,穿戴复用限于同一项目内,跨项目复用为后续。
3.4 母版(Master Sheet)
母版是角色某一朝向的标准参考图(定妆图),是一致性的事实基准——后续每帧生成均以其为约束逐项比对。
- 在多视角项目中,母版构成"母版视角集合":侧视一张即可(反向经镜像获得),俯视 / 2.5D 需 4 或 8 向。
- 多造型情形下,每个造型拥有独立母版,并共用角色的身份约束。
- 各朝向母版独立生成,不以伪透视替代,每个朝向作为独立资产绘制。
3.5 动作与动作实例(Action & Action Instance)
动作是"运动方式"的可复用定义——名称、文字描述、姿势参考(可选)及规格(帧数、画布尺寸、FPS、是否循环、锚点、脚底线、生成模式)。默认动作(idle、walk、run、jump 等)可直接选用,定制动作(如拔刀居合)以文字描述创建,难以描述时可上传姿势参考图;一份定义可套用于任意造型。
动作实例是某造型下某动作、某视角的一套完整帧。金甲造型的 walk 与布衣造型的 walk 为两个实例,共用同一份 walk 定义。
行为:
- 用户在角色 / 造型下添加动作,形成动作清单,可批量选择多个一并提交;每个动作实例独立生成、独立检查、独立通过。
- 规格挂载于动作定义层,同一实例的全部帧共享同一套画布、脚底线与锚点。
这样做的考虑:
- 定义与实例分层,动作方成为可复用资产,与"生产者、着装"解耦。
- 动作是检查与交付的单元:一个动作实例整体判定"通过 / 退回";不同生成路线对同一动作可采用各自的检查方式(逐帧生成对应逐帧检查,视频生成对应整段播放 / 裁剪检查),将"检查 / 通过"机制固定于动作层,对任意生成路线均成立。
边界:本期在单造型上完成默认动作(idle、walk、run、jump 等);跨造型 / 跨角色复用为后续。
3.6 帧(Frame)
帧是生成与检查的最小单位,一个动作实例由按序排列的若干帧构成。
字段:序号、图片、所属动作实例、所属生成记录、状态、实测偏差。
状态机:待审核 → 通过 / 退回。每帧生成后先经自动质检(对母版比对一致性、对规格比对对齐与偏差),不合格自动标记退回;用户再行逐帧审核,退回可精确至单帧或单段并附备注,并携带相邻帧作为上下文单独重生成,已通过的帧不受影响。
这样做的考虑:竞品普遍存在"一套帧中单帧不合格即须整套重生成、且失败仍计费"的问题;帧级状态机将失败局部化,使返工范围由一套降至一帧。
边界:帧不支持手绘编辑(本期无画笔工具),修正的唯一方式为重生成。
3.7 生成记录(Generation Run)
生成记录是一次生成调用的完整记录,是可追溯的载体。
字段:提示词、参考条件(母版版本、姿势参考)、生成路线、模型与工具、次数、耗时、成本、产出帧列表。
行为:每帧可溯源至产生它的记录;记录对用户可见,包括某角色的累计生成次数、成本与所用路线;提交前显示预估消耗,生成后记入实际消耗。
这样做的考虑:产品对外承诺的是帧层面的输出契约(尺寸、对齐、一致性),不绑定单一模型;路线信息收敛于记录,更换路线不影响概念结构。
边界:本期不做配额与预算管理。
3.8 工作流引擎与入口(Workflow Engine)
工作流引擎是将上述概念串联并执行的底层机制:一次"生成动作"请求按动作类型自动路由至相应生成路线(决策四的落地);一段完成的流程可保存为模板,复用的是一套已验证的生产规范(尺寸、视角、动作数、帧率、命名、导出规则),可为新角色重放。
引擎之上设两个入口,二者操作同一条流程:
- Quick Start:标准任务以一句自然语言完成(如"创建一个横版像素骑士,需 idle、walk 与 attack 动作")。系统解析需求 → 选择角色与母版 → 建立动作节点 → 套用项目规格 → 执行 → 在需人工判断处暂停 → 输出资产包。用户无需搭建流程,底层仍为完整工作流。
- 画布(Canvas):面向需要精细控制的生产任务,以节点与连线呈现资产依赖、并行生产多个动作、局部返工(回到生产链的准确位置而非从头执行),并为不同动作指定不同生产方法;亦可打开 Quick Start 已建立的流程进行修改。
这样做的考虑:交互层与底层引擎分离,自然语言与画布仅为两种入口,底层的路线调度与质检门禁完全共用,而非两套系统。将流程保存为模板,使"复用生产规范"而非"复用图片"成为团队协作与批量生产的基础。
3.9 导出包与环境(Delivery Package)
导出包是最终交付物:一个角色若干已通过动作的完整快照,可直接放入游戏项目使用。
内容:GIF 预览、逐帧透明 PNG、sprite sheet(图集)、JSON 元数据(帧序、FPS、锚点、脚底线)、目标引擎导入说明。
行为:仅全部帧通过的动作可进入导出包,不产出残缺包;用户自行选择本次打包的已完成动作,不强制全量。
环境即"引擎 + 平台"(如 Cocos Creator + 微信小游戏),为项目的目标环境。微信小游戏以 Cocos 为主力引擎,故本期对 Cocos 的适配即覆盖微信小游戏的运行——导出包在 Cocos 运行时(含其微信小游戏构建)播放即达成微信适配。微信 4MB 主包与远程加载的分包组织属平台部署层细节,不改变导出产物本身,本期不展开;导出器按引擎以适配器组织,扩展引擎即新增一个导出目标,不影响产品。
这样做的考虑(交付序列帧而非骨骼数据):序列帧为全引擎原生支持的最低公分母、无运行时依赖,其质量判据(漂移像素、对齐、导入可播)可完全转化为自动化测试;骨骼资产要求绑定、蒙皮等运行时知识,超出目标用户能力,且质量缺乏客观判据。
四、核心流程与原型
Windup 的主界面为常驻资产库,资产贯穿全流程、可随时回溯。一次完整生产如下(标注:AI 生成 / 人工确认 / 工程自动):
- 创建或选择项目,设定题材、风格与视角模式(人工)。
- 进入生成:入口二选一(Quick Start / 画布),起点三选一——从零开始(以文本或参考图定义风格)、上传参考图(可先行风格化)、或从资产库既有资产出发(人工)。
- 按项目视角配齐母版视角集合,逐张经门禁与确认后,角色定稿锁定(AI 生成 / 人工确认)。
- 定制动作清单,可批量选择;逐动作确认规格与生成模式,提交前显示预估消耗(人工)。
- 前台或后台生成(AI)→ 自动质检(工程):不合格帧自动重生成,设次数上限,达上限即停止并提示调整规格或更换生成模式。
- 检查台逐动作审核(人工):支持播放、暂停、逐帧、慢放;退回单帧或单段并携上下文重生成,其余帧不受影响;动作全部帧通过方为完成。
- 选择本次打包的动作,导出资源包(人工 / 工程)。
- 实时预览(人工):在预览画布中以 WASD 操控角色移动、切换动作、绑定按键,验证操作手感;不满意可退回检查台。
- 选择目标引擎 / 平台,按引擎出包并附导入说明,放入项目即可播放(人工 / 工程)。
原型:本产品含界面,依 01 规范两步法,于文字定稿后附原型。MS2 起原型建立在真实工程代码之上,以一个仅用于展示、不合并的 PR 承载,用以明确目标形态与预期行为。
五、核心假设与验收
5.1 核心假设
| # |
核心假设 |
验证方式 |
通过标准 |
失败退路 |
| 1 |
目标用户需要的是可进入项目、可持续管理复用的动作资产,而非更多单张角色图 |
5–8 名目标用户对比单图工作流与 Windup 资产工作流,各完成一次任务 |
≥4 人独立完成,并认可资产化管理与工程导出的价值 |
收缩为角色基准管理与动作素材整理工具 |
| 2 |
母版(定妆参考 + 结构化描述 + 参考图)可将跨动作一致性提升至可用水平 |
普通提示词与本方案各生成同一批默认动作,按面部、服装、配色、体型盲评 |
≥80% 动作帧被多数评审判为同一角色,且优于提示词基线 |
收窄角色类型与主风格 |
| 3 |
默认动作(idle、walk、run、jump 等)足以支撑原型与小游戏核心玩法 |
以横版动作、平台跳跃、轻量战斗三个场景展示并访谈 |
≥4 人指出明确使用场景 |
聚焦最高频的 idle、walk |
| 4 |
按动作类型选择路线(默认走逐帧、定制走图生视频)可兼顾成本与质量 |
默认动作与定制动作各走既定路线,记录成本、成功率、一致性 |
默认动作以低成本达标;定制动作一次成型的总成本优于低成本路线的反复重试 |
缩小定制动作范围,标注实验档 |
| 5 |
动作级统一规格(画布、脚底线、锚点、帧序、元数据)可显著降低接入成本 |
用户将同一动作包导入 Cocos Creator,记录耗时与手工校正步骤 |
无需重切帧、批量改名、逐帧调锚点即可首次播放 |
固定 Cocos 版本与项目模板,提供强预设 |
| 6 |
中文、开源、模型可替换构成相对闭源竞品的采用理由 |
向 5 名目标用户展示闭源成品与开源工作流,访谈试用与替换意愿 |
≥3 人认可可控性、可替换性或国内链路适配 |
差异化收敛至角色一致性与 Cocos / 小游戏交付 |
5.2 验收标准
统一用例:像素风骷髅剑士。
说明:用户流程项由现有产品串联验证,生成质量项由生成路线实测验证。本期交付为可验证的假设与打通的核心链路,系统性质量数据的实测为后续承诺,不作为本期既成事实。
现状(不使用本产品):各动作分别以提示词逐个尝试,进入 Cocos 前需手工完成去背、切帧、对齐、命名与配置,耗时以小时计且结果不稳定。
提议后形态(逐条可判定通过 / 不通过):
- 全流程可跑通:5–8 名目标用户试用,≥4 人无需讲解即完成"角色输入 → 角色定稿 → 动作选择 → 逐帧审核 → 导出"全流程(假设 1)。
- 产出物:单次任务产出同一角色(单造型)的默认动作序列(如 idle、walk、run、jump),各自可循环完整播放(假设 3)。
- 角色一致性:动作帧盲评判为同一角色的比例 ≥80%,且优于纯提示词基线(假设 2)。
- 对齐与帧间稳定:画布一致、背景透明,脚底线对齐无肉眼可见跳动(量化阈值初设为帧高 3% 以内,第 1–2 周实验校准)。
- 单帧重生成一致性:任一帧单点重生成后,与相邻帧不出现可见抖动或角色漂移(本期路线的关键风险,纳入实验专项验证)。
- 引擎适配:导出包在 Cocos Creator / 微信小游戏首次播放成功,无需重切帧、批量改名、逐帧调锚点(假设 5);本期仅验收 Cocos 靶子(即微信小游戏主力引擎),Godot、Unity 不在本期。
- 过程可追溯:每帧可溯源至生成记录(提示词、参考、路线、次数、耗时、成本)。
边界与非法情况:缺失母版、动作帧不全或规格检查失败时明确报错,不导出残缺包;验收不含换装、骨骼、特效、UI / 道具 / 场景、3D、完整引擎插件。
项目 1 · 产品策划案
关联PR：#2
一、Windup 是什么
Windup 是面向缺乏美术产能的个人开发者与小型团队的 2D 角色素材生成资产工作台,覆盖从角色构思、动作生成、逐帧质检到引擎导入的完整链路。用户提供文字描述或参考图,即可为指定角色生成成套动作,并将其作为可长期管理、可复用的资产留存;最终交付物为一个可直接放入游戏项目使用的资源包,免去手工去背、切帧与对齐等重复工序。
与现有工具的根本区别在于"交付的是资产,而非图片"。现有产品止步于"生成完":交付图片或动图后责任即终止,角色资产的管理、迭代、复用与进入引擎均留给用户,其形态中只有"一次生成"、没有"角色资产"。Windup 将"从生成到进入引擎"的整条纵深做全——主界面是一个常驻的角色资产库,角色、造型、动作、帧以资产树长期留存,当日生成的角色可于日后回来补充动作、修正缺陷帧、重新导出,生成记录均可追溯;交付的是可直接进入项目、可持续迭代的角色资产。
在此基础上,Windup 面向国产小游戏生态进行适配。微信小游戏以 Cocos 为主力引擎,故适配 Cocos 即服务于微信等小游戏:导出资产按 Cocos 的图集格式、命名与导入规范组织,导入即可播放。同时,以角色母版约束保障跨动作、跨批次的视觉一致性,由工程系统而非模型概率输出保障;并保持开源、中文原生与生成模型 / 路线的可替换,不绑定单一厂商。
Windup 的底层逻辑是"母版约束生成 + 确定性工程后处理",并由统一工作流按动作类型调度生成路线。基于该架构,产品可延伸至非角色素材与长期资产复用管理,并可接入 Godot、Unity 等引擎。
二、背景与战略决策
2.1 背景与机会
生图模型已能稳定产出高质量的角色原画,"能否画出"基本得到解决;但从一张角色图到游戏引擎可直接调用的资产之间——动画生成、去背、切帧、按引擎规范导入、素材复用与项目管理——仍存在完整的工程链路空白,"能否用上"是当前真正的难点,其手工返工成本可达生成环节的十倍以上。该空白对目标用户具体表现为四个痛点:
骨骼动画路线在当前技术条件下尚不成熟:视觉模型难以准确理解图像坐标,导致部件拆分与锚点设置失准、骨架层级混乱(有公开失败记录);其可覆盖的资产类型有限(像素风、复杂动画难以实现);且资产质量缺乏客观判据,无法建立自动质检。此为本项目不采用骨骼路线的依据之一。
竞品方面,海外垂类产品(Ludo.ai、Meowa、PixelLab 等)已能生成可用的单段动画,其中 Ludo、Meowa 最为成熟。但以"从生成一张图到进入引擎可用"为轴衡量,现有产品均止于左端:它们选择横向铺开品类,与纵深方向天然冲突。因此,"从生成贯通至进入引擎"的纵深尚无人做全,此为第一个空白。
第二个空白在国内小游戏生态:据中国音数协游戏工委《2025 年中国游戏产业报告》(2025 年 12 月发布),小程序游戏年收入 535 亿元,且全行业年度增长中过半来自小游戏。国内 2D 游戏的主要分发渠道为微信、抖音等小游戏平台;以微信为例,官方口径开发者规模约五十万、其中八成为三十人以下团队,开发管线高度集中于 Cocos 引擎(其小游戏畅玩榜前 100 中 Cocos 占约 61%)。然而现有素材工具中,无一针对该生态进行适配。
2.2 目标用户与核心问题
主用户为国内小游戏赛道的个人开发者与微型团队中的程序、策划及非专业美术成员:具备引擎使用与游戏逻辑开发能力,但缺乏美术产能;常见于横版动作、平台跳跃、Game Jam、独立原型及微信小游戏开发。首期优先服务已有角色设定或参考图、需快速补齐基础动作、并使用 Cocos Creator / 微信小游戏或 Web 预览链路的用户。
核心问题:如何以较低成本,将 AI 生成的视觉设定转化为符合国内小游戏工程规范、可直接进入引擎运行的连贯动作资产,并支持其后续的持续管理与复用。
2.3 战略决策与边界
一句话决策:放弃泛用型动画生成路线,以国产小游戏(微信 / Cocos)为主线,在八周内打通单一链路——从一句角色描述到可直接进入引擎播放的角色资产。该链路的完整性在于:生成仅为第一步,其后的管理、质检、资产复用、成本与效率权衡直至引擎导入,均属于同一套工作流,亦为多数竞品尚未覆盖的部分。基于此,确立四项决策:
本期范围:单角色、单造型,支持默认动作(idle、walk、run、jump 等)的生成与验收,以及项目视角模式(侧视 / 俯视 / 2.5D)的多视角生成。
明确延后与不做:
三、基本概念
3.1 项目(Project)
项目是组织角色的顶层单位,对应一款游戏或一次 Game Jam,类似工作区,于创建时设定。
边界:项目内的角色与资产管理为核心能力;同一角色或资产的跨项目复用为后续。
3.1.1 资产模型总览
信息结构:
3.2 角色(Character)
角色代表"一个人"而非单张图片:其自身记录跨造型稳定的信息——名字、面部、年龄、体型、关键标志(如断刃、独眼)、参考图,并在名下持有一个或多个造型。同一人物更换造型后仍为同一角色:无论着装如何,只要是同一人物即为同一角色。角色与动作无关。
行为:
这样做的考虑:
边界:角色仅服务于视觉约束,人设背景、世界观等叙事内容暂缓;本期仅做单角色 · 单造型,多造型 / 换装为后续延伸(数据模型预留接口)。
3.3 造型与穿戴资产(Outfit & Wearable)
造型是角色着一套具体穿戴后的形态(相当于角色的皮肤),即「角色 + 一组穿戴资产」,每个造型拥有独立母版。同一角色可有多个造型(常态、金甲、受伤态等),换装即切换或新建造型。
穿戴资产是构成造型的可复用组件——服装、服饰、装备(如长剑、红围巾),各自独立成卡,可跨角色、跨造型复用,创建一次即可多处套用。
这样做的考虑:资产的可提取、可迁移、可复用是贯穿全模型的原则;将角色拆分为身份与可复用组件,正是为使同一件穿戴资产可供多个角色使用。
边界:本期为单造型,穿戴复用限于同一项目内,跨项目复用为后续。
3.4 母版(Master Sheet)
母版是角色某一朝向的标准参考图(定妆图),是一致性的事实基准——后续每帧生成均以其为约束逐项比对。
3.5 动作与动作实例(Action & Action Instance)
动作是"运动方式"的可复用定义——名称、文字描述、姿势参考(可选)及规格(帧数、画布尺寸、FPS、是否循环、锚点、脚底线、生成模式)。默认动作(idle、walk、run、jump 等)可直接选用,定制动作(如拔刀居合)以文字描述创建,难以描述时可上传姿势参考图;一份定义可套用于任意造型。
动作实例是某造型下某动作、某视角的一套完整帧。金甲造型的 walk 与布衣造型的 walk 为两个实例,共用同一份 walk 定义。
行为:
这样做的考虑:
边界:本期在单造型上完成默认动作(idle、walk、run、jump 等);跨造型 / 跨角色复用为后续。
3.6 帧(Frame)
帧是生成与检查的最小单位,一个动作实例由按序排列的若干帧构成。
字段:序号、图片、所属动作实例、所属生成记录、状态、实测偏差。
状态机:待审核 → 通过 / 退回。每帧生成后先经自动质检(对母版比对一致性、对规格比对对齐与偏差),不合格自动标记退回;用户再行逐帧审核,退回可精确至单帧或单段并附备注,并携带相邻帧作为上下文单独重生成,已通过的帧不受影响。
这样做的考虑:竞品普遍存在"一套帧中单帧不合格即须整套重生成、且失败仍计费"的问题;帧级状态机将失败局部化,使返工范围由一套降至一帧。
边界:帧不支持手绘编辑(本期无画笔工具),修正的唯一方式为重生成。
3.7 生成记录(Generation Run)
生成记录是一次生成调用的完整记录,是可追溯的载体。
字段:提示词、参考条件(母版版本、姿势参考)、生成路线、模型与工具、次数、耗时、成本、产出帧列表。
行为:每帧可溯源至产生它的记录;记录对用户可见,包括某角色的累计生成次数、成本与所用路线;提交前显示预估消耗,生成后记入实际消耗。
这样做的考虑:产品对外承诺的是帧层面的输出契约(尺寸、对齐、一致性),不绑定单一模型;路线信息收敛于记录,更换路线不影响概念结构。
边界:本期不做配额与预算管理。
3.8 工作流引擎与入口(Workflow Engine)
工作流引擎是将上述概念串联并执行的底层机制:一次"生成动作"请求按动作类型自动路由至相应生成路线(决策四的落地);一段完成的流程可保存为模板,复用的是一套已验证的生产规范(尺寸、视角、动作数、帧率、命名、导出规则),可为新角色重放。
引擎之上设两个入口,二者操作同一条流程:
这样做的考虑:交互层与底层引擎分离,自然语言与画布仅为两种入口,底层的路线调度与质检门禁完全共用,而非两套系统。将流程保存为模板,使"复用生产规范"而非"复用图片"成为团队协作与批量生产的基础。
3.9 导出包与环境(Delivery Package)
导出包是最终交付物:一个角色若干已通过动作的完整快照,可直接放入游戏项目使用。
内容:GIF 预览、逐帧透明 PNG、sprite sheet(图集)、JSON 元数据(帧序、FPS、锚点、脚底线)、目标引擎导入说明。
行为:仅全部帧通过的动作可进入导出包,不产出残缺包;用户自行选择本次打包的已完成动作,不强制全量。
环境即"引擎 + 平台"(如 Cocos Creator + 微信小游戏),为项目的目标环境。微信小游戏以 Cocos 为主力引擎,故本期对 Cocos 的适配即覆盖微信小游戏的运行——导出包在 Cocos 运行时(含其微信小游戏构建)播放即达成微信适配。微信 4MB 主包与远程加载的分包组织属平台部署层细节,不改变导出产物本身,本期不展开;导出器按引擎以适配器组织,扩展引擎即新增一个导出目标,不影响产品。
这样做的考虑(交付序列帧而非骨骼数据):序列帧为全引擎原生支持的最低公分母、无运行时依赖,其质量判据(漂移像素、对齐、导入可播)可完全转化为自动化测试;骨骼资产要求绑定、蒙皮等运行时知识,超出目标用户能力,且质量缺乏客观判据。
四、核心流程与原型
Windup 的主界面为常驻资产库,资产贯穿全流程、可随时回溯。一次完整生产如下(标注:AI 生成 / 人工确认 / 工程自动):
原型:本产品含界面,依 01 规范两步法,于文字定稿后附原型。MS2 起原型建立在真实工程代码之上,以一个仅用于展示、不合并的 PR 承载,用以明确目标形态与预期行为。
五、核心假设与验收
5.1 核心假设
5.2 验收标准
统一用例:像素风骷髅剑士。
现状(不使用本产品):各动作分别以提示词逐个尝试,进入 Cocos 前需手工完成去背、切帧、对齐、命名与配置,耗时以小时计且结果不稳定。
提议后形态(逐条可判定通过 / 不通过):
边界与非法情况:缺失母版、动作帧不全或规格检查失败时明确报错,不导出残缺包;验收不含换装、骨骼、特效、UI / 道具 / 场景、3D、完整引擎插件。