企业官网建设流程全解析

在 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，够做一轮筛选了。设完记得观察实际出图数量是不是你预期的，因为超过上限后插件的行为在不同版本里不一致，有的是截断，有的是随机采样。

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 到 4；SDXL 系列 1024×1024 单张起步 8GB 到 10GB，12GB 显存建议 batch size 保持 1。这些是经验值，实际还受文本编码器是否常驻显存、是否启用显存优化选项影响。

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 张稳得多。

6. 长期维护：词库、模板与经验沉淀

6.1 词库版本管理与迭代节奏

词库是会生长的东西，不管理就会变成一堆没人敢动的垃圾。我的做法很土但有效：每次大改之前复制一份带日期的备份，文件名加_20240115这样的后缀。不用上复杂的版本工具，文本文件加日期后缀足够了。

迭代节奏上，我不建议每天都往里加词。更好的模式是攒一批再加：平时出图的时候看到好的效果，把当时的提示词片段记在一个“待收录”文本里，每周整理一次，筛掉重复和无效的，合并进正式词库。这个流程的好处是词库里的每一条都是被验证过的，而不是网上抄来的。

定期清理也很重要。三个月没被任何模板引用过的词条，直接删。词库不是越大越好，一个 500 行的高质量词库，效果远好过一个 5000 行的杂货铺，因为后者会让随机分布稀碎，你很难通过调整模板来控制画面。

6.2 踩坑多年沉淀下来的几条硬经验

第一条，先固定再随机。新做一套模板，前 20 张图全部固定参数、固定词条，确认模板本身的构图和风格是你要的，然后再把各个槽位逐步放开随机。反过来做，你会在随机的结果里迷失，根本不知道模板哪里有问题。

第二条，模板数量宁少勿多。我见过有人建了三十套模板，结果每套都只用过一次。真正好用的模板通常就三到五套，分别对应不同的出图目的（人像、场景、概念图、材质测试），把这五套打磨到极致，比三十套半成品强得多。

第三条，词条要跟模型绑定记录。同一批词条在不同模型上的表现差异巨大，你在 A 模型上验证有效的词库，换到 B 模型可能完全失效。所以词库文件的开头或者配套的说明文件里，写清楚它是在哪个模型、哪个采样器、什么步数下验证的。这个信息三个月后你自己会感谢自己。

第四条，别迷信“万能词库”。网上流传的那种几万行的通用词库，听起来很美，实际用起来你会发现 90% 的词条跟你的审美不搭，而你要花大量时间去筛。自己从零建一个 200 行的词库，用一个月，比直接用现成的快得多。

第五条，批量出图的成果要立刻处理。出完 200 张，当天必须筛完、归档、把有价值的参数记下来。拖到第二天，你面对着 200 张不知道哪张是哪张的图，只能重新跑一遍。这个环节的纪律性，直接决定了这套工作流到底是提效还是添乱。

最后再分享一个小技巧：给每次批量任务建一个对应的文本文件，文件名就是任务启动的时间戳，里面记录模板全文、展开后的前几条完整提示词、种子范围、以及你自己的主观评价（“这批光线不错但姿态太单一”）。这个习惯坚持三个月，你会拥有一份完全属于自己的、别人抄不走的提示词经验库，比任何插件都值钱。