以下对象字段、状态名和代码是同类短剧系统的设计示例，供工程评估使用，不代表嘟哩已公开的接口或内部数据库结构。嘟哩的产品流程以当前手册和实际版本为准。
剧本节点接收的输入不只有一种：用户可能直接编辑文本、上传已有剧本，也可能上传小说后由模型改编。如果系统只保存最终正文，下游很难回答"这版剧本从哪里来、改过什么、主体提取使用了哪一版"。
嘟哩剧本节点提供自写、上传和小说转剧本入口，并把剧本放在画布中继续优化和分集。若自行实现类似链路，建议显式保存来源与版本，而不是把所有操作覆盖到一个文本字段。
嘟哩剧本节点及后续制作入口
字段 含义 生成时检查
script_id 稳定剧本标识 同一剧本修订不新建无关身份
source_type manual/upload/novel_adapted 记录输入来源
source_ref 上传文件或上游节点 校验用户访问权限
revision 剧本版本 下游节点引用具体版本
review_state draft/reviewed/approved 未确认版本是否允许下游批量执行
建议流程：
input -> normalize -> draft revision -> human review -> optimize -> downstream refs
小说改编任务还要区分原文与改编文本，保存章节范围、用户指令和模型输出版本。改编结果为空、上传文件解析失败或上游版本已更新时，应阻断下游自动推进并提示重新确认。
例如分集节点引用 script_id + revision，主体提取也保存相同引用。修改剧本后，系统可提示哪些主体和分集基于旧稿，而不是静默覆盖。
MVP 可以先做单项目、多版本、明确确认和下游引用，不必第一版就实现复杂 diff 或协同冲突合并。AI 生成稿不能自动视为定稿，人物关系、情节取舍和版权仍由内容负责人确认。
对于长文本，章节拆分要保留原文定位。可用 source_document_id + chapter_id + paragraph_range 指向来源，而不是只留上传文件名；若导入格式无法识别段落，可退化为页码或文本偏移，并把定位精度标为近似。
版本并发修改也需处理。编剧和 Agent 同时基于 v3 修改时，先提交的一方创建 v4，后提交的一方不能静默覆盖；可让用户重新基于 v4 生成，或把后续修改另存为候选分支。首期不必做在线协同编辑，但至少要提示版本冲突。
验收数据可覆盖纯文本、带目录的 Word、扫描 PDF、重复文件名、空文本和超长文档。检查解析结果、来源定位、失败提示、版本号和下游引用，避免接口成功但内容没有正确进入制作。
事件记录与下游失效策略
剧本节点每次保存可记录 script_revision_created、revision_approved、source_replaced 等事件。事件用于审计和恢复，不一定全部暴露给普通用户。用户查看版本历史时，至少能看到创建人、时间、来源类型和当前状态。
下游失效不宜简单删除。假设分镜引用 v3，剧本更新到 v4 后，系统可以标记分镜为 stale，仍允许预览 v3 结果；用户确认后才重拆受影响场次。这样项目中保留了"历史上用过什么"和"现在推荐什么"两种信息。
可以为节点输入定义校验器：上传对象存在且可读、文件类型受支持、正文非空、字符数在处理范围内、用户有项目编辑权限。校验失败返回具体问题，例如"文档解析为空"或"当前账号无该文件读取权限"，避免统一显示"生成失败"。
小结：把输入变成可追溯对象
自写、导入和小说改编最后都可以形成 ScriptRevision，但来源、原文范围和任务约束应保留。节点模型的主要收益是下游知道自己使用了哪一稿，失败时可以回退，修改后能识别受影响对象。版权判断和改编取舍仍属于业务流程，不能由版本状态自动推断。
重试解析，不能重复触发付费改编
将文件导入拆成 upload、parse、normalize、adapt 四步，每步输出独立标识。解析已成功、改编超时时，应使用现有解析文本恢复，不能把文件重传视为唯一恢复方式。相同文件名也不能作为去重依据，至少结合内容摘要和用户选择的改编范围。
可采用以下校验顺序：
check_read_permission(source)
parsed = load_successful_parse(source_revision)
assert parsed.scope_covers(requested_chapters)
create_adaptation(input_ref=parsed.id, base_revision=current_revision)
原文只有部分章节解析成功时，返回可见范围和缺失范围；禁止用空字符串代替缺失章节继续生成。用户可以缩小任务或换文件，系统不用猜测缺失剧情。
验收时尤其关注后续引用：同一场次改过两版，主体节点是否仍能指出输入版本；批准新稿后，旧分镜是否保持可追溯。嘟哩支持从剧本节点继续优化和分集，这是使用流程；上述去重和恢复机制是同类系统实现建议，不应被当作现有接口说明。