最近在群里帮人排查工作流发现一个很有意思的现象很多人对ComfyUI里那个绿油油的、写着“Conditioning”的节点理解得很浅觉得它就是个“输入提示词的地方”。但实际去追问正面提示词和负面提示词为什么要分开接、为什么同一个提示词在不同的checkpoint下效果差异很大、为什么有些人可以用一句“a cute cat”就出图而你写了一大段英文却完全跑偏——这些问题追到最后全都落在Keyword节点也就是CLIPTextEncode这类文本编码节点身上。这篇文章我想系统拆一下这个节点。不是简单说“你连上就能用”而是把它内部到底做了什么、哪些参数会影响出图、怎么组织提示词才能稳定出图、遇到问题该怎么查一次性讲透。无论你刚接触ComfyUI还是已经玩了一段时间但一直对提示词管理比较随意这篇都值得花十分钟看完。1. Keyword节点到底是什么为什么工作流里离不开它1.1 模型看不懂文字Keyword节点是“翻译官”先来搞清楚一个最底层的问题为什么AI画图需要Keyword节点原因很简单——Stable Diffusion这类模型是纯数字系统它内部处理的全是张量Tensor也就是多维数组。你手写的英文提示词、中文提示词、甚至emoji模型本身根本不认识。要让模型理解你的意图必须有一层“翻译机制”把自然语言转换成模型能理解的数值信号。这个转换分两步第一步是把字符串拆成token词元也就是把句子切成模型词表里能对应的最小单位第二步是把每个token变成一个向量这个向量带着语义信息。Keyword节点在ComfyUI里干的就是这件事。我用一个生活化的类比帮你理解你把一个菜谱交给一个只懂法语的大厨你中文说得再清楚也没用大厨听不懂。你需要一个翻译官把你的话翻译成法语的烹饪术语大厨才能动手。Keyword节点就是这个翻译官它把中文/英文提示词翻译成“Stable Diffusion语”——也就是一组数学向量后续的UNet和采样器拿到这组向量才知道该往哪个方向去噪生成图像。在ComfyUI里这个节点最常见的名字叫CLIPTextEncode界面很简单一个text输入、一个clip输入、一个conditioning输出。很多新手觉得它简单但它恰恰是整个流程里最值得花心思去理解的一环因为所有关于“画什么”的信息都从这里进入模型。1.2 它在节点图中的位置一切条件控制的入口ComfyUI是节点式流程典型的Text-to-Image工作流长这样checkpoint加载器 → CLIPTextEncode正面 → KSampler → VAEDecode → 保存图像。其中CLIPTextEncode承担着所有文本条件的编码工作。但你如果只把它当成“一个放提示词的框”会漏掉很多细节。实际上ComfyUI里有好几个节点都带“Conditioning”输入输出比如ConditioningConcat、ConditioningZeroOut、ConditioningSetArea等等。Keyword节点是这条“条件链路”的起点后面接谁、怎么接决定了提示词是以什么方式影响扩散过程的。举个例子当你同时使用ControlNet和文本提示词时ControlNet输出的是ExtraConditioning它和文本的Conditioning在采样器里是并列关系不是替代关系。也就是说文本条件仍然全程参与生成ControlNet只是额外加了空间结构约束。如果你把Keyword节点删了哪怕ControlNet接得再完整出图也会非常飘忽因为模型完全失去了语义引导。所以我的结论是Keyword节点不是“可有可无的入口”而是整个扩散模型的语义锚点。你后续玩什么图生图、局部重绘、风格迁移凡是涉及文本的都绕不开它。2. 核心原理解析一段提示词是如何变成模型信号的2.1 分词、映射、编码三个不可见的关键步骤那Keyword节点接收到你输入的文本之后内部是怎么处理的主要经历三个步骤第一步是分词Tokenization。模型有一个固定的词表比如SD1.5用的CLIP词表大约有49408个token。文本会被切成若干个token每个token对应一个数字ID。常见情况是一个单词是一个token但有些罕见词会被切成多个token数字也可能被合并。这就是为什么同一个单词在不同写法下效果不同。第二步是向量化映射。每个token ID都会去查找嵌入层embedding layer取出一个对应的向量。这个向量的维度取决于CLIP模型的配置SD1.5用的是768维SDXL用的是1280维。可以理解为每个词在“语义空间”里有一个固定坐标。第三步是通过CLIP的Transformer层做上下文编码。这里是最关键的一步模型不是单独理解每个词而是结合上文的顺序和关系生成一组带上下文信息的向量序列。也就是说“a cat on the mat”和“a mat on the cat”虽然用了同样的词但经过编码后的向量是完全不同的因为位置信息和词间关系都被编码进去了。理解这三步有什么用非常有帮助。它能帮你解释“为什么提示词顺序影响出图”“为什么有些词会被忽略”“为什么中文提示词效果差”——前两个问题都和tokenization以及上下文编码相关第三个问题则和词表覆盖范围强相关。2.2 一个被忽略的参数最大Token限制SD1.5的CLIP模型一次最多处理77个tokenSDXL有两个文本编码器其中一个也是77个token的限制实际处理的是77×2的长度。这意味着什么你一次性输入的提示词如果超过77个token后面超出的部分会被直接截断完全不参与生成。我见过不少人疯狂堆砌提示词写了两三百个token的“咒语”以为越长越精细结果后半段根本没被模型看到等于白写。这也就是为什么很多人觉得“提示词越长效果越差”——不是因为长文本不好而是因为你的后半段压根没被处理。那怎么利用这77个token我的经验是把最重要的内容往前放前面30个token放主体中间30个放风格和细节最后17个放环境或氛围。不要把一个细节反复用不同词描述浪费token。如果你的需求确实超过77个token可以考虑使用SDXL或者用ConditioningConcat把多段文本拼接起来不同分段的语义可以叠加效果比重写一大段要好很多。2.3 权重语法ComfyUI是怎么解析的Keyword节点还支持一种权重语法用来微调某个词在生成过程中的影响力。最常见的做法是写成(keyword:1.2)意思是把“keyword”这个token的权重提升到1.2倍。ComfyUI的解析逻辑其实发生在进入CLIP之前——节点内部先把文本里的括号语法剥出来解析成对应token的缩放系数然后再送进编码器。这里有不少新手容易踩坑。第一权重数值不是越大越好超过1.5容易造成过拟合式的“画崩”比如画面出现大面积伪影、色彩溢出第二小括号和中括号的语义不同(keyword)是微幅增强[keyword]通常是降低权重第三如果你在中文输入法状态下打了全角括号“keyword:1.2”很多版本不会被正确解析权重直接失效。我个人比较推荐的做法是核心主体词用1.1到1.3的权重细节修饰词不要加权重环境词可以适当减重。这个经验是在大量出图后总结出来的——权重本质上是影响attention的曝光度太强的权重会导致模型过度关注某个词反而忽略其他描述。3. 实操指南从零到一搭建一套可复用的提示词管理流程3.1 最基础的三个节点串联先保证能出图我们先从最小可用流程开始。假设你已经装好了ComfyUI并能正常加载一个checkpoint模型。搭建一个能出图的流程只需要三个核心节点第一步添加“Load Checkpoint”节点选择你下载好的模型文件比如SD1.5或SDXL的ckpt/safetensors。这个节点会输出MODEL、CLIP、VAE三路信号其中CLIP就是要接给Keyword节点的。第二步添加两个“CLIPTextEncode”节点。一个用于正面提示词一个用于负面提示词。把Load Checkpoint输出的CLIP分别接到两个节点的clip输入端口。第三步添加“KSampler”节点。把正面的CLIPTextEncode输出接到positive负面的CLIPTextEncode输出接到negative再把Load Checkpoint的MODEL接过去。设置好种子、步数、CFG点击运行就能出图。很多新手在这里会忽略一个细节——KSampler下方的“denoise”参数。在纯文生图流程里它通常保持1.0但如果你之前做了图生图denoise被调低了哪怕你换了完全不同的提示词生成结果也会带着原图的影子。这在排查“为什么提示词改了没效果”的时候是第一优先检查项。3.2 正面和负面两个CLIPTextEncode的分工与协作新手最容易犯的误区是把太多负面描述写进负面提示词比如“no dog, no cat, no tree, no car”。负面提示词的本质不是“排除法”而是提供“不希望出现的语义方向”。写太多具体实体的负面会让模型在去噪过程中反复修正方向浪费采样步数还可能引入伪影。我的经验是负面提示词优先写质量类词汇比如“lowres, bad anatomy, bad hands, extra fingers, blurry”这类常见问题描述如果某个具体物体反复出现且你确实不想要再加排除词。正面提示词则按“主体→细节→风格→环境”的结构组织。另外一个容易被忽略的细节如果你的负面提示词留空CLIPTextEncode不是不编码而是编码一个空字符串向量这个空向量本身也有方向性对出图是有影响的。所以不要以为“不填就完全没作用”。负面提示词尽量保持稳定一套方便对比实验。3.3 一套可抄作业的工作流模板速查表下面这个表格是我日常用的文生图工作流模板适合SD1.5和SDXL所有节点都是ComfyUI自带能力不需要额外插件节点名称输入来源关键参数输出去向Load Checkpoint无模型选择MODEL → KSamplerCLIP → CLIPTextEncodeVAE → VAEDecodeCLIPTextEncode (正面)clip来自Load Checkpointtext手写正面提示词CONDITIONING → KSampler positiveCLIPTextEncode (负面)clip来自Load Checkpointtext手写负面提示词CONDITIONING → KSampler negativeEmpty Latent Image无宽高、批次数LATENT → KSampler latent_imageKSamplermodel、positive、negative、latent种子、步数、CFG、采样器名、调度器、denoiseLATENT → VAEDecodeVAEDecodesamples来自KSamplervae来自Load Checkpoint无IMAGE → Save ImageSave Imageimages来自VAEDecode文件名前缀输出图像用这个模板你可以稳定复现绝大多数提示词效果。后续加Lora、ControlNet也都是在这个基础上增加分支而不是推翻重来。4. 进阶玩法动态提示词、多段拼接与自动批量4.1 用动态语法实现随机与组合出图单张出图只是基础实际项目里我们经常需要批量探索画风或内容。ComfyUI有一个非常有用的文本语法动态提示词Dynamic Prompts通过花括号实现随机选择比如写“{cat, dog, rabbit} on a {beach, mountain, city street}”每次运行会从花括号里随机各取一个词组合。这个功能不需要任何额外插件ComfyUI的默认文本处理就支持花括号语法。你在CLIPTextEncode的text输入框里直接写就行。我经常用它做风格抽卡固定主体描述不变把风格词放在花括号里一次跑三四张图能看到不同风格落在同一主体上的效果。配合“Latent Image”节点里的batch_size参数一次可以生成多张随机组合图。但用了动态提示词后有一个问题你没法保证随机出来的组合都是合理的。比如“a cat on a mountain”可能合理“a dog on a city street”也合理但“a rabbit on the sun”就会画得很奇怪。所以我建议动态范围只放在风格、光线、材质这类不影响物理常识的维度上主体和环境尽量固定否则筛选成本会很高。4.2 提示词分段让画面不同区域各取所需另一个进阶玩法是用多个CLIPTextEncode节点分别描述画面不同区域的内容然后用ConditioningSetArea等区域控制节点把它们组合起来。这在多角色构图、多物体互动时特别有用。原理也很直白每个CLIPTextEncode输出一个条件你通过区域设置把条件绑定到图像的不同坐标区间KSampler在去噪时会根据位置取用对应的文本语义。你可以先用“a red car”的提示词控制左下角区域再用“a blue motorcycle”控制右上角区域两张画面在同一张图中共同生成互相影响的程度由区域边界和重叠参数控制。不过说实话这个玩法对新手不太友好需要你对latent图像的尺寸坐标有概念。我建议先把最简单的分段拼接ConditioningConcat玩明白把两段提示词用Concat节点拼接起来让它们按顺序共同影响整个画面。这适合描述复杂构图第一段写主体第二段写背景和光线合成后语义完整度比重写一段长提示词高很多。4.3 Keyword节点与Lora、ControlNet配合时的几个细节当你给工作流加Lora时Load Lora节点会接收CLIP信号并把经过Lora调制的CLIP输出给CLIPTextEncode。这里的关键是Lora的触发词一定要写在提示词里而且最好放在显眼位置——通常Lora作者会在模型介绍页给出触发词不写的话Lora风格强度会大打折扣。和一个容易踩的坑如果你在流程里加载了多个Lora它们的触发词最好不要冲突否则CLIPTextEncode编码后的语义会互相干扰出图容易出现“风格打架”的现象。我的做法是每次最多挂两个Lora一个是底模配套的细节Lora一个是风格/角色Lora触发词分别写在正面提示词的不同位置中间用逗号隔开。ControlNet则完全是另外一条线它输入的是图像输出的是控制条件不经过CLIPTextEncode。但ControlNet和Keyword节点有一个配合关系——ControlNet控制的是“形”Keyword节点控制的是“意”。比如你用了OpenPose骨架图控制人物姿势那么提示词里就应该明确写“standing, full body”这类与骨架匹配的描述你用了Depth控制景深结构提示词里写“indoor, room”会比空泛的“beautiful scene”好很多。两者在语义上越一致出图效果越稳定。5. 常见问题与排查技巧实录5.1 改了提示词画面纹丝不动从哪里查起这是我在各种群里被问得最多的一个问题。排查顺序建议如下第一检查KSampler的denoise。如果denoise是0.5或者更低生成结果会保留大量原始结构提示词改变带来的差异会被压制。纯文生图流程denoise一定要是1.0。第二检查CLIPTextEncode是否真的接在了KSampler的positive或negative上。有时候你新增了一个节点但连线接错到了别的节点上系统依然能运行只是提示词根本没进入采样流程。第三检查是否有其他Conditioning节点比如ConditioningZeroOut、ConditioningConcat在中间做了不可见的干扰。曾经我排查过一个问题一个零值条件节点和文本条件做了Concat等于把有用的文本条件稀释了结果提示词怎么改都“没效果”。第四检查CFG是不是被调得太低。CFG低于4时提示词对生成结果的影响会变得很弱画面更接近“模型自由发挥”的状态。5.2 中文提示词为什么经常不灵CLIP模型是基于英文语料训练的词表覆盖以英文为主。你把中文“一只可爱的猫”直接写进CLIPTextEncode模型虽然能分词但中文token在嵌入空间的语义覆盖远不如英文清晰经常出现“识别成了某个近似概念但完全不是你要的东西”的情况。解决方案有两个方向。第一个是翻译成英文再输入这个方法最简单直接效果也最稳定。第二个是使用一些专门封装了中文处理逻辑的工作流或插件它们会在内部把中文提示词先翻译成英文再交给CLIP编码。但你如果只是临时测试建议直接写英文不要依赖翻译插件因为翻译质量参差不齐出图结果很难统一复现。还有一个小技巧如果某个英文单词你记不准确可以用简单的同义替换不要硬写。例如“transparent”记不住就写“see-through”或“glass-like”模型对高频词的语义覆盖率远高于生僻词。5.3 Token超长被截断画面总缺东西怎么办前面说过SD1.5上限是77tokenSDXL虽然有两个text encoder但单次处理上限也没有翻倍到完全无视长度。当你发现提示词写的很全但生成结果总是“画面元素残缺不全”大概率是后半段被截断了。一个快速判断方法在CLIPTextEncode的text输入框里输入英文句子然后接一个“CLIP Tokenizer”或“Show Text”之类的调试节点查看token数量。如果接近或超过77就需要精简。精简时优先删形容词和冗余修饰保留名词和动词结构或者把长句拆成两个CLIPTextEncode再用ConditioningConcat拼接效果往往比删词更好。5.4 权重语法写了没反应多半是标点问题权重语法失效的高频原因是标点。中文输入法打出的逗号、括号和英文逗号、括号在文本层面是不同的字符ComfyUI解析时只认英文半角字符。你写“(cat:1.2)”在中文输入法下可能实际打出的是“cat:1.2”肉眼看着差不多解析器完全不认识。排查办法很简单把文本内容复制到一个纯文本编辑器里开启“显示标点符号”功能检查有没有全角字符。另外权重数值建议保留小数点后一位写“(cat:1.25)”也能解析但没必要那么精细。还有一个小坑权重语法不要用在负面提示词上。负面提示词本身是一个整体方向控制你给某个词加权并不会让模型“更不画某个东西”反而有可能让模型对该词的概念产生过度修正引发画面畸变。负面提示词就简简单单列质量词就好别搞花活。写在最后Keyword节点最大的价值不是“写词”而是“理解条件”我自己玩ComfyUI这么久最大的感悟是很多人以为工作流出图好坏取决于模型大小、采样器选择、步数设置但在实际调图过程里Keyword节点对出图效果的“塑形”能力被严重低估了。一张图的构图方向、内容主体、风格倾向很大程度上在文本编码完之后就已经基本定型了后面的采样只是在“细化”和“修正”。我建议你花一个下午单独把Keyword节点拎出来做一组对照实验固定其他节点参数不变只变换提示词的顺序、结构和权重记录一下每组出图的差异。做完这组实验你对提示词的理解会超过很多人闷头画半年积累的经验。最后再分享一个小技巧当你想测试一个新checkpoint或新Lora时先用一段你已经非常熟悉、出图效果很稳定的固定提示词作为基准不要一上来就写新内容。只有控制变量你才能判断新模型带来的变化是正面的还是负面的。Keyword节点的输出质量决定了一次实验是否有参考价值——这句话值得加粗。
ComfyUI核心节点解析：CLIPTextEncode与提示词管理全指南
最近在群里帮人排查工作流发现一个很有意思的现象很多人对ComfyUI里那个绿油油的、写着“Conditioning”的节点理解得很浅觉得它就是个“输入提示词的地方”。但实际去追问正面提示词和负面提示词为什么要分开接、为什么同一个提示词在不同的checkpoint下效果差异很大、为什么有些人可以用一句“a cute cat”就出图而你写了一大段英文却完全跑偏——这些问题追到最后全都落在Keyword节点也就是CLIPTextEncode这类文本编码节点身上。这篇文章我想系统拆一下这个节点。不是简单说“你连上就能用”而是把它内部到底做了什么、哪些参数会影响出图、怎么组织提示词才能稳定出图、遇到问题该怎么查一次性讲透。无论你刚接触ComfyUI还是已经玩了一段时间但一直对提示词管理比较随意这篇都值得花十分钟看完。1. Keyword节点到底是什么为什么工作流里离不开它1.1 模型看不懂文字Keyword节点是“翻译官”先来搞清楚一个最底层的问题为什么AI画图需要Keyword节点原因很简单——Stable Diffusion这类模型是纯数字系统它内部处理的全是张量Tensor也就是多维数组。你手写的英文提示词、中文提示词、甚至emoji模型本身根本不认识。要让模型理解你的意图必须有一层“翻译机制”把自然语言转换成模型能理解的数值信号。这个转换分两步第一步是把字符串拆成token词元也就是把句子切成模型词表里能对应的最小单位第二步是把每个token变成一个向量这个向量带着语义信息。Keyword节点在ComfyUI里干的就是这件事。我用一个生活化的类比帮你理解你把一个菜谱交给一个只懂法语的大厨你中文说得再清楚也没用大厨听不懂。你需要一个翻译官把你的话翻译成法语的烹饪术语大厨才能动手。Keyword节点就是这个翻译官它把中文/英文提示词翻译成“Stable Diffusion语”——也就是一组数学向量后续的UNet和采样器拿到这组向量才知道该往哪个方向去噪生成图像。在ComfyUI里这个节点最常见的名字叫CLIPTextEncode界面很简单一个text输入、一个clip输入、一个conditioning输出。很多新手觉得它简单但它恰恰是整个流程里最值得花心思去理解的一环因为所有关于“画什么”的信息都从这里进入模型。1.2 它在节点图中的位置一切条件控制的入口ComfyUI是节点式流程典型的Text-to-Image工作流长这样checkpoint加载器 → CLIPTextEncode正面 → KSampler → VAEDecode → 保存图像。其中CLIPTextEncode承担着所有文本条件的编码工作。但你如果只把它当成“一个放提示词的框”会漏掉很多细节。实际上ComfyUI里有好几个节点都带“Conditioning”输入输出比如ConditioningConcat、ConditioningZeroOut、ConditioningSetArea等等。Keyword节点是这条“条件链路”的起点后面接谁、怎么接决定了提示词是以什么方式影响扩散过程的。举个例子当你同时使用ControlNet和文本提示词时ControlNet输出的是ExtraConditioning它和文本的Conditioning在采样器里是并列关系不是替代关系。也就是说文本条件仍然全程参与生成ControlNet只是额外加了空间结构约束。如果你把Keyword节点删了哪怕ControlNet接得再完整出图也会非常飘忽因为模型完全失去了语义引导。所以我的结论是Keyword节点不是“可有可无的入口”而是整个扩散模型的语义锚点。你后续玩什么图生图、局部重绘、风格迁移凡是涉及文本的都绕不开它。2. 核心原理解析一段提示词是如何变成模型信号的2.1 分词、映射、编码三个不可见的关键步骤那Keyword节点接收到你输入的文本之后内部是怎么处理的主要经历三个步骤第一步是分词Tokenization。模型有一个固定的词表比如SD1.5用的CLIP词表大约有49408个token。文本会被切成若干个token每个token对应一个数字ID。常见情况是一个单词是一个token但有些罕见词会被切成多个token数字也可能被合并。这就是为什么同一个单词在不同写法下效果不同。第二步是向量化映射。每个token ID都会去查找嵌入层embedding layer取出一个对应的向量。这个向量的维度取决于CLIP模型的配置SD1.5用的是768维SDXL用的是1280维。可以理解为每个词在“语义空间”里有一个固定坐标。第三步是通过CLIP的Transformer层做上下文编码。这里是最关键的一步模型不是单独理解每个词而是结合上文的顺序和关系生成一组带上下文信息的向量序列。也就是说“a cat on the mat”和“a mat on the cat”虽然用了同样的词但经过编码后的向量是完全不同的因为位置信息和词间关系都被编码进去了。理解这三步有什么用非常有帮助。它能帮你解释“为什么提示词顺序影响出图”“为什么有些词会被忽略”“为什么中文提示词效果差”——前两个问题都和tokenization以及上下文编码相关第三个问题则和词表覆盖范围强相关。2.2 一个被忽略的参数最大Token限制SD1.5的CLIP模型一次最多处理77个tokenSDXL有两个文本编码器其中一个也是77个token的限制实际处理的是77×2的长度。这意味着什么你一次性输入的提示词如果超过77个token后面超出的部分会被直接截断完全不参与生成。我见过不少人疯狂堆砌提示词写了两三百个token的“咒语”以为越长越精细结果后半段根本没被模型看到等于白写。这也就是为什么很多人觉得“提示词越长效果越差”——不是因为长文本不好而是因为你的后半段压根没被处理。那怎么利用这77个token我的经验是把最重要的内容往前放前面30个token放主体中间30个放风格和细节最后17个放环境或氛围。不要把一个细节反复用不同词描述浪费token。如果你的需求确实超过77个token可以考虑使用SDXL或者用ConditioningConcat把多段文本拼接起来不同分段的语义可以叠加效果比重写一大段要好很多。2.3 权重语法ComfyUI是怎么解析的Keyword节点还支持一种权重语法用来微调某个词在生成过程中的影响力。最常见的做法是写成(keyword:1.2)意思是把“keyword”这个token的权重提升到1.2倍。ComfyUI的解析逻辑其实发生在进入CLIP之前——节点内部先把文本里的括号语法剥出来解析成对应token的缩放系数然后再送进编码器。这里有不少新手容易踩坑。第一权重数值不是越大越好超过1.5容易造成过拟合式的“画崩”比如画面出现大面积伪影、色彩溢出第二小括号和中括号的语义不同(keyword)是微幅增强[keyword]通常是降低权重第三如果你在中文输入法状态下打了全角括号“keyword:1.2”很多版本不会被正确解析权重直接失效。我个人比较推荐的做法是核心主体词用1.1到1.3的权重细节修饰词不要加权重环境词可以适当减重。这个经验是在大量出图后总结出来的——权重本质上是影响attention的曝光度太强的权重会导致模型过度关注某个词反而忽略其他描述。3. 实操指南从零到一搭建一套可复用的提示词管理流程3.1 最基础的三个节点串联先保证能出图我们先从最小可用流程开始。假设你已经装好了ComfyUI并能正常加载一个checkpoint模型。搭建一个能出图的流程只需要三个核心节点第一步添加“Load Checkpoint”节点选择你下载好的模型文件比如SD1.5或SDXL的ckpt/safetensors。这个节点会输出MODEL、CLIP、VAE三路信号其中CLIP就是要接给Keyword节点的。第二步添加两个“CLIPTextEncode”节点。一个用于正面提示词一个用于负面提示词。把Load Checkpoint输出的CLIP分别接到两个节点的clip输入端口。第三步添加“KSampler”节点。把正面的CLIPTextEncode输出接到positive负面的CLIPTextEncode输出接到negative再把Load Checkpoint的MODEL接过去。设置好种子、步数、CFG点击运行就能出图。很多新手在这里会忽略一个细节——KSampler下方的“denoise”参数。在纯文生图流程里它通常保持1.0但如果你之前做了图生图denoise被调低了哪怕你换了完全不同的提示词生成结果也会带着原图的影子。这在排查“为什么提示词改了没效果”的时候是第一优先检查项。3.2 正面和负面两个CLIPTextEncode的分工与协作新手最容易犯的误区是把太多负面描述写进负面提示词比如“no dog, no cat, no tree, no car”。负面提示词的本质不是“排除法”而是提供“不希望出现的语义方向”。写太多具体实体的负面会让模型在去噪过程中反复修正方向浪费采样步数还可能引入伪影。我的经验是负面提示词优先写质量类词汇比如“lowres, bad anatomy, bad hands, extra fingers, blurry”这类常见问题描述如果某个具体物体反复出现且你确实不想要再加排除词。正面提示词则按“主体→细节→风格→环境”的结构组织。另外一个容易被忽略的细节如果你的负面提示词留空CLIPTextEncode不是不编码而是编码一个空字符串向量这个空向量本身也有方向性对出图是有影响的。所以不要以为“不填就完全没作用”。负面提示词尽量保持稳定一套方便对比实验。3.3 一套可抄作业的工作流模板速查表下面这个表格是我日常用的文生图工作流模板适合SD1.5和SDXL所有节点都是ComfyUI自带能力不需要额外插件节点名称输入来源关键参数输出去向Load Checkpoint无模型选择MODEL → KSamplerCLIP → CLIPTextEncodeVAE → VAEDecodeCLIPTextEncode (正面)clip来自Load Checkpointtext手写正面提示词CONDITIONING → KSampler positiveCLIPTextEncode (负面)clip来自Load Checkpointtext手写负面提示词CONDITIONING → KSampler negativeEmpty Latent Image无宽高、批次数LATENT → KSampler latent_imageKSamplermodel、positive、negative、latent种子、步数、CFG、采样器名、调度器、denoiseLATENT → VAEDecodeVAEDecodesamples来自KSamplervae来自Load Checkpoint无IMAGE → Save ImageSave Imageimages来自VAEDecode文件名前缀输出图像用这个模板你可以稳定复现绝大多数提示词效果。后续加Lora、ControlNet也都是在这个基础上增加分支而不是推翻重来。4. 进阶玩法动态提示词、多段拼接与自动批量4.1 用动态语法实现随机与组合出图单张出图只是基础实际项目里我们经常需要批量探索画风或内容。ComfyUI有一个非常有用的文本语法动态提示词Dynamic Prompts通过花括号实现随机选择比如写“{cat, dog, rabbit} on a {beach, mountain, city street}”每次运行会从花括号里随机各取一个词组合。这个功能不需要任何额外插件ComfyUI的默认文本处理就支持花括号语法。你在CLIPTextEncode的text输入框里直接写就行。我经常用它做风格抽卡固定主体描述不变把风格词放在花括号里一次跑三四张图能看到不同风格落在同一主体上的效果。配合“Latent Image”节点里的batch_size参数一次可以生成多张随机组合图。但用了动态提示词后有一个问题你没法保证随机出来的组合都是合理的。比如“a cat on a mountain”可能合理“a dog on a city street”也合理但“a rabbit on the sun”就会画得很奇怪。所以我建议动态范围只放在风格、光线、材质这类不影响物理常识的维度上主体和环境尽量固定否则筛选成本会很高。4.2 提示词分段让画面不同区域各取所需另一个进阶玩法是用多个CLIPTextEncode节点分别描述画面不同区域的内容然后用ConditioningSetArea等区域控制节点把它们组合起来。这在多角色构图、多物体互动时特别有用。原理也很直白每个CLIPTextEncode输出一个条件你通过区域设置把条件绑定到图像的不同坐标区间KSampler在去噪时会根据位置取用对应的文本语义。你可以先用“a red car”的提示词控制左下角区域再用“a blue motorcycle”控制右上角区域两张画面在同一张图中共同生成互相影响的程度由区域边界和重叠参数控制。不过说实话这个玩法对新手不太友好需要你对latent图像的尺寸坐标有概念。我建议先把最简单的分段拼接ConditioningConcat玩明白把两段提示词用Concat节点拼接起来让它们按顺序共同影响整个画面。这适合描述复杂构图第一段写主体第二段写背景和光线合成后语义完整度比重写一段长提示词高很多。4.3 Keyword节点与Lora、ControlNet配合时的几个细节当你给工作流加Lora时Load Lora节点会接收CLIP信号并把经过Lora调制的CLIP输出给CLIPTextEncode。这里的关键是Lora的触发词一定要写在提示词里而且最好放在显眼位置——通常Lora作者会在模型介绍页给出触发词不写的话Lora风格强度会大打折扣。和一个容易踩的坑如果你在流程里加载了多个Lora它们的触发词最好不要冲突否则CLIPTextEncode编码后的语义会互相干扰出图容易出现“风格打架”的现象。我的做法是每次最多挂两个Lora一个是底模配套的细节Lora一个是风格/角色Lora触发词分别写在正面提示词的不同位置中间用逗号隔开。ControlNet则完全是另外一条线它输入的是图像输出的是控制条件不经过CLIPTextEncode。但ControlNet和Keyword节点有一个配合关系——ControlNet控制的是“形”Keyword节点控制的是“意”。比如你用了OpenPose骨架图控制人物姿势那么提示词里就应该明确写“standing, full body”这类与骨架匹配的描述你用了Depth控制景深结构提示词里写“indoor, room”会比空泛的“beautiful scene”好很多。两者在语义上越一致出图效果越稳定。5. 常见问题与排查技巧实录5.1 改了提示词画面纹丝不动从哪里查起这是我在各种群里被问得最多的一个问题。排查顺序建议如下第一检查KSampler的denoise。如果denoise是0.5或者更低生成结果会保留大量原始结构提示词改变带来的差异会被压制。纯文生图流程denoise一定要是1.0。第二检查CLIPTextEncode是否真的接在了KSampler的positive或negative上。有时候你新增了一个节点但连线接错到了别的节点上系统依然能运行只是提示词根本没进入采样流程。第三检查是否有其他Conditioning节点比如ConditioningZeroOut、ConditioningConcat在中间做了不可见的干扰。曾经我排查过一个问题一个零值条件节点和文本条件做了Concat等于把有用的文本条件稀释了结果提示词怎么改都“没效果”。第四检查CFG是不是被调得太低。CFG低于4时提示词对生成结果的影响会变得很弱画面更接近“模型自由发挥”的状态。5.2 中文提示词为什么经常不灵CLIP模型是基于英文语料训练的词表覆盖以英文为主。你把中文“一只可爱的猫”直接写进CLIPTextEncode模型虽然能分词但中文token在嵌入空间的语义覆盖远不如英文清晰经常出现“识别成了某个近似概念但完全不是你要的东西”的情况。解决方案有两个方向。第一个是翻译成英文再输入这个方法最简单直接效果也最稳定。第二个是使用一些专门封装了中文处理逻辑的工作流或插件它们会在内部把中文提示词先翻译成英文再交给CLIP编码。但你如果只是临时测试建议直接写英文不要依赖翻译插件因为翻译质量参差不齐出图结果很难统一复现。还有一个小技巧如果某个英文单词你记不准确可以用简单的同义替换不要硬写。例如“transparent”记不住就写“see-through”或“glass-like”模型对高频词的语义覆盖率远高于生僻词。5.3 Token超长被截断画面总缺东西怎么办前面说过SD1.5上限是77tokenSDXL虽然有两个text encoder但单次处理上限也没有翻倍到完全无视长度。当你发现提示词写的很全但生成结果总是“画面元素残缺不全”大概率是后半段被截断了。一个快速判断方法在CLIPTextEncode的text输入框里输入英文句子然后接一个“CLIP Tokenizer”或“Show Text”之类的调试节点查看token数量。如果接近或超过77就需要精简。精简时优先删形容词和冗余修饰保留名词和动词结构或者把长句拆成两个CLIPTextEncode再用ConditioningConcat拼接效果往往比删词更好。5.4 权重语法写了没反应多半是标点问题权重语法失效的高频原因是标点。中文输入法打出的逗号、括号和英文逗号、括号在文本层面是不同的字符ComfyUI解析时只认英文半角字符。你写“(cat:1.2)”在中文输入法下可能实际打出的是“cat:1.2”肉眼看着差不多解析器完全不认识。排查办法很简单把文本内容复制到一个纯文本编辑器里开启“显示标点符号”功能检查有没有全角字符。另外权重数值建议保留小数点后一位写“(cat:1.25)”也能解析但没必要那么精细。还有一个小坑权重语法不要用在负面提示词上。负面提示词本身是一个整体方向控制你给某个词加权并不会让模型“更不画某个东西”反而有可能让模型对该词的概念产生过度修正引发画面畸变。负面提示词就简简单单列质量词就好别搞花活。写在最后Keyword节点最大的价值不是“写词”而是“理解条件”我自己玩ComfyUI这么久最大的感悟是很多人以为工作流出图好坏取决于模型大小、采样器选择、步数设置但在实际调图过程里Keyword节点对出图效果的“塑形”能力被严重低估了。一张图的构图方向、内容主体、风格倾向很大程度上在文本编码完之后就已经基本定型了后面的采样只是在“细化”和“修正”。我建议你花一个下午单独把Keyword节点拎出来做一组对照实验固定其他节点参数不变只变换提示词的顺序、结构和权重记录一下每组出图的差异。做完这组实验你对提示词的理解会超过很多人闷头画半年积累的经验。最后再分享一个小技巧当你想测试一个新checkpoint或新Lora时先用一段你已经非常熟悉、出图效果很稳定的固定提示词作为基准不要一上来就写新内容。只有控制变量你才能判断新模型带来的变化是正面的还是负面的。Keyword节点的输出质量决定了一次实验是否有参考价值——这句话值得加粗。