简介这是一份面向网文作者、漫剧编剧与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 做中间产物因为结构化好校验。下面这张表是我实际用的契约字段名可以改但结构建议保留。阶段输入输出关键字段1 预处理原始小说 txt分章 JSONchapter_id, title, raw_text2 要点提取分章 JSON剧情要点 JSONchapter_id, plot_points[], characters[]3 场景拆分要点 JSON场景 JSONscene_id, location, time, action_desc4 对白生成场景 JSON剧本片段 JSONscene_id, dialogues[{role, line, emotion}]5 格式规范剧本片段 JSON漫剧剧本 md标准排版文本这张表的价值在于它让每一步都能单独测试。比如你怀疑对白生成有问题直接拿一份场景 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.jsonSKILL.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[i1].strip() if i1 len(parts) else chapters.append({ chapter_id: (i1)//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重新拆分场景和对白比从头跑快得多。这套工作流真正的价值不在于「全自动」而在于把不可复用的脑力劳动变成了可复用的结构化数据。希望帮到你。本文还有配套的精品资源点击获取