1. 这套流程到底解决什么问题做AI产品经理的人都有一个共同的痛点模型能力摸得差不多了但要把生成能力真正塞进业务流程里中间总隔着一道墙。ComfyUI本地跑图很爽可每次都要打开浏览器、拖节点、改参数、等出图、再手动保存发给同事——这套动作重复十次就让人崩溃。而飞书作为日常协作工具如果能做到“在飞书里发一句话图就自动生成并回传”那才是真正把AI能力产品化了。我最近花了两周时间把ComfyUI的图生图工作流和飞书机器人打通实现的效果是在飞书群里机器人并附上一张参考图机器人自动调用本地ComfyUI的图生图工作流生成结果后直接把图片发回群里。整个过程不需要打开ComfyUI界面不需要手动操作任何节点。这套方案特别适合AI产品经理、设计团队、电商运营这类需要批量出图但又不想被工具绑架的角色。核心关键词就几个ComfyUI图生图、飞书机器人、工作流自动化。下面我会从架构设计、环境搭建、工作流配置、飞书对接、问题排查五个维度把整个流程拆干净。2. 整体架构与方案选型思路2.1 为什么选ComfyUI而不是WebUI市面上做AI生图的工具不少WebUI和ComfyUI是最主流的两个。我选ComfyUI做这套流程的核心原因有三个。第一ComfyUI的API模式极其干净。它原生支持通过HTTP请求提交工作流并获取结果返回的是标准的JSON和图片数据对接任何外部系统都很顺滑。WebUI虽然也有API插件但稳定性和文档完整度差一截版本升级后接口经常变。第二工作流可复用、可版本管理。ComfyUI的工作流可以导出成JSON文件这意味着你可以把“图生图”的完整参数——模型选择、采样器、步数、CFG、降噪强度、ControlNet配置——全部固化成一个文件。团队里谁改了参数直接替换JSON就行不需要口头传达“你把那个滑块拉到0.7”。第三秋叶整合包降低了环境门槛。秋叶的ComfyUI整合包把Python环境、常用插件、模型目录结构全部预配置好了解压即用。对于AI产品经理来说不需要花两天时间折腾CUDA和依赖冲突这点非常关键。2.2 飞书作为交互层的优势飞书在这套流程里扮演的是“前端界面”的角色。为什么不用微信或者钉钉因为飞书的机器人开发文档最完整Webhook和事件订阅机制清晰而且飞书群组天然适合团队协作场景。你可以在一个群里同时让设计师、运营、产品经理看到生成结果直接评论、挑选、二次修改。飞书机器人的接入方式有两种Webhook自定义机器人和应用机器人。Webhook机器人只能发消息不能收消息适合“通知”场景应用机器人可以接收群消息和私聊消息适合“交互”场景。我们这套流程需要接收用户发的参考图所以必须用应用机器人。2.3 数据流转的完整链路整个系统的数据流是这样的用户在飞书群里机器人并发送一张参考图飞书服务器将消息事件推送到你的回调服务回调服务从事件中提取图片的file_key调用飞书API下载图片到本地回调服务读取ComfyUI的图生图工作流JSON模板将参考图路径和提示词注入通过HTTP POST将工作流提交到ComfyUI的/prompt接口轮询ComfyUI的/history接口直到任务完成从ComfyUI的输出目录读取生成图上传到飞书获取image_key调用飞书API将图片发送回群聊这条链路里回调服务是核心枢纽。我用Python的FastAPI写的大概两百行代码跑在一台带RTX 3060的Windows机器上。ComfyUI和回调服务在同一台机器通过localhost通信延迟极低。3. 环境搭建与ComfyUI工作流配置3.1 秋叶整合包的安装与国内源切换秋叶ComfyUI整合包的下载渠道在B站和GitHub上都有发布页搜“秋叶ComfyUI整合包”就能找到。下载后解压到一个路径中不含中文和空格的目录比如D:\ComfyUI。这一点非常重要ComfyUI的很多插件对中文路径支持不好后期出问题很难排查。解压后运行A绘世启动器.exe第一次启动会自动检测环境。如果提示缺少VC运行库按照启动器的指引安装即可。启动器里有一个“高级选项”可以切换pip源为国内镜像建议切到清华源或阿里源否则安装插件时下载速度会让你怀疑人生。启动ComfyUI后浏览器访问http://127.0.0.1:8188就能看到节点界面。默认端口是8188如果被占用可以在启动器的设置里改。3.2 图生图工作流的核心节点拆解图生图的工作流比文生图多了一个关键节点Load Image。这个节点负责加载参考图然后通过VAE Encode将图片编码成潜空间表示再送入KSampler进行去噪采样。一个最简图生图工作流包含以下节点Load Checkpoint加载大模型比如SD 1.5或SDXL的模型文件Load Image加载参考图输出IMAGE和MASKVAE Encode将参考图编码为LATENTCLIP Text Encode (Positive)正向提示词CLIP Text Encode (Negative)负向提示词KSampler核心采样器接收LATENT、模型、提示词VAE Decode将采样后的LATENT解码为图像Save Image保存最终图像其中KSampler的denoise参数是图生图最关键的一个值。denoise1.0时等同于完全重绘参考图只提供构图信息denoise0.4~0.6时保留较多原图特征denoise0.2以下基本只做微调。做产品图换背景一般用0.6~0.75做风格迁移用0.5~0.65做细节修复用0.3~0.45。3.3 工作流导出为API格式在ComfyUI界面里配置好工作流后点击菜单的“Save (API Format)”导出JSON。注意不是普通的“Save”而是API Format。两者的区别在于普通格式包含界面布局信息API格式只包含节点连接和参数更适合程序化调用。导出的JSON里每个节点的输入参数都是可以动态替换的。比如Load Image节点的image字段、CLIP Text Encode的text字段、KSampler的seed和denoise字段。回调服务要做的就是读取这个JSON模板把里面的占位值替换成实际值然后POST给ComfyUI。我建议在JSON模板里把需要动态替换的字段用特殊标记标出来比如{{INPUT_IMAGE}}、{{POSITIVE_PROMPT}}这样代码里做字符串替换更清晰不容易误伤其他字段。3.4 模型与插件的选择建议图生图的效果很大程度上取决于底模。做写实风格推荐用Realistic Vision或ChilloutMix做二次元用Anything V5或Counterfeit做通用场景用SDXL Base加Refiner。模型文件放在ComfyUI/models/checkpoints/目录下。插件方面ComfyUI Manager是必装的它可以在界面里直接搜索和安装其他插件。ControlNet Aux插件提供了OpenPose、Depth、Canny等预处理节点做精确控制时很有用。Impact Pack提供了面部修复和细节增强节点出图质量能提升一个档次。注意插件不是越多越好。每装一个插件都会增加启动时间和内存占用而且插件之间可能冲突。建议只装当前工作流用到的保持环境干净。4. 飞书机器人对接与回调服务实现4.1 飞书应用创建与权限配置在飞书开放平台open.feishu.cn创建一个“企业自建应用”。创建后需要配置几个关键项机器人能力在“添加应用能力”里开启机器人事件订阅配置请求地址为你的回调服务公网地址订阅im.message.receive_v1事件权限管理至少需要im:message、im:message:send_as_bot、im:resource这三个权限图片上传需要im:resource权限才能上传图片到飞书事件订阅的请求地址需要是HTTPS的公网地址。如果你在本地开发可以用内网穿透工具把本地端口映射出去。飞书在配置请求地址时会发送一个challenge验证请求你的服务需要正确响应才能保存成功。4.2 回调服务的核心代码逻辑回调服务用FastAPI实现核心逻辑分四步。第一步验证请求并解析事件。飞书推送的事件是加密的需要用应用的Encrypt Key解密。解密后拿到事件体判断事件类型是否为im.message.receive_v1然后提取消息内容。第二步下载参考图。消息体里图片是以file_key形式存在的需要调用飞书的im/v1/messages/{message_id}/resources/{file_key}接口下载。下载后保存到本地临时目录路径传给ComfyUI。第三步提交ComfyUI任务。读取工作流JSON模板替换占位字段构造POST请求发送到http://127.0.0.1:8188/prompt。返回结果里有一个prompt_id用于后续查询任务状态。第四步轮询结果并回传。每隔2秒查询http://127.0.0.1:8188/history/{prompt_id}直到状态变为completed。然后从输出目录读取生成的图片调用飞书图片上传接口获取image_key最后调用消息发送接口把图片发回群聊。import requests import json import time def submit_to_comfyui(workflow_path, input_image, positive_prompt): with open(workflow_path, r, encodingutf-8) as f: workflow json.load(f) workflow_str json.dumps(workflow) workflow_str workflow_str.replace({{INPUT_IMAGE}}, input_image) workflow_str workflow_str.replace({{POSITIVE_PROMPT}}, positive_prompt) workflow json.loads(workflow_str) resp requests.post( http://127.0.0.1:8188/prompt, json{prompt: workflow} ) return resp.json()[prompt_id] def wait_for_result(prompt_id, timeout300): start time.time() while time.time() - start timeout: resp requests.get(fhttp://127.0.0.1:8188/history/{prompt_id}) history resp.json() if prompt_id in history: outputs history[prompt_id][outputs] for node_id, node_output in outputs.items(): if images in node_output: return node_output[images] time.sleep(2) return None这段代码是整个回调服务的骨架。实际部署时还需要加上异常处理、日志记录、并发控制。特别是并发控制ComfyUI同时只能处理一个任务如果多个人同时发图需要排队。4.3 飞书消息发送的细节处理飞书发送图片消息需要先上传图片获取image_key。上传接口是im/v1/images用multipart/form-data格式字段名为image_type和image。image_type填message表示用于发送消息。上传成功后拿到image_key构造消息体{ receive_id: oc_xxx, msg_type: image, content: {\image_key\: \img_xxx\} }注意content字段是字符串化的JSON不是嵌套对象。这个坑我踩过一开始直接传对象飞书返回参数错误排查了半天。如果要同时发送文字说明和图片可以发一条富文本消息post类型里面同时包含文字和图片。或者简单点先发一条文字消息说明“正在生成”生成完再发图片消息。4.4 公网地址与安全校验回调服务需要暴露到公网才能接收飞书的事件推送。我用的是内网穿透工具把本地的8000端口映射到一个HTTPS地址。飞书要求请求地址必须是HTTPS且证书有效。安全方面飞书的事件推送支持签名校验。在应用的“事件订阅”页面可以设置Verification Token你的服务在收到请求时需要校验这个token防止伪造请求。虽然内网穿透地址不容易被猜到但加上校验更稳妥。提示回调服务的响应必须在3秒内返回否则飞书会认为推送失败并重试。所以收到事件后应该立即返回200然后在后台异步处理图片生成。不要把耗时的ComfyUI调用放在请求处理的主流程里。5. 常见问题与排查技巧实录5.1 ComfyUI任务提交失败最常见的报错是prompt is required或invalid prompt。这通常是工作流JSON格式不对。API Format的JSON顶层是一个对象每个key是节点IDvalue是节点的定义。如果你导出的是普通格式里面会多一层nodes数组和links数组直接提交会报错。另一个常见问题是节点ID不匹配。工作流JSON里的节点ID是ComfyUI自动生成的数字如果你在代码里硬编码了某个ID去替换参数换一个工作流后ID变了就会替换错位置。建议用节点标题title来定位或者维护一个ID映射表。5.2 图片下载与路径问题飞书下载的图片是二进制流保存到本地时要确保扩展名正确。飞书返回的Content-Type可能是image/jpeg或image/png根据这个设置扩展名。如果保存成.tmp或者无扩展名ComfyUI的Load Image节点可能无法识别。路径中的反斜杠在JSON里需要转义。Windows路径D:\ComfyUI\input\ref.png在JSON字符串里要写成D:\\ComfyUI\\input\\ref.png。或者直接用正斜杠D:/ComfyUI/input/ref.pngPython和ComfyUI都能识别。5.3 生成结果与预期不符图生图最常见的“翻车”是生成结果和参考图差距太大或太小。差距太大通常是denoise值太高试试降到0.5以下。差距太小通常是denoise太低或者CFG太低导致模型没有足够“发挥空间”。还有一个容易被忽略的因素是参考图的尺寸。如果参考图是1024x1024而工作流里的Empty Latent Image设置的是512x512VAE Encode出来的latent尺寸和采样器期望的尺寸不匹配会导致生成结果变形。解决办法是在Load Image后面加一个Image Scale节点统一缩放到目标尺寸。5.4 飞书机器人无响应如果机器人后没有任何反应按以下顺序排查检查事件订阅的请求地址是否可访问飞书开放平台有“重新验证”按钮检查回调服务的日志看是否收到了事件推送检查机器人是否被添加到了群聊且群聊设置里允许机器人接收消息检查应用的权限是否已发布未发布的权限变更不会生效如果机器人回复了但图片发送失败大概率是image_key获取失败。检查上传图片时的image_type是否正确以及应用是否有im:resource权限。5.5 性能优化与并发处理ComfyUI默认是单任务队列同时提交多个任务会排队。如果团队人多建议加一个简单的任务队列用Redis或者Python的queue模块实现。每个任务记录提交者、提交时间、状态生成完成后按顺序回传。出图速度方面RTX 3060跑SD 1.5的图生图512x512大概3-5秒一张1024x1024大概15-20秒。如果觉得慢可以降低采样步数20步够用、换用DPM 2M Karras采样器、开启xFormers加速。问题现象可能原因排查方法提交任务返回404ComfyUI未启动或端口不对浏览器访问127.0.0.1:8188确认生成图为空白VAE Decode节点连接错误检查工作流连线图片发回群聊失败image_key无效或权限不足检查im:resource权限机器人重复回复飞书事件重试机制加消息去重逻辑生成速度极慢显存不足或模型太大换小模型或降低分辨率6. 从产品经理视角看这套流程的扩展价值6.1 批量出图的业务场景这套流程最直接的价值是批量处理。电商团队每天要出几十张商品图传统方式是设计师一张张修现在可以写一个脚本把商品图列表和对应的提示词批量提交ComfyUI自动跑完结果自动发到飞书群里。设计师只需要在群里挑选和微调效率提升非常明显。另一个场景是A/B测试。同一个参考图用不同的提示词或不同的denoise值生成多张发到飞书群里让团队投票。这种快速迭代的能力在传统工作流里需要反复打开工具、改参数、导出、发送现在一句话就能触发。6.2 与飞书多维表格的结合飞书多维表格是一个被低估的工具。你可以把生成任务写进多维表格每一行是一条任务记录包含参考图链接、提示词、状态、生成结果。回调服务读取表格中的待处理任务生成完成后回写状态和图片链接。这样整个生成过程就是可追溯、可统计的。多维表格还支持自动化流程比如“当状态变为已完成时发送通知到群聊”。结合飞书的自动化能力可以做到完全无人值守的出图流水线。6.3 工作流的版本管理与团队协作ComfyUI工作流JSON文件建议用Git管理。每次调整参数或节点后提交一个新的版本写清楚改了什么、为什么改。团队成员拉取最新JSON就能用同样的参数出图避免“我这边效果怎么不一样”的扯皮。如果团队里有人不熟悉ComfyUI可以做一个简单的Web界面把常用参数暴露出来——参考图上传、提示词输入、风格选择——背后调用固定的工作流。这样非技术成员也能用而技术成员仍然可以在ComfyUI里做深度调整。6.4 成本与资源考量这套方案的成本主要是硬件。一台带RTX 3060 12G的机器二手大概1500-2000元跑SD 1.5和SDXL都够用。如果团队规模大可以考虑租云GPU按小时计费不用的时候关掉。飞书方面自建应用和机器人能力都是免费的API调用也有充足的免费额度。对于中小团队来说这套方案的初始投入很低主要是时间成本——搭建和调试大概需要两三天。我个人在实际操作中的体会是不要一开始就追求完美的工作流。先用最简的图生图跑通全流程确认飞书能收到图、ComfyUI能出图、结果能回传然后再逐步加ControlNet、面部修复、高清放大这些节点。每加一个节点都要重新测试全链路否则出了问题很难定位是哪个环节的锅。最后分享一个小技巧在回调服务里加一个“调试模式”开启后把所有中间结果——收到的消息体、下载的图片路径、提交的工作流JSON、ComfyUI的返回、上传飞书的响应——全部写到一个日志文件里。出问题的时候直接看日志比在代码里打断点快得多。这个习惯帮我省了至少十几个小时的排查时间。