novel-to-screen-adaptation

name novel-to-screen-adaptation x-chancellor-os true lastUpdated 2026-08-01T00:00:00.000Z description Novel-to-Screen Adaptation Protocol. Not a script-writing skill. A translation machine that decomposes a novel into proposition, engine, objects, scenes, episode structure, and screenplay — in that order. 中文名：改编流 / 小说改编剧本协议。触发词：改编流/小说改编/剧本改编/改编剧本/小说转剧本/小说到剧本/改编协议。将小说分解为命题、发动机、物件、场景、剧集结构与剧本的转译协议（不是写剧本的 skill）。 Novel-to-Screen Adaptation Protocol 小说到屏幕剧本转译协议 Core Thesis Adaptation is not preserving the original text. It is preserving the narrative function and replacing the information carrier. 改编不是保留原句。改编是保留原句背后的叙事功能，并更换信息载体。 小说信息 = 事实 + 心理 + 因果 + 主题 + 风格 + 世界规则 剧本信息 = 行动 + 冲突 + 可见目标 + 阻碍 + 关系变化 + 信息揭示 + 视听承载 改编 = 保留因果与主题，同时更换信息载体 本协议不产出"好看的小说场景版"。本协议产出"可以拍的剧本"。 Core Sequence 先保真。 再找发动机。 再找屏幕载体。 再重组结构。 最后才写剧本。 5-Phase Structure Phase 0: 预算提醒 / Budget & Scope Contract ↓ Phase 1: 文本拆分 / Source Map ├─ A. 机械拆分（脚本做） └─ B. 戏剧拆分（LLM 做） ↓ Phase 2: 叙事命题 / Narrative Proposition ↓ Phase 3: 改编发动机 + 影视形态 / Adaptation Driver & Screen Format ↓ Phase 4: 屏幕物件系统 / Screen Object System ↓ Phase 5: 内心信息外化 / Interior-to-Screen Translation ↓ 7. 章节→剧集功能 / Episode Function Map 8. 情节节点 + 关键场面 / Plot Node & Set-Piece 9. 场景卡 / Scene Cards 10. 节拍表 → 剧本正文 / Beat Sheet → Screenplay Draft 导演模式工作流（Director-Mode Workflow） 本协议由 导演驱动 执行，不再批量自动流水线：每一阶段产出后暂停，向导演出示一屏样片摘要，收到导演指令后只重跑目标阶段及其下游，并强制出示 before/after diff。机械环节（文本拆分、格式校验、schema 检查）保留自动；判断性决策由导演（用户）做出。 本协议即执行方式 ——创作阶段按本文档在 Claude 会话内执行，不依赖外部 runner 编排（见 §10）。 出处：Main Design（2026-08-01 APPROVED v5，导演模式重构）。交互骨架（通过/修改/自检三命令）借鉴 @山音 screenwriting-master（MIT），只借骨架，不复制其结构原文。 1. 样片循环（Sample Loop） 每阶段产出 → 样片摘要（一屏）→ 导演指令 [通过] / [改:<自由文本批注>] / [自检] / [评审 <checkpoint 或场景>] → 只重跑目标阶段及下游（依赖级联，见 §7）→ 强制 before/after diff → 再次出示样片 指令语法： 指令 含义 持久化产出 [通过] 签核本阶段产出，进入下一阶段 ack status=PASSED + 裁决日志 [改:<批注>] 批注经「批注→返修指令编译器」（§9）转为目标阶段 + 具体修改 ack status=REVISE + compiledAction [自检] 对已产出物做机械检查（schema/字段/链路），不产审美结论 自检报告 + 裁决日志 [评审 <目标>] 按需召集评审团（08-review-iteration 第三模式承接），导演当唯一法官 评审记录 → 裁决日志 [改:] 的批注必须先经编译器转为 compiledAction: {targetStage, instruction, confidence} 写入 ack 文件，再驱动重跑（重跑起点 = targetStage + 下游级联），不得直接整链重跑。 1a. 指令呈现协议（AskUserQuestion 选择框） 导演指令 用 Claude 自己的选择框（AskUserQuestion）弹出 ，不裸等文本输入——借鉴 gstack 的 AskUserQuestion 交互（Main Design 2026-08-01：「样片摘要模板…借鉴 gstack AskUserQuestion」）。 出示样片摘要后，必须调用 AskUserQuestion 弹出导演选项 ： question: <checkpoint> 样片已出示，导演指令？ header: 导演指令 选项（≤4 个，推荐项放第一位并标注「（推荐）」）： [通过] —— description: 签核本阶段产出，进入下一阶段（如推荐通过则标注推荐） [改:<批注>] —— description: 批注经编译器转 compiledAction 后驱动重跑；批注请选 Other 输入 [自检] —— description: 对已产出物做机械检查（schema/字段/链路），不产审美结论 [评审 <目标>] —— description: 召集评审团（08 第三模式承接）；目标请选 Other 输入 四命令恰好放满 4 个选项上限；需要自由文本的指令（改:/评审 目标）由用户选 Other 输入，按指令语法解析 decision 映射：通过→pass / 自检→self_check / 评审→council / 改→revise；自由文本按前缀解析（decision 枚举见 §3） rationale 必填 ：导演的理由取用户注解（AskUserQuestion 注解栏）；无注解时记「导演选择 <选项>，样片摘要推荐理由：<…>」——理由缺失 = 裁决未完成 不改变 ack 文件协议与 gate 状态机 ：呈现方式只是交互层，ack status（PASSED/REVISE）、compiledAction、单写入者等协议原样执行（见 §11 与 frameworks/13） 回退 ：非交互环境（无法弹出选择框）退回文本等待，导演以 [通过] 等指令语法输入，协议其余部分不变 2. 样片摘要模板（决策简报格式） 每个阶段收尾前，把产出压缩为一屏决策简报： ## <阶段名> 样片 关键决策：<本阶段做的 1-3 个判断> Gate 证据：<机械检查结果 PASS/FAIL/WARN + 证据文件引用> 是否需要导演判定：是（分诊点）/ 否 推荐：<导演倾向的选项 + 一句理由> 选项与代价：<2-3 个选项 + 各自的人力/token 代价> 下一步：通过 / 改: <批注> / 自检 / 评审 <目标> 规则： Gate 证据必须引用具体证据文件（如 checkpoints/01-source-map.json 、 09-scene-cards/EP03-S05.md ），不写空话 推荐是给导演支点，不是替导演决定；选项必须带代价（人力/token），「通过」才是知情选择 3. 裁决日志（味觉记忆最小版） 每次导演裁决（通过/改/自检/评审/终裁）记录一条 jsonl： {"checkpoint": "07-episode-map.json", "decision": "revise", "rationale": "EP03 的功能与 EP02 重复：白焰登场与私人猎人是一条线", "timestamp": "2026-08-01T10:23:00+08:00"} 字段： {checkpoint, decision, rationale, timestamp} ；decision ∈ pass | revise | revert | self_check | council | confirm_warn | accept | cut | terminate 理由必须记录 （"为什么删这场戏"）——理由缺失 = 裁决未完成 存储： checkpoints/director-log.jsonl ，追加写不覆盖 展示与加载：最近 5 条随样片摘要展示；新会话开工自动加载（§6）。裁决日志累积后即导演偏好数据源（味觉记忆最小版；完整版——批注分类归档、按口味过滤候选——出 MVP） 4. 完成状态协议 每个阶段收尾必须声明且只声明一个状态： 状态 含义 DONE 产出 + 签核完整 DONE_WITH_CONCERNS 完成但列出关切（导演可见） BLOCKED 第一阻塞点，附证据 NEEDS_CONTEXT 缺输入，说明缺什么 禁止「基本完成」「大概没问题」——状态缺失 = 阶段未收尾。 5. 分诊白名单（必须导演判定的点） 以下决策点 必须 导演判定（gate = DIRECTOR_WAIT），其余机械可判的自动过： 决策点 阶段 产物 预算分档（SAMPLE/ARC/FULL/PILOT） Phase 0 00-budget-scope.json 命题可改编性 Phase 2 03-main-proposition.md 改编发动机 Phase 3 04-driver-decision.json 剧集结构定夺 Step 7 07-episode-map.json set-piece 取舍（是否值得花预算） Step 8 08-plot-nodes.json 签核 Final 12-sign-off.json 其余 gate：机械可判的 PASS/FAIL 自动过；判断性的 WARN 不阻断前进，但随样片摘要持续展示，直到导演 [确认 WARN] 或 [改:...] FLAGGED（Phase 5 内心外化 compensation 为空 + fidelity < high）优先于分诊 ：不受白名单边界约束，渲染为不可忽略的 WARNED，必须 [确认] 或 [改:...] ，不得自动放行 未处理的 DIRECTOR_WAIT/WARNED：管线不自动前进 6. Session Bootstrap 契约 新会话开工时自动加载以下上下文（恢复"上次干到哪 + 导演口味"）： 最近裁决日志 —— checkpoints/director-log.jsonl 最近 N 条（导演偏好） 最近 checkpoint 摘要 ——按时间戳最新的样片摘要/产物状态 待决 ack 清单 ——status ∈ DIRECTOR_WAIT / REVISE / WARNED 的 checkpoint 等待中的管线不自动前进；任何时刻可查询"我们在哪"（读 ack 文件 + 最新 checkpoint 时间戳）。 7. 协议层依赖图（checkpoints 00→12） Checkpoint 阶段 依赖 00-budget-scope.json Phase 0 —（输入：源文本 + Director's Brief） 01-source-map.json Phase 1A 00（模式决定拆分范围） 02-narrative-function.md Phase 1B 01（source_id 体系） 03-main-proposition.md Phase 2 02 04-driver-decision.json Phase 3 03 05-screen-objects.json Phase 4 02, 03（命题 → 主题绑定） 06-translation-log.md Phase 5 02, 05（屏幕物为载体） 07-episode-map.json Step 7 06 08-plot-nodes.json Step 8 07 09-scene-cards/*.md Step 9 06, 07, 08 10-beat-sheets/*.md Step 10 09（场景卡） 11-screenplay.md Step 10 09（场景卡）+ 10（节拍表） 12-sign-off.json Final 11 + 全部 gate 结果 + 导演 ack 注：Artifact Tree 中的 scene-cards/ 、 beat-sheets/ 即本表 09-scene-cards/ 、 10-beat-sheets/ （命名归一）。 重跑级联 ：「只重跑目标阶段」= 目标 checkpoint + 其全部下游依赖（按上表向下传播）；上游不重跑（除非 diff 显示上游输入变更，此时自变更点起级联）。旧 runner 每阶段重切源文本、阶段独立性从未建立——本表将依赖显式化，是重跑与回退的正确依据。 8. Diff 纪律 每 checkpoint 版本快照： checkpoints/<name>.v<N> （首版 v0，每次返修 +1） 结构化产物 （json：00/01/04/05/07/08）：字段级 diff——diff 主战场 散文产物 （md：02-narrative-function.md、06-translation-log.md、09-scene-cards/、10-beat-sheets/、11-screenplay.md）：节级 diff（按场景/按节）；散文返修默认节级重写，不整文件重写 每次返修必须出示 before/after diff 摘要（改了什么、影响哪些字段/节） 「变差」从感觉变成可回退的事实：导演可 回退 v<N> （恢复快照 + 记裁决日志 + 重跑下游） 9. 返修回路（批注 → 返修指令编译器） 批注（如"第三场怪怪的"）→ 根因分类（复用 08-review-iteration 的 failure-classification）→ 目标阶段 + 具体修改指令（"重写 EP03-S05 节拍结构"） MVP 用确定性路由 （08 现有路由表；置信度校准出 MVP） 路由置信度低（无匹配分类）→ 先回问澄清 （"是节奏还是动机？"），不猜 每 checkpoint 返修上限 2 轮 ；超过后导演在真实决策集终裁： 接受现状 / 召评审团换视角 / 删减元素缩小范围 / 终止该线 ——不把问题抛回导演（导演本身就是发 [改:] 的人） 返修后重跑 08 preflight 连续性检查（continuity-locks、ID 断链） 10. Runner 定位（执行方式） 创作阶段（Phase 1B–Step 10 的全部 LLM 内容产出） 按本协议在 Claude 会话内文档驱动执行 ——本协议即执行器 scripts/ds-pipeline-runner.js 的 9 个 LLM 阶段（1B 叙事功能 / 2 命题 / 3 发动机 / 4 物件 / 5 转译 / 7 剧集 / 8 情节节点 / 9 场景卡 / 10 剧本） 已废弃 ，不再作为执行方式 仅保留机械步骤脚本，会话内按需调用： scripts/source-map.js （Phase 1A 拆分）、 scripts/budget.js （Phase 0 预算）、 scripts/validate-screenplay.js （剧本格式校验） 签核语义：sign-off.json 缺人工 ack 不得生成 （ack status=PASSED 且 signedBy 非空） 11. ack 文件协议（持久化通道） 每 checkpoint 一个 ack 文件（ checkpoints/<name>.ack.json ）： { "checkpoint" : "05-screen-objects.json" , "status" : "DIRECTOR_WAIT | PASSED | REVISE | WARNED" , "directorNote" : "把日记本改成挂在腰间的旧钥匙串" , "signedBy" : "导演（用户确认时间戳）" , "compiledAction" : { "targetStage" : "04-driver-decision" , "instruction" : "重写 EP03-S05 节拍结构" , "confidence" : "high" } , "sessionId" : "<认领会话>" , "waitingSince" : "<ts>" , "reviseCount" : 0 } 状态枚举与 gate 状态机对齐； ack 枚举是持久化事实源 （Reviewer Concern #3） 评审团不是独立状态：DIRECTOR_WAIT 下的进行中标记（waitingSince + 评审记录文件） 单写入者：sessionId 认领恢复权，第二个会话接管需先释放；任一 ack 超 24h 无更新 → 只报告 "管线活动中断"， 接管需导演人工确认 （绝无自动放行；确认后释放旧认领并接管，审计记录保留）——T-B 决定 完整细则（gate 状态机、11 门处置表、级联示例、diff 摘要格式、路由映射表）见 frameworks/13-director-mode.md 12. 输出位置协议（Output Location Contract） 新产出不写入本 skill 目录 ——skill 目录只存定义文件（frameworks/prompts/templates/scripts）。历史遗留（本目录下 output/ 、 星谣/ 为早前的产出）不迁移； 本协议生效后的新产出一律写入工作区 。 开工进入 Phase 0 前，必须用 AskUserQuestion 弹输出位置选项： question: 产出文档输出到哪里？ header: 输出位置 选项（≤4 个）： [默认工作区]（推荐）—— description: State/Foundry/tasks/<项目名>-<YYYYMMDD>/（沿用 Foundry 任务目录惯例） [当前目录] —— description: 写在当前会话工作目录 [自定义路径] —— description: 选 Other 输入完整路径 默认工作区路径规则： State/Foundry/tasks/<项目名>-<YYYYMMDD>/ ；项目名未定用 novel-to-screen-adaptation ；日期用开工日 确定后，本协议各处 checkpoints/ 即指 <输出位置>/checkpoints/ （依赖图、ack 文件、director-log.jsonl 全部落该目录）；样片摘要必须写明输出绝对路径 回退：无交互环境默认「默认工作区」 Mandatory Input — Director's Adaptation Brief 02 协议不得在缺少 Director's Adaptation Brief 的情况下开始。 01 story-analyzer → manifest.json ↓ film-director 读小说 + 读 manifest ↓ 产出 Director's Adaptation Brief（frameworks/00-directors-brief.md） ↓ assistant-director 派发 head-writer 验收 brief → 确认 untouchable_core / cuttable → 开始 02 没有 brief → 02 不得进入 Phase 0。 head-writer 不赞同 brief 中的判断 → 返回 director，不自己改。 详见 frameworks/00-directors-brief.md 。 Q0（Pre-Flight 第一问）：是否有 Director's Adaptation Brief？ 如果没有 → 不得开始 02。退回 film-director。 Phase 0: Budget & Scope Contract 拿到 Director's Brief 后，进入预算检查。第一步不是分析——是先给出预算报告。 SOURCE_BUDGET_REPORT 任何源文本进入时必须先产出： SOURCE_BUDGET_REPORT source_file: 白焰.md line_count: 4528 chapter_count: 13 estimated_reading_passes: 4 estimated_output_size: 2 recommended_mode: ARC risk: medium reasoning: 4528 行超过一次性完整处理的安全预算。建议先做ARC模式（一条完整叙事弧验证），再决定是否FULL。 Processing Modes Mode 适用条件 产出 用法 SAMPLE ≤500 行，或只验证单段落 1 个关键段落剧本 测试风格是否成立 ARC 500-5000 行，或有一条完整弧线 1 条叙事弧的完整改编链 验证改编发动机是否成立 FULL >5000 行，或需要全篇改编 Bible + 分集大纲 + 多集样章 正式生产模式 PILOT 剧集项目 第 1 集完整剧本 + 后续大纲 剧集制作 Budget Hard Rules 如果源文本超过当前上下文安全预算，必须先进入分批索引模式，不得直接生成完整剧本。 ARC 模式必须覆盖：source map → proposition → engine → objects → translation → episode → scene card → beat → 至少 2 场完整剧本 FULL 模式必须分轮：第一轮做 Bible + 大纲，第二轮按集逐批生成 Phase 1: Source Map — 文本拆分 对小说文本的拆分理解。 分两种，手段不同。 1A: 机械拆分（脚本做） 运行 scripts/source-map.js 自动产出： - 按章节标题拆分 → 章节边界 + 行号范围 - 统计每章字数/行数 → 体量分布 - 提取人物名 → 出场频率表 - 提取地点 → 地点清单 - 提取高频物件 → 潜在屏幕物件 - 提取对话比例 → 每章对话/叙述占比 - 提取疑似场景边界 → 空行 + 时间词 + 地点词 - 建立 source_id 体系 → CH01-LN001-CH01-LN320 输出示例： { "chapters" : [ { "id" : "CH01" , "title" : "莱纳崩溃" , "lines" : "1-320" , "wordCount" : 2840 , "dialogueLines" : 86 , "narrativeLines" : 234 , "dialogueRatio" : 0.27 , "characters" : [ "伊沃" , "莱纳" , "卡洛" ] , "locations" : [ "食堂" , "莱纳宿舍" ] , "objects" : [ "日记本" , "墨水" , "蓝色营养剂" ] , "sceneBoundaries" : [ 1 , 42 , 98 , 187 , 320 ] } ] , "characters" : { "伊沃" : { "firstAppearance" : "CH01-LN001" , "mentionCount" : 187 , "role" : "protagonist" } , "莱纳" : { "firstAppearance" : "CH01-LN004" , "mentionCount" : 93 , "role" : "friend" } , "白焰" : { "firstAppearance" : "CH02-LN321" , "mentionCount" : 76 , "role" : "mystery" } } , "objects" : { "日记本" : { "firstAppearance" : "CH01-LN012" , "mentionCount" : 34 } , "蓝色营养剂" : { "firstAppearance" : "CH01-LN089" , "mentionCount" : 18 } , "墨水黑斑" : { "firstAppearance" : "CH01-LN156" , "mentionCount" : 12 } } } 1B: 戏剧拆分（LLM 做） 机械拆分无法判断以下内容，必须 LLM 处理： - 这一段落的叙事功能是什么？ - 谁的立场发生了变化？ - 哪个信息被揭露给读者/观众？ - 哪个物件变成后续伏笔？ - 哪段内心活动需要外化？