企业官网建设流程全解析

简介：一份围绕《只字不提》MV制作的PDF实操文档，面向希望把DeepSeek、豆包、即梦与剪映接入音乐视频流程的创作者和剪辑爱好者，重点解决歌词画面设计、AI素材生成与后期整合之间如何衔接的问题。压缩包仅含1个PDF文件，约3.98MB，便于在电脑或移动端阅读与对照练习。内容提供完整制作链路、可直接复用的提示词框架、按歌词情感拆分的画面描述示例，以及即梦生图与生视频的比例选择、超清处理和抽卡筛选思路，并附剪映转场、音乐与歌词字幕的编排参考。已有1550人学习，适合想理解多工具协作边界、提升素材产出效率的初中级创作者借鉴。

1. 一整套 AI 音乐视频制作流程，核心其实是“补素材”

一首三分钟左右的抒情歌，歌词拆下来四十多句，一句配一个画面就是四十多个镜头。传统做法要么翻素材库翻到眼花，要么扛设备出去拍空镜，成本先不说，光是“画面和歌词对不上”这一条就能把人耗死。DeepSeek、豆包、即梦、剪映这四件工具串起来，解决的正是这个最脏最累的环节：DeepSeek 和豆包把歌词翻译成能画的画面描述，即梦把描述渲染成图和短视频片段，剪映把几十个片段按节拍缝成一条能看的片子。

这套流程最适合两类人：一类是做自媒体、需要稳定周更但预算为零的独立创作者，另一类是想验证“AI 生成素材到底能不能商用级交付”的从业者。它不适合追求电影级运镜和真人表演的项目，也不适合一句歌词想磨三天的完美主义者。下面按我实际跑通的顺序拆：提示词怎么造、图怎么出、视频怎么抽、剪辑怎么收。

2. 歌词到画面描述：DeepSeek 出骨架、豆包填血肉

2.1 为什么一步到位必然翻车：长歌词的两道翻译

把整首歌词一次性丢给任何一个模型，让它“生成 MV 分镜”，出来的东西基本没法用。原因不在模型笨，而在于这一步实际包含两次翻译：第一次是把情绪化的歌词翻译成“可拍摄的事件”，第二次是把事件翻译成“生图模型能理解的视觉描述”。两次翻译挤在一次对话里，模型会偷懒——它会把“岁月流逝”直接写成“时间流逝的画面”，这种描述丢进即梦，出来的就是一坨抽象光效。

我的做法是拆开：DeepSeek 负责第一次翻译，它长文本结构能力强，适合把四十多句歌词切成画面单元、标注情绪锚点、检查前后逻辑；豆包负责第二次翻译，它在中英文视觉词汇的“具象化”上更顺手，能把“淡然与坚守”换成“暮色里花苞紧闭、枝干斜伸、影子随光线变浓”这类能渲染的东西。两边来回改两三轮，提示词质量会有明显台阶。

这里有个判断标准值得记住：一条合格的画面描述，应该能让一个没听过这首歌的摄影师照着拍出来。做不到，就说明还停在情绪层面。

2.2 四字段骨架：画面、动态、镜头、情感锚点

原始流程里给的是“画面 / 动态 / 情感”三段式，实际跑下来我加了第四个字段“镜头”，因为即梦的图生视频对景别和运镜是敏感的，你不写，它默认给一个中景缓推，四十个镜头全一个味道。四字段的骨架长这样：

情感锚点这一栏最容易被人省掉，但它是后面剪辑时的救命稻草。四十多条提示词铺开之后，你根本记不住第 27 条是为哪句词服务的，锚点就是索引。

2.3 把输出压成机器可读的结构

手工复制粘贴四十多条提示词，出错率极高。我一般让 DeepSeek 直接吐 JSON 数组，再用脚本做格式校验和批量改写。切句这一步也别交给模型，用正则按标点断更可控：

# build_prompts.py # 作用：按标点把歌词切成画面单元，套四字段模板，输出可直接粘贴的 JSON import re, json RAW_LYRICS = """ （歌词原文粘进来，一行一句或整段都行） """ STYLE_TAIL = "写实摄影风格，暖调低饱和，浅景深，胶片颗粒，画面干净无文字" def split_lines(raw: str): # 中文标点断句；过短的碎片（<4 字）丢掉，避免出现"啊""哦"这种空镜 parts = re.split(r"[，。！？、；\n]", raw) return [p.strip() for p in parts if len(p.strip()) >= 4] def build(line: str, idx: int): return { "id": f"shot_{idx:02d}", "lyric": line, # 以下三个字段先留占位，由 DeepSeek/豆包逐条填写后再回填 "scene": "", "motion": "", "shot": "中景，固定机位", "emotion": f"对应歌词“{line}”", "style": STYLE_TAIL, } lines = split_lines(RAW_LYRICS) shots = [build(l, i + 1) for i, l in enumerate(lines)] with open("shots.json", "w", encoding="utf-8") as f: json.dump(shots, f, ensure_ascii=False, indent=2) print(f"共切出 {len(shots)} 个画面单元")

这段脚本做三件事：断句、编号、留空字段。STYLE_TAIL是全局风格尾巴，每条提示词都带上，这是后面保证四十张图“像同一部片子”的最便宜手段。shot默认给固定机位，是因为默认值一旦是“推拉摇移”，模型就会自由发挥。跑完之后把shots.json丢给 DeepSeek，让它只填scene和motion两栏，一次填十条，填完人工扫一遍，比让它一口气生成四十条稳定得多。

2.4 单条提示词的自检：三条硬指标

填完之后别急着导进即梦，先过三道筛子。第一条，单条长度控制在 100 字以内，超过 120 字模型会开始丢字段，写了半天“镜头”它当没看见；第二条，主体名词必须唯一，一条提示词里出现“花苞、花瓣、落叶、雪”四个主体，出图必然是拼贴感；第三条，动态描述必须能被一帧画面承载，写“从含苞到盛开”这种跨时间的描述，图生视频会给你一个诡异的变形过程。

我习惯在脚本里加个校验：

# check_prompts.py import json with open("shots.json", encoding="utf-8") as f: shots = json.load(f) bad = [] for s in shots: text = s["scene"] + s["motion"] if len(text) > 120: bad.append((s["id"], "超长", len(text))) if not s["scene"] or not s["motion"]: bad.append((s["id"], "缺字段", 0)) if text.count("，") < 2: bad.append((s["id"], "描述过简", 0)) for b in bad: print(b) print(f"待修 {len(bad)} 条 / 共 {len(shots)} 条")

校验逻辑很朴素，但能拦住八成低级错误。阈值 120 是实测出来的，不同模型对长度的敏感度不一样，偏保守一点没坏处。

3. 即梦出图：16:9、2.0 Pro 与“先锚点后批量”

3.1 模型与比例的选择理由

生图这一步有两个参数先定死。比例选 16:9，因为最终成片是横屏，用 1:1 或 9:16 出图再裁，构图会被拦腰砍断，尤其是“花苞在画面右侧、留白给字幕”这种设计，裁完就废了。模型选图片 2.0 Pro，理由是它对中文提示词里“光线方向 + 材质细节”的响应比基础模型稳，同一段描述连续生成几张，风格漂移更小——这对需要四十张图保持统一的项目是刚需。

真正的坑不在参数，而在顺序。很多人拿到四十条提示词，直接开批量，出了几十张风格各异的图再想办法统一，这时候只能靠后期调色硬拉，效果很勉强。正确顺序是“先出一张锚点图，再以它为准批量”。

3.2 锚点图：用第一张图给全片定调

挑情绪最完整、主体最明确的那一条——原文里的画面 1“破晓微光中的期待”就很合适。单独生成，反复抽到满意为止，这张图定义了整部片子的色温、对比、颗粒感和景深。定下来之后的动作是：把这张图作为参考图垫进后续每一次生成，同时在提示词尾巴上把STYLE_TAIL调整为对这张图的文字化描述，比如“暖调、低饱和、青灰阴影、胶片颗粒”。

参考图强度别开满格。开满会得到一个复读机，四十张图全是同一朵花的不同角度；开到中档偏上，画面主体跟着提示词走，色调和质感跟着参考图走，这个平衡点需要试两三张找到。这是玄学成分比较重的一步，我一般会固定一组参数跑五张，对比后再决定，而不是每张都换参数。

3.3 超清处理的时机：别在出图阶段就上

超清应该放在“图选定之后”，不是“每张都超清”。逻辑很简单：四十条提示词每条可能出四五张候选，全量超清等于把算力和时间砸在废片上。我的流程是先出普通分辨率，人工筛选，把入选的十几二十张单独做超清。筛选标准里有一条容易被忽略——看主体边缘有没有糊。超清能把细节拉回来，但救不回被生成阶段就糊掉的轮廓，尤其是花瓣边缘和露珠这种高频细节。

另外提醒一句，带角标的图不要想着靠裁切解决。裁掉角标意味着重新构图，本来算好的三分法、留白位全部作废，剪映里再加速裁关键帧，出来的画面是抖的。这属于血泪经验，省那点成本最后都要用返工时间还回去。

3.4 文件命名与对照表：为图生视频铺路

从即梦下载下来的文件名基本是乱码，四十张图堆在一个文件夹里，根本分不清哪张对应哪句词。必须在出图当天就把映射关系坐实，否则三天后回头做视频，只能一张张重新看，效率直接崩。

# rename_shots.py # 把即梦下载的图，按 shot 编号 + 歌词关键词 重命名，并输出对照表 import os, json, shutil, csv SRC = "./jimeng_download" # 下载目录 DST = "./images_named" # 重命名后目录 with open("shots.json", encoding="utf-8") as f: shots = json.load(f) os.makedirs(DST, exist_ok=True) files = sorted(os.listdir(SRC)) # 按下载顺序排，和生成顺序一一对应 rows = [] for shot, fn in zip(shots, files): ext = os.path.splitext(fn)[1] key = shot["lyric"][:6].replace("/", "") # 取歌词前 6 字做可读后缀 new = f'{shot["id"]}_{key}{ext}' shutil.copy(os.path.join(SRC, fn), os.path.join(DST, new)) rows.append([shot["id"], shot["lyric"], new]) with open("shot_map.csv", "w", newline="", encoding="utf-8-sig") as f: csv.writer(f).writerows([["id", "lyric", "file"], *rows])

zip的前提是下载顺序等于生成顺序，实际下载常常乱序，所以第一次跑完必须对着shot_map.csv抽检十张，确认图和词对得上。对不上就改成按修改时间排序，或者干脆逐张手动命名——前期十分钟的手工，换后面两小时的返工，很划算。utf-8-sig是为了表格在常见办公软件里打开不乱码。

4. 图生视频：抽卡、运镜与时间轴对齐

4.1 抽卡的期望值管理：十条留三条

图生视频这一步没有任何“一次成”的可能，本质是分布采样，你给的是概率描述，模型返回的是概率结果。我统计过自己这一轮的经验值：十条里能直接用的三条左右，三条里能进最终成片的两条。所以规划素材量的时候，直接按需求量的三倍去准备候选，别按 1:1 规划，否则剪到一半发现素材荒，进度直接卡死。

抽卡成本要控制，方法是缩小单次生成的数量、增大迭代次数。一次只出少量候选，看方向对不对，不对就改提示词里的动态描述，而不是靠反复重抽碰运气。重抽是在赌，改词是在调参，后者积累下来的经验下次还能用。

4.2 运镜词写法：小幅度、单方向、有主体

图生视频的提示词比生图更挑，因为它多了时间维度。三条经验：第一，幅度要小，“缓慢推近”比“快速推近”稳，推快了主体会糊成一片；第二，一条只写一个方向，写“先推再摇”模型会给你一段晕眩的摇摆；第三，明确谁在动，“花瓣随微风轻颤”比“画面有动态感”强一百倍。

镜头语言最好和情绪对上。原文里“暮色中的坚守”那一条，情绪是静的，镜头就该固定或极缓慢拉远；而“冷雨洗礼下的坚韧”，可以让雨滴在画面前景快速划过、主体保持静止，动静对比出来的张力比运镜本身强。这套对应关系没有标准答案，但把“情绪→镜头”列成一张小表贴在旁边，比每次凭感觉强。

4.3 片段时长与歌词句的对齐

生成的片段时长通常固定，而歌词每句的长短差很多，硬拼必然出现“画面还没动完就切走”或者“画面停住等下一句”。解决办法是在剪辑前先做一张时间规划表：

这张表是拿来反推素材需求的：四十句歌词，实际需要的片段数可能到六十个，再加上间奏空镜，七十个起步。前面说按三倍准备候选，算的就是这个数。

4.4 进剪映前的统一化处理

即梦导出的片段分辨率、帧率、有无音轨都不统一，直接拖进剪映会出两类问题：帧率不一致导致播放卡顿，自带音轨和背景音乐打架。进剪辑前统一跑一遍：

# normalize_clips.sh # 统一到 1920x1080 / 30fps / 无音轨，等比缩放后补黑边，不裁切不拉伸 mkdir -p clips_std for f in ./clips_raw/*.mp4; do name=$(basename "$f" .mp4) ffmpeg -y -i "$f" \ -an \ -vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,fps=30" \ -c:v libx264 -crf 18 -pix_fmt yuv420p \ "./clips_std/${name}.mp4" done

-an去掉原音轨，音频统一在剪映里贴；force_original_aspect_ratio=decrease保证等比缩放不拉伸变形，pad把不足的部分补黑边，黑边后期可以用剪映的缩放裁掉；fps=30统一帧率，这是解决卡顿的关键；-crf 18是质量参数，数值越小质量越高体积越大，18 属于肉眼无损区间的上限，再往下降体积涨得比画质快。这套处理会损失一点点边缘像素，但换来的是整条时间轴拖动不卡。

5. 避坑：这条链路上五个最容易翻车的地方

5.1 素材侧：画面重复、主体漂移、角标裁切

现象一：剪到后半段发现素材不够，画面开始重复。原因是最初按“一句一个画面”规划，忽略了长句需要拆镜头、间奏需要空镜。解决方式是在提示词阶段就把长句标出来，一条歌词拆两个描述，宁可多出二十条闲置，也不要剪到一半停下来补。

现象二：同一个主体在不同镜头里长得不一样。腊梅在第五张里是嫩黄花瓣，第十二张变成了深红。原因是提示词里的主体描述不固定，每次都在换形容词。解决办法是把主体描述抽出来做成固定短语，每条提示词原样粘贴，只改环境和光线。参考图能缓解，但治不了根，根在文字描述的不一致。

现象三：为了去角标去裁切，结果构图全毁。现象很明显，画面要么主体被切掉一半，要么四周出现明显抖动。原因就是裁切改变了原本设计的视觉重心。解决方式是出片阶段就用无水印的成品图，或者接受角标存在、在版式上把它压到画面之外的遮罩区——后一种只适合角标位置固定的情况。

5.2 剪辑侧：帧率打架与字幕断句

现象四：时间轴上单条片段播放正常，连起来就卡顿、音画不同步。原因是素材帧率混杂，常见的是 24fps 和 30fps 混着用，剪映预览时会做实时补偿，但补偿是有代价的。解决方式是进剪辑前统一转码，按 4.4 那套跑一遍，并且工程帧率设置为与素材一致，别用默认值。

现象五：字幕和歌词对不上，或者断句断在奇怪的位置。原因有两层，一层是自动识别歌词的断句逻辑按语义走，不按乐句走；另一层是歌词里有生僻字被识别错。解决方式是先拿到准确的时间轴（有官方歌词文件最好），再在剪映里逐句校对，重点盯每句的尾字和拖腔位置。四十句歌词全对一遍大概二十分钟，比成片发出去被人指出错别字强。

还有一条不属于翻车但影响很大的：转场滥用。四十个镜头如果每个之间都加转场，观众看到的是特效展示而不是 MV。我一般只在段落切换（主歌进副歌、间奏进出）用三到五个转场，句与句之间用硬切，情绪连贯性反而更好。

6. 最后一公里：字幕批量、转场克制与模板固化

剪映这一段真正费时的不是剪辑，是字幕。四十多句歌词，手动打字加对时间轴，两个小时起步，而且极容易错位。我的做法是先在外部把歌词整理成“一句一行、无标点、无空行”的纯文本，用剪映的歌词识别功能导入生成时间轴，再逐句校三处：句首第一个字是否被吃掉、句尾拖腔是否提前收、长句是否被拆成两行。校对时把播放速度调到 0.75 倍，错位会非常明显。

版式上有个取巧的做法：全片只保留一套字幕样式，字号、描边、位置一次设好，用“应用到所有字幕”批量刷。想要变化，就在副歌段落单独换颜色或加一点点淡入，别每条都调，调到最后你自己都记不清哪条是什么样式。

导出参数按平台走，横屏 1080p、30fps、码率中高即可，别为了“更清晰”导出 4K，源素材本身是生成图放大的，多出来的像素没有信息量，只增加上传时间和转码失败概率。

流程跑顺之后，我把每一轮用到的提示词模板、校验脚本、转码脚本、字幕样式都收进一个文件夹，下次换一首歌，只改歌词和主体描述就能复用。从那以后我每次开新项目，都强制先跑一遍这套模板而不是凭手感重来——因为凭手感重来的结果，往往是做到第三十句才发现风格跑偏，那时候已经没救了。希望帮到你。

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