企业官网建设流程全解析

简介：这份资源是面向网文作者、动漫编剧与AI创作爱好者的Claude Code Skill工具包，用于将长篇网络小说自动化改编为标准漫剧剧本，解决人工改编周期长、风格易走样的问题。压缩包共21个文件，约47KB，以14个md文档为核心，涵盖技能说明、设计规范、人物设定、大纲与质检报告等模块，另含txt示例文本、json项目配置、sh安装脚本及license等辅助文件，结构清晰便于直接调用。目前已有102人学习下载。其价值在于内置五阶段全自动工作流：从立项问答确立需求，到世界观与人物规划、逐章剧本创作，再到自检与定向返修，并采用三层记忆维护机制保障情节、角色与设定的一致性。读者可据此快速搭建可复用的改编流水线，获得从小说文本到漫剧剧本的完整落地思路与可执行脚本。

1. 网文改编漫剧剧本：为什么五阶段工作流比一把梭更靠谱

手里有一本三百万字的网络小说，想改成漫剧剧本，最直接的做法是把原文丢给模型让它「帮我改成剧本」。我试过，前两集还能看，到第五集人物关系就开始漂移，第十集主角名字都能换一个。问题不在模型笨，而在于改编这件事本身是多目标约束的：既要保留原著爽点，又要符合漫剧的单集时长节奏，还要让分镜描述可被画师直接执行。一个 prompt 同时扛这三件事，必然顾此失彼。

Claude Code Skill 的价值就在这里。Skill 不是简单的提示词模板，它是 Claude Code 里一种可复用的能力封装——把一套固定的处理逻辑、文件读写规则、阶段间校验写成结构化的指令集，让模型按阶段执行而不是一次性生成。把「网文改编漫剧剧本」拆成五个阶段做成 Skill，本质上是把一个大而模糊的创作任务，拆成五个各自有明确输入输出和验收标准的小任务。这篇要讲的就是这套五阶段工作流怎么搭、每个阶段的 Skill 怎么写、参数怎么调、哪里最容易翻车。适合手里有网文 IP 想做漫剧改编的编剧、制片，也适合想用 Claude Code 做内容生产工作流的工程师。

2. 五阶段工作流拆解：从原文到可拍剧本的链路设计

2.1 为什么是五个阶段而不是三个

漫剧剧本和传统影视剧本最大的区别在于单集时长短、节奏密度高。一集漫剧通常 2 到 5 分钟，意味着每集必须有一个完整的情绪起伏，不能像长剧那样慢慢铺。这就要求改编时先做全局的结构规划，再落到单集，最后才写具体台词和分镜。

三个阶段（拆解→改编→输出）的问题是：拆解阶段如果只输出章节梗概，改编阶段拿到的是压缩过的信息，原著里的细节和伏笔全丢了；如果拆解阶段输出全文，那和没拆一样。五个阶段的划分解决的是信息粒度的逐级收敛：

这个划分的关键在于：阶段二和阶段三之间有一次「回看原文」的动作。分集大纲确定后，生成单集剧本时需要把对应章节的原文片段重新喂给模型，而不是只靠大纲。这是保证细节不丢失的核心设计。

2.2 Skill 的目录结构和文件约定

Claude Code Skill 的常见组织方式是一个目录加一个入口文件。我一般会这样组织：

manju-skill/ ├── SKILL.md # 主入口，定义工作流和阶段调度 ├── stages/ │ ├── 01_parse.md # 阶段一：原文解析指令 │ ├── 02_structure.md # 阶段二：结构规划指令 │ ├── 03_script.md # 阶段三：单集剧本生成指令 │ ├── 04_format.md # 阶段四：格式标准化指令 │ └── 05_verify.md # 阶段五：一致性校验指令 ├── templates/ │ ├── outline.md # 故事大纲模板 │ ├── episode.md # 分集大纲模板 │ └── script.md # 剧本格式模板 └── config.json # 参数配置

SKILL.md 是调度中心，它不负责具体生成，而是定义「什么时候调用哪个阶段、阶段之间怎么传递数据、什么条件下回退重做」。每个 stages 下的文件是独立的指令集，可以单独调试。

提示：不要把五个阶段的指令全塞进一个 SKILL.md。分开写的好处是单阶段可以独立跑、独立调参，出问题时能快速定位是哪个阶段的问题。

2.3 阶段间的数据传递格式

阶段之间传什么格式，直接决定了工作流能不能跑通。我的经验是统一用 Markdown 加 YAML frontmatter，因为 Claude Code 对 Markdown 的解析最稳定，YAML 又能承载结构化字段。

故事大纲的输出格式示例：

--- stage: outline source_chapters: 1-120 character_count: 8 main_plot_lines: 3 --- ## 主要人物 - name: 林远 role: 主角 arc: 从落魄少年到宗门首席 first_appear: 第1章 - name: 苏瑶 role: 女主 arc: 从敌对到并肩 first_appear: 第3章 ## 主线 ### 线1：宗门崛起 - 关键节点：第1章入门、第15章初赛、第40章夺魁 - 情绪曲线：压抑→小胜→挫折→爆发 ## 关键场景清单 - id: S001 chapter: 1 summary: 林远被逐出家族 emotion: 屈辱 reusable: true

这个格式的好处是：阶段二读main_plot_lines和关键场景清单来切分集，阶段五读first_appear和关键节点来做一致性校验。字段名固定后，每个阶段的指令只需要关注自己读哪些字段、写哪些字段。

3. 阶段一二的 Skill 写法：原文解析和结构规划怎么落地

3.1 原文解析阶段：分块读取与信息抽取

网文动辄几百万字，不可能一次性塞进上下文。常见做法是按章节分块，逐块抽取，最后合并。这里有个坑：如果每块独立抽取人物，同一个人在不同块里可能被写成不同名字（比如「林远」和「林师兄」）。解决办法是在抽取指令里要求模型输出别名列表，合并阶段再做归一化。

阶段一的 Skill 指令核心片段：

# 阶段一：原文解析 ## 输入 - 小说原文文件路径（支持 txt / md） - 分块大小（默认按章节，每块不超过 3000 字） ## 执行逻辑 1. 读取原文，按章节标题或空行切分 2. 对每个块执行以下抽取： - 人物：姓名、别名、首次出现章节、身份 - 场景：地点、涉及人物、事件摘要、情绪标签 - 伏笔：埋设章节、内容、预期回收章节（如有） 3. 合并所有块的抽取结果： - 人物按别名归并，保留出现次数最多的名字为主名 - 场景按章节顺序排列，去重 - 伏笔单独成表 ## 输出 - 写入 `output/outline.md`，格式见 templates/outline.md - 同时在终端输出统计：人物数、场景数、伏笔数

对应的配置参数：

{ "chunk_size": 3000, "chunk_by": "chapter", "extract_fields": ["character", "scene", "foreshadow"], "merge_strategy": "alias_normalize", "output_format": "markdown_yaml" }

chunk_size设 3000 字是个经验值。太小会导致块数过多、合并开销大；太大则单块信息密度高，模型容易漏抽。chunk_by优先按章节，因为章节本身就是作者划分的语义单元。如果原文没有明确章节标记，退化为按空行切分，每 3000 字一块。

3.2 结构规划阶段：漫剧节奏怎么切集

拿到故事大纲后，阶段二要做的核心决策是切多少集、每集切在哪里。漫剧的切集逻辑和小说章节不一样：小说一章可能 3000 字只讲一个场景，漫剧一集需要 2 到 3 个场景形成一个小高潮。

我一般用「情绪节点法」来切：先在大纲里标出所有情绪高点（打脸、反转、告白、决战），然后以情绪高点为锚，往前推 2 到 3 个场景作为一集的铺垫，情绪高点落在集尾做钩子。

阶段二的 Skill 指令：

# 阶段二：漫剧结构规划 ## 输入 - `output/outline.md`（阶段一输出） - 目标集数（可选，默认根据情绪节点数自动计算） - 单集时长（默认 3 分钟） ## 执行逻辑 1. 从大纲中提取所有情绪高点，按章节顺序排列 2. 计算建议集数： - 情绪高点数 / 每集高点数（默认 1）= 基础集数 - 如果基础集数 < 12，按 12 集规划（漫剧最短季） - 如果基础集数 > 60，按 60 集上限合并相邻低强度节点 3. 为每集分配： - 集号、标题、对应原文章节范围 - 核心事件（1 个）、辅助事件（1-2 个） - 集尾钩子（必须是一个未解决的悬念或情绪高点） - 预计场景数（2-3 个） 4. 输出分集大纲 ## 输出 - 写入 `output/episodes.md` - 每集格式见 templates/episode.md

这里的关键参数是每集高点数。设 1 意味着每集一个情绪高点，节奏最紧凑，适合爽文改编。设 2 适合偏日常或感情线的作品，节奏舒缓一些。我一般先按 1 跑一版，看总集数是否合理，再调整。

注意：阶段二输出的分集大纲必须包含「对应原文章节范围」这个字段。阶段三生成单集剧本时要靠这个字段回查原文，没有它细节就丢了。

3.3 阶段三：单集剧本生成的回查机制

阶段三是整个工作流里最耗 token 的一步，因为每集都要回查原文。我的做法是只回查该集对应的章节范围，且只取场景相关的段落，而不是把整个章节范围全塞进去。

具体逻辑：阶段二的分集大纲里每集标了章节范围，阶段三先读这个范围，再从原文里抽取包含该集核心事件和辅助事件的段落。抽取方式可以用关键词匹配（人物名+事件关键词），也可以用模型做一次轻量筛选。

# 阶段三：单集剧本生成 ## 输入 - `output/episodes.md` 中指定集号的分集大纲 - 原文文件中对应章节范围的内容 - `templates/script.md` 格式模板 ## 执行逻辑 1. 读取指定集的分集大纲，提取核心事件、辅助事件、集尾钩子 2. 从原文对应章节中抽取相关段落： - 匹配人物名 + 事件关键词 - 每段不超过 500 字，总抽取量不超过 4000 字 3. 按漫剧剧本格式生成： - 场景头：地点、时间、内/外景 - 动作描述：简洁，可被画师执行 - 对白：保留原著关键台词，口语化调整 - 转场：标注转场方式 4. 确保集尾落在钩子上 ## 输出 - 写入 `output/scripts/ep{集号}.md`

单集剧本的格式模板：

## 第X集：集标题 ### 场景1 **地点**：宗门演武场 **时间**：日 **内/外**：外 **动作**：林远握剑而立，对面是比他高出一头的师兄。 **对白**： 林远：「这一剑，我等了三年。」 师兄：「就凭你？」 **转场**：剑光闪过，切黑。

这个格式的好处是画师拿到就能画，不需要再猜「这句话是谁说的、在什么场景」。动作字段要求简洁，是因为漫剧分镜对动作的描述越具体越好执行，写「林远很生气」画师没法画，写「林远握剑的手在发抖」就能画。

4. 阶段四五的 Skill 写法：格式标准化与一致性校验

4.1 格式标准化：把初稿变成可交付剧本

阶段三生成的剧本初稿，格式可能不完全统一——有的场景写了时间，有的没写；有的对白用了直角引号，有的用了弯引号。阶段四做的就是格式归一化，把初稿变成符合交付标准的剧本。

这一步看起来简单，但如果不做，后面阶段五的一致性校验会很难写，因为校验逻辑要处理各种格式变体。先归一化再校验，校验规则可以写得很干净。

阶段四的 Skill 指令核心：

# 阶段四：格式标准化 ## 输入 - `output/scripts/` 下所有单集剧本 ## 执行逻辑 1. 遍历每个剧本文件 2. 对每个场景执行格式检查： - 场景头必须包含：地点、时间、内/外 - 对白必须用「」包裹 - 动作描述不超过 50 字 - 转场必须标注方式 3. 不符合的自动修正： - 缺失字段从上下文推断补全 - 引号统一为「」 - 过长动作描述拆分或精简 4. 输出标准化后的剧本 ## 输出 - 覆盖写入 `output/scripts/` - 生成 `output/format_report.md` 记录修正项

动作描述不超过 50 字这个限制是硬性的。漫剧分镜一格的信息量有限，动作描述太长画师会漏掉关键信息。如果初稿里出现大段动作描写，阶段四会把它拆成多个短动作，或者精简到核心动作。

4.2 一致性校验：跨集人物和时间线的自动检查

阶段五是整个工作流的「后悔药」。前四个阶段各自独立跑，难免出现跨集不一致：第三集说林远是左撇子，第八集他右手使剑；第五集是冬天，第七集突然出现荷花。

校验逻辑分三类：

人物一致性：从阶段一的大纲里读人物属性（姓名、别名、身份、首次出现章节），然后遍历所有剧本，检查每个人物的出现是否符合大纲设定。比如大纲说苏瑶第 3 章才出现，剧本第 1 集就有她的对白，就是问题。

时间线一致性：从剧本的场景头里提取时间标记（日/夜、季节、相对时间），按集号排序，检查是否有倒流或矛盾。

伏笔回收：从阶段一的大纲里读伏笔表，检查每个伏笔是否在预期章节范围内被回收。未回收的伏笔在报告里标红。

# 阶段五：一致性校验 ## 输入 - `output/outline.md`（人物、伏笔数据） - `output/scripts/` 下所有标准化剧本 ## 执行逻辑 1. 人物校验： - 遍历每个剧本，提取所有出场人物 - 对比大纲中的人物首次出现章节 - 标记「提前出场」「未出场」「名字不一致」 2. 时间线校验： - 提取每个场景的时间标记 - 按集号排序，检查时间是否单调递增 - 标记「时间倒流」「季节矛盾」 3. 伏笔校验： - 遍历伏笔表，检查每个伏笔的回收章节 - 标记「未回收」「回收章节偏差超过 5 集」 4. 生成校验报告 ## 输出 - `output/verify_report.md` - 如有严重问题，输出修正建议

校验报告的结构：

## 校验报告 ### 人物问题 - [严重] 苏瑶在第1集出现，但大纲设定首次出现为第3章 - 位置：ep01.md 场景2 - 建议：删除该对白或调整为大纲设定 ### 时间线问题 - [警告] 第5集为冬季，第7集出现荷花（夏季） - 位置：ep07.md 场景1 - 建议：修改场景描述或调整季节设定 ### 伏笔问题 - [提示] 伏笔「玉佩来历」预期第20集回收，当前未回收 - 建议：在第20-25集之间补充回收场景

提示：校验报告里的严重程度分级很重要。「严重」必须改，「警告」建议改，「提示」可以留到下一轮迭代。不要所有问题都标严重，否则改不过来。

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

5.1 阶段一人物抽取漏人

现象：大纲里人物数明显少于原文实际出场人物，配角大量丢失。

原因：分块抽取时，如果某个人物只在某个块里出现一次且没有明显标签（比如「店小二」这种临时角色），模型容易忽略。另外chunk_size设太大时，单块信息密度高，模型注意力分散。

解决：把chunk_size降到 2000 字，并在抽取指令里加一条「即使只出现一次的角色也要记录，标注为临时角色」。合并阶段再做一次去重，临时角色如果只出现一次可以保留但标记。

5.2 阶段二切集后单集内容过少

现象：按情绪节点切集后，某些集只有一两个场景，撑不满 3 分钟。

原因：情绪高点分布不均匀，有的章节密集出现多个高点，有的章节几十章都没有明显高点。按高点切集会导致集与集之间内容量差异大。

解决：在阶段二的切集逻辑里加一个「最小场景数」约束。如果某集场景数少于 2，从相邻集借一个场景过来，或者把该集和相邻集合并。我一般设min_scenes_per_episode: 2，低于这个值就触发合并。

5.3 阶段三回查原文时 token 超限

现象：生成到中后期集数时，报上下文超长错误。

原因：阶段三回查原文时，如果章节范围大且抽取逻辑不精确，可能把大量无关段落也塞进去了。另外如果工作流没有做阶段间的上下文清理，前面阶段的输出会一直累积。

解决：两个措施。一是抽取逻辑加硬上限，max_extract_chars: 4000，超过就截断。二是每个阶段独立运行，阶段三不读阶段一二的完整输出，只读分集大纲里该集需要的字段。Claude Code 里可以用/clear清理上下文，或者把每个阶段写成独立命令分别执行。

5.4 阶段四格式修正过度

现象：标准化后剧本变得千篇一律，原本有特色的动作描述被精简得没有画面感。

原因：格式修正规则太激进，比如「动作描述不超过 50 字」被严格执行，把「林远缓缓抬起右手，指尖凝聚出一团青色光芒，光芒中隐约可见符文流转」这种有画面感的描述砍成了「林远抬手，光芒凝聚」。

解决：把硬性限制改成软性建议。动作描述不超过 50 字改为动作描述建议不超过 50 字，超过时优先保留视觉细节，删减心理描写。另外在阶段四加一个「保留原文特色表达」的白名单，白名单里的描述不参与精简。

5.5 阶段五校验报告误报太多

现象：校验报告里几十条问题，大部分是误报，比如把「林远」和「林师兄」当成两个人。

原因：阶段一的人物别名归并没有做好，或者阶段五的人物匹配逻辑太严格，只做精确匹配。

解决：阶段五的人物匹配用「主名+别名列表」做模糊匹配。阶段一输出的人物数据里，每个主名带一个aliases数组，阶段五匹配时先查主名，查不到再遍历别名列表。另外校验报告加一个「置信度」字段，精确匹配的问题标高置信度，模糊匹配的标低置信度，低置信度的默认折叠不显示。

6. 进阶：把五阶段工作流做成可迭代的 Skill 体系

跑通五阶段只是起点。真正让这套工作流产生复利的是把每次改编的反馈沉淀回 Skill。我的做法是在阶段五之后加一个「反馈收集」环节，不写进主流程，但每次跑完手动记录三类信息：哪些校验问题是误报、哪些格式修正被人工改回去了、哪些集数的钩子效果不好。这些记录积累到一定量后，反过来修改对应阶段的指令和参数。

比如我发现阶段二的「每集高点数」设 1 对某些作品太紧凑，就在 config.json 里加了一个genre_preset字段：

{ "genre_preset": { "爽文": { "emotion_peaks_per_episode": 1, "min_scenes": 2 }, "言情": { "emotion_peaks_per_episode": 2, "min_scenes": 3 }, "悬疑": { "emotion_peaks_per_episode": 1, "min_scenes": 2, "hook_required": true } } }

阶段二读这个字段自动调整切集策略，不用每次手动改参数。这就是 Skill 相比一次性 prompt 的优势：参数和逻辑分离，改参数不用改指令。

另一个进阶方向是阶段三的并行化。单集剧本生成各集之间没有依赖，理论上可以并行跑。Claude Code 里可以用多个终端窗口分别执行不同集号的生成命令，最后统一跑阶段四和阶段五。我试过 12 集的量，串行跑大约 40 分钟，并行跑 4 个窗口能压到 15 分钟左右。代价是并行时上下文管理更麻烦，每个窗口要独立加载分集大纲和原文片段，内存占用高。

最后一个技巧是关于校验的增量执行。阶段五不必每次全量跑，可以只校验本次修改涉及的集数。在剧本文件里加一个last_modified字段，阶段五读这个字段，只校验最近修改过的文件及其相邻集（因为跨集问题往往涉及相邻集）。全量校验留到最终交付前跑一次。

我自己跑这套工作流最大的教训是：不要在第一遍就追求完美。第一遍跑完拿到校验报告，先改「严重」级别的问题，跑第二遍，再看「警告」。我见过有人第一遍就想把所有问题改完，结果改到一半上下文乱了，反而引入新问题。分轮迭代，每轮只解决一类问题，比一把梭靠谱得多。希望帮到你。

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