entity-continuity-system
name: entity-continuity-system description: 实体连续性系统:为跨镜头、跨集和跨媒介反复出现的角色、物体、品牌与场景建立身份字段、视觉不变量和变更记录。用于长期项目中的实体一致性维护。 veRSIon: 1.0.0
实体化资产与连续性数据系统
R — 原文(Reading)
“我会建立一个我自己的角色的主体库……我这熊猫就叫呼噜噜,然后我可以呼噜噜和一个女孩一起互动。”
— MokeLMa,视频 01,01:03:34–01:04:03
I — 方法论骨架(Interpretation)
不要把反复出现的角色、商品、道具和场景当作每个镜头临时上传的“图 1”,要把它们建成可追踪实体。 每个实体使用稳定 ID,并分离三类信息:身份不变量、随剧情变化的状态、在具体镜头中的实例。 身份不变量回答“它是谁”;状态回答“此刻怎样”;镜头实例回答“在哪个版本、哪个视角、哪个镜头被使用”。 用批准视图、比例、材质、服装、表情、标签、损伤和失败示例把身份变成可观察证据,而不是只靠名字或一段提示词。 生成结果必须回写实体、状态、镜头、版本、来源和批准状态,才能被检索、复用、淘汰和审计。 连续性因此是一套小型数据治理系统,而不是“再强调一次角色名”的提示词技巧。
A1 — 课程中的应用(Past APPlication)
案例 1:为熊猫“呼噜噜”建立主体库
问题:角色需要在新画面中被再次调用,并与另一角色组合互动。
方法论的使用:讲者把熊猫保存为具名主体,再将其与女孩参考一起输入新的生成任务。
结论:稳定命名和主体资产能把角色从临时图片提升为可复用实体。
结果:课程现场展示了组合结果;长期跨镜头一致性没有量化,因此不能把“具名”当成稳定保证。
案例 2:用表情资产约束动画角色笑容
问题:同一角色的笑容和情绪表达容易在生成中漂移。
方法论的使用:讲者为角色包加入正、侧、背面、表情、动作和细节图,并用指定表情图约束笑容。
结论:身份包除多视图外,还应包含表情、动作、服装、比例和失败边界。
结果:动画角色测试更接近指定表情;真人角色未测试,也没有系统性多表情对照。
案例 3:场景组件化与素材库
问题:场景、灯光和美术元素在每个镜头里重新生成,难以复用和保持一致。
方法论的使用:讲者把画面拆成色彩、线稿、灯光和场景组件,再组合到可复用的资产流程中。
结论:可独立命名、替换和版本化的组件比不可拆解的最终图更适合连续生产。
结果:课程展示了分层和重组过程;“更高效率”没有受控对照。
A2 — 触发场景(future Trigger)
用户会在什么情境下需要这个 Skill?
同一角色跨多个镜头、集数或活动素材时,脸、体型、服装、表情或细节不断变化。
商品、杯子、车辆、武器等道具的标签、液面、损伤、方向、开合或材质状态不连续。
团队已经生成大量文件,却找不到获批素材、来源、提示信息、所属镜头和当前版本。
需要建立主体库、角色包、资产 Bible、场景组件库或 continuity sheet。
需要让不同模型、软件或成员引用同一实体,而不是传递“图 1、最终版 2”。
语言信号
“同一个角色每个镜头都长得不一样。”
“把这个商品做成能反复调用的主体库。”
“标签、液面和道具状态总在变,帮我做连续性表。”
“Build a versioned asset bible / entity continuity system.”
“We need charACTer consistency across shots and episodes.”
与相邻 Skill 的区分
minimum-visual-bible定义全项目共同视觉规则;本 Skill 维护具体角色、商品、道具和场景的身份、状态与版本事实源。cross-shot-consistency-audit检查成组镜头是否遵守该事实源;本 Skill 负责提供基准和接收经批准的状态更新。
E — 可执行步骤(Execution)
激活后,按以下步骤执行:
盘点重复实体并分级
列出角色、商品、道具、车辆、场景和可复用组件;为每项分配稳定 ID、类型、负责人、来源/授权、当前版本和风险等级。
完成标准:所有跨两个以上镜头出现的高风险对象都有唯一 ID;禁止使用“图 1、最终版、最终版 2”作为正式标识。
判停条件:若实体只出现一次且返工代价低,保留轻量记录,不建立完整资产包。
定义身份不变量与允许变体
记录能被画面验收的形态、比例、轮廓、材质、颜色、标识、面部特征和不可出现项;同时列出可随剧情、媒介或镜头变化的属性。
完成标准:每项规则都能通过画面对比判断,不能只写“保持一致”“像原图”。
建立批准视图和证据包
按风险选择正/侧/背面、近景细节、比例图、表情、动作、服装、道具状态、材质样本、标签展开图和失败示例。
完成标准:每个高风险不变量至少有一个获批视觉证据;标明版本、日期、来源和审批人。
判停条件:只有名字或文字描述、没有可见证据时,不宣称身份已锁定。
建立状态与连续性表
为每个场景/镜头记录时间、地点、服装、发型、表情、姿态、损伤、污渍、液面、标签方向、道具持有关系和前序状态。
完成标准:任一镜头都能追溯到“实体 ID + 状态 ID + 前序镜头 + 批准版本”,并能解释状态变化原因。
绑定生成与回写规则
输入时引用实体 ID、状态 ID、批准视图和本镜头允许变量;输出时回写模型/工具版本、输入来源、镜头号、生成批次、通过/淘汰原因和文件位置。
完成标准:任何获批素材都能被检索、复现其控制包并定位使用位置;弃用版本不再进入新任务。
执行连续性审看与版本治理
按镜头顺序制作接触表,逐项比较身份、状态和关系;把问题分成“局部修复、重新生成、资产基准更新、叙事状态修订”。
完成标准:每个偏差都有责任字段、处理结果和新版本号;批准、弃用与待审状态互斥且清晰。
判停条件:若一天新增量已经超过可标注和审批带宽,暂停生成,先清理未归档资产。
交付最小数据包
输出实体登记表、身份卡、批准视图包、状态/连续性表、版本记录、生成引用规则和失败示例集。
完成标准:另一位成员只用该数据包即可准确引用实体,并判断一张新图是否破坏身份或状态。
B — 边界(Boundary)
不要在以下情况单独使用此 skill
一次性、低风险且不会复用的素材;完整资产治理的成本可能高于返工成本。
问题只涉及全片色彩、光线或成像质感漂移,实体身份和状态并未变化;改用
visual-calibration-loop或cross-shot-consistency-audit。项目尚未确定哪些角色、商品或道具具有叙事优先级;先明确创作北极星和最小 Visual Bible。
课程中的失败模式
生成速度超过治理能力:一天产生数百张图,却没有稳定 ID、版本、通过/淘汰状态和镜头归属,产量会转化为认知债务。
把名字当身份锁:角色名、主体 token 或单张参考只提供线索,不保证跨模型、跨视角或长序列一致。
完整工业规范压给所有项目:按风险裁剪字段;未被使用的表格不是专业,只是流程负担。
讲者的盲点 / 时代局限
个人桌面主体库不等于团队资产系统;团队还需要权限、责任人、审批、版本冲突和审计规则。
角色/场景参考必须保留来源、授权和使用范围;不能把来历不明的图片直接沉淀为长期资产。
课程案例主要证明“有帮助”,没有量化跨镜头准确率;任何平台的主体库功能都不能替代视觉验收。
此系统治理外观与状态,不自动解决角色表演、剧情弧光、声音连续性或剪辑节奏。
容易混淆的方法
文件命名只是入口;实体系统还必须包含不变量、状态、批准证据、镜头关系和版本历史。
视觉 Bible 规定全局世界规则;实体卡规定某个对象;连续性表规定该对象在某时某镜头的状态。
来源
source_book:《AI 创作体系:视觉 Bible、工作流与 Agent Skill》(三期课程),MokeLMa
source_chapter:视频 01 00:19:03–00:24:00、00:43:37–00:44:28、01:03:34–01:04:03;视频 02 00:27:02–00:36:00;视频 03 00:14:02–00:20:10
tags:asset-management, entity, character-consistency, continuity, versioning
相关 Skills
depends-on:
minimum-visual-bible— 实体字段和批准视图继承项目视觉契约。作为 depends-on 前置:
cross-shot-consistency-audit以实体身份、状态和版本作为审计基准。
现有生态接入
hands-off-to:
character-continuity-bible— 本 Skill 维护跨集、跨模型、跨镜头的实体 ID、状态与版本事实源;后者把当前版本编译成单次生成可直接使用的身份、服装、道具、场景和空间锁。records-with:
creative-production-ledger— 每次生成记录实体 ID、状态 ID、版本和参考角色,产出获批后再按规则回写事实源。receives-from:
production-design-worldbuilding— 世界与美术设计定义实体应当属于什么文化和规则系统;本 Skill 只治理复用、状态和连续性,不替代设计。receives-from:
action-choreography-reference— 接收需要跨镜头、片段或集数持续的伤势、体力、装备与环境状态变化;只登记已批准的持续状态,不记录每次命中的局部微反应。
审计信息
验证通过:V1 ✓ / V2 ✓ / V3 ✓
测试通过率:100%(独立路由盲测)
蒸馏时间:2026-07-13
Comments & Questions (0)
No comments yet
Be the first to comment!