扣子AI Agent+大模型+剪映：自动生成诗词视频工作流实战

1. 从一句诗到一条视频这条链路到底长什么样先说说我为什么盯上这个题目。去年年底我帮一个做国学内容的朋友做账号他每天要发一条古诗词短视频坚持了两个月就扛不住了——写文案、找配图、配音、剪辑、加字幕一条视频从构思到导出至少四十分钟日更根本顶不住。当时我就在想能不能把给一句主题自动产出一条诗词视频这件事做成一条流水线。试了几套方案之后最终落地的组合是扣子CozeAI Agent 大模型 剪映。这套东西跑通之后单条视频的人工介入时间压到了三到五分钟剩下的全交给工作流。这篇内容我想讲清楚三件事扣子 AI Agent 在这里扮演什么角色、大模型负责哪一段、剪映怎么接进来完成最后一步。适合两类人看——一类是想做内容账号但被产能卡住的创作者另一类是想找一个真实可落地的 AI Agent 练手项目的开发者。不需要你懂深度学习但需要你对工作流这个概念有基本认知知道节点、变量、API 调用大概是怎么回事。先把整体链路摆出来让你有个全局印象。整条流水线分四段主题输入 → 大模型生成诗词与分镜脚本 → 扣子工作流编排与素材准备 → 剪映完成合成导出。扣子在这里不是写诗的那个它是调度中枢负责把大模型的输出结构化、把素材准备好、把参数传给下游。很多人一上来就纠结用哪个大模型写诗最好其实写诗只是整条链路里最简单的一环真正难的是让机器产出的内容能被剪映直接消费。这个认知差是我踩了半个月坑才扭过来的。提示本文所有方案基于常见实践整理具体节点名称和界面可能随版本迭代变化思路和参数逻辑是通用的。2. 为什么是扣子而不是自己写脚本或者用别的编排工具2.1 扣子在这个项目里的真实定位很多人对扣子的第一印象是搭聊天机器人的觉得拿它做视频有点大材小用或者不搭。我一开始也这么想直到我把三种方案都试了一遍才改观。自己写 Python 脚本调大模型 API灵活是灵活但你要自己处理重试、自己管素材存储、自己写并发一个周末就搭进去了而且改一个环节要动代码。用纯提示词让大模型一次性吐出诗词分镜字幕时间轴听起来很美实测下来大模型对时间轴的把控极差经常给出第3秒到第7秒这种剪映根本没法直接用的描述。而扣子的价值在于它把大模型调用、条件判断、变量传递、插件调用这些能力做成了可视化节点你可以在不改代码的前提下反复调整流程而且每个节点的输出都能单独调试。具体到这个项目扣子承担了四个明确职责接收主题词、调用大模型生成结构化内容、对生成结果做格式校验和清洗、把最终参数整理成剪映能识别的格式。它不负责渲染视频也不负责最终剪辑它是一条内容生产线的工头。2.2 大模型、Agent、工作流这三个词别再混着用热词里有一堆人在问agent 和 llm 和 ai 模型有什么区别这个问题不搞清楚后面搭起来会很乱。我用一个做菜的类比讲明白。大模型LLM是那个厨艺很好的厨师你给他食材和菜名他能做出一道菜。DeepSeek、通义、豆包这些都属于大模型它们是能力本身。AI Agent是给这个厨师配了一个助理助理知道先买菜、再洗菜、再让厨师炒、最后装盘还能根据客人反馈决定要不要重做。Agent 的核心是有目标、能规划、会调用工具。工作流Workflow则是把助理的这套动作画成一张流程图每一步做什么、上一步的输出怎么给下一步全都固定下来。扣子这个平台既能搭 Agent带自主决策的智能体也能搭工作流固定流程。做诗词视频这种步骤明确、不需要太多自主决策的任务我强烈建议用工作流而不是纯 Agent。原因很简单视频生产是标准化的你不需要 AI 每次自己决定这次要不要加背景音乐你需要的是稳定、可复现。用 Agent 反而会因为它的自主性引入不确定性今天给你加个片头明天忘了加字幕账号内容风格就乱了。2.3 方案选型的三个关键取舍在正式动手前有三个选择你必须先定下来它们直接决定后面顺不顺。第一个取舍是诗词由大模型现生成还是从诗词库里检索。现生成的好处是主题贴合度高你说写一首关于加班到深夜的诗它能给你写出来坏处是有时候会写出格律不对、甚至事实错误的句子。检索的好处是质量稳定坏处是主题覆盖有限。我的做法是混合先用大模型生成再用一个校验节点检查字数和基本格律不合格就重新生成一次两次都不行就降级到检索库。第二个取舍是配音用 TTS 还是真人录音。TTS 快、成本低、可批量但情感表达偏平真人录音有温度但没法规模化。做日更账号TTS 是唯一现实的选择但要在语速和停顿上做文章后面会讲具体参数。第三个取舍是剪映用电脑版手动操作还是走草稿文件自动生成。手动操作意味着每条视频你还要打开剪映点几下产能上不去自动生成草稿文件剪映的 draft 工程文件本质是 JSON能实现全自动但需要你摸清它的文件结构。我走的是后者这也是这套方案能压到三分钟一条的关键。3. 扣子工作流的节点拆解与参数设计3.1 工作流整体节点编排一条完整的扣子工作流我拆成了七个节点顺序如下。这里不贴具体截图讲清楚每个节点的输入输出和配置逻辑你照着搭就行。开始节点接收两个输入变量theme主题词字符串和style风格枚举值比如豪放婉约边塞。大模型节点生成诗词输入 theme 和 style输出一首四句或八句的诗词。代码节点格式校验检查诗句数量、每句字数、是否含标点异常。条件判断节点校验通过走下一步不通过回到大模型节点重试设置最多重试两次。大模型节点生成分镜脚本把诗词拆成画面描述输出结构化的 JSON。插件节点TTS 语音合成把诗词转成音频文件拿到音频时长。代码节点生成剪映草稿参数把画面描述、音频时长、字幕文本整合成剪映草稿需要的 JSON 结构。这七个节点里第 3 和第 7 是代码节点是整条工作流的灵魂。第 3 个保证内容质量第 7 个保证下游能消费。很多人搭工作流只堆大模型节点结果输出一堆没法用的自然语言卡在最后一步。3.2 大模型节点的提示词怎么写才稳定提示词是这套东西里最容易被低估的部分。我见过太多人写一句帮我写一首诗就完事然后抱怨输出不稳定。大模型不是不听话是你没把要求说清楚。生成诗词的提示词我实测下来这套结构最稳先定角色再定硬约束最后给输出格式。硬约束一定要具体到数字比如必须是七言绝句共四句每句七个字押平声韵韵脚为第一、二、四句。输出格式要求它只返回诗词本身不要任何解释、不要标题、不要这首诗表达了之类的废话。这一点极其重要因为下游的代码节点是按行解析的多一行解释就全乱了。生成分镜脚本的提示词更讲究。你要让大模型把每一句诗翻译成画面描述而且这个描述要能被后续的素材检索或 AI 绘图消费。我的提示词里会明确要求每句诗对应一个分镜每个分镜包含 scene画面描述20 字以内、mood情绪关键词、duration_weight时长权重1 到 3 的整数。输出必须是严格的 JSON 数组不要用 markdown 代码块包裹。这里有个坑很多大模型默认会用 json 包裹输出你必须在提示词里明确禁止否则代码节点解析会失败。3.3 代码节点把自然语言变成机器能吃的结构第 3 个代码节点做校验逻辑不复杂但很关键。核心是三个检查句数对不对、每句字数对不对、有没有混入非中文字符。用 JavaScript 写大概是这样async function main({ params }) { const poem params.poem.trim(); const lines poem.split(\n).filter(l l.trim().length 0); const expectedLines 4; const expectedChars 7; let valid true; let reason ; if (lines.length ! expectedLines) { valid false; reason 句数不符期望${expectedLines}句实际${lines.length}句; } else { for (let i 0; i lines.length; i) { const clean lines[i].replace(/[。、]/g, ); if (clean.length ! expectedChars) { valid false; reason 第${i 1}句字数不符期望${expectedChars}字实际${clean.length}字; break; } } } return { valid, reason, cleanPoem: lines.join(\n) }; }这段代码的意图很直白把标点去掉之后数汉字。为什么要去标点因为大模型有时候会在句末加句号有时候不加你不统一处理就会误判。这个细节不写出来很多人会在这里卡半天明明诗是对的校验就是不通过。第 7 个代码节点更复杂它要生成剪映草稿的 JSON。剪映的草稿文件结构里核心是tracks轨道和segments片段。一条视频至少要有视频轨、音频轨、字幕轨三条。每条轨道下的每个 segment 都要有start开始时间单位微秒、duration持续时长、material_id素材引用。时间轴的计算逻辑是先拿到 TTS 音频的总时长再按每个分镜的 duration_weight 按比例分配。举个例子音频总长 12 秒四个分镜的权重分别是 3、3、3、3那每个分镜就是 3 秒。如果权重是 2、4、3、3总和 12那第一个分镜就是 12 × 2/12 2 秒第二个是 4 秒以此类推。这个按权重分配的逻辑是保证画面切换和语音节奏对上的关键。你要是平均分配遇到长句就会画面切太快、短句画面拖太久观感很差。4. 从诗词到成片完整实操流程与关键参数4.1 素材准备画面从哪来分镜脚本有了画面素材怎么解决三条路AI 绘图生成、免费图库检索、纯色背景加文字动画。我三条都试过说下各自的适用场景。AI 绘图生成质量最高、最贴合诗意但慢而且需要额外的绘图工作流比如 ComfyUI 那套。如果你追求效率免费图库检索是性价比最高的选择用分镜里的 mood 关键词去检索比如孤舟明月大漠这类意象词命中率不错。纯色背景加文字动画最省事适合做那种极简风格的账号但对文案要求高画面撑不住就容易显得廉价。我的建议是按账号定位选。做大众国学号图库检索够了做精品文化号上 AI 绘图做快节奏知识号纯色背景加动效反而清爽。别一上来就追求最复杂的方案先把链路跑通再逐步升级素材质量。4.2 TTS 配音的参数调校配音这块参数比工具重要。我用下来语速控制在每分钟 200 到 240 字比较舒服古诗词比日常口语要慢一点太快了没有韵味。停顿是关键每句诗之间留 0.5 到 0.8 秒的停顿让听众有回味的时间。很多 TTS 工具支持在文本里插入停顿标记比如用逗号或者专门的 SSML 标签你要善用这个。音色选择上古诗词适合偏沉稳的男声或者温润的女声别用那种过于活泼的。如果 TTS 工具支持情感参数选平静或深情这类不要选开心。我试过用活泼音色配边塞诗效果非常违和像在念广告。还有一个实操细节TTS 输出的音频格式要统一成剪映支持的格式一般是 mp3 或 wav。有些工具默认输出 m4a剪映虽然也认但在草稿文件里引用时路径处理容易出问题统一成 mp3 最省心。4.3 剪映草稿文件的生成与导入这是整套方案里技术含量最高的一步也是最多人卡住的地方。剪映的草稿文件本质是一个 JSON存放在特定目录下每个草稿一个文件夹里面有draft_content.json和draft_meta_info.json等文件。你要做的是用代码节点生成一份符合剪映格式的 draft_content.json写入到剪映的草稿目录然后打开剪映就能看到这条草稿。听起来简单但格式细节很多。核心字段包括canvas_config画布尺寸竖屏是 1080×1920、tracks轨道数组、materials素材引用数组。时间单位是微秒这个一定要记住1 秒等于 1,000,000 微秒。我第一次做的时候按毫秒算结果所有片段时长都差了 1000 倍视频打开是一片空白。素材引用有个坑视频素材、音频素材、文字素材要分别放在 materials 数组的不同子数组里然后在 segment 里通过 material_id 引用。文字素材字幕还要单独配置字体、字号、颜色、位置。字幕位置我一般放在画面下方三分之一处字号 48 到 60颜色白色加黑色描边保证在任何背景上都看得清。注意剪映草稿文件结构会随版本变化建议先手动创建一条最简单的草稿导出后研究它的 JSON 结构再照着生成。直接照搬网上的模板很容易因为版本不匹配失败。4.4 一条完整视频的实操记录我拿写一首关于秋夜思乡的七言绝句这个主题完整跑了一遍记录下关键节点。主题输入后大模型生成秋风又起叶纷飞独倚高楼望月归。故里炊烟应未散天涯游子泪沾衣。校验节点检查通过四句七言。分镜脚本生成四个画面落叶纷飞、高楼望月、故乡炊烟、游子落泪。TTS 合成音频总时长 14.2 秒。按权重 3、3、4、4 分配四个画面分别是 3.0、3.0、4.1、4.1 秒。代码节点生成草稿 JSON写入剪映目录打开剪映一条带字幕、带配音、画面切换的诗词视频就躺在草稿箱里了。从输入主题到看到成片全程不到四分钟其中人工只做了输入主题和打开剪映导出两个动作。这个效率意味着什么意味着一个人一天产出二三十条诗词视频是可行的。当然内容质量还得靠人把关机器负责的是把重复劳动干掉。5. 踩过的坑与常见问题速查5.1 大模型输出不稳定的三种典型表现第一种是格式漂移。你要求输出 JSON它给你输出带 markdown 代码块的 JSON或者干脆输出一段自然语言。解决办法是在提示词里反复强调只输出纯 JSON不要任何其他字符并且在代码节点里做容错解析先尝试直接 parse失败就正则提取花括号之间的内容再 parse。第二种是内容注水。你要求写四句它给你写六句或者每句字数不齐。这就是校验节点存在的意义别指望大模型百分百听话一定要有兜底。第三种是重复生成。重试机制如果没设上限遇到大模型持续输出不合格内容会陷入死循环白白烧 token。一定要设最大重试次数我设的是两次两次不行就走降级方案。5.2 剪映草稿打不开的排查思路草稿打不开九成是 JSON 格式问题。排查顺序是先看 JSON 本身是否合法用在线工具校验一下再看时间单位是不是微秒再看素材路径是不是绝对路径且文件真实存在最后看版本兼容性。素材路径这个坑特别隐蔽。你在代码节点里引用的音频文件必须是剪映能访问到的真实路径不能是网络 URL也不能是相对路径。我的做法是把 TTS 生成的音频先下载到本地固定目录再在草稿里引用这个绝对路径。5.3 常见问题速查表问题现象可能原因解决方向校验节点一直不通过标点未统一处理校验前先去除所有标点再数字数视频打开一片空白时间单位用错确认所有时长单位为微秒字幕不显示文字素材未加入 materials检查字幕是否单独建了文字素材并引用音频和画面不同步权重分配逻辑有误按 duration_weight 比例分配总和等于音频时长草稿导入后闪退JSON 结构缺字段对照手动创建的草稿补齐必填字段TTS 音频有杂音采样率不匹配统一为 44100Hz格式统一 mp35.4 几条压箱底的经验第一先跑通最小闭环再优化。别一上来就搞 AI 绘图、搞复杂动效先用纯色背景加字幕把整条链路跑通确认草稿能正常导入导出再逐步替换素材。我见过太多人卡在素材质量上链路根本没跑通就放弃了。第二把每个节点的输出都存一份日志。扣子的调试功能可以看每个节点的输出但工作流跑多了之后你需要一个持久化的记录来排查问题。我在代码节点里会把关键中间结果写到一个文本文件出问题时翻日志比重新跑一遍快得多。第三内容质量的人工把关不能省。机器生成的诗词格律可能没问题但意境和用词经常差一口气。我的做法是批量生成、人工筛选一次生成十条挑出最好的三条发布。这样既保证了产能又守住了质量底线。第四注意账号内容的合规性。诗词内容本身一般没问题但配图和配音要注意版权图库素材要选可商用的TTS 音色要确认授权范围。这块别偷懒账号做起来之后被投诉下架得不偿失。6. 这套方案还能往哪延伸跑通诗词视频之后我发现这条链路的骨架是通用的——主题输入、内容生成、结构化、素材合成换个内容类型就能复用。比如做成语故事、做历史人物科普、做每日一句英文逻辑几乎一样只需要换提示词和素材库。再往深了走可以把扣子工作流和定时任务结合实现每天自动生成、自动入库你只需要定期登录剪映批量导出。这一步做完内容账号的产能瓶颈基本就解除了。我个人在实际操作中的体会是AI Agent 这类工具真正的价值不在于替代人而在于把人从重复劳动里解放出来去做判断和筛选。写诗这件事机器能写但哪首值得发还得人来定。工具越强人的审美和判断力反而越值钱。