问题
Character 现在只有 reference_image_url + character_data{outfits→actions→frames}，也就是角色 = 一张图 + 一棵帧树。
渲染出帧路线（3D 建模 → 绑骨 → 套动作 → 渲 2D 序列帧）在母版确认之后，还有一段角色级、一次性的派生工作：
母版图 → 图生3D → 减面 → 绑骨 → (GLB + 骨架规范 + 挂点)
这段产物必须持久化，并被该角色所有后续动作任务复用。现有数据模型里没有"角色的可复用生产资产"这一层，它无处存放。
为什么这条最急：不修会直接抹掉这条路线的成本优势
2026-08-05 实测的计费口径（腾讯混元生3D，官方计费文档 + 实调）：
| 段落 |
计费 |
| 图生3D（专业版） |
20 积分 ≈ ¥2.4 |
| 绑骨蒙皮 |
10 积分 ≈ ¥1.2 |
| 套动作（外部免费动作库 + 本地重定向） |
¥0 不限量 |
于是两种存储方案的成本模型完全不同：
- 有角色级存储：¥3.6 一次性 + 每个动作 ¥0 → 出 10 个动作 ≈ ¥3.6
- 无角色级存储（每次动作都从母版重跑）：每动作 ¥3.6 → 出 10 个动作 ≈ ¥36
一次性成本被变成每动作成本，10 倍差距，而这条路线相对视频生成路线的全部优势就建立在"角色级一次性"上。
建议的落点
沿用 #81 已提议的字段，挂在角色层（不是 outfit / action 层）：
character_data: {
version, outfits: [...],
model_3d: { url, format, tris, source, skeleton_convention } | null
render_profile: { camera, ortho_h, view, mat, canvas } | null
sockets: { <bone_name>: {...} } | null
}
- 三个字段全部可选，逐帧 / 视频路线一律为
null，行为与现在完全一致——纯加法。
skeleton_convention 用于标记骨架命名规范。2026-08-03/08-05 两次实测：云绑骨产出 28 骨，标准 humanoid 命名（root/Hips/Spine/Spine1/Spine2/Neck/...），无 mixamorig: 前缀；挂点骨保留，故 sockets 可跨动作复用。render_profile 是"确定性重跑"的前提：同一角色的所有动作必须用同一套相机与画布参数，否则跨动作的尺寸与构图会漂。
谁来写这三个字段：派生资产不应走"用户确认"（2026-08-06 补，Refs #123）
#123 里 @xiaocheny214 已确认后端的设计意图：生成结果必须得到用户确认，才会落入角色资产库；这个决策由前端识别执行。
这条规则对本 Issue 提议的三个字段有一个必须一并定掉的后果。
它们不是用户确认的对象。 用户确认的是"这 16 帧是不是我要的"，不会去确认一个 GLB、一套骨架命名规范、一组相机参数——
这些是管线中间产物，用户在界面上根本看不见。
如果它们也只能经前端回写 character_data 才落库，会出现两个具体问题：
- 用户跑完一个动作但没点确认（换个动作重试、直接关掉页面）→ 那次 ¥3.6 的建模 + 绑骨产物丢了，
下个动作只能重跑一次 → 本 Issue 开头那个 10 倍成本差距原样回来。确认与否是用户对帧的判断，
不该连带决定一个与帧无关的、纯成本项的资产存不存。
- 前端要把一个 22.6MB GLB 的 URL、28 根骨的命名规范、正交相机参数当业务数据搬运，而它对这些没有任何判断力。
建议把这三个字段划为"派生资产：后端在派生任务完成时直接写入，不经用户确认"，与"动作帧需确认"区分开。
判据是它们同时满足两条：
- 确定性且无候选 —— 不存在"四选一"，没有可供用户确认的内容；
- 纯成本项 —— 重跑要真金白银，丢弃只有损失、没有收益。
落到接口上：character_data.model_3d / render_profile / sockets 由后端写；outfits[].actions[] 保持 #123 里确认后写。
两者不冲突，但这正好又是"确认入库不该用整树 PATCH"的一个理由：现在唯一的写入口 PATCH /characters/{id}
接的是完整 CharacterData，前端在确认动作时回写整棵树——它读到的树里如果没有这三个字段（或它的 DTO 里压根没定义），
回写就等于把后端写入的派生资产删掉。 这一条与 #123 的待办二是同一个修法。
与正在做的后端存储的关系
后端这两天正在做存储与生成。这三个字段建议在建表时一并留位，否则等渲染路线接进来时要改已经上线的表结构。字段可选、默认 null，留位的代价接近零。
验收
PATCH /characters/{id} 能整树写入并原样读回这三个字段（现有 character_data 已验证整树往返无损，扩字段应同样成立）。- 同一角色的第二个动作任务，不再触发图生3D 与绑骨两段计费调用。
- 派生任务完成后，不经任何前端调用，
GET /characters/{id} 就能读到 model_3d。
- 前端确认一个动作入库之后，
model_3d / render_profile / sockets 不被清空。
关联
契约主体在 #81；写入通路（确认入库接口、整树 PATCH 的并发覆盖）在 #123；
步骤模板侧（create_character 需要一个可选的"角色资产派生"段）归 workflow controller 那条线。本 Issue 只谈数据模型落点。
问题
Character现在只有reference_image_url+character_data{outfits→actions→frames}，也就是角色 = 一张图 + 一棵帧树。渲染出帧路线（3D 建模 → 绑骨 → 套动作 → 渲 2D 序列帧）在母版确认之后，还有一段角色级、一次性的派生工作：
这段产物必须持久化，并被该角色所有后续动作任务复用。现有数据模型里没有"角色的可复用生产资产"这一层，它无处存放。
为什么这条最急：不修会直接抹掉这条路线的成本优势
2026-08-05 实测的计费口径（腾讯混元生3D，官方计费文档 + 实调）：
于是两种存储方案的成本模型完全不同：
一次性成本被变成每动作成本，10 倍差距，而这条路线相对视频生成路线的全部优势就建立在"角色级一次性"上。
建议的落点
沿用 #81 已提议的字段，挂在角色层（不是 outfit / action 层）：
null，行为与现在完全一致——纯加法。skeleton_convention用于标记骨架命名规范。2026-08-03/08-05 两次实测：云绑骨产出 28 骨，标准 humanoid 命名（root/Hips/Spine/Spine1/Spine2/Neck/...），无mixamorig:前缀；挂点骨保留，故sockets可跨动作复用。render_profile是"确定性重跑"的前提：同一角色的所有动作必须用同一套相机与画布参数，否则跨动作的尺寸与构图会漂。谁来写这三个字段：派生资产不应走"用户确认"（2026-08-06 补，Refs #123）
#123 里 @xiaocheny214 已确认后端的设计意图：生成结果必须得到用户确认，才会落入角色资产库；这个决策由前端识别执行。
这条规则对本 Issue 提议的三个字段有一个必须一并定掉的后果。
它们不是用户确认的对象。 用户确认的是"这 16 帧是不是我要的"，不会去确认一个 GLB、一套骨架命名规范、一组相机参数——
这些是管线中间产物，用户在界面上根本看不见。
如果它们也只能经前端回写
character_data才落库，会出现两个具体问题：下个动作只能重跑一次 → 本 Issue 开头那个 10 倍成本差距原样回来。确认与否是用户对帧的判断，
不该连带决定一个与帧无关的、纯成本项的资产存不存。
建议把这三个字段划为"派生资产：后端在派生任务完成时直接写入，不经用户确认"，与"动作帧需确认"区分开。
判据是它们同时满足两条：
落到接口上：
character_data.model_3d / render_profile / sockets由后端写；outfits[].actions[]保持 #123 里确认后写。两者不冲突，但这正好又是"确认入库不该用整树 PATCH"的一个理由：现在唯一的写入口
PATCH /characters/{id}接的是完整
CharacterData，前端在确认动作时回写整棵树——它读到的树里如果没有这三个字段（或它的 DTO 里压根没定义），回写就等于把后端写入的派生资产删掉。 这一条与 #123 的待办二是同一个修法。
与正在做的后端存储的关系
后端这两天正在做存储与生成。这三个字段建议在建表时一并留位，否则等渲染路线接进来时要改已经上线的表结构。字段可选、默认
null，留位的代价接近零。验收
PATCH /characters/{id}能整树写入并原样读回这三个字段（现有character_data已验证整树往返无损，扩字段应同样成立）。GET /characters/{id}就能读到model_3d。model_3d/render_profile/sockets不被清空。关联
契约主体在 #81；写入通路（确认入库接口、整树 PATCH 的并发覆盖）在 #123；
步骤模板侧（
create_character需要一个可选的"角色资产派生"段）归 workflow controller 那条线。本 Issue 只谈数据模型落点。