简介一份围绕《只字不提》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: fshot_{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, encodingutf-8) as f: json.dump(shots, f, ensure_asciiFalse, indent2) 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, encodingutf-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, encodingutf-8) as f: shots json.load(f) os.makedirs(DST, exist_okTrue) 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, encodingutf-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-6 字2-3 秒1单片段不做变速常规句7-10 字3-5 秒1单片段头尾各留 0.2 秒余量长句 拖腔6-10 秒2拆成两段不同景别避免观众盯一个画面太久间奏 / 前奏8 秒以上3-5用空镜和环境音节奏可以慢下来这张表是拿来反推素材需求的四十句歌词实际需要的片段数可能到六十个再加上间奏空镜七十个起步。前面说按三倍准备候选算的就是这个数。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 scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2,fps30 \ -c:v libx264 -crf 18 -pix_fmt yuv420p \ ./clips_std/${name}.mp4 done-an去掉原音轨音频统一在剪映里贴force_original_aspect_ratiodecrease保证等比缩放不拉伸变形pad把不足的部分补黑边黑边后期可以用剪映的缩放裁掉fps30统一帧率这是解决卡顿的关键-crf 18是质量参数数值越小质量越高体积越大18 属于肉眼无损区间的上限再往下降体积涨得比画质快。这套处理会损失一点点边缘像素但换来的是整条时间轴拖动不卡。5. 避坑这条链路上五个最容易翻车的地方5.1 素材侧画面重复、主体漂移、角标裁切现象一剪到后半段发现素材不够画面开始重复。原因是最初按“一句一个画面”规划忽略了长句需要拆镜头、间奏需要空镜。解决方式是在提示词阶段就把长句标出来一条歌词拆两个描述宁可多出二十条闲置也不要剪到一半停下来补。现象二同一个主体在不同镜头里长得不一样。腊梅在第五张里是嫩黄花瓣第十二张变成了深红。原因是提示词里的主体描述不固定每次都在换形容词。解决办法是把主体描述抽出来做成固定短语每条提示词原样粘贴只改环境和光线。参考图能缓解但治不了根根在文字描述的不一致。现象三为了去角标去裁切结果构图全毁。现象很明显画面要么主体被切掉一半要么四周出现明显抖动。原因就是裁切改变了原本设计的视觉重心。解决方式是出片阶段就用无水印的成品图或者接受角标存在、在版式上把它压到画面之外的遮罩区——后一种只适合角标位置固定的情况。5.2 剪辑侧帧率打架与字幕断句现象四时间轴上单条片段播放正常连起来就卡顿、音画不同步。原因是素材帧率混杂常见的是 24fps 和 30fps 混着用剪映预览时会做实时补偿但补偿是有代价的。解决方式是进剪辑前统一转码按 4.4 那套跑一遍并且工程帧率设置为与素材一致别用默认值。现象五字幕和歌词对不上或者断句断在奇怪的位置。原因有两层一层是自动识别歌词的断句逻辑按语义走不按乐句走另一层是歌词里有生僻字被识别错。解决方式是先拿到准确的时间轴有官方歌词文件最好再在剪映里逐句校对重点盯每句的尾字和拖腔位置。四十句歌词全对一遍大概二十分钟比成片发出去被人指出错别字强。还有一条不属于翻车但影响很大的转场滥用。四十个镜头如果每个之间都加转场观众看到的是特效展示而不是 MV。我一般只在段落切换主歌进副歌、间奏进出用三到五个转场句与句之间用硬切情绪连贯性反而更好。6. 最后一公里字幕批量、转场克制与模板固化剪映这一段真正费时的不是剪辑是字幕。四十多句歌词手动打字加对时间轴两个小时起步而且极容易错位。我的做法是先在外部把歌词整理成“一句一行、无标点、无空行”的纯文本用剪映的歌词识别功能导入生成时间轴再逐句校三处句首第一个字是否被吃掉、句尾拖腔是否提前收、长句是否被拆成两行。校对时把播放速度调到 0.75 倍错位会非常明显。版式上有个取巧的做法全片只保留一套字幕样式字号、描边、位置一次设好用“应用到所有字幕”批量刷。想要变化就在副歌段落单独换颜色或加一点点淡入别每条都调调到最后你自己都记不清哪条是什么样式。导出参数按平台走横屏 1080p、30fps、码率中高即可别为了“更清晰”导出 4K源素材本身是生成图放大的多出来的像素没有信息量只增加上传时间和转码失败概率。流程跑顺之后我把每一轮用到的提示词模板、校验脚本、转码脚本、字幕样式都收进一个文件夹下次换一首歌只改歌词和主体描述就能复用。从那以后我每次开新项目都强制先跑一遍这套模板而不是凭手感重来——因为凭手感重来的结果往往是做到第三十句才发现风格跑偏那时候已经没救了。希望帮到你。本文还有配套的精品资源点击获取