ComfyUI 提示词语法全解：权重、转义、动态提示与 embedding 引用

ComfyUI 的提示词语法条目非常少，README 的 Notes 章节里就那么几行。但正因为少，很多人是靠别的 WebUI 的经验去脑补它的行为，结果在两个地方反复翻车：一是括号权重的默认值记错，二是把花括号的随机当成了采样器层面的随机。

这篇按 ComfyUI v0.31.0（核对日 2026-08-09）官方仓库 README 的原始表述，把五条规则逐条拆开。比规则本身更重要的是每条规则由谁执行——是浏览器里的前端，还是 Python 后端的节点。这个归属决定了出问题时你该去改工作流、还是该去看前端版本。

五条规则的原文口径

先把 README 给的东西原样列出来，后面各节负责解释怎么读：

语法	README 规则
权重	用 () 改变词或短语的强调程度，例如 (good code:1.2) 或 (bad code:0.8)；() 的默认强调值是 1.1
转义括号	想在提示词里用真正的 ( ) 字符，写成 \( 或 \)
动态提示	`{day
转义花括号	想用真正的 { }，写成 \{ 或 \}
注释	动态提示支持 C 风格注释：// comment 或 /* comment */
词嵌入	把 textual inversion 概念/embedding 放进 models/embeddings 目录，在 CLIPTextEncode 节点里用 embedding:embedding_filename.pt 引用，可以省略 .pt 扩展名

这张表要横着读一遍再竖着读一遍：横着读知道语法长什么样，竖着读会发现它大致分成两组——括号权重和 embedding: 作用在文本编码节点这一侧，花括号和注释作用在前端这一侧。需要先说清楚的是：README 里只对动态提示一条明写了「由前端执行」，embedding: 那条明写了是在 CLIPTextEncode 节点里引用，其余归属是我们按语法出现的位置推出来的，不是官方逐条声明的。下面凡是推论，都会标出来。混淆这两组，是后面所有排查动作的分岔点。

括号权重：默认值是 1.1，不是 1.0

(good code:1.2) 这种写法没什么可讲的，冒号后面写多少就是多少。真正容易出错的是不带冒号的裸括号：() 的默认强调值是 1.1。

这意味着你在提示词里为了断句、为了视觉分组随手加的一对括号，并不是无害的排版——按 README 这句话，一对不带冒号的裸括号就代表 1.1 的强调，而不是装饰。所以从别处抄来的提示词里那些看着像排版的括号，在 ComfyUI 里要当成有语义的写法来读。至于多层嵌套时这 1.1 怎么叠加，README 没写，见下面一段。

反过来说，降低强调只能显式写。README 给的例子是 (bad code:0.8)，你必须把 0.8 写出来，没有「加一层括号就降权」的写法。想去掉强调，就把括号删掉，而不是再套一层。

需要如实说明的是：README 只给了这一句话和两个例子，没有说明权重的数值上限、多层括号嵌套时是相乘还是取最大、超出范围会不会被截断。这些我们没有依据，就不编。真要确认嵌套行为，正确做法是把嵌套写法和等价的单层显式写法各排一次队做对照，而不是听某个「1.1 的 n 次方」的说法。

转义：反斜杠对应的是括号本身

README 为这四个字符专门给了 \( \) \{ \} 四个转义序列。反过来读这条规则能得到一个很有用的默认前提（这是推论，README 没有直说）：( 和 { 在提示词里的默认身份是语法字符，只有加了反斜杠才退回普通字符。也就是说，不写反斜杠等于你在主动要求 ComfyUI 解析它。

什么时候会撞上？最常见的是提示词里要写带括号的专有名词、作品名、年份标注，或者要描述一段代码、一个公式。这时候你的本意是让模型看见括号这个字符，而不是让 ComfyUI 把括号里的内容当成权重段。写成 \( \) 就行。

判定动作也很直接：把提示词粘到编辑器里，搜一遍 (、)、{、}，逐个问自己「这个字符我是想让 ComfyUI 解析，还是想让它原样进文本」。凡是后者却没带反斜杠的，就是待修的地方——这一步不需要跑生成，纯看字面就能判。

动态提示：随机发生在前端，每次排队时

这是本文最想说清楚的一条，也是 README 里唯一带了「由谁执行」的一条。原文明写随机替换是 由前端在每次你排队提交提示词时 完成的（“by the frontend every time you queue the prompt”）。

把这句话拆开，能推出三个很实用的结论：

第一，它不是采样器层面的随机。 花括号的选择在提示词离开浏览器之前就已经定死了，后端收到的是一条已经替换完毕的普通字符串。所以固定 seed 并不能让 {day|night} 固定——seed 管的是采样，管不到一个在它之前就发生的文本替换。反过来，你想复现某一次结果，光记 seed 不够，还得知道那次抽中的是哪一个词。

第二，它解释了「为什么我什么都没改，连点几次队列结果却不一样」。 README 的执行模型里写着两条规则：只有输出端所有输入都正确的那部分图会被执行；只有相对上一次执行发生变化的部分会被执行，提交两次相同的图只有第一次真正执行。按这两条推演，一条不含花括号的提示词第二次排队时文本没变，理应命中缓存；而含花括号的提示词每次排队送到后端的字符串都可能不同，文本编码节点的输入就变了，它和依赖它的下游自然要重新执行。这个推演是基于 README 给出的规则组合出来的，README 本身没有把这两节连起来写，但它能自洽地解释这个现象。

第三，出问题时该查前端。 既然替换由前端完成，那么花括号语法失灵、注释没被吃掉这类问题，方向就不在后端 Python 代码里。ComfyUI 的前端自 2024-08-15 起已迁到独立仓库 Comfy-Org/ComfyUI_frontend，编译产物以 pypi 包 comfyui-frontend-package 的形式作为依赖安装，v0.31.0 的 requirements.txt 里 pin 的是 1.48.7。README 也明确建议：前端相关的 bug 与需求应该提到前端仓库，这样官方好分流。想换前端版本，README 给的参数是 --front-end-version Comfy-Org/ComfyUI_frontend@latest 取每日版，把 latest 换成版本号（README 举的例子是 1.2.2）取指定版，或者用 --front-end-root PATH 指向本地目录（它会覆盖 --front-end-version）。主仓库里的前端每两周更新一次，独立仓库是每日发布——所以「我朋友那台机器行为不一样」很可能只是两边前端版本差了几周。

一个可执行的验证动作：写一条只含 {day|night} 的提示词，什么都不改连排几次队，然后只看执行范围——按 README 的第 2 条规则，只要出现过「第二次仍然重新执行了文本编码及其下游」，就说明送到后端的字符串确实变了，替换生效。注意 {day|night} 只有两个选项，连着抽到同一个词是很正常的，所以别只排两次就下结论；连排若干次全都被整条跳过，才该去怀疑你把花括号转义掉了，或者前端版本不对。这个判定不依赖任何对画面的主观比对。

注释：它挂在动态提示这一节下

README 的原话是「动态提示支持 C 风格注释」，给的两种形式是 // comment 和 /* comment */。

这句话的措辞值得留意：它没有说「提示词支持注释」，而是说动态提示支持。按字面理解，注释和花括号是同一层能力，也就是前端那一层。README 没有进一步说明注释在没有花括号的普通提示词里是否同样生效，我们不替它下结论——但从排查角度，把注释和花括号当成同一套机制去查，方向不会错。

实际用法上，// 适合在多行提示词里给自己留标记（哪一段是主体、哪一段是风格、哪一段是从别处抄来的），/* */ 适合临时把一整段提示词「关掉」做 A/B 对照，比删掉再粘回来安全。要注意的是：既然注释很可能是前端处理的，那你在别的地方（比如通过本地 API 直接把提示词喂给后端）复用同一段文本时，就不能默认注释一定会被剥掉。这一点 README 没有交代，属于需要你自己先验证的边界。

embedding：目录、前缀、以及可以省略的扩展名

用法只有一句：把 textual inversion 概念或 embedding 文件放进 models/embeddings 目录，然后在 CLIPTextEncode 节点的文本里写 embedding:embedding_filename.pt。README 明确说扩展名 .pt 可以省略。

三个容易忽略的点：

一是它是写在提示词文本里的，不是一个独立节点。你不需要去找什么「加载 embedding」的节点，就在正常写提示词的地方插进去。这也意味着 embedding 引用属于「节点这一层」，和括号权重同组，而不是前端那一层。

二是目录是固定的 models/embeddings。README 在模型目录那一节里把几个位置分得很清楚：小模型放 models/checkpoints，VAE 放 models/vae，embedding 放 models/embeddings，TAESD 预览解码器放 models/vae_approx。如果你的模型不在 ComfyUI 目录下，README 给的做法是把 extra_model_paths.yaml.example 改名为 extra_model_paths.yaml 再编辑，用它设置额外的模型搜索路径、和其它 UI 共享模型；standalone windows 构建里这个文件就在 ComfyUI 目录下。

三是冒号后面跟的是文件名，不是随便一个别名。名字对不上就等于没引用。省略扩展名是允许的，但省略之后你更要确认目录里那个文件到底叫什么——写错了不会有语法报错，它就是个普通字符串。

出问题时的分诊表

把上面几节压缩成一条决策路径：

• 现象和括号、embedding 有关（权重不对、embedding 没生效）→ 落在文本编码节点这一侧，先核对提示词字面、models/embeddings 里的文件名、以及是不是漏了转义。这一层的排查基本不需要动启动参数。
• 现象和花括号 有关（随机不生效）→ README 明写归前端，先核对前端版本（v0.31.0 的 requirements.txt pin 的是 comfyui-frontend-package 1.48.7），再决定要不要用 --front-end-version 切版本；确认是 bug 就按 README 的建议提到 Comfy-Org/ComfyUI_frontend 仓库，而不是主仓库。
• 现象和注释 有关（注释被当成正文）→ 按 README 把注释挂在动态提示名下的写法，很可能也在前端这一层，按上一条同样的顺序查；但这一条是推论，如果查完前端仍无解释，别继续在这个方向上钻。
• 现象是「改了参数没反应 / 结果和上次一样」→ 先回到执行模型的两条规则：只有输出端输入齐全的部分会执行，只有相对上次变化的部分会执行。想强制全量重跑，comfy/cli_args.py（v0.31.0）里配套的参数是 --cache-none，它的语义是把 RAM/VRAM 占用压到最小，代价就是每次运行都重新执行每个节点——所以它是排查手段，不是日常配置。
• 想找回某次的完整配置 → README 说把生成出来的 png 拖到网页上（或加载它），会得到完整的工作流，包括当时用的 seed。但请记住上面第一条推论：seed 回来了，花括号那一次抽中的词不一定还原得出来，所以关键提示词别全靠花括号随机。

最后提醒一句版本纪律。上面这几条都是 v0.31.0（核对日 2026-08-09）README 的口径，而主仓库里的前端每两周更新一次、独立仓库还有每日发布，具体由哪一版前端实现、行为有没有细微变化，只能以你手上那一版为准——我们没有跨版本比对过这些规则，也不替你断言它们从来没变过。把上面这套「哪一层负责哪条语法」的分诊逻辑记住，比背住某一版的具体行为更耐用。

延伸阅读

• 为什么改了参数它不重跑：ComfyUI 局部重执行机制怎么读
• 采样预览不显示，先看这个参数
• ComfyUI 改一次提示词就重载一次模型：缓存模式与局部重执行的排查路径

---

本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、 release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0； 文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。 参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。