叙事转影视开发读本

它解决什么问题

把一段叙事文本丢给影视团队时，最常见的失败不是剧本写得不好，而是在文本还没准备好时就冲进了开发。一段只有情绪堆砌的大纲、一份人物单薄的对话记录、一个只有场景序列的梗概——它们看起来「能拍」，但人物动机、冲突和可回收的视听骨架其实都没立起来。

narrative-to-screen-reader 的工作前提很直接：先有故事，才有后续开发；并且不是所有文本都能直接影视化。所以它做的第一步不是改写，而是判断这份文本目前到了哪一步，以及下一步能做什么、不能做什么。

核心能力

• 快速诊断：从原文证据中提取主要人物、关键场景、关键台词、物件链、动作链、空间链与关系转折，输出 A/B/C/D/D0 五级判定，并说明当前重心、最危险的误开发方式、最值得先保住的东西。
• 多受众读本：同一份文本可拆成完整开发读本、演员读本、编剧改编读本、导演视听读本、制片摘要与 AI 剧本化提示包，分别回答不同的问题——演员看「这个人怎么活着、怎么说话」，编剧看「从哪里切进去改」，制片看「这个项目最值钱的地方和最容易怎么死」。
• 事实与推断分层：把原文明确事实、基于原文的强推断、影视化建议分开书写，避免把推演当成事实；证据不足时明确标注「不足」，不编造。
• 多类型输入适配：长会话记录、短篇小说、中长篇片段、大纲、剧本初稿、互动文本各有策略，例如对话体会先转译成戏剧单元，再判断是否存在「核心对象厚、参与者角色薄」的情况。
• 强制检查点：诊断完成后必须暂停，展示等级与推荐模块并等用户确认，才会生成任何正式读本。
• 文件化交付：所有正式文档写入 .md 文件，会话中只返回摘要和链接。

工作流程

1. 收到文本后先说明「先读故事，再做快速诊断」。
2. 超 50KB 的文本按每批 30–40KB 分批读完，先输出文本概览。
3. 执行快速诊断，按等级从路由表加载对应的 references 文件。
4. 🔴 CHECKPOINT：展示诊断结果并等待确认；用户明确指定「诊断完直接出 XX 读本」或判定为 D0 终止时才跳过。
5. 生成目标读本，写入 Markdown 文件并返回链接。

适用边界

• 这是影视开发前置分析，不是正式剧本化。第二步不会直接重写剧本。
• 重要配角不单独出读本，而是合并进完整开发读本、编剧改编读本和 AI 提示包中处理。
• 原文证据不足时不会补全，只给补写或重构建议；不会为了迎合用户强行改变终局。
• 制片摘要中的预算、周期、集数等数字均标注为粗估或需复核。
• 涉及 D0 红线内容的文本会被立即终止并输出终止说明。