1. 从一句诗到一条视频这个项目到底在做什么先说说我为什么盯上这个方向。去年年底我帮一个做国学内容的朋友处理批量短视频他手头有三百多首原创诗词想做成带画面、带配音、带字幕的短视频发到内容平台。人工做一条大概要四十分钟三百首就是两百个小时这活儿根本没法接。当时我第一反应就是能不能用 AI Agent 把这条链路串起来让机器自己写诗、自己配图、自己合成视频。折腾了两周踩了不少坑最后跑通了一套还算稳定的流程也就是今天要拆解的这套“扣子 AI Agent 生成 AI 诗词视频”方案。这套东西说白了就是三件事的串联用大模型生成诗词文本用 AI Agent 编排整个工作流用剪映把素材合成成片。听起来简单但真正落地的时候你会发现难点根本不在“能不能生成”而在“怎么让每一步的输出都能被下一步稳定接住”。大模型写诗会跑偏配图会跟诗意不搭配音的节奏跟画面时长对不上剪映的批量导入又有一堆格式要求。这些细节才是决定这套流程能不能真正跑起来的关键。适合谁来参考这套方案我把它分成三类人。第一类是内容创作者尤其是做国学、情感、文化类账号的手里有大量文本素材需要视频化第二类是刚接触 AI Agent 想找个完整项目练手的开发者这套流程涉及大模型调用、工作流编排、API 对接、文件处理是个不错的综合练习第三类是做自动化工具的产品或运营想看看 Agent 在实际业务场景里到底能承担多少工作量。不管你属于哪一类只要跟着走一遍应该都能拿到一条能用的诗词视频。我先把整体架构摆出来让你有个全局印象。整个流程分四段诗词生成段负责用大模型产出符合格律和主题的诗词文本素材准备段负责根据诗词意境生成或匹配画面素材、配音音频、字幕文件编排调度段是扣子工作流的核心负责把前面两段的输出按顺序串起来处理异常和重试视频合成段用剪映的批量处理能力把素材拼成最终视频。四段之间通过结构化的数据格式传递每一段都有明确的输入输出契约这样任何一段出问题都不会把整条链路带崩。提示这套流程的核心思路是“分段解耦、契约传递”。不要试图让一个大模型调用干完所有事那样一旦出错你根本不知道是哪一步的问题。2. 为什么选扣子加剪映这套组合2.1 大模型选型写诗这件事到底该用哪个模型写诗跟写普通文案不一样它对模型的中文语感和格律理解要求很高。我实测下来通用大模型里表现比较稳的是 DeepSeek 和通义千问这两个系列。DeepSeek 的优势在于中文古文的语料覆盖比较扎实写出来的七绝、五律在平仄和对仗上基本能看通义千问的优势是响应速度快适合批量生成场景。如果你追求更高的诗词质量可以考虑用微调过的专用模型但那个成本就上去了对于批量生产短视频来说性价比不高。这里要澄清一个常见困惑Agent、LLM、AI 模型到底什么关系。LLM 就是大语言模型是底层能力比如 DeepSeek 就是一个 LLMAI 模型是个更大的概念包含 LLM、图像模型、语音模型等Agent 则是建立在这些模型之上的“调度者”它自己不产生内容而是决定什么时候调用哪个模型、怎么处理模型的输出。扣子就是一个 Agent 编排平台你可以在上面把 LLM、图像生成、语音合成这些能力串成一条流水线。我在选型时对比过几个方案。直接用 API 写脚本调用大模型最灵活但异常处理、重试、日志这些都要自己写用 Dify 工作流也可以它的可视化编排做得不错但对接国内模型的便利性稍差扣子的优势在于它本身就是国内生态对接 DeepSeek、通义、豆包这些模型很顺而且工作流的节点类型丰富处理文件、调用 HTTP 接口、做条件判断都有现成的节点。对于这个项目来说扣子的“够用且省事”是我最终选它的原因。2.2 剪映的角色为什么不用纯代码合成视频很多人第一反应是用 FFmpeg 或者 MoviePy 直接代码合成视频为什么要绕一道剪映我一开始也是这么想的直到我实际对比了两种方案的效果。纯代码合成的优势是自动化程度高、无需人工干预但劣势也很明显转场效果、字幕样式、背景音乐淡入淡出这些细节代码实现起来非常繁琐而且做出来的视频“机器感”很重观众一眼就能看出来是批量生产的。剪映的批量处理能力在这里就体现出价值了。你可以先在剪映里做好一个模板把诗词文本、图片、音频、字幕的位置和样式都定好然后用剪映的“批量替换”功能或者通过草稿文件的方式批量生成。剪映 5.9 和 6.0 版本对批量处理的支持比较好而且免安装版本在 Windows 上跑起来很方便。如果你在 Linux 环境下工作剪映 Linux 版的稳定性稍差一些建议还是在 Windows 或 Mac 上做最终的合成环节。注意剪映的版本选择很关键。我实测 5.9 和 6.0 这两个版本在批量导入素材时最稳定9.7 版本虽然功能多但免会员限制比较麻烦做批量生产反而容易卡在导出环节。2.3 扣子工作流的核心节点设计扣子工作流是整个方案的“中枢神经”。我把它拆成六个核心节点每个节点负责一件事节点之间用变量传递数据。第一个节点是输入接收接收诗词主题、风格、数量这些参数第二个节点是诗词生成调用大模型 API 产出诗词文本第三个节点是文本解析把大模型返回的文本拆成标题、正文、注释三部分第四个节点是素材生成根据诗词内容调用图像生成模型和语音合成模型第五个节点是文件整理把生成的素材按固定命名规则存到指定目录第六个节点是输出汇总把素材清单和诗词文本打包成一个结构化数据供剪映环节读取。这六个节点的设计逻辑是“单一职责”。每个节点只做一件事做完了就把结果传给下一个。这样做的好处是排查问题特别方便——如果最终视频里诗词不对你只需要检查第二个节点如果画面跟诗意不搭检查第四个节点就行。我见过很多人把三四个功能塞进一个节点里结果一出错就要从头调试效率极低。3. 诗词生成环节的实操细节3.1 提示词怎么写才能让大模型稳定输出提示词是这个环节最核心的东西。我试过几十版提示词最后稳定下来的结构是这样的角色设定 格式要求 内容约束 示例参考。角色设定让模型进入“古典诗人”的状态格式要求明确告诉它输出几言、几句、要不要标题内容约束限定主题范围和禁用词汇示例参考给一两个样例让它模仿风格。具体来说我用的提示词模板大致是这样的你是一位精通古典诗词的创作者擅长七言绝句和五言律诗。 请根据以下主题创作一首诗 主题{theme} 风格{style} 要求 1. 如果是七绝四句每句七字押平水韵 2. 如果是五律八句每句五字中间两联需要对仗 3. 输出格式为 标题xxx 正文xxx 注释xxx用一句话解释诗意 参考示例 标题秋思 正文秋风起处叶纷飞独倚栏杆望落晖。欲寄相思无雁过空留明月照人归。 注释借秋景抒发思乡之情。这个模板的关键在于输出格式的强约束。如果你不规定格式大模型有时候会输出一大段解释文字有时候会加一堆 Markdown 标记后续解析起来很麻烦。规定了“标题、正文、注释”三段式之后解析节点就可以用简单的字符串分割来处理。3.2 批量生成时的参数控制批量生成诗词的时候有几个参数需要特别注意。温度值temperature建议设在 0.7 到 0.9 之间太低会让每首诗都很像太高又容易跑偏出律。最大生成长度设 200 到 300 个 token 就够了诗词本身很短设太大反而会让模型在结尾加废话。重试次数建议设 2 到 3 次因为大模型偶尔会输出格式不对的内容重试一次基本就能拿到合格结果。我在实际跑批量的时候还发现一个问题同一主题连续生成多首时后面的诗会跟前面的越来越像。这是因为模型在同一个对话上下文里会倾向于保持一致性。解决办法是每生成一首就重置一次对话上下文或者在提示词里加入随机种子。扣子工作流里可以通过在每次循环时传入不同的随机数来解决这个问题。实操心得批量生成时建议先跑 5 首做质量抽检确认格式和内容都合格了再跑全量。我吃过一次亏一次性跑了 200 首结果发现提示词里有个标点符号写错了导致所有输出都多了一行乱码全部返工。3.3 输出解析与异常处理大模型的输出不可能 100% 符合格式要求所以解析节点必须做异常处理。我的做法是先用正则表达式匹配“标题”“正文”“注释”这三个标记如果匹配成功就正常提取如果匹配失败就把整段文本当作正文标题用主题代替注释留空。这样即使模型输出格式有问题流程也不会中断只是那一条的质量会差一些。解析完之后还要做一次长度校验。七绝的正文应该是 28 个字不含标点五律是 40 个字。如果解析出来的正文长度偏差超过 20%就标记为“需人工复核”不进入后续流程。这个校验能过滤掉大部分格式异常的输出保证进入视频合成环节的诗词质量。4. 素材生成与剪映合成的完整链路4.1 画面素材的生成策略诗词视频的画面素材有两种来源AI 生成和素材库匹配。AI 生成用图像模型根据诗词意境出图优势是画面跟诗意高度契合劣势是生成速度慢、成本高而且风格一致性难保证。素材库匹配是从预先准备好的图片库里按关键词检索优势是快、免费、风格统一劣势是可能找不到完全贴合的图。我的做法是混合使用对于重点诗词用 AI 生成保证画面质量对于批量生产的诗词用素材库匹配保证效率。素材库我建议按“春夏秋冬、山水、花鸟、人物、建筑”这几个大类来组织每类下面再按色调分冷暖两套。这样匹配的时候可以根据诗词的季节和情感色彩快速定位。AI 生成画面时提示词的写法跟诗词提示词完全不同。图像模型需要的是具体的视觉描述而不是抽象的情感表达。比如“秋风起处叶纷飞”这句诗直接拿去生成图像效果很差要改写成“秋天的树林金黄色的落叶在空中飞舞夕阳透过树枝洒下斑驳光影中国水墨画风格”。这个改写过程可以再调用一次大模型来完成让大模型把诗句翻译成图像提示词。4.2 配音与字幕的处理配音我用的是语音合成模型选的是偏古风的音色。这里有个细节语速要调慢。诗词的节奏跟日常说话不一样正常语速读出来会显得很赶把语速降到 0.8 倍左右再在句号处加长停顿听起来就有韵味了。扣子的语音合成节点支持调节语速和停顿参数具体在节点配置里找“语速”和“句间停顿”这两个选项。字幕的处理有个坑要特别注意字幕的时间轴必须跟音频对齐。如果音频是 15 秒字幕就不能按固定间隔切分而要根据音频的实际波形来定位每个字的出现时间。我的做法是先用语音合成生成音频同时拿到每个字的起止时间戳然后按诗句的断句把时间戳分组每组对应一句字幕。这样字幕出现和消失的时机就跟朗读完全同步了。4.3 剪映批量合成的操作步骤剪映这一环是整个流程里最“手工”的部分因为剪映本身没有提供完善的 API 来做批量合成。我的做法是用草稿文件批量生成。具体步骤是这样的先在剪映里手动做一条完整的诗词视频把画面、音频、字幕、背景音乐、转场都调好保存为草稿。找到剪映的草稿文件目录Windows 一般在C:\Users\用户名\AppData\Local\JianyingPro\User Data\Projects\com.lveditor.draft把草稿文件复制出来。分析草稿文件的 JSON 结构找到画面路径、音频路径、字幕文本、时间轴这些字段的位置。写一个脚本读取扣子工作流输出的素材清单批量替换草稿文件里的对应字段生成新的草稿文件。把新草稿文件放回剪映的草稿目录打开剪映就能看到批量生成的草稿逐条导出即可。这个方法的好处是保留了剪映所有的视觉效果你手动调好的转场、滤镜、字幕样式都会原样保留。坏处是草稿文件的 JSON 结构比较复杂第一次分析需要花点时间。我建议先用一条最简单的视频做实验把 JSON 结构摸清楚了再批量操作。注意剪映草稿文件的版本兼容性是个大坑。不同版本的剪映草稿格式不一样5.9 的草稿文件在 6.0 里可能打不开。所以整个流程里剪映的版本要固定不要随意升级。4.4 素材命名与目录规范批量处理最容易出问题的地方就是文件命名混乱。我的规范是这样的每首诗词分配一个唯一 ID比如poem_001然后所有相关素材都用这个 ID 做前缀。画面素材叫poem_001_bg_01.jpg、poem_001_bg_02.jpg音频叫poem_001_audio.mp3字幕叫poem_001_subtitle.srt最终视频叫poem_001_final.mp4。所有素材放在以 ID 命名的子目录里比如output/poem_001/。这个规范看起来简单但能省掉大量麻烦。我在早期没做规范的时候素材文件混在一起经常出现 A 诗词的画面配到 B 诗词上的情况排查起来非常痛苦。有了 ID 前缀之后任何素材都能一眼看出属于哪首诗词批量替换的时候也不会搞混。5. 常见问题与排查技巧实录5.1 大模型输出格式不稳定的排查这是最高频的问题。表现是大模型返回的文本里“标题”“正文”“注释”这三个标记有时候用中文冒号有时候用英文冒号有时候干脆不写标记直接输出内容。排查思路是先看原始输出再看解析逻辑。在扣子工作流里把大模型节点的输出直接打印出来看看实际返回的是什么格式然后调整解析节点的正则表达式来兼容多种情况。我的经验是正则表达式要写得“宽容”一些。比如匹配标题的时候用标题[:]\s*(.)这样的模式中英文冒号都能匹配冒号后面的空格可有可无。正文的匹配要考虑到模型可能在句号后换行所以用[\s\S]来匹配多行内容。注释部分如果匹配不到就设为空字符串不要让整个解析失败。5.2 画面与诗意不匹配的调整方法这个问题通常出在图像提示词的转换环节。大模型把诗句翻译成图像提示词的时候有时候会抓错重点。比如“空留明月照人归”这句重点应该是“明月”和“人归”但模型可能把重点放在“空”字上生成一张空旷荒凉的图。解决办法是在转换提示词的时候明确告诉模型要提取哪些意象。我用的转换提示词是这样的请把以下诗句转换成图像生成提示词。 要求 1. 提取诗句中的核心意象人物、景物、动作 2. 描述画面的构图、色调、风格 3. 输出格式主体 环境 光线 风格 4. 不要加入诗句中没有的元素 诗句{poem}这样约束之后生成的图像提示词就准确多了。如果还是不满意可以在提示词里加一句“画面要明亮温暖”或者“画面要清冷孤寂”来调整情感基调。5.3 剪映批量导入失败的常见原因剪映批量导入草稿失败我遇到过三种原因。第一种是草稿文件路径不对剪映找不到素材文件。这个要在草稿 JSON 里把素材路径改成绝对路径或者把素材放到剪映默认的素材目录里。第二种是JSON 格式错误批量替换字段的时候不小心破坏了 JSON 结构。这个用 JSON 校验工具检查一下就能发现。第三种是剪映版本不匹配前面提过了固定版本就好。排查的时候建议先手动导入一条草稿测试确认单条能正常工作之后再批量操作。如果单条都失败那就是草稿文件本身的问题如果单条成功但批量失败那就是批量脚本的问题。这个二分法能帮你快速定位问题范围。5.4 常见问题速查表问题现象可能原因排查方法解决方案诗词格式错乱提示词约束不够打印原始输出加强格式约束增加重试画面与诗意不搭图像提示词转换偏差检查转换后的提示词优化转换提示词明确意象字幕与音频不同步时间轴未对齐对比音频波形和字幕时间用字级时间戳重新分组剪映导入失败路径或版本问题先测单条再测批量固定版本用绝对路径批量生成内容雷同上下文未重置对比多首输出每首重置上下文或加随机种子视频导出卡顿素材分辨率过高检查素材尺寸统一压缩到 1080P5.5 几个我踩过的坑第一个坑是大模型的并发限制。我一开始为了追求速度同时开了 10 个并发请求结果触发了 API 的限流一半的请求都失败了。后来改成串行执行虽然慢一点但稳定得多。如果确实需要并发建议控制在 3 到 5 个并发以内并且加上失败重试机制。第二个坑是音频和视频的时长对齐。诗词朗读的时长是不固定的五言诗和七言诗的时长能差好几秒。如果画面素材是固定时长的就会出现画面播完了音频还没完或者音频完了画面还在放的情况。解决办法是根据音频时长动态调整画面时长在剪映草稿里把画面的持续时间设成跟音频一致。第三个坑是背景音乐的音量。诗词朗读的声音比较轻如果背景音乐音量不调低会盖住朗读声。我的做法是把背景音乐音量设到 20% 到 30%并且在朗读开始的时候做一个短暂的音量降低闪避效果。剪映里可以用关键帧来实现这个效果在草稿文件里对应的是音量曲线的控制点。6. 这套流程还能怎么扩展跑通基础流程之后我做了几个扩展效果还不错。第一个扩展是加入数字人。剪映有卡通人物数字人的功能可以让一个古风形象来“朗读”诗词比纯音频更有代入感。数字人的口型跟音频对齐需要额外处理剪映里可以用“文本朗读”功能自动生成口型动画。第二个扩展是多语言版本。同一首诗词可以生成中文、英文两个版本英文版用翻译模型处理配音用英文语音合成字幕也做双语。这样一条内容可以覆盖更多受众。翻译的时候要注意诗词翻译不能直译要让翻译模型用“意译”的方式保持诗意。第三个扩展是自动发布。视频合成完之后可以通过各平台的开放接口自动上传发布。不过这个环节涉及平台规则需要谨慎处理建议先手动发布一段时间确认内容质量稳定了再考虑自动化。第四个扩展是数据回流优化。把每条视频的播放量、完播率、互动数据收集回来分析哪些主题、哪些风格的诗词更受欢迎然后把这些数据反馈到提示词里让大模型优先生成高互动率的主题。这个闭环跑起来之后内容质量会持续提升。实操心得扩展功能不要一次全上跑通一个再加一个。我见过太多人一上来就想做全自动全平台发布结果基础流程都没跑稳最后什么都没做成。先把“生成诗词到导出视频”这条最短路径跑通再逐步加功能。最后分享一个我在实际使用中发现的小技巧扣子工作流的日志功能一定要打开。每次运行的时候把每个节点的输入输出都记录下来存到一个日志文件里。这样当某条视频出问题的时候你可以直接翻日志看是哪一步出了偏差不用重新跑一遍流程。这个习惯帮我省了大量排查时间尤其是批量跑了几百条之后没有日志根本不知道问题出在哪一条。