别让AI瞎画图！用n8n+nano构建高质量视频生产SOP

别让AI瞎画图！用n8n+nano构建高质量视频生产SOP 别让AI瞎画图！用n8n+nano构建高质量视频生产SOP Modified August 30, 2025 Audio or video is not supported Please download the file and open it with the appropriate software. n8n+nano+tg.mp4 · 127.42MB n8n+nano+tg 00:00 让我们先看看最简单的文生图流程： Code block Plain Text Copy Telegram Trigger → AI意图分析 → 路由判断 → 生图/修图 → 结果推送 第一个节点当然是Telegram Trigger。 用户在 TG 里输入任何消息，n8n 都会实时接收到，数据结构如下： Code block JSON Copy [ { "update id": 968087117, "message": { "message id": 342, "from": { "id": 12345678, "is bot": false, "first name": "L", "language code": "en" }, "chat": { "id": 12345678, "first name": "L", "type": "private" }, "date": 1756517697, "text": "请将此角色的截图转化为一个3D风格角色形象。在其背后放置一个印有角色图像和的手办包装盒。在其旁边添加一台电脑，屏幕上显示建模场景，包括界面和这个3D角色的建模场景。在包装盒前方添加一个圆形塑料底座，让角色站立其上。底座的PVC材料应具有水晶般清晰、半透明的质感，并将整个场景设定在室内。" } } ] 这个 JSON 包含了所有我们需要的信息：用户ID、聊天ID、消息内容等。 二）如何处理修图需求？ 这里遇到一个技术难点！ TG 每发送一条消息，n8n 就会立即接收并处理。对于纯文生图没问题，但修图怎么办？用户的参考图从哪来？ 我总不能让用户先发图片，再发提示词吧？那用户体验就太割裂了。 三）Human in the Loop：优雅的解决方案 这时候就要请出我们的杀手锏了——Human in the Loop节点！ 1、什么是 Human in the Loop？ 简称 HITL，听起来像是某种高深的 AI 概念。实际上？它就是"让人类在关键时刻做决定"的fancy说法。 想象一下：你的系统能够自动处理 95% 的日常任务，但在那关键的 5% 时刻——需要额外输入、需要人工判断、需要上传文件时——它会优雅地暂停，等待你的操作。 2、HITL 在 n8n 中的妙用 在我们的场景中，HITL 完美解决了"图片上传时机"问题： 🤔 1. 用户发送修图需求："把这个角色改成3D风格" 2. AI 判断需要参考图：分析出这是修图请求 3. HITL节点暂停执行：弹出上传界面，等待用户上传参考图 4. 用户上传图片：通过 web 界面上传需要修改的原图 5. 工作流继续执行：拿到图片+提示词，调用 Nano API 四）完整的工作流架构 让我详细介绍这个复杂但强大的工作流： 1、第一层：智能意图识别 Telegram Trigger → Basic LLM Chain 这里用的是 DeepSeek 模型，专门用来分析用户意图： 提示词 Bash Copy 请分析以下用户请求，判断用户的意图： 用户消息："{{ $json.message.text }}" 请按以下JSON格式回复： { "intent": "image edit" 或 "image generate", "confidence": 0 100之间的数字, "reasoning": "判断理由", "requires existing image": true或false, "suggested response": "建议回复给用户的消息" } 判断规则： 1. 如果用户提到"把这个/这张/这辆..."、"将...改为..."、"修改..."、"编辑..."、"更改颜色"、"变成..."等，通常需要一张现有图片进行编辑 2. 如果用户说"画一个..."、"生成..."、"创建..."、"我想要一张...图片"等，通常是要从零生成图片 3. 如果用户使用了指示代词（这个、这张、它）但没有上传图片，很可能需要图片编辑 4. 考虑上下文语境，比如"现在将颜色更改为黄色"明显是在讨论已存在的物体 示例分析： "把这辆车变成敞篷车" → image edit（指示代词"这辆"） "现在将颜色更改为黄色" → image edit（"现在"暗示正在修改某个现有物体） "画一只可爱的猫咪" → image generate（明确的生成请求） "生成一张海边日落的图片" → image generate（明确的生成请求） "让这只狗变成金毛" → image edit（指示代词"这只"） 2、第二层：智能路由分发 Structured Output Parser → IF节点 解析 AI 返回的 JSON 结果，根据intent字段进行路由： • image generate → 走生图分支 • image edit → 走修图分支 3、第三层：分支处理逻辑 生图分支（简单）： Code block Plain Text Copy IF(generate) → "发送生图提醒" HTTP Request → Edit Fields → Convert to File → 图片发送 修图分支（复杂）： Code block Plain Text Copy IF(edit) → HITL等待上传 → Code处理 → HTTP Request → Edit Fields → Convert to File → 图片发送 Audio or video is not supported Please download the file and open it with the appropriate software. n8n+nano+tg.mp4 · 127.42MB n8n+nano+tg 00:00 Audio or video is not supported Please download the file and open it with the appropriate software. n8n+nano+tg.mp4 · 127.42MB n8n+nano+tg 00:00 让我们先看看最简单的文生图流程： 第一个节点当然是Telegram Trigger。 用户在 TG 里输入任何消息，n8n 都会实时接收到，数据结构如下： 这个 JSON 包含了所有我们需要的信息：用户ID、聊天ID、消息内容等。 二）如何处理修图需求？ 这里遇到一个技术难点！ TG 每发送一条消息，n8n 就会立即接收并处理。对于纯文生图没问题，但修图怎么办？用户的参考图从哪来？ 我总不能让用户先发图片，再发提示词吧？那用户体验就太割裂了。 三）Human in the Loop：优雅的解决方案 这时候就要请出我们的杀手锏了——Human in the Loop节点！ 1、什么是 Human in the Loop？ 简称 HITL，听起来像是某种高深的 AI 概念。实际上？它就是"让人类在关键时刻做决定"的fancy说法。 想象一下：你的系统能够自动处理 95% 的日常任务，但在那关键的 5% 时刻——需要额外输入、需要人工判断、需要上传文件时——它会优雅地暂停，等待你的操作。 2、HITL 在 n8n 中的妙用 在我们的场景中，HITL 完美解决了"图片上传时机"问题： 🤔 1. 用户发送修图需求："把这个角色改成3D风格" 2. AI 判断需要参考图：分析出这是修图请求 3. HITL节点暂停执行：弹出上传界面，等待用户上传参考图 4. 用户上传图片：通过 web 界面上传需要修改的原图 5. 工作流继续执行：拿到图片+提示词，调用 Nano API 1. 用户发送修图需求："把这个角色改成3D风格" 2. AI 判断需要参考图：分析出这是修图请求 3. HITL节点暂停执行：弹出上传界面，等待用户上传参考图 4. 用户上传图片：通过 web 界面上传需要修改的原图 5. 工作流继续执行：拿到图片+提示词，调用 Nano API 四）完整的工作流架构 让我详细介绍这个复杂但强大的工作流： 1、第一层：智能意图识别 Telegram Trigger → Basic LLM Chain 这里用的是 DeepSeek 模型，专门用来分析用户意图： 2、第二层：智能路由分发 Structured Output Parser → IF节点 解析 AI 返回的 JSON 结果，根据intent字段进行路由： • image generate → 走生图分支 • image edit → 走修图分支 3、第三层：分支处理逻辑 生图分支（简单）： 修图分支（复杂）： • 说明下一步操作：降低用户困惑 • 设定合理期待：让用户知道这不是瞬间完成的 从用户心理学角度，这种"确认+引导"的回复方式比简单的"请稍候"要友好得多。 我们可以看到这里的 Respond 是可以点击的。 2、HITL节点配置 打开后，这个就是需要用户介入参与上传原图的一个入口，这里就是由 HITL 节点配置的。 这里有个很容易被忽视的技术点：Response Type 的选择。 我选择了Custom Form而不是默认的 Approval，为什么？ 如果用Approval，用户只能要么同意，要么拒绝，和现在我们的场景不符合，我们的需求是要和表单交互的。 配置其实非常简单，所以 Response Type 选了 Custom Form 类型，这样就可以自定义表单元素了，用户后面想提交什么信息，都是可控的。 3、Code节点数据处理 HITL 收到图片后，最复杂的就是数据整合。我们需要把两个不同来源的数据合并： • 用户的原始提示词（来自Telegram） • 上传的参考图片（来自HITL） 具体代码这边我就不贴了，和第四章节的 Code 节点相差无几。 4、 结果处理和发送 其实不论哪个分支，生成的图片直接发送回原 TG 对话，推送到用户聊天，这块比较简单，直接用的 Send Photo。 到这一步，我们的 n8n + Nano 对接流程就算是完整实现了！ 不过我们还可以进一步扩展。比如看到有网友把生成的图片做成视频，或者集成到其他平台。这就是自动化的魅力：一旦基础流程跑通，想象力就是唯一的限制！ 六）即梦图生视频 看到生成的图片效果这么好，我突然有个大胆的想法：能不能让这些图片动起来？ 正好想起之前玩过即梦AI的视频生成功能，何不把两者结合一下？ 技术方案的巧妙复用 不得不说，即梦的视频生成流程和我们之前分享的 小红书高质量图文批量生产 的文生图流程非常像！ 小红书高质量图文批量生产 基本架构完全一样： 唯一的区别就是几个参数不同，核心逻辑几乎可以直接复用。这就是模块化设计的好处！ 具体的详细接口我这里就不多做阐述了，大家看官方文档即可。 📌 即梦AI 视频生成3.0 Pro 接口文档（公测）https://www.volcengine.com/docs/85621/1777001 即梦AI 视频生成3.0 Pro 接口文档（公测）https://www.volcengine.com/docs/85621/1777001 六、总结：最落地的 AI 内容生产 SOP 回顾这整个技术探索过程，我发现最有价值的不是单一的技术实现，而是形成了一套完整的 AI 内容生产标准作业流程： 生图 → 人工确认 → 生视频 🤔 为什么这套 SOP 最实用？ 成本控制：先用便宜的图片验证创意，再投入昂贵的视频制作。避免了直接生视频的试错成本。 质量保证：人工确认环节确保每一步的输出质量，不会让错误在后续流程中放大。 用户体验：在关键节点保持人类控制权，既享受自动化效率，又不失去创作主导权。 为什么这套 SOP 最实用？ 成本控制：先用便宜的图片验证创意，再投入昂贵的视频制作。避免了直接生视频的试错成本。 质量保证：人工确认环节确保每一步的输出质量，不会让错误在后续流程中放大。 用户体验：在关键节点保持人类控制权，既享受自动化效率，又不失去创作主导权。 模块化设计让每个环节都可以独立替换：生图可以换成其他 AI 模型，视频也可以接入不同服务商。不被单一平台绑定。 核心观点：AI 的价值不在于完全替代人类，而在于放大人类的判断力。让 AI 处理执行，让人类专注创意和决策。 这才是 AI 时代内容创作的正确姿势：人机协作，而非人机对抗。 我是林月半子，关注我，带你一起挖掘工作流自动化的无限可能。 🔗 原文链接：https://mp.weixin.qq.com/s/PYcXO2MDuPsTYEeS fFMtg ⏰ 发布时间：2025 08 30 22:06:00 (UTC+8) 作者：林月半子的AI笔记 最近几天，Nano Banana 简直火得不行！无论国内外，教程满天飞。作为一个专业搞 n8n 的，我当然坐不住了——必须得整个自动化流程出来。 正好发现 OpenRouter 上的 Nano 模型完全免费。这不是白嫖的好机会吗？ 一、为什么选择这个技术栈？ 说实话，单独用 Nano 生图确实很香，但我们程序员的思维就是：能自动化的绝不手动！ 我设计了三个递进的方案： 1. 聊天生图 最基础的文生图流程 2. 表单修图 上传图片进行 AI 修图 3. Telegram 集成 在 TG 里直接下命令，后台自动跑流程 从简单到复杂，逐步进阶。 二、OpenRouter API：免费 Nano 模型的正确打开方式 既然要白嫖 OpenRouter 的免费接口，咱们得先搞清楚怎么用。 一）获取API Key 首先去 OpenRouter 官网注册账号，然后在设置页面生成 API Key。免费账户有一定额度限制，但对于测试和轻量使用完全够了。 二）API 文档解读 💡 OpenRouter 的 Nano 模型 API 地址： https://openrouter.ai/google/gemini 2.5 flash image preview:free/api OpenRouter 的 Nano 模型 API 地址： https://openrouter.ai/google/gemini 2.5 flash image preview:free/api 官方提供了多种语言的示例代码： cURL示例： 我们在 n8n 里主要用 HTTP Request 方式来对接，所以只需要看 curl 模式即可，下面是它的案例 关键参数说明 • model：指定要用的模型，这里是 “google/gemini 2.5 flash image preview:free”。 • messages：对话内容，可以包含文本和图片 URL。 • api key：你的 OpenRouter API 密钥。 💡 关键参数详解： 1. model字段："google/gemini 2.5 flash image preview:free" ◦ 这是 OpenRouter 上免费的 Nano 模型标识 ◦ 注意最后的:free后缀，这表示使用免费版本 2. messages结构： ◦ role: 固定为"user" ◦ content: 数组格式，可以包含多种类型的内容 3. content类型支持： ◦ type: "text": 纯文本提示词 ◦ type: "image url": 图片URL，支持 HTTP 链接和 Data URI 4. 图片格式支持： ◦ HTTP/HTTPS 链接：直接传图片URL ◦ Data URI：data:image/jpeg;base64,{base64数据} ◦ 支持JPEG、PNG、GIF 等常见格式 关键参数详解： 1. model字段："google/gemini 2.5 flash image preview:free" ◦ 这是 OpenRouter 上免费的 Nano 模型标识 ◦ 注意最后的:free后缀，这表示使用免费版本 ◦ 这是 OpenRouter 上免费的 Nano 模型标识 ◦ 注意最后的:free后缀，这表示使用免费版本 2. messages结构： ◦ role: 固定为"user" ◦ content: 数组格式，可以包含多种类型的内容 ◦ role: 固定为"user" ◦ content: 数组格式，可以包含多种类型的内容 3. content类型支持： ◦ type: "text": 纯文本提示词 ◦ type: "image url": 图片URL，支持 HTTP 链接和 Data URI ◦ type: "text": 纯文本提示词 ◦ type: "image url": 图片URL，支持 HTTP 链接和 Data URI 4. 图片格式支持： ◦ HTTP/HTTPS 链接：直接传图片URL ◦ Data URI：data:image/jpeg;base64,{base64数据} ◦ 支持JPEG、PNG、GIF 等常见格式 ◦ HTTP/HTTPS 链接：直接传图片URL ◦ Data URI：data:image/jpeg;base64,{base64数据} ◦ 支持JPEG、PNG、GIF 等常见格式 请求体示例（纯文生图）： 请求体示例（图片+文本）： 我们可以看到接口其实是非常简单的，那么我们下面开始对接吧。 三、聊天生图 流程设计 第一步，拖个On Chat Message节点。用户在聊天界面输入提示词，工作流自动触发。 接着是HTTP Request节点。 这里有个小技巧：直接用import cURL功能！把上面的 curl 命令粘贴进去，n8n 会自动解析配置。 ⚠️ 重要提醒：千万别直接在 Header 里写 API Key！用凭证模式，安全性拉满。 即使分享工作流也不会泄露密钥。 重要提醒：千万别直接在 Header 里写 API Key！用凭证模式，安全性拉满。 即使分享工作流也不会泄露密钥。 另外我们还需要调整一下 Body 部分，这次我们只需要生图，所以只保留文字部分即可，然后将接受提示词的改成从 chatinput，如下所示 处理返回结果 接下来我们可以直接用官方的提示词来做下测试，直接给出了响应。 Nano 返回的是 Data URI 格式的 base64 图片。我们需要提取纯净的 base64 数据： 用Set Fields节点，表达式写成： 最后加个 Convert to File 节点，将 Base64 直接转换成文件，搞定！ 测试结果相当给力，生图质量没得说。 四、表单修图 单纯的文生图？那只是 Nano Banana 的基础技能！它真正让人惊艳的是修图能力。什么换装、换背景、风格转换，统统不在话下。 但这里有个技术难点：修图必须要上传原图。这就需要我们处理文件上传、格式转换等一系列复杂操作。 一）为什么选择 n8n Form？ n8n Form 有几个独特优势： • 原生集成：无需第三方服务，数据直接流转 • 文件处理：内置 binary 数据处理能力 • 自定义性强：可以精确控制每个字段的行为 二）表单设计的考虑 我设计了两个核心字段： 1. 提示词输入框 ◦ 类型：长文本 ◦ 必填：是 ◦ 占位符：例如"把这个人的衣服换成红色" ◦ 类型：长文本 ◦ 必填：是 ◦ 占位符：例如"把这个人的衣服换成红色" 2. 参考图上传 ◦ 类型：文件上传 ◦ 必填：否（重要！） ◦ 限制：jpg/png ◦ 类型：文件上传 ◦ 必填：否（重要！） ◦ 限制：jpg/png 📌 这里为什么参考图设为"非必填"？因为我们要复用这个通道！ 用户可能有两种需求： 1. 纯文生图：只填提示词，不上传图片 2. AI修图：提示词+参考图 一个表单搞定两种场景，用户体验更流畅。 这里为什么参考图设为"非必填"？因为我们要复用这个通道！ 用户可能有两种需求： 1. 纯文生图：只填提示词，不上传图片 2. AI修图：提示词+参考图 一个表单搞定两种场景，用户体验更流畅。 三）Code节点：数据转换的核心 我这边为了快速处理，直接让 AI 生成了一段 Code，让它直接根据我上面描述的情况，生成了一段 OpenRouter 需要的 Payload 参数，具体代码如下。 执行效果如下图 四）HTTP Request 节点的简化配置 经过Code节点处理后，HTTP Request就简单多了： Body配置： {{ $json }} 就这么简单！因为所有复杂的数据组装都在 Code 节点完成了。 五）实战测试 这里我们直接最近超火的将图片转成手办做一下测试 💡 提示词 请将此角色的截图转化为一个3D风格角色形象。在其背后放置一个印有角色图像和的手办包装盒。在其旁边添加一台电脑，屏幕上显示建模场景，包括界面和这个3D角色的建模场景。在包装盒前方添加一个圆形塑料底座，让角色站立其上。底座的PVC材料应具有水晶般清晰、半透明的质感，并将整个场景设定在室内。 提示词 请将此角色的截图转化为一个3D风格角色形象。在其背后放置一个印有角色图像和的手办包装盒。在其旁边添加一台电脑，屏幕上显示建模场景，包括界面和这个3D角色的建模场景。在包装盒前方添加一个圆形塑料底座，让角色站立其上。底座的PVC材料应具有水晶般清晰、半透明的质感，并将整个场景设定在室内。 然后我们就会得到了。 生成效果： 完全超出预期！不仅服装细节完美复刻，连妆容的细微差别都处理得很到位。头饰、配饰的质感也非常真实。 这就是 Nano Banana 的厉害之处——它不是简单的"换脸"，而是真正理解了角色特征，然后进行智能融合。 五、Telegram 集成 真正的自动化 前面两个方案虽然实用，但还是太"手工"了。作为一个重度 TG 用户，我理想的体验是：在群里@机器人，丢个需求，图片自动就来了！ 这才是真正的自动化嘛。 一）基础流程设计 五）修图分支的详细实现 这是整个工作流最复杂也最有趣的部分！让我逐步拆解每个环节的设计思路和技术细节。 1、用户体验优化 当 AI 判断出用户想要修图时，我们不能让用户干等着。立即给个反馈是基本的产品思维。 即时回复消息： 这个回复有几个巧思： • 重复用户需求：证明 AI 真的"听懂"了