公司动态
本地AI设计工作流全指南:从ComfyUI搭建到批量生产实践
这几年凡是接触过 AI 设计的人大概都经历过同一个场景新项目定了二十张概念图预算有限版权要求又严素材还不能随便传到外部服务。于是“搞一套免费工具自己在本地跑”就成了很自然的想法。我也一样前前后后折腾过不少方案最后形成了一个判断——本地运行一套 AI 设计工作流真正值钱的不是省下订阅费而是把“AI 能出图”升级成“我能稳定地批量生产设计素材”。单张出图和持续产出是完全两码事。前者只要有一个好模型就能做到后者需要一套能承载需求、参数、批次、审核、归档的工作流系统。这篇文章不会给一份神奇的一键包而是会讲清楚一套免费、本地运行的 AI 设计工作流应该怎么选组件、怎么搭最小闭环、怎么从单张扩展到批量以及长期维护时最容易忽略的坑。1. 本地 AI 设计工作流的本质不是把工具搬到电脑里很多人第一次接触本地 AI 设计最关心的问题是哪个软件能免费跑装完能不能出图这两件事确实重要但如果只盯着工具本身很容易陷入“装软件、跑一张、然后吃灰”的循环。1.1 单次出图只是验证持续生产才是目标单次出图能证明三件事模型能加载、显存能撑住、结果确实好看。但它证明不了另外三件事换了输入之后结果是否稳定、批量任务跑一半失败能不能恢复、下个月换新模型时旧产出还能不能复现。我见过不少团队把 ComfyUI 装好之后第一周每天都很兴奋第二周就开始发现新问题工作流节点报错、批量跑一半显存溢出、出图风格漂移、输出文件乱堆放最终只能手动一张张挑。问题不在工具而在“用单次出图的思路去跑生产流程”。本地 AI 设计工作流的本质是把一次性的生成行为拆解成“输入 — 生成 — 验证 — 归档”四个稳定环节。每个环节都要有明确标准而不是看完一张图就决定整个流程行不行。1.2 免费与本地运行为什么值得认真考虑免费和本地运行不是营销话术它们有实实在在的工程价值。本地运行意味着数据不出机器。做设计的人应该都能理解这意味着什么内部参考图、未发布方案、客户素材这些内容放在自己的 GPU 上处理心理压力完全不同。免费则意味着成本结构变了。按张付费的平台每跑一批图你都要算一次成本本地运行则是“硬件一次投入 电费 维护时间”随着使用次数增加单张成本会持续下降。当然这不代表零成本后面会专门讲。1.3 我的建议先定一个小目标再选工具不管最终要不要搭一套完整的本地设计工作流我都建议先选一个真实的小任务做试点。目标不要定成“我要做一个媲美商业平台的方案”而是“我能不能稳定地每周产出五十张可供筛选的设计稿”。先把这个小闭环跑通再去讨论要接 Dify 还是 n8n要不要做 API 批量提交要不要加 LoRA 训练。否则很容易在选型阶段就耗尽耐心。2. 核心组件怎么选生成、编排、辅助各司其职一套本地 AI 设计工作流通常由三层组成生成层负责真正产出图像编排层负责流程串联辅助层负责存模板、管参数、记输出。很多人只盯着第一层导致后面全部靠手工。2.1 生成层ComfyUI 是最适合做工作流引擎的选择之一ComfyUI 是当前本地 AI 设计工作流里比较主流的一类方案。它的核心特点是节点式工作流把“加载模型 — 编写提示词 — 设置采样参数 — 保存图像”这些步骤拆成可视化的节点用连线串联起来。相比单窗口工具它更适合做批量生产原因有三点工作流可保存为 JSON同一套流程可以反复加载也能发给别人复现。可以切换 API 模式让程序自动提交任务而不是每次都在界面里手动点。节点高度可定制可以插入 LoRA、控制网络、放大模型、遮罩处理等中间步骤。不过 ComfyUI 的上手门槛也比“一键出图”类工具高一些。节点一多就乱版本更新也频繁换工作流文件时要格外小心兼容性。2.2 编排层Dify、n8n、Coze 和 Flowable 的差别生成层解决“图怎么出”编排层解决“任务怎么流转”。Dify可以本地部署擅长把大模型应用、知识库、工具 API 组装成完整 AI 应用。在 AI 设计工作流里它可以承担“需求理解”“Prompt 改写”“自动打标签”这类下游任务。n8n本地自动化流程工具适合定时触发任务、把生成结果推送到不同目录或通知管理员。Coze云端编排平台容易上手但与“本地运行”的目标不一致更适合快速验证流程逻辑不适合严格的数据本地化场景。Flowable偏向企业级审批流、业务流引擎和 AI 出图的协作关系不大。如果你的目标是让设计稿走审批流程它才有参考意义。我的建议是先不碰编排层让 ComfyUI 自己跑通最小闭环。等发现真正需要自动流转需求单、自动发通知、自动归档时再引入 Dify 或 n8n。过早接编排层只会增加排错面积。2.3 辅助层Prompt 模板、项目目录、命名规范这一层最不起眼但长期来看最影响幸福感。辅助层不需要专门软件而是需要一开始就建立一套约定。哪怕是几条规定每个项目一个独立目录目录命名用“日期-项目名”。Prompt 和 Seed 信息记录在每一批次结果里最好生成一个 JSON 文件。输出图按“小样、筛选、定稿”三级目录存放。没有这套约定三个月后回看自己生成的设计稿你根本不知道哪一张对应哪组参数。3. 从零搭一个最小可运行工作流这部分不追求大而全只做一个目标在一台有独立显卡的电脑上跑出第一张由本地模型生成的图片。所有安装步骤都以“你下载版本的官方说明”为准因为版本变化很快写死版本号反而容易误导。3.1 环境准备先确认硬件和基础软件首先确认两件事显卡显存8GB 起步会比较舒服16GB 以上能跑更高分辨率。驱动状态Windows 上建议先把 NVIDIA 显卡驱动升级到较新版本避免 CUDA 版本不匹配。然后安装基础软件# 示例结构安装 Python 虚拟环境相关工具 # 以你的系统包管理工具为准 python -m venv comfyui_env source comfyui_env/bin/activate如果你用的是 Windows可能还需要 Git 客户端用来下载代码。这些都不是必须的纯粹是工程习惯。3.2 获取 ComfyUI 源码并安装依赖从 ComfyUI 官方仓库获取最新源码然后进入目录安装依赖。这里只写通用命令# 示例结构在 ComfyUI 源码目录内执行 pip install -r requirements.txt官方对 Python 版本、PyTorch 版本、CUDA 版本通常会有明确要求。遇到安装失败不要直接换一个整合包先去看错误日志是缺哪个包。3.3 下载模型并放到正确位置ComfyUI 默认通过文件目录来识别模型。常见模型目录有模型类型常见目录作用Checkpoint 主模型models/checkpoints/出图的核心模型LoRA 模型models/loras/调整风格或人物一致性VAE 模型models/vae/改善图像色彩与细节从开源模型平台下载模型权重后放到对应目录。下载前一定看清楚模型卡页面上的许可协议。个人学习可以用的模型不一定允许商用。3.4 启动服务并跑第一张图启动命令通常是python main.py看到类似To see the GUI go to: http://127.0.0.1:8188的日志后用浏览器打开这个地址。默认工作流已经包含最基本的节点串联通常有“加载模型 / 输入正向提示词 / 输入负向提示词 / 空潜空间 / 采样器 / 保存图像”。直接点击界面里的Queue Prompt如果显卡工作正常几秒到几十秒后就能看到结果。第一张图跑通之后立刻做三件事把这个工作流保存下来命名成base_single_image.json。记录模型文件名、分辨率、采样步数、CFG、Seed。把输出图从临时截图目录移到正式项目目录。注意第一张图跑通只代表流程没有断不意味着工作流可以稳定生产。先不要急着换模型、调参数、批量跑先确认每一步都看得懂。4. 从单张到批量把出图变成生产流程单张跑通后马上要面对的问题是如果需要生成五十张图难道要手动改五十次提示词再点五十次按钮吗当然不是。ComfyUI 的价值就在它可以被当成后台服务调用。4.1 用 API 方式批量提交任务ComfyUI 在启动后除了提供 Web 界面还提供一个 API 接口。可以把你在界面上搭好的工作流导出成 API 格式的 JSON然后在 Python 脚本里修改参数并逐个提交。常见批量脚本逻辑是import json import requests # 示例结构加载从 Web UI 导出的 API 格式工作流 with open(workflow_api.json, r, encodingutf-8) as f: workflow json.load(f) # 1. 找到工作流里的提示词节点替换成当前批次的内容 # 2. 替换 Seed保证每张图不完全一样 # 3. 提交到本地 API # 4. 等待返回结果把图片保存到目标目录注意不同 ComfyUI 版本导出的 API 格式可能不一样。先在浏览器里确认界面右上角能开启“开发者模式”再导出带 API 的格式。批量跑之前一定要先小规模验证用三组不同的提示词手动确认输出内容和预期一致。等脚本能连续跑出三张正常图片再扩大到二十张、五十张。4.2 把 Dify 接进来需求、审核、交付当批量脚本稳定之后你会发现下一个瓶颈变成了“需求管理”。设计师不可能每次手工写 JSON 里的提示词。这时候可以把 Dify 接进来用一个表单收集设计需求Dify 应用把文字需求转成结构化 Prompt再通过 API 调用本地 ComfyUI 生成图片。Dify 本地部署通常依赖 Docker对内存有一定要求。如果你的电脑同时要跑 GPU 任务和 Docker 服务建议先评估资源占用。最简单的方式是 Dify 和 ComfyUI 分两台机器跑或者只在办公电脑上跑 Dify在 GPU 工作站上跑 ComfyUI。不要一上来就追求完整的业务闭环。先让 Dify 能调用 ComfyUI 的 API生成一张图再把结果回传就算打通了。4.3 质量验证不能每张图都直接交付批量生产的最大陷阱是“批量生产垃圾”。脚本能跑出一百张图不代表有一百张能交给客户。所以工作流里一定要加一个质量验证环节第一轮程序自动跑但只用于筛选不直接交付。第二轮人工从候选中挑出符合项目要求的图像记录对应的 Seed 和 Prompt。第三轮把挑选结果作为复盘样例反过来优化 Prompt 模板。这看起来慢实际上比“一次性生成五十张然后全盘返工”快得多。5. 参数不是玄学理解关键参数才能稳定复现很多人把 ComfyUI 里的参数当成“玄学”其实是把“需要理解”误当成了“不可理解”。核心参数就那几个每个都对应一个清晰的物理或采样含义。5.1 关键参数说明参数作用常见建议分辨率width/height直接影响显存占用和构图先从 512x768 或 768x768 起步再根据硬件上调采样步数steps控制去噪过程的迭代次数20-30 步大多够用过高步数不一定更好CFG控制生成结果贴合提示词的程度通常在 3-8 之间过低会发散过高会过饱和Seed随机种子决定噪声起始状态同一 Seed 同参数可复现替换 Seed 可出不同构图Batch Size一次生成几张图建议从 1 开始确认显存余量后再增加对设计工作流来说最关键的是记录 Seed。出图后如果觉得这张不错但需要微调 Prompt保留 Seed 可以让你在同一个构图上小改而不是完全随机重新画。5.2 显存与性能取舍显存不够时最常见的手段是降低分辨率。但降低分辨率会直接影响构图质量。另一个思路是保留分辨率减少 Batch Size跑完一张再跑下一张。也有加速方案比如显存优化参数或使用轻量模型但这些依赖具体环境不能一概而论。判断标准很简单看显存占用是否持续接近 100%。如果是就先降 Batch Size 或分辨率不要盲目加放大模型。5.3 如何复现一张好图复现的核心是“记录三件套”模型完整文件名、Prompt 全文、Seed 与参数。光记录 Seed 不够因为换一个模型同样的 Seed 会得到完全不同的图。光记录 Prompt 也不够采样方式和 CFG 变了结果也会差很多。所以我建议每次批量任务结束后自动生成一个同名 JSON 文件记录所有关键信息。这比在聊天记录里翻找历史配置可靠得多。6. 常见故障排查链路多数问题不是工具不行本地 AI 设计工作流最劝退人的时刻是启动报错、节点变红、出图全黑。但大部分问题有固定规律。6.1 先看现象再动配置遇到问题先别急着重装整套环境。先按下面顺序排查看现象是程序起不来还是出图失败还是出图质量差看输入模型文件在不在指定目录工作流文件是不是从新版或旧版导入提示词有没有明显冲突看环境Python 版本是否符合要求PyTorch、CUDA、显卡驱动是否匹配看参数分辨率是否超出显存Batch Size 是否过大采样步数是否正常看工具边界这个功能是否依赖单独的插件或自定义节点6.2 常见错误与处理方式现象大概率原因处理思路启动缺包Python 环境不完整查看终端报错安装对应依赖不要盲目重装工作流节点变红缺少自定义节点或节点版本不兼容用 ComfyUI Manager 找缺失节点或检查 JSON 来源出图全黑模型加载失败、VAE 缺失检查 checkpoint 路径与 VAE 配置显存溢出分辨率或 Batch Size 过高降低参数逐步测试批量任务卡住API 请求并发过高或单任务异常加日志、逐个提交观察失败的任务节点6.3 一个实际排查示例如果你导入一个别人分享的工作流提示“请安装缺失的包以使用此工作流”不要慌。通常说明工作流里引用了某些自定义节点而你的环境没有安装。先看终端日志找缺失节点名再用 ComfyUI Manager 安装缺失节点或者回到下载页看它要求安装哪些依赖。特别要注意下载来的工作流 JSON 可能是旧版本 ComfyUI 创建的节点接口已经变更装完插件也不一定能直接跑。这时候优先用作者标注的最低版本来验证。建议从网上获取工作流时先看明确标注的 ComfyUI 版本、必装节点和模型名称。任何不带版本的分享工作流都需要做好手动修节点的心理准备。7. 本地运行不等于零成本适用边界要认清“免费 本地运行”听起来很理想但它有明确的适用边界。如果不清楚边界很容易在错误场景里浪费时间。7.1 免费背后的三笔成本硬件成本一台够用的 GPU 机器并不便宜。时间成本安装、调试、修节点、做批量脚本都需要投入时间。维护成本模型更新、插件更新、显存清理、目录整理是持续存在的日常事务。如果把这些成本都算上本地方案更适合“长期、持续、批量”的使用场景。低频用一次的用户订阅云端更划算。7.2 适合本地运行的场景适合场景原因内部设计素材批量生成需要大量迭代数据不便于外传风格固定、需要反复调参本地多跑不心疼成本对隐私和版权敏感的项目文件不出机器需要把模型能力嵌入内部工具API 可控容易集成7.3 不适合本地运行的场景不适合场景原因没有独立显卡CPU 可以跑但效率很低偶尔才用一次维护成本分摊下来不划算需要极强的生成模型能力云端大型模型仍在持续升级多个成员需要跨网络协同本地搭建协作链路复杂度明显上升7.4 混合模式可能更现实实际工作中我越来越偏向混合模式本地用 ComfyUI 出图保证隐私和批量可控云端用在线大模型服务来理解自然语言需求、做文本总结或生成营销文案。两者通过 API 连接而不是强行把一切压在本机。这也是一种更成熟的工程思维不为了“全部本地”而牺牲能力也不为了“全部云端”而放弃控制权。8. 长期使用要把工作流沉淀成个人资产工具会换代模型会更新但一套良好的流程习惯不会浪费。本地 AI 设计工作流跑通三个月后真正有价值的已经不是某个节点图而是你围绕这套流程建立的目录规范、参数记录能力和复盘方法。8.1 目录与命名的可复用框架我常用的目录结构长这样projects/ 20250410_product_homepage/ input/ output/ preview/ selected/ prompts.json workflow_api.json models/ checkpoints/ loras/ vae/每条批次记录里至少包含项目名、日期、模型文件名、Prompt、反向 Prompt、分辨率、步数、CFG、Seed、批次数。8.2 每周一次小巡检长期维护不复杂只需要每周做一次小巡检清理 output 目录里的废弃预览图。检查模型目录里有没有重复体积的大文件。挑一批本周最佳输出记录它们的共同特征。更新 Prompt 模板库删掉无效写法。这套动作每次最多半小时但能避免三个月后整个目录变成一团乱麻。8.3 本地 AI 设计工作流的五个检查项最后留一个可复用的检查清单适合在任何节点停下来时问一遍输入是否可重复同一套工作流文件和模型文件换台机器还能复现吗参数是否有记录能不能说出某张好图对应哪个 Seed 和哪组参数输出是否有分类预览、筛选、定稿是不是分得清楚故障是否有路径出问题时能不能按日志快速判断是输入、环境还是参数维护是否有收益持续维护这套流程的成本是否低于它带来的产出这套工作流最迷人的地方不在于“我有了一个不用花钱的 AI 出图软件”而在于它把不可控的生成过程一点点变成可以由自己掌控的规则系统。免费和本地运行只是入口真正值钱的是可控、可复用、可批量、可沉淀。如果你也想搭一套我建议别先下载一堆模型。先选一个最小的任务比如“给一个产品页面生成三张封面草图”今天先跑通第一张。完成之后再沿着批量、编排、归档的路一步步走。很多问题只有在真正跑起来之后才会出现也只有那时候你才会真正理解自己的流程该怎么设计。