做直播带货和知识分享的内容创作者，最头疼的一件事不是“没货可卖”，而是“没时间做视频”。一条十分钟的知识科普视频，背后是选题、脚本、画面素材、配音、字幕、剪辑、封装这一长串工序。哪怕团队里有两三个人，按传统生产方式，从定稿到发布少说也要两三天；更常见的情况是一个选题拖了一周还没上线，热度早过去了。
这个问题的关键，不是在某一个环节找到一个“神器”，而是把整条视频生产流水线，重构成一个 Agent 可以稳定执行的自动化系统。这也是本文想重点展开的方向：用 Agent 作为任务调度核心，用 Skills 把视频制作的专业经验固化下来，再配合可本地部署的 MinimaxH3 模型完成内容生成，最终形成一套面向直播带货和知识分享场景的长视频自动化生产方案。
读完这篇文章，你会得到三条明确的信息：第一，这套自动化方案的架构到底长什么样，每个组件在链路里干什么活；第二，从零开始要怎么配置环境、怎么设计 Skills、怎么写 Agent 编排脚本；第三，这套方案适合什么人、不适合什么人，真正容易踩的坑在哪里。文章偏工程实践，我会给出可参考的目录结构、代码和排查思路，建议先收藏再看。
1. 这篇文章要解决的问题
如果只看“Agent + MinimaxH3 自动生成视频”这个标题，很容易产生两种极端判断：要么觉得这是科幻片，AI 随便就能出片；要么觉得这就是套壳工具，把几个脚本拼在一起而已。这两种判断都不准确。
先说直播带货场景。带货账号的短视频内容更新频率通常很高，有些团队一天要发三五条引流视频。每条视频都要有钩子、有卖点、有口播、有字幕，还要符合平台的内容规范。靠人工一条条做，成本根本压不下来。更现实的问题是，很多带货团队不缺素材，缺的是把素材快速转成合格视频的生产效率。
再说知识分享场景。这类内容的特点是“长”——三分钟都算短的，十分钟、二十分钟很常见。长视频的难点不只是时长，而是结构：开头要留人，中间要有信息密度，结尾要有总结和引导。传统生产方式里，脚本、画面、配音、剪辑是四个割裂的环节，每一环都要人盯。自动化方案真正解决的，就是把这个割裂的协作过程，压缩成一条可重复执行的流水线。
所以，这篇文章要解决的并不是“做视频要不要人”的问题，而是哪些环节应该交给 Agent，哪些环节必须保留人工，以及怎么用 Skills 把专业经验沉淀下来，让流水线越跑越稳定。
2. Agent、Skills 与 MinimaxH3 的基础认知
在进入工程实现之前，有必要先把三个关键词的技术边界说清楚。因为在实际讨论中，很多人会把“Agent 工作流”和“简单的脚本调用”混为一谈，也会把“Skill”理解成“普通提示词”，这两个误区会直接影响后续的方案设计。
2.1 Agent 不是聊天机器人
Agent 的核心特征，是它能在一个复合任务中自主地做决策和执行。你给它一个目标，它可以自己拆解步骤、调用工具、读取结果、判断下一步动作，并且在失败时尝试修正。它和执行单条提示词的“聊天机器人”有本质区别：聊天机器人等用户输入，Agent 是为了完成一个目标而持续运转的。
在视频自动化生产方案里，Agent 承担的是“项目制片人”的角色。它不亲自做每一件事，但知道每一件事应该交给哪个 Skill 去处理。比如拿到一个选题“如何挑选适合新手的第一台相机”，Agent 会拆成选题分析、脚本创作、分镜设计、配音文本生成等子任务，然后按顺序调度对应的 Skill 去完成。这个拆解和调度过程，就是 Agent 和传统脚本最大的不同。
2.2 Skills 是什么，为什么需要 Skills
Skills 可以理解成“专业技能的封装”。它把某个任务的执行方法、提示词模板、参数约定、输出规范，打包成一个可复用的文件或代码包。Agent 在执行任务时，可以动态加载需要的 Skill，而不是每次都把一大段复杂指令写在对话里。
举个例子。一个“带货口播脚本 Skill”里，可以包含：开头 3 秒抓注意力的模板、卖点介绍的逻辑顺序、价格锚定的表达方式、结尾行动号召的写法、字数控制规范，以及禁止使用的违禁词列表。Agent 接到任务后加载这个 Skill，生成的脚本就会稳定地符合这个风格和规范，而不是每次生成出完全不同结构的文案。
Skills 的关键价值在于知识沉淀。一个团队的视频制作经验，过去存在于资深编导的脑子里，人走了经验就没了。现在可以把这些经验写进 Skill 文件，用 Git 管理，团队每个人都能复用和迭代。这也是为什么近期的 Agent 开发趋势里，Skills 的受关注度越来越高。
2.3 MinimaxH3 在链路中的定位
MinimaxH3 从社区讨论和相关资料来看，是一个支持本地部署的内容生成模型，常和“导演台”“工作流”“提示词 Skill”这些概念一起出现。在本文的视频自动化方案里，它承担的是内容生成引擎的职责：负责把选题扩展成完整脚本、把脚本转成可供视频渲染的分镜描述、以及生成配音所需的文案内容。
之所以强调“本地部署”，是因为视频生产链路往往涉及大量中间产物。脚本要反复改、分镜要频繁调，如果每一次调用都走远程 API，不仅成本不可控，数据安全也是一个问题。本地化部署意味着生成任务可以在自有环境里完成，Agent 可以将中间结果直接写入本地工作区，减少网络等待，也方便做批量化生产。
需要说明的是，本文不承诺 MinimaxH3 的具体参数或功能清单，因为这取决于实际使用的版本和官方文档。文章的重点是：在自动化链路中，模型是最后一个负责“出内容”的环节，前面所有编排工作，都由 Agent 和 Skills 完成。理解了这一点，即使后续替换成其他模型，整个架构也不需要推倒重来。
3. 视频自动化生产的整体架构
有了基础概念，接下来看整套方案如何组织。视频自动化生产不是简单地把模型输出丢给剪辑软件，而是一条有清晰阶段划分的流水线。
3.1 传统长视频制作流程的痛点
传统流程一般是这样的：编导定选题、写脚本，摄影或剪辑找素材，配音录制口播，后期剪节奏、加字幕、配音乐，最后人工审查后发布。这条流程有四个明显的痛点：
- 信息割裂：脚本、分镜、素材、字幕分散在不同人手里，风格很难统一。
- 返工成本高：剪辑到一半发现脚本逻辑有问题，整个后半段要重做。
- 经验难复制：老手知道怎么开场更抓人，但这种经验很难量化给新人。
- 批量生产难：做一个视频可以靠人力堆，做一百个视频就完全不是一回事了。
自动化方案的存在意义，不是消灭这些环节，而是把每个环节都改造成“输入结构化、输出可校验”的标准流程。
3.2 自动化流水线的六个环节
这套方案的核心流水线可以拆成六个环节：
| 环节 | 输入 | 输出 | 执行角色 |
|---|---|---|---|
| 选题规划 | 行业关键词、账号定位 | 选题列表及优先级 | Agent + 选题 Skill |
| 脚本生成 | 选题、目标受众 | 完整口播脚本 | Agent + 文案 Skill + MinimaxH3 |
| 分镜设计 | 脚本正文 | 分镜表（画面+时长） | Agent + 分镜 Skill |
| 素材准备 | 分镜表 | 图片/视频片段/配音 | Agent + 素材 Skill + MinimaxH3 |
| 视频合成 | 素材包 | 带字幕和背景音乐的视频 | 渲染脚本 / 视频合成工具 |
| 质量审查 | 成片 | 审查报告与修改建议 | Agent + 审查 Skill + 人工 |
从表格里可以看到，Agent 是贯穿全程的调度者，Skills 是每个环节的操作手册，MinimaxH3 则在脚本、分镜、配音文本等多个内容生产点提供生成能力。视频合成这一步属于偏工程化的部分，通常由 FFmpeg、渲染服务或剪辑软件命令行完成，Agent 负责传参和调度。
3.3 为什么说“本地部署”是重要前提
对于直播带货团队和知识分享创作者来说，内容数据往往有明确的保密需求。带货脚本可能涉及商品价格政策、渠道策略；知识分享内容可能有未发布的课程框架。如果全部经过远程模型处理，数据管控和成本预算都是问题。
本地部署 MinimaxH3 之后，整个内容生产链路可以在自己的服务器或工作站里闭环完成。Agent 调用模型生成脚本，脚本直接写入本地目录，后续的分镜和渲染也都在本地处理。这样既降低了接口调用的延迟，也更容易控制批量生产时的成本。
4. 环境准备与前置条件
下面进入可操作的部分。环境准备是整套方案里最容易让人失去耐心的环节，但它直接决定后续流程能否稳定运行。
4.1 硬件与系统
视频自动化生产涉及模型推理和视频渲染，对计算资源有明确要求。具体的硬件配置要以你实际使用的模型版本和官方文档为准，本文不写死最低配置，但有两个建议：
- 模型推理建议使用带 GPU 的环境，显存大小会影响能加载的模型规模；
- 视频渲染需要足够的磁盘空间，一条十分钟的视频中间产物可能有好几 GB。
操作系统方面，Windows、macOS、Linux 都可以搭建这套链路。Linux 服务器更适合长期批量跑任务，macOS 适合个人开发者做原型验证，Windows 则适合在本地快速测试。
4.2 运行时与依赖
建议在环境里准备以下基础组件：
- Python 3.10 及以上版本，用于运行 Agent 编排脚本和调用模型；
- Node.js 18 及以上版本，如果你选择的 Agent 框架或 Skills 工具基于 Node.js 生态；
- Git，用于管理 Skills 文件、脚本和提示词模板的版本；
- FFmpeg，用于最终视频合成和格式转换。
依赖管理建议使用requirements.txt或pyproject.toml来锁定 Python 包版本，避免“昨天能跑，今天跑不了”的问题。
4.3 MinimaxH3 部署前的检查项
部署 MinimaxH3 前，建议按下面的清单做一次检查：
# 检查 GPU 驱动状态（NVIDIA 环境） nvidia-smi # 检查 Python 版本 python --version # 检查磁盘空间 df -h /data # 检查 Git 是否可用 git --version # 检查 FFmpeg 是否已安装 ffmpeg -version如果nvidia-smi能正常输出 GPU 信息，说明驱动基本可用。如果某个命令报错，先补齐对应组件，再继续后续步骤。模型的具体安装方式、启动命令和依赖，一律以模型官方文档为准，不同来源的“一键包”质量参差不齐，不建议在生产环境使用来路不明的安装脚本。
5. 核心工程实现
环境准备好之后，我们来拆解整个自动化方案的核心工程实现。这一部分会提供可复制的目录结构、Skill 定义文件和 Agent 编排脚本。示例使用通用思路编写，目的不是绑定某个特定 Agent 框架，而是让你理解设计方法后，能迁移到自己的技术栈里。
5.1 设计 Skills 目录结构
一个规范的 Skills 目录结构，是整套方案可维护性的基础。建议这样组织：
skills/ ├── content_script/ # 文案脚本 Skill │ ├── SKILL.md # Skill 的行为说明 │ ├── params.json # 参数定义 │ └── templates/ │ └── live_selling.md # 带货口播模板 ├── storyboard/ # 分镜设计 Skill │ ├── SKILL.md │ ├── params.json │ └── templates/ │ └── storyboard_table.md └── review_quality/ # 质量审查 Skill ├── SKILL.md └── rules/ └── content_safety.md每个 Skill 都是一个独立目录，包含说明文件、参数配置和模板。这样设计的好处是：某个 Skill 的规则调整不影响其他模块；团队可以多人并行维护不同的 Skill；通过 Git 可以清楚看到每个 Skill 的变更历史。
下面是一个SKILL.md文件的示例：
# 技能名称：带货口播脚本生成 ## 功能描述 根据商品信息和目标用户，生成符合直播带货规范的 口播脚本。脚本包含开场钩子、痛点引入、卖点介绍、 价格锚定、行动号召五个部分。 ## 适用场景 - 直播短视频预热 - 视频号/抖音带货口播 - 商品讲解长视频 ## 输出规范 - 字数控制在 800 到 1500 字 - 禁止使用绝对化用语 - 每段不得连续超过 3 句话 - 结尾必须包含明确的行动号召5.2 编写内容创作类 Skill
上面的SKILL.md解决了“这个 Skill 是干什么的”的问题，接下来还要有参数定义和提示词模板。
params.json用来声明这个 Skill 运行时需要的参数：
{ "name": "content_script", "version": "1.0.0", "description": "生成带货口播脚本", "parameters": { "product_info": { "type": "string", "description": "商品名称、核心卖点、价格信息", "required": true }, "target_audience": { "type": "string", "description": "目标人群画像", "required": false }, "video_duration": { "type": "integer", "description": "目标视频时长，单位秒", "required": false } } }有了参数定义，Agent 在调用这个 Skill 时就能知道需要收集哪些信息，输出了什么结构化的参数给模型。
5.3 编写视频分镜与剪辑类 Skill
脚本生成之后，下一步是转成分镜表。分镜 Skill 的作用，是把一段连续的口播脚本，拆成按镜头组织的内容。这里给出一个模板示例：
# 分镜表 视频标题：{{title}} 视频时长：{{duration}} 秒 视频比例：{{aspect_ratio}} | 序号 | 时间区间 | 画面描述 | 字幕文案 | 备注 | | --- | --- | --- | --- | --- | | 1 | 0:00-0:05 | 商品特写，背景为纯色 | {{hook_text}} | 开场钩子 | | 2 | 0:05-0:20 | 主播手持商品讲解 | {{pain_text}} | 痛点引入 | | 3 | 0:20-0:45 | 商品功能演示画面 | {{feature_text}} | 卖点介绍 | | 4 | 0:45-0:55 | 价格标签出现 | {{price_text}} | 价格锚定 | | 5 | 0:55-1:00 | 主播指向屏幕方向 | {{cta_text}} | 行动号召 |这个模板通过{{变量}}占位，Agent 在运行时会根据实际脚本内容填充。分镜表不仅指导画面生成，也直接决定渲染脚本的转场和时长安排。
5.4 使用 Agent 编排完整工作流
核心编排逻辑可以用 Python 来实现。下面是一个简化版示例，演示 Agent 如何加载 Skill、调用模型、生成中间产物：
# 文件路径：pipeline/orchestrator.py from dataclasses import dataclass @dataclass class Task: skill_name: str input_path: str output_path: str class VideoAgent: def __init__(self, model_endpoint: str): self.model_endpoint = model_endpoint self.skills = {} def load_skill(self, skill_name: str, skill_dir: str): """加载 Skill 定义。""" # 实际实现中，这里会读取 SKILL.md 和 params.json # 并把解析结果存入 self.skills self.skills[skill_name] = {"dir": skill_dir, "loaded": True} return self def run_task(self, task: Task, context: dict) -> str: """执行单个任务，调用本地模型生成内容。""" # 1. 读取 SKILL.md 里的系统提示词 # 2. 把 context 和输入文本拼装成完整 prompt # 3. 请求本地 MinimaxH3 模型 # 4. 把模型输出写入 task.output_path output_text = self._call_model(task, context) with open(task.output_path, "w", encoding="utf-8") as f: f.write(output_text) return output_text def _call_model(self, task: Task, context: dict) -> str: # 这里以伪代码表示模型调用过程 # prompt = build_prompt(task, context) # response = requests.post(self.model_endpoint, json={...}) # return response.json()["content"] return "模型生成的文本内容" if __name__ == "__main__": agent = VideoAgent(model_endpoint="http://127.0.0.1:8000/generate") agent.load_skill("content_script", "skills/content_script") agent.load_skill("storyboard", "skills/storyboard") # 任务1：根据选题生成脚本 script_task = Task( skill_name="content_script", input_path="input/topic.txt", output_path="output/script.md", ) script = agent.run_task(script_task, { "topic": "如何选择适合新手的微单相机", "target_audience": "刚入门的摄影爱好者", }) # 任务2：根据脚本生成分镜 storyboard_task = Task( skill_name="storyboard", input_path="output/script.md", output_path="output/storyboard.md", ) agent.run_task(storyboard_task, { "title": "新手微单选购指南", "aspect_ratio": "16:9", })这个示例的核心逻辑是：Agent 本身只是一个调度器，它不关心某个文案怎么写、分镜怎么设计，它只负责把任务按顺序分配下去，并把上一个任务的输出作为下一个任务的上下文。这样做的好处是，任何一步出了问题，只需要修改对应的 Skill，而不需要改动整个编排逻辑。
5.5 提示词模板设计要点
不管用哪个 Agent 框架，提示词模板都是决定生成质量的关键。这里给出一个供参考的提示词模板结构：
# 角色定位 你是一名有 10 年经验的直播带货编导。 # 任务目标 根据以下商品信息，生成一段完整的带货口播脚本。 # 商品信息 {{product_info}} # 目标受众 {{target_audience}} # 输出要求 1. 严格按照“开场钩子、痛点引入、卖点介绍、 价格锚定、行动号召”五段结构输出； 2. 总字数 800 到 1500 字； 3. 语言口语化，避免书面语； 4. 禁止使用绝对化用语，如“最好”“第一”“百分百”； 5. 直接输出脚本内容，不要输出解释文字。模板的关键在于“约束明确、结构稳定”。越是需要批量生产的视频，提示词里越不能留太多让模型自由发挥的空间。每一个输出段落的结构、数量、禁忌，都要写明。
6. 运行与效果验证
工程链路搭建完成后，接下来要验证整条流水线是否真的能产出合格内容。这个阶段的目标不是追求“一次成功”，而是建立一套可以判断成功和失败的验收标准。
6.1 从选题到成片的试运行
推荐先用一个最小任务跑通全流程。比如选择“手机拍照小技巧”这样范围明确、不涉及复杂商品的选题。运行流程如下：
# 1. 准备选题文件 echo "手机夜景拍摄的三个设置技巧" > input/topic.txt # 2. 运行 Agent 编排脚本 python pipeline/orchestrator.py # 3. 检查中间产物 ls -la output/如果一切正常，output目录下会依次出现script.md和storyboard.md。人工打开这两个文件，检查脚本是否符合 Template 结构的五段式要求，分镜表是否填入了合理的画面描述。中间产物合格后，再用后续的合成脚本生成成片。
6.2 判断视频质量的四个维度
自动化生成的视频，不能只看“有没有画面、有没有字幕”，要按下面的维度逐项验收：
| 维度 | 验收标准 | 检查方式 |
|---|---|---|
| 内容准确性 | 信息无事实错误，无违规词 | 人工通读脚本 + 关键词扫描 |
| 画面一致性 | 画面描述与字幕文案对应 | 抽查分镜表和成片的对应段 |
| 语音自然度 | 配音无明显机械感 | 听 30 秒以上 |
| 剪辑节奏 | 开场 5 秒有钩子，转场不突兀 | 按分镜表时间区间抽查 |
如果四个维度里有三个不达标，不要试图在剪辑阶段修复，先回到对应的 Skill 和提示词模板去调整。
6.3 失败时的排查路径
自动化流水线的特点是一环扣一环，任何一步失败，后面的任务都可能中断。排查时建议按下面的顺序进行：
- 先看编排脚本的日志，确认任务执行到哪一步中断；
- 检查对应 Skill 的输入文件是否存在、格式是否正确；
- 查看模型调用日志，确认是否返回了预期格式的内容；
- 检查输出文件是否写入成功，编码是不是 UTF-8；
- 如果是渲染阶段失败，查看 FFmpeg 的报错信息，确认是否缺少编解码器或字体文件。
7. 常见问题与排查思路
在实际部署这套方案时，团队最容易遇到的问题集中在环境、模型调用和内容质量三块。下面整理一份高频问题排查表：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型启动失败 | 显存不足或驱动版本过低 | 查看启动日志与nvidia-smi输出 | 更换更大显存设备或升级驱动 |
| Agent 执行中断 | 某个 Skill 加载失败 | 查看 Skill 目录是否正确、params.json是否合法 | 修正 Skill 路径和 JSON 格式 |
| 生成的脚本不符合五段式结构 | 提示词模板被修改或权重冲突 | 检查模板文件内容和 SKILL.md 规则 | 恢复模板，并在模板中强调结构顺序 |
| 分镜表存在空缺字段 | 上一个任务输出缺少关键信息 | 查看 script.md 是否缺少卖点描述 | 在脚本 Skill 的模板中增加必填字段校验 |
| 视频渲染时报编码错误 | FFmpeg 未安装或版本过旧 | 运行ffmpeg -version | 安装或升级 FFmpeg |
| 字幕时间轴与口播不同步 | 分镜表时间区间与实际配音时长不匹配 | 比较配音音频时长和分镜表總时长 | 在分镜 Skill 中增加“按配音时长自动切分”规则 |
| 生成文本出现事实错误 | 模型没有获得准确的商品资料 | 检查输入上下文是否包含可靠信息 | 增加知识库或人工审核环节 |
| 批量任务越跑越慢 | 中间产物未清理，磁盘占用过高 | 查看磁盘占用和日志文件大小 | 定期清理中间产物，配置日志轮转 |
表格里列出的这些问题，多数不是模型不够聪明，而是流程设计有缺口。排查时不要先怀疑“模型不行”，先检查自己的输入、模板和依赖环境。
8. 最佳实践与生产建议
自动化视频生产不是“一个脚本配一个模型”就能长期稳定运转的。真正进入生产阶段后，还有几件容易被忽略的事，值得单独强调。
8.1 内容安全与版权边界
自动生成视频最大的风险，不是技术跑不通，而是内容合规出问题。带货视频涉及商品宣传，要严格遵守广告法；知识分享视频引用他人素材时，要确保有合法的使用授权。
在 Agent 编排层，建议把“内容安全审查”做成一个独立的 Skill。每次视频合成前，先让审查 Skill 扫一遍脚本和分镜，检查有没有违禁词、绝对化用语、侵权风险词。这不是象征性检查，而是要产生可留痕的审查报告，方便后续追溯。
8.2 质量人工 Review 机制
不要追求“全自动无人值守”。最合理的生产模式是：Agent 批量产出候选视频，人工只审核最终成片。这样可以兼顾效率和风险控制。
具体操作上，可以给每一条自动生成的视频设置一个状态字段。Agent 生成完成后标记为pending_review，人工审核通过后标记为approved，不通过的标记为rejected并填写原因。人工审片的结果反过来可以作为优化提示词和 Skill 的训练数据。
8.3 用 Git 管理 Skills 变更
Skills 是整套方案的“知识资产”，一定要纳入版本管理。每次提示词调整、模板修改、规则更新，都提交一次变更，并在提交信息里说明原因。
git add skills/ git commit -m "优化带货脚本 Skill：调整开场钩子模板，增加违禁词过滤"这样做的价值在于：当某次调整导致生成质量下降时，可以快速回滚到上一个稳定版本，而不是靠记忆去恢复文件。多人协作时，也建议通过代码评审的方式合并 Skill 变更。
8.4 成本控制与资源规划
视频自动化生产看起来节省了人力，但计算资源成本是真实存在的。两个建议：
- 批量任务尽量错峰运行，避免生成任务和渲染任务同时抢占 GPU，导致单任务耗时翻倍；
- 给中间产物设置生命周期，脚本和分镜这类纯文本产物保留即可，临时渲染素材按天清理，防止磁盘被占满。
另外，Agent 的权限要遵循最小权限原则。编排脚本只需要读写特定目录的权限，不要给它整个系统的操作权限，尤其是涉及删除、覆盖生产文件的操作，必须在脚本里增加双重确认逻辑。
9. 总结与后续学习方向
这套基于 Agent、Skills 与 MinimaxH3 模型的视频自动化生产方案，核心思路可以概括成一句话：把视频制作经验工程化，让 Agent 调度可复用的 Skill，让本地模型负责内容生成，用标准化流程批量产出长视频。
它不是要取代编导和剪辑师，而是把重复性高、创造性低的部分交给自动化链路，把人解放出来去处理选题判断、内容把关和策略调整。从直播带货的引流视频，到知识分享的科普长视频，只要内容生产流程可以标准化，这套架构就有复用的价值。
接下来值得深入的方向有三个。第一，学习主流 Agent 框架的官方 Skills 规范，了解不同框架在 Skill 加载、参数传递和错误恢复上的差异，选型时更有依据。第二，如果你的内容类型非常垂直，比如专注某一领域的科普，可以在本地模型的基础上做领域化的提示词优化，甚至可以结合检索增强生成（RAG）为模型补充准确的背景资料。第三，把自动生成的视频数据沉淀下来，分析哪类脚本的完播率高、哪类开头的转化效果好，用真实反馈反向优化 Skill 模板。
最后提醒一句：视频内容的自动化生产是一条越走越宽的路，但起点永远是先把一个最小闭环跑通。先让一条视频完整生成，再让一百条视频稳定生成，最后才是让一百条视频都达到可发布的质量。建议收藏这篇文章，搭建环境时按章节逐步操作，遇到问题优先看第 7 节的排查表，效果验证严格按第 6 节的验收标准执行。
