ComfyUI工作流怎么分享

你把工作流导出丢给同事，对方一打开满屏红框：节点不认识、模型找不到、图片输出没了。这不是他手笨，是分享时依赖信息没带上。这篇按分享前、分享中、对方导入后三段给清单，说清哪些要打包、哪些要写进说明、报错时按什么顺序查。

你把工作流导出丢给同事，对方一打开满屏红框：节点不认识、模型找不到、图片输出没了。这不是他手笨，是分享时依赖信息没带上。ComfyUI 的工作流文件本身只记录节点连接关系，不记录插件和权重文件，所以光给一个 JSON，对方大概率跑不起来。

下面按分享前、分享中、对方导入后三段给清单，说清哪些要打包、哪些要写进说明、报错时按什么顺序查。整体思路是：让接收方少装没用的东西，也少猜你本机到底放了什么。

分享前先自己过一遍：这份工作流到底依赖了什么

导出之前先把自己这份工作流当成别人的东西看一遍。很多人分享翻车，不是导出步骤错了，是自己都没数清楚用过哪些插件、读过哪些文件。先盘点，再动手导。

• 把工作流里用到的自定义节点列出来，区分哪些是社区插件、哪些是内置节点，前者必须写进说明
• 把加载类节点引用的模型文件名逐个抄下来，包括大模型、VAE、LoRA、ControlNet 这类附属文件
• 确认有没有用到本地绝对路径或自己机器上的临时文件，这类引用换台机器就断
• 清一遍没用到的孤儿节点再导出，避免对方装了一堆其实不跑的插件

盘点时顺手做一个动作：把画布上所有加载器节点挨个点开，看文件名和它所在的实际目录。文件名和目录层级都记下来，后面写清单直接用。这一步花五分钟，能省掉对方半小时的来回问。

导出时带什么：JSON、依赖清单、示例输入三样

分享包最少要有三样东西：工作流本体、依赖清单、一份能对照的输出参考。少任何一样，对方都要多问你一轮。下面这张表把三样东西的内容和常见漏项列清楚。

依赖清单建议写成纯文本或表格，别塞在聊天记录里。对方装插件时对着清单一条条勾，装完再导入工作流，出错时也能快速排除「是不是少装了某个」。清单里插件名写全称，别用自己习惯的缩写。

如果工作流读外部素材，比如参考图、遮罩、音频，把素材一起打进去，或者写清素材规格让对方自备。素材的尺寸、格式、命名规则都值得写一句，这类细节最容易在换机器后变成静默失败——不报错，但输出不对。

对方导入后按这个顺序排查，别一上来就重装

对方打开后报红是常态，关键是排查顺序。一上来就重装 ComfyUI 或重下模型，通常是最慢的路。按下面的步骤走，每一步都有明确的判断依据。

1. 看红框节点的名字能在插件管理器里搜到的，说明是插件没装；搜不到的，可能是节点已改名或作者已弃坑。先分类再处理。
2. 看加载节点的报错多半是文件名对不上，去模型目录核对文件名和子目录层级，大小写也算。清单里抄的名字和实际文件必须逐字一致。
3. 确认模型目录搜索路径文件放对目录但没被扫到的情况很常见，检查配置里有没有把这个子目录加进搜索范围。
4. 比对分享者的截图以上都不对，就问分享者要一份他本机跑通时的界面截图，比对节点版本和连线状态，比盲猜省事。

排查时有个顺序原则：先解决「节点认不认识」，再解决「文件找不找得到」，最后才看「跑出来对不对」。三层的报错信息长得不一样，混在一起看只会更乱。如果你在选配套的推理服务或中转方案，可以到 /sites 看当时的可用选项和延迟数据，别只凭别人一句「我这边能跑」就下单。

什么情况下这套办法不适用

上面这套清单解决的是「依赖信息没带全」这一类问题。但有几类情况，光给清单也救不了，提前说清楚比事后扯皮好。

• 工作流依赖特定插件版本、甚至依赖某个还没合并的 PR，仅给清单也未必装得上，得连版本号一起给
• 对方用的是完全不同的前端或云端环境，节点生态不通用，只能让他换到你用的那套再谈分享
• 工作流里嵌了大量本地微调权重，权重本身不宜外发，这时只能给结构、不给权重，能否跑通取决于对方有没有同源模型

还有一种容易被忽略的情况：你分享的是「能跑通的结果」，不是「可复现的流程」。如果中间有手工替换文件、临时改参数这类操作没写进说明，对方按 JSON 跑出来一定不一样。这类口头步骤要补进依赖清单末尾。

判断标准很简单：把工作流交给一个只有干净环境的人，他能不能只靠你给的三样东西跑出近似结果。跑不出，就说明还有隐藏依赖没交代。如果涉及具体插件的兼容范围和当前可用版本，到 /tools/speed-test 核对当时的数字，比记别人说的结论靠谱。