# PixelMotion 技术方案拆解（2026-04-04）

## 1. 文档目的

拆解 [PixelMotion](https://www.pixelmotion.art/#features) 当前线上版本的产品形态与技术实现思路，重点回答下面几个问题：

- 它到底是不是“AI 一键做像素动画”
- 前端、后端、数据层分别怎么分工
- 它为什么能比普通图生图更稳定地产出可用 Sprite Sheet
- 如果我们在自己的项目里复刻类似能力，应该保留哪些关键设计

本次拆解时间截至：`2026-04-04`

---

## 2. 调研范围与证据等级

本次只基于**线上公开可见信息**进行拆解，未拿到 PixelMotion 的私有后端代码。

### 2.1 已实际核对的公开对象

- 首页 HTML
- `manifest.json`
- `sw.js`
- 前端打包产物 `assets/index-BHdWGq2s.js`
- 前端样式产物 `assets/index-DFENcMpn.css`
- 公开接口：
  - `/api/utils?type=stats`
  - `/api/utils?type=gifs`
  - `/api/showcase?limit=3`
- 线上响应头

### 2.2 本文的标记规则

- `【已确认】`：可直接从公开页面、脚本、接口返回或响应头确认
- `【高概率推断】`：无法看到后端源码，但从前端契约和数据形态可以较高把握推断
- `【推测】`：仅作为方案猜测，不能当成已确认事实

---

## 3. 先说结论

PixelMotion 本质上不是“运行时实时动画引擎”，而是一个**面向社交传播和轻量游戏资产生产的 AI Sprite Sheet 工坊**。

它的核心不是：

- 生成视频后再让前端临时播放
- 在浏览器里做复杂骨骼动画
- 给任意图片自由发挥动作

它真正的关键设计是：

1. 把输出格式强约束成 **4x4、16 帧的 Sprite Sheet PNG**
2. 把动作空间强约束成 **模板动作 + 极强提示词规则**
3. 把生成后的可用性问题交给 **前端二次编辑** 解决：
   - 隐藏坏帧
   - 调整帧序
   - 调整 FPS
   - 导出 PNG / GIF / Set
4. 把账号、存储、积分、分享、审核全部接进同一套 BaaS 与 API 网关

一句话概括：

**它不是在做“无限自由的 AI 动画”，而是在做“高约束、可编辑、可分享的像素精灵表生成流水线”。**

---

## 4. 产品形态拆解

## 4.1 用户主流程

【已确认】从前端路由、文案和接口可以还原出主流程：

1. 上传角色图
2. 选择动作
3. 可选开启 AI 角色分析，或直接用图片参考
4. 提交生成
5. 得到一张 16 帧 Sprite Sheet
6. 在编辑页中调帧序、隐藏帧、改 FPS
7. 导出 PNG / GIF / 多角色 Set
8. 保存到个人资产库
9. 可投稿到 Showcase 社区

## 4.2 它卖的不是视频，而是精灵表

【已确认】前端内部把结果当成一个 `4 x 4` 的 sprite sheet 来处理：

- 默认按 `rows=4`、`cols=4`
- 一共 `16` 帧
- GIF 导出是从单张图里切格子，不是播放视频
- PNG 导出也是从同一张大图里重组

这说明 PixelMotion 的核心资产格式是：

- 生成结果主文件：`Sprite Sheet PNG`
- 预览导出：浏览器侧再转 `GIF`

所以它更像：

- 游戏资产小工坊
- 社交素材制作器

而不是：

- 视频生成器
- 骨骼动画编辑器

---

## 5. 前端技术栈

## 5.1 应用框架

【已确认】

- 前端是 **React SPA**
- 打包方式很像 **Vite**
- 路由是 **React Router**
- 国际化使用 **i18next**
- 样式是 **Tailwind 风格的 utility CSS**

确认依据：

- HTML 使用 `type="module"` 加载单入口 bundle
- bundle 中可见 React 生产构建标识
- 存在 `/`, `/home`, `/edit`, `/terms`, `/privacy`, `/admin/review` 等前端路由
- CSS 中存在大量 `--tw-*` 变量与 utility class

## 5.2 UI 结构

【已确认】它不是纯 landing page，而是两层产品：

- 落地页：首页、功能说明、社区展示、定价入口
- 工具页：`/edit`

这种拆法的好处是：

- SEO 与转化页保持轻量
- 真正复杂的工具状态集中在编辑页

## 5.3 PWA 与缓存

【已确认】

- 有 `manifest.json`
- 注册了 `serviceWorker`
- `sw.js` 会缓存核心静态资源
- 运行时采用近似 **network first + cache fallback**

这说明它把产品定位成：

- 可被收藏到手机桌面
- 网络不稳时仍能较快打开外壳

---

## 6. 部署与托管

## 6.1 静态站托管

【已确认】

- 响应头里有 `x-vercel-id`
- 也有 Cloudflare 相关头

这说明它大概率是：

- **Vercel 托管应用**
- **Cloudflare 在前层做缓存 / 统计 / 防护**

## 6.2 API 组织方式

【已确认】所有业务接口都挂在同域 `/api/*` 下，例如：

- `/api/analyze-proxy`
- `/api/transform-action`
- `/api/generate-proxy`
- `/api/generate-beta-actions`
- `/api/remove-background`
- `/api/payment/create`
- `/api/payment/creem-create`
- `/api/showcase`
- `/api/user-actions`
- `/api/utils?type=geo`
- `/api/utils?type=stats`

【高概率推断】这类路径风格非常像：

- Vercel Serverless Functions
- 或同类 Node/Edge API 层

其目的非常明确：

- 把模型供应商密钥藏到服务端
- 把支付和鉴权放到服务端
- 把不同模型调用统一封装成同域 API

---

## 7. 数据层与 BaaS 方案

## 7.1 Supabase 接入

【已确认】前端 bundle 中直接包含 Supabase 项目地址，并创建了 Supabase client。

可确认能力包括：

- `auth`
- `storage`
- `database`
- `rpc`

## 7.2 已暴露出的主要表与存储桶

【已确认】

存储桶：

- `pixel-assets`
- `showcase`

数据表：

- `user_assets`
- `user_actions`
- `user_credits`

RPC：

- `redeem_credits`

## 7.3 数据职责推断

【高概率推断】这些表/桶的职责大致如下：

### `user_assets`

- 保存用户生成结果
- 主文件是 sprite sheet 的存储路径
- 还会附带 `action_metadata`
- `action_metadata` 里至少保存：
  - action 信息
  - `activeFrames`
  - `frameOrder`
  - `fps`

### `user_actions`

- 保存动作收藏 / 用户动作偏好
- 也可能承载“每日刷新动作配额”相关信息

### `user_credits`

- 保存积分余额

### `showcase`

- 保存社区投稿所需的上下文图和结果 GIF
- 可见字段包括：
  - `title`
  - `content`
  - `author`
  - `context_images`
  - `result_gifs`
  - `is_private`
  - `private_flags`

---

## 8. 生成链路拆解

## 8.1 不是单模型一步到位

【已确认】从接口命名和编辑页流程看，PixelMotion 至少拆成了 4 类能力：

1. 角色理解：`/api/analyze-proxy`
2. 动作文本结构化：`/api/transform-action`
3. 精灵表生成：`/api/generate-proxy`
4. 背景去除：`/api/remove-background`

【高概率推断】这意味着它后端不是一个模型完成全部事情，而是多步骤流水线。

## 8.2 两种输入模式

【已确认】编辑器存在两种模式：

- `AI Character Analysis`：更慢、更精确
- `Direct image reference`：更快

【高概率推断】对应两条链路：

### 模式 A：分析后生成

1. 上传图片
2. 调 `analyze-proxy`
3. 把角色描述文本 + 动作模板一起送去生成

优点：

- 更容易抽出稳定的角色语义
- 对脏图、照片、复杂背景更友好

缺点：

- 多一次模型调用
- 时延更高

### 模式 B：直接图参考

1. 上传图片
2. 跳过分析
3. 直接把参考图 base64 传给 `generate-proxy`

优点：

- 更快

缺点：

- 对输入质量更敏感

## 8.3 自定义动作不是直接裸喂一句话

【已确认】自定义动作会先走 `/api/transform-action`。

【高概率推断】这一步的作用是：

- 把用户自由文本改写成更结构化的动作描述
- 降低“自定义动作太抽象、太文学化”导致的失控

这其实非常关键，因为 PixelMotion 并不是让用户把任何想法直接丢给绘图模型，而是先做一层“动作编排翻译”。

## 8.4 最终输出契约

【已确认】`generate-proxy` 返回的是单个 `imageBase64`，前端将其当成一张 4x4 精灵表处理。

【高概率推断】服务端最终对前端暴露的契约就是：

- 输入：prompt + 可选参考图
- 输出：一张最终可切片的 Sprite Sheet

这有两个可能实现：

### 方案 1：直接让模型产出 4x4 精灵表

优点：

- 前端最简单
- 一次请求得到最终结果

风险：

- 帧间一致性很难控
- 容易出现局部漂移

### 方案 2：后端逐帧生成后再拼表

优点：

- 更可做重试和筛帧

风险：

- 成本更高
- 延迟更大

【我的判断】结合它前端动作模板的写法，PixelMotion 当前更像是**强约束 prompt 直接产出整张精灵表**，或者至少对模型暴露的是“直接出 16 帧表”的任务，而不是先生成视频再切帧。

---

## 9. 为什么它比普通图生图更稳

PixelMotion 真正有价值的不是“模型多强”，而是它把自由度砍掉了。

## 9.1 固定 16 帧、固定网格

【已确认】

- 固定 `4 x 4`
- 固定 `16` 帧

好处：

- 模型目标明确
- 导出逻辑简单
- 编辑器也更容易做

## 9.2 动作模板非常强约束

【已确认】游戏动作模板不是只写“run”“attack”这种词，而是把动作分成明确阶段：

- 起势
- 主动作
- 收势 / 回正

并且强制约束：

- 始终朝同一方向
- 不允许左右镜像翻转
- 身体水平位置固定
- 武器不换手
- 循环动作必须首尾闭合

【高概率推断】这类 prompt 工程是 PixelMotion 稳定性的核心来源之一。

它本质上是在把“动画导演规则”提前写进 prompt，而不是把结果完全交给模型即兴发挥。

## 9.3 后编辑能力兜底

【已确认】它允许：

- 拖拽调整帧序
- 双击隐藏坏帧
- 调整 FPS
- 保存布局

这一步非常重要，因为 AI 结果不可能永远 16 帧都完美。

PixelMotion 的思路不是追求“模型一次全对”，而是：

- 先把结果做出来
- 再让用户低成本修整

这比试图用一次模型调用直接得到完美动画更现实。

## 9.4 导出链路放到浏览器

【已确认】

- PNG 导出使用 canvas 重排
- GIF 导出使用 `gif.js`
- 透明背景导出时按需调用 `/api/remove-background`

这意味着：

- 昂贵的 AI 只负责生成主资产
- 廉价的导出和重排交给前端本地完成

这个分工非常合理。

---

## 10. 编辑器能力拆解

## 10.1 编辑页不是“看结果页”，而是轻量资产编辑器

【已确认】编辑页至少具备这些能力：

- 查看单张 sprite sheet
- 播放动画预览
- 调 FPS
- 隐藏帧
- 调整帧顺序
- 保存布局
- 导出 PNG
- 导出 GIF
- 多选导出 Set

## 10.2 布局持久化

【已确认】保存布局时会把状态写回 `user_assets.action_metadata`。

这说明它没有把“AI 结果”和“人工修整结果”分离成两套系统，而是把二次编辑直接沉淀到资产元数据里。

这个做法很实用，因为：

- 同一资产可反复继续编辑
- 资产库里保存的是“可用版本”，不是原始毛坯

---

## 11. 社区与增长设计

## 11.1 Showcase

【已确认】首页有公开社区展示，数据来自 `/api/showcase?limit=20`。

公开返回里能看到：

- 原始上下文图
- 结果 GIF
- 作者名
- 标题和故事文案

这说明 PixelMotion 不是只强调“工具效率”，还在做：

- UGC 内容传播
- 首页案例社证
- 情绪价值展示

## 11.2 审核后台

【已确认】前端存在 `/admin/review` 页面，审核通过后可发布 Showcase。

说明社区能力不是完全开放式自动发布，而是有人工审核流。

## 11.3 隐私模式

【已确认】Showcase 数据里存在：

- `is_private`
- `private_flags`

【高概率推断】它支持对原始参考图做局部隐私隐藏或模糊，只公开结果，不完全公开全部上下文。

---

## 12. 账号、积分与支付

## 12.1 账号体系

【已确认】

- 使用 Supabase Auth
- 支持邮箱注册登录
- 支持找回密码
- 支持 OAuth 登录入口

## 12.2 积分体系

【已确认】

- 生成主流程消耗 credits
- 刷新动作推荐也可能消耗 credits
- 前端存在 `NO_CREDITS`、`freeCreditsExhausted` 等状态
- 可通过 `redeem_credits` 兑换码充积分

## 12.3 定价方案

【已确认】前端内置了三档套餐：

| 套餐 | 人民币 | 美元 | 基础积分 | 赠送 |
| --- | --- | --- | --- | --- |
| `basic` | `9.9` | `4.99` | `5` | `0` |
| `pro` | `49.5` | `24.9` | `25` | `3` |
| `studio` | `99` | `46.9` | `50` | `10` |

## 12.4 区域支付分流

【已确认】

- 中国区：`/api/payment/create`
- 国际区：`/api/payment/creem-create`

结合文案还可确认：

- 中国区支持微信 / 支付宝语境
- 国际区有信用卡语境

这说明它做了明显的地域分流支付设计。

---

## 13. 一个更完整的技术架构图

```mermaid
flowchart LR
    A["首页 / 编辑页<br/>React SPA"] --> B["同域 API 层<br/>/api/*"]
    A --> C["Supabase Auth"]
    A --> D["Supabase Storage / DB"]
    B --> E["角色分析服务<br/>analyze-proxy"]
    B --> F["动作文本结构化<br/>transform-action"]
    B --> G["精灵表生成服务<br/>generate-proxy"]
    B --> H["去背景服务<br/>remove-background"]
    B --> I["支付服务<br/>China / Intl"]
    G --> J["返回 4x4 Sprite Sheet PNG"]
    J --> A
    A --> K["本地导出层<br/>Canvas + gif.js"]
    A --> L["Showcase 投稿"]
    L --> D
```

---

## 14. 如果我们复刻，最该学什么

如果要学 PixelMotion，我认为最值得学的不是 UI，而是下面 6 个工程判断。

## 14.1 先把资产格式定死

不要一开始就追求：

- 任意帧数
- 任意布局
- 任意动作长度

先定死一个可生产、可编辑、可导出的资产标准，例如：

- 16 帧
- 4x4
- PNG sprite sheet

## 14.2 模型前面一定要有动作模板层

用户说“跑步”“攻击”“比心”，不应该原样送给模型。

应该先转换成：

- 朝向约束
- 位移约束
- 起承转合
- 武器规则
- 循环规则

## 14.3 允许生成后修帧

不要试图只靠模型一次完成。

至少要有：

- 隐藏帧
- 排序
- FPS

否则大量“差一点能用”的结果会直接报废。

## 14.4 导出放前端，本地完成

像 PNG 重排、GIF 预览、透明导出这类低成本操作，完全没必要都放到后端。

## 14.5 资产库和社区是增长飞轮

PixelMotion 不只是一个生成按钮，它还做了：

- 我的资产库
- 作品展示
- 投稿审核
- 分享内容化

这能把一次性生成工具，变成可留存产品。

## 14.6 支付、积分、地域适配要早做

它不是等产品成熟后才补商业化，而是从一开始就把：

- credits
- 兑换码
- 地域支付
- 国际支付

串进主流程里了。

---

## 15. 对 PixelMotion 后端方案的推断版复原

下面给一个我认为比较接近它真实实现的“后端内部分层草图”。

## 15.1 推荐复原结构

### API Gateway 层

- 鉴权
- 积分扣减
- 配额判断
- 路由到不同 AI 服务

### Prompt Builder 层

- 读取动作模板
- 合成角色描述
- 合成单方向、单中心点、16 帧规则

### Generation Worker 层

- 调视觉模型生成 sprite sheet
- 失败时重试
- 返回 base64 PNG

### Asset Service 层

- 存储到 `pixel-assets`
- 写 `user_assets`
- 保存布局元数据

### Export Layer

- 前端本地切帧
- 前端本地生成 GIF

### Community Layer

- 投稿
- 审核
- 公开展示

---

## 16. 风险与局限

因为没有后端源码，本拆解仍有边界。

## 16.1 不能确认的部分

- 实际调用了哪一家模型供应商
- 是单次整图生成，还是逐帧生成后拼图
- 支付后端的真实实现细节
- 服务端有没有额外的安全审核与图像后处理

## 16.2 但可以较确定的部分

- 前端是 React + Vite 风格 SPA
- 数据层是 Supabase
- 输出主资产是 16 帧 sprite sheet
- 编辑器支持帧编辑和本地导出
- 产品采用积分制
- 社区、审核、展示是正式能力，不是临时 demo

---

## 17. 最终判断

PixelMotion 的成功点，不在于它“偷偷用了某个神秘模型”，而在于它把一个本来极不稳定的问题，拆成了一个高度约束的资产生产流程：

- 输入被约束
- 动作被模板化
- 输出被标准化
- 错误被编辑器兜底
- 结果被资产库与社区承接

如果我们要借鉴它，最应该借鉴的是这套**产品约束 + 资产契约 + 编辑兜底**的整体设计，而不是只学“上传一张图点生成”这层表面交互。

---

## 18. 资料来源

本次拆解实际使用了以下公开来源：

- 官网首页：
  [https://www.pixelmotion.art/](https://www.pixelmotion.art/)
- PWA Manifest：
  [https://www.pixelmotion.art/manifest.json](https://www.pixelmotion.art/manifest.json)
- Service Worker：
  [https://www.pixelmotion.art/sw.js](https://www.pixelmotion.art/sw.js)
- 公开统计接口：
  [https://www.pixelmotion.art/api/utils?type=stats](https://www.pixelmotion.art/api/utils?type=stats)
- 公开 GIF 列表接口：
  [https://www.pixelmotion.art/api/utils?type=gifs](https://www.pixelmotion.art/api/utils?type=gifs)
- 公开 Showcase 接口示例：
  [https://www.pixelmotion.art/api/showcase?limit=3](https://www.pixelmotion.art/api/showcase?limit=3)
- 首页前端 bundle 与样式产物：
  - `https://www.pixelmotion.art/assets/index-BHdWGq2s.js`
  - `https://www.pixelmotion.art/assets/index-DFENcMpn.css`