★ FEATURED ARTICLE 1. WorkBuddy 是什么它为什么能“管住” ComfyUI 这头猛兽很多人第一次听说 WorkBuddy会下意识把它当成另一个“ComfyUI 启动器”或者“UI 美化插件”。我最初也是这么想的——直到我在某次连续三小时调试一个带 27 个节点、嵌套 4 层循环的 ControlNetIP-Adapter 工作流时电脑风扇声盖过了空调显存占用曲线像心电图一样反复冲顶又骤降而我连保存当前状态都得手动截图、记笔记、关掉所有节点再重开……那一刻我才意识到ComfyUI 的强大恰恰是它最难被“管理”的根源。WorkBuddy 不是 UI 插件也不是模型加载器它是一个面向工作流生命周期的轻量级编排层Workflow Orchestration Layer。它的核心定位非常清晰不碰 ComfyUI 的底层执行逻辑也不改写任何 Python 节点代码而是像一位经验丰富的产线班组长在 ComfyUI 这台精密机床的“输入口”和“输出口”之间加装了一套可配置、可追溯、可复用的调度系统。它解决的不是“能不能出图”的问题而是“能不能稳定、可重复、可协作、可回溯地出图”的问题。举个生活化类比ComfyUI 是一台功能齐全但没有操作手册、没有预设模式、所有旋钮都裸露在外的工业级咖啡机而 WorkBuddy 就是你在它前面加装的智能控制面板——你可以一键调用“美式浓缩”“冷萃冰滴”“双份奶泡拿铁”三种预设配方每种配方自动记录水温、研磨度、萃取时间、奶泡温度还能在出杯失败时自动触发“重做上一杯”并保留全部参数快照。这个定位决定了 WorkBuddy 的技术边界它不替代 ComfyUI也不试图封装 ComfyUI它只做三件事——固化流程、隔离环境、追踪状态。所以它不需要修改 ComfyUI 源码不依赖特定 Python 版本甚至不强制要求你用官方启动方式。我实测过无论你是用comfyui.exe双击运行、用python main.py命令行启动还是通过 Docker 容器部署只要 ComfyUI 的/api接口正常响应WorkBuddy 就能无缝接入。提示WorkBuddy 的本质是 HTTP 客户端 本地元数据管理器。它通过标准 ComfyUI API如/prompt,/history,/view与后端通信所有“管理”动作最终都转化为对这些接口的结构化调用。这意味着它天然兼容所有遵循 ComfyUI API 规范的衍生版本如 ComfyUI-Manager、ComfyUI-Custom-Nodes 生态不存在“锁死官方版”的风险。这也是为什么它能“把本地 ComfyUI 管成一条出图流水线”——流水线的核心不是速度而是确定性。当你的 prompt 修改、模型切换、采样器参数调整、图像尺寸变更都能被 WorkBuddy 自动捕获、打标、归档、复用时“出图”就从一次性的手工操作变成了可批量、可审计、可交接的标准化工序。后面我会详细拆解它是如何做到这一点的。2. 流水线成型的关键WorkBuddy 的三大支柱能力WorkBuddy 的能力不是堆砌出来的而是围绕“让 ComfyUI 工作流具备工程化属性”这一目标构建起的三个相互支撑的支柱。它们共同构成了那条“流水线”的骨架。很多用户初期只看到界面按钮却忽略了背后这三层设计逻辑——结果就是用得很顺手但一遇到跨设备迁移或多人协作就卡壳。下面我逐层拆解说明每个支柱解决了什么具体问题以及它为什么非如此不可。2.1 支柱一工作流模板Workflow Template——把“临时灵感”变成“可复用资产”ComfyUI 最常见的痛点之一是“调好一个效果下次想复现却找不到当初的 JSON 文件”。你可能有几十个.json文件散落在不同文件夹里命名像flux_v2_32000steps_20240512.json、ipad_v3_fix_lighting.json、final_final_v2_fixed.json……这种命名方式在单人小项目里尚可忍受但一旦涉及多轮迭代、AB 测试、客户返稿就会迅速失控。WorkBuddy 的工作流模板本质上是一套带元数据封装的 JSON 包装器。它不改变原始 ComfyUI 工作流结构而是在其外部增加一层描述层包含语义化名称非文件名如“电商主图-白底-8K-光影强化”用途标签Tag#product,#e-commerce,#lighting-enhance关联资源引用自动记录该模板所依赖的 Checkpoint、Lora、ControlNet 模型路径注意是路径不是文件名避免因重命名失效默认参数快照包括seed设为 -1 表示随机、steps、cfg、sampler_name、scheduler等关键字段的初始值版本备注支持添加简短说明如“修复了 face detail 在 1024x1024 下的崩坏问题”最关键的是WorkBuddy 模板支持参数覆盖机制。当你基于某个模板启动新任务时可以只修改width1280和height720其余所有参数包括模型路径、节点连接关系均继承自模板。这彻底终结了“复制粘贴 JSON → 手动改 5 处路径 → 忘记改第 6 处 → 出图报错”的恶性循环。我曾用这个功能重构了一个客户定制的服装平铺图生成流程。原来需要手动加载 3 个 Lora布料纹理、缝线细节、阴影层次、设置 2 个 ControlNet深度图法线图、调整 7 处采样参数。现在只需在 WorkBuddy 中选择“服装平铺-高精度”模板输入产品图路径和背景色 HEX 值点击“提交”整个流程自动完成。客户反馈修改意见后我直接在历史记录里找到上一次成功出图的模板实例仅修改control_net_strength参数30 秒内生成新版本。这才是流水线该有的样子。2.2 支柱二环境沙箱Environment Sandbox——让“换模型不翻车”成为常态ComfyUI 用户最深的恐惧之一是“昨天还能跑通的工作流今天打开就报错”。究其原因90% 都源于环境污染某个新装的 Custom Node 更新了依赖库导致旧版节点崩溃某个 Lora 模型更新了适配器与现有 ControlNet 冲突甚至只是 Python 包版本微调如torch2.1.0升级到2.1.1就引发 CUDA 内存分配异常。WorkBuddy 的环境沙箱不是指虚拟机或 Docker那太重而是一种进程级依赖隔离策略。它通过以下三步实现“安全换模”模型指纹注册首次加载任意模型Checkpoint/Lora/VAE/ControlNet时WorkBuddy 会计算其 SHA256 哈希值并与模型文件路径、创建时间、所属工作流模板绑定存入本地 SQLite 数据库。这意味着哪怕你把realisticVisionV60B1_v51HyperVAE.safetensors重命名为my-best-model.safetensorsWorkBuddy 仍能识别出它是同一文件。沙箱配置文件Sandbox Config每个工作流模板可绑定一个.sandbox.yml文件内容类似python_version: 3.10.12 torch_version: 2.1.0cu118 comfyui_commit: a1b2c3d # 对应 ComfyUI 仓库的 commit hash required_nodes: - comfyui_controlnet_aux0.0.12 - comfyui-ipadapter1.1.0启动时校验与提示当你点击“用此模板运行”时WorkBuddy 会实时检查当前 ComfyUI 进程的 Python 版本、Torch 版本、Git Commit ID并比对.sandbox.yml中的声明。若发现不匹配如当前 Torch 是2.1.1而模板要求2.1.0它不会强行启动而是弹出明确提示“检测到 Torch 版本不匹配期望 2.1.0当前 2.1.1。是否① 切换至兼容环境推荐② 强制运行可能报错③ 查看差异详情”——这个选项救了我至少 5 次深夜调试。这个机制的价值在于把“环境问题”从“玄学故障”变成了“可读日志”。以前同事问我“为什么他那边跑不通”我只能让他截图报错信息然后凭经验猜是哪个包冲突现在我直接让他导出 WorkBuddy 的沙箱诊断报告一个 JSON 文件里面清晰列出所有版本差异项3 分钟内就能定位根因。2.3 支柱三执行历史Execution History——让每一次出图都“留痕、可溯、能复”ComfyUI 默认的历史记录/historyAPI 返回的数据只包含prompt_id、status、outputs路径缺失最关键的上下文这次出图用的是哪个工作流模板当时设置了哪些覆盖参数模型路径是否已被移动有没有手动修改过节点内部值比如某个CLIPTextEncode节点的文本框WorkBuddy 的执行历史是一个增强型审计日志系统。每次成功提交 Prompt它都会持久化记录字段说明实例值template_id关联的工作流模板唯一标识tpl-7f3a2b1coverride_params用户显式覆盖的参数JSON 格式{seed: 12345, steps: 30}model_fingerprints本次运行实际加载的模型哈希列表[sha256:abc..., sha256:def...]node_edits手动修改过的节点 ID 及修改内容仅记录变化{12: positive prompt updated}execution_time从提交到完成的精确毫秒数142857output_files生成的所有文件路径含缩略图、元数据 JSON[out/20240515_142233_12345.png, ...]这个日志不是存在内存里而是以 SQLite 数据库存储在本地workbuddy/history.db。这意味着你可以用标准 SQL 查询“查出所有使用juggernautXL_v8R.safetensors且cfg 7的成功出图记录”可以导出为 CSV用 Excel 做 AB 测试效果对比比如统计不同denoise值下的平均出图质量分更重要的是当客户说“我要和上次一模一样的图但换个背景色”你不用翻聊天记录、不用猜参数直接在 WorkBuddy 历史页搜索关键词找到对应记录点击“复刻此任务”它会自动加载原模板、填入原参数、只让你修改background_color字段——整个过程 10 秒内完成。我曾用这套历史系统帮某高校实验室重建了一个中断半年的图像生成实验。他们原来的 ComfyUI 工作流全靠口头传承没人记得清第 3 轮实验用的是哪个 Lora 组合。我们导入 WorkBuddy 历史数据库按时间范围筛选导出所有prompt_id对应的完整参数快照3 小时内就还原出了全部 12 个实验组的精确配置。没有 WorkBuddy 的历史追踪这事至少要花 2 天。3. 从零搭建WorkBuddy ComfyUI 流水线的实操四步法很多用户卡在第一步不知道 WorkBuddy 怎么装、怎么连、怎么用。网上教程要么过于简略“下载解压即可”要么过度复杂硬推 Docker Nginx 反向代理。作为每天都在这条流水线上干活的人我总结出一套零基础、低侵入、可验证的四步落地法。它不要求你懂 Python 虚拟环境不强制修改 ComfyUI 源码甚至不需要管理员权限——所有操作都在用户目录下完成。3.1 第一步确认 ComfyUI 基础服务可用5 分钟这是最容易被跳过的一步却是后续所有操作的前提。WorkBuddy 依赖 ComfyUI 的 Web API如果 API 不通再好的管理工具也是废铁。请严格按顺序执行以下检查在你启动 ComfyUI 的终端窗口中操作确认 ComfyUI 正在运行且监听正确端口启动 ComfyUI 后观察终端输出的最后一行。正常情况应包含类似Starting server on 127.0.0.1:8188或Starting server on 0.0.0.0:8188注意如果你看到127.0.0.1表示只允许本机访问0.0.0.0表示允许局域网访问。WorkBuddy 默认连接127.0.0.1:8188无需修改。手动测试 API 连通性打开浏览器访问http://127.0.0.1:8188/object_info。你应该看到一个巨大的 JSON 响应内容是 ComfyUI 所有节点的定义如CLIPTextEncode: { input: {...}, output: [...] }。如果页面显示ERR_CONNECTION_REFUSED说明 ComfyUI 没启动或端口被占如果返回404说明你访问的不是 ComfyUI 的根路径检查 URL 是否多写了/api或少写了端口号。验证/prompt接口可写这是最关键的一步。新建一个文本文件test_prompt.json内容如下这是一个极简工作流只生成纯色图{ prompt: { 3: { class_type: EmptyLatentImage, inputs: {width: 512, height: 512, batch_size: 1} }, 6: { class_type: VAEDecode, inputs: {samples: [3, 0], vae: [4, 0]} } } }然后在终端执行确保 ComfyUI 正在运行curl -X POST http://127.0.0.1:8188/prompt \ -H Content-Type: application/json \ -d test_prompt.json如果返回{prompt_id: xxx}说明 API 写入正常如果返回{error: ..., reason: ...}请根据错误信息排查常见原因是test_prompt.json格式错误或缺少必要节点。这三步做完你才真正拥有了一个“可编程的 ComfyUI”。WorkBuddy 的所有能力都建立在这个坚实的基础上。跳过此步后面所有配置都是空中楼阁。3.2 第二步安装 WorkBuddy 并完成首次对接8 分钟WorkBuddy 提供两种安装方式绿色免安装版推荐新手和Python 包安装版适合进阶用户。这里只讲绿色版因为它最简单、最可控、最易卸载。下载与解压访问 WorkBuddy 官方 GitHub Release 页面搜索workbuddy release下载最新版workbuddy-vX.X.X-win64.zipWindows或workbuddy-vX.X.X-macos-arm64.zipMac M 系列。解压到任意位置例如D:\tools\workbuddy。配置 ComfyUI 连接进入解压后的文件夹找到config.yaml。用记事本Windows或 TextEditMac打开它。找到comfyui部分修改为comfyui: host: 127.0.0.1 port: 8188 # 如果你的 ComfyUI 启用了认证请取消下面两行注释并填写 # username: your_username # password: your_password注意WorkBuddy 默认不启用认证。如果你的 ComfyUI 开启了--enable-cors-header或--user参数请务必在此处同步配置否则连接会失败。首次启动与验证双击workbuddy.exeWindows或workbuddy.appMac。首次启动会自动创建templates/和history/目录。等待 5 秒软件主界面左上角应显示绿色圆点 ✅ 和文字 “Connected to ComfyUI (127.0.0.1:8188)”。如果显示红色 ❌请检查config.yaml中的地址和端口是否与 ComfyUI 启动日志完全一致。此时WorkBuddy 已经成功“看到”你的 ComfyUI。但还不能出图——它需要知道你打算用什么工作流。下一步就是导入或创建第一个模板。3.3 第三步创建你的第一个工作流模板12 分钟别被“模板”二字吓到。WorkBuddy 的模板创建本质就是“给一个已有的 ComfyUI JSON 工作流加上一层描述信息”。我们以最常用的“SDXL 文生图”为例。准备基础工作流 JSON在 ComfyUI 界面中用节点搭建一个最简 SDXL 工作流Load Checkpoint→CLIPTextEncode正向提示词→CLIPTextEncode负向提示词→KSampler→VAEDecode→SaveImage。然后点击右上角Queue Prompt旁的Save图标将工作流保存为sdxl_base.json到D:\comfyui\custom_nodes\workbuddy_templates\路径可自定。在 WorkBuddy 中导入启动 WorkBuddy点击左侧导航栏的Templates→ New Template。在弹出窗口中Template Name: 输入 “SDXL 基础文生图”Tags: 输入#sdxl #text2image #baseDescription: 输入 “SDXL 1.0 官方 Checkpoint适用于通用文生图任务”Workflow File: 点击Browse选择刚才保存的sdxl_base.jsonDefault Parameters: 在下方表格中添加两行seed→-1表示随机steps→30保存并验证点击Save。你会在模板列表中看到新条目。点击它右侧的▶ Run按钮。WorkBuddy 会自动将sdxl_base.json发送到 ComfyUI 的/prompt接口并在界面上显示“Queued” → “Running” → “Success”。几秒钟后output/文件夹里会出现一张新图。这一步的意义在于你亲手完成了“从 ComfyUI 原生工作流”到“WorkBuddy 可管理资产”的转化。以后所有优化加 ControlNet、换 Lora、调参数都基于这个模板进行而不是在原始 JSON 上反复修改。3.4 第四步配置自动化流水线15 分钟现在你已经能用 WorkBuddy 启动单次任务。但真正的“流水线”意味着它可以自动响应外部事件、批量处理、无人值守。WorkBuddy 通过Triggers触发器模块实现这一点。我们以一个高频需求为例监控一个文件夹当有新图片放入时自动用指定模板为其生成 3 种风格的变体图写实、插画、赛博朋克。创建三个风格化模板基于上一步的SDXL 基础文生图模板分别克隆Clone三次命名为SDXL 写实风格在正向提示词中加入photorealistic, ultra-detailed, f/1.4, shallow depth of fieldSDXL 插画风格加入illustration, flat design, clean lines, pastel colorsSDXL 赛博朋克加入cyberpunk, neon lights, rain-soaked streets, chrome, 80s retro设置文件夹监控触发器点击左侧Triggers→ New Trigger→ 选择File Watcher类型。Watch Path: 设置为D:\comfyui\input_images\你存放待处理图片的文件夹File Pattern:*.png, *.jpg, *.jpeg支持的图片格式Trigger On:Created文件创建时触发Action:Run Workflow TemplateTemplate: 选择SDXL 写实风格Parameters Override: 添加一行input_image_path→{file_path}这是 WorkBuddy 的内置变量代表刚创建的文件路径添加批量分发逻辑点击Add Another Action重复上述步骤两次分别选择SDXL 插画风格和SDXL 赛博朋克模板并同样设置input_image_path为{file_path}。启用并测试点击Enable Trigger然后将一张test.jpg放入D:\comfyui\input_images\。WorkBuddy 日志区会立即显示[INFO] FileWatcher: Detected new file D:\comfyui\input_images\test.jpg [INFO] Trigger Style Batch executing action 1/3... [INFO] Trigger Style Batch executing action 2/3... [INFO] Trigger Style Batch executing action 3/3...30 秒后output/文件夹里会出现test_realistic.png,test_illustration.png,test_cyberpunk.png三张图。至此一条完整的、可扩展的、无人值守的图像生成流水线已经建成。你不再需要打开 ComfyUI 界面不再需要手动拖拽节点所有操作都由 WorkBuddy 在后台调度完成。这就是“管成一条流水线”的真实含义。4. 高阶实战用 WorkBuddy 解决 ComfyUI 团队协作中的三大顽疾当 ComfyUI 从个人玩具升级为团队生产工具时新的问题会指数级涌现。我曾在某视觉创意工作室担任技术顾问他们用 ComfyUI 为 12 个客户制作营销素材团队共 5 人。最初大家各自维护自己的 ComfyUI 实例结果出现了三个经典顽疾版本混乱、参数失焦、责任难溯。WorkBuddy 的高阶用法正是为解决这些问题而生。下面我用真实场景还原告诉你如何用 WorkBuddy 的进阶功能一一击破。4.1 顽疾一版本混乱——“为什么我的机器上跑出来是糊的他的就是高清的”现象设计师 A 用juggernautXL_v8R.safetensorscontrolnet-scribble-sdxl-1.0生成了完美的草图转线稿效果设计师 B 拿着同样的 JSON 工作流在自己电脑上运行却得到模糊、断线的结果。两人核对模型文件名、节点版本、ComfyUI 版本全都一致问题陷入僵局。根因分析表面看是“模型相同”实则是模型加载路径不同导致的权重加载偏差。A 的模型放在D:\models\checkpoints\B 的放在E:\AI\models\checkpoints\。ComfyUI 的Load Checkpoint节点在 JSON 中记录的是相对路径如../checkpoints/juggernautXL_v8R.safetensors当工作流在不同机器上加载时..指向的父目录不同实际加载的文件可能根本不是同一个。WorkBuddy 的解法全局模型注册中心 路径无关引用统一注册所有模型在 WorkBuddy 主界面点击Models→ Register Model。为每个常用模型Checkpoint/Lora/ControlNet单独注册Model Type: 选择CheckpointModel Name:Juggernaut XL V8RFile Path:D:\models\checkpoints\juggernautXL_v8R.safetensorsA 的路径Fingerprint: WorkBuddy 自动计算Aliases: 添加juggernaut,xl-v8r便于搜索然后让 B 在他的机器上用完全相同的Model NameJuggernaut XL V8R和Aliases但指向他本地的路径E:\AI\models\checkpoints\juggernautXL_v8R.safetensors。WorkBuddy 会为两个路径生成相同的model_id如mdl-9a8b7c6d。模板中引用 model_id 而非路径当创建工作流模板时在Workflow File的 JSON 中将Load Checkpoint节点的inputs.checkpoint_name字段从原来的文件名juggernautXL_v8R.safetensors改为 WorkBuddy 的模型 IDmdl-9a8b7c6d。WorkBuddy 在提交 Prompt 前会自动将mdl-9a8b7c6d替换为当前机器上注册的对应物理路径。效果A 和 B 使用同一个模板 JSON其中只含mdl-9a8b7c6d在各自机器上运行都能加载到正确的、经过指纹校验的模型文件。版本混乱问题从根源上消失。注意这个功能要求团队成员使用同一套Model Name命名规范。我们制定了《模型命名公约》[品牌/作者]-[模型名]-[版本号]如stabilityai-sdxl-turbo-1.0、comfyanonymous-controlnet-scribble-sdxl-1.0。公约由团队负责人在 WorkBuddy 的Models页面统一发布新人入职第一件事就是导入公约。4.2 顽疾二参数失焦——“客户说要调亮一点但我们有 17 个地方影响亮度”现象客户反馈“人物脸部太暗”需要提亮。团队有 5 个相关参数可能影响KSampler的cfg、denoiseCLIPTextEncode的正向提示词加bright lightingControlNet的strengthVAEDecode前的ImageScale节点。设计师们各自尝试修改结果 A 调了cfgB 改了提示词C 动了ControlNet strength最后交出的 3 张图风格迥异客户更困惑了。根因分析ComfyUI 的参数是“分散式”的没有统一的“亮度控制中枢”。每个节点独立工作参数之间缺乏语义关联。WorkBuddy 的解法参数组Parameter Group 语义化覆盖定义语义化参数组在 WorkBuddy 的Templates编辑页点击Advanced Settings→ Add Parameter Group。创建名为Lighting Control的组包含lighting_brightness类型Slider范围 0.5–2.0默认 1.0lighting_contrast类型Slider范围 0.8–1.5默认 1.0lighting_style类型Dropdown选项Soft,Dramatic,Studio将参数组映射到具体节点在同一页面找到Parameter Mapping区域。为lighting_brightness添加映射Node ID:12假设这是KSampler节点 IDField:cfgFormula:base_value * lighting_brightnessbase_value是模板中cfg的默认值如 7 为lighting_style添加映射Node ID:5假设这是CLIPTextEncode节点 IDField:textFormula:if lighting_style Soft: soft lighting, even exposure elif lighting_style Dramatic: dramatic lighting, high contrast shadows else: studio lighting, professional portrait交付客户时只暴露语义参数当需要向客户演示或收集反馈时WorkBuddy 可以生成一个精简版的 Web 表单Share → Generate Web Form表单上只有三个控件Brightness Slider、Contrast Slider、Lighting Style Dropdown。客户完全不需要知道cfg、text是什么他只关心“亮一点”、“对比强一点”、“要影楼风”。效果参数从“技术符号”变成了“业务语言”。客户的一句“再亮一点”直接对应lighting_brightness从 1.2 调到 1.3WorkBuddy 自动计算出cfg 7 * 1.3 9.1并注入KSampler节点。所有设计师操作的是同一套语义参数结果自然一致。4.3 顽疾三责任难溯——“这张图是谁改的改了哪为什么改”现象项目上线前 QA 发现一张图的 Logo 位置偏移了 5 像素。追溯 Git 提交记录发现过去 3 天有 8 次工作流 JSON 的修改。没人记得清哪次修改影响了ImageScale节点的scale_by字段。根因分析ComfyUI 工作流是二进制 JSONGit 无法有效 diff人工记录修改日志容易遗漏没有强制的审批流程。WorkBuddy 的解法模板版本控制Template Versioning 变更审计日志启用模板版本控制在Templates列表页找到目标模板点击右侧⋯→Enable Versioning。WorkBuddy 会为该模板创建一个 Git 仓库位于workbuddy/templates/[template_id]/.git所有对模板的修改JSON 内容、参数默认值、描述文字都会自动提交附带提交者姓名从系统用户名获取和时间戳。查看可视化变更对比点击模板右侧History进入版本历史页。选择任意两个版本WorkBuddy 会以高亮方式显示 JSON 的差异绿色新增的字段如inputs: {scale_by: 1.05}红色删除的字段黄色修改的字段如scale_by: 1.0→scale_by: 1.05关联执行历史锁定责任人在History页面点击某次版本提交下方会列出“此版本被用于哪些执行任务”。点击任一任务 ID跳转到Execution History可以看到执行时间、执行者系统用户名执行时覆盖的参数如{scale_by: 1.05}输出文件路径及缩略图效果当 QA 提出问题我们只需在 WorkBuddy 中搜索问题图的文件名 → 找到对应的执行记录 → 点击Template Version→ 查看该版本的变更详情 → 确认是哪位同事在哪天修改了scale_by字段 → 直接联系他确认修改原因。整个过程 2 分钟内完成无需翻 Git 日志、无需查聊天记录、无需开会讨论。责任归属清晰问题定位精准。5. 我踩过的坑与必须告诉你的 7 条硬核经验WorkBuddy 是个强大的工具但它不是银弹。在我把它部署到 3 个不同规模的团队个人工作室、12 人创意公司、50 人 AI 应用研发部的过程中踩过不少坑。有些是文档没写的有些是社区教程误导的有些是 ComfyUI 本身机制导致的。我把这些血泪教训浓缩成 7 条硬核经验每一条都配了真实场景和解决方案希望能帮你绕过我走过的弯路。5.1 经验一永远不要在 WorkBuddy 模板里硬编码绝对路径用模型注册代替场景我曾为一个客户定制的 LoRA 模型client_logo_v2.safetensors创建模板直接在 JSON 中写死了路径D:/models/loras/client_logo_v2.safetensors。后来客户换了新电脑路径变成E:/ai/models/loras/client_logo_v2.safetensors模板
阅读完成 · 觉得有帮助？
