简介：这是一份面向网文作者、漫剧编剧与AI内容创作者的Claude Code Skill资源包，聚焦将网络小说高效改编为标准漫剧剧本这一具体场景。它内置五阶段全自动工作流，从原著解析、人物与大纲梳理，到分集剧本生成、质检报告输出，形成可复用的工业化改编链路，帮助创作者摆脱逐句改写与反复抽卡的繁琐流程。压缩包共21个文件，约47KB，以14个md文档为主体，承载技能说明、设计规范、角色设定、大纲与示例剧本等核心内容，另含txt示例文本、json项目配置、sh安装脚本及license等辅助文件，结构清晰、便于直接接入使用。目前已有52人学习下载。读者可借此掌握一套可落地的漫剧剧本改编方法论，获得角色设定、分集大纲、质检报告等模块化产出模板，并参考示例工程快速搭建自己的改编工作流。

1. 网文改编漫剧剧本的 Claude Code Skill：五阶段工作流到底在解决什么

手里有一本三百万字的网络小说，想改成漫剧剧本，最笨的办法是人工通读、拆章、提炼分镜、写台词、再统一格式。一个熟练编剧改一集三分钟的漫剧，从读原文到出稿，少说两三个小时，一本长篇改下来就是几个月。真正卡住进度的不是创意，而是那些重复到令人崩溃的机械劳动：把小说段落切成场景、把心理描写转成可拍的画面、把叙述性语言改成角色对白、再按漫剧的格式规范排版。Claude Code Skill 这类东西的价值，就是把这套流程固化成一个可复用的工作流，让 AI 按固定阶段跑，而不是每次从零写提示词。

这个标题里的「五阶段全自动工作流」，本质是把改编拆成五个前后依赖的步骤，每个步骤有明确的输入输出，前一步的产物是后一步的原料。它适合两类人：一类是手里有网文 IP、想快速产出漫剧剧本初稿的编剧或工作室；另一类是熟悉 Claude Code、想用 Skill 机制搭自己内容流水线的工程师。不适合指望一键出成片的人——它产出的是剧本文本，不是分镜图，更不是视频。下面按「先讲清每个阶段在干什么、再落到 Skill 怎么写、最后说坑」的顺序展开，中间会给出可直接抄的 Skill 配置和提示词骨架。

2. 五阶段工作流拆解：从小说原文到漫剧剧本的每一步

2.1 为什么是五个阶段而不是一个大提示词

很多人第一反应是写一个超长提示词，把小说丢进去让模型直接输出剧本。实测下来这条路基本走不通，原因有三个。第一是上下文长度，一本网文动辄几百万字，任何模型都塞不下，必须分块处理。第二是任务耦合，改编里混了「理解剧情」「切分场景」「转换对白」「格式化」四类完全不同的认知任务，混在一起模型容易顾此失彼，切场景的时候忘了对白规范。第三是不可控，一个大提示词跑出来的结果没法局部重跑，第三集格式错了你得整本重来。

五阶段拆分的核心思路是「每步只做一件事，产物可检查可回滚」。常见做法是拆成：原文预处理与章节切分、剧情要点提取、场景与分镜拆分、对白与旁白生成、格式规范化输出。这五步里，前两步是「读懂」，中间两步是「转化」，最后一步是「对齐规范」。每一步的输出都存成中间文件，这样某一步出问题，只重跑那一步，前面的成果不浪费。

提示：阶段数不是死的。如果你的小说已经有人工整理好的章节梗概，第一步可以省掉，变成四阶段。五阶段是覆盖「从零开始」的最全版本。

2.2 每个阶段的输入输出契约

要让工作流稳定，关键是给每个阶段定死输入输出格式。我一般用 JSON 做中间产物，因为结构化好校验。下面这张表是我实际用的契约，字段名可以改，但结构建议保留。

这张表的价值在于，它让每一步都能单独测试。比如你怀疑对白生成有问题，直接拿一份场景 JSON 喂给第四阶段，不用跑完整条链。这也是 Skill 能做成「可维护」而不是「一次性脚本」的前提。

2.3 用 Claude Code Skill 把阶段串起来

Claude Code 的 Skill 机制，简单说就是把你的一套提示词、脚本、配置打包成一个可调用的能力单元。它和普通提示词的区别在于：Skill 可以带文件、带脚本、带多步逻辑，模型调用它的时候是按你定义的流程走，而不是自由发挥。这正好适合五阶段这种有固定顺序的流水线。

一个最小可用的 Skill 目录结构大概是这样：

manju-script-skill/ ├── SKILL.md # 技能说明，告诉 Claude 什么时候用、怎么用 ├── prompts/ │ ├── stage1_split.md │ ├── stage2_extract.md │ ├── stage3_scene.md │ ├── stage4_dialogue.md │ └── stage5_format.md ├── scripts/ │ └── run_pipeline.py └── schema/ └── stage_contract.json

SKILL.md 是入口，写清楚这个 Skill 干什么、触发条件、以及五个阶段怎么调。下面是一个骨架示例：

--- name: manju-script description: 将网络小说改编为标准漫剧剧本，五阶段流水线 --- # 漫剧剧本改编 Skill ## 使用场景 当用户提供网络小说文本，要求改编为漫剧剧本时触发。 ## 工作流 1. 调用 scripts/run_pipeline.py 的 split_chapters 切分章节 2. 对每章调用 prompts/stage2_extract.md 提取剧情要点 3. 对每个要点调用 prompts/stage3_scene.md 拆分场景 4. 对每个场景调用 prompts/stage4_dialogue.md 生成对白 5. 汇总后调用 prompts/stage5_format.md 输出标准剧本 ## 约束 - 每阶段输出必须符合 schema/stage_contract.json - 单章原文超过 8000 字时先分块 - 对白生成阶段禁止添加原文没有的情节

这段 SKILL.md 的关键是「约束」部分。模型在跑 Skill 时，约束写得越具体，跑偏越少。比如「禁止添加原文没有的情节」这一条，能挡掉大量模型自作主张加戏的情况。

2.4 阶段一和阶段二：切章与要点提取的提示词写法

阶段一看似简单，其实有坑。网文的章节标题格式五花八门，有的用「第X章」，有的用「Chapter X」，有的干脆只有数字。纯正则切不干净，得让模型辅助判断。我一般先用脚本做粗切，再用模型修正边界。

import re def split_chapters(raw_text): # 粗切：匹配常见章节标题模式 pattern = r'(第[零一二三四五六七八九十百千\d]+章[^\n]*)' parts = re.split(pattern, raw_text) chapters = [] # parts[0] 是标题前的内容，通常丢弃或并入第一章 for i in range(1, len(parts), 2): title = parts[i].strip() body = parts[i+1].strip() if i+1 < len(parts) else '' chapters.append({ 'chapter_id': (i+1)//2, 'title': title, 'raw_text': body }) return chapters

这段代码的逻辑是：用正则把「第X章」这类标题作为分隔符，切出来的奇数位是标题、偶数位是正文。参数上，pattern里的字符集覆盖了中文数字和阿拉伯数字，如果你的小说用「卷」「节」做单位，需要相应扩展。切完之后一定要抽查前几章和后几章，网文经常有「作者的话」「求票」这类非正文内容混在章节里，得在阶段一就过滤掉，否则会污染后面的要点提取。

阶段二的要点提取，提示词要逼模型输出结构化结果，而不是写一段读后感。下面是我常用的骨架：

你是网文剧情分析助手。请阅读以下章节内容，提取： 1. 本章核心剧情点（3-5 条，每条一句话） 2. 出场角色列表（含角色名和本章作用） 3. 关键冲突或转折 严格按 JSON 输出，不要输出任何解释文字： { "chapter_id": <数字>, "plot_points": ["...", "..."], "characters": [{"name": "...", "role": "..."}], "turning_point": "..." } 章节内容： {{chapter_text}}

这里「严格按 JSON 输出，不要输出任何解释文字」这句很重要。不加这句，模型经常在 JSON 前后加一段「好的，我来分析一下」。加了之后，配合代码里的 JSON 解析容错，成功率能到九成以上。

3. 场景拆分与对白生成：改编质量的分水岭

3.1 从剧情要点到可拍场景的转换逻辑

阶段三是最考验「改编思维」的一步。小说里一段「他站在山顶，回想起三年前的种种」，在剧本里不能直接这么写，得拆成：场景（山顶，黄昏）、动作（角色站立远眺）、可选的闪回场景。这一步做不好，后面生成的对白就是无根之木。

我的做法是让模型按「地点 + 时间 + 动作 + 情绪基调」四要素输出场景。提示词里要明确告诉它：心理描写要转成外部动作或旁白，不能保留大段内心独白。下面是一个场景拆分的输出示例：

{ "scene_id": "ch12_s1", "location": "宗门后山悬崖", "time": "黄昏", "action_desc": "主角独立崖边，手握断裂的玉佩，风吹动衣袍", "emotion": "压抑的愤怒", "source_plot": "主角得知师门被灭后独自来到后山" }

参数上，source_plot字段是溯源用的，方便你回头核对这个场景是从哪条剧情点来的。emotion字段会直接影响阶段四对白的语气，所以不能省。如果原文是群像戏，一个剧情点可能拆出多个场景，这时候要让模型输出场景数组，而不是单个对象。

3.2 对白生成：让角色说人话而不是念旁白

阶段四最容易翻车。模型很容易把小说里的叙述句直接改成「角色说：……」的形式，读起来像在念课文。真正的对白要有潜台词、有停顿、有情绪起伏。提示词里我会加几条硬约束：

根据以下场景生成漫剧对白。要求： 1. 每句对白不超过 30 字，漫剧节奏快，长句拆短 2. 对白要体现角色性格，避免所有角色说话一个腔调 3. 心理活动优先转为动作描述或简短旁白，不要写成角色自言自语 4. 每段对白标注情绪，用于后续配音参考 场景信息： {{scene_json}} 输出格式： { "scene_id": "...", "dialogues": [ {"role": "角色名", "line": "台词", "emotion": "情绪", "action": "伴随动作"} ] }

「每句不超过 30 字」这条是血泪经验。漫剧单集时长通常两三分钟，对白太长根本配不完，而且观众记不住。action字段是给分镜师看的，写清楚角色说这句话时在干什么，比如「握拳」「转身」「低头」，这些细节能让后续制作省很多沟通成本。

3.3 阶段五：格式规范化与批量输出

前四阶段跑完，你手里是一堆 JSON。阶段五的任务是把它们拼成一份能直接交给制作方的剧本。漫剧剧本的格式各家不同，但通用要素差不多：场景标题、场景描述、角色对白、动作提示。下面是一个格式化脚本的核心逻辑：

def format_scene(scene, dialogues): lines = [] # 场景标题行 lines.append(f"【场景】{scene['location']} - {scene['time']}") lines.append(f"【描述】{scene['action_desc']}") lines.append("") # 对白逐条输出 for d in dialogues: lines.append(f"{d['role']}（{d['emotion']}）：{d['line']}") if d.get('action'): lines.append(f" △ {d['action']}") lines.append("") return "\n".join(lines)

这段代码里，△是动作提示的常见标记，不同团队可能用不同符号，改成你们内部规范就行。emotion放在角色名后的括号里，是给配音演员看的。批量跑的时候，把所有场景按scene_id排序后依次调用这个函数，最后拼成一个 md 文件。

注意：格式化阶段不要做任何「创作」，只做排版。一旦让模型在这一步润色文字，前面四步辛苦建立的结构就白费了，而且会引入不可控的改动。

4. 避坑与排查：五阶段工作流跑不通时先看这几条

4.1 章节切分把正文切碎了

现象：跑完阶段一，发现某些章节内容明显不完整，或者一章里混进了下一章的开头。原因通常是小说里存在「第X章」之外的标题格式，比如「序章」「番外」「上卷」这类，正则没覆盖到。解决办法是先把所有可能的标题模式列出来，扩展正则的字符集，或者在粗切后加一步模型校验：把切分结果的前后各 200 字喂给模型，问它「这里是不是章节边界」。我一般会在切分脚本里加一个validate_boundaries函数，对可疑边界做二次确认。

4.2 要点提取漏掉关键剧情

现象：某几章明明有重要转折，但提取出的plot_points里没有。原因是模型对「重要」的判断和你不一致，它可能觉得打斗场面重要，而你觉得感情线重要。解决办法是在提示词里给出明确的判断标准，比如「优先提取推动主线剧情的事件，日常对话和景物描写可忽略」。另外可以在阶段二之后加一个人工抽检环节，随机抽 10% 的章节核对，发现偏差就调整提示词重跑。

4.3 对白生成出现原文没有的情节

现象：生成的对白里出现了小说里根本没发生的事，模型自己「脑补」了剧情。这是最危险的一类错误，因为很难逐条核对。原因通常是提示词约束不够强，或者场景 JSON 里信息太少，模型只能自己补。解决办法有两个：一是在提示词里加「禁止添加原文未出现的情节和角色」，二是把source_plot字段一起喂给对白生成阶段，让模型有据可依。如果还是出现，就在阶段四之后加一个校验步骤，用模型对比对白和原文，标记出无来源的内容。

4.4 长章节导致上下文溢出

现象：处理某些超长章节时，模型输出被截断，或者干脆报错。原因是单章原文超过了模型的上下文窗口。解决办法是在阶段一之后加一个分块逻辑：单章超过 8000 字就按段落切成子块，分别提取要点后再合并。合并的时候要注意去重，因为相邻子块可能有重叠的剧情点。我一般用plot_points的文本相似度做去重，阈值设在 0.85 左右。

4.5 格式输出在不同平台显示不一致

现象：本地看着排版正常的剧本，发到协作平台后换行和缩进全乱了。原因是不同平台对 Markdown 的渲染规则不同，尤其是空行和全角空格的处理。解决办法是阶段五输出时统一用\n\n做段落分隔，避免用全角空格做缩进，动作提示的△后面跟一个半角空格。如果目标平台支持，直接输出纯文本加固定分隔符，比 Markdown 更稳。

5. 进阶：把五阶段工作流做成可复用的 Skill 资产

跑通一次五阶段不难，难的是让它稳定复用到不同小说上。我的做法是把每次改编的参数和提示词版本都记下来，形成一套「改编配置」。比如玄幻类和都市类的小说，阶段三的场景拆分逻辑差别很大：玄幻要处理大量战斗场景和功法描写，都市要处理日常对话和场景切换。这时候可以在 Skill 里加一个genre参数，根据类型加载不同的提示词变体。

GENRE_PROMPTS = { 'xuanhuan': 'prompts/stage3_scene_xuanhuan.md', 'dushi': 'prompts/stage3_scene_dushi.md', 'default': 'prompts/stage3_scene.md' } def get_scene_prompt(genre): return GENRE_PROMPTS.get(genre, GENRE_PROMPTS['default'])

这个模式的好处是，新类型只需要加一个提示词文件，不用改主流程。验证方法也很直接：拿同一章原文，分别用两个类型的提示词跑，对比场景拆分的粒度。玄幻类的场景应该更碎、动作描述更多，都市类的场景应该更整、对白占比更高。如果跑出来差不多，说明提示词没起到区分作用，得回去改。

另一个进阶方向是加「一致性校验」。长篇改编最大的问题是角色前后不一致，比如某个角色前面叫「林师兄」，后面变成「林哥」。可以在阶段五之后加一个全局扫描，把所有角色名提取出来做聚类，发现疑似同一角色的不同称呼就标记出来人工确认。这个校验用简单的字符串相似度就能做，不需要模型。

最后说个我自己的习惯：每次跑完一整本，我会把中间产物全部保留，尤其是阶段二的要点 JSON。因为改编需求经常变，今天要 20 集，明天可能砍到 12 集，有了要点 JSON，重新拆分场景和对白比从头跑快得多。这套工作流真正的价值不在于「全自动」，而在于把不可复用的脑力劳动变成了可复用的结构化数据。希望帮到你。

本文还有配套的精品资源，点击获取