简介面向短视频运营者和AI视频内容创作者这份源码包围绕如何用Coze工作流高效制作AI美食视频展开适用于希望复现高播放量美食短视频的运营人员与入门实战者。资源体积精致共3个文件包含Coze工作流源码inscode、可直观查看的HTML说明页面以及Git忽略规则文件压缩包仅8KB轻量易导入。目前已有1385人学习下载。作者基于单条视频百万播放的实操经验完整拆解了从输入食物名称、生成高质量文生视频提示词到选择豆包、Running Hub或Veo3等模型的决策逻辑并对比三种生成方式的优缺点同时结合AI切水果项目迁移到美食吃播的案例分享了通过特效与编辑技巧传递食物色香味、增强观众感官体验的运营思路。这套轻量源码提供可直接复用的工作流模板、可借鉴的提示词优化方法以及完整的模型选型参考尤其适合希望在短视频赛道快速验证内容创意的读者。 先聊一个我最近总在思考的问题AI生成的美食视频为什么很多都“画面很精美但根本不想看下去”做了几条彻底翻车的视频之后我慢慢想明白了——文生视频工具负责的是“单个镜头好看”但一条能让人看完的美食视频靠的是叙事逻辑、节奏、食材状态的连贯性这些单靠输入一句提示词是解决不了的。所以我把整套流程搬到了Coze扣子工作流上从输入菜名、生成菜谱到拆解分镜脚本、转换视频提示词、调用视频生成插件全部用工作流串联。这篇文章就把我的完整设计思路、节点Prompt配置以及一份可以直接修改使用的源码结构分享出来给正在折腾AI视频内容的朋友一个可复用的参考。1. 先拆解一个真问题AI美食视频“画面好看但没法看”的病根在哪1.1 单靠文生视频工具你得到的是“碎片”而不是“片子”我最早尝试用即梦、可灵这类工具做美食视频工作流简单粗暴想好一句提示词输入生成一个5~10秒的片段。比如“一个厨师把番茄切成薄片4K画质特写镜头”。生成结果单独看确实不错光影、质感都在线。但一旦想拼成一道菜的完整视频问题就全暴露出来前一个镜头里番茄还是整个的下一个镜头突然变成切好的丁中间过程丢失了镜头之间没有景别逻辑全是特写没有交代食材、厨具、环境的关系配文和画面完全脱节解说词是“大火翻炒”画面却在展示摆盘。说白了视频生成工具的本质是“按照提示词生成一段动态图像”它不理解“做菜的逻辑”也不理解“一条视频应该有起承转合”。这个工作必须由内容结构层来补。1.2 工作流真正的价值是把“内容生产流程”拆开而不是把“大模型串起来”很多人误以为工作流就是把几个大模型节点串在一起跑一遍其实不是。我在Coze里搭这套美食视频流水线时最大的体会是工作流是对“内容生产流程”本身的数字化拆解。你想想一个真人美食博主拍一支视频大概要经历这些步骤确定做什么菜列出食材和烹饪步骤设计分镜确定每个画面拍什么、怎么运镜、配什么文案拍摄或找素材剪辑拼接、配音、字幕。Coze工作流做的事情就是把第2到第4步替换成大模型和视频生成插件并且让每一步的输出自动成为下一步的输入。这中间最关键的不是“用了多少个大模型”而是“每一步的输出格式是否稳定、是否可被下游节点直接使用”。2. 工作流骨架六个节点如何把“一道菜”变成“一条视频”2.1 六节点设计每个节点只干一件事我最终落地的版本是六个节点结构如下开始节点接收用户输入——“菜名/食材”和“视频风格”两个变量大模型节点A菜谱与结构生成根据菜名生成完整食材清单、分步烹饪步骤以及每一步的预估时长大模型节点B分镜脚本生成把菜谱转换成镜头语言每个镜头包含“画面描述、景别、运镜、字幕、配音文案”代码节点提示词转换把分镜脚本中的“画面描述”转成视频生成模型更易理解的英文提示词并做清洗插件节点视频生成调用Coze插件市场里的视频生成能力输出视频文件地址结束节点汇总返回“视频地址列表”和“分镜脚本/解说词全文”。这样设计的核心原因是让每个节点保持“单一职责”。尤其是大模型节点如果让它同时干“写菜谱写分镜写提示词”三件事输出格式几乎必然不稳定。拆开之后每个环节都只需要围绕一个明确目标准确率会高很多。2.2 数据流转逻辑节点之间的“交接棒”我把这套工作流里最核心的数据流转关系整理成了一张逻辑清单比看一堆配置更直观开始节点输出{dish_topic, video_style}大模型节点A读取dish_topic输出结构化JSON{ingredients[], steps[{name, detail, duration}]}大模型节点B读取节点A的JSON输出分镜数组{scenes[{description, shot_type, camera_move, subtitle, voiceover}]}代码节点读取scenes[].description逐个生成英文视频提示词插件节点循环调用视频生成拿到每个镜头的成片地址结束节点把所有地址和文案打包输出。整个流程里节点A和节点B之间的“交接棒”是最容易出问题的环节。所以我在设计Prompt时强制要求节点A输出严格的JSON并且字段名固定。这个细节在后面会专门展开。3. 节点Prompt设计如何让大模型的输出“可被下游直接消费”3.1 菜谱与结构节点用JSON把输出格式锁死这个节点的输入是菜名输出是“食材步骤时长”我用的核心指令是这样的你是一位资深美食编辑。请根据用户提供的菜名生成一份可用于视频拍摄的菜谱。 要求 1. 输出必须是严格JSON不要输出任何解释性文字。 2. JSON结构固定为 { dish_name: 菜名, ingredients: [食材1, 食材2], steps: [ {step_number: 1, action: 动作描述, duration_minutes: 5} ] } 3. steps数组按烹饪顺序排列每个step只描述一个重要动作用词具体例如“将番茄切成薄片”不要写“处理食材”这种模糊表达。 4. duration_minutes为预估拍摄时间不是烹饪时间。为什么要强调“输出严格JSON”因为后续的分镜脚本节点要把这段输出作为输入如果模型输出一段散文或者JSON前后带markdown标记解析就会失败。我在最早一版就是因为没锁格式结果10次运行里有一半在解析节点报错。3.2 分镜脚本节点把“怎么做菜”翻译成“怎么拍”分镜脚本节点是整个工作流里最讲经验的环节。它要完成一个翻译任务把菜谱步骤翻译成视频镜头语言。你是一位美食视频导演。请根据菜谱JSON生成8-12个镜头的分镜脚本。 输出格式严格为JSON数组 [ { scene_number: 1, description: 画面内容描述包含食材、动作、环境具体到色彩和质感, shot_type: 特写/中景/全景/俯拍, camera_move: 固定机位/缓慢推进/跟随摇移, subtitle: 画面上的字幕文案10字以内, voiceover: 配音旁白一行字口语化有节奏 } ] 要求 1. 第一个镜头必须是食材/环境的全景建立镜头最后一个镜头必须是成品摆盘特写。 2. 镜头之间要有因果逻辑比如“切番茄”的镜头后面必须接“番茄入锅”的镜头。 3. description要具体到动作和状态不要出现“切菜”“炒菜”这种宽泛词。这里我踩过的一个坑是如果不指定“第一个镜头必须是全景”模型会随机从特写开始导致整个视频没有环境和空间关系的交代非常跳脱。3.3 代码节点提示词转换与清洗分镜脚本节点输出的是中文画面描述但不少视频生成插件对中文提示词支持一般。我加了一个Python代码节点把中文描述转成更易出效果的英文提示词同时拼接一些通用风格词。import json def main(script_json: str, video_style: str cinematic food photography): scenes json.loads(script_json) prompts [] for scene in scenes: base scene[description] shot_type scene[shot_type] camera_move scene[camera_move] prompt ( f{base}, {shot_type}, {camera_move}, f{video_style}, high detail, 4k, warm lighting ) prompts.append(prompt) return {prompts: prompts, count: len(prompts)}在Coze的代码节点里输入变量名要和上游节点的输出变量名对齐这里我设置的输入是script_json和video_style输出是prompts和count。很多新手容易在这里踩坑代码节点里的参数名和上游输出名不一致导致运行时报“变量未定义”。4. 源码到手后的导入与调参五个关键位置不能只改不改4.1 工作流源码结构与导入步骤Coze工作流的“源码”在视觉呈现上是一套可视化的连线图但如果导出工程文件看到的其实是一组节点配置和连线关系的定义。你不需要完全手写这份JSON但至少要看得懂它这样排查问题时才知道去哪里改。一个典型的导出结构长这样{ workflow_name: ai_food_video_generator, nodes: [ { id: start_1, type: start, config: { inputs: [ {key: dish_topic, type: string}, {key: video_style, type: string, default: cinematic} ] } }, { id: llm_recipe, type: llm, config: { model: doubao-pro-32k, prompt_template: 你是资深美食编辑...省略, input_mapping: {dish_topic: {{start_1.dish_topic}}} } }, { id: code_1, type: code, config: { language: python, input_mapping: {script_json: {{llm_script.output}}}, source_code: def main(script_json, video_style...): ... } } ], edges: [ {from: start_1, to: llm_recipe}, {from: llm_recipe, to: llm_script}, {from: llm_script, to: code_1}, {from: code_1, to: plugin_video}, {from: plugin_video, to: end_1} ] }在Coze平台里导入这个工程的方式也很简单新建工作流后在画布右上角找到“导入/导出”入口把JSON上传平台会自动重建节点和连线关系。如果使用的是我上面的结构导入后你还需要逐个检查大模型节点的Prompt是否完整因为不同版本的平台在导出时对Prompt模板的转义会略有差异。4.2 五个反复需要确认的参数调试了几天我总结出五个换环境后最容易出问题的位置建议每次导入后逐一核对模型选择大模型节点里默认模型可能不是最优解。菜谱生成这类任务用32K上下文的中等模型就够用追求更高质量可以换更大的模型但响应速度和成本需要权衡。插件节点授权视频生成插件通常需要单独授权而且额度是独立的。导入工作流后必须重新检查插件状态我第一次就遇到“工作流导入成功但插件未授权”的情况。代码节点的变量名上游输出名、代码参数名、下游输入名三处必须完全一致。建议全部用小写下划线命名避免大小写不一致的问题。超时设置视频生成插件调用一次普遍需要一两分钟以上。大多数平台默认的节点超时时间可能不够我建议把插件节点的超时时间调到300秒以上。结束节点的输出映射结束节点需要手动把“视频地址列表”和“解说词全文”映射到输出参数。漏掉这一步工作流运行成功也拿不到结果。5. 实测排雷四个在调试中高频出现的问题及定位思路5.1 视频生成插件超时整个工作流直接失败最开始我设置的插件节点超时时间是默认值结果每次跑到视频生成这一步总是运行到一半就报超时。刚开始我还以为是插件不稳定后面发现是超时设置太短。定位方式很简单先在插件节点单独测试一次调用记录从发起到返回完整视频地址所需的秒数。以我用的插件为例生成一个5秒的720P片段大约需要90秒。三层循环跑下来整条链路跑完需要将近5分钟。所以我的处理方案是在插件节点配置里把超时时间调整为300秒并且把“失败重试次数”设为1次。同时在工作流外部测试时先用1~2个镜头的短脚本跑通不要一上来就生成8个镜头。5.2 大模型输出带多余字符代码节点解析失败这是运行报错频率最高的一个问题。大模型节点A输出JSON时偶尔会在首尾加上json和这种代码块标记。代码节点拿去json.loads()时直接抛异常。后来我用两个手段在Prompt层面解决一是明确要求“不要输出任何解释性文字不要使用Markdown代码块标记”二是在代码节点里加了一层容错处理把常见的多余字符剥掉再解析import json def parse_json_safe(raw): raw raw.strip() if raw.startswith(): raw raw.strip() if raw.startswith(json): raw raw[4:] return json.loads(raw)实测加了这个容错之后代码节点的失败率从大概20%降到了接近0。建议所有接大模型输出的代码节点都加类似的保护逻辑。5.3 生成的视频片段之间“接不上”食材状态跳变这是生成结果层面的坑比报错更隐蔽。首次跑通后我把所有镜头按顺序拼接起来发现前一个镜头里番茄已经切好了后一个镜头番茄又变回完整的了。这是视频模型对“跨镜头一致性”能力不强的表现目前阶段靠工作流是完全无法根治的。我的缓解思路是在分镜Prompt里强制要求每个镜头的description必须以“上一镜头的最终状态”为初始状态。比如第3个镜头是“将切好的番茄丁倒入锅中”第4个镜头就不能写成“番茄放进碗里”而要写成“锅中的番茄丁开始翻炒出汁”。这样至少能让单个动作链条内保持基本连贯。另外尽量把每个镜头的画面内容控制在“一个动作”内不要在一个镜头里塞多个动作否则生成质量会明显下降。5.4 成本失控一次完整工作流跑出的Token消耗比预想高很多做一个8镜头的视频我的工作流实际会调用节点A一次生成菜谱、节点B一次生成分镜、节点C一次生成英文提示词、插件八次。大模型部分Token消耗不算特别大真正的大头其实是视频生成的时长和次数。我建议在测试阶段把视频生成插件每次生成的时长调到最短有的插件支持5秒/10秒选项分辨率不要一上来就选4K。跑通整体链路之后再根据实际需求提升参数。否则调试一次的成本够正式生成好几条视频了。6. 从单条视频到批量栏目这套工作流还能怎么延伸6.1 批量模式做一个“每日一菜”自动选题机现在的输入节点一次只接收一个菜名如果你想做一个“每天更新美食视频”的账号可以把开始节点改成接收一个“本周菜名清单”在大模型节点A里循环生成多个菜谱再为每个菜谱独立执行后续的分镜、提示词转换和视频生成。当然这样一整条链路跑下来的时间会更长我建议在实际落地时拆成“两段式”第一段只跑菜谱生成和分镜设计把脚本先存下来第二段再逐条读取脚本执行视频生成。这样一旦某个镜头生成失败不需要重新跑整条大链路。6.2 联动发布渠道把“生产”和“分发”接上Coze工作流的一个优势是节点生态持续在扩展除了视频生成插件还能接入表格、飞书文档、消息通知等能力。我在扩展版本里就加了两个节点一个是把每次生成的分镜脚本和视频地址写入飞书多维表格用于存档另一个是生成完成后发一条通知到飞书群方便人工检查后再手动发布。内容自动生产确实能大幅提高效率但从我的实践经验看目前的AI视频生成要真正做到“全自动发布且内容质量稳定”还有比较长的路要走。所以我把发布环节保持人工确认生成环节全自动这也是我运行大半个月后觉得性价比最高的状态。6.3 换一个品类复用美食模板稍作修改就能跑通其他领域这套工作流的核心其实是“结构化内容流程”不只是美食专属。把大模型节点A的Prompt换成“旅游攻略生成”把分镜脚本节点Prompt换成“景点镜头设计”把首镜头的“食材全景”换成“目的地全景”那条流水线就变成了一条“AI旅游视频生成工作流”。我最近在用它做城市历史小视频结构基本不用大改。所以如果你照着这篇文章把美食视频工作流跑通了后续最值得做的一件事是保留这套节点骨架把它当成一个“内容视频化流水线模板”来对待。每次换赛道只需要迭代最前面的“内容结构化”节点和“分镜设计”节点的Prompt。最后分享一个我实际使用中很小的技巧在最终成片之前一定要把大模型生成的解说词读一遍去掉那些“首先、然后、最后”的标准AI腔换成口语化的短句。这不会影响视频生成的画面质量但会直接影响观众看到第一条视频时会不会继续往下看。画面决定了观众会不会点进来文案逻辑和节奏才决定了他愿不愿意看到最后。本文还有配套的精品资源点击获取