简介：一份面向 ComfyUI 使用者的文生图工作流配置文件，聚焦 SDXL 基础模型与 Refiner 精炼阶段的组合应用，适合已掌握 ComfyUI 基本操作、希望深入理解精炼出图流程的爱好者，也可作为初次接触 SDXL 双阶段生成的入门参考。包内仅含 1 个 JSON 文件，约 4KB，可直接导入 ComfyUI 加载；借助节点图与参数记录，读者能清晰查看正向/负向提示词、采样器、模型接入及 Refiner 切换等关键配置，省去手动搭建的工作量。当前已有 138 人学习下载。通过这份工作流，既能快速复现 SDXL 生成再到 Refiner 细化的完整链路，也可以以此为模板调整提示词、步数和精炼时机，观察不同参数对画质的影响；同时，JSON 文件的文本形态也让版本对比与二次修改变得很方便。由于文件体积很小，适合作为学习 ComfyUI 节点编排与 SDXL 精炼机制的高性价比素材，导入后即可开始实验，减少环境探索成本。
1. 为什么我劝你把 SDXL 的 Refiner 环节留到最后：先弄懂再跑通
如果你已经在 ComfyUI 里跑通过 SDXL 文生图，大概率见过工作流里那个叫 Refiner 的节点，也知道有人把它叫「精炼器」。很多人第一反应是：base 模型已经出图了，再塞一个 Refiner 进去多此一举，还多占显存。我第一次跑 ComfyUI 的 SDXL + Refiner 精炼文生图工作流时也是这么想的，直到我拿同一组提示词、同一个种子分别跑了两遍，对比完才发现：Refiner 不是玄学，它对皮肤质感、发丝边缘和暗部噪点的改善肉眼可见，代价只是多了几十秒和 3~4G 显存。
这篇笔记就是围绕这份 ComfyUI/SDXL + Refiner 精炼文生图资源写的。资源本体是 c0064.rar 压缩包，里面是 c0064.json 工作流定义和配套的 c0064 数据文件，导入 ComfyUI 就能看到一张完整的 base + Refiner 串联图。适合两类人：刚把 ComfyUI 装好、想知道 Refiner 节点怎么接的初学者；以及已经在用 SDXL 出图、但对 Refiner 时机和参数设置拿不准的熟手。
2. SDXL 为什么要配 Refiner：base 出结构、refiner 补细节的分工逻辑
2.1 SDXL 的两段式架构：base 负责构图，refiner 负责质感的底层原因
SDXL 本身不是单一模型，而是一组配套模型。官方发布时给了两个权重：base 1.0 和 refiner 1.0。base 模型在 1024×1024 分辨率下的构图能力比 SD 1.5 强一截，但纯靠 base 出的图，放大看时皮肤会有点「塑料感」，头发边缘偶尔有糊成一团的情况。
Refiner 模型解决的正是这个问题。它不是一个独立的文生图模型，而是设计好的第二段精修器——接收 base 的低噪声潜空间特征，在这个基础上继续去噪修正。用工程师的话说，base 负责「全局语义布局」，refiner 负责「局部高频细节」。两者是串联关系，不是并联，也不是二选一。
这也是这份 c0064.json 工作流的核心：它把 base 模型节点和 refiner 模型节点串在同一条链路上，按 denoise 比例切分任务。你在 ComfyUI 里看到的图是这样的：左侧是 base checkpoint 加载器，中间是 KSampler 做第一阶段采样，右侧接 refiner checkpoint 加载器和第二个 KSampler，两个采样器之间通过一个 switch 参数控制切换时机。
2.2 为什么不是所有工作流都要接 refiner：显存模型和场景的判断标准
先说结论：8G 以下显存建议直接跳过 refiner，base 单跑性价比更高；10G 以上显存值得把 refiner 接上。
原因很直接。base 的 UNet 结构在 1024 分辨率下跑一次全流程大约需要 6G 显存（batch size 1，fp16），此时 GPU 已经比较吃紧。再接 refiner 等于要同时把两个 UNet 的权重驻留在显存里，8G 卡很容易在采样中途报 CUDA out of memory。秋叶整合包默认启动参数是低显存模式，但低显存模式只解决权重调度，不解决总量不足。
判断标准我一般看三件事：出图的最终用途（网络发布还是打印）、你对细节的容忍度（人脸特写还是远景全景）、以及显卡型号。如果只是做远景插画和概念图，refiner 带来的提升边际递减；如果是半身人像、产品渲染这类需要放大细看的场景，refiner 那一步值得留。
2.3 工作流里 refiner 的两个核心参数：denoise 和 start/end 节点
c0064.json 里真正需要动手调的只有两个地方：refiner 的 denoise 值，以及两个 KSampler 的节点连接方式。denoise 这个参数很多人理解反了——在 ComfyUI 里，KSampler 的 denoise 不是「从第几步开始精修」，而是「这个采样器实际处理的噪声比例」。
常见做法是 base 阶段的 KSampler 用 denoise=1.0，跑完整去噪；refiner 阶段用 denoise=0.2~0.4，意思是只处理后 20%~40% 的去噪过程，把 base 输出当作已经去噪到 60%~80% 的中间态接着修。这个值和总步数配合理解：总步数 30，refiner 的 denoise=0.3，相当于 base 跑前 21 步，refiner 跑后 9 步。
我在多组生成对比里试过，人像场景 refiner 的 denoise 取 0.25~0.35 效果最稳，低于 0.2 修不出差别，高于 0.4 会出现过修导致的纹理发腻。具体设置后面章节有参数表。
3. 把 c0064.json 跑起来：工作流导入、模型路径与 node 缺失处理
3.1 导入前的文件准备和目录结构
拿到 c0064.rar 先别急着拖进 ComfyUI。解压后你会看到 c0064.json 和 c0064 目录（或文件），我一般在 ComfyUI 安装目录下建立一个专门的项目工作区，把这两个东西放一起，路径上不要带中文和空格。
我的习惯目录结构是这样：
ComfyUI/ ├── models/ │ ├── checkpoints/ # base 和 refiner 模型都放这里 │ └── vae/ ├── user/ │ └── default/ │ └── workflows/ # c0064.json 也可以放这，但放桌面直接拽也行 └── c0064_work/ ├── c0064.json └── c0064/ # 说明文档或其他配套资源逻辑说明：ComfyUI 默认通过拖拽 json 文件来加载工作流，文件放哪个目录其实无所谓，但单独建目录有三个好处：方便备份、方便对比不同版本、避免 json 里的模型路径因为目录迁移而失效。配套的 c0064 目录不要改名，json 里如果引用了相对路径资源，改名会导致加载时找不到文件。
参数说明：checkpoints 目录下需要同时存在 SDXL base 模型（比如 sd_xl_base_1.0.safetensors）和 SDXL refiner 模型（sd_xl_refiner_1.0.safetensors）。秋叶整合包自带的模型管理里可以直接下载这两个，动手能力强也可以从 HuggingFace 拉原版，放在 checkpoints 下即可。
3.2 加载工作流和修复 node 缺失的完整过程
打开 ComfyUI 页面后，直接把 c0064.json 文件拖进浏览器窗口，工作流会自动加载。如果页面没有任何反应，先按 F12 看控制台是否有报错。
AC 端的网络检索结果显示，新手最常见的翻车点是「加载后多个节点是红色的」。红色意味着该节点涉及的插件没有安装。c0064.json 主体依赖的是内置节点（CheckpointLoaderSimple、KSampler、VAEDecode），这些不需要额外装。但如果 json 里有 Custom Node 引用，比如 ComfyUI-Manager 管理的某些自定义节点包，你就得先装依赖。
# 如果你用的是秋叶整合包，先启动 ComfyUI 再打开 Manager # 在 Manager 里点 "Install Missing Custom Nodes" 自动补装 # 如果自动安装失败，手动方式如下 cd ComfyUI/custom_nodes git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack.git cd ComfyUI-Impact-Pack python install.py逻辑说明：Impact-Pack 是最常见的需要手动安装的节点包之一，很多进阶工作流都会引用它做图像分割和细节重绘。但 c0064.json 这个精炼工作流本身不一定用到它，如果你看到的红色节点是内置节点名，那问题大概率不是缺插件，而是模型路径或文件名不匹配。
参数说明：安装完自定义节点后必须重启 ComfyUI，不是刷新页面，是完整退出进程再启动。否则节点包不会加载进运行时。
3.3 模型路径和启动参数的常见匹配问题
加载完工作流后，第一个要检查的是 CheckpointLoaderSimple 节点里选择的模型名。c0064.json 保存时记录的模型路径是写死的，如果解压后的模型文件不在同一路径，节点会显示「Load checkpoint: Not Found」。
# 检查当前模型列表 ls -lh ComfyUI/models/checkpoints/ # 如果没有 base 模型，用秋叶整合包内置的模型下载器 # 或者手动确认文件名是否和 json 里一致逻辑说明：ComfyUI 的模型加载器只会扫描 checkpoints 目录下的一级文件，不会递归子目录，也不会自动匹配同名不同后缀。比如 json 里写的是sd_xl_base_1.0.safetensors，你实际放的是sd_xl_base_1.0_fp16.safetensors，节点照样报错。
参数说明：报错信息里有完整的预期文件名，照着改就行。还有一个坑是 VAE——SDXL 的 base 和 refiner 都没有内置可用的 VAE decoder，工作流里通常会单独引用sdxl_vae.safetensors。c0064.json 里如果只有 VAEDecode 节点加载 VAE，记得把 VAE 文件放到models/vae目录。
4. 精炼生成的关键参数：采样步数、切换时机与 CFG 的配合逻辑
4.1 base 与 refiner 两个 KSampler 各自怎么取值
这是整套工作流出图质量的命门。下面是我基于 c0064.json 默认配置跑了几十组对比之后得到的一组稳妥参数：
| 参数 | base 阶段 KSampler | refiner 阶段 KSampler | 说明 |
|---|---|---|---|
| steps | 30 | 30 | 总步数由 base 决定，refiner 不改步数 |
| denoise | 1.0 | 0.3 | base 全流程去噪，refiner 只处理后段 |
| cfg | 6.5 | 5.0 | refiner 的 cfg 略低于 base 更自然 |
| sampler_name | dpmpp_2m | dpmpp_2m | 换 euler 出图锐利度会变 |
| scheduler | karras | karras | 对 SDXL 是常规稳妥解 |
参数逻辑说明：steps 是总步数，refiner 节点里虽然也填 30，但它不会重跑 30 步，而是根据 denoise 计算出自己要跑的步数。refiner 的 KSampler 实际执行步数 = 总步数 × denoise，填 30 步 + 0.3，实际处理约 9 步。cfg 降低是因为修细节阶段不需要模型对提示词做那么强的服从，稍微给点自由度反而能避免过锐化和纹理假感。
4.2 切换时机的含义：denoise 0.3 到底切在哪一步
「切换时机」这个概念容易让人误解成某个具体的步数，实际上 ComfyUI 是通过 denoise 比例来隐式表达切换点的。工作流在运行时，base 阶段的 KSampler 先完成自己的采样循环，输出一个潜空间张量，传给 refiner 阶段的 KSampler。refiner 阶段的 KSampler 拿到这个潜空间后，会把它当作已经去噪到 70% 的状态，自己再从 70% 往 100% 推。
这里有一个很容易翻车的地方：两个 KSampler 之间如果接了 latent 重采样节点或者 VAE 编解码节点，潜空间的数据结构会被改变，refiner 会报形状不匹配的错误。c0064.json 里两个 KSampler 是直接用 latent 连线接的，中间不要插入任何 VAE 操作，除非你明确知道自己在做什么。
我一般将 denoise 设为 0.3 作为起步，然后观察出图。如果觉得修得不够狠，往 0.4 调；如果觉得皮肤纹理太重看起来像油画，回落到 0.25。每次只动 0.05 的幅度，一次调到位容易因为其他变量干扰而误判。
4.3 分辨率与 latent 尺寸的匹配：SDXL 的基础分辨率边界
SDXL 的基础分辨率是 1024×1024，但 ComfyUI 里的 Empty Latent Image 节点可以自由填宽高。c0064.json 默认是 1024×1024，这个值不建议随意改成 512×512——SDXL 本身在低分辨率下生成效果反而不如 SD 1.5。
如果你确实需要竖图或者横图，调整宽高时保持像素总量在 1000 万上下。例如竖图 832×1216，横图 1344×768，这两种是 SDXL 官方推荐的备选分辨率。明显偏离这些值会导致双重问题：一是构图变差，二是 refiner 阶段因为潜空间尺寸不匹配报错或生成重影。
显存不够时优先降 batch size 而不是降分辨率。分辨率 768×768 时显存占用能省三分之一左右，细节损失在接受范围内；但如果把 batch size 提到 2，显存占用直接翻倍，8G 卡大概率直接黑。
5. 精炼工作流避坑：我踩过的五个常见翻车现场、原因与解法
5.1 现象：refiner 阶段采样极慢，甚至卡到像死机
原因：refiner 的 UNet 权重在低显存模式下没有被及时换出，base 和 refiner 同时驻留显存导致频繁换页，实际算力全浪费在显存搬运上。
解决：给 ComfyUI 启动参数加--reserve-vram 2，为显存管理预留 2G 余量，减少换页频率。这个方法在秋叶整合包的启动器里可以直接填参数，命令行启动则在 bat 文件里加在python main.py后面。如果显存低于 8G，直接把这个参数调到 3，配合四连并行参数--lowvram，能稳一些但要接受速度下降。
5.2 现象：生成的图和单独跑 base 一模一样，refiner 完全没生效
原因：denoise 值填了 0，或者 latent 链路接错——refiner KSampler 输入的不是 base 的潜空间输出，而是重新初始化了一个空 latent。工作流从 json 导入后连线可能错位，拖拽时节点自动对齐覆盖了原连线。
解决：检查 refiner 的 KSampler 输入 latent 是否来自 base KSampler 的输出。正确链路是base KSampler(latent) → refiner KSampler(latent) → VAEDecode。如果中间出现了EmptyLatentImage的输出端，那就是接错了，断开重连。其次是确认 denoise 大于 0.2，0.1 以下基本看不出变化。
5.3 现象：报错Shape mismatch或 tensor 维度对不上
原因：refiner 的潜空间输入尺寸和模型期望的尺寸不一致。SDXL 是 4 通道潜空间，如果你在工作流中间插入了别的 VAE 或放大节点，通道数被改成 3 或尺寸被缩放，refiner 一跑就崩。
解决：严格按 c0064.json 原始连接不动。如果已经动过，把 json 重新拖进页面还原。需要放大图像的话，放在 refiner 完成之后的 VAE Decode 之后再加 upscale 节点，不要在潜空间阶段做放大。
5.4 现象：皮肤满脸噪点、纹理像砂纸
原因：refiner 的 cfg 设置过高，模型在精修阶段过度服从提示词中的细节词汇，把噪点也当成特征加强。另一个原因是 base 阶段采样器选错，部分采样器在低 step 下收敛不稳定，给 refiner 喂了一个带明显噪声底的潜空间。
解决：把 refiner 阶段的 cfg 从默认 7 左右降到 5.0 以下，如果还不行就换dpmpp_2m_sde并把 base 跑满 40 步。这一步解决的噪声问题从根源上是 base 出图质量不够，refiner 不是万能的，修不了大面积的构图崩坏。
5.5 现象：VAE Decode 报错，提示找不到 VAE 文件
原因：c0064.json 工作流如果单独引用了sdxl_vae.safetensors，而你的models/vae目录下没有这个文件，解码环节直接断层。SDXL 的 checkpoint 文件里其实打包了 VAE，但很多调用方式不会自动回退到内置 VAE。
解决：去模型站下载sdxl_vae.safetensors放进models/vae，然后在 ComfyUI 里点 VAE Loader 节点重新选择一次。如果你确定自己的 checkpoint 文件完整，也可以不加载独立 VAE，而是把 VAEDecode 的 vae 输入接到 CheckpointLoaderSimple 的 VAE 输出上，省一个文件。
6. 验证 Refiner 是否真在干活：一张图跑两遍的对比测试法
我每周至少会做一次「对照实验」来确认工作流没有退化。方法是在 c0064.json 基础上拉出一个新分支工作流，把 refiner 相关的 KSampler 和模型加载节点禁用（快捷键 Ctrl+M 设为静音），保持提示词、种子、步数完全一致，分别生成一张图。
关键一步是固定 seed。两个工作流都用同一个 seed 值，比如 6666，这样 base 阶段的输出潜空间是相同的，两图的差异纯粹来自 refiner 的修正。对比时重点看三个位置：眼睛高光和瞳孔纹路、发丝边缘的锯齿、皮肤毛孔的颗粒感。如果这两张图放大后毫无差别，说明你的 refiner 虽然连着线但实际没在工作流里起作用，优先排查 denoise。
我还会配合用一行脚本验证 refiner 是否被真实调用，省去肉眼判断：
# 在 ComfyUI 的 cmd 窗口里观察输出日志 # 正常跑精炼工作流时，日志会记录两次采样循环 # 第一次采样（base） # 100%|██████████| 21/21 [00:32<00:00, 1.53s/it] # 第二次采样（refiner） # 100%|██████████| 9/9 [00:14<00:00, 1.55s/it]逻辑说明：日志里出现两次独立的进度条，第一次对应 base 的步数，第二次对应 refiner 的步数。如果只看到一条进度条就结束，说明 latent 链路没有接到 refiner 上。还可以检查第二次采样的步数——总步数 30、denoise 0.3，第二次应该显示 9/9，如果显示 30/30，说明 denoise 参数被重置成了 1.0。
参数说明：日志里每步耗时（1.5s/it 左右）在 8G 显存机器上属于正常值。如果第二次采样步数是 0/it 且时间极短，说明 refiner 节点虽然存在但没有实际执行计算，这时候要回第 5.2 节查连线和 denoise 设置。从那以后我每次跑完精炼流程都会顺手瞄一眼日志输出确认两次采样都执行了，确认无误再收藏出图批次，避免攒了一堆「伪精炼」图最后交不了差。希望这个对比测试和参数习惯能帮到你，省下你拿真金白银的算力去交学费的时间。
本文还有配套的精品资源，点击获取
