
简介这份源码资源面向短视频创作者与AI视频爱好者聚焦如何借助Coze工作流批量产出高质量AI美食视频解决从食物名称输入到成片生成的全流程自动化问题适合具备一定Coze基础、希望切入美食吃播赛道的中级用户。压缩包共3个文件以inscode工程配置、html页面与gitignore为主整体约8KB结构轻量便于直接导入或二次修改。资源完整呈现了文生视频提示词生成、视频模型选择等关键环节的实现思路并对比豆包、Running Hub与Veo3三种生成方式的优劣帮助读者按需选型。同时涉及美食色香味的视觉化表达与短视频运营策略可对照源码理解工作流编排逻辑快速搭建属于自己的AI美食视频生产管线。目前已有1397人学习下载适合想提升内容产出效率的创作者参考借鉴。1. 从一条美食视频到一套可复用工作流Coze 到底能省掉哪些手工活做美食短视频的朋友大概率经历过这种循环拍完素材写文案、配音、找 BGM、卡点剪辑、加字幕、导出、发布一条 60 秒的视频能磨掉两三个小时。如果一天要更三条基本就废了。Coze 工作流制作 AI 美食视频这件事核心不是让 AI 替你拍菜而是把「文案生成 → 分镜拆解 → 配音合成 → 素材匹配 → 字幕对齐 → 成片导出」这条链路用节点串起来让重复劳动变成一次配置、批量执行。它适合两类人一类是个人美食账号运营者想用最低成本把日更跑起来另一类是做内容工具的产品或开发想拿 Coze 当编排层把 AI 能力接进自己的业务。源码在这里的价值不是「一键出片」的魔法而是让你看清每个节点的输入输出长什么样方便替换模型、改参数、接自己的素材库。下面按「先跑通最小链路再补细节最后处理翻车场景」的顺序拆。2. 拆解 Coze 美食视频工作流的节点链路从文案到成片要过几道手2.1 一条美食视频工作流的最小节点集合先把链路说清楚不然后面配节点会迷路。一条能出片的美食视频工作流通常包含六个核心节点文案生成节点、分镜拆解节点、配音节点、素材检索节点、字幕对齐节点、合成导出节点。Coze 的工作流本质是一个有向图每个节点接收上游输出处理后传给下游。文案节点一般用大模型节点输入是「菜名 口味标签 目标人群」输出是一段带钩子的口播文案。分镜节点把文案切成 5 到 8 个镜头描述每个镜头带时长建议和画面关键词。配音节点调用 TTS 能力把分镜文案转成音频同时拿到时间戳。素材检索节点根据画面关键词去匹配视频片段或图片。字幕节点把音频时间戳和文案对齐成 SRT。合成节点用 FFmpeg 或云剪辑接口把素材、音频、字幕拼成成片。这里有个容易忽略的点Coze 工作流里的变量传递是显式的上游节点输出的字段名必须和下游节点引用的字段名一致。很多人第一次搭的时候文案节点输出content分镜节点却去读text结果节点报空。常见做法是每个节点输出后先跑一次单节点调试把返回结构看清楚再连下游。2.2 文案与分镜节点的参数怎么设才不跑偏文案节点是整个工作流的起点参数设不好后面全歪。我一般会固定三个输入变量dish_name菜名、flavor口味比如「麻辣」「清爽」、audience人群比如「上班族」「宝妈」。提示词里明确要求输出 JSON字段包括hook前 3 秒钩子、body正文、cta结尾引导。温度参数建议设在 0.7 到 0.9 之间太低文案死板太高容易跑题。分镜节点接收文案后要求输出一个数组每个元素包含shot_id、duration、visual_desc、voiceover。duration建议控制在 3 到 8 秒太短剪辑碎太长素材难匹配。{ dish_name: 蒜蓉粉丝蒸虾, flavor: 鲜香, audience: 上班族, shots: [ {shot_id: 1, duration: 4, visual_desc: 活虾在清水中游动, voiceover: 下班回家不想动这道菜十五分钟搞定}, {shot_id: 2, duration: 5, visual_desc: 蒜末在热油中爆香, voiceover: 蒜末下锅那一刻香味直接把人拽回厨房}, {shot_id: 3, duration: 6, visual_desc: 粉丝铺底摆虾上锅蒸, voiceover: 粉丝垫底虾摆一圈上锅蒸六分钟} ] }这段 JSON 是分镜节点的标准输出结构。shot_id用于后续字幕和素材的顺序对齐duration决定配音节点生成多长的音频片段visual_desc是素材检索节点的查询关键词voiceover是 TTS 的输入文本。参数上duration的总和要和文案总时长匹配偏差超过 20% 就要回头调分镜提示词。素材检索节点拿到visual_desc后建议做一次关键词扩展比如「蒜末爆香」扩展成「蒜末 热油 翻炒 特写」提高匹配命中率。2.3 配音、字幕与合成节点的衔接细节配音节点输出两个东西音频文件和每个句子的时间戳。时间戳的精度直接决定字幕对齐质量。常见做法是让 TTS 返回 SSML 标记或按句切分的音频这样字幕节点可以按句对齐而不是整段硬切。字幕节点接收voiceover数组和对应时间戳生成 SRT 格式。合成节点用 FFmpeg 时命令里要显式指定音频和字幕的偏移量否则容易出现字幕比声音慢半拍的情况。ffmpeg -i video_concat.mp4 -i voiceover.mp3 -vf subtitlessubtitle.srt:force_styleFontSize18,PrimaryColourH00FFFFFF -c:v libx264 -c:a aac -shortest output_final.mp4这条命令把拼接好的视频、配音和字幕合成成片。-shortest保证以最短流为准避免尾部黑屏。force_style里的FontSize和PrimaryColour按平台习惯调抖音类竖屏一般字号 18 到 22白色带描边。如果字幕出现乱码检查 SRT 文件编码是不是 UTF-8FFmpeg 对 GBK 支持不稳定。合成节点最容易翻车的地方是素材分辨率和帧率不统一建议在拼接前统一转成 1080x1920、30fps否则 FFmpeg 会报流不兼容。3. 用 Coze 工作流跑通第一条美食视频节点配置与调试步骤3.1 从零搭一个可运行的工作流骨架打开 Coze 工作流编辑器后先别急着堆节点。第一步是定义输入变量把dish_name、flavor、audience三个字段加到开始节点。第二步拖入大模型节点做文案生成提示词里写清楚输出 JSON 格式并在节点设置里开启「结构化输出」把字段名和类型填进去。第三步接分镜节点同样用大模型节点输入引用文案节点的body字段输出数组。第四步接 TTS 节点输入引用分镜数组里的voiceover输出音频和时间戳。第五步接素材检索节点输入引用visual_desc输出素材 URL 列表。第六步接代码节点做字幕对齐把时间戳和文案拼成 SRT 字符串。第七步接合成节点调用外部 FFmpeg 服务或云剪辑 API。调试顺序很重要不要一次性连完再跑而是每加一个节点就单独跑一次。Coze 的节点调试面板会显示输入和输出重点看输出字段名和类型是否符合预期。文案节点如果返回的是纯文本而不是 JSON检查提示词里有没有明确「只输出 JSON不要解释」。分镜节点如果数组长度不对调提示词里的镜头数量约束。3.2 素材检索节点的关键词扩展与命中率优化素材检索是整条链路里最不稳定的一环。visual_desc写得太具体比如「蒜末在 180 度热油中翻滚」检索大概率空手而归写得太泛比如「做饭」匹配到的素材又和画面不搭。我一般会在检索节点前加一个关键词扩展节点用大模型把visual_desc拆成三组关键词主体、动作、场景。比如「蒜末爆香」拆成「蒜末 / 爆香 / 厨房特写」。然后用这三组关键词去素材库做多路召回取交集或按权重排序。def expand_keywords(visual_desc): # 调用大模型或规则引擎做关键词扩展 prompt f把下面的画面描述拆成主体、动作、场景三组关键词用 JSON 返回{visual_desc} result call_llm(prompt) return { subject: result[subject], action: result[action], scene: result[scene] } def search_material(keywords, material_lib): # 多路召回按命中数排序 candidates [] for kw in keywords.values(): candidates.extend(material_lib.search(kw, top_k5)) # 去重并按出现频次排序 freq {} for item in candidates: freq[item[id]] freq.get(item[id], 0) 1 return sorted(freq.items(), keylambda x: -x[1])[:3]这段代码展示了关键词扩展和多路召回的基本逻辑。expand_keywords把一句画面描述拆成三组词search_material分别检索后按命中频次排序取前三个作为候选素材。参数上top_k建议设 5 到 10太小容易漏太大增加排序开销。如果素材库是自己的建议给每个素材打上主体、动作、场景三类标签检索时直接按标签匹配比全文检索稳定得多。3.3 字幕对齐与合成节点的参数表字幕对齐的精度取决于 TTS 返回的时间戳粒度。如果 TTS 只返回整段音频的时长字幕只能按字数均分效果很差。常见做法是要求 TTS 按句返回时间戳或者用强制对齐工具如 Whisper 的 word-level timestamp重新对齐。合成节点的参数直接影响成片质量下面这张表是我常用的配置。参数建议值说明分辨率1080x1920竖屏平台标准帧率30fps兼容性最好视频码率6Mbps平衡画质和体积音频码率128kbps人声足够字幕字号18-22竖屏可读字幕颜色白色带描边避免背景干扰音频采样率44100Hz标准合成节点如果调用的是云剪辑 API注意接口的并发限制和超时时间。批量生成时建议加一个队列节点控制同时合成的任务数避免触发限流。合成完成后输出文件建议按dish_name_timestamp.mp4命名方便后续追溯。3.4 用代码节点做异常兜底与重试工作流跑批量时最怕某个节点偶发失败导致整条链路中断。Coze 的代码节点可以做异常捕获和重试。比如素材检索节点返回空列表时代码节点可以触发一次降级检索用更泛的关键词再查一遍如果还是空就返回一个默认素材 URL保证链路继续走。def safe_search(keywords, material_lib, retry2): for i in range(retry): result search_material(keywords, material_lib) if result: return result # 降级去掉场景关键词只保留主体和动作 keywords.pop(scene, None) # 最终兜底 return [{id: default, url: https://example.com/default.mp4}]这段代码做了两层兜底第一次检索失败后去掉场景关键词再试第二次还失败就返回默认素材。retry参数控制重试次数建议设 2 到 3 次太多会拖慢整体速度。兜底素材建议选一段通用厨房空镜至少保证视频能出片后期人工替换也比整条重跑划算。4. Coze 美食视频工作流避坑5 个血泪翻车现场4.1 节点输出字段名不一致导致下游读空现象分镜节点跑完显示成功但素材检索节点报「输入为空」。原因分镜节点输出的是shots数组素材节点引用的是shot_list字段名对不上。解决每次连节点前先点开上游节点的输出面板把字段名复制到下游节点的输入框不要手打。Coze 的变量引用支持下拉选择尽量用选择而不是手输。4.2 TTS 时间戳粒度过粗导致字幕漂移现象字幕整体比声音慢 1 到 2 秒越到后面越明显。原因TTS 只返回整段音频时长字幕按字数均分语速不均匀时误差累积。解决换用支持句级时间戳的 TTS或者用 Whisper 做强制对齐拿到每个词的起止时间后再生成 SRT。如果只能用整段时长至少在文案里控制每句字数相近减少均分误差。4.3 素材分辨率不统一导致 FFmpeg 合成失败现象合成节点报「Stream specifier matches no streams」或输出视频花屏。原因拼接的素材来自不同来源分辨率和帧率不一致。解决在合成前加一个统一转码节点把所有素材转成 1080x1920、30fps、H.264。FFmpeg 命令里加-vf scale1080:1920:force_original_aspect_ratiodecrease,pad1080:1920:(ow-iw)/2:(oh-ih)/2做等比缩放加黑边填充。4.4 批量运行时触发 API 限流现象前几条视频正常跑到第十条左右开始报「rate limit exceeded」。原因合成节点或 TTS 节点并发太高触发服务方限流。解决在关键节点前加队列或延迟节点控制并发数在 2 到 3 个。Coze 工作流里可以用代码节点做简单的令牌桶或者把批量任务拆成多个小批次每批之间 sleep 几秒。4.5 文案钩子同质化导致视频完播率低现象工作流跑得很顺但视频发出去完播率一直在 20% 以下。原因文案节点的提示词太固定每条视频的前 3 秒钩子都是「今天教你做一道……」。解决在文案节点里加随机种子或从钩子模板库里随机选模板库至少准备 10 种不同句式比如悬念式、反常识式、场景代入式。温度参数可以适当调高到 0.9增加多样性。5. 把 Coze 美食视频工作流接进批量生产进阶技巧与验证方法5.1 用批量输入节点做日更流水线单条跑通之后下一步是批量。Coze 工作流支持批量输入可以把菜名列表、口味列表、人群列表做成 CSV 或 JSON 数组一次性喂给工作流。我一般会建一个「菜谱库」表格字段包括dish_name、flavor、audience、priority工作流按priority排序依次执行。批量运行时建议把合成节点单独拆成子工作流主工作流只负责生成文案、分镜、配音和素材合成用异步任务处理避免主流程阻塞。import csv import json def load_recipe_batch(csv_path): # 读取菜谱库按优先级排序 with open(csv_path, encodingutf-8) as f: reader csv.DictReader(f) recipes [row for row in reader] return sorted(recipes, keylambda x: -int(x[priority])) def run_batch(recipes, workflow_api): results [] for recipe in recipes: payload { dish_name: recipe[dish_name], flavor: recipe[flavor], audience: recipe[audience] } # 调用 Coze 工作流 API resp workflow_api.invoke(payload) results.append({dish: recipe[dish_name], status: resp[status]}) return results这段代码展示了批量输入的基本结构。load_recipe_batch读取 CSV 并按优先级排序run_batch逐条调用工作流 API。参数上priority建议用 1 到 5 的整数数字越大越先跑。批量运行时记得加日志记录每条任务的开始时间、结束时间和状态方便排查哪条卡住了。5.2 用 A/B 对比验证工作流输出质量工作流跑起来之后怎么判断它出的片能不能用我一般会做两组 A/B 对比一组是工作流出片 vs 人工剪辑另一组是不同提示词版本的工作流出片。对比指标看三个前 3 秒完播率、平均观看时长、互动率。如果工作流出片的前 3 秒完播率比人工低 15% 以上说明钩子生成有问题回去调文案节点。如果平均观看时长差距不大但互动率低可能是结尾 CTA 不够自然。验证时注意控制变量同一道菜、同一时间段发布、同一账号。样本量至少 10 条太少波动大。我自己的习惯是每周跑一次对比把数据记在表格里连续三周下降就停下来检查工作流是不是哪个节点退化了。5.3 源码里值得盯的几个扩展点拿到源码后不要急着改先跑通默认配置再按需扩展。值得盯的扩展点有三个一是文案节点的提示词模板这是最影响出片质量的环节可以换成自己积累的爆款句式二是素材检索节点的数据源默认可能是通用素材库换成自己拍的素材或垂直美食素材库命中率和画面匹配度会明显提升三是合成节点的输出参数不同平台对分辨率、码率、字幕样式的要求不一样按平台调参比一套参数打天下效果好。最后说个我自己的教训刚开始搭工作流时总想一步到位把所有节点都配到完美再跑结果卡了两周没出片。后来改成先跑通最小链路哪怕素材是默认的、字幕是粗糙的先让视频能出来再逐个节点优化。工作流这东西跑起来比跑得完美重要。希望帮到你。本文还有配套的精品资源点击获取