Jellyfish分镜状态机深度剖析：shot.status与候选确认表的完整设计逻辑

Jellyfish分镜状态机深度剖析shot.status与候选确认表的完整设计逻辑【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址: https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish在 JellyfishAI 短剧一站式生产工作台中分镜状态机shot.status与两张候选确认表共同决定了一个镜头是否具备生成视频的条件。本文将用通俗的方式带你理解这套状态流转的完整设计逻辑帮助你快速掌握 Jellyfish 从剧本提取到视频生成的状态判定机制。为什么要设计分镜状态机AI 短剧的生产流程是剧本 → 分镜提取 → 资产/对白确认 → 生成视频。中间环节最怕的就是状态不清——前端说差不多了后端却说条件不足。Jellyfish 的解法是把正式状态统一交给后端维护前端只消费结果。核心分工如下数据项职责shots.status系统流程状态只由后端更新shots.skip_extraction用户声明当前镜头无需提取shot_extracted_candidates资产候选角色/场景/道具/服装的确认明细shot_extracted_dialogue_candidates对白候选的确认明细这一设计在 shot-status-flow.md 中有完整说明。shot.status只有两个正式状态状态枚举定义在 types.pypending当前镜头还没有完成视频生成前的确认流程ready已完成信息提取确认具备进入视频生成的前置条件这里有一个容易被忽略的细节运行中的生成任务不再写入shot.status。生成中这个动态状态由GenerationTask / GenerationTaskLink任务表实时聚合得出而不是占用一个静态状态。这避免了生成中/生成失败/生成完成等状态与流程状态互相污染的问题——静态归静态动态归任务。ready 的判定规则5 条重算逻辑状态的真正裁判是 shot_status.py 中的recompute_shot_status它按以下顺序重算skip_extraction true→ 直接ready从未提取过last_extracted_at为空→pending提取过但没有任何候选项 →ready所有资产候选与对白候选都已处理完 →ready其他情况 →pending其中处理完的口径是资产候选candidate_status linked已关联真实资产或ignored已明确忽略对白候选candidate_status accepted已接受并写入对白表或ignored只要还有任意一条候选处于pending镜头就停留在pending。注意一个宽松点没有对白候选不会阻塞 ready空镜、纯氛围镜头都能顺利通过。两张候选确认表状态机的明细账本候选表的模型定义在 studio_shots.py建表脚本见 002-add-shot-extracted-candidates.sql。资产候选表 shot_extracted_candidates记录镜头级资产提取确认明细不是最终资产本身。每条候选包含candidate_typecharacter / scene / prop / costume四类candidate_statuspending / linked / ignoredlinked_entity_id关联成功后指向的真实资产实体payload保留提取时的附加信息描述、缩略图、置信度等confirmed_at确认时间戳理解口诀一条提取候选 → 先进入 pending → 用户确认关联后变 linked或忽略后变 ignored。候选关联到的角色、场景、道具等实体就是上图资产管理页中维护的正式资产。对白候选表 shot_extracted_dialogue_candidates与资产候选分表存储避免把对白确认流和实体关联流混在一起。每条对白候选包含index镜头内对白排序text/line_mode对白文本与模式对白、画外音、电话等speaker_name/target_name说话者与听者candidate_statuspending / accepted / ignoredlinked_dialog_line_id接受后写入的正式对白行 ID理解口诀一条对白候选 → pending → 用户接受后写入ShotDialogLine并变 accepted或忽略后变 ignored。三条典型状态流转路径路径 A正常提取确认extract 提取 → 资产/对白候选分别写入 pending → 用户逐一确认linked / ignored / accepted → 全部候选 resolved → shot.status ready路径 B明确无需提取用户设置 skip_extraction true → shot.status ready路径 C取消关联 / 替换回退原 candidate linked → 用户删除关联 / 替换角色 / 清空场景 → candidate 回退到 pending → shot.status 重新计算路径 C 是这套状态机的关键保障状态只向前算而不依赖人工标记任何回退操作都会触发重算保证ready永远真实可信。后端已接入的自动回写点角色关联、场景切换、对白接受/忽略等 10 类动作详见 shot-status-flow.md。前端约束与页面职责边界Jellyfish 明确规定前端不再自行推导shot.status也不再手动写回 pending/ready而是调用后端接口并直接使用返回的最新ShotRead。对应到页面职责前端代码位于 ChapterShotEditPage.tsx 与 ChapterStudio.tsx分镜编辑页单镜头准备台提取候选、确认候选、把镜头推进到ready分镜工作室生成工作台查看 video-readiness、生成关键帧/参考图/视频连续推进多个镜头推荐主流程分镜编辑页完成提取与确认 →shot.status ready→ 进入分镜工作室生成视频。一个负责准备一个负责生成边界清晰。总结Jellyfish 的分镜状态机设计有三个值得借鉴的点状态收敛正式状态只保留pending / ready两个生成中等动态状态交给任务系统明细账本候选表逐条记录确认过程ready由数据推导而非人工标记自动回算任何关联/取消/替换操作都触发状态重算保证判定始终可追溯对于新手来说只需记住一句话镜头变 ready 的唯一标准是所有提取候选都已被明确处理——要么关联要么忽略没有悬而未决。【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址: https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考