企业官网建设流程全解析

上个月我们内部跑完了一条 30 集的 AI 短剧，从拿到剧本到输出第一版成片，总耗时从早期人工操作的 7 天压到了 18 小时。这中间最大的变化不是某个单点工具变强了，而是我们把整个流程重新“编排”了一遍：从最开始的画布 Agent 做分镜和角色锁定，到后面用 API 把剧本、分镜、生成、配音、字幕、审核全部串成一条可监控、可重试、可持续优化的流水线。这套东西我们内部叫羽山数智方案，今天把它完整复盘一遍，该说的细节都摊开讲，能帮想自己做 AI 短剧工业化的人少踩几个坑。

这篇文章适合什么人看：想批量生产 AI 短剧的团队、已经在用 AI 工具但觉得“单条视频能做、一批跑不动”的内容负责人、以及做 Agent 或 API 编排的技术同学。我尽量不空谈概念，多放实际配置、真实参数、踩坑记录，你可以直接拿这套思路去搭自己的流水线。

1. 项目缘起：为什么 AI 短剧需要“工业化流水线”

1.1 从“单点效率”到“系统效率”的转变

先说一个很多人都有的误区。早期我们做 AI 短剧，用的是“手工串联”的方式：先用对话式 AI 写剧本，把剧本复制到分镜工具里调图，再拿着分镜图去视频生成平台逐条生成，最后用剪辑软件手动拼。单条 1 分钟的视频，这么操作大约需要 3 到 4 个小时。听起来还能接受对吧？但放到 30 集、每集 10 到 20 个镜头的短剧里，这个数字就变成 100 到 200 个小时。更可怕的是，中间任何一次角色面容漂移、提示词写错、生成平台排队超时，都得从头来一段。

我们最终意识到，问题不在于某个 AI 工具不够聪明，而在于整个流程是“人肉串联”的。人一旦成为流水线里的传输带，效率上限就是人的手速和耐心。所以羽山数智方案的第一性原理是：把所有能标准化的环节全部标准化，把创意判断保留给人，把重复劳动全部交给自动化和 API 编排。

1.2 羽山数智方案要解决的三组矛盾

这套方案从设计之初就不是冲着“做一个更好用的 AI 画图工具”去的，而是奔着解决三组核心矛盾：

第一组矛盾是质量与速度。AI 生成有随机性，同一个提示词每次出来的结果都不一样。如果追求质量就要反复采样，速度必然慢；如果追求速度直接跑一遍，画质和一致性又没法看。工业化流水线不能靠赌运气，所以我们在关键节点引入了“批量预生成 + 质量打分筛选”的机制，让速度快和结果稳同时成立。

第二组矛盾是标准化与创意表达。短剧的题材千差万别，但镜头语言、叙事节奏、角色一致性这些底层逻辑是共通的。我们把剧本结构、分镜模板、提示词模板做成可复用资产，创意工作者只需要在模板上做选择题，而不是每次从零开始描述一切。

第三组矛盾是成本与控制。大模型 API 按 token 计费，视频生成按条计费，跑一条流水线动辄消耗大量资源。如果没有配额管理、缓存机制、失败重试策略，成本会像漏水的水管一样止不住。羽山数智方案把成本控制做进了编排逻辑里，而不是事后看账单再拍大腿。

这三组矛盾，决定了我们后面的每一步技术选型。你可以理解成：我们不是在搭一个工具，而是在建一座“内容工厂”，所有模块都要为连续生产服务。

2. 整体架构设计：画布 Agent 与 API 编排如何分工

2.1 五层架构总览

羽山数智方案整体分五层，从下往上分别是：模型接入层、画布 Agent 层、流程编排层、业务应用层、监控审计层。这套分层不是一开始就定好的，是在迭代中慢慢长出来的，但事后看每一层都缺一不可。

模型接入层负责统一对接各家大模型和视频生成服务，屏蔽底层 API 差异。我们接入了多种模型，包括对话模型、图像模型、视频模型、语音合成模型，通过统一的“模型网关”暴露标准接口。画布 Agent 层是整个方案最有特色的部分，它不是一个聊天机器人，而是一个“可操作的可视化工作台”：每个镜头、每个角色、每个场景都在画布上有对应的实体卡片，Agent 可以读取、修改、关联这些卡片，也可以调用底层模型执行生成任务。

流程编排层负责把所有节点串成 DAG，也就是有向无环图。剧本完成后自动触发分镜生成，分镜通过质量校验后自动触发视频生成，视频生成完成后自动触发配音和字幕，每一部都有关卡检查，不通过就走重试或者人工介入分支。业务应用层是我们的运营后台，能看到每部剧的进度、每条任务的耗时、每个环节的成本。监控审计层则记录所有调用日志和生成结果，便于定位问题，也满足内容追溯要求。

2.2 为什么不能用“一个 Agent 包打天下”

很多团队一开始会问：为什么不做一个超级 Agent，让它从头到尾自己把短剧生成完？我们的答案很直接：当前的大模型能力还撑不起这种全流程自主决策，硬要做的结果是每个环节都只有七十分，而且出了问题你不知道该改哪一环。

举一个具体的例子。让一个 Agent 同时负责“写剧本”和“画分镜”，很容易出现剧本写得很嗨但画面根本无法实现的情况。因为文字创作的想象空间和视觉生成的物理规则完全是两套逻辑，一个模型很难同时把两者约束好。我们把职责拆开：剧本 Agent 只负责叙事结构和台词质量，分镜 Agent 只负责把剧本转换成可执行的镜头描述和画面风格。它们之间通过结构化的“分镜脚本”通信，而不是靠自然语言互相扯皮。

另外一个原因是可调试性。流水线一定会出错，出错的时候你要能精准定位是“剧本阶段提示词写法有问题”还是“分镜阶段角色参考图没传对”。如果只有一个大 Agent，问题状态全混在上下文里，排查成本高到离谱。拆成独立 Agent + 明确的输入输出之后，每一段的调试范围都变小了，这对工业化生产来说是性命攸关的特性。

2.3 画布 Agent 的定位：把创意变成“可执行资产”

“画布 Agent”这个名字，我们内部讨论过很久。它不是传统意义上的聊天窗口，而是一个可视化的“内容状态空间”。早期我们用对话式 Agent 做分镜，效果很不好，因为分镜需要不断回看、对比、微调，纯对话的上下文窗口根本扛不住 30 集的信息量。

后来我们借鉴了设计工具的思路，做了一个画布界面：左侧是可拖拽的素材库，包括角色设定图、场景氛围图、道具参考图；中间是镜头时间轴，每个镜头是一张卡片，卡片上标注了景别、运镜、角色关系、提示词、生成状态；右侧是 Agent 的交互面板，你可以选中任意镜头让 Agent 帮你重写提示词，或者对选定的一段连续镜头做统一风格调整。

这套设计的精髓在于：画布上的每一个实体都有唯一 ID，Agent 操作的不是“抽象的对话历史”，而是“具体的资源状态”。比如你改了一个角色的发型设定，后续所有引用这个角色的镜头卡片都会自动标出“需要重新校验一致性”，Agent 可以据此批量触发重新生成，而不是让你手动去翻每一个镜头。这就是把创意过程变成了可执行资产：人可以随时介入干预，机器可以随时接管执行。

3. 核心环节拆解：从剧本到成片的 8 个关键节点

3.1 剧本 Agent：结构化指令的力量

我们在剧本 Agent 上踩过最大的坑，是让它“自由发挥”。早期我们只给 Agent 一句话“写一个古装复仇短剧第一集”，出来的剧本五花八门，有的第一集就把大 boss 写死了，有的压根没给主角设置困境，根本不适合短剧的快节奏逻辑。

后来我们把剧本结构强模板化。每一集拆成“开场钩子—冲突升级—反转时刻—悬念结尾”四段式，每一段都限定字数区间和必须出现的情节要素。剧本 Agent 要做的不是从零创造，而是在模板约束下填充高质量内容，同时输出结构化字段：角色列表、场景列表、每场戏的冲突目标、反转点位置。这些字段会作为后续分镜 Agent 的输入，非常重要的点是角色列表里必须包含稳定的角色外貌描述，这是后面保持视觉一致性的根基。

关于提示词，我们总结了一个实用的写法模板，就是在系统提示词里写明：你需要生成符合短剧节奏的剧本，每集剧情需要包含不少于两次冲突、一次反转，结尾必须留有悬念。同时把“角色外貌描述”和“场景描述”作为 JSON 字段单独输出，避免全部混在正文里。这样做的好处是，后续 Agent 可以精准读取字段，而不需要从大段文本里用自然语言再提取一遍。

3.2 分镜画布 Agent：视觉一致性从哪来

视觉一致性是 AI 短剧工业化里最容易被低估的难题。单看每个镜头都觉得不错，连起来看就成了“整容剧”，主角的脸每 10 秒换一张脸。这类问题光靠提示词写“同一个角色”是解决不了的，必须靠参考图和角色绑定。

我们在画布 Agent 里做了“角色资产库”。每个主要角色会先经过一轮“定妆生成”，从多个候选形象里人工挑出一张最满意的，锁定为角色参考图。之后所有涉及该角色的镜头，画布 Agent 在生成提示词时都会自动附带这张参考图，并明确标注“保持该角色的面部特征、发型、服装风格一致”。

场景一致性用的是另一套思路，叫场景锚点。每个核心场景先做一张氛围定调图，后续镜头在描述光线和色调时，都以这张锚点图为基础做微调。实际操作中我们发现，角色一致性靠参考图能解决八成问题，剩下两成要靠视频生成模型的参数设置，比如把运动幅度调小、把引导强度控制在合理范围，减少动态过程中的畸变。

3.3 生成调度层：并发、队列与失败重试

流水线跑起来以后，真正决定效率的不是模型多强，而是调度层做得好不好。我们早期是“线性跑”，一个镜头生成完再生成下一个，30 集的短剧要跑两三天，完全不能接受。后来我们用异步任务队列把生成过程并发化：允许同时跑 8 到 12 个视频生成任务，每个任务独立上报状态。

并发带来了新问题：生成平台有速率限制，并发一高就开始报 429，也就是请求过于频繁；有些任务会因为网络抖动或者服务端超时而失败。我们编排层做了三件事：第一是令牌桶限流，把请求速率控制在平台允许范围以内；第二是自动重试机制，对于瞬时错误最多重试 3 次，每次退避时间递增；第三是失败隔离，单个任务的失败不会影响整条流水线，它会被丢进“补救队列”，等条件允许时再补跑。

这里要特别提醒一件事：重试不是万能的。如果是提示词本身有问题导致生成结果不符合预期，重试一百次也没用，只会白白烧钱。所以我们在重试逻辑里加了“失败类型分类”：网络错误和限流错误可以重试，内容审核拒绝和参数校验错误直接进人工处理队列，绝不自动重放。

3.4 内容安全与质量闸门：工业化必须有的“质检线”

工业化生产最怕什么？批量产出违规内容。我们内部有一条铁律：所有生成内容必须经过多层审核才能进入素材库。第一层是机审，用内容审核 API 对文本、图像、视频帧分别做安全检测，打回疑似违规内容；第二层是规则校验，检查字幕是否完整、音频是否对齐、分辨率是否达标；第三层是人工抽检，每部剧至少抽 20% 的镜头做人工复核。

质量闸门同样重要。我们对每个生成镜头计算“质量分”，综合评估画面清晰度、人脸完整度、动态流畅度等指标，低于阈值的镜头自动标记为“待重于”，不进入剪辑队列。这道闸门在早期帮我们拦下了大量劣质素材，避免了剪辑师在废片堆里挑素材的噩梦。

有人会担心多一道闸门会影响效率。我的实际体会是，闸门看起来多了一步，但它节省的是下游所有环节的返工时间。宁可在生成端多花三分钟筛掉废片，也不要让成片审核时发现十处问题再全部推倒重来。工业化追求的是“一次做对”，质检线是这条路的保障。

4. 实操记录：我的 API 编排落地细节

4.1 工具选型：Dify、LangChain、扣子，怎么选

很多读者会关心我们用什么工具做编排。这里我可以直接分享选型过程。我们最开始评估过三套方案：Dify、LangChain 和扣子工作流。简单说结论：如果你和我一样需要深度控制、自定义程度高、要跟自己的画布 Agent 深度集成，LangChain 这类可编程框架更合适；如果你的诉求是快速搭一条标准化流程，不太需要定制界面，Dify 和扣子能让你两天就上线。

我们最后用 LangChain 作为底层编排框架，但并没有直接用它的所有高级抽象，而是主要用了它的模型调用封装和链式组合能力，自己实现了一套更贴近短剧场景的任务调度逻辑。原因是短剧流水线本质上是一个“人机协同的混合流程”，中间有人工审批节点，有外部视频生成 API，有异步回调，框架本身提供不了这种业务语义，必须自己二开。

如果你团队里算法工程师多，我建议走可编程路线；如果更多是运营和内容同事在使用，可视化平台的上手成本确实低很多。选型没有绝对好坏，只有适不适合。我们之所以没选纯可视化平台，最重要的原因是“资源控制”。可视化的节点能帮你节省开发时间，但遇到高并发、复杂重试、精细配额管理这些工业化刚需时，写代码的灵活性优势就出来了。

4.2 模型接入与 Token 规划：成本是设计出来的

模型接入这块，我们做了统一模型网关，用一套标准 RESTful API 封装了多家模型服务。对外暴露的接口只有三四个：文本生成、图像生成、视频生成、语音合成。内部再各自转发到对应的真实服务商。这么做的好处是上层业务完全不用关心底层换了哪个模型，随时可以切换供应商。

Token 规划是成本控制的重点，我自己算过一笔账。一条 30 集的短剧，剧本和分镜阶段的生成文本量大约是 60 万到 100 万 token；如果用单次对话把整个剧本一次性塞进去，会远超模型处理的上下文上限，而且费用极高。我们的做法是“分片处理”：每集剧本独立生成，分镜阶段每 5 到 8 个镜头作为一批传给视觉模型，批次之间共享角色描述和场景锚点信息，但绝不把所有历史画面全塞进上下文。

这里有一个非常实用的建议：上下文不是越大越好。大上下文看似信息全，但会让模型注意力分散，输出质量反而下降，费用却成倍上涨。工业化的思路是把“关键信息”做成长时记忆，把“即时信息”保持在短上下文里，用结构化的方式在批次之间传递状态，而不是靠堆 token。我们实践中把单次请求的 token 消耗控制在一个合理范围，质量和成本之间找到了平衡点。

4.3 一套可复用的编排配置示例

我在这里放一个简化版的编排逻辑伪代码，用 Python 描述，你不需要完全照抄，重点看它的分步结构和出错处理思路：

def run_episode(episode_id): # 第一步：生成剧本并解析结构化字段 script = script_agent.generate(episode_id) scenes = parse_scenes(script) # 第二步：逐个场景生成分镜，并写入画布 for scene in scenes: storyboards = storyboard_agent.generate( scene, role_lib=load_role_lib(), scene_anchor=load_scene_anchor(scene.location) ) canvas.save_storyboards(episode_id, scene.id, storyboards) # 第三步：批量提交视频生成任务 task_ids = [] for sb in canvas.get_pending_storyboards(episode_id): if quality_check(sb) >= QUALITY_THRESHOLD: task_id = video_api.submit(sb.to_prompt()) task_ids.append(task_id) # 第四步：轮询任务状态，处理失败重试 results = wait_and_collect(task_ids, max_retries=3, backoff=10) # 第五步：合成配音、字幕，生成最终文件 audio = tts_api.synthesize(script.dialogues) final_video = assemble(results, audio, subtitle_style="short_drama") # 第六步：内容审核 audit_result = audit_api.check(final_video) if audit_result.passed: publish_to_asset_lib(episode_id, final_video) else: notify_human_review(episode_id, audit_result.reasons) return final_video

这个流程看起来简单，但每个函数内部都有不少细节。比如 parse_scenes 不是正则匹配，而是用一个大模型对剧本做二次结构化解析，因为它要理解叙事语义；load_role_lib 会做缓存，避免每次都把十几张角色图传一遍，浪费带宽和上游费用；wait_and_collect 里用线程池做并发等待，而不是串行轮询，这样整体任务耗时才能压下来。

4.4 把画布 Agent 接进 API 网关：签名、鉴权与回调

画布 Agent 不是单独运行的桌面程序，它是作为整个流水线的一个服务节点存在的。所以必须解决好 API 接入问题。我们在网关层做了三个关键动作：签名、鉴权、回调。

签名方面，每个请求都要带时间戳和 HMAC-SHA256 签名，防止请求被篡改。鉴权用的是 API Token，每个服务节点有独立的 Token，权限按最小化原则分配：剧本服务只能调剧本相关模型，视频服务只能调视频生成接口，不能跨权调用。这里踩过教训，早期为了省事所有服务共用一个 Token，结果某个测试任务误调了高额视频生成接口，跑了一宿才发现，账单让人心绞痛。

回调机制是最容易被忽略的。视频生成是异步任务，提交后要等服务端回调通知完成状态，而不是让客户端傻等。我们设置了回调接口，上游服务完成后会把结果 ID 和状态推回来，流水线收到回调后才继续下一步。调试回调链路时要特别注意，回调地址必须是公网可访问的，而且要做好幂等处理，同一回调可能因为网络重试收到多次，如果重复触发下游任务会造成资源浪费，一定要用任务 ID 做去重判断。

5. 常见问题与排查实录

5.1 报错速查表

工业化跑久了，难免会遇到各种报错。我把我们半年内遇到频率最高的错误整理成一张速查表，方便你对照排查。

这里我特别想提醒 400 上下文超限这个错误。第一次遇到时我们以为是模型不支持长文本，后来排查发现是代码 bug，在拼接提示词时把整个素材库都塞进去了，等于让模型读几百页资料再做一句话总结，不超限才怪。调整成按需加载后，问题立刻消失，费用也降了一大截。

5.2 三个让我印象深刻的翻车现场

第一个翻车现场是角色“换头”事故。早期我们做了一部现代都市剧，前五集女主角形象都很稳，第六集开始明显变成另一个人。排查了很久才发现是提示词模板里角色描述字段被截断了，后面镜头没有加载到正确的参考图，画布 Agent 直接按新的文字描述生成，导致角色漂移。从那以后我们加了一个“角色引用完整性校验”，每个镜头提交前都会检查角色 ID 和参考图是否匹配，不匹配就拦截。

第二个翻车现场是配音和口型对不上。AI 短剧的配音是后期合成的，但角色说话的口型是视频生成时模型自由发挥的。早期成片总有一种“说完了嘴还在动”的错位感。后来我们做了一个笨但有效的方案：先把整集台词时长算出来，再约束每段镜头时长与台词时长对齐，生成视频时通过提示词和参数控制镜头的起始动作，尽量给后期留出对齐冗余。这个问题目前没有完全消灭，但已经控制在可接受范围。

第三个翻车现场是成本失控。有一个月我们的 API 费用突然比平时高出三倍，查到最后是测试环境的重试逻辑写错了，失败任务被无限循环提交。那次之后我们给所有重试机制加了最大次数硬限制，并且在监控面板上对“重试占比”做了告警，一旦超过阈值就自动停线检查。千万记住，自动化的最大风险是它会高效地犯错，比人犯错快得多。

5.3 排查思路：先看链路，再看模型，最后看数据

在多次排查实践中，我总结出一套适合短剧流水线的排错顺序：先看链路、再看模型、最后看数据。

先看链路是最快的。从任务提交到回调返回，所有节点都有日志和状态，你先确认每个节点是不是都执行了，有没有卡在某个环节，节点间的参数传递有没有断掉。大多数问题在这一步就能肉眼看见。再看模型是指：如果链路没有问题，就到具体模型调用那里去看输入输出，是不是提示词写得太含糊、参考图没传对、参数设置有冲突。模型的问题通常可以通过更换提示词写法或者调整参数解决。最后看数据，是排查历史数据的影响，比如角色资产库里存了过期数据、场景锚点被覆盖、缓存命中了错误版本。

这套顺序的核心逻辑是：大多数故障都出在集成层，而不是模型能力本身。你如果一上来就怀疑模型不够聪明，很容易陷入反复调提示词的泥潭，而忽略可能是上游传参遗漏了这个最简单的原因。

6. 成本核算与 ROI 复盘

6.1 一条 30 集短剧的算力账单

工业化最后躲不开的就是财务账。我大致列一下我们内部跑完一部 30 集短剧的成本分布，币种单位就按通用计费方式理解，重点是比例关系：剧本生成约占总成本 5%，分镜生成约占 20%，视频生成是大头约占 60%，配音和字幕约占 10%，审核与杂项约占 5%。

视频生成占比这么夸张，是因为它是一个镜头一个镜头地调用视频模型，30 集短剧大约有 450 到 600 个镜头，每个镜头可能还要重跑几遍才能拿到满意的版本。控制成本的关键就是控制视频生成的“重跑率”。我们通过质量分闸门，把一次通过率从早期的 35% 提到了后来的 62%，这意味着同样一部剧，视频生成费用几乎腰斩。

6.2 哪些钱可以省，哪些省不得

省钱这件事，我们的经验是可以从三处入手。第一处是文本模型选型，剧本和分镜阶段可以选择性价比更高的模型，不一定非要顶配，结构化输出和审校能力够用即可；第二处是缓存，相同场景、相同角色的重复描述不要重复生成，直接复用已有资产；第三处是并发调度，避开服务商高峰期也能节省部分成本增量。

但有三笔钱绝对省不得：内容审核的钱不能省，这关乎平台安全和口碑，任何侥幸心理都会在未来加倍找回来；画布 Agent 的开发维护成本不能省，它是整个流水线里“人机协同”的关键界面，体验做不好，其他效率都白搭；监控告警的钱不能省，没有监控的自动化流水线就像蒙着眼睛开车，出了问题你根本不知道在哪一段翻的。这三点是我们用真金白银换出来的教训。

7. 后续演进与个人体会

7.1 从“半自动流水线”到“智能排产”

羽山数智方案跑通以后，我们内部最明显的感受是“人终于可以做人了”。以前团队花了大量时间做重复性劳动，比如调整格式、搬运素材、盯任务进度；现在这些全部由流水线接管，人主要做创意决策和例外处理，比如选定妆图、决定反转点承接方式、介入异常镜头。这才是人机协同该有的样子。

下一步我们正在探索的是“智能排产”：让编排层根据资源占用率、任务紧急程度、模型当前质量表现，自动决定哪部剧先跑、哪些镜头优先重做、哪些环节可以降级处理。本质上是从“自动化流水线”走向“自优化流水线”。这个方向还很新，但我觉得它才是工业化真正的终局。

7.2 一点真心话

最后说一点真心话。做这套方案花了我们很多精力，中途无数次想放弃，尤其是角色一致性怎么都调不好、成本不断超预算的时候。但现在回头看，所有这些痛苦都是值得的，因为工业化最核心的价值不是把单个视频做得更炫，而是把“批量交付”从口号变成了现实。

如果你正在计划搭建自己的 AI 短剧流水线，我给的建议是先别急着上大而全的系统，而是先把手头的流程画出来，标出哪些环节是重复的、哪些环节是容易出错的、哪些环节是成本大头，然后针对性地用 Agent 和 API 编排去解决其中一个痛点。从单点切入，跑通之后再逐步扩展，这条路比一开始就设计一个完美平台要稳妥得多。希望这篇复盘能给你一些参考，也欢迎有类似实践的朋友多交流。