任何一个人，都要必须养成自学的习惯，即使是今天在学校的学生，也要养成自学的习惯，因为迟早总要离开学校的！自学，就是一种独立学习，独立思考的能力。行路，还是要靠行路人自己。—— 华罗庚

当工作流开始“看得见”：为什么 ComfyUI 会让很多创作者一用就回不去

在 AI 内容生成这条路上，很多工具都在努力做一件事：让事情变简单。

而 ComfyUI 的气质有点不一样。它当然也希望你能顺利开始，但它更在意的，似乎不是把一切都藏起来，而是把那些原本埋在黑箱里的过程，一步步摆到你面前。模型怎么接，参数怎么走，节点怎么串，哪一段被重跑，哪一段被复用，整个工作流像电路图一样摊开，既不躲闪，也不含糊。

这也是它最吸引人的地方。

Comfy-Org/ComfyUI 在仓库 description 里把自己定义为：The most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface.
而 README 里的第一句则更进一步，把它称作：The most powerful and modular AI engine for content creation.

这两句放在一起，几乎已经把 ComfyUI 的气质说透了：它不是一个只负责“出图”的小工具，而是一套围绕内容创作搭起来的、可视化但又足够底层、模块化而且能接入生产流程的 AI 引擎。

项目地址：https://github.com/Comfy-Org/ComfyUI

它不是在帮你“点一下生成”，而是在把创作过程变成一张可编排的图

ComfyUI 最核心的特征，就是它的 node graph interface。

README 里写得非常明确：它提供的是一个 visual node graph，用来构建和复用 image、video、audio、3D、text workflows，而且 without code。这件事听上去像是“可视化编排”，但真正上手过这类系统的人都知道，区别并不只是界面长得像流程图而已。

当一个工作流被节点化之后，很多原本在传统 UI 里被压扁、被隐藏、被一次性打包的步骤，就重新恢复了层次：

  • 输入从哪里来
  • 模型在哪一层接入
  • 条件控制怎么流动
  • 哪些步骤可以复用
  • 哪些节点只在局部变化时重跑
  • 最终结果究竟是怎么一步步长出来的

ComfyUI 的魅力，恰恰在这里。它不是把你挡在系统外面，而是请你坐到驾驶席上。

README 里那句“为要求控制力的视觉专业人士而生”，一点都不夸张

README 对目标用户有一个很鲜明的描述：ComfyUI 是为 visual professionals who demand control over every model, every parameter, and every output 准备的。

这句话的重点不是“专业人士”四个字，而是后面那三个 every：

  • every model
  • every parameter
  • every output

很多工具的思路，是尽量把复杂性收起来，让用户少做决定；ComfyUI 的思路则更像是：如果你真的在意过程、在意选择、在意结果是如何生成的，那么我把控制权交还给你。

这也是为什么它的“模块化”不是一个空词。它不是简单支持几个插件，而是让工作流本身天然具备可拆、可接、可复用、可局部替换的结构。

它不是只会玩图像，README 直接把版图铺到了图像、视频、音频、3D 和文本

很多人提起 ComfyUI，第一反应可能还是图像生成。但 README 很清楚地展示了它的覆盖范围早就不只这一块。

在 Features 里，它列出的工作流类型包括：

  • image
  • video
  • audio
  • 3D
  • text

而且不是笼统提一嘴，而是分别列出了原生支持的代表性模型和方向。

图像生成

README 提到的代表模型包括：

  • Stable Diffusion 1.5
  • SDXL
  • SD3.5
  • Flux.1
  • Flux.2
  • Qwen Image
  • Z-Image
  • Hunyuan Image 2.1
  • HiDream
  • Lumina Image 2.0
  • Chroma

图像编辑

包括：

  • Flux Kontext
  • Flux.2 Klein
  • Qwen Image Edit
  • HiDream E1.1 and O1
  • OmniGen2
  • Boogu
  • JoyImage Edit
  • MageFlow Edit
  • LongCat Image

视频生成

包括：

  • Wan 2.1 and 2.2
  • LTX-Video 2 and 2.3
  • HunyuanVideo 1.5
  • Kandinsky 5 Video
  • CogVideoX
  • Cosmos Predict2
  • Bernini-R
  • SCAIL 2

音视频生成

  • MiniMax H3
  • LTX-AV

音频生成

  • ACE-Step 1.5
  • Stable Audio 3

3D 与视觉

  • Hunyuan3D 2.1
  • TripoSplat
  • SeedVR2
  • SUPIR
  • Depth Anything 3
  • MoGe
  • SAM 3 and 3.1
  • RT-DETRv4
  • BiRefNet

文本生成

  • Gemma 3 and 4
  • Qwen3
  • Qwen3.5
  • Qwen3-VL

从这份列表能明显看出来，ComfyUI 并不是围着某一个单模态模型打补丁，而是在不断把更广的生成与理解能力纳入同一套节点式工作流体系里。

它既能接开源前沿模型，也能通过 API 节点连到闭源模型

README 里有两句话特别值得注意：

  • ComfyUI natively supports the latest open-source state of the art models
  • API nodes provide access to the best closed source models

这两句一起看，很有意思。

它一方面强调了对最新开源模型的原生支持，另一方面也没有把自己封闭在纯本地开源世界里，而是通过 API nodes 去接入闭源模型，例如 README 中提到的 Nano Banana、Seedance、Hunyuan3D 等。

这意味着 ComfyUI 并不把“本地”和“外部能力”看成对立关系。对它来说，更重要的是：这些能力能不能进入统一的节点化工作流里，被同样地编排、连接和复用。

它不是只面向单机玩票，还明确强调了 API 与生产流水线接入

README 里有一句非常关键的话：

It integrates seamlessly into production pipelines with our API endpoints.

这句话的分量不小，因为它说明 ComfyUI 不只是一个桌面创作工具。它还提供：

  • local API
  • API endpoints
  • App Mode
  • reusable subgraphs
  • workflow templates

这几项放在一起看，意味着它的角色可以从“自己在本地拖节点出结果”，一路延伸到“把复杂工作流包装成更简单的交付界面”，甚至进一步嵌入生产管线。

尤其是 README 提到：

  • 最复杂的 workflows 也可以通过 App Mode 暴露成简单 UI
  • 本地 API 可用于把 workflows 集成进应用

这就是 ComfyUI 很特别的一点：它既允许专家深入到底层，又允许把成果封装给其他人使用。

运行效率这件事，它不是靠一句“我们很快”糊过去

在执行层面，README 给了不少非常具体的特性：

  • asynchronous queueing
  • partial graph re-execution
  • smart VRAM and RAM management
  • model offloading
  • support for quantized models

这些点拼起来，能看出它对“图工作流”的理解不是停留在 UI 层，而是贯穿到执行策略。

其中尤其值得一提的是：

partial graph re-execution

README 和 Notes 都强调了一个核心机制：
只有变化的那部分图会重新执行。

它写得很直白：

  • 只有那些拥有正确输入并且能产出输出的图部分会被执行
  • 如果同一个图提交两次，只有第一次会完整执行
  • 之后只会重跑发生变化的部分

这是 ComfyUI 使用体验里非常关键的一环。因为节点式工作流一旦复杂起来，如果每次都整图重跑，效率会很难看；而局部重执行则让试验、微调、替换后半段流程都变得更自然。

“保存的不只是结果，而是整个生成过程”——这件事特别像 ComfyUI 的性格

README 提到，ComfyUI 支持：

  • 保存和加载 workflows 为 JSON
  • 从受支持的生成媒体中恢复完整 workflow 和 seeds

而 Notes 里又补了一句很经典的话：

把生成出的 png 拖回网页，或者加载它，就能拿回完整 workflow 和所用 seeds。

这真的是很 ComfyUI 的设计。

很多生成工具保存的是“结果图”；ComfyUI 显然更在意“这张图是怎么来的”。在它的世界里，结果并不是故事的终点，生成路径本身也是资产。你可以回放、复用、修改、再分叉，这种可追溯性和可再加工性，本身就是工作流系统的灵魂。

安装方式很多，但它很清楚地把不同用户分层了

ComfyUI 的 README 在安装这块写得非常完整，而且明显考虑到了不同层次用户的起点。

它把 Get Started 分成了：

  • Local
  • Cloud

Local 下面又分成：

  • Desktop Application
  • Windows Portable Package
  • Manual Install

Cloud 则是：

  • Comfy Cloud

这种分层很清楚。

Desktop Application

README 明说：这是 the easiest way to get started，并且适用于 Windows 与 macOS。
后面的 Installing 部分还再次强调：对于新用户来说，desktop app 是 the easiest and best way。

Windows Portable

README 说得很诚实：它可以拿到最新 commits，而且完全 portable；但同样也写明了，不推荐普通用户，普通用户应优先使用 desktop app。

Manual Install

支持所有操作系统和 GPU 类型，包括：

  • NVIDIA
  • AMD
  • Intel
  • Apple Silicon
  • Ascend

这部分显然是留给更愿意自己掌控环境、也更熟悉依赖关系的人。

Cloud

还有官方付费的 Comfy Cloud，README 说明这是给那些本地硬件扛不住的人准备的版本。

整个分层看下来，你会发现它没有假装所有人都该走同一条路，而是按不同需求给出了不同入口。

它对硬件生态的覆盖，宽得很惊人

README 在 Manual Install 这部分，很认真地把不同硬件平台的安装路径拆开写了：

  • AMD GPUs（Linux）
  • AMD GPUs（实验性：Windows 和 Linux，限 RDNA 3 / 3.5 / 4）
  • Intel GPUs（Windows 和 Linux）
  • NVIDIA
  • Apple Mac silicon
  • Ascend NPUs
  • Cambricon MLUs
  • Iluvatar Corex

这份列表本身就很说明问题。ComfyUI 并没有只把自己做成“默认你有一张 NVIDIA 卡”的工具，而是尽量把更多硬件路线纳入支持范围。

README 甚至在最开始的 Manual Install 段落里直接说，它支持 all operating systems and GPU types，后面再逐项给出安装说明。这种硬件覆盖广度，是它作为“内容创作引擎”而不只是“单一模型前端”的一个重要支撑。

安装说明写得很工程，也很实用

README 给出的安装过程不是一句带过，而是具体到不同平台的 pip 安装命令。

例如：

使用 comfy-cli

1
2
pip install comfy-cli
comfy install

安装依赖

1
pip install -r requirements.txt

运行

1
python main.py

针对不同 GPU 路线，它也给出了各自的 PyTorch 安装方式。比如 NVIDIA 使用：

1
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130

而 Intel XPU、AMD ROCm 也分别有对应命令。

你能明显感觉到，这份 README 不是只想“展示一下项目多厉害”，而是真的希望不同环境的人能跑起来。

它甚至连“如果你已经在用别的 UI，怎么共享模型”都考虑到了

README 里专门有一节：

How do I share models between another UI and ComfyUI?

答案是使用配置文件 extra_model_paths.yaml 来设置模型搜索路径。README 说明，在 standalone Windows build 中能找到这个文件，把示例文件重命名后编辑即可。

这件事非常贴近真实使用场景。因为很多用户并不是从零开始接触 AI 生成工具，他们可能已经有另一套 UI 和模型目录。ComfyUI 在这里给出的思路，不是“重新来过”，而是让模型位置可配置、可共享。

ComfyUI-Manager 的存在，让“扩展生态”变得更顺手

README 还介绍了 ComfyUI-Manager，它是一个扩展，用来方便地安装、更新和管理 custom nodes。

配置方式包括：

  1. 安装 manager 依赖：
1
pip install -r manager_requirements.txt
  1. 运行 ComfyUI 时带上参数：
1
python main.py --enable-manager

此外还支持：

  • --enable-manager
  • --enable-manager-legacy-ui
  • --disable-manager-ui

这说明 ComfyUI 的扩展能力并不是口头上的“你可以自定义”，而是已经有专门的管理机制去处理 custom nodes 的安装、更新和管理。

custom nodes 不是点缀，而是这个系统开放性的关键部分

Features 列表里有一条很简短，但很重要：

Extend ComfyUI with custom nodes

这句话虽然只有一行，却非常关键。因为当一个节点式系统允许大量自定义节点存在时，它就不再只是官方能力的容器，而是一个可以不断生长的创作平台。

你可以把 ComfyUI 想成一块主板，而 custom nodes 则像是不断插进来的新模块。它们让工作流不止是“现成组件拼接”，还能随着社区和个人需求不断扩展。

App Mode 很像给复杂工作流套上一层“对外友好外壳”

README 里提到：

The most sophisticated workflows can be exposed through a simple UI thanks to App Mode.

这句话很有意思，因为它刚好说中了节点工作流最常见的一个矛盾：

  • 对创作者本人来说，复杂图很强大
  • 但对普通使用者来说，复杂图也可能太复杂

App Mode 的意义就在这里。它让那些高度定制、结构复杂的底层流程，能够以更简单的界面形式对外暴露。这不是削弱工作流，而是给它套上一层更易用的入口。

从产品思路上看，ComfyUI 并不满足于“高手玩得转”，它也在考虑“高手做好的东西，能不能更轻松地给别人用”。

Release Process 写得很透明，甚至把“master 可能很不稳定”都摆在桌面上

README 的 Release Process 部分非常详细，也非常坦率。

它说明 ComfyUI 采用 weekly release cycle，目标通常是周一，但会因为模型发布或者较大代码变更而调整。同时，它还解释了三个互相关联的仓库：

  1. ComfyUI Core
  2. Comfy Desktop
  3. ComfyUI Frontend

其中最重要的几个点包括：

  • Core 大约每两周发布一个新的 major stable version
  • 从 v0.4.0 开始，patch versions 用于回移修复
  • minor versions 用于 master branch 的发布
  • 某些情况下 master branch 上也可能使用 patch 版本
  • stable release tags 之外的 commits 可能非常不稳定，并可能破坏大量 custom nodes
  • Desktop 基于最新 stable core 构建
  • Frontend 大约每 2+ 周合并进 core 一次

这种透明度很难得。它不是一句“我们持续更新中”带过，而是把核心仓库、桌面版、前端版之间的关系都讲清楚了，也明确提醒用户 master 分支可能不稳。

它连快捷键都写成了一整张表，这恰恰说明它不是玩具界面

README 有一整张 Shortcuts 表，列出了大量操作，例如：

  • Ctrl + Enter：排队执行当前图
  • Ctrl + Shift + Enter：把当前图插到队列最前
  • Ctrl + Alt + Enter：取消当前生成
  • Ctrl + S：保存工作流
  • Ctrl + O：加载工作流
  • Ctrl + B：Bypass 节点
  • Q：切换队列显示
  • H：切换历史显示
  • R：刷新图
  • F：显示/隐藏菜单
  • .：适配视图到当前选择
  • 双击鼠标左键：打开节点快速搜索面板

这类快捷键表的存在，本身就说明 ComfyUI 不是一个“点点按钮看结果”的轻量玩具，而是一个希望用户长期停留、频繁编辑、熟练操作的工作台。

Notes 里的很多细节，特别像创作系统的“老经验总结”

README 后面的 Notes 部分非常有味道，读起来像一堆被真实使用反复验证过的经验。

比如：

  • 只有图中输出完整且输入正确的部分会执行
  • 只有变化部分会重跑
  • 拖入已生成 PNG 可恢复完整 workflow 和 seeds
  • 可在 prompt 里用 () 调节强调权重
  • 可用 {day|night} 这类动态 prompts
  • 动态 prompts 支持 C 风格注释
  • textual inversion 放在 models/embeddings 目录，并通过 embedding:embedding_filename.pt 使用

这些内容虽然零碎，但恰恰很能说明 ComfyUI 的“生产型气质”。它关注的不只是模型有没有接上，还包括提示词书写、流程复用、提示动态性、结果可回溯等日常工作细节。

它甚至给出了高质量预览和 TLS/SSL 的使用方法

在 README 后段，还能看到一些非常实际的运维与体验细节。

高质量预览

如果想显示高质量 previews，可以使用：

1
--preview-method auto

README 还说明默认安装包含的是快速但低分辨率的 latent preview；如果要启用更高质量的预览，可以配合 TAESD。

TLS/SSL

README 也给出了启用 TLS/SSL 的方法，包括：

  • 使用 openssl 生成自签名证书和 key
  • 启动时通过 --tls-keyfile 与 --tls-certfile 指定

这说明 ComfyUI 并不把自己局限在“本地玩玩”的层面，它也考虑到了更正式的访问方式和部署需求。

前端拆仓之后，它依旧把协作关系写得明明白白

README 还提到，自 2024 年 8 月 15 日起，前端已经迁移到独立仓库 ComfyUI Frontend。同时说明：

  • 新前端已经是默认前端
  • 主仓库中的前端大约每两周更新一次
  • 独立前端仓库则提供 daily releases
  • 可以通过 --front-end-version 指定使用最新版本或某个具体版本

示例包括：

1
--front-end-version Comfy-Org/ComfyUI_frontend@latest

以及：

1
--front-end-version Comfy-Org/ComfyUI_frontend@1.2.2

这类能力对于想测试最新前端、或想固定某个版本的人来说，非常实用。也能看出 ComfyUI 在主仓、前端仓、桌面版之间的演进已经有了一套相对清晰的节奏。

从 README 的整体气质看，ComfyUI 更像一个创作操作系统，而不是单一功能软件

如果只看功能名录，ComfyUI 已经足够强大；但它真正令人印象深刻的，其实是这些能力如何被组织起来。

它有：

  • 图形化节点工作流
  • 本地与云端入口
  • 桌面版、便携版、手动安装
  • 图像、视频、音频、3D、文本的多类型工作流
  • 原生模型支持与 API 节点扩展
  • 局部重执行与资源管理
  • JSON 工作流保存与媒体反向恢复
  • App Mode
  • local API 与生产管线接入
  • custom nodes 与 Manager
  • 前端独立演进机制
  • 大量平台与硬件支持

这些东西加在一起，你会发现它已经不只是“一个 diffusion GUI”。更像一张足够灵活、足够开放、也足够工程化的创作底座。

它之所以让人上头，可能正因为它没有替你简化掉“理解系统”的乐趣

ComfyUI 最大的魅力，可能并不是“它能支持多少模型”，也不只是“它有多少节点”。

而是它愿意把创作过程本身交还给你。

你可以搭图、拆图、复用图；可以只改最后一段、只重跑需要变化的部分；可以把工作流保存成 JSON，也可以从一张图反向拿回生成路径；可以在本地离线跑，也可以通过 API 和 App Mode 把成果变成别人的入口；可以只做个人创作，也可以把它嵌进更长的生产管线。

这套系统的气质非常鲜明：它不怕复杂，但它努力让复杂变得有结构。

而这，恰恰是很多真正做内容、做流程、做批量生产的人，最后会对它产生依赖的原因。

因为一旦你开始习惯“工作流是看得见的”，很多原来只能凭运气、凭记忆、凭截图保存的创作过程，就忽然有了形状。

ComfyUI 做的，正是这件事：
把 AI 创作从一次次生成，慢慢变成一套可以编排、复用、追溯和继续扩展的流程语言。