企业官网建设流程全解析

如果你在抖音、快手或B站刷到那种“萌系小精灵日常”的动画短视频，大概率会以为是某个动画工作室的作品。实际上，这类视频已经有相当一部分是个人创作者用 AI 全流程做出来的：LLM 写剧本，AI 绘画画角色，图生视频让画面动起来，再配上一段 TTS 配音和 BGM，最后剪辑成片。整个过程从原来的“需要一个原画师、一个动画师、一个配音演员、一个剪辑师”，压缩到“一个熟悉 AIGC 工具链的人”。

围绕“奇妙萌可 AI 短视频”这类需求，真正值得研究的技术问题，不是哪个 AI 模型画得最好、生成最流畅，而是如何保证角色前后一致、叙事连续、音画同步。换句话说，AI 短视频的壁垒已经从“单点工具的使用”变成了“内容生产管道的搭建”。本文会从一条完整的 AI 短视频制作链路出发，讲清楚剧本、角色、画面、动态、配音、剪辑每一步怎么落地，也会指出最容易踩坑的地方。

如果你正在做短视频运营、独立开发 AI 内容工具，或者只是对 AIGC 创作感兴趣，这篇文章能帮你把一个看起来“很玄”的需求拆解成可执行的工程流程。下文用“奇妙萌可”这类萌系角色作为案例，同时会说明版权边界和替代方案。

1. 这篇文章真正要解决的问题

很多人第一次接触 AI 视频工具时，都会有这种感觉：单看某一个模型，效果相当惊艳。生成一张角色图、一段 5 秒的镜头、一句自然配音，都已经能做到以假乱真。但一旦想做一个“连续剧情的短视频”，问题就立刻冒出来了。

第一个问题是角色不一致。第一张图的角色是粉发、蓝眼睛、白色魔法袍，到第二张图，脸型变了，衣服花纹变了，甚至瞳色都变了。在短视频里，观众对连续性的容忍度很低，一个角色频繁“变形”，基本就宣告作品失败。

第二个问题是叙事不成片。单个镜头很好看，但镜头之间没有逻辑关系。上一秒角色还在森林，下一秒就出现在城堡，没有过渡、没有因果，观众看不懂在讲什么。这不是模型的问题，而是缺少“剧本结构”和“分镜拆分”。

第三个问题是音画同步。AI 生成视频时不会自动生成口型和表演节奏，如果把配音和时间轴硬凑在一起，就会出现“嘴巴没动、台词在响”的尴尬效果。很多人做到这一步就放弃了。

第四个问题是质量不稳定。同样的提示词，生成三次，三次结果差异很大。这种不确定性对创作来说是灾难，需要通过固定种子、参考图、LoRA 等方式去约束。

所以，这篇文章真正要解决的问题，不是“哪个 AI 工具最厉害”，而是怎么把 AI 绘画、AI 视频生成、语音合成、剪辑几件事串起来，做成一条稳定的、可以重复生产的短视频流水线。文章会用一个“萌系魔法角色”的项目作为贯穿案例，带你从零跑通全流程。

2. 核心概念与AI短视频制作链路

在进入实操前，先统一认识一下几个核心概念。这篇文章后面会频繁使用这几个词。

• LLM：大语言模型，负责理解和生成文本。在短视频流程里，它主要承担“编剧”和“分镜脚本生成”的工作。
• 文生图：根据文字描述生成图片。用来设计角色、绘制场景。
• 图生图：在已有图片基础上，根据新的提示词生成变体。比如把一张草稿细化成成品图。
• 图生视频：从静态图片生成动态视频片段。这是“让画面动起来”的关键技术。
• TTS：文本转语音，把台词变成配音音频。
• Agent：智能体，在 AI 小镇这类项目里，指由 LLM 驱动的虚拟角色，它们有记忆、有目标、可以对话。

一条完整的 AI 短视频生产链路，可以拆成七个环节：

和传统动画视频相比，AI 短视频的变化发生在多个层面。

这意味着，AI 短视频本质上不是“艺术创作”单点突破，而是一套“软件工程管道”。你需要像做后端流水线一样管理输入、输出和异常，而不是像动画师一样逐帧精修。

3. 环境准备与前置条件

这一节看起来偏基础，但很多问题都出在环境上。如果你已经在用一些 AI 工具，可以跳过前面部分，直接看模型与 API 选型。

3.1 硬件要求

如果使用本地开源模型做绘图和视频生成，硬件要求会比较直接：NVIDIA 显卡优先，显存 8GB 以上可以跑基础流程，16GB 以上更从容。如果是生成视频，显存越大越好，因为视频模型需要在显存里同时处理多帧图像。

如果主要使用在线 API 平台，对本地硬件要求会低很多。一个普通笔记本、网速够快就行。文章后面介绍的链路就属于这种混合模式：本地只做素材管理和脚本调用，重计算放在云端。

3.2 软件与运行环境

推荐使用以下基础环境：

• Python 3.10 或更高版本
• Git
• FFmpeg
• VS Code 或其他代码编辑器
• Anaconda 或 Miniconda 用于管理 Python 环境

如果是本地部署绘图模型，可以选用 Stable Diffusion WebUI 或 ComfyUI。两者都是图形化界面，适合不同操作习惯。ComfyUI 的节点式工作流更灵活，适合做流水线；WebUI 上手更快，适合快速验证效果。

用命令行创建一个干净的 Python 环境：

# 创建 Python 环境 conda create -n ai-video python=3.10 -y conda activate ai-video # 安装常用依赖 pip install openai requests numpy pillow ffmpeg-python # 验证 FFmpeg 是否安装成功 ffmpeg -version

如果你的系统没有装 FFmpeg，macOS 可以用brew install ffmpeg，Ubuntu/Debian 可以用sudo apt install ffmpeg，Windows 建议从官网下载并加入 PATH。后续合成音频视频会频繁用到它。

3.3 模型与 API 选型

文本模型方面，可选方案很多。闭源 API 接入简单，质量稳定；开源模型可以本地部署，成本更可控，但需要自己管理显存和推理服务。选型的核心指标是“结构输出能力”，也就是你能不能要求模型输出严格的 JSON 或 Markdown 表格。短视频流水线非常依赖这种能力。

绘图模型方面，本地开源方案比较常见的是 Stable Diffusion 系列模型。实际操作时可以下载一些卡通、二次元风格的底模，或者训练角色专属 LoRA。在线绘图平台则更适合不想折腾环境的人。

视频生成方面，国内有不少在线平台支持图生视频，也有一些开源视频模型可以本地部署。这里不特指某个平台，因为每个平台的能力、价格、审核规则都在变化。你的选择标准应该是：是否支持图生视频、是否支持控制镜头运动方向、生成时长是否够用、分辨率是否满足发布要求。具体版本和参数，请以你使用的平台官方文档为准。

4. 剧本生成：先用LLM把故事结构化

很多新手拿到 LLM 后，第一句话是“帮我写一个关于萌可的短视频剧本”。这种提问方式效率很低，因为模型不知道该生成多长、什么风格、几个镜头、要配音还是纯字幕。它只能给出一段通用回答。

正确的做法，是先把故事变成“结构化数据”。这一步决定了后续所有环节的效率。

4.1 用角色卡固定人物设定

所谓角色卡，就是用一个 JSON 结构把角色的外貌、性格、说话风格、声音全部固定下来。每次和 LLM 交互时，都把角色卡内容一起传过去，这样模型每次写出来的剧本就不会跑偏。

这里给出一个角色卡示例：

{ "character_id": "mengke_01", "name": "萌可", "personality": "好奇、调皮、有点小傲娇", "appearance": { "species": "魔法小精灵", "hair_color": "粉色", "eyes": "大而圆，深蓝色", "outfit": "白色魔法袍，带星星纹饰", "props": "一颗发光的魔法宝石" }, "voice": { "timbre": "清爽、活泼的少女音", "speed": "偏快", "emotion": "容易惊喜，也容易生气" }, "speech_style": "句式简短，喜欢使用感叹词，偶尔会自言自语" }

角色卡的价值，是让“角色”成为一个可复用的数据对象。以后换一个视频剧本，不再需要重新描述角色，直接加载这个 JSON 就行。

4.2 用 LLM 生成分镜脚本

拿到角色卡之后，可以把短视频拆成“格式要求 + 剧情要求 + 角色卡”三部分，一次性让 LLM 输出结构化脚本。

你是短视频编剧。请根据以下设定输出一个 15 秒竖屏短剧脚本。 角色设定： {把角色卡 JSON 内容粘贴到这里} 剧情要求： 萌可在森林里发现一颗会说话的星星，好奇地把它带回家。 输出格式要求： 必须使用 JSON 数组格式，每个数组元素代表一个镜头，字段如下： - shot_index: 镜头序号 - duration: 镜头时长（秒） - scene: 场景描述 - action: 画面动作描述 - dialogue: 台词 - sound_effect: 音效 - camera: 镜头运动方式（推近/拉远/平移/固定）

LLM 的输出示意如下，真实输出可能因模型而异：

[ { "shot_index": 1, "duration": 3, "scene": "森林晨光，树梢挂着露珠", "action": "萌可从树洞探出头，手里的魔法宝石闪烁", "dialogue": "今天也要去冒险！", "sound_effect": "鸟鸣、树叶沙沙声", "camera": "固定镜头，轻微推近" }, { "shot_index": 2, "duration": 4, "scene": "小径尽头，一颗星星从灌木丛里滚出来", "action": "萌可弯腰捡起星星，星星发出金色微光", "dialogue": "咦？你是迷路了吗？", "sound_effect": "好奇的钢琴音效", "camera": "跟随萌可动作，向下平移" }, { "shot_index": 3, "duration": 4, "scene": "萌可站在家门口，怀里抱着星星", "action": "星星发光，萌可露出惊喜的表情", "dialogue": "那以后你就住我家吧！", "sound_effect": "欢快的八音盒旋律", "camera": "从远景缓慢推近到萌可表情" } ]

这个 JSON 数组就是后续一切素材生成的“施工图纸”。建议把它保存为script.json，放在项目目录里，不要在生成过程中反复手动复制。

5. 素材生成：用AI绘画解决角色一致性问题

在萌系角色短视频里，角色一致性是最影响观感的部分。接下来详细讲怎么解决。

5.1 为什么角色一致性是难点

Stable Diffusion 这类图像模型本身没有“角色记忆”。你给它一段文字描述，它按概率重新生成一张图。不同生成批次之间的随机性很大，所以同样的描述，两次得到的面孔几乎不可能完全一样。

要在多张图中保持相同角色，只有两条路：第一，每次生成时都喂给模型同一张参考图；第二，把角色的视觉特征训练进一个专用模型。前者成本低，后者效果好。

对“奇妙萌可”这类需要连续剧情的短视频，最低要求是“参考图 + 控制条件”，长期产出则建议训练 LoRA。

5.2 生成角色设定图

第一步先用文生图生成一张角色设定图。建议一次性多生成几张，从中挑选最接近角色卡描述的一张，作为后续所有镜头的基准参考图。

正面提示词和负面提示词示例：

positive prompt: a cute magical fairy girl, pink hair, big blue eyes, white magic robe with star pattern, glowing magic gem, chibi style, anime style, polished, soft lighting, full body, character reference sheet, neutral background negative prompt: blurry, distorted face, extra hands, bad anatomy, low quality, watermark, text, realistic photo, extra legs

注意事项：

• 如果你的绘图平台支持中文提示词，可以换成中文，效果差异取决于平台。
• “character reference sheet”是设定图常用词，有助于模型生成正面、背面等参考角度。
• 先固定一个 seed 值，记录这个 seed，后续微调更容易复现。

绘图模型没有统一参数，一般建议采样步数在 20 到 30 之间，CFG Scale 在 5 到 7 之间。具体以你使用的工具为准。

5.3 批量生成分镜画面

拿到角色设定图后，把分镜脚本里的每个镜头拆出来，逐镜头生成对应的关键帧图片。这里需要用到图生图功能。在 Stable Diffusion WebUI 或 ComfyUI 中，加载底模，挂上角色 LoRA（如果有），同时候填入设定图作为参考图，然后输入该镜头的场景描述，就能得到符合角色形象的分镜画面。

如果要做一个自动化脚本，可以先把脚本 JSON 解析为镜头列表，再调用绘图接口逐张生成。下面是一个流程示意：

import json import os # 伪代码：调用绘图接口生成分镜画面 # 请根据你使用的绘图 API 或本地 WebUI 接口替换实际请求 def generate_frames(script_path, output_dir): os.makedirs(output_dir, exist_ok=True) with open(script_path, "r", encoding="utf-8") as f: script = json.load(f) for shot in script: index = shot["shot_index"] action = shot["action"] scene = shot["scene"] # 将 action 和 scene 拼接为生成提示词 prompt = f"{scene}, {action}, same character as reference image" # resp = requests.post("http://localhost:7860/sdapi/v1/img2img", json=payload) output_path = os.path.join(output_dir, f"frame_{index:03d}.png") # resp_image.save(output_path) print(f"frame {index} generated -> {output_path}") return output_dir

实际开发时，建议不要把绘图逻辑写死在脚本里，而是封装成一个generate_frame(shot, character_ref)函数，方便后续替换模型。

6. 动画生成：图生视频的镜头与运动控制

关键帧已经画好了，接下来要让画面动起来。这一步是 AI 短视频和普通“PPT 视频”的分水岭。

6.1 三种视频生成路径对比

在角色短视频项目中，最值得优先使用的是“图生视频”。因为关键帧已经锁定了角色样貌，图生视频只需要负责“怎么动”的问题，不需要重新理解角色。

6.2 关键帧工作流

推荐的工作流是“关键帧 + 片段生成 + 拼接”：

1. 用一个静态关键帧作为视频首帧。
2. 在图生视频平台上传关键帧，输入镜头运动描述。
3. 生成 3 到 10 秒的短视频片段。
4. 如果片段不满意，重新生成或换关键帧。
5. 将所有镜头片段按顺序拼接。

镜头运动提示词可以尽量具体。比如“缓慢推近镜头，背景微微模糊，角色头发随风飘动”。不同平台对运动控制的支持程度不一样，有的平台支持运镜方向按钮，有的平台只能靠文字描述。要具体情况具体对待。

6.3 一个通用的图生视频调用示例

下面是一个通用的 Python 调用示意，用来说明“上传关键帧、创建生成任务、轮询结果”的基本流程。真实平台的 API 名称和参数一定不同，务必替换为官方文档中的实际接口。

import requests import time # 伪代码：以某视频生成平台通用 API 为例 # 实际使用时，请替换为你的视频生成平台官方 API API_URL = "https://api.example-platform.com/v1/video_generation" API_KEY = "your-api-key" # 推荐使用环境变量读取 def generate_video_from_image(image_path, prompt, duration=5): headers = {"Authorization": f"Bearer {API_KEY}"} # 第一步：提交任务 with open(image_path, "rb") as f: resp = requests.post( API_URL, headers=headers, data={ "prompt": prompt, "duration": duration, "resolution": "1080x1920", "fps": 24, }, files={"image": f}, ) task_id = resp.json()["task_id"] # 第二步：轮询任务状态 while True: status_resp = requests.get( f"{API_URL}/{task_id}", headers=headers, ).json() if status_resp["status"] == "succeeded": return status_resp["video_url"] elif status_resp["status"] == "failed": raise RuntimeError(status_resp.get("error_message")) time.sleep(10) # 使用示例 video_url = generate_video_from_image( "frames/frame_001.png", "少女好奇地弯腰看向地面，镜头缓慢推近", ) print(video_url)

写代码时要注意两点：API Key 绝对不要硬编码在源码里，建议用环境变量读取；生成任务可能耗时较长，轮询间隔不要太小，否则容易触发平台限流。

6.4 分段拼接与镜头节奏

视频生成平台通常一次只能生成几秒到十几秒的片段，长视频需要分段完成。分段拼接时，建议每个镜头之间留 0.2 到 0.5 秒的转场缓冲，避免画面硬切。

节奏方面有一个简单经验：台词密集的镜头，片段时长可以短一些，配合快节奏 BGM；情感戏和场景展示，片段时长可以拉长，让镜头慢慢推进。这样观众看起来会舒服很多。

7. 配音、音效与剪辑合成

画面和片段都到位后，进入后半程：配音与合成。

7.1 TTS 配音

TTS 选型要考虑两件事：音色是否匹配角色，以及情感表达是否自然。萌系角色通常需要明亮、语调起伏明显的音色。尽量选择支持多音色、支持语速调节的工具。

实际操作时，把 script.json 里每个镜头的 dialogue 字段提取出来，逐段生成音频：

import json def extract_dialogues(script_path): with open(script_path, "r", encoding="utf-8") as f: script = json.load(f) dialogues = [] for shot in script: if shot.get("dialogue"): dialogues.append({ "shot_index": shot["shot_index"], "dialogue": shot["dialogue"], }) return dialogues

这段代码只做一件事：把台词从脚本里抽出来，方便批量配音。真实的 TTS 调用接口因平台而异，但数据准备逻辑是通用的。

配音生成后，一定要检查两遍。第一遍检查错别字和断句，第二遍检查情感语气。AI 配音最怕一个字一个字蹦出来，完全没有情绪起伏，这种素材放到视频里会非常出戏。

7.2 BGM 与音效版权

BGM 和音效可以直接决定短视频的氛围感。但版权问题非常普遍，很多创作者在背景音乐上翻车。

最稳妥的方式是用素材库提供的可商用音乐，或者用 AI 音乐生成工具自制 BGM。音效方面，鸟鸣、马蹄、魔法闪现这类素材可以从可商用音效库获取。务必记录每一个音乐、音效的授权信息，尤其是准备发布到公开平台的视频。

7.3 用 FFmpeg 合成音视频

如果镜头片段和配音已经准备好，可以用 FFmpeg 做最后的合并。最简单的是把一段无声视频和一段配音合并：

# 将无声视频画面和配音合成为一个视频 ffmpeg -i video_without_audio.mp4 -i voice.mp3 \ -c:v copy -c:a aac -shortest final_video.mp4

-shortest参数表示以较短的那条音视频时长为准，可以避免画面播完了音频还在继续。

如果需要按镜头顺序拼接多个片段，先生成一个文件列表：

# 在 Linux/macOS 下创建 concat 列表文件 ls clips/*.mp4 | sed 's/^/file /' > concat_list.txt

然后执行：

# 按列表拼接所有视频片段 ffmpeg -f concat -safe 0 -i concat_list.txt -c copy merged_video.mp4

这里有两种合成方式：先把多个片段合成一个完整视频，再统一加配音；也可以先给每个片段加各自配音，再拼接。后者更容易实现“台词和画面一一对应”的效果，推荐优先使用。

7.4 字幕与导出参数

字幕是短视频的标配。剪映等剪辑工具可以自动识别语音生成字幕，使用方便。如果需要命令行批量烧录字幕，可以先生成 ASS 字幕文件，再交给 FFmpeg 处理：

# 将 ASS 字幕烧录到视频中 ffmpeg -i final_video.mp4 -vf "ass=subtitle.ass" -c:a copy with_subtitle.mp4

导出参数方面，短视频平台一般建议 H.264 编码、帧率 24 或 30、分辨率按横屏 1920x1080 或竖屏 1080x1920。码率太高会导致上传变慢，码率太低会损失画质，建议根据平台要求调整。

8. 常见问题与排查方法

AI 短视频项目里，失败是常态。下面这张表列出了实践中最高频的几类问题：

排查的基本思路是“缩小范围”。先确认问题出在剧本层、画面层、音频层还是合成层，然后再看具体工具配置。不要一上来就换模型、改参数，那样只会引入新的变量。

9. 工程化、版权与后续进阶

当你能用上面这套流程做出第一条完整视频后，下一步不是继续手动生成更多视频，而是把它工程化。

9.1 建立素材库和流水线

一个完整的 AI 短视频项目，建议按下面的目录结构管理素材：

ai_video_project/ ├── characters/ # 角色卡、角色参考图、LoRA ├── scripts/ # LLM 生成的剧本 JSON ├── prompts/ # 各类提示词模板 ├── frames/ # AI 绘制的关键帧 ├── clips/ # 图生视频生成的动态片段 ├── audio/ # TTS 配音、BGM、音效 ├── output/ # 剪辑导出的成片 └── logs/ # 每次生成的参数记录

日志文件特别重要。每次生成时，记录底模、LoRA、提示词、seed、CFG 等参数。不要相信自己的记忆，AI 生成的历史参数如果不记录，下次想复现效果就只能靠运气。

流水线层面，可以把剧本生成、图片生成、视频生成、配音分别封装成脚本，再通过一个总调度脚本串联。这样哪怕单个环节的工具换了，其他环节也不会受影响。

9.2 从 AI 小镇到多 Agent 剧情生成

如果想把剧情从“人工设定”升级为“自动演化”，可以关注 AI 小镇方向的项目。这类项目最早源自学术界对生成式智能体的研究，思路是让多个 LLM 智能体生活在同一个模拟世界里，每个智能体有独立的记忆、计划、人际关系和对话能力。它们每天按时间线睡觉、吃饭、社交、干活，整个过程自动产生大量日常剧情。

用户材料里提到过一个名为 my_ai_town 的开源仓库，地址是：https://github.com/mewamew/my_ai_town 。从项目名称和下载信息看，它属于 AI 小镇方向的实现，提供了可运行的桌面版本，支持 Mac 和 Windows 环境。如果你在制作类似“小镇日常”的角色短视频，这类项目可以作为故事引擎，自动产出角色间的互动日志，再把这些日志转化为剧本，喂给绘图和视频生成环节。不过这类项目往往还处于 Demo 阶段，工程成熟度不一，接入前需要仔细阅读仓库 README 和示例代码。

9.3 版权与合规提醒

如果你准备做“奇妙萌可”这类已有动漫 IP 的短视频，一定要先确认是否存在版权授权问题。动漫角色的形象、名称、世界观都受到版权保护。个人热爱是好事，但如果要公开传播甚至商业化，必须尊重原 IP 的授权规则。

更稳妥的做法是参考“奇妙萌可”的萌系风格，设计一个原创角色。你可以用同一个角色卡模板，把外貌、性格、世界观全部改成原创内容。这样既能跑通整套技术流程，又不需要承担版权风险。

AI 生成内容还涉及平台内容规则。不同短视频平台对 AI 生成内容的标识要求不一样，有些平台要求标注“AI 生成”，有些平台对特定题材有审核限制。建议在发布前仔细阅读目标平台的创作者规则。

9.4 发布与迭代建议

内容创作的验证逻辑是“小步快跑”。不要一开始就试图做一条 3 分钟的长片，而是先做一条 15 秒到 30 秒的片段，发布后看数据反馈。如果角色形象、故事节奏、配音风格都被认可，再扩大成系列。

每次发布后，记录播放量、完播率、评论关键词。这些数据会反过来指导下一轮内容创作。哪类镜头观众喜欢，就多保留；哪类剧情观众看不懂，就简化。AI 短视频的优势就在于此：生产速度快，验证成本低，可以快速试错。

把第一个 15 秒片段完整跑通，比你研究一百篇 AI 视频教程都有用。当你把角色卡、参考图、分镜脚本、配音和剪辑这五个环节串成一条稳定管道之后，会发现 AI 短视频本质上是在管理一致性和概率。下一步，试着做一个属于你自己的“萌可”，把这个流程真正变成