简介这份源码资源面向短视频创作者与AI视频爱好者聚焦如何借助Coze工作流批量产出高质量AI美食视频解决从提示词设计到模型选型、再到成片质感把控的完整链路问题适合具备一定Coze基础、希望切入美食吃播赛道的中级用户。压缩包共3个文件以inscode工程配置、html页面与gitignore为主整体仅8KB轻量易读便于直接导入或二次改造。资源围绕输入食物名称、生成文生视频提示词、选择视频生成模型等关键环节展开并对比豆包、Running Hub与Veo3三种方案的优劣同时给出通过特效与剪辑强化美食色香味的实操思路。目前已有1397人学习下载可帮助读者快速搭建可复用的AI美食视频生产流程理解提示词优化与模型选型对成片质量的影响并借鉴短视频运营策略提升内容吸引力。1. 从一条美食短视频倒推Coze 工作流到底替我们干了什么一条能发出去的美食短视频拆开看是四件事选题文案、分镜画面、配音字幕、封面标题。手工做熟练的剪辑师一天出 3 到 5 条用 Coze 工作流搭一条自动化管线同样的时间能跑几十条而且风格统一、不会今天忘了加字幕明天忘了配 BGM。这就是「Coze 工作流制作 AI 美食视频」真正解决的问题——不是让 AI 替你当厨师而是把重复的编排劳动交给工作流你只负责定风格和做终审。Coze 是字节跳动推出的智能体与工作流编排平台节点式拖拽内置大模型、插件、知识库、数据库等能力能一键发布成 Bot 或 API。美食视频这条线特别适合它文案有套路、画面有模板、配音有固定音色几乎全是可枚举的工序。适合谁做会一点 Python、懂 JSON、能看懂接口返回的运营或独立开发者。纯小白也能跟但遇到节点报错要能自己看日志。下面我把这条管线从零拆到能跑源码结构、参数、坑点都摊开讲。2. 拆解美食视频生产链路Coze 工作流里该放哪几个节点2.1 先画数据流再拖节点很多人一上来就打开 Coze 拖节点拖到一半发现数据接不上又回头删。血泪经验是先在纸上把数据流画清楚。一条美食视频工作流的标准数据流是这样的——输入菜品名 / 风格 / 时长→ 文案生成大模型节点→ 分镜拆解大模型节点输出 JSON 数组→ 逐镜画面生成图像插件节点循环→ 配音合成语音插件节点→ 字幕时间轴代码节点计算→ 汇总输出返回视频素材清单 文案 封面。每个箭头代表一次数据传递传递的格式必须提前定死。我一般会先定义好中间数据结构比如分镜对象固定为{index, duration, prompt, narration}后面所有节点都按这个结构读写改起来才不会牵一发动全身。2.2 节点选型哪些用大模型哪些用插件哪些必须写代码Coze 工作流有三类节点LLM 节点、插件节点、代码节点。选错了要么贵要么慢要么不准。文案生成和分镜拆解用 LLM 节点因为需要创造性和语义理解。画面生成用图像插件比如文生图能力配音用语音合成插件这两个是确定性任务交给插件比让大模型「想象」靠谱得多。字幕时间轴、JSON 清洗、字段校验这类纯逻辑必须用代码节点别指望大模型每次都输出合法 JSON——它总会在某个字段后面多个逗号。环节节点类型理由典型耗时文案生成LLM 节点需要创意与风格控制3-8s分镜拆解LLM 节点语义切分输出结构化 JSON3-8s画面生成图像插件确定性出图可批量5-15s/张配音合成语音插件固定音色稳定2-5s字幕时间轴代码节点纯计算必须精确1s结果汇总代码节点拼装返回结构1s2.3 用代码节点把大模型的「自由发挥」关进笼子LLM 节点最大的问题是输出不稳定。同一个 prompt这次给你标准 JSON下次给你裹一层 json 代码块再下次字段名从narration变成voiceover。所以分镜拆解节点后面必须跟一个代码节点做清洗和校验。import json import re def main(shot_text: str) - dict: # 去掉大模型可能包裹的 markdown 代码块标记 cleaned re.sub(rjson|, , shot_text).strip() try: shots json.loads(cleaned) except json.JSONDecodeError: # 兜底尝试截取第一个 [ 到最后一个 ] start, end cleaned.find([), cleaned.rfind(]) shots json.loads(cleaned[start:end 1]) # 字段校验与补全保证下游节点拿到统一结构 normalized [] for i, s in enumerate(shots): normalized.append({ index: i, duration: int(s.get(duration, 3)), prompt: s.get(prompt, ).strip(), narration: s.get(narration, s.get(voiceover, )).strip() }) return {shots: normalized, count: len(normalized)}这段代码做了三件事剥离代码块标记、JSON 解析失败时兜底截取、字段名归一化。参数上duration默认 3 秒narration兼容voiceover别名是因为不同批次的 prompt 会让模型用不同字段名。返回结构里带count方便下游循环节点直接拿长度。注意代码节点里不要做网络请求Coze 的代码节点执行环境对超时和依赖有限制重活交给插件。3. 从零搭一条能跑的美食视频工作流节点配置与参数3.1 文案生成节点的 prompt 怎么写才不翻车LLM 节点的 system prompt 决定了整条管线的下限。美食视频文案有固定套路钩子开头、步骤中段、情绪收尾。我一般这样写 system你是美食短视频文案策划。根据用户给的菜品名和风格输出一段 60-90 秒的口播文案。 要求开头 3 秒必须有钩子提问或反常识中间按步骤讲结尾引导互动。 只输出文案正文不要标题不要分点不要 emoji。user prompt 里传入{{dish_name}}和{{style}}两个变量。温度temperature设 0.7 到 0.8太低文案死板太高会跑题。最大长度按 90 秒口播约 250 字来卡设 500 token 足够。这里有个玄学同一个 prompt早上跑和晚上跑结果可能不一样因为模型侧有负载调度所以关键文案建议跑两次挑一条别指望一次到位。3.2 分镜拆解让大模型输出可循环的 JSON 数组分镜节点的任务是把整段文案切成 5 到 10 个镜头每个镜头给出画面描述和对应旁白。prompt 里必须明确要求输出 JSON 数组并给一个示例结构。示例比任何描述都管用——大模型是模仿机器你给它看什么格式它就还你什么格式。把下面的文案拆成 5-8 个分镜每个分镜 3-5 秒。输出 JSON 数组每个元素包含 duration秒整数、prompt画面描述中文适合文生图、narration该镜头对应的旁白原文。 只输出 JSON不要任何解释。 文案{{copy_text}}拿到输出后接 2.3 节的清洗代码节点。这里的关键参数是分镜数量太少画面单调太多生成成本高。美食视频我一般控制在 6 到 8 个镜头总时长 60 到 90 秒平均每镜 8 到 12 秒——注意画面生成可以一个 prompt 出多张但配音是按旁白时长走的所以duration要和narration字数匹配中文口播大约每秒 4 到 5 个字。3.3 循环生成画面批量出图与失败重试Coze 工作流支持循环节点把分镜数组喂进去每个元素调一次图像插件。配置时注意三点并发数别拉满一般设 2 到 3拉满容易触发插件限流每个循环项要能拿到index方便失败时定位是第几个镜头出图后把图片 URL 写回分镜对象。// 循环体内调用图像插件后把结果挂回当前分镜 async function main({ shot, imageResult }) { return { index: shot.index, duration: shot.duration, narration: shot.narration, image_url: imageResult?.data?.[0]?.url || , status: imageResult?.data?.[0]?.url ? ok : failed }; }参数说明imageResult.data[0].url是图像插件常见的返回路径但不同插件字段名可能不同接之前先在插件测试面板跑一次看真实返回。status字段是为了后面汇总时能筛出失败镜头做重试。如果某个镜头连续失败两次不要死磕直接换一个更简单的 prompt 重试——文生图对复杂场景描述本来就容易翻车把「热气腾腾的红烧肉在砂锅里翻滚背景是木质餐桌」简化成「红烧肉特写砂锅暖光」成功率会高很多。3.4 配音与字幕时间轴把秒数算准配音节点选一个稳定的中文音色语速设 1.0 到 1.1 倍。拿到音频后字幕时间轴要用代码节点算按每句旁白的字数占比分配总时长。常见做法是用音频实际时长除以总字数得到每字秒数再累加。def main(shots: list, audio_duration: float) - dict: total_chars sum(len(s[narration]) for s in shots) if total_chars 0: return {subtitles: []} sec_per_char audio_duration / total_chars subtitles, cursor [], 0.0 for s in shots: dur len(s[narration]) * sec_per_char subtitles.append({ index: s[index], start: round(cursor, 2), end: round(cursor dur, 2), text: s[narration] }) cursor dur return {subtitles: subtitles}参数上audio_duration从配音插件返回里取单位秒。sec_per_char是动态计算的不要写死因为不同音色语速不同。返回的start和end直接对应剪辑软件的字幕轨道。注意如果旁白里有标点标点也占时间所以按字符数算比按词数算更贴近实际。4. 避坑与排查这条工作流最容易翻车的 5 个地方4.1 大模型输出 JSON 解析失败现象代码节点报JSONDecodeError工作流中断。原因LLM 节点偶尔会在 JSON 前后加解释文字或字段值里带未转义的引号。解决清洗代码里必须做兜底截取见 2.3 节同时在 LLM 节点 prompt 里加一句「只输出 JSON不要任何解释」双保险。如果还失败把 temperature 降到 0.3。4.2 图像插件限流导致部分镜头无图现象循环跑到第 5 个镜头开始返回空 URL。原因并发数设太高或短时间内请求过多触发限流。解决循环并发降到 2并在循环体内加 1 到 2 秒延迟汇总节点筛出status failed的镜头单独跑一次重试流程。别在主流程里无限重试会拖垮整条管线。4.3 配音时长和分镜时长对不上现象字幕比画面快或慢最后几个镜头字幕飘出画面。原因分镜的duration是大模型估的配音是插件实际生成的两者天然有偏差。解决以配音实际时长为准用 3.4 节的代码重新分配字幕时间轴分镜的duration只作为出图参考不作为时间基准。4.4 代码节点超时现象代码节点执行超过平台限制被强制中断。原因在代码节点里做了循环请求或复杂计算。解决代码节点只做纯逻辑网络请求全部交给插件节点如果必须处理大量数据拆成多个代码节点串联每个节点只干一件事。4.5 变量名不一致导致数据接不上现象下游节点拿到的字段是undefined。原因上游 LLM 节点这次输出voiceover下次输出narration。解决在清洗节点统一字段名见 2.3 节下游只认归一化后的结构。这是最隐蔽的坑因为工作流不会报错只是结果为空排查时要从最后一个节点往前逐个打印字段。5. 进阶把工作流封装成可复用源码结构跑到这里工作流能出片了但每次改菜品都要手动改输入效率还是低。进阶做法是把整条管线封装成「配置驱动」把菜品名、风格、音色、分镜数量抽成一个 config 对象工作流只读 config不读散落的变量。这样一份源码可以跑不同品类改配置就行。{ dish_name: 红烧肉, style: 家常温馨, voice: zh_female_warm, shot_count: 7, image_style: 暖光特写浅景深, output: { need_cover: true, subtitle_burn: false } }这份 config 作为工作流入口后面所有节点从它取值。shot_count控制分镜数量image_style会拼进每个分镜的 prompt 前缀保证整条视频画面风格统一。subtitle_burn决定字幕是烧进画面还是单独输出 srt方便后期二次剪辑。验证方法很简单拿同一个 config 跑三遍对比三次输出的分镜数量、总时长、图片风格是否一致。如果三次差异很大说明某个节点的 temperature 还是太高或者 prompt 约束不够。我一般会把三次结果并排看挑最稳的那版 prompt 固化下来。源码组织上建议把 prompt 模板、清洗代码、config 示例分成三个文件工作流里只引用不内联。这样改 prompt 不用动工作流结构改结构不用动 prompt。我自己踩过的最大坑就是把所有 prompt 硬编码在节点里后来想换风格改了十几个节点改漏一个就出怪片。现在我的习惯是任何会变的东西都不写死在节点里全部抽成变量或配置文件。希望帮到你。本文还有配套的精品资源点击获取
