用过本地AI画图的同学，应该都了解ComfyUI，这是一款开源的可视化界面兼推理引擎，用节点和连线把出图流程搭成一张图。
用久了，多半会遇到两种情况：网上下载的工作流导入后满屏红框，提示缺节点、缺模型；或者上个月出过一张满意的图，现在怎么也调不回来。
问题出在哪，怎样让一个工作流换台电脑、隔一个月还能跑出同样的结果？YouTube频道CLI Stack最近有一期视频，对照ComfyUI的开源仓库，从安装、模型放置、图的执行、排错一路讲到API自动化，接下来我们顺着它拆开看看。视频作者的出发点也说在了前面：目标不是保证出一张完美的图，而是搭出一个能复现、能排错的工作流。
据ComfyUI背后的公司Comfy Org在2026年4月24日的官方博客披露，ComfyUI完成3000万美元融资，估值5亿美元，累计融资4700万美元，当时有400万用户、6万多个社区节点、每天超过15万次下载。用户和扩展越多，“别人的工作流在我这里跑不起来”的问题就越常见，这期视频处理的正是这个问题。
“工作流描述的是流程，不打包模型”
ComfyUI的核心是一张图。节点执行操作，插槽传递带类型的数值，连线表达依赖关系。普通出图工具把所有决定藏在一个提示词框后面，ComfyUI把从输入到输出的每一个阶段都摆了出来。提示词、检查点（checkpoint）、文本编码器、采样器、潜空间解码器和保存操作，都可以单独查看和替换。检查点就是模型权重文件本身，潜空间解码器负责把模型内部的压缩表示还原成像素。这样一来，你可以隔离某个阶段、复用一段子图、对比不同设置，分享时交出的也是完整的工作流，而不只是一张压平的成品图。
仓库的内容远不止前端界面。它包含节点定义、图的执行、模型识别与加载、设备和显存管理、服务器接口、示例、测试和配置。视频研究时锁定的提交版本是8f04fd6，这个快照里有一千多个受版本管理的文件，项目仍在活跃开发，没有归档。作者提醒，上游分支会变，照着具体命令操作之前，先和当前文档、发布说明核对一遍。
最需要分清的一点是：ComfyUI是引擎和界面，模型权重是单独的大文件。 仓库里只有模型文件夹的占位目录和示例配置，没有现成的全套扩散模型。存储空间、许可证和硬件都要提前规划，这些资产都在Git之外。
仓库自带的默认工作流是一个JSON文件，记录节点、连线、分组和标识符，示例里有10个节点、10条连线。正因为它只是一份描述，所以便于传播，却不包含节点要用的模型权重。核心代码定义了加载检查点、文本编码、采样、VAE解码、保存图片这些常用操作，项目还自带更多节点，扩展也能注册新操作。VAE是变分自编码器，在这里承担解码工作。工作流能不能跑通，取决于的不只是图文件本身。
图的执行顺序也有讲究。一个节点何时运行，取决于它需要的输入是否已经就绪，跟它在画布上摆在左边还是右边无关。引擎按图的结构安排任务，能复用的结果就复用，不会因为下游改了一个小参数就把上游全部重跑一遍。
以生图为例，可以把这张图看成一条数据流水线：加载器提供模型组件，文本编码器把提示词变成条件信息，空白潜空间或由图片转来的潜空间提供起点，采样器反复迭代更新它，解码器生成像素，保存节点写出最终文件。
视频强调，这只是概念路径，不保证每个模型都用同样的组件。新架构可能改变条件信息、潜空间格式、采样器或解码器的要求。作者的建议是，从针对具体模型家族、有人持续维护的模板起步，再顺着每条连线、读每个节点的输入来理解这张图。
一个常见的新手陷阱，是把上一代模型的图拿来，以为只要改一下检查点文件名就行。 兼容性还牵涉文本编码器、VAE、采样器设置、分辨率和自定义节点。正确做法是查对应模型的文档，每次只验证一处改动。
ComfyUI的局部重新执行也在这里派上用场：上游某个值变了，依赖它的下游必须重算，无关的缓存结果可以直接复用。迭代因此更省时间，而图本身仍然记录着改了什么、为什么改。
项目的适用范围也早已超出静态图片，文档里有图像、视频、音频、三维内容和文本的工作流，支持情况还在变化。视频建议把它们当作不同的工作流家族对待，模型要求、性能开销和节点顺序都有明显差别，实际使用中不能互换。
Python版本以README为准，3.10只是下限
安装环节的第一个细节就容易看错。README写的是Python 3.13支持良好，如果某些自定义节点的依赖出问题，建议改用3.12。项目元数据声明的是Python 3.10及以上，但这个宽泛的下限不等于README推荐的配置。
流程是：克隆仓库，建一个隔离的Python环境，先装与操作系统和加速硬件匹配的PyTorch，再按requirements文件装ComfyUI的依赖。README为英伟达（NVIDIA）、AMD和英特尔（Intel）分别给了说明，不要把CUDA的安装命令搬到别的后端上用。
程序入口是main.py。加上help参数运行，会列出当前版本支持的启动选项，但不会真的启动服务器。克隆完先跑这一步很有用，既确认Python能解析这个程序，也能看到这份代码具体暴露了哪些选项。
本地启动默认绑定回环地址，端口是8188，被别的服务占用时换一个即可。listen选项控制绑定地址，视频特别提醒：把服务暴露到本机以外是一个安全决定，不是顺手的便利。 交互式生成服务器能读写文件、消耗大量算力，在不受信任的网络上不要绑定到所有网卡，开放远程访问前先想清楚认证和防火墙。
模型放置方面，检查点放在models/checkpoints，VAE放在models/vae，除非配置另有指定。仓库里还有文本编码器、视觉编码器、音频编码器等文件夹。文件名和配套文件以模型发布方的说明为准。扩展名眼熟，不代表文件安全或者可以互换，要核对来源、许可证、预期架构和需要的配套文件。大文件不要随手提交进代码仓库，也不要下载到你不希望服务器扫描的位置。
如果模型放在另一块硬盘上，README提供了额外模型路径的配置文件，几套安装可以共用一个模型库，不必把几个GB的文件复制多份。加载器找不到文件时，先检查YAML语法、类别映射和最终拼出来的路径，再去怀疑别的地方。
报错时，先看终端，不要乱改图里的参数依赖和模型就位后，启动ComfyUI，打开本地界面，用自带的默认图或有人维护的模板跑第一次。启动失败时保留终端输出，它通常比浏览器更直接地指出是缺Python包、后端不兼容，还是模型找不到。
默认图适合用来熟悉界面，不是万能配方。点运行之前，读每个节点的标题，检查必填输入：确认加载器指向的是你想要的检查点，提示词确实连进了编码器，潜空间和条件信息的连线都接到了采样器上。
把提示词加入队列就开始执行。服务器先校验提交的结构，再安排任务，并在界面上报告进度。校验失败和运行时的模型错误是两回事，去看服务器响应和控制台，而不是随手改图里的数值。
跑完以后，查看保存的图片，图片里带有工作流元数据的话也一并查看。视频指出，输出只是可复现性的一部分，还要记下工作流、种子、模型文件、自定义节点版本和相关的运行选项。少了这些，单凭一张图，以后未必能重现同样的结果。
采样器是最显眼的调节面板，却不是唯一的变量来源。模型选择、提示词编码、潜空间尺寸、去噪强度、种子、调度器和引导强度都会影响结果。每次只改一两个变量，把有意义的版本存下来，别靠记忆。分辨率同时影响构图和显存占用，潜空间越大，通常需要的算力和显存越多，有些模型家族还有偏好的尺寸或宽高比。先用一个确定能跑通的模板、以适中尺寸出图，确认硬件扛得住再往上加。
ComfyUI提供设备选择、精度、显存行为、预览、注意力后端和缓存等选项。作者说，这些不是通用的加速开关，一个参数可能让这台机器变快，却让另一台机器出错。所以要先建立一个能跑通的基线，读帮助文本，再用自己的实际任务做对比测试。
CPU选项适合诊断，或者给没有受支持加速硬件的机器用，但生成速度会慢得多。只要依赖和模型支持，纯CPU运行仍能验证图的结构是否有效，但它的耗时不能代表GPU部署的情况。显存相关的选项也一样，ComfyUI有低显存和高显存模式、动态内存控制和卸载选项，取舍取决于显存、系统内存、模型大小和存储速度。遇到显存不足，就缩小任务规模，或有条理地调整受支持的显存设置。
排错的第一步是分清故障出在哪一层：
动手改之前，先把确切的报错信息记下来。
缺节点的情况最常见，也最容易处理过头。自定义节点能扩展这张图，代价是新增的依赖和信任成本。这份核心代码只带了一个示例节点和一个通过websocket保存图片的工具，大部分社区扩展需要单独安装。视频建议，看过扩展的代码和发布历史再装，需要复现的项目要把扩展版本固定下来。
工作流提示未知节点时，先确定缺的到底是哪一种节点类型，再去工作流文档里找对应扩展，读它的安装说明，确认它支持你的ComfyUI版本。不要为了消掉一个缺节点的警告，装一大堆无关的扩展。
一个实用的诊断办法是临时禁用所有自定义节点，启动帮助里就有这个选项。如果只跑核心功能时表现不同，问题可能出在某个扩展上。作者也提醒，这是隔离测试，不是长期方案，生产环境里的工作流如果确实依赖扩展节点，还得把扩展装回来。
HTTP请求成功不代表出图成功，截图也不等于可复现ComfyUI对外提供HTTP API，包括提交提示词、查看队列、查询历史和中断任务的接口，仓库里还附了基础的API和websocket示例，可以用来自动化工作流、追踪进度。视频认为，这些示例比自己编一套命令行更可靠，用它们搭客户端时，要把输入的图、被接收的提示词和完成后的输出分开管理。
做自动化时，先通过官方支持的导出流程，把界面里的工作流转换成API格式的提示词，再提交到本地的提示词接口。每次运行生成的JSON、响应标识符和输出文件要对应保存。队列接口用来查看排队中和运行中的任务，历史接口返回已完成任务的结果，websocket消息可以传递进度和图片事件。
HTTP请求成功，只说明服务器接收了任务，不说明服务器上生成成功。 所以错误处理要覆盖超时、服务器重启和提示词失败这几种情况。仓库把API和执行拆在不同模块，包括一个提示词执行器和若干图工具。普通使用不需要改这些内部代码，但知道边界在哪，读报错堆栈时会更有方向：校验、调度、节点执行和模型加载，可能分别在不同阶段出错。
团队协作时，视频建议在图旁边放一份小清单，写明锁定的ComfyUI版本、扩展的提交版本、模型标识和安装说明。密钥不要写进工作流文件，远程API地址也按敏感信息处理，图里可能带着你不想公开的路径或元数据。
离线使用是明确支持的模式。根据帮助输出，offline选项会给前端套上严格的内容策略，并禁用合作方节点，适合需要内置功能完全留在本地的场景，但启用前要确认你的部署具体需要什么。项目说明核心功能在本地运行，除非你主动要求，否则不会下载任何东西，可选集成和合作方功能另有各自的行为。处理敏感工作时，逐项检查选项，关掉不需要的功能，并在实际运行环境里监控外发网络流量。
可复现的工作流，要保存的东西比一张截图或一段提示词多得多：图的JSON、模型校验和或确切的来源标识、节点版本、种子、尺寸、采样参数和软件版本。有变动就记下来。这份记录，把一次性的结果变成一个可以回头比较的实验。
公开分享工作流之前，删掉和本机绑定的路径和私人信息，写明需要哪些模型和扩展，条件允许的话在干净环境里测一遍，再说明预期的输入和输出。视频的说法是，观众要猜的越少，越有可能真正复现这个流程，而不只是欣赏一张截图。
对于第一个项目，作者给了一个循环：从有人维护的、针对具体模型的模板开始，确认所需资产都在，跑一次最小的有效生成；然后顺着图理一遍，改一个参数，另存一个带名字的副本。这个有纪律的循环，比盲目搭一张复杂的图学得更快。
排错也有对应的流程：保留失败的提示词和完整的控制台堆栈，把图缩减到最小的失败路径，核对版本和模型家族，必要时禁用自定义节点测试，再一个个把组件加回来。这样能找到原因，而不是在配置上层层叠加改动。
视频的结论是，ComfyUI把生成式工作变成一张看得见的图，图和模型资产分开存放，同时支持交互运行和API驱动。灵活性带来的代价是，版本和依赖必须写清楚。当你需要查看、复用和自动化一个多阶段的创作流程时，ComfyUI尤其有用，但它替代不了模型文档、硬件规划和细致的依赖管理。作者的说法是，把这张图既当作可执行的计划，也当作产出结果的那些选择的记录。
