企业官网建设流程全解析

本地 ComfyUI 出图的人大概都有这个体会：图能跑出来，但“管图”这件事本身特别费人。手动拖工作流、一张张点 Queue、等出图、再手动改文件名、挪文件夹，偶尔忘了关显存占用，下一批任务直接给你报 OOM。我自己的出图需求一多起来，就明显感觉 ComfyUI 像是台性能不错的发动机，但缺一条把它串起来的流水线。后来我花时间把 WorkBuddy 用起来，把本地 ComfyUI 接成了一条能批量提交、自动归档、出问题自己重试的出图流水线。这篇文章就是我自己搭这套东西的完整记录，包括设计思路、接入配置、实操步骤和踩过的坑，给同样在折腾本地出图、想从手动跑图里解放出来的人一个参考。

无论你是主要跑 SD 模型，还是用 ComfyUI 做电商图、角色设定、风格测试，这套思路都能套。全文不涉及花钱买服务，全部基于本地已有环境，工具选型也是自己能控制的那种，核心就三个词：可重复、可追踪、可批量。

1. 为什么会把 ComfyUI 管成“流水线”：从手动跑图到批量出图的痛点

1.1 本地 ComfyUI 跑图最让人上火的三个瞬间

先说一个真实感受：ComfyUI 本身是个好工具，节点化操作确实灵活，但灵活的反面是“自由过了头”。我的工作流会同时用基础模型、几个 LoRA、一个 ControlNet 辅助，再加上放大和修脸节点。平时跑单张没问题，真正让人头大的是以下三个场景。

第一，批量出图完全靠人工盯。比如要给一组角色分别出正面、侧面、表情特写，如果全靠手动改 Prompt、改 seed、点 Queue， 40 张图下来至少一两个小时，而且中间只要有人来叫你，回来就忘了自己跑到第几张，容易重复跑或者漏跑。

第二，参数很难保持一致。手动操作时，有些人习惯改 Prompt 后顺手把 steps、cfg、分辨率也调了，回头一对比，图与图之间的风格差异根本不是 Prompt 造成的，而是旁路参数不一致。最离谱的一次，我出 12 张产品图，有一张分辨率和其他图不一样，后面整理素材时才被发现，整个批次直接废掉。

第三，输出文件像一锅粥。ComfyUI 默认输出目录是output/，文件名默认带一串随机码。如果你一天跑 3 个批次、每批 20 张，晚上再去目录里翻图，根本分不清哪张是哪批的。想从里面挑图出来归档，只能一张张看图预览，工作效率全耗在“找图”上。

我自己还遇到过一次更难受的：工作流跑到一半，显存爆了，ComfyUI 前端报错，但后台进程没退出，重新提交任务时队列卡住，所有任务都堵着不动。那时候我就意识到，缺的不是控制台，而是一个能真正管理任务状态的调度层。

1.2 WorkBuddy 在整条链路里的角色定位

先说清一个概念：WorkBuddy 不是 ComfyUI 的替代品，它是在 ComfyUI 外面套了一层“调度和控制层”。

如果把 ComfyUI 当成一台发动机，WorkBuddy 就是整条生产线的控制台。发动机负责把电力转成动力，控制台负责决定“什么时候启动哪台机器、加工哪个零件、完成后送往哪里”。WorkBuddy 主要干四件事：

• 接收任务：把“出 12 张侧视图”这种自然语言需求，解析成一条条具体的出图任务。
• 管理队列：按顺序提交任务，设置并发数，避免全部任务一起挤爆显存。
• 监控状态：周期性查询 ComfyUI 的执行历史，判断任务是完成、失败、还是超时。
• 归档结果：出图完成后按批次命名、移动文件，并生成一份清单，能随时知道哪张图是哪个 Prompt、哪个 seed、哪一批跑出来的。

我见过有人用 Python 脚本直接调 ComfyUI API 来完成类似操作，也能用。但 WorkBuddy 的价值在于它把任务模板、队列策略、结果归档做成了可以反复用的工具，而不是每次写一段一次性脚本。你只要把工作流模板配好，后面提交任务就是一条命令的事。

对我个人来说，接上 WorkBuddy 之后，最大的改变不是“速度快了多少”，而是“出图过程终于可以放心去睡觉了”。任务提交后，它会按计划跑，跑完自动归档，失败的重试，实在不行才标记失败。这个确定性，比单纯提高出图速度更管用。

2. 流水线怎么设计：核心思路与工具选型

2.1 一条可复用的出图链路，重点不是节点而是“状态”

搭建流水线之前，我先把 ComfyUI 的出图过程拆成了一串状态，而不是去纠结工作流里画了什么节点。这一思路很关键。

一条出图链路可以拆成五个阶段：

1. 任务输入：包含文本描述、负向描述、seed、steps、cfg、分辨率、批次数量等。
2. 参数解析：把输入映射成 ComfyUI 工作流 JSON 模板里的具体字段。
3. 工作流提交：通过 ComfyUI API 把渲染后的完整 JSON 提交到/prompt接口。
4. 执行与轮询：定时访问/history接口，检查任务是否执行完成。
5. 结果归档：根据执行历史获取输出文件名，把 PNG 文件从输出目录移动或复制到归档目录。

为什么要按状态拆？因为只有“状态”是可控可追踪的。比如你手动点 Queue，图没出来只能干等；但在流水线里，任务已经提交、执行中、成功、失败都是明确状态。某一个环节出了问题，你能直接定位是哪一步停了。

ComfyUI 的 API 并不是什么秘密，它本身就提供了一套 HTTP 接口：

• POST /prompt：提交工作流 JSON，返回prompt_id。
• GET /history/{prompt_id}：查询某个任务的状态和输出信息。
• GET /view：根据文件名获取生成的图片。

WorkBuddy 做的事情，本质上是把“手动在网页上操作节点”替换成“程序化地组装 JSON、提交、轮询、收图”。

2.2 WorkBuddy 的任务队列为什么比“手动拖图”好用

ComfyUI 前端本身也有 Queue 概念，但它的队列感受更像食堂排队——你站在队伍里，窗口处理完一个，你往前走一步。问题是，一旦你关掉浏览器页面，队列进度就看不到了；中途想插一个新任务，也要重新打开页面操作。

WorkBuddy 的队列更像是“外卖订单系统”。你提交订单之后，不需要一直盯着厨房；厨房做完一单，系统自动派下一单；如果某一单做砸了，系统自动安排重做。我需要做的就是设定规则：同一时间最多跑几个任务、失败最多重试几次、单个任务最长执行多久。

实际使用下来，队列控制还有一个特别重要的点：并发限制。本地显卡显存是有限的，ComfyUI 一次同时跑太多任务会把显存挤爆。WorkBuddy 里我设置max_concurrent: 1，也就是同一时间只跑一个出图任务。听起来好像变慢了，其实不是。单任务跑完再跑下一个，显卡不争抢、不爆显存，整体吞吐反而更稳。如果你有两张显卡，也可以设置成 2，按需调整。

2.3 参数规范与命名策略：让流水线产生的文件可追溯

我强烈建议在搭建流水线的第一步就建立参数规范，而不是等出图量大了之后再来整理。WorkBuddy 支持把任务参数写进归档文件名，这里分享我的命名模板：

{batch}/{date}/{seq}_{prompt_tag}_{steps}steps_{seed}.png

比如20241108_014_side_view_30steps_123456789.png，一眼就能看出来：

• 第 20241108 天
• 第 014 张图
• prompt 主题是 side_view
• 使用 30 steps
• seed 是 123456789

这样即使不打开图片预览，也能通过文件名判断是哪批、哪类、哪个参数跑出来的。这个习惯帮了我大忙，后期整理素材时不需要一张张看缩略图，直接按文件名筛选就行。

参数规范里还有两个容易忽略的点：一是 seed 默认随机，但归档时必须把真实 seed 写入文件名，方便日后复现；二是分辨率、steps、cfg 要放在统一配置里，不要散落在每个任务里手动填。如果 40 张图里有 39 张用的同一组参数，只有一张填错了，出来以后很难发现是哪张。参数模板化之后，这种错误从根本上就不会发生。

3. 实操过程：从零把本地 ComfyUI 接进 WorkBuddy

3.1 准备工作：ComfyUI 安装状态整理与目录规划

开始之前，先把 ComfyUI 本身的环境确认一遍。我本机用的是 Linux，显卡驱动和 CUDA 已经配好，ComfyUI 能正常在浏览器里打开。WorkBuddy 的接入方式走的是 API 模式，所以要求 ComfyUI 进程以服务方式启动，而不是只在桌面简单运行。

启动命令建议带上--listen 127.0.0.1和--port 8188，只监听本机，避免暴露到局域网。如果只是自己用，没必要开远程访问，减少不必要的风险。完整命令大概是：

python main.py --listen 127.0.0.1 --port 8188

启动后先确认http://127.0.0.1:8188能正常返回页面，再继续。

接下来是目录规划。我习惯把出图相关的文件整理成以下结构：

comfyui/ models/ checkpoints/ loras/ vae/ output/ workflows/ workbuddy/ tasks/ archive/

其中workflows/放工作流 JSON 模板，workbuddy/tasks/存放待提交的任务描述，workbuddy/archive/存放归档后的出图成品。目录先建好，后面配置里会反复引用。这一点别偷懒，否则后续写死在配置里的路径不一致，再改就要花时间梳理。

3.2 WorkBuddy 接入配置：API端口、默认工作流、任务模板

WorkBuddy 的接入配置我写在一个 YAML 文件里，看起来像这样：

server: host: 127.0.0.1 port: 8188 default_workflow: sdxl_base.json output_dir: /data/comfyui/output archive_dir: /data/comfyui/archive queue: max_concurrent: 1 retry_count: 3 timeout_seconds: 600 prompt_defaults: steps: 30 cfg: 7.0 width: 1024 height: 1024 sampler: "dpmpp_2m" scheduler: "karras"

server.host和server.port对应 ComfyUI 的 API 地址。default_workflow是基础工作流 JSON 文件名。output_dir是 ComfyUI 的原始输出目录，归档时会从这里搬图。archive_dir是归档目录，每批任务跑完后的成品图放这里。

queue.max_concurrent设置为 1，我前面说过，是为了防止显存冲突。retry_count设置为 3，意思是任务失败后最多自动重试 3 次。timeout_seconds设置为 600 秒，也就是 10 分钟。如果单个任务超过 10 分钟还没完成，WorkBuddy 会认为任务异常，主动终止并重新调度。这个超时值需要根据你自己工作流的实际运行时长调整，我这边普通单张图一般 1~2 分钟，10 分钟留了足够余量。

工作流模板是 JSON 文件，里面有一些字段占位符，比如：

{ "prompt": "{{prompt}}", "negative_prompt": "{{negative_prompt}}", "seed": "{{seed}}", "steps": "{{steps}}" }

WorkBuddy 提交任务时会把真实参数替换进去。这样你只需要维护有限的几个工作流模板，而不是每次新建工作流都从头拖一遍节点。

3.3 批量出图跑起来：队列提交、资源限制、重试策略

配置完成后，批量出图就变得很机械了。我提交一个 12 张图的批次，命令大致是：

workbuddy submit --template sdxl_base --batch 12 --tag product_shot

它会自动生成 12 个任务，每个任务独立使用同一个模板，但 seed 可以各自设定。你可以顺序 seed，也可以固定一个 seed 做风格对比，具体看需求。

提交之后，WorkBuddy 会按顺序执行。因为它设置了max_concurrent: 1，同一时间只会有一个任务在 ComfyUI 里跑。每完成一个，它会立刻从队列里提取下一个；失败的任务不会无限重试，最多按配置重试 3 次后标记失败。

我实测下来，这个策略最大的好处是稳定。之前手动跑图时，偶尔一次显存不足导致前端卡死，后面所有任务全部停摆。WorkBuddy 模式下，单个任务失败最多浪费一张图的算力时间，不影响后续任务。失败原因会记录到日志里，比如 OOM、模型加载失败、API 超时，看一眼日志就能定位。

还有一个细节：资源限制不是只在 queue 里写max_concurrent就完事。我在底层还给 WorkBuddy 配置了显存占用保护，核心逻辑是“在一个任务结束并释放显存后，再启动下一个任务”，这样比连续提交多个任务更稳。

3.4 输出归档与多批次管理

任务跑完后，WorkBuddy 会把 ComfyUIoutput/目录里生成的文件按批次搬进归档目录。这一步如果不做，时间长了output/会堆满几千个文件，目录一打开就卡。

归档时我让它同时写入一个manifest.csv，记录每个文件的批次、Prompt、seed、steps、cfg、执行时间。这样后续查图、复现、重导出都很快。

manifest.csv大致长这样：

seq,title,prompt_tag,steps,seed,file 001,product_shot,front_view,30,123456789,product_front_view_001.png 002,product_shot,side_view,30,987654321,product_side_view_002.png

需要找某一张图时，直接在 CSV 里筛选条件，就能拿到文件名和对应参数。这个能力在整理素材、复盘效果、甚至写后续博文配图时都非常实用。

多批次管理上，我按“日期 + 任务名”生成子目录，比如archive/20241108_product_shot/。每一批任务都在独立目录里，不会互相污染。如果你还跑多个工作流模板，建议在归档目录里再加一层模板名，避免因模板不同导致同名文件覆盖。模板名这层我一开始漏了，后来从sdxl_base和flux_base跑同批次时才意识到，同一天两个模板生成的第一张图会撞名，所以目录层级宁可多一层，也不要后面返工。

4. 常见问题与排查技巧实录

4.1 问题速查表

实际使用 WorkBuddy 管理 ComfyUI 流水线的过程中，我遇到过不少问题。下面整理成一张速查表，方便你对照排查。

这张表不需要背，你只需要记住一个原则：所有异常第一步都是看日志。WorkBuddy 的日志会打印出任务提交前后的状态，哪一步出错一目了然，比对着前端报错瞎猜高效得多。

4.2 三个值得记下来的避坑细节

第一个坑：不要用随机文件名做长期归档。ComfyUI 默认输出文件名是一串随机码，比如ComfyUI_00001_.png，如果不做改名直接归档，后面很难定位。后来我强制规定，所有归档文件必须根据 CSV 里的信息重命名，重复就加序号，绝不留随机码。这个操作看似简单，但省下的找图时间远远超过命名时间。

第二个坑：批量任务最好固定 seed 或者明确记录 seed。早期我为了追求随机性，每个任务都使用随机 seed，结果出现了一种尴尬情况：同一批同一 Prompt 出两张好看的图，但 seed 差异很大，风格不稳定，想复现却找不到规律。后来我把 seed 策略分成两种模式：需要多样性时用递增 seed，需要一致性时固定同一个 seed。WorkBuddy 会把最终实际使用的 seed 写进日志，这一步是后来排查问题时最省心的地方。

第三个坑：检查磁盘空间。出图流水线跑起来后，图片数量增长速度很惊人。一次批量 100 张，每张几 MB，加上放大图可能五六 MB，一天就能积攒几个 GB。我因为没注意磁盘空间，曾经出现过任务跑到一半磁盘写满、ComfyUI 直接报错的情况。现在我在归档模块里加了一个磁盘空间检查，小于 10 GB 会提前告警，不会再等跑挂。

5. 流水线跑顺之后，我对“出图效率”的重新理解

5.1 效率指标的变化：同样是 100 张图，时间只是表象

以前我衡量出图效率只盯着“100 张图要跑多久”。接上 WorkBuddy 后，我逐渐意识到，时间只是效率的一部分，更重要的是稳定性、可控性和可追溯性。

同样是 100 张图，手动跑可能只需要两小时，但这中间你得一直盯着，那些排队、改参数、整理文件的时间，实际都是隐形成本。用 WorkBuddy 跑也是两小时，但这两个小时我可以去写别的代码、处理其他事情。任务结束后的整理也变成了自动化操作，CSV 清单直接就能用。算总账的话，真正的效率提升其实来自“不需要守在旁边”。

另外，批量出图的确定性提升以后，我敢跑更大的批次了。以前手动跑 40 张就要担心出错，现在跑 300 张也只是分几次提交的事。模型的风格测试、参数对比、批量素材生成，这些以前觉得麻烦的工作，现在变成了一条可重复执行的流水线。

5.2 给也想搭流水线的朋友三个建议

如果你也想把本地 ComfyUI 管成出图流水线，我有三点个人建议：

第一，先跑通最小闭环，再追求功能完整。不要一开始就配置复杂的重试、多工作流、自动告警。先把“提交 1 张图 → 归档 → 看到文件名”这件事跑通，后面再逐步加批量、加重试。最小闭环能让你快速验证配置没写错，而不是一步到位后面对一堆报错找不到出处。

第二，宁可并发少，不要并发贪。出图流水线的瓶颈永远在显存。设置并发数时，建议从 1 开始，实测稳定后再往上调。多任务并行带来的吞吐提升，在单卡环境下常常不明显，反而容易因为显存不足频繁失败，拖慢整体节奏。

第三，维护好工作流模板的版本。工作流模板不是一次配好就永久不变的，模型更新、节点升级后你可能需要调整模板。建议每个模板保存时带上日期或版本号，比如sdxl_base_v3.json，归档 CSV 里也记录模板版本。这样跑出来的图如果效果有变化，你能知道是模板变了还是参数变了。

我个人在流水平稳运行之后，把以前积累的几百张零散出图也按统一规范重新归档了一遍，整理完觉得整个素材库清爽了很多。现在每次接到新出图需求，我都先想“能不能拆成批量任务”，而不是打开 ComfyUI 手动点一下。这两者之间的区别，就是流水线带来的真正变化。