comfyui 工作流教程

你可能已经装好 ComfyUI，也拿到别人给的 JSON 工作流，但一打开就是满屏连线和红框节点，不知道从哪儿动手。或者照着视频拖了几个节点，出图却报错、出怪图，也说不清是哪一步接错了。这篇按新手的实际卡点走一遍：从打开一份工作流开始认结构，到搭一条最小可跑链路，再讲几个高频节点的作用和对不上时怎么查。不保证你一次就顺手，但至少知道每一步在干什么。

你可能已经装好 ComfyUI，也拿到别人给的 JSON 工作流，但一打开就是满屏连线和红框节点，不知道从哪儿动手。或者照着视频拖了几个节点，出图却报错、出怪图，也说不清是哪一步接错了。这篇按新手的实际卡点走一遍：从打开一份工作流开始认结构，到搭一条最小可跑链路，再讲几个高频节点的作用和对不上时怎么查。不保证你一次就顺手，但至少知道每一步在干什么。

先说个前提：下面讲的是「能跑通一条链路」的思路，不是「一次调出好看图」的方法。出图质量跟模型、提示词、采样设置都有关，那部分不在这篇的范围里。如果你连 ComfyUI 界面都没打开过，先去把基础的安装和启动走完，回来再看这一篇。

先读懂一份现成工作流，别急着从零搭

新人最容易走的弯路，是打开空画布就开始拖节点。更省事的顺序是：找一份别人分享的、能出图的工作流 JSON，导入进来先跑通一次，再在这个基础上改。跑通意味着你有了一个「已知能干活的参照物」，后面改坏了还能退回去对比。空画布从零搭，等于同时面对「节点怎么连」和「我搭得对不对」两个问题，出错了很难定位。

导入之后别急着一层层研究，先做一件事：把整张图按三类功能分区看。第一类是模型加载类节点，它们通常没有上游输入，是链路的起点；第二类是条件与采样类节点，负责把提示词和模型拼成出图过程；第三类是输出保存类节点，是链路的终点。你先找到保存节点，顺着线往回捋，就能看出主线是哪一条，旁边那些孤立的、没连到保存节点的分支，暂时可以不管。

• 模型加载类：一般没有输入接口，只有输出，它决定这条链路用哪个底模；
• 条件与采样类：有多个输入，接收模型、提示词和尺寸，输出给下一环；
• 输出保存类：通常只有一个输入，接到它上面的那条线就是主干；
• 红框或红字节点：多数是模型文件没放对目录或文件名对不上，先去补文件再谈连线；
• 孤立的节点分支：暂时折叠或忽略，等主线跑通再回头看它们的作用。

搭一条最小可跑的链路：从加载到出图

如果你非要从零搭一条链路，那就搭最小的那条，别一上来就加一堆花哨节点。一条能出图的基本顺序是：加载底模，把模型接到文本编码节点，正向提示词和负向提示词分别编码，采样器接收模型和编码结果，再根据潜空间尺寸算出结果，解码成图像，最后保存。这里面每一步的输出类型都对得上，链路才成立。

1. 先放保存节点从输出端往回接，先摆好保存节点，这样你知道链路要往哪儿走，不容易漏掉最后一环。
2. 往回收解码节点解码节点的作用是把潜空间结果变成能看的图，它接保存节点，说明它的输出就是最终图像。
3. 再接采样节点采样节点接解码节点，它的输入来自模型和文本编码，这里要确认模型和提示词都接到了它身上。
4. 往回补编码和加载文本编码节点接收提示词和模型，加载节点提供模型，把这条线补齐，链路就闭环了。
5. 连不上时看接口类型鼠标停在节点接口上会显示类型，类型对不上一般连不上，不要硬拉线，先确认两个节点的类型是否匹配。

搭好之后第一次跑，把尺寸和步数都放在保守区间，先把流程走通。走通了再去调质量参数。别一上来就追求出图效果，流程没通的时候调参数只会让你更乱。各种参数的具体取值范围，这篇不写死，你可以到 提示与调参术语速查（/ai-dict/category/tips） 对照概念理解，实际数字以站内页面当时的说明为准。

这张表不是让你背，是给你排查时一个方向。比如报错信息里点名某个节点，你就先对照它的类别，看看是文件问题、连线问题还是参数问题，别一上来就重装软件。

几个高频节点先认脸，改动优先动它们

工作流里节点很多，但你日常真正会动的就那么几类。加载类节点决定用哪个底模或附加模型，换模型基本就是换这里。文本编码节点分正面和负面两个方向，接反了会出现「怎么调都没效果」的情况，这是新手很常见的坑。采样类节点管出图过程和随机性，你改了它却没反应，先别怀疑节点坏了，很可能你改的那条分支根本没连到保存节点上。

• 改风格、换模型：优先动加载类节点，而不是去改采样参数；
• 改提示词没效果：检查正负两路编码是不是接反或接错；
• 改采样没反应：顺着线确认这条链路最终连到了保存节点；
• 图能出但结构怪：先看解码节点上游是不是接到了别的分支；
• 节点太多看不清：把与当前链路无关的分支临时折叠，排查范围能小一半。

如果节点名字或概念看着陌生，不要靠猜。先去 AI 术语词典（/ai-dict） 把名词的意思对一遍，再回来改。术语没搞清就凭感觉调，很容易把一条好链路改坏，而且你还说不清是哪一步开始坏的。

跑不通时的排查顺序

报错不可怕，可怕的是东改一下西改一下。下面这个顺序是经过验证的排查路径：先查文件，再查连线，然后查依赖，最后查硬件。这个顺序的道理是，越靠前的问题越常见、越好确认，越靠后的越费时间。按顺序来，不会在错误方向上浪费精力。

第一查文件：模型、VAE、附加网络有没有放到对应目录，文件名有没有差一个大小写或后缀。第二查连线：报错点名哪个节点，就从那个节点的输入往回看，缺输入通常是上游断了。第三查依赖：导入别人工作流后提示缺节点，多半是缺了对应的自定义节点包，先把包补齐再跑。

第四查硬件与显存：跑到一半崩、进度卡死，可能是尺寸或批量开太大，先把数值降下来跑一次，排除环境原因，再怀疑工作流本身。如果你在排查过程中拿不准是不是自己机器的问题，可以用站内的 速度测试（/tools/speed-test） 先跑一次，看看基础环境是否正常，别把环境问题当成工作流问题来回改。

排查的顺序，比排查的耐心更重要：先排除最常见的，再去啃最麻烦的。

这套顺序也不是万能的。如果你用的是别人魔改过的工作流，节点来源不明、依赖包版本混乱，那么按上面四步可能都排不掉，这时候更实际的做法是回到一份干净的、来源清楚的工作流重新开始，而不是继续在烂摊子里打补丁。哪种工作流更值得信任、分享来源怎么判断，可以到 中转站与工具导航（/sites） 看看站内整理的入口和说明。