在 SD-WebUI 的插件生态里提示词扩展类插件属于那种“装的时候不觉得用顺手了离不开”的工具。它干的活很具体把你手写的一句提示词变成可随机、可组合、可批量、可复现的一整批提示词。解决的是同一个痛点——同一个模型、同一个采样器、同一套参数为什么别人能一天出两百张不重样的图而你还在复制粘贴改五个词、改到自己都不知道在改什么。这篇内容面向三类人刚装完 WebUI 还在摸索提示词写法的新手、已经能稳定出图但卡在“量产”环节的中级用户、以及需要做对照实验验证提示词效果的进阶玩家。下面我按“为什么这么设计—插件怎么解析—参数怎么配—流水线怎么搭—坑怎么绕”的顺序把我这几年的实操细节摊开讲一遍。1. 先把问题说透提示词扩展插件到底在替你干哪部分活1.1 从“写一句提示词”到“管一个提示词池”的认知转变绝大多数人第一次接触提示词扩展理解都停在“随机换词”这一层觉得它就是个玩具。这个理解会让你错过它 80% 的价值。真正的分水岭在于你是在“写提示词”还是在“管提示词池”。写提示词是线性的——我想一个画面我描述它我出图不满意我改一个词再出图。这种做法在初期是必要的因为它建立你对模型语感的直觉。但当你需要出 200 张图去挑 3 张或者需要验证“加不加rim light到底差多少”线性写法就彻底崩了因为你的时间成本全花在重复敲键盘上而不是在判断结果上。提示词池是结构化的——把画面拆成若干可替换的零件主体、动作、镜头、光线、质感、氛围、构图。每个零件对应一个词库文件每个词库文件里有几十到几百个候选词条。生成时由插件按规则抽取组合你在旁边看结果、做筛选、记录哪几组词条命中了你的审美。这时候你的角色从“打字员”变成了“策展人”效率差着一个数量级,判断质量也完全不同——因为你终于有足够的样本量去观察规律而不是靠三五张图凭感觉。我见过太多人卡在这一步他们的提示词永远是一整段没有分层的长句权重乱加改一个词整段崩。根源不是模型不懂是提示词本身没有结构插件再强也救不了没有结构的东西。所以装插件之前先花半小时把自己的常用提示词拆成 5 到 7 个字段这件事的收益比任何插件都大。1.2 三类主流插件的能力边界与选型判断SD-WebUI 里的提示词扩展不是单一插件是一族。按职责可以分成三类它们解决的问题完全不同装错类型会白折腾。第一类是语法扩展型也就是常说的动态提示词。它在提示词里引入一套迷你语法花括号竖线做随机选择双下划线引用外部词库文件{}做变体采样还支持指定抽取数量。它的核心能力是“在采样阶段把模板展开成具体提示词”所以它管的是随机性和组合爆炸。第二类是输入辅助型典型是标签补全。它做的是一件事你敲三个字母它从本地标签库里把匹配的标签列出来带权重快捷调整、带分类、带预览。它不改变生成逻辑只改变你敲键盘的效率同时大幅降低拼写错误率——模型对拼错的标签基本无感你写了masterpice它不会报错只会默默忽略。这类插件对新手最友好收益立竿见影。第三类是语义转换型包括提示词翻译和提示词扩写。翻译解决的是双语转换问题让你能用母语组织思路扩写则是把一句短描述交给一个语言模型让它补全成完整的、符合模型语感的长提示词。这类插件风险最高因为它引入了不可控的中间环节——翻译可能丢掉关键词扩写可能把你的构图意图改得面目全非。我的选型建议很明确翻译和补全先装动态语法后装扩写最后再考虑。原因是前两者的收益确定、副作用小后两者的效果高度依赖你的词库质量和扩写模型的能力。用不好扩写的人往往得到一个“看起来很长很专业、但画面完全不受控”的结果最后反而退回到手写。表格对比一下这三类的适用场景方便你按需要装插件类型核心能力上手成本主要风险适合谁语法扩展型随机抽取、组合爆炸、词库引用中等要学语法随机性失控、结果难复现需要批量出图的中高级用户输入辅助型标签联想补全、权重快捷调整低装上就能用词库版本过旧导致标签不准所有用户尤其新手语义转换型中英翻译、短句扩写低到中等语义漂移、关键词丢失母语组织思路的用户、需要快速起稿的用户还有一个容易被忽略的判断维度你出图的目的。如果是为了探索风格、找灵感那语法扩展型的随机性就是优点如果是为了稳定复现某个效果、做交付那随机性就是灾难你就需要把它关掉只用模板化的固定词库。同一个插件两种用法配置完全相反。2. 核心机制拆解扩展语法是怎么被解析成最终提示词的2.1 通配符与槽位把一句提示词拆成可替换的零件先讲最基础的通配符引用。语法是双下划线包裹词库名比如__lighting__插件会去指定目录里找lighting.txt从这个文件的若干行里随机抽一行把结果替换进去。这套机制的巧妙之处在于它把“词条管理”和“提示词编写”彻底解耦了——你改词库不需要动提示词改提示词不需要动词库。我一般这么组织目录按语义分文件不按项目分。比如subject/放主体类pose/放姿态camera/放机位和镜头lighting/放光线mood/放氛围quality/放质量词。子目录用双下划线加路径引用__camera/lens__。这样你的提示词模板会非常干净__subject__ standing in __scene__, __camera/lens__ shot, __lighting__, __mood__, highly detailed这一句在每次生成时会被展开成完全不同的具体提示词。注意“完全”两个字——如果某个槽位有 50 个候选六个槽位就是 50 的六次方种组合你永远抽不到重复的。槽位还可以带数量控制。花括号里加数字和双美元符号表示从这组选项里抽几个{2$$masterpiece|best quality|ultra detailed|highres}表示这四个词里随机抽两个。范围写法是{1-3$$a|b|c|d}每次抽 1 到 3 个。这个功能在堆质量词的时候特别好用——你既不想全堆上去容易过锐、塑料感又不想一个都不加抽两到三个是甜点区。注意数量控制语法里的分隔符是竖线不是逗号。写成{2$$a,b,c}会被当成一个整体选项这是新手最常犯的语法错误之一。2.2 权重、分组与嵌套语法的边界在哪里扩展语法和原生权重语法是两套东西混用的时候必须清楚谁先谁后。原生权重是圆括号加冒号数字(word:1.3)插件解析时会先处理动态语法把模板展开成纯文本再交给 WebUI 的提示词解析器去处理权重。所以你在词库里写的权重词条是有效的但在随机语法内部套权重要小心。嵌套是另一个坑。很多人会写出这样的东西{(red|blue) dress|(green|yellow) shirt}。这个写法在部分插件版本里会解析异常因为解析器对嵌套花括号的处理是有限深度的。稳妥的做法是拆成两层词库文件外层一个outfit.txt每行写完整的一套衣服内层不用嵌套。宁可多建几个文件也不要在语法上耍聪明。权重的实际取值范围也有经验值。1.0 到 1.3 是安全区1.3 到 1.5 是危险区超过 1.5 基本就是过曝、色块、五官崩坏的开始。负向提示词那边权重可以更狠一点1.5 到 2.0 都还能用因为负向的作用是压制而不是塑形。这些数值没有理论保证是我在 SD1.5 系列模型上跑了上千张图摸出来的换 SDXL 系列模型权重敏感度会略低可以适当放宽。还有一个常被误解的点动态语法不是每张图都重新解析。在同一次“生成”动作里如果只出 batch size 张图一次前向提示词是同一份。只有跨 batch 的时候才会重新解析。所以你想要不同的展开结果必须靠增加 batch count或者开启组合模式。这件事搞不清楚就会遇到“我明明写了随机怎么出的图一模一样”的困惑。2.3 解析顺序与种子为什么同一张图复现不出来这是提示词扩展最让人头疼的问题必须讲清楚。一次生成涉及两个种子概念采样种子和扩展种子。采样种子决定噪声初始状态扩展种子决定随机语法抽到了哪些词条。大多数插件在保存图片时PNG 信息里记录的是采样种子和展开后的最终提示词而不是你写的那个模板。这意味着什么你把图发给别人别人用同样的参数、同样的种子出不来同样的图——因为他手上的模板展开结果和你不一样。你过两天自己复现也复现不出来。解决办法有两个。一是用好组合模式组合模式下插件会穷举所有组合每张图对应一个确定的组合序号这个序号是可以记录的复现性有保障。二是做好日志很多插件支持把每次展开的完整提示词写进图片元数据或者文本日志打开这个选项事后能查到当时抽到了什么。我强烈建议把日志打开硬盘不差那几 KB。提示如果你的工作流里有“出一批图、挑一张、再基于这张微调”的环节那第一件事就是把这批图的完整展开提示词保存下来。这个习惯能省掉无数次“我记得那个光挺好的但我想不起来写的是什么了”的抓狂。再补一个细节提示词长度。SD1.5 系列的文本编码器单次处理上限是 77 个 token超长部分会被分块处理但很靠后的内容对画面的影响会显著衰减。所以动态语法展开后如果太长前半段有效、后半段近乎无效。我的做法是把核心主体和构图放前面氛围和质量词放后面长度控制在 60 个 token 以内英文大约 40 到 50 个单词。想要更长的提示词就得考虑支持长文本编码的模型变体那是另一个话题了。3. 装与配把插件跑起来的最小可用配置3.1 安装路径与目录结构核对安装方式有三条路WebUI 内置的插件管理页按地址安装、Git 克隆到插件目录、或者直接下载压缩包解压。三条路的最终结果一样都是把插件代码放进extensions/下的独立子目录。我推荐前两种因为可以走更新检查手动解压的版本后面升级要重新走一遍流程。装完之后第一件事不是点启用而是核对目录。以动态提示词类插件为例它通常会有一个wildcards子目录你的词库文件必须放在这里或者放在你另行指定的目录。放错位置的典型症状是提示词里写了__lighting__插件报“找不到文件”或者更糟——不报错但原样输出__lighting__这几个字符直接进到模型里变成噪声。我建议装完先做一次最小验证在插件目录下新建一个test.txt写三行词然后在正向提示词里只写__test__出一张图。如果出来的图看着像那三行词里的某一个描述的说明链路通了。不通就去看控制台输出插件的加载日志一般会明确打印“从哪个路径加载了多少个词库”一眼能看出路径对不对。另外一个容易漏的配置是词库目录的绝对路径。有些插件允许你在设置里指定额外的词库目录这个路径要写绝对路径写相对路径在不同启动方式下会解析到不同位置。我吃过这个亏命令行启动一切正常换了启动脚本就找不到词库了查了半小时才发现是相对路径的锅。3.2 参数配置逐项过一遍设置页里那堆开关我按重要程度分三档讲。必开的三项一是启用动态提示词这个不开等于没装二是提示词展开日志/元数据保存为了复现三是组合模式的数量上限保护避免你不小心写了个组合爆炸把机器跑死。按需的两项一是“负向提示词也参与动态解析”默认关闭是对的。负向词库随机化很容易带来意外——你抽到一个没用过的负面词画面突然变糊你还不知道为什么。除非你有明确的负向词库策略否则保持关闭。二是“随机数来源”有 CPU、GPU 等选项差异不大但 GPU 来源在某些显卡上会触发额外的显存分配显存紧张的时候切成 CPU。劝退的一项自动扩写/魔法提示词。这个东西的原理是把你的提示词丢给一个小语言模型改写效果非常看脸而且耗时明显增加。我给它的定位是“灵感枯竭时按一下”不要常态化开启。参数里还有一个隐蔽但重要的配置组合模式的最大生成数。假设你有五个槽位每个 20 个候选理论组合数是 320 万。插件如果老老实实穷举你的机器会跑到天亮。所以这个上限必须设我一般设 200 到 500够做一轮筛选了。设完记得观察实际出图数量是不是你预期的因为超过上限后插件的行为在不同版本里不一致有的是截断有的是随机采样。参数项推荐值设置理由启用动态提示词开不开则语法完全无效负向提示词动态解析关负向随机化易导致画面质量跳水展开日志/元数据开复现与追溯的唯一依据组合模式最大生成数200-500防止组合爆炸跑死机器随机数来源CPU减少显存额外分配差异极小自动扩写关按需手动开耗时高、可控性差3.3 词库文件准备与质量规范词库质量决定这套系统的上限。几条硬规范编码必须是 UTF-8 无 BOM。带 BOM 的文件第一行开头会多出三个不可见字节导致第一个词条永远匹配失败或者带着乱码进提示词。Windows 记事本保存的时候注意选编码别用默认的 ANSI。一行一个词条不要标点不要编号。词条是直接拼进提示词的你写了1. soft light,逗号和序号都会进到模型里变成无意义 token。分隔符由提示词模板负责不是词库负责。单个文件控制在几千行以内。我实测过两三万行的超大词库文件会让每张图的解析耗时明显上升因为每次抽取都要读文件。按语义拆成多个文件既快又好维护。去重。词库长起来之后重复词条极难避免重复不致命但会让某个词的出现概率翻倍破坏随机分布的均匀性。隔一段时间跑一次去重脚本或者干脆用表格软件排序找重复。词条要写“有效的词”。什么叫有效模型训练数据里高频出现的、语义明确的词。写very very beautiful amazing这种模型对修饰词堆叠基本无感纯属浪费 token。写volumetric fog、shallow depth of field、golden hour backlight这种具体的光学/视觉术语效果立刻不一样。一个我踩过的坑词条里不要写中文。哪怕你装了翻译插件词库文件里的中文在解析时可能被拆成奇怪的字节序列或者翻译插件只处理提示词不处理词库引用。词库老老实实写英文翻译放在输入环节。4. 生产级玩法把提示词扩展接进批量出图流水线4.1 批量规模与耗时的估算方法批量出图的第一课是算账不算账就会遇到“挂机两小时出了 20 张”的尴尬。先算单张耗时。以 512×512、20 步采样、常见中端显卡为例单张大约 2 到 4 秒。1024×1024 大约翻三到四倍8 到 15 秒。这个数字受采样器、步数、是否用高分辨率修复影响很大所以第一步永远是实测单张耗时而不是拍脑袋估。再算总张数。总张数 组合数上限或你设定的数量× 每个组合的出图数。比如你要 300 张候选单张 3 秒理论 15 分钟实际加上模型换载、图片保存、CPU 解码通常要乘以 1.3 到 1.5 的系数也就是 20 到 23 分钟。这个预估很重要因为它决定了你要不要去吃个饭。显存这边是另一套算法。batch size 决定显存峰值batch count 只影响总时长不影响显存。所以显存吃紧的时候正确做法是把 batch size 降到 1把 batch count 加上去速度会慢一点但不会爆。很多人反过来做把 batch size 拉到 8结果 OOM 报错然后以为是自己显卡不行。粗略的显存参考SD1.5 系列 512×512 单张推理大约 4GB 起步6GB 显存可以跑 batch size 2 到 4SDXL 系列 1024×1024 单张起步 8GB 到 10GB12GB 显存建议 batch size 保持 1。这些是经验值实际还受文本编码器是否常驻显存、是否启用显存优化选项影响。分辨率与模型档位单张耗时中端卡建议 batch size显存下限参考512×512 / 轻量模型2-4 秒46GB768×768 / 轻量模型5-8 秒26-8GB1024×1024 / 大模型8-15 秒110-12GB1024×1024 高清修复25-40 秒112GB 以上4.2 对照实验用矩阵脚本验证每个词条的真实贡献如果你只从这篇里带走一件事我希望是这件提示词扩展的真正价值不在出图快在于它能让你做对照实验。做法是这样。你怀疑cinematic lighting这个词是不是真的有用那就别靠感觉。固定采样种子、固定所有其他参数、固定模板只让这一个词在“加”和“不加”之间切换各出 3 到 5 张并排看。WebUI 自带的 X/Y/Z 对比脚本就是干这个的把变量轴设成提示词片段两个值分别是空和cinematic lighting一次跑完直接出对比网格图。这个方法的威力在于它把玄学变成了数据。我靠这个办法验证过好几条反直觉的结论某些被吹上天的“神词”在我常用的模型上几乎没有可见影响某些看起来无关紧要的构图词反而是效果最明显的。这些结论换模型就不成立了所以必须自己测。做对照实验有几个纪律。一是一次只变一个变量同时改提示词和采样器你永远不知道是谁的功劳。二是每个条件至少三张单张的随机波动太大。三是固定种子不然噪声的差异会淹没提示词的差异。四是记笔记把结论写下来不然一周后全忘。4.3 与其他插件的协同与冲突提示词扩展不是孤岛它跟几个常见插件有交互。跟标签补全类插件的关系是互补的补全负责输入效率扩展负责展开逻辑两者不冲突。但要注意补全的触发字符通常是逗号或空格有时候会跟动态语法的花括号打架在写语法的时候补全弹窗频繁干扰。解决办法是在设置里把触发字符改成更少用的符号或者写语法的时候先关掉补全。跟提示词矩阵/对比脚本的关系需要小心有些对比脚本自己也会解析提示词两个解析器叠加可能导致语法被解析两次结果莫名其妙。稳妥做法是做对比实验时把动态语法关掉只用固定词条。跟图片信息读取类插件的关系是加分项展开后的完整提示词如果能被正确写进元数据那你后面把图拖回去就能还原参数。这个链路要验证一次——出一张图拖进读取框看提示词是模板还是展开结果。如果是模板说明日志没开或者格式不对。还有一个隐蔽的冲突源两个插件都想接管提示词预处理。症状是其中一方的语法完全失效。排查方法是把插件逐个禁用做二分通常三步就能定位。这也是我建议“插件能少装就少装”的原因每多一个插件就多一个潜在的预处理环节。5. 问题排查实录那些让人抓狂的“不生效”5.1 通配符完全没反应这是最高频的问题按概率排序排查。第一位主开关没开或者没保存。设置页改完要点应用并重启有些插件改完不重启不生效。这个听起来很蠢但我打赌每个人都至少中过一次。第二位文件编码带 BOM。前面讲过症状是提示词里原样输出双下划线内容。第三位文件名大小写和路径层级。__Lighting__和lighting.txt对不上子目录引用写成__lighting/warm__但实际文件在lighting/warm.txt的下一层。核对方法看控制台启动日志里插件打印的词库清单逐个对。第四位提示词语法被别的插件吃掉了。比如你装了另一个提示词处理插件它先一步把双下划线处理掉了。二分法排查。第五位词库文件是空的或者全是空行。有些编辑器保存时会加尾部空行如果文件只有一个词条加一堆空行抽取命中空行的概率很高表现就是“有时生效有时不生效”。排查口诀先看日志、再看编码、三看路径、四看插件冲突。这个顺序能解决九成问题。5.2 出图全是同款或者随机性失控两头都是病得分开治。全是同款三个原因。一是种子固定了动态语法的展开结果跟种子绑定固定种子等于固定组合。二是 batch size 大于 1 但 batch count 是 1一次前向里提示词只解析一次所以同一个 batch 内的图全用同一份展开结果。三是组合模式没开随机抽取在极端情况下连着抽到同一组概率低但词库小的时候会发生。随机性失控表现是十张图十个风格一个都不能用。根因通常是槽位太多、每个槽位候选太多、且核心主体也在随机。比如你把主体也做成随机槽位那出来的当然是十个不同的东西。解决办法是分级核心主体固定或者只在 2 到 3 个候选里选中间层姿态、服装小范围随机外围层光线、氛围、质量词大范围随机。这样保证“同一类东西的不同呈现”而不是“一堆不同的东西”。我自己的比例大致是主体 3 个候选场景 5 个候选机位 8 个候选光线 20 个氛围 20 个质量词 10 个。这样组合出来的图有足够的多样性但都在一个审美区间内。5.3 速度拖慢与显存问题速度突然变慢如果最近刚扩了词库先怀疑词库文件太大。前面说过大文件每次抽取都要读改成按语义拆分能明显改善。另一个原因是展开后的提示词变得很长文本编码耗时上升这个也好判断——把模板精简一下对比速度。显存溢出先降 batch size这是唯一正确的第一步。降了还溢出考虑关闭其他常驻显存的插件、降低分辨率、开启显存优化选项。不要一上来就怀疑显卡坏了。出图到一半卡住不动常见于组合模式跑大批量时。可能是某一张图触发了极端情况比如提示词展开后为空也可能是显存碎片累积。我的应对是批量任务拆成小段跑比如一次 100 张跑完释放一次比一口气跑 500 张稳得多。症状最可能原因处理动作双下划线原样输出编码带 BOM / 路径不对重存为 UTF-8 无 BOM核对目录同批次图完全一样batch size 1 且解析只发生一次改为 batch size 1 加大 batch count每次出图风格差异巨大主体层也被随机化主体槽位收敛到 2-3 个候选大批量中途卡死显存碎片 / 极端展开结果拆成百张一段跑完释放同一个种子复现失败保存的是展开结果而非模板开日志记录展开后提示词语法部分生效部分失效嵌套过深 / 插件冲突拆平语法插件二分排查6. 长期维护词库、模板与经验沉淀6.1 词库版本管理与迭代节奏词库是会生长的东西不管理就会变成一堆没人敢动的垃圾。我的做法很土但有效每次大改之前复制一份带日期的备份文件名加_20240115这样的后缀。不用上复杂的版本工具文本文件加日期后缀足够了。迭代节奏上我不建议每天都往里加词。更好的模式是攒一批再加平时出图的时候看到好的效果把当时的提示词片段记在一个“待收录”文本里每周整理一次筛掉重复和无效的合并进正式词库。这个流程的好处是词库里的每一条都是被验证过的而不是网上抄来的。定期清理也很重要。三个月没被任何模板引用过的词条直接删。词库不是越大越好一个 500 行的高质量词库效果远好过一个 5000 行的杂货铺因为后者会让随机分布稀碎你很难通过调整模板来控制画面。6.2 踩坑多年沉淀下来的几条硬经验第一条先固定再随机。新做一套模板前 20 张图全部固定参数、固定词条确认模板本身的构图和风格是你要的然后再把各个槽位逐步放开随机。反过来做你会在随机的结果里迷失根本不知道模板哪里有问题。第二条模板数量宁少勿多。我见过有人建了三十套模板结果每套都只用过一次。真正好用的模板通常就三到五套分别对应不同的出图目的人像、场景、概念图、材质测试把这五套打磨到极致比三十套半成品强得多。第三条词条要跟模型绑定记录。同一批词条在不同模型上的表现差异巨大你在 A 模型上验证有效的词库换到 B 模型可能完全失效。所以词库文件的开头或者配套的说明文件里写清楚它是在哪个模型、哪个采样器、什么步数下验证的。这个信息三个月后你自己会感谢自己。第四条别迷信“万能词库”。网上流传的那种几万行的通用词库听起来很美实际用起来你会发现 90% 的词条跟你的审美不搭而你要花大量时间去筛。自己从零建一个 200 行的词库用一个月比直接用现成的快得多。第五条批量出图的成果要立刻处理。出完 200 张当天必须筛完、归档、把有价值的参数记下来。拖到第二天你面对着 200 张不知道哪张是哪张的图只能重新跑一遍。这个环节的纪律性直接决定了这套工作流到底是提效还是添乱。最后再分享一个小技巧给每次批量任务建一个对应的文本文件文件名就是任务启动的时间戳里面记录模板全文、展开后的前几条完整提示词、种子范围、以及你自己的主观评价“这批光线不错但姿态太单一”。这个习惯坚持三个月你会拥有一份完全属于自己的、别人抄不走的提示词经验库比任何插件都值钱。