企业官网建设流程全解析

简介：面向AI漫剧与AI短剧创作者的一套Coze平台Seedance视频脚本大师工作流，以13个节点串联LLM编排与AI生图链路，覆盖剧本解析、分镜规划、角色/道具/场景编排、全局风格控制到最终脚本格式化输出，可显著压缩从文本创意到视觉成片的制作周期。压缩包共53个文件，以34个Python脚本承担核心处理逻辑，6个JSON承载各环节LLM配置与提示词模板，5个Shell脚本用于环境搭建与本地运行，另有Markdown说明、requirements依赖及Coze工程入口文件，整体仅94KB，轻量且便于部署。目前已有59人学习下载，适合希望快速搭建或二次开发AI漫剧工作流的创作者与开发者。包内包含完整的场景编排、分镜规划、角色/道具/全局风格等LLM配置示例，以及可直接执行的生成脚本和运行辅助工具，按源码、配置、文档分层组织，导入Coze Bot后即可按需调整节点与提示词，复用价值较高。

1. 从一句选题到一条漫剧：这个 Seedance 脚本工作流把最耗人力的中间层自动化了

做漫剧短视频的朋友应该都有同感：一条 60 秒的漫剧，最费时间的不是剪辑，而是「脚本 + 分镜」这一层。剧情要编、镜头要切、画面要描述、每个镜头还得配好运动轨迹，最后再跟生图模型磨角色一致性和画风，一个人一天能稳定产出两三条就算不错。这套「漫剧大师极速版」工作流，本质是把这条人力流水线搬进 Coze（扣子）：输入一个选题，13 个节点接力完成 LLM 编排剧情、分镜结构化输出、AI 生图出画面、Seedance 图生视频出动态镜头。适合两类人：一是靠漫剧账号做内容矩阵的运营，想从一条一条手写变成一次跑一批；二是刚接触 coze 工作流搭建的开发者，想看看大模型 LLM、代码节点、图像生成和视频插件是怎么串成一条真实生产线的。

2. 13 个节点怎么编排：从一句话选题到 Seedance 能直接消费的分镜包

2.1 四段式分层：为什么不能一个 LLM 节点干完全部的活

漫剧这条链路上，最忌讳的就是「凑合」——让一个 LLM 节点既写剧情又写分镜还写画面描述，看起来省事，跑两次就知道问题：输出一长，模型就开始顾此失彼，前面定的角色性格到后面就忘了，分镜数量忽多忽少，给生图的提示词也不可读。所以我搭这类工作流时的第一原则是：每个节点只干一件能被校验的事，LLM 节点之间用代码节点和条件判断节点做隔离，不让模型的输出直接流到下一个模型。

这套 13 节点工作流按职责分成五段，对应的节点明细如下：

这样分段以后，每段的失败都只影响本段，不会把「剧情写崩」和「画面生成失败」混在一起排查。后面几节把关键节点的参数和写法展开讲。

2.2 输入层：开始节点先定义好「用户能给你什么」

开始节点是工作流唯一面向使用者的口子，字段设计比想象中重要。我一般只开放四个字段：story_topic（选题，必填）、character_set（角色设定，JSON 字符串，选填）、style（画风关键词，选填）、episode_count（单次生成集数，默认 1）。选填字段都配默认值，不要强迫用户在入口填一堆东西，否则工作流在第一步就会劝退一半人。

字段类型我坚持用字符串而不是数组，原因是扣子的开始节点对数组格式的输入不友好，用户从文档里复制粘贴过来，格式经常是坏的，清洗节点还要多写一套解析逻辑。文本清洗节点只做三件事：去掉多余空白和换行、去掉 Emoji 和 URL、把全角标点转半角。代码很短，但省下来的 token 很可观，尤其是当用户从短视频文案里直接复制内容进来时：

import re def clean_input(raw: str) -> dict: text = raw.strip() text = re.sub(r"[\U0001F300-\U0001FAFF]", "", text) # 去 Emoji text = re.sub(r"https?://\S+", "", text) # 去 URL text = text.replace("\u3000", " ").replace("\n", " ") text = re.sub(r"\s+", " ", text) return {"cleaned": text, "length": len(text)}

逻辑说明：raw从开始节点传入，返回清洗后的文本和一个长度计数。length不是给用户看的，是给后面的条件判断节点用的——超过 500 字我直接走错误分支返回提示，不让超长文本进 LLM 烧 token。参数说明：Emoji 的 Unicode 区间\U0001F300-\U0001FAFF覆盖了绝大部分常用 Emoji，顺手把兼容 Emoji 也处理掉；URL 的正则只匹配http/https开头，防止误删正文里的斜杠写法。

2.3 大纲层：先出三个候选方向，再用条件判断做质量闸门

我不让 LLM 直接写分镜。第一道 LLM 节点只干一件事：根据选题产出三个候选剧情大纲。每个大纲带主线、核心冲突、爆点出现的位置、转折逻辑。这样做的理由很实际：直接写分镜时模型容易「自我感觉良好」，一个开头就铺了八百字，等发现剧情不够撑全集数已经来不及。先出大纲，运营可以在工作流之外人工挑一个，也可以直接让条件判断节点按规则自动择优。

大纲节点用扣子的大模型节点，模型选支持长上下文的，temperature设 0.7，max tokens设 2000，避免大纲阶段就把上下文窗口挤爆。提示词里明确要求只输出 JSON 数组：

你是一名漫剧编剧。根据下面选题生成 3 个候选剧情大纲。 每个大纲必须包含： - main_line：主线，50 字内 - conflict：核心冲突，30 字内 - climax_at：爆点位置，第几集第几镜 - twist：转折逻辑，80 字内 输出格式：严格 JSON 数组，不要输出任何解释文字。 [{"main_line": "...", "conflict": "...", "climax_at": "...", "twist": "..."}] 选题：{story_topic} 角色设定：{character_set}

后面接一个条件判断节点：解析返回内容，校验是否包含三个对象、每个字段是否都有值。不合格就回到 LLM 节点重试一次，重试逻辑在扣子里用「循环 + 计数变量」实现，上限两次，超时直接结束工作流并返回失败原因，避免死循环烧钱。为什么 13 个节点里要放两个校验用的条件判断节点？因为 LLM 不是确定性程序，它输出「像」JSON 不代表「是」JSON。把校验做成显式闸门，错误率就会从「偶发」变成「可控」。

2.4 分镜层：把大纲展开成数组，为后面的循环节点铺路

大纲通过校验后，第二个 LLM 节点负责把选中的大纲展开成完整分镜表。这一步的输出结构直接决定后面几个节点能不能逐个处理，所以必须规定成 JSON 数组：每个元素是一个分镜对象，包含scene_id、narration（旁白/台词）、character（出场角色）、mood（情绪）、shot_type（景别）、camera_move（运镜方式）、image_prompt（给生图模型）、video_prompt（给视频模型）。

分镜对象里同时预埋image_prompt和video_prompt两个字段，是这套工作流的关键设计：AI 生图模型和 Seedance 视频模型的提示词语法完全不同，前者吃画面元素和风格，后者吃运动轨迹和镜头语言，硬憋在一个字段里两边都不讨好。我给分镜 LLM 的指令核心是：每个分镜只表达一个镜头、一个画面、一句话剧情，不要图省事把两个镜头写进一个 scene。分镜数量控制在 8 到 12 个，超过上限会让后续生图和视频环节的耗时成倍增长，用户等不起。

3. 让 LLM 输出能被 Seedance 消费：JSON 结构、代码清洗与提示词改写

3.1 分镜对象的数据结构：人读一份、模型读一份

分镜是这套工作流里所有下游节点的数据契约，结构必须定死。我给分镜 LLM 的示例是一个具体的 JSON 对象，让它照着这个形状生成：

{ "scene_id": 1, "narration": "她推开咖啡馆的门，发现窗边坐着的人正是失踪三年的哥哥。", "character": "林晚", "mood": "震惊", "shot_type": "中景", "camera_move": "缓推", "image_prompt": "林晚，中短发，米色针织衫，推开玻璃门，室内暖光，日漫风格，背景细节丰富", "video_prompt": "镜头跟随林晚从门口走向窗边，中景缓推，背景虚化，咖啡馆暖光" }

字段说明：narration最后会给到配音或字幕环节，是给人读的台词文本；image_prompt直接进图像生成节点，video_prompt进 Seedance 视频生成节点，是给模型读的。character和mood看起来是冗余字段，实际上有大用——后面接的代码节点可以从数组里按character分组，检查同一个角色在不同分镜里的描述是否冲突，这也是排查角色一致性问题的数据基础。

3.2 工作流编码里的脏活：LLM 输出的 "JSON" 根本不是 JSON

无论提示词里怎么强调「只输出 JSON，不要解释」，LLM 节点还是偶尔给你带个 ```json 包裹、行尾逗号，甚至全角冒号。这种脏输出直接送进下一个节点必炸，所以必须有一个代码节点专门做清洗。我在第 6 号节点里放的就是这个解析函数：

import json, re def parse_llm_json(raw: str): raw = raw.strip() # 去掉 markdown 代码块包裹 raw = re.sub(r"^```json|```$", "", raw, flags=re.MULTILINE).strip() # 全角标点转半角，避免 json.loads 直接报错 raw = raw.replace("，", ",").replace("：", ":") # 去掉行尾逗号，兼容模型多打一个逗号的情况 raw = re.sub(r",\s*([}\]])", r"\1", raw) try: return json.loads(raw) except json.JSONDecodeError: # 兜底：找到第一个 [ 和最后一个 ]，截取数组部分 start, end = raw.find("["), raw.rfind("]") if start == -1 or end == -1: raise ValueError("no json array found") return json.loads(raw[start:end+1])

逻辑说明：第一步处理的是最常出现的代码块包裹；第二步是全角转半角，中文输入法下模型很容易输出中文冒号；第三步去尾逗号，正则,\s*([}\]])匹配的是「逗号后面紧跟右括号」的情况。参数说明：第三步正则看起来简单，但前提是字段值里不能出现逗号，所以我在分镜提示词里写死「描述里不要使用逗号，用顿号或空格代替」。清洗失败的节点走错误分支，把原始输出写进日志，方便判断是模型抽风还是提示词约束不到位。

3.3 视频提示词改写：Seedance 不读台词，只读镜头语言

Seedance 这类图生视频模型，对提示词的偏好跟生图模型差别很大：它可以接受一段自然语言描述，但描述里如果写「她很伤心」这种情绪词，模型不知道该让画面动哪里；写成「镜头缓慢后拉，人物低头，肩膀轻微起伏，背景雨点下落」，它就能稳定输出一个情绪镜头。所以分镜对象里的video_prompt不能在分镜生成环节一次性搞定，我在第 10 号节点单独放了一个改写 LLM：

你是视频提示词工程师。把下面的分镜描述改写成适合图生视频模型使用的提示词。 约束： 1. 只描述可见画面，不写心理活动和情绪词 2. 明确主体运动，使用动词 3. 明确相机运动：固定 / 推 / 拉 / 摇 / 移 / 跟随 4. 明确光线方向和景别 5. 不超过 80 字，不使用逗号以外的标点 输入分镜： 旁白：{narration} 画面：{image_prompt} 运镜：{camera_move}

改写前和改写后的差异非常明显。「她发现了哥哥」这种描述给到 Seedance，生成结果大概率是人物愣在原地的静态画面；改成「林晚抬头看向窗边，镜头缓推，逆光，中景」，画面就有了运动感和情绪张力。漫剧能不能出「电影感」，这一步起的作用比生图参数还大。这套流程也回答了「seedance 如何制作漫剧」这个高频问题：不是把剧情文本丢给视频模型，而是先把剧情翻译成镜头语言，再让视频模型执行。

4. 从 AI 生图到图生视频：图像节点和 Seedance 的衔接参数怎么设

4.1 图像生成节点：先锁角色一致性，再谈画质

这个工作流里的 AI 生图节点用扣子自带的图像生成模型，参数设置按漫剧的竖屏场景来：图片尺寸选 9:16 竖版，这是漫剧的主流画幅；生成数量每镜 1 张，多生成只会增加筛选成本，一致性问题和数量无关；风格强度按画风需求调节，日漫风格可以拉高一点，写实风格保持中档。图像提示词不要让人手动拼，我在第 9 号代码节点里拼装：

CHARACTER_ANCHORS = { "林晚": "林晚，中短发，米色针织衫，日常向二次元少女", "哥哥": "哥哥，深色外套，高个子，成熟轮廓，日常向二次元" } def build_image_prompt(scene: dict, style: str) -> str: anchor = CHARACTER_ANCHORS.get(scene["character"], scene["character"]) return f"{anchor}，{scene['image_prompt']}，{style}，竖构图，人物主体居中"

逻辑说明：CHARACTER_ANCHORS是每个角色的固定锚定描述，无论哪个分镜用到这个角色，生图提示词里都带同一段锚定文本，这是成本最低的一致性手段。脚本通过scene["character"]查表，查不到就用原始角色名兜底，不会报错。参数说明：style从开始节点传入，比如「日漫」「韩漫」「厚涂」「赛博朋克」，同一批分镜全部追加同样的风格后缀。锚定描述建议写满 30 字以上，太短等于没写。

4.2 图生视频节点：把运动幅度当成风险旋钮

图生视频节点接收上一节点的输出图片和改写好的video_prompt，调用的就是 Seedance 能力。这里有几个参数是我每次搭都会写进说明文档的：时长默认 5 秒，选更长的时间出片耗时和费用都成倍增加，漫剧单镜头 5 秒已经够用；运动幅度第一版不要拉满，控制在中等档位，幅度拉大伴随的是崩脸和形变概率直线上升，翻车率极高；镜头运动参数要和video_prompt里写的保持一致，如果不一致，节点以参数面板为准，提示词只起补充作用。

这里有一个很多人忽略的点：图生视频不是拿「任意一张图」都能生成好结果。图片本身要留出运动余量——主体不能顶满画框，背后要有可交代的环境信息。所以在第 9 号图片后处理节点里，我除了校验尺寸和格式，还会检查图片主体占比：主体占比超过 80% 的图直接退回生图节点重新生成，并追加「画面上下留白，主体居中偏上」的约束。这个校验用图片的透明通道信息近似估算，不需要接复杂的视觉模型。

4.3 循环与批处理：13 个节点里最容易被忽略的节流点

分镜是数组，所以第 7 号循环节点包住图像生成、图片后处理、视频生成这三个节点，逐个分镜处理。循环的好处是每个分镜独立失败、独立重试，不会像「一次生成全部分镜图片」那样一个失败全盘重来。但有三个细节直接决定工作流能不能跑完：第一，循环内节点越少越好，视频提示词改写这类轻量 LLM 调用不依赖图片，放在循环外一次性处理完再进循环；第二，循环的并发数设 1，不要试图并行调多个高耗时节点，扣子对并发请求有限流，并行反而容易触发限流把整条工作流拖死；第三，每个分镜的视频生成节点单独配重试，重试上限 2 次，超过就跳过当前分镜继续，最后在第 12 号结果校验节点汇总失败列表，而不是让一个失败分镜卡住后面所有分镜。

提示：循环节点里所有节点的超时时间统一设置，不要用默认值。视频生成节点耗时最长，超时设 120 秒，图像生成设 60 秒，其他设 30 秒，超时即重试，避免单节点无限挂起。

5. 实战避坑：Coze 工作流最容易翻车的 5 个环节

5.1 LLM 返回的 JSON 永远比想象的脏

现象：工作流跑到清洗节点直接报ValueError: no json array found，打开日志看原始输出，明明是一段长得像 JSON 的文本，就是解析不过。原因：模型在数组前面插了一句「好的，这是你的分镜：」，或者用了中文逗号、行尾多了一个逗号、字段名带了双引号转义。解决：清洗函数做四步处理之后，再加一道兜底截取逻辑；但更重要的一步在提示词侧——明确写「只输出 JSON 数组，首尾不要任何解释文字」，同时把「描述里不使用逗号」写进字段约束。我见过最多的情况不是模型不会输出，而是提示词里根本没强调这件事。

5.2 角色一致性玄学：换个景别就变脸

现象：同一角色在第 1 镜和第 5 镜生成的图不像同一个人，发型、衣服、脸型对不上。原因：生图节点没有固定种子，且角色锚定描述太短，或者锚定词放在提示词最后被模型忽略了。解决：三管齐下。第一，图像生成节点固定seed值，同一个分镜重试多次不会换人；第二，锚定描述写到 30 字以上，放到提示词最前面，并用「，」（中文逗号）和画面描述隔开；第三，有条件的话给每个角色配置一张参考图，扣子图像生成节点支持参考图输入，参考图的一致性效果比任何文字锚定都稳定。

5.3 Seedance 输出被裁切，字幕没地方放

现象：生成出来的视频里人物主体被切掉一半，或者后期加字幕时发现字幕区域正好压在人物脸上。原因：生图阶段主体顶满画框，没有预留安全区，图生视频时镜头一动，主体就出画了。解决：在image_prompt里统一追加「上下留白，主体居中偏上」约束；视频比例固定 9:16；后期字幕放在画面底部 20% 的区域，这个位置在生图时就要避免放重要内容。这个坑属于典型的「生图时没想视频的事」，等到了视频阶段才发现构图错了，只能回头重新生图，一镜返工等于整条链路重跑一遍。

5.4 多集漫剧上下文超长导致大纲缩水

现象：设置生成 3 集，结果第一集分镜写得很细，第二集开始分镜数量明显变少，第三集直接缩成一个模糊的收尾。原因：分镜生成节点的max tokens设置太小，上下文窗口被前面的内容占满，模型只能压缩后面集数的内容。解决：把「多集展开」的逻辑拆分——大纲节点只输出每集的核心冲突和爆点，然后按集数循环调用分镜生成节点，每一集只带自己那一集的大纲进上下文，不让上一集的分镜污染下一集。这个方案牺牲了一点节点数，换来了输出质量的稳定性。13 节点里有 3 个 LLM 节点，每一个都在干不同的事，这就是原因。

5.5 循环节点把整条工作流拖死

现象：10 个分镜，跑到第 3 个就超时，整个工作流失败，前面生成的成果全部丢失。原因：循环里串了三个高耗时节点，且没有配重试上限，一个节点卡住，后面的分镜全部排队等死。解决：循环内只留图像生成和视频生成，视频提示词改写挪到循环外；视频生成节点加重试策略，重试 2 次后跳过当前分镜继续；第 12 号结果校验节点收集失败的scene_id，最后统一返回「成功 8 镜、失败 2 镜，失败镜为第 3、7 镜」。宁可让用户看到不完整的成果，也别让用户等十分钟等来一个整体失败。

6. 把这套 13 节点方案升级成量产底座：三个立刻能用的验证技巧

先解决一个刚跑通时最容易忽略的问题：怎么判断这次跑出来的结果比上次好？我习惯在结束节点前加一个「LLM 裁判」分支，把生成的分镜 JSON 数组丢给一个只打分不生成内容的 LLM 节点，按四个维度打分：剧情爆点密度、分镜衔接流畅度、角色一致性描述、video_prompt 的镜头语言完整性。分数低于阈值的工作流自动回到大纲节点重新生成一轮，实现类似「LLM as Judge」的质量闭环。

第二个技巧是固定种子做回归测试。同一个选题、同一份参数，每周跑一次，如果两次生成的画面差异过大，说明种子没有被正确传递，检查图像生成节点是否勾选了「固定随机种子」。漫剧是连续剧，用户对角色外观的记忆跨集存在，种子不稳定会直接毁掉续集观感。

第三个技巧是把风格从「写死在节点里」提升为工作流入参。刚开始我把「日漫」直接拼在图像提示词后缀里，后来发现想试「韩漫」风格要改节点，麻烦。现在style字段从开始节点传入，生图提示词和视频提示词的改写模板里都引用这个变量，一套工作流给无数种画风用，这才是「极速版」该有的样子。

我自己的教训是：最早一版把所有逻辑塞进一个 LLM 节点，跑通之后一换选题就翻车，后来拆成大纲、分镜、视频提示词三个独立节点，错误率降了一个数量级。工作流搭建的价值从来不在于节点多，而在于每一层都能单独验证、单独重试。希望这套拆解能帮你少踩几个坑，把漫剧量产这件事真正跑起来。

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