本地ComfyUI批量出图流水线：WorkBuddy调度与参数注入实战

1. 从“手动点按钮”到“流水线”：我为什么要折腾本地 ComfyUI 管理

本地跑 ComfyUI 出图这件事，刚开始玩的时候特别爽——节点随便连，模型随便换，LoRA 想叠几个叠几个，ControlNet 想挂哪就挂哪。但玩到第三个月，我的工作流文件夹里躺着四十多个 JSON，桌面截图存了上百张参数记录，每次要出一套风格统一的图，我得手动做这些事：打开 ComfyUI、加载工作流、改随机种子、改提示词、点生成、等进度条、保存图片、重命名、再改参数、再点生成……一套图二十张，光重复操作就耗掉大半个小时。

问题不在于 ComfyUI 本身慢，而在于人成了流水线上最不稳定的那个环节。我会忘记改种子导致出重复图，会手滑覆盖掉上一批结果，会在切换模型时忘了同步调整采样器参数。更麻烦的是，当我想批量测试不同 CFG 值对画面风格的影响时，手动操作根本没法保证变量控制的一致性。

后来我意识到，ComfyUI 本质上是一个有 API 的推理引擎，它的图形界面只是给人类看的壳。真正高效的使用方式，应该是把它当成一个可以被程序调度的服务，让代码去处理那些重复、机械、容易出错的环节。这就是我折腾 WorkBuddy 的起点——我想把本地 ComfyUI 从“一个需要我伺候的软件”变成“一条我说了算的流水线”。

WorkBuddy 在这个场景里扮演的角色，简单说就是本地任务调度与流程编排的中间层。它不替代 ComfyUI，也不重写推理逻辑，而是负责管理“什么时候、用什么参数、跑哪个工作流、结果存哪里、下一步做什么”这些流程性事务。你可以把它理解成一个工厂里的生产计划员：机器还是那些机器，但计划员决定了生产节奏和物料流向。

这套方案适合谁？如果你满足以下任意一条，后面的内容应该对你有用：本地已经有能跑通的 ComfyUI 环境，但每次出图还在靠手动点按钮；需要批量生成风格一致的图片，但不想写复杂的 Python 脚本；想对工作流做 A/B 测试，但手动改参数改到崩溃；或者单纯觉得“每次都要打开浏览器操作”这件事很蠢。不需要你精通编程，但需要你对 ComfyUI 的基本概念（节点、工作流、模型加载）有起码的了解。

2. 整体设计思路：为什么是“调度层”而不是“重写一切”

2.1 核心架构的取舍逻辑

在动手之前，我调研过几种方案。第一种是直接用 ComfyUI 的 API 写 Python 脚本，用 requests 库发请求。这条路最灵活，但问题是每换一个工作流就要重写一遍参数映射，工作流一多，脚本维护成本指数级上升。第二种是用现成的队列管理工具，但那些工具要么太重量级，要么对 ComfyUI 的支持不够原生，配置起来比手动操作还累。

最终选择 WorkBuddy 作为调度层，核心原因是它不侵入 ComfyUI 的内部逻辑。ComfyUI 还是那个 ComfyUI，你可以在浏览器里正常用，也可以让 WorkBuddy 通过 API 去调用。两者共享同一套模型文件和工作流定义，不存在“迁移”或“同步”的问题。WorkBuddy 做的事情很纯粹：读取工作流 JSON、替换指定节点的参数、提交任务、监控状态、收集结果、按规则命名保存。

这种设计的好处是故障隔离。如果 WorkBuddy 挂了，ComfyUI 本身不受影响，你随时可以回到手动模式。反过来，如果 ComfyUI 更新了版本导致 API 有变化，也只需要调整 WorkBuddy 的适配层，不需要动工作流本身。我踩过的一个坑是：早期尝试过把参数直接写死在脚本里，结果 ComfyUI 升级后节点 ID 变了，所有脚本全部报错。后来改成从工作流 JSON 里动态读取节点信息，才彻底解决了这个问题。

2.2 流水线的三个核心模块

整套流水线我拆成了三个模块，每个模块各司其职。

任务定义模块负责描述“要生成什么”。这里我用的是 YAML 文件，因为 YAML 比 JSON 更适合人类阅读和编辑，支持注释，缩进清晰。一个典型的任务定义长这样：指定工作流文件路径、指定要覆盖的节点参数（比如提示词、种子、步数、CFG）、指定输出目录和命名规则。这个模块的关键设计是参数覆盖机制——只写需要改的，没写的保持工作流默认值。这样既灵活又不会因为漏写参数导致意外行为。

调度执行模块是 WorkBuddy 的核心。它读取任务定义，把参数注入到工作流 JSON 的对应节点里，然后通过 ComfyUI 的 API 提交任务。这里有个细节：ComfyUI 的 API 提交需要把整个工作流 JSON 发过去，而不是只发参数。所以 WorkBuddy 实际上是在内存里做了一次“工作流实例化”——把模板工作流和任务参数合并成一个完整的可执行工作流。这个合并过程需要精确匹配节点 ID 和输入字段名，匹配错了就会静默失败（ComfyUI 不会报错，只是忽略你的参数）。

结果收集模块负责把生成的图片从 ComfyUI 的输出目录搬运到指定位置，并按规则重命名。我用的命名规则是{工作流名}_{日期}_{序号}_{种子}.png，这样一眼就能看出这张图是用什么工作流、什么时候、第几张、什么种子生成的。对于需要对比实验的场景，这个命名规则能省掉大量翻找时间。

2.3 为什么不用现成的队列工具

有人可能会问：ComfyUI 本身就有队列功能，为什么还要套一层？我的体验是，ComfyUI 自带的队列是面向单次会话的，关掉浏览器队列就没了，而且没法做条件分支（比如“如果这张图评分低于阈值就自动重跑”）。WorkBuddy 的调度是持久化的，任务定义存在磁盘上，随时可以重新执行，也可以设置依赖关系。比如我可以定义“先生成十张草图，人工筛选出三张，再对这三张做高清修复”，这个流程用 WorkBuddy 可以半自动化地串起来。

另一个考虑是参数扫描。做模型对比测试时，我经常需要固定其他参数，只变一个变量（比如 CFG 从 5 到 12，步长 1）。手动改八次参数、点八次生成，很容易出错。WorkBuddy 支持参数矩阵展开，一个任务定义里写cfg: [5, 6, 7, 8, 9, 10, 11, 12]，它会自动生成八个任务依次执行。这个功能在调参阶段帮我省了大量时间。

3. 核心细节解析：工作流改造与参数注入的实操要点

3.1 工作流 JSON 的结构与节点定位

要让 WorkBuddy 能正确注入参数，首先得理解 ComfyUI 工作流 JSON 的结构。一个工作流 JSON 本质上是一个节点图，每个节点有唯一的id，有type（节点类型，比如KSampler、CLIPTextEncode），有inputs（输入参数），有outputs（输出连接）。参数注入的关键是找到正确的节点和正确的输入字段。

举个例子，如果你想把正面提示词改成“a cat sitting on a chair”，你需要找到类型为CLIPTextEncode且连接到KSampler的positive输入的那个节点。但问题是，工作流里可能有多个CLIPTextEncode节点，怎么知道哪个是正面、哪个是负面？我的做法是在 ComfyUI 里给关键节点重命名。ComfyUI 允许你右键节点选择“Title”来改显示名称，这个名称会保存在工作流 JSON 的title字段里。我把正面提示词节点改名为“POSITIVE_PROMPT”，负面改名为“NEGATIVE_PROMPT”，采样器改名为“MAIN_SAMPLER”。这样 WorkBuddy 就可以通过title字段来定位节点，而不是依赖容易变化的id。

这个技巧看起来简单，但实际用起来差别巨大。我早期的工作流没有重命名节点，结果每次调整工作流结构（比如插入一个新节点），所有节点的id都会变，之前写的参数映射全部失效。改成按title定位后，只要我不改节点名称，工作流怎么调整都不影响调度脚本。

3.2 参数覆盖的优先级设计

WorkBuddy 的参数注入遵循一个明确的优先级：任务定义 > 工作流默认值。也就是说，如果任务定义里写了steps: 30，那就用 30；如果没写，就用工作流 JSON 里原本的值。这个设计看起来理所当然，但实现时有个坑：ComfyUI 的工作流 JSON 里，参数值可能藏在多层嵌套结构中，不是简单的键值对。

比如KSampler节点的inputs里，steps是一个整数，直接替换就行。但CLIPTextEncode的text字段是一个字符串，如果提示词里包含特殊字符（比如引号、换行），直接字符串替换可能会破坏 JSON 结构。我的解决方案是用 JSON 解析库做结构化修改，而不是用文本替换。具体来说，先把工作流 JSON 加载成 Python 字典，然后按路径修改字典里的值，最后再序列化回 JSON。这样无论提示词里有什么字符，都不会破坏结构。

另一个细节是类型转换。YAML 里写的steps: 30会被解析成整数，但如果你写steps: "30"，它就是字符串。ComfyUI 的 API 对类型是敏感的，传字符串进去可能被忽略或报错。所以 WorkBuddy 在注入参数前会做一次类型检查，确保整数节点收到整数、浮点节点收到浮点、字符串节点收到字符串。这个检查逻辑不复杂，但能避免很多“为什么参数没生效”的困惑。

3.3 种子控制与可复现性

做批量出图时，种子的管理是个容易被忽视但极其重要的环节。ComfyUI 默认的种子行为是“每次生成随机”，这在手动操作时没问题，但在流水线里会导致结果不可复现。我的做法是在任务定义里显式指定种子范围，比如seed: [1000, 1001, 1002, ...]或者seed_start: 1000, seed_count: 10。WorkBuddy 会为每个任务分配一个确定的种子，并把种子值记录在输出文件名和日志里。

这样做的好处是，如果某张图效果特别好，你可以直接从文件名里读出种子，然后在 ComfyUI 里手动复现。反过来，如果某张图有问题，你也可以通过种子定位到具体的生成参数。我踩过的坑是：早期没有记录种子，结果一批图里有一张特别满意，但怎么都复现不出来，因为不知道当时用的什么种子。从那以后，种子记录成了我的硬性要求。

还有一个进阶技巧是种子偏移。当你用同一个提示词生成多张图时，如果种子完全随机，风格波动可能很大。我的做法是固定一个基础种子，然后对每张图做小幅度偏移（比如base_seed + i * 1000）。这样生成的图片在保持整体风格一致的同时，又有足够的变化。这个技巧在生成角色多姿势图或者场景多角度图时特别有用。

4. 实操过程：从零搭建一条可复用的出图流水线

4.1 环境准备与依赖安装

开始之前，你需要确保本地 ComfyUI 已经能正常运行，并且知道它的 API 地址。默认情况下，ComfyUI 的 API 监听在127.0.0.1:8188，但如果你改了端口或者用了其他启动参数，需要对应调整。验证 API 是否可用的最简单方法是访问http://127.0.0.1:8188/queue，如果返回一个 JSON 对象（哪怕队列是空的），说明 API 正常。

WorkBuddy 本身是一个轻量级的调度工具，安装方式取决于你拿到的版本。如果是 Python 包，直接pip install workbuddy即可；如果是源码，克隆到本地后pip install -r requirements.txt。依赖项通常包括requests（发 HTTP 请求）、pyyaml（解析任务定义）、pillow（图片处理，可选）。我建议在一个独立的虚拟环境里安装，避免和 ComfyUI 的 Python 环境冲突。

提示：ComfyUI 和 WorkBuddy 可以共用同一个 Python 环境，但我不推荐这样做。ComfyUI 的依赖比较重，而且经常更新，混在一起容易出兼容性问题。用虚拟环境隔离是最稳妥的做法。

安装完成后，你需要配置 WorkBuddy 的连接信息。通常是一个config.yaml文件，里面写 ComfyUI 的 API 地址、默认输出目录、日志级别等。我的配置里还加了timeout和retry参数，因为生成高分辨率图片时，单张图可能需要几分钟，默认的超时时间可能不够。

4.2 工作流模板的规范化改造

在把工作流交给 WorkBuddy 之前，我建议先做一轮规范化改造。具体步骤是：在 ComfyUI 里打开你要用的工作流，给所有需要动态控制的节点重命名（用全大写加下划线，比如POSITIVE_PROMPT、NEGATIVE_PROMPT、MAIN_SAMPLER、IMAGE_SAVE），然后导出为 API 格式的 JSON（注意不是普通的“保存”格式，而是“导出（API）”格式）。

这两种格式的区别很重要。普通保存的 JSON 包含界面布局信息（节点位置、大小、颜色），而 API 格式的 JSON 只包含执行所需的最小信息。WorkBuddy 需要的是 API 格式，因为界面信息对它没用，反而会增加解析负担。我早期用错了格式，结果 WorkBuddy 一直报“找不到节点”，排查了半天才发现是格式问题。

导出 API 格式后，建议手动检查一下关键节点的inputs字段，确认参数名称和类型正确。比如KSampler的steps应该是整数，cfg应该是浮点数，sampler_name应该是字符串。如果发现类型不对，可以在 ComfyUI 里调整后重新导出，或者直接在 JSON 里修正。

4.3 任务定义的编写与参数矩阵

任务定义文件是整个流水线的“生产订单”。我通常按项目来组织，一个项目一个 YAML 文件。文件结构大致如下：

workflow: workflows/portrait_workflow_api.json output_dir: outputs/portrait_batch_001 naming: "{workflow}_{date}_{index:03d}_{seed}" tasks: - name: base_generation params: POSITIVE_PROMPT: "a portrait of a young woman, soft lighting, detailed skin" NEGATIVE_PROMPT: "blurry, low quality, deformed" MAIN_SAMPLER: steps: 28 cfg: 7.5 sampler_name: "dpmpp_2m" scheduler: "karras" seed_start: 2000 seed_count: 10

这个定义会生成 10 张图，种子从 2000 到 2009，其他参数固定。如果你想做参数扫描，可以把某个参数写成列表：

MAIN_SAMPLER: steps: [20, 25, 30, 35] cfg: 7.5

这样会生成 4 组任务，每组 10 张图，总共 40 张。WorkBuddy 会自动做笛卡尔积展开，你不需要手动写 40 个任务。这个功能在调参阶段特别高效，我通常先用小图（512x512）快速扫描参数，找到最优区间后再用大图精修。

注意：参数矩阵展开时，任务数量会相乘。如果你同时扫描 steps 和 cfg，每个有 4 个值，那就是 16 组任务。如果每组还要生成 10 个种子，那就是 160 张图。建议先用小规模测试，确认流程通畅后再放大。

4.4 执行监控与结果收集

启动 WorkBuddy 后，它会依次提交任务到 ComfyUI 的队列，并轮询任务状态。我通常会在另一个终端窗口开着 ComfyUI 的日志，这样能实时看到生成进度。WorkBuddy 本身也会输出日志，包括每个任务的提交时间、完成时间、生成的图片路径、种子值等。

结果收集环节，WorkBuddy 会把 ComfyUI 输出目录里的图片按命名规则重命名并移动到指定目录。这里有个细节：ComfyUI 默认的输出文件名是ComfyUI_00001_.png这种格式，序号是全局递增的。如果你同时跑多个任务，序号会混在一起。WorkBuddy 的做法是在提交任务时记录返回的 prompt_id，然后根据 prompt_id 去输出目录里找对应的图片。这个匹配逻辑需要 ComfyUI 的 API 返回足够的信息，通常没问题，但如果 ComfyUI 版本较老，可能需要额外配置。

我踩过的一个坑是：ComfyUI 的输出目录里可能残留之前手动生成的图片，如果匹配逻辑不够精确，可能会把旧图当成新图收集。解决方案是在每次批量任务开始前，清空或归档输出目录，或者用时间戳过滤。我现在的做法是给每个批次建一个独立的输出子目录，ComfyUI 的输出路径也通过参数动态指定，这样物理隔离，不会混淆。

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

5.1 参数不生效的排查思路

这是最常见的问题：任务提交了，图也生成了，但参数没变。排查步骤我总结了一个顺序：

我遇到最多的情况是第 2 种：参数路径写错。比如KSampler的steps在 JSON 里是inputs.steps，但如果你在任务定义里直接写steps: 30，WorkBuddy 可能不知道要往哪个节点的inputs里塞。正确的写法是指定节点 title 和字段名，比如MAIN_SAMPLER.steps: 30。这个映射规则需要在 WorkBuddy 的配置里定义清楚，或者遵循它的默认约定。

5.2 生成速度慢的优化方向

本地出图的速度瓶颈通常在显卡。但除了硬件，软件层面也有优化空间。我实测下来，以下几个调整对速度影响比较明显：

降低预览频率。ComfyUI 默认会在生成过程中不断更新预览图，这个预览本身消耗资源。在 API 模式下，预览其实没必要，可以在启动参数里关掉。具体方法是在 ComfyUI 的启动命令里加--preview-method none，这样生成过程中不渲染预览，速度能提升 10% 到 20%。

调整批次大小。ComfyUI 支持一次生成多张图（batch_size），但批次太大会爆显存，太小又浪费。我的经验是，512x512 的图 batch_size 设 4 比较合适，768x768 设 2，1024x1024 设 1。这个值需要根据你的显卡显存调整，没有万能公式。

模型加载策略。如果你在批量任务中频繁切换模型，每次切换都会触发模型加载，这个开销很大。WorkBuddy 支持按模型分组任务，把用同一个模型的任务排在一起，减少切换次数。这个优化在跑多模型对比时效果显著，我试过把加载次数从 20 次降到 4 次，总时间缩短了将近三分之一。

5.3 输出文件管理的避坑经验

批量出图最大的痛苦不是生成，而是生成完之后找不到想要的图。我踩过的坑包括：文件名重复导致覆盖、输出目录太深找不到、图片太多无法快速筛选。

解决方案是命名规则要包含足够的信息。我现在的命名格式是{项目名}_{工作流名}_{日期}_{序号}_{种子}_{关键参数}.png。比如portrait_v2_20250115_003_2003_cfg7.5.png。这样即使不看图片内容，也能从文件名判断出这张图是用什么参数生成的。对于需要对比的场景，我还会在文件名里加上参数值，方便用文件管理器排序。

另一个技巧是生成缩略图联系表。WorkBuddy 可以在任务完成后自动生成一张联系表（contact sheet），把所有图片缩略图拼成一张大图。这样你可以快速浏览整批结果，不用一张张点开。联系表的生成可以用 Pillow 库实现，代码不复杂，但能省大量时间。我通常会把联系表和原图放在同一个目录，文件名加_contact后缀。

提示：如果你的输出目录在机械硬盘上，大量小文件的写入速度可能成为瓶颈。建议把输出目录设在固态硬盘上，或者用内存盘做临时存储，批量任务完成后再归档到机械硬盘。

5.4 任务中断与恢复的处理

批量任务跑到一半，可能因为各种原因中断：显存不足、ComfyUI 崩溃、电脑休眠。如果没有恢复机制，你只能从头再来。WorkBuddy 的做法是记录已完成的任务，中断后重新启动时，跳过已经完成的任务，只跑剩下的。

这个功能依赖一个状态文件，通常是一个 JSON 或 SQLite 数据库，记录每个任务的 ID、状态、输出路径。我建议把这个状态文件和任务定义放在同一个目录，方便管理。如果状态文件丢失，也可以根据输出目录里已有的图片来推断哪些任务完成了——这就是命名规则包含种子和序号的好处，可以通过文件名反推任务进度。

我遇到过一次断电导致任务中断，恢复后发现状态文件损坏了。好在输出目录里的图片文件名完整，我写了个小脚本扫描文件名，重建了状态文件，然后继续跑剩下的任务。从那以后，我养成了定期备份状态文件的习惯，虽然麻烦一点，但比重新跑几百张图划算得多。

6. 流水线扩展：从单机批量到多机协作的演进思路

6.1 多工作流串联的玩法

单工作流批量出图只是起点。真正有意思的是把多个工作流串起来，形成更复杂的生产流程。比如：第一个工作流生成低分辨率草图，第二个工作流对草图做高清修复，第三个工作流对修复后的图做风格迁移。这三个工作流可以定义成三个任务组，WorkBuddy 负责把上一组的输出作为下一组的输入。

实现这个串联的关键是任务间的数据传递。WorkBuddy 支持在任务定义里引用上一个任务的输出路径，比如input_image: "{prev_output}"。这样第二个工作流加载图片时，会自动使用第一个工作流的输出。这个机制看起来简单，但实际用起来需要处理好文件命名和路径映射，否则很容易出现“找不到输入图片”的错误。

我试过的一个典型场景是：先用一个工作流生成 20 张不同姿势的角色草图，人工筛选出 5 张满意的，然后用第二个工作流对这 5 张做高清修复和细节增强。整个流程半自动化，人工只负责筛选环节，其他都交给 WorkBuddy 调度。相比全手动操作，效率提升非常明显。

6.2 质量筛选与自动重跑

批量出图的一个痛点是质量参差不齐。有些图一次就很好，有些图需要重跑好几次。如果全靠人工筛选，批量越大越累。我的做法是引入简单的自动筛选规则，比如用图像质量评估指标（清晰度、对比度、人脸检测置信度）给每张图打分，低于阈值的自动标记为“待重跑”。

WorkBuddy 本身不包含图像评估功能，但可以通过插件或外部脚本扩展。我写了一个简单的 Python 脚本，用 OpenCV 计算拉普拉斯方差（衡量清晰度），用一个人脸检测模型判断是否有人脸以及人脸是否完整。这个脚本在 WorkBuddy 完成任务后自动运行，把评分结果写入一个 CSV 文件。然后我根据评分决定哪些图需要重跑，重跑时只需要修改任务定义里的种子列表，其他参数不变。

这个流程的优点是把人工判断和机器执行分开。机器负责生成和初步筛选，人负责最终决策。我实测下来，对于 100 张图的批次，人工筛选时间从原来的半小时缩短到五分钟，而且漏筛率更低。

6.3 远程调度的可能性与限制

目前这套方案是单机运行的，WorkBuddy 和 ComfyUI 在同一台机器上。但理论上，WorkBuddy 可以通过网络调用远程的 ComfyUI API。这意味着你可以把生成任务提交到另一台性能更强的机器上，本地只负责调度和结果收集。

这个模式在团队协作场景下特别有用：一台高性能工作站跑 ComfyUI，多个成员通过各自的 WorkBuddy 提交任务。但实现时需要注意几个问题：网络延迟会影响任务提交和状态轮询的效率；远程机器的输出目录需要能被本地访问（通常用共享目录或对象存储）；并发任务需要排队机制，避免同时提交太多任务把远程机器压垮。

我目前还没有大规模部署这个模式，只在局域网内做过小规模测试。实测下来，千兆局域网下提交任务和拉取结果的延迟可以接受，但如果是跨地域的网络，延迟可能会成为瓶颈。另外，远程模式下 ComfyUI 的 API 需要暴露在网络上，这涉及到访问控制的问题，需要额外配置认证和授权机制。

6.4 日志与可观测性的重要性

流水线跑起来之后，日志是你唯一能依赖的排查工具。我建议从第一天就建立完善的日志体系，包括：任务提交日志（什么时间、提交了什么参数）、任务完成日志（耗时、输出路径、种子）、错误日志（失败原因、堆栈信息）。WorkBuddy 通常自带日志功能，但默认级别可能不够详细，建议调到 DEBUG 级别，至少在调试阶段这样做。

日志的存储我推荐用结构化格式（JSON Lines），每行一个 JSON 对象，方便后续用脚本分析。比如你可以统计每个工作流的平均生成时间、每个参数组合的成功率、每天的生图数量等。这些数据对于优化流水线很有价值。我通过分析日志发现，某个采样器在特定步数下失败率明显偏高，调整后整体成功率从 85% 提升到了 97%。

注意：日志文件会随时间增长，建议设置轮转策略，比如每天一个文件，保留最近 30 天。如果日志量很大，可以考虑写入数据库而不是纯文本文件，方便查询和聚合。

7. 我在这套流水线上踩过的坑与总结的经验

7.1 工作流版本管理的教训

最开始我没有对工作流做版本管理，改了什么全凭记忆。结果有一次调整了采样器参数，导致之前跑通的任务全部失败，而我完全不记得改了什么。后来我养成了习惯：每次修改工作流，导出 API JSON 时在文件名里加上版本号和日期，比如portrait_workflow_v3_20250110_api.json。同时在任务定义里明确引用具体版本的文件名，而不是用latest这种模糊的引用。

这个习惯看起来增加了操作步骤，但实际节省了大量排查时间。当某个任务失败时，我可以快速对比当前工作流和上一个可用版本的差异，定位问题。我还会在 Git 仓库里管理工作流文件，每次修改都提交一次，这样有完整的变更历史。

7.2 显存管理的实战技巧

本地出图最怕的就是显存不足。尤其是在批量任务中，如果前一个任务没有完全释放显存，后一个任务就可能失败。我的经验是：在 WorkBuddy 的任务之间加入短暂的等待（比如 2 秒），给 ComfyUI 一点时间释放资源。这个等待时间不需要太长，但能显著降低连续任务失败的概率。

另一个技巧是监控显存使用情况。我写了一个小脚本，在每次任务提交前检查显存占用，如果超过阈值就暂停提交，等显存降下来再继续。这个脚本用nvidia-smi命令获取显存信息，逻辑很简单，但效果很好。我试过在 8GB 显存的显卡上连续跑 50 张 1024x1024 的图，加入显存监控后，失败率从 15% 降到了 2% 以下。

7.3 参数扫描的实用策略

参数扫描是调参的利器，但用不好也会浪费时间。我的策略是先粗后细，先小后大。第一轮用低分辨率（512x512）和较少的步数（比如 15 步）快速扫描大范围参数，找到效果较好的区间。第二轮在较优区间内用中等分辨率（768x768）和正常步数做精细扫描。第三轮用最终分辨率（1024x1024 或更高）验证最优参数。

这个策略的核心是用最低的成本排除最差的选项。我试过直接在高分辨率下扫描 20 组参数，结果跑了三个小时才完成，而且大部分结果都不理想。后来改成先低分辨率扫描，20 组参数只用了二十分钟，筛选出 5 组有潜力的，再在高分辨率下验证，总时间缩短到一小时以内。

7.4 关于自动化的边界

最后想说的是，自动化不是万能的。有些环节人工介入反而更高效，比如最终的质量判断、风格微调、创意决策。我的流水线设计原则是：机器做重复劳动，人做判断和创造。WorkBuddy 负责把图生成出来、按规则命名、初步筛选，但最终选哪张图、要不要调整提示词、下一步往哪个方向探索，这些还是人来决定。

我见过有人试图把整个流程完全自动化，包括自动评估图片质量、自动调整提示词、自动迭代优化。结果往往是陷入局部最优，生成的图片越来越同质化，失去了多样性。我的做法是在流水线里保留几个“人工检查点”，比如每生成 20 张图暂停一次，人工快速浏览并决定是否继续。这样既享受了自动化的效率，又保留了人的判断力。

这套 WorkBuddy 加 ComfyUI 的流水线，我用了大半年，从最初的手忙脚乱到现在基本稳定运行。最大的体会是：工具的价值不在于它有多强大，而在于它能不能让你把精力集中在真正重要的事情上。对我来说，重要的事情是构思画面、调整风格、探索创意，而不是重复点击按钮和手动改参数。流水线把这些琐事接过去之后，我出图的效率和创作的热情都明显提升了。如果你也在被类似的重复劳动困扰，不妨试试这个思路，从一个小工作流开始，慢慢把流程串起来。