企业官网建设流程全解析

1. WorkBuddy 是什么，它为什么能管住 ComfyUI 这头“野马”

“我用 WorkBuddy 把本地 ComfyUI 管成了一条出图流水线”——这句话里藏着三个关键信息点：本地 ComfyUI、WorkBuddy、出图流水线。它不是在说“我又装了个新插件”，而是在描述一种工作范式的转变：从手动拖拽节点、反复调试参数、守着显卡风扇狂转的“手工作坊式出图”，切换到可调度、可复用、可追踪、可回滚的“工业化生产流程”。

ComfyUI 本身是一套基于节点图（Node Graph）的 Stable Diffusion 前端，它的强大在于自由度——你可以把采样器、CLIP 编码器、LoRA 加载器、ControlNet 预处理器像乐高一样任意拼接。但自由的反面是混乱。一个中等复杂度的工作流（Workflow）JSON 文件动辄 3000 行以上，里面嵌套着十几层对象、几十个模型路径、上百个参数字段。某次更新后，你发现生成图突然全黑；或者换了一台机器，因为模型路径写死在 C:\Users\XXX\ComfyUI\models\checkpoints\，而新机器上路径是 D:\AI\comfy\models\，整个工作流直接报错“model not found”。更别提多人协作时，A 同学改了 VAE 节点的vae_name字段，B 同学没同步就跑任务，结果输出图色偏严重却找不到原因。

WorkBuddy 就是为解决这类“工程化失序”而生的工具。它不是 ComfyUI 的插件，也不是另一个 Web UI，而是一个运行在本地的、轻量级的工作流编排与执行代理。你可以把它理解成 ComfyUI 的“车间主任”：它不直接画画（不参与图像生成计算），但它负责下发图纸（工作流）、分配原料（模型/LoRA/ControlNet 权重）、校准设备（GPU 显存分配、CUDA 版本兼容性检查）、记录每一道工序（输入参数、耗时、显存峰值、输出图哈希值），并在异常时立刻叫停（自动捕获 Python 异常并返回结构化错误日志）。

它之所以能“管住”ComfyUI，核心在于它绕开了传统 Web UI 的交互瓶颈，直接对接 ComfyUI 的API Server 模式。当你启动 ComfyUI 时，加一个- --enable-cors-header --listen 127.0.0.1:8188参数，它就不再只是浏览器里那个图形界面，而变成一个 RESTful 服务。WorkBuddy 正是通过/prompt、/queue、/history这些标准 API 接口与之通信。这意味着：

• 它可以批量提交 50 个不同提示词的请求，而不用在浏览器里点 50 次“Queue Prompt”；
• 它可以把一次生成任务拆成“预处理→采样→后处理”三阶段，每个阶段调用不同的 ComfyUI 实例（比如预处理用 CPU，采样用 GPU，后处理再切回 CPU 节省显存）；
• 它甚至能在任务失败后，自动提取错误堆栈里的关键行（如torch.cuda.OutOfMemoryError: CUDA out of memory），并建议你将batch_size从 4 改为 1，而不是让你自己翻 200 行 traceback。

提示：WorkBuddy 不依赖 ComfyUI 的任何特定分支或自定义节点。只要你的 ComfyUI 能正常响应http://127.0.0.1:8188/object_info这个 API（返回所有可用节点的元数据），WorkBuddy 就能识别并调度它。这保证了极强的兼容性，也意味着你无需为了用 WorkBuddy 而放弃正在维护的私有节点库。

我第一次在某跨平台图像生成 Demo 项目中引入 WorkBuddy，是为了解决一个具体痛点：客户需要每天定时生成 200 张不同风格的产品图，每张图需叠加 3 种水印、应用 2 种色彩校正 LUT，并导出 PNG+WebP 双格式。之前靠人工操作，平均单张耗时 4 分钟，且极易漏掉某个 LUT 应用步骤。接入 WorkBuddy 后，我们把整个流程固化为一个 YAML 配置文件，配合系统 cron，实现了全自动无人值守。最让我意外的是，当某天 NVIDIA 驱动更新导致 ComfyUI 崩溃时，WorkBuddy 的健康检查模块在 30 秒内检测到 API 无响应，并自动切换到备用的 CPU 模式（降级运行，速度慢但不断流），保障了当日交付。这种“故障自愈”能力，是纯手工操作永远无法企及的。

2. 从零搭建：WorkBuddy + ComfyUI 流水线的四步落地实操

搭建这条流水线，不需要改 ComfyUI 源码，也不用部署 Docker 或 Kubernetes。整个过程控制在 15 分钟内，且全部在本地完成。我以 Windows 11 + RTX 4090 为基准环境，但所有步骤在 macOS 和 Linux 上完全一致，仅路径分隔符和命令略有差异。

2.1 第一步：确认 ComfyUI 已启用 API 模式（不是默认开启）

很多人卡在这一步，以为装完 ComfyUI 就能用 WorkBuddy，结果连不上。根本原因是：ComfyUI 默认只监听127.0.0.1:8188，且不启用 CORS（跨域资源共享）。而 WorkBuddy 作为独立进程，需要通过 HTTP 请求访问该地址，若未开启 CORS，浏览器或某些网络栈会直接拦截请求。

验证方法：打开终端，执行

curl -X GET "http://127.0.0.1:8188/object_info" -H "accept: application/json"

如果返回一长串 JSON（包含"KSampler": { ... },"CheckpointLoaderSimple": { ... }等节点定义），说明 API 已就绪；如果返回curl: (7) Failed to connect...，则需修改启动方式。

正确启动命令（推荐写成start_api.bat）：

@echo off cd /d "D:\ComfyUI" python main.py --listen 127.0.0.1 --port 8188 --enable-cors-header --extra-model-paths-config extra_model_paths.yaml pause

关键参数解析：

• --listen 127.0.0.1：明确绑定本地回环地址，避免暴露到局域网（安全基线）；
• --enable-cors-header：添加Access-Control-Allow-Origin: *响应头，允许 WorkBuddy 跨域调用；
• --extra-model-paths-config：指向一个 YAML 文件，统一管理模型路径，这是后续实现“路径解耦”的基础（下文详述）。

注意：不要使用--listen 0.0.0.0。虽然它能让局域网其他设备访问，但会带来不必要的安全风险。WorkBuddy 与 ComfyUI 本就是同机协作，走127.0.0.1最稳。

2.2 第二步：安装 WorkBuddy 并初始化工作区

WorkBuddy 是一个 Python CLI 工具，通过 pip 安装。它不依赖 ComfyUI 的 Python 环境，建议新建一个干净虚拟环境，避免包冲突。

# 创建并激活虚拟环境 python -m venv wb_env wb_env\Scripts\activate.bat # Windows # wb_env/bin/activate # macOS/Linux # 安装 WorkBuddy（当前最新版 0.8.3） pip install workbuddy-cli # 初始化工作区（会在当前目录生成 .workbuddy/ 文件夹） wb init

wb init会创建以下关键文件：

• .workbuddy/config.yaml：全局配置，定义 ComfyUI 地址、默认超时、日志级别；
• .workbuddy/workflows/：存放所有工作流 YAML 文件的目录；
• .workbuddy/assets/：存放图片、LUT 文件、字体等静态资源的目录。

此时打开.workbuddy/config.yaml，将comfyui_url改为http://127.0.0.1:8188。保存后，执行wb status，若看到ComfyUI Status: OK (v0.3.16)（版本号为你实际安装的 ComfyUI 版本），说明连接成功。

2.3 第三步：将 ComfyUI 工作流 JSON 转为可复用的 YAML 模板

这是最关键的一步，也是 WorkBuddy 区别于“简单封装”的核心价值。它不让你直接扔一个巨大的 JSON 过去，而是要求你把工作流“解耦”为三部分：结构（Structure）、参数（Parameters）、资源（Assets）。

假设你有一个生成动漫角色的 ComfyUI 工作流anime_char.json。用 WorkBuddy 的转换命令：

wb convert --input anime_char.json --output workflows/anime_char.yaml

它会生成一个 YAML 文件，内容类似：

name: "Anime Character Generator" description: "High-detail anime portrait with style control" structure: - id: "loader" type: "CheckpointLoaderSimple" inputs: ckpt_name: "{{ model }}" - id: "clip" type: "CLIPTextEncode" inputs: text: "{{ prompt }}" clip: "{{ loader.clip }}" # ... 其他节点省略 parameters: model: "animagine-xl-3.1.safetensors" prompt: "masterpiece, best quality, 1girl, white dress, sunny garden" negative_prompt: "lowres, bad anatomy" seed: 12345 steps: 30 assets: - "assets/luts/cinematic.cube" - "assets/fonts/arial.ttf"

看到{{ model }}和{{ prompt }}了吗？这就是模板化的威力。parameters下的字段，可以在每次运行时动态覆盖；assets列表中的文件，WorkBuddy 会自动从.workbuddy/assets/目录拷贝到 ComfyUI 的临时工作区，确保路径绝对可靠。再也不用担心C:\Users\XXX\...这种硬编码路径在另一台机器上失效。

2.4 第四步：定义流水线任务并一键触发

现在，我们把“生成 10 张不同提示词的图”这个需求，写成一个流水线任务文件pipeline_daily.yml：

name: "Daily Anime Batch" description: "Generate 10 variations for client review" stages: - name: "Preprocess" workflow: "workflows/anime_char.yaml" parameters: model: "animagine-xl-3.1.safetensors" negative_prompt: "lowres, bad anatomy, text" steps: 25 loop: over: "prompts" values: - "masterpiece, best quality, 1girl, school uniform, cherry blossoms" - "masterpiece, best quality, 1boy, cyberpunk jacket, neon city" # ... 共 10 条 outputs: - "outputs/daily/{{ loop.index }}_{{ loop.value | truncate(20) }}.png" - name: "Postprocess" workflow: "workflows/watermark.yaml" parameters: input_image: "{{ Preprocess.outputs[0] }}" watermark_text: "SAMPLE - DO NOT DISTRIBUTE" outputs: - "outputs/final/{{ loop.index }}_final.png"

执行命令：

wb run --pipeline pipeline_daily.yml

WorkBuddy 会：

1. 读取pipeline_daily.yml，解析出两个 stage；
2. 对Preprocessstage，循环 10 次，每次用不同的prompt覆盖anime_char.yaml中的prompt参数，并将输出图按规则命名；
3. 将Preprocess的第 1 个输出路径（即第一张图）传给Postprocessstage 的input_image参数；
4. 调用watermark.yaml工作流，叠加水印；
5. 所有日志、错误、耗时统计，自动写入.workbuddy/logs/目录，按日期归档。

实测下来，10 张图总耗时约 6 分钟（RTX 4090），比手动操作快 5 倍，且 100% 无遗漏、无误操作。更重要的是，这个pipeline_daily.yml文件可以 git commit，团队成员拉取后，只需wb run一行命令，就能复现完全一致的结果。

3. 流水线进阶：参数自动化、资源隔离与失败重试策略

当流水线从“能跑”走向“稳定量产”，就会遇到新问题：提示词从哪来？模型版本怎么管理？某张图生成失败，是重跑全部 10 张，还是只重跑那 1 张？WorkBuddy 提供了一套完整的进阶机制，不是靠“猜”，而是靠结构化设计。

3.1 参数来源：从硬编码到多源动态注入

在pipeline_daily.yml的loop.values里写死 10 条提示词，显然不可持续。WorkBuddy 支持三种参数注入方式，按优先级从高到低排列：

我最常用的是CSV 方式。创建data/prompts.csv：

id,prompt,negative_prompt,style_lut 001,"1girl, red dress, roses","lowres, bad hands","cinematic.cube" 002,"1boy, blue jacket, mountains","lowres, deformed fingers","filmic.cube" ...

然后在 pipeline YAML 中：

loop: over: "csv" file: "data/prompts.csv" columns: ["prompt", "negative_prompt", "style_lut"] parameters: prompt: "{{ loop.prompt }}" negative_prompt: "{{ loop.negative_prompt }}" luts: ["assets/luts/{{ loop.style_lut }}"]

这样，运营同学只需维护一个 Excel 表格，导出为 CSV，流水线就能自动读取并应用。当客户说“把第 5 张图的负面提示词改成bad anatomy, extra limbs”，你只需改 CSV 的第 5 行，wb run重跑即可，完全不用碰代码。

3.2 资源隔离：模型、LoRA、ControlNet 的版本化管理

ComfyUI 的模型文件动辄几个 GB，不同项目用的模型版本不同（如animagine-xl-3.1vsanimagine-xl-3.2），混在一起极易出错。WorkBuddy 的extra_model_paths.yaml是解法核心。

在 ComfyUI 根目录创建extra_model_paths.yaml：

animagine_v31: checkpoints: "models/checkpoints/animagine-xl-3.1" loras: "models/loras/animagine-v31" controlnet: "models/controlnet/animagine-v31" animagine_v32: checkpoints: "models/checkpoints/animagine-xl-3.2" loras: "models/loras/animagine-v32" controlnet: "models/controlnet/animagine-v32"

然后在anime_char.yaml的parameters中：

model: "animagine-xl-3.1.safetensors" model_group: "animagine_v31" # 新增字段，指向 extra_model_paths.yaml 的 key

WorkBuddy 在提交任务前，会自动读取extra_model_paths.yaml，根据model_group的值，将model字段解析为完整路径models/checkpoints/animagine-xl-3.1/animagine-xl-3.1.safetensors。这意味着：

• 你可以在 YAML 中写model_group: "animagine_v32"，瞬间切换整套模型生态；
• 不同 pipeline 可以共用同一份extra_model_paths.yaml，但各自指定不同model_group，实现资源逻辑隔离；
• 模型升级时，只需在extra_model_paths.yaml中新增一个 group，旧 pipeline 不受影响。

注意：extra_model_paths.yaml必须放在 ComfyUI 根目录，且--extra-model-paths-config参数必须指向它。这是 ComfyUI 官方机制，WorkBuddy 只是利用它，而非替代它。

3.3 失败重试：精准定位、局部重跑与熔断保护

流水线跑 100 张图，第 47 张失败了，你是重跑全部 100 张，还是只重跑第 47 张？WorkBuddy 的--resume模式专治此病。

当wb run执行中断（如 Ctrl+C，或某张图 OOM），WorkBuddy 会自动在.workbuddy/runs/目录下生成一个run_20240520_142301.json文件，记录每个 stage 的执行状态：

{ "run_id": "20240520_142301", "stages": [ { "name": "Preprocess", "status": "failed", "completed": 46, "failed": [47], "outputs": ["outputs/daily/001.png", ..., "outputs/daily/046.png"] } ] }

此时，执行：

wb resume --run-id 20240520_142301 --stage Preprocess --index 47

WorkBuddy 会：

• 跳过已完成的 46 张；
• 单独为第 47 项重新构造参数（读取data/prompts.csv第 47 行）；
• 提交 ComfyUI 任务；
• 将新生成的图覆盖到outputs/daily/047.png。

更进一步，你可以设置熔断阈值。在pipeline_daily.yml中添加：

options: max_failures_per_stage: 3 retry_delay_seconds: 5 retry_max_attempts: 2

含义是：单个 stage 内，最多允许 3 次失败；每次失败后等待 5 秒再重试；每个任务最多重试 2 次。如果第 47 张图连续重试 2 次都失败（比如显存不足），WorkBuddy 会标记为hard_failure，跳过它，继续执行第 48 张，确保整体流程不被单点故障阻塞。最终报告里会清晰列出：“Hard failures: [47]”，方便你事后专项排查。

我曾在一个生成 500 张电商图的项目中启用此策略。因某张图的提示词触发了 ControlNet 的边界 bug，导致 3 次重试均失败。WorkBuddy 自动跳过，其余 499 张按时交付。当天晚上，我单独用wb debug --run-id xxx --index 47命令，加载了当时的完整上下文（包括所有参数、模型路径、ComfyUI 日志），在本地复现并定位到是ControlNetDepthPreprocessor对纯白输入图的处理异常，随后提交了修复 PR。没有熔断，整个批次就得返工。

4. 真实踩坑全记录：那些文档里不会写的 5 个致命细节

WorkBuddy 的官方文档写得简洁优雅，但真实落地时，有 5 个细节几乎让每个新手都至少栽一次跟头。这些不是 Bug，而是设计权衡下的“隐性契约”，必须亲手踩过才懂。

4.1 坑一：ComfyUI 的--max-upload-size限制，会让大图上传直接 413

WorkBuddy 的assets功能很香，但如果你把一张 20MB 的高清参考图放进.workbuddy/assets/，然后在 workflow YAML 中引用它，大概率会失败。错误日志里只有模糊的HTTP 413 Payload Too Large。

原因在于：ComfyUI 的 FastAPI 服务默认--max-upload-size是 10MB（约 10485760 字节）。WorkBuddy 在提交任务时，会把assets中的图片作为 multipart/form-data 上传到 ComfyUI 的/upload/image接口，一旦超限，就被拒绝。

解决方案：启动 ComfyUI 时，显式增大该参数：

python main.py --listen 127.0.0.1 --port 8188 --enable-cors-header --max-upload-size 52428800

52428800= 50MB。这个值要根据你最大的参考图尺寸设定。我一般设为 100MB（104857600），足够应付绝大多数场景。

提示：这个参数只影响文件上传接口，不影响模型加载或图像生成性能。增大它不会增加内存占用，只是放宽了 HTTP 请求体大小限制。

4.2 坑二：Windows 路径中的反斜杠\，在 YAML 里是转义字符

你在extra_model_paths.yaml中写了：

checkpoints: "C:\ComfyUI\models\checkpoints"

结果 WorkBuddy 报错FileNotFoundError: C:ComfyUImodelscheckpointssomething.safetensors。路径里的\C、\m、\c全被 YAML 解析器当成了转义序列（\n换行，\t制表符）。

正确写法有三种：

• 双反斜杠："C:\\ComfyUI\\models\\checkpoints"（推荐，最直观）；
• 正斜杠："C:/ComfyUI/models/checkpoints"（Windows 兼容，且 YAML 无歧义）；
• 单引号包裹：'C:\ComfyUI\models\checkpoints'（单引号内反斜杠不转义）。

我后来统一采用正斜杠，因为.workbuddy/config.yaml、pipeline.yml等所有 YAML 文件都用它，跨平台（macOS/Linux 也是/）无缝迁移，且视觉上更清爽。

4.3 坑三：ComfyUI 的--gpu-only模式，会让 WorkBuddy 的健康检查误判

你为了极致性能，在启动 ComfyUI 时加了--gpu-only参数，强制所有计算走 GPU。这很好，但 WorkBuddy 的wb status命令在检查 ComfyUI 状态时，会发送一个轻量级测试请求（/prompt提交一个最小工作流）。这个测试工作流默认不指定device，ComfyUI 在--gpu-only模式下，若检测到请求未声明 GPU 设备，会直接拒绝，返回500 Internal Server Error，导致wb status显示ComfyUI Status: ERROR。

这不是 ComfyUI 真的挂了，而是测试逻辑不匹配。

绕过方法：在.workbuddy/config.yaml中，添加health_check_prompt字段：

comfyui_url: "http://127.0.0.1:8188" health_check_prompt: prompt: "3": { "class_type": "KSampler", "inputs": { "seed": 0, "steps": 1, "cfg": 1, "sampler_name": "euler", "scheduler": "normal", "denoise": 1, "model": ["2", 0], "positive": ["1", 0], "negative": ["4", 0], "latent_image": ["5", 0] } } # ... 其他最小化节点定义（可从 ComfyUI 的 "Save as API" 功能获取）

这个字段告诉 WorkBuddy：健康检查时，不要用默认测试，而是用你提供的、明确指定了 GPU 设备的完整工作流。这样，--gpu-only模式下也能通过检查。

4.4 坑四：LoRA 加载顺序错乱，导致权重叠加失效

你在anime_char.yaml中这样写：

parameters: lora_1: "detail-enhancer.safetensors" lora_2: "lighting-fix.safetensors"

并期望它们按 1→2 的顺序加载。但 ComfyUI 的 LoRA 节点（如LoraLoader) 本身不保证加载顺序，WorkBuddy 提交的 JSON 中，lora_1和lora_2的节点 ID 是随机生成的，可能lora_2的节点 ID 更小，被先执行，结果lighting-fix的权重覆盖了detail-enhancer。

根因：ComfyUI 的执行顺序由节点间的数据流依赖决定，而非参数名顺序。LoraLoader节点的输出（model和clip）必须被下游节点消费，才能形成依赖链。

正确做法：在 workflow YAML 中，显式定义节点依赖：

structure: - id: "lora_1_loader" type: "LoraLoader" inputs: model: "{{ loader.model }}" clip: "{{ loader.clip }}" lora_name: "{{ lora_1 }}" strength_model: 0.8 strength_clip: 0.8 - id: "lora_2_loader" type: "LoraLoader" inputs: model: "{{ lora_1_loader.model }}" # 关键！这里依赖 lora_1_loader 的输出 clip: "{{ lora_1_loader.clip }}" lora_name: "{{ lora_2 }}" strength_model: 0.6 strength_clip: 0.6

通过model: "{{ lora_1_loader.model }}"这行，强制lora_2_loader的model输入来自lora_1_loader的输出，从而建立确定的执行顺序。WorkBuddy 在生成最终 JSON 时，会按此依赖关系排序节点，确保lora_1先加载，lora_2后加载，权重叠加符合预期。

4.5 坑五：流水线并发数设太高，ComfyUI 显存 OOM，但 WorkBuddy 不报错

你设置了wb run --concurrency 8，想最大化 GPU 利用率。结果跑着跑着，ComfyUI 进程崩溃退出，WorkBuddy 却还在傻等，最终超时失败，错误日志里只有Connection refused，看不出是显存炸了。

真相：ComfyUI 崩溃后，其进程终止，127.0.0.1:8188端口不再监听，WorkBuddy 的请求自然失败。但 WorkBuddy 默认不监控 ComfyUI 进程状态，它只管发请求、收响应。

防御性配置：在.workbuddy/config.yaml中，启用process_watchdog：

process_watchdog: enabled: true check_interval_seconds: 10 restart_on_crash: true restart_command: "start_api.bat" # Windows 下重启脚本

开启后，WorkBuddy 会每 10 秒检查一次 ComfyUI 进程是否存活（通过端口探测 + 进程名匹配）。一旦发现崩溃，立即执行start_api.bat重启它，并等待 5 秒让服务就绪，再继续后续任务。这样，即使并发过高导致 OOM，系统也能自愈，流水线不会中断。

我在某次压力测试中故意将--concurrency设为 12，RTX 4090 显存瞬间打满，ComfyUI 崩溃。Watchdog 在 12 秒内完成检测、重启、恢复，整个流水线只延迟了 15 秒，且无任何任务丢失。这种“韧性”，是手工操作永远无法构建的。

5. 流水线不止于出图：如何把 WorkBuddy 扩展为 AI 工作流中枢

当 ComfyUI 流水线稳定运行后，你会自然思考：它能否不只是“出图”，而是成为整个 AI 工作流的调度中心？答案是肯定的。WorkBuddy 的设计哲学是“开放集成”，它预留了多个扩展钩子，我把它们称为“中枢接口”。

5.1 钩子一：pre_run和post_run脚本，接管前后置逻辑

WorkBuddy 允许你在流水线执行前、执行后，运行自定义的 Shell/Python 脚本。这让你能把 ComfyUI “嵌入”到更大的业务流程中。

例如，你想实现“用户上传一张照片 → 自动生成 3 种风格的漫画头像 → 邮件通知用户”：

• pre_run.sh：接收用户上传的input.jpg，用 OpenCV 裁剪为 512x512，保存到.workbuddy/assets/input.png；
• pipeline_avatar.yml：以input.png为参考图，调用controlnet_tile工作流生成 3 张图；
• post_run.py：将生成的 3 张图打包为 ZIP，调用 SMTP 库发送邮件给用户。

在pipeline_avatar.yml中声明：

hooks: pre_run: "scripts/pre_run.sh" post_run: "scripts/post_run.py"

WorkBuddy 会确保：pre_run.sh执行成功后，才开始 ComfyUI 任务；post_run.py执行成功后，整个流水线才算完成。任何一个脚本返回非零退出码，流水线即失败。这形成了一个可靠的“输入→处理→输出”闭环。

5.2 钩子二：Webhook 通知，打通 Slack、飞书、钉钉

生成任务耗时较长（如 30 分钟），你不可能一直守着终端。WorkBuddy 支持在关键节点触发 HTTP Webhook。

在.workbuddy/config.yaml中配置：

webhooks: on_start: url: "https://open.feishu.cn/open-apis/bot/v2/hook/xxx" method: "POST" headers: Content-Type: "application/json" body: | { "msg_type": "text", "content": { "text": "🎨 流水线 {{ pipeline.name }} 已启动，预计 {{ estimated_minutes }} 分钟完成" } } on_success: url: "https://discord.com/api/webhooks/yyy" body: | { "content": "✅ 流水线完成！共生成 {{ total_outputs }} 张图，详见 <{{ output_dir_url }}>" }

WorkBuddy 会自动填充{{ pipeline.name }}、{{ total_outputs }}等上下文变量。这样，任务一启动，飞书群里就弹出提醒；任务一完成，Discord 频道就收到汇总消息。信息触达零延迟，团队协作效率倍增。

5.3 钩子三：自定义节点集成，让 WorkBuddy 调用外部 API

WorkBuddy 的 YAML 工作流，不仅能调用 ComfyUI 内置节点，还能通过HttpNode调用任意外部 REST API。这打破了 ComfyUI 的边界。

假设你需要在生成图后，调用某第三方版权检测 API：

structure: - id: "copyright_check" type: "HttpNode" inputs: url: "https://api.copyright-check.com/v1/scan" method: "POST" headers: | { "Authorization": "Bearer {{ env.COPYRIGHT_API_KEY }}", "Content-Type": "application/json" } body: | { "image_url": "{{ Postprocess.outputs[0] }}", "threshold": 0.95 } outputs: - "is_safe" - "confidence" - id: "conditional_save" type: "ConditionalSaveNode" inputs: image: "{{ Postprocess.outputs[0] }}" condition: "{{ copyright_check.is_safe }}" safe_path: "outputs/final_safe/{{ loop.index }}.png" unsafe_path: "outputs/review/{{ loop.index }}_needs_review.png"

HttpNode会把Postprocess生成的图 URL 发送给版权 API，API 返回{ "is_safe": true, "confidence": 0.98 }，然后ConditionalSaveNode根据is_safe布尔值，决定把图存到final_safe还是review目录。整个过程对 ComfyUI 透明，WorkBuddy 全权调度。

我曾用这套机制，为某高校的学术图像生成平台集成了论文查重 API。所有学生提交的生成图，自动经过版权筛查，高风险图进入人工审核队列，低风险图直通下载。整个流程无需人工干预，日均处理 2000+ 张图。

5.4 构建你的 AI 工作流中枢：一个可落地的三年演进路线

最后，分享我个人规划的一条务实演进路径，它不追求一步登天，而是基于现有 ComfyUI 流水线，逐步扩展：

• **第 1