我用 WorkBuddy 把本地 ComfyUI 管成了一条出图流水线

一台 8GB 显存的笔记本，零积分，从"每次手动拖工作流"到"一句话触发、自动归档"。这篇把这一路上真正踩过的坑全写下来了。

一、起点：为什么我把生成端搬回本地

用 AI 生图的人迟早会撞上同一堵墙。云端工具确实好用，但有三件事绕不开：

• 要积分、要订阅，跑一个系列就是一串消耗；
• 没有 LoRA 接口——你没法把"这一张脸、这一种身形、这一套配色"固定下来，每次都是重新抽卡；
• 提示词、参考图、产物全在别人的服务器上。

我的解法是把生成端放回本地（ComfyUI + 一块 RTX 5060 Laptop 8GB），然后让 WorkBuddy 站在"总控"的位置上。

这里要说清楚分工：WorkBuddy 不画画，它管"画画这件事"。 探环境、拼参数、提交任务、轮询结果、归档产物、审查提示词——这些又碎又容易出错的活，全交给它。

下面八条，每一条都能直接抄。

本地生成·国风电影感肖像

二、第一件事：先让 WorkBuddy 把机器摸清楚

很多人卡在第一步不是不会用 ComfyUI，是不知道自己这台机器到底能吃多大的模型。

我做的第一件事，是让 WorkBuddy 直接去问引擎：读 /system_stats 拿显存与设备信息，列 models/ 目录清点权重。它给出的判断很干脆：

8GB 显存，主模型只能上量化档。 我的主模型是一枚 5.7G 的 Q3_K_M GGUF；同目录下那个 7.0G 的 Q4_K_M 看起来只大一点，但换页成本高到不值得——多出来的 1.3G 会让权重被切得更碎，每步都要从内存搬回来。

这一步的价值不在结论，在方法：以后换任何新模型，先让它报"文件多大、我这卡装不装得下、装不下会掉多少速度"，比出图时才发现爆显存划算得多。

⚠️ 顺带一个埋得很深的坑：ComfyUI 的插件依赖不一定写在 pyproject.toml 里。我装 ReActor 时，它依赖的 segment_anything（SAM）没被写进依赖表，漏装之后启动日志只报一句 No module named 'segment_anything'，22 个节点一个都不注册——症状看起来特别像"插件根本没装上"，其实是差一个纯 Python 包。从别的环境拷一个 site-packages/segment_anything 进去就好了。

三、让它当调度员：脚本化提交 + 轮询

ComfyUI 自带的工作流画布适合调试，不适合批量。真正的效率来自 API 层提交。

这里有个关键纪律：工作流源 JSON 只读，绝不手改。 画布上拖一下保存一次，格式和节点 ID 都可能变，脚本跟着崩。正确做法是在提交时动态改：

import json, urllib.request

def submit(api, server="http://127.0.0.1:8188"):
    payload = json.dumps({"prompt": api}).encode()
    req = urllib.request.Request(f"{server}/prompt", payload,
                                {"Content-Type": "application/json"})
    return json.loads(urllib.request.urlopen(req).read())["prompt_id"]

然后把这张工作流交给 WorkBuddy，让它写成一个可复用的提交脚本：读源 JSON → 注入参数（seed、分辨率、提示词、权重）→ 提交 → 轮询 /history/<id> 拿结果 → 按命名规则落到指定目录。

这一步之后，出图从"打开浏览器拖节点"变成"跑一行命令"。 后面所有批量、所有套图、所有系列复用，都是在这一层上加东西。

四、四只 LoRA 的链式串联（含最容易写错的一行）

风格稳定的核心是 LoRA 链。我的主力配方是四只串在一起：

前两只挂在源工作流原有节点上，后两只在 API 层新造节点接到链尾——源 JSON 一个字不改：

def append_lora_chain(api, extra, first_free_id=100):
    ks = [nid for nid, n in api.items() if n["class_type"] == "KSampler"][0]
    cur = api[ks]["inputs"]["model"]          # 形如 ["11", 0]
    nid = first_free_id
    for name, strength in extra:
        api[str(nid)] = {"class_type": "LoraLoaderModelOnly",
                         "inputs": {"model": cur,
                                    "lora_name": name,
                                    "strength_model": strength}}
        cur = [str(nid), 0]
        nid += 1
    api[ks]["inputs"]["model"] = cur

★ 关掉某只 LoRA 的正确写法

这是我最想越过屏幕来提醒你的一条：不要通过"删掉那条配置"来关掉一只 LoRA。

你的权重列表和 LoRA 列表是按下标一一对应的，删掉一条会让后面的整体错位；更糟的是节点还留在图里，继续吃原来那份权重。

正确的做法只有一个——把强度写成 0.00，然后清掉动态追加的节点：

extra = [(name, 0.00) if name in DISABLED else (name, w) for name, w in extra]

换题材时别沿用旧档位

同一个配方，换题材要换档。我固定五档：

LoRA 挂不上的三种可能，3 秒判完

拿不准一只 LoRA 能不能挂到当前底模上，读它的键名前缀就行：

• lora_unet_input/middle/output_blocks → SD 1.5 系
• lora_unet_down/mid/up_blocks + attentions_transformer_blocks → SDXL 系
• diffusion_model.blocks.*.attn.wq/wk/wv/wo/gate → DiT 系（Krea2 / Qwen-Image / Flux）

我本地囤的好几只 SDXL 精细度 LoRA，挂到 DiT 底模上一条权重都贴不上——不是权重设小了，是压根没有对应的张量可加载。

另一个小坑：LoRA 放在子目录里时，lora_name 必须用反斜杠（subdir\file.safetensors），写成正斜杠会被直接 HTTP 400 秒拒，连图都不跑。

本地生成·LoRA 风格化定妆

五、cfg=1.0 的双重否定禁令：这篇最值钱的一段

先记死采样档位：8 步 / cfg 1.0 / euler / simple / denoise 1.0。这是蒸馏 turbo 模型的官方档，别动。

然后是真正的重点。当 cfg = 1.0 时，负向提示词是完全无效的。

不是"效果弱"，是根本不执行。采样器里有一段优化逻辑，在 cond_scale == 1.0 时直接把 uncond_ 置为 None——

# comfy/samplers.py（示意）
if cond_scale == 1.0 and disable_cfg1_optimization is False:
    uncond_ = None      # 负向分支压根不跑

所有"去 AI 味""不要 xx"的词，必须写进正向。 写进负向框里，等于没写。

但这还不是最坑的。更坑的是下面这条：

正向里的否定句式，同样自伤

文本编码器不做逻辑否定。你写 no sheerness and no translucency，它读到的概念恰恰是 sheerness + translucency。实测表现非常反直觉：越写"不透明"，出图越透。

正确做法是：正向里一律不出现 no / not / never / rather than / without / nothing 结构，只写"我要的那个实物属性"。

中文的"否定式形容词"一样中招。 写"遮挡""密实"时，人很自然会写成「不透」「看不穿」「见不到」「不入画」——这些全是含否定词的形容词，命中同一条禁令。编码器读到的正是「透」「穿」「见」这几个概念本身。

人眼靠不住，必须上机器门禁

最后这一类最阴：「无 / 不」藏在普通词组里。无名指、无意间、不笑也自有一段柔媚——写的时候全都读得通、看着毫无问题。

我自认为写了一份很干净的四机位提示词，被正则门禁抓出 3 处「密实不透」，写的时候一个都没察觉。

所以这条检查必须写成硬门禁，而不是打印一句警告——命中就中止出图：

import re

BAN = re.compile(r"不|无|非|没有|避免|禁止|别|勿|"
                 r"\bno\b|\bnot\b|\bnever\b|\bwithout\b|\bavoid\b|\bfree of\b", re.I)

def assert_no_negatives(prompt: str):
    hits = [l for l in prompt.splitlines() if BAN.search(l)]
    if hits:
        raise SystemExit("❌ 命中否定词，禁止出图：\n" + "\n".join(hits))

（只 print 警告等于没有自检——我真的抓到过 without 却照样把图跑完了。）

六、显存就是速度：别急着换加速内核

8GB 卡上，"慢"这件事九成不是算力问题，是权重被切了多少。

启动日志里搜这一行：

loaded partially; X MB usable, Y MB loaded, Z MB offloaded

我同一台机器、同一组参数，只改可用显存，速度差一倍：

可用显存只差 262MB，速度就差 50%。

我一开始的直觉是"装个注意力加速库"。实测下来这条路收益极小：官方自带的那套 CUDA INT8 注意力开起来，同 seed 严格对比 s/it 只快 4.8%、总耗时只快 1.5%，画质无损但也几乎白忙。至于第三方方案，本机 torch 版本已经超出预编译 wheel 的覆盖范围，得自己备编译器，不值得。

结论：真正的提速杠杆是腾显存——关掉吃显存的程序、降画幅、减 LoRA、调 offload 参数。别在注意力内核上找速度。

顺手一张耗时表（四 LoRA，插电状态），方便你估时间：

★ 最容易忽略的一条：笔记本不插电时，驱动会把功耗墙锁到 35W，每步从 6.8 秒膨胀到 56 秒（8 倍）。出图突然变慢，先看一眼电源线，再看日志。

七、写词：让 WorkBuddy 做"细节审查官"

前六条是工程，这一条是审美。而这一条我吃过最多亏。

**★ 别写概念词，写坐标

本地生成·写实生活质感

我连出过九版图，问题全都一样：衣服该滑落的只滑一侧、该宽松的写了两版还是紧贴、材质反复没变化。根子不在模型，在我写的全是"结论"——「滑落」「飘逸」「宽松随意」。模型拿到的是结论不是坐标，它就会按最省力的路走。

后来我把这套改法固化成了两条规则，交给 WorkBuddy 逐句审：

规则一：每条部位句答齐"五问"

规则二：材质必须写到"织物层"，能摸到为止

「丝质」「飘逸」「轻薄」「宽松」这类空洞词一律不合格。要写组织与形状：

对照着看最清楚：

本地生成·面部与材质特写

配套一条：褶皱要写"落点分区"

整件衣服平均堆一遍褶 = 假。 真实织物只有受力处绷平、离体处堆褶，而且褶量是守恒的——一处绷平，褶量必然被挤到旁边去。

⚠️ 注意「不皱」不能直写——回到第五节，它喂给编码器就是「皱」。一律翻成肯定式：平整 / 平顺 / 服帖 / 绷平。

交付前跑一遍这条自检

逐句问自己：这句话在画面上能被指出来吗？指不出来就是空话。 说不清"指哪儿"的句子，删掉重写。逐句过，不是整段扫一眼。

八、踩坑速查表

本地生成·雨夜氛围竖构图

九、最后：WorkBuddy 在这里到底值什么

回看整条链路——

探环境、拼参数、串 LoRA、写提示词门禁、读日志定位瓶颈、审查细节描写、归档产物——这些活的共同点是：碎、重复、且错了不容易发现。

ComfyUI 负责"画得好不好"，WorkBuddy 负责"这件事有没有按规矩跑完"。前者决定天花板，后者决定你能不能不靠意志力，把一套流程稳定地重复一百遍。

我那套出图流程现在的样子是：写好提示词 → 过一遍门禁 → 提交 → 轮询 → 自动落盘 → 归档 → 下一张。

人只做两件事：定方向，看图。

本文所有参数、耗时、报错均来自本机 RTX 5060 Laptop 8GB 的真实实测记录。配图均为本地生成、并已剥离原始元数据。