2026-08-13 痛点归档

创作者/开发者反复迭代工作流时，每次微调（换LoRA、改CFG、加节点）都产生新版本。现有方式是手动保存 workflow_v2_FINAL.json，或用 Git 提交 JSON 文件。但 Git 的文本 diff 无法语义化显示'CFG从7改到8'这种关键变更，也无法将工作流版本与其产出图片自动关联。当一个工作流引用了特定版本的模型、LoRA、自定义节点，Manager 更新一个节点就可能导致工作流崩溃，而文件级版本控制完全无法追踪是哪个节点版本出了问题。

团队平均每周3-6小时花在'数字考古'上（numonic.ai 数据），个人用户每次找回正确配置约15-30分钟

1) Git——不满意：文本 diff 无法区分语义变更，无法关联产出图片；2) comfy-pack (BentoML)——不满意：只解决打包部署，不解决版本管理；3) ComfyUI Manager——不满意：只管节点安装更新，不管工作流版本；4) Numonic——新兴产品但尚未普及

ComfyUI 官方在推进 Nodes v3 试图分离内部函数和公共 API；BentoML 开源了 comfy-pack 用于打包工作流为 cpack 文件；Numonic 正在构建 provenance-native 的基础设施。但都是早期方案，用户仍无成熟工具可用。

1) 手动文件命名（workflow_v2_FINAL.json）；2) Git 提交 JSON（但 diff 无意义）；3) 不管理（靠记忆和撤销按钮）。团队约25%的时间花在'数字考古'——找文件、重建丢失的配置、回忆哪个设置产出了甲方满意的结果。

工作流开发者从社区下载工作流，打开后大量节点显示红色（missing/import failed）。用 Manager 安装后仍然失败——因为节点 A 要求 torch==2.4.1，节点 B 要求 torch>=2.4.2，pip 依赖冲突。更严重的是：ComfyUI 核心更新后破坏了自定义节点的 API，回退核心版本又破坏其他节点。用户被迫清空 custom_nodes 文件夹，一个一个重新添加来定位问题节点。

每次下载新工作流平均30-60分钟排查依赖问题；严重冲突时2-4小时重建环境

1) ComfyUI Manager 的 'Install Missing Nodes'——不满意：经常装了仍无法 import；2) RunComfy（云端）——不满意：需要付费、数据上云、依赖网络；3) 多 venv/容器隔离——不满意：技术门槛高，普通用户不会操作

ComfyUI 官方推出 Nodes v3 计划，建立 curated API 和节点公共接口来防止更新破坏。但这需要节点作者配合迁移，短期内无法解决。RunComfy 提供云端自动配置但需付费。

1) 二分法逐个禁用/启用节点排查（耗时30分钟到数小时）；2) RunComfy 云端重建环境（需要付费且数据上云）；3) 放弃复杂工作流只用默认节点；4) 维护多个 ComfyUI 实例（每个绑定不同节点集）

电商设计师需要批量生成产品图（不同角度、不同风格、不同文案），但 ComfyUI 原生的批量功能非常原始：要么在 Empty Latent Image 设 batch_size（但无法每张图用不同提示词），要么手动改参数一个个排队。批量并发会 OOM。当需要测试不同 LoRA 强度组合时（如0.3/0.5/0.7/1.0），需要手动创建 XYZ 网格或反复改参数重跑，缺乏统一的批量任务管理界面。

每天30-60分钟用于手动批量操作和参数调整（电商设计师场景）

1) ComfyUI 原生 batch_size——不满意：无法每张图用不同参数；2) Comflowy Batch——不满意：限10次，功能弱；3) 无限画布类工具（如API中转平台）——不满意：依赖云端、按量收费、数据隐私问题；4) 自己写脚本——不满意：技术门槛高

社区已有多个工具：1) OutputList_Combiner 节点支持多提示词批量出图+XYZ网格；2) FL_PromptMulti 节点支持多提示词并行；3) 多个B站UP主分享了批量出图工作流教程。但都是碎片化的节点/工作流，缺少统一的管理界面。

1) 用第三方批量管理软件（B站 'Comfyui批量管理软件V4.2'）；2) 手动改参数反复 Queue；3) 自己写脚本调 API 批量提交；4) 用 Comflowy 的 Batch 功能（限制最多10次）；5) 用无限画布类工具批量生成

创作者积攒了大量 LoRA（画风、角色、效果），但文件命名混乱（随机字符串、缩写），文件夹里一堆 .safetensors 文件无法预览效果。使用时不知道哪个 LoRA 适合自己的需求，需要逐个加载测试。多个 LoRA 叠加时（LoRA堆），不知道每个的触发词，也不知道哪个组合效果好。Civitai 下载的 LoRA 元数据需要手动同步。

每周1-3小时整理和测试 LoRA；每次使用新 LoRA 约10-15分钟测试效果

1) willmiao/ComfyUI-Lora-Manager——基本满意但缺少批量对比评测功能；2) Civitai 网站——不满意：需要离开 ComfyUI 切换；3) 手动文件夹管理——不满意：无预览、无元数据；4) 星月之鸢的 LoRA 管理器——偏向训练而非使用管理

willmiao/ComfyUI-Lora-Manager 是目前最成熟的方案，支持：Civitai 集成自动获取预览图/触发词/模型描述、LoRA Recipes（保存喜欢的 LoRA 组合）、可视化画廊浏览、拖拽插入工作流、版本选择。但仍有改进空间：批量对比评测、自动推荐相似 LoRA、效果评分系统等。

1) willmiao/ComfyUI-Lora-Manager 自定义节点（从 Civitai 自动拉取预览图和元数据）；2) 手动用文件夹分类；3) 用 XYZ 网格逐个测试 LoRA 效果；4) 在 Civitai 网站上逐个查看信息；5) 用笔记软件记录触发词

创作者在 12-16GB 显存的显卡上跑视频生成（MiniMax H3、WAN2.2 等），采样完成后 VAE 解码阶段 OOM 崩溃——前面几分钟的采样全部白费。根本原因：1) Dynamic VRAM 模式下，采样后的 DiT 权重不释放，VAE 解码时无法获得足够显存；2) tiled retry 对某些 VAE 是 no-op（重复执行同样的解码）；3) 长时间运行后内存泄漏（模型缓存不清理）。多次运行后性能严重退化（首次138秒→后续543秒）。

每次 OOM 崩溃浪费3-10分钟（采样已完成但解码失败）；内存泄漏导致每天需重启2-3次，每次5分钟

1) ComfyUI Dynamic VRAM——不满意：引入新问题，与部分节点冲突；2) 手动 UnloadModel——不满意：繁琐、需要提前计算；3) 重启 ComfyUI——不满意：浪费时间；4) --reserve-vram / --lowvram——不满意：效果有限

ComfyUI 官方推出了 Dynamic VRAM 优化框架，但本身引入了新问题（与 TensorRT 节点冲突、某些场景下反而更慢）。社区有人写了 Workflow Manager 工具自动清理内存（B站视频介绍）。PR #15456 正在修复 VAE 解码 OOM 问题。

1) 手动加 UnloadModel 节点在工作流中释放模型（繁琐且不精确）；2) --disable-dynamic-vram 禁用新功能（放弃优化）；3) --reserve-vram 预留显存（效果有限）；4) 定期重启 ComfyUI（浪费时间）；5) 购买更大显存显卡（成本高）；6) 使用云端 GPU（按小时付费）

工作流开发者做好了工作流，想把它变成一个面向非技术用户（设计师、甲方、电商运营）的产品。痛点链：1) 需要把节点参数暴露为简单 UI（App Mode 做了但功能有限）；2) 需要打包整个环境（自定义节点+模型+Python依赖）让其他人能运行——但依赖冲突导致在别人机器上无法运行；3) 需要部署为 API 服务——冷启动60-120秒、WebSocket 不稳定（~1/5 调用失败）、无安全隔离、无法水平扩展。

从工作流到可交付 API 产品平均需要1-2周工程化工作（含环境配置、API封装、部署、测试）

1) Runflow——成熟但偏企业级，价格门槛高；2) ComfyDeploy——开发者友好但仍在发展中；3) comfy-pack——开源但只解决打包，不解决部署；4) ComfyUI App Mode——免费但功能基础，不适合真正的产品化

商业生态已较成熟：Runflow（一键部署+质量评分+成本归因）、ComfyDeploy（类似 Vercel for ComfyUI）、Baseten（build_commands 功能）、BentoML（comfy-pack 开源工具）、ComfyUI 官方 App Mode。但多数面向企业，个人开发者/小团队门槛仍高。

1) ComfyUI App Mode（简化 UI）；2) Runflow/ComfyDeploy/Baseten 等第三方部署平台（收费）；3) comfy-pack 打包为 cpack 文件；4) EasyAI 等一键封装平台（B站生态，收费）；5) 自己写 API wrapper（技术门槛高）

LoRA 训练者/工作流开发者训练完 LoRA 后，需要系统化评测效果：在不同提示词、不同强度（0.3-1.0）、不同基础模型下的表现。目前只能手动用 XY 网格逐个测试，或者用 lora_tester 这样的脚本工具。没有自动化的质量评分系统来决定 LoRA 是否达到发布标准。对于需要管理大量 LoRA 的团队，缺乏 CI/CD 式的质量门禁。

每个新 LoRA 约30-60分钟手动测试评估；批量评测（如10个 LoRA × 5个提示词 × 4个强度）需要2-4小时

1) lora_tester——基本满意但需要技术能力配置；2) LoRAPlotNode——满意但功能有限；3) Runflow Sentinel——企业级付费方案

lora_tester 提供了批量测试+画廊对比的基础方案；LoRAPlotNode 支持多 LoRA 对比。但都缺少自动化质量评分和发布门禁。Runflow 的 Sentinel 评分系统是商业方案。

1) purzbeats/lora_tester（批量测试+画廊对比，但需要 Claude Code 配合）；2) LoRAPlotNode（10个 LoRA 对比网格）；3) Weird Wonderful AI Art 的 LoRA Test Compare Workflow；4) 手动 XY 网格测试

创作者精心调好工作流，第一次运行出图完美。第二次用不同 seed 运行，风格/质量突然变差。排查后发现是某些自定义节点（如 AutomaticCFG）在执行过程中修改了模型状态但运行结束后不恢复，导致下一次运行时修改叠加。即使没有这类 bug，ComfyUI 的 noise 生成方式（CPU vs GPU）也导致与 A1111 结果不同，跨平台/跨硬件的复现性无法保证。批量出图时，batch 内不同图片的角色/风格不一致也是常见问题。

每次遇到不一致问题约15-30分钟排查；批量出图时发现不一致需要全部重跑

1) Global Seed 节点——部分解决随机性控制但不解决状态污染；2) 重启 ComfyUI——浪费时间；3) 避免使用问题节点——限制了功能

社区发现并报告了部分节点的状态污染 bug（如 AutomaticCFG #45）；easy globalSeed 节点提供了跨运行的一致性控制。但根本性的'节点状态不隔离'问题未解决。

1) 每次运行后重启 ComfyUI（浪费时间）；2) 固定 seed 并避免使用有问题的节点；3) 用 Global Seed 节点控制随机性；4) 在 batch 中用 LatentBatchSeedBehavior 控制种子行为

工作流开发者在调试时，只修改了一个节点的参数（如调整 LoRA 强度），但 ComfyUI 的缓存策略不智能——要么缓存太多导致内存不足，要么缓存失效导致所有节点重新计算。用户反映更新后变慢，排查发现是缓存配置变化导致 GPU 回退到 CPU 计算。复杂的视频工作流中，一次完整运行可能需要几分钟，改一个参数重跑全部令人崩溃。

每次调试工作流因缓存失效浪费30-60秒等待不必要的重算；一天调试多次累计浪费30-60分钟

1) ComfyUI 原生缓存参数——不满意：需要手动调参，默认配置经常不合理；2) TeaCache——不满意：需要额外安装配置，仅适用于特定模型；3) TorchCompile——不满意：编译本身需要时间，首次运行更慢

ComfyUI 官方提供了多种缓存策略选项（cache-classic, cache-lru, cache-none）；社区有 TeaCache 加速节点、TorchCompileSpeed 节点等优化方案。但需要用户自己理解缓存原理并手动配置。

1) 手动调 --cache-classic / --cache-lru N / --cache-none 参数；2) 用 KSampler Advanced 分步执行只重跑变化的部分；3) 用 TeaCache/TorchCompile 加速；4) 降低分辨率先快速预览再高清出图

ComfyUI 工作流 JSON 可包含任意 Python 代码执行路径。安全研究员发现 KJNodes 中存在可被攻击者控制的工作流输入导致的任意代码执行漏洞，且有证据表明已在野外被利用。对于部署 ComfyUI 为服务的团队，这意味着零安全隔离——1000+ 个暴露的 ComfyUI 实例可能被攻击。官方 Nodes v3 计划将节点执行从主进程中分离以实现依赖隔离和安全沙箱。

未提及

1) 容器化部署——不满意：增加运维复杂度；2) 第三方安全平台——不满意：成本高；3) 不接受外部输入——不满意：限制了功能

官方 Nodes v3 计划改进安全模型；kijai 已收到安全报告并修复。但生态层面的安全隔离仍未实现。

1) 私密报告渠道报告漏洞；2) 在容器中运行 ComfyUI 实现隔离；3) 不接受外部工作流输入；4) 使用第三方部署平台（Runflow 等提供隔离）