一鱼两吃 · 双线改编创作工坊

把一部小说/故事，同时改编成 一款游戏 与 一部视频（漫剧），输出两份各自独立、
专业详实、可直接对投资人/平台/内部立项演示的完整方案，并编译成一个可离线双击打开的时尚查看器。

"一鱼两吃"的核心不是把同一个故事讲两遍，而是用同一条叙事内核，喂养两种完全不同的媒介逻辑：

• 游戏吃的是 互动性——玩家要"做"这件事，规则、循环、成长必须成立。
• 视频吃的是 观看性——观众要"看"这件事，节奏、画面、情绪必须成立。

何时使用

用户提供任何形式的故事素材（完整文本、片段、梗概、设定集、人物小传、甚至一句话点子），
并希望得到游戏改编方案、影视/漫剧改编方案，或两者兼得时，使用本技能。

交付物

固定产出 1 个目录 + 9 个文件，目录名 <故事名>-一鱼两吃/，放在当前工作目录：

最后用 present_files 展示，顺序：demo.html（会自动打开实时预览）→ pv.html →
viewer.html → 两份 Markdown。Demo 与 PV 是"能玩 / 能放的房子"，方案是"施工图"，
四者缺一不可。

执行流程

第 1 步 · 通读与体检

完整读完用户给的故事。若用户只给了片段或点子，先用 3–5 行确认故事底盘，
再基于合理推演继续，不要停下来反复追问。读完后按 references/adaptation-method.md
的《原著体检表》做一次结构化拆解，产出一张"资产清单"。

第 2 步 · 提取双线资产

按 references/adaptation-method.md 的方法，把原著拆成两组资产：

• 可玩性资产：可规则化的世界设定、可量化的成长、可对抗的关系、可探索的空间、天然循环
• 可拍性资产：视觉奇观、强情绪节点、悬念钩子、可表演的人物关系、名场面

再给出"吃法判断"：这个故事更适合游戏优先、影视优先，还是双强？并说明理由。

第 3 步 · 写总览

用 references/adaptation-method.md 末节的《总览模板》写 00-overview.md。
必须包含一张 "同一内核 × 两种媒介"对照表，说明两案共享什么、分叉在哪里。

第 4 步 · 写游戏设计方案

加载 references/game-design-spec.md，严格按其中的《章节骨架》与《质量标尺》写 10-game.md。

要求：
- 覆盖 核心玩法 / 叙事结构 / 系统设计 / 制作思路 / 可演示 Demo 五大板块，缺一不可
- 核心循环必须能画出来，且用文字把循环图讲清楚
- 系统设计要给出具体数值框架或表格，不能只写"有养成系统"
- 制作思路要有里程碑排期与风险对策
- Demo 章节给出垂直切片定义：场景、时长、展示点、操作流程、验收标准、情绪目标

第 5 步 · 写视频（漫剧）设计方案

加载 references/video-design-spec.md，严格按其中《章节骨架》与《质量标尺》写 20-video.md。

要求：
- 覆盖 分镜节奏 / 视觉风格 / 剧情改编 / 视频呈现 / 可演示 Demo 五大板块，缺一不可
- 剧情改编要给出取舍说明与分集节拍表
- 分镜节奏要到 时间码级别（镜头号/时间码/景别/运镜/时长/声音）
- 视觉风格要给出色彩脚本、参考片单、镜头语言规则
- Demo 章节给出一集（或一支预告）的完整可制作清单

第 6 步 · 生成查看器

写 manifest.json（字段见 references/viewer-spec.md），然后执行：

python "<skill_dir>/scripts/build_viewer.py" --manifest "<工作目录>/manifest.json" --out "<工作目录>/viewer.html"

Windows 下若 python 不可用，用 C:/Users/<user>/.workbuddy/binaries/python/versions/3.13.12/python.exe。
脚本零第三方依赖。脚本输出里每个 track 的章节数必须大于 0，否则说明正文缺少 ## 标题。

第 6.5 步 · 生成可玩 Demo 与动态分镜 PV

这一步产出"房子"，前五步产出"施工图"。缺了这一步，交付不算完成。

1. 写 demo-spec.json：从 10-game.md 第七章的垂直切片里挑 6–12 分钟可玩的一段，
   按 references/demo-spec.md 的积木类型（alarm / prose / dialogue / choice /
   allocate / meter / watch / hold / bag / slot / end）写成 JSON。
   铁律："机制讲剧情"——原文案里"橘子扔不掉""多待不加价"这类设定必须变成真实的
   禁用按钮和 ¥0 回报，不许用台词解释。
2. 写 pv-spec.json：把 20-video.md 里的 PV（或首集）分镜表逐镜转成 JSON，
   每镜给 t / size / motion / visual / c1 / c2 / say / sub / sfx / note。
   铁律：每镜的 note 必须能回答"为什么要有这一镜"。
   片名卡那一镜别只写 {"visual":"black"}——要把片名给进去：
   "params": {"title": "《故事名》", "sub": "概念 PV · 改编自 原著名"}，否则画面是空的。
3. 编译：

python "<skill_dir>/scripts/build_demo.py" --spec "<工作目录>/demo-spec.json" --out "<工作目录>/demo.html"
python "<skill_dir>/scripts/build_pv.py"   --spec "<工作目录>/pv-spec.json"   --out "<工作目录>/pv.html"

4. 必须实测（不要只看脚本是否退出 0）：
   - 两个文件的 <script> 抽出来用 node --check 过一遍语法；
   - 有无头浏览器就真机通关一遍 Demo（点到 end 结算页为止），抓 pageerror / console.error；
   - PV 用 ←/→ 走完全部镜头，截 3–5 张关键帧确认色彩脚本没跑偏。
   - 已知坑：脚本作用域的 const 不挂在 window 上，用 page.evaluate 时要直接写 SPEC、S。

第 7 步 · 自检并交付

逐条过 references/viewer-spec.md 的《交付自检清单》，再过一遍
references/troubleshooting.md 的《写作反模式清单》（12 条，中招就改）。
然后调用 present_files，按这个顺序：

demo.html（会自动打开实时预览）→ pv.html → viewer.html → 10-game.md → 20-video.md → 00-overview.md

Demo 与 PV 是"能玩 / 能放的房子"，方案是"施工图"，四者缺一不可——不要只交 Markdown。
最后在回复里说清楚：Demo 怎么操作（哪个键蓄力、哪个键拒绝）、PV 多长、录音/录屏能不能直接当提案用。

写作铁律

1. 两份方案必须能各自独立成立。读者只拿到 10-game.md 时，不需要读 20-video.md 也能完全理解。
   禁止出现"如前文视频方案所述""详见另一份方案"这类交叉依赖。
2. 专业术语要用对。游戏侧用：核心循环、心流、动词、垂直切片、数值产出与消耗、留存曲线；
   视频侧用：节拍表、景别、构图、色彩脚本、场面调度、声音设计、蒙太奇。
3. 拒绝空话。每一句判断后面跟一个具体例证、数字或可执行动作。"玩法非常有趣"是废话，
   "玩家每 12 秒做一次高风险选择"才是设计。
4. Demo 必须可演示。给人一个能想象出画面的场景，而不是一段形容词。
5. 尊重原著内核。可以大胆改结构、改媒介，但必须说清楚保留了什么、为什么保留。

参考文档