FLUX.1 Kontext 本地改背景不崩脸-知了AI

为什么”改背景就崩脸”是本地编辑的世纪难题

一个看似简单、实际极难的需求

“只改背景、人物不动”——这句话听起来像是一个一行代码就能解决的问题，但在图像生成领域，它是过去两年困扰所有 ComfyUI 用户的经典难题。无论是用 inpaint 硬抠蒙版，还是用各种局部重绘方案，人物的脸、发型、服装边缘总会在几轮迭代之后悄悄漂移，直到你认不出最初的那张图。FLUX.1 Kontext 的出现，第一次让”一句指令式编辑”在本地成为可靠的工作方式，但前提是你必须真正理解它的机制，而不是把它当成普通文生图模型来用。

Kontext 到底是什么：指令式图像编辑模型

FLUX.1 Kontext 是 Black Forest Labs 推出的指令式图像编辑模型系列。它的工作范式与传统的文生图完全不同：你给它一张参考图加一句英文指令，例如 She is now holding an orange umbrella and smiling，它就只改指令中描述的部分，其余尽量保持不变。在 ComfyUI 中，开源可本地部署的版本是 FLUX.1 Kontext Dev，官方在工作流模板中直接提供了 Flux.1 Kontext Dev 模板。本文所有实验基于 ComfyUI v0.3.42 与 RTX 4090（24GB 显存），模型使用推荐的 flux1-dev-kontext_fp8_scaled.safetensors（约 11GB）。

本文承诺与不承诺什么

承诺：按本文操作，你可以在 12GB+ 显存的卡上本地跑通 FLUX.1 Kontext Dev，并掌握一套让多轮迭代”不崩脸”的纪律。不承诺：FLUX.1 Kontext 会永远不漂移——这是最重要的预期管理。Kontext 的真正优势不是”永久不崩脸”，而是可回退：每一轮修改都有明确的上下文，且你随时可以回到上一张干净的输出。理解这一点，是你用好 FLUX.1 Kontext 的第一步。

机制详解：为什么 FLUX.1 Kontext 能”锚住”身份

参考图走的是潜空间，不是文本编码器

这是全文最关键的一段，请务必读透。与 Qwen Image Edit 或 Krea 2 不同，FLUX.1 Kontext 没有独立的视觉文本编码器去”读图”。Qwen Image Edit 内部有一个视觉分支，可以直接理解图像内容并写入条件；而 FLUX.1 Kontext 的参考图信息，只能通过一条链路进入模型：

LoadImage：载入参考图；
FluxKontextImageScale：把参考图缩放并填充到 FLUX.1 Kontext 训练时见过的分辨率档位；
VAEEncode：把参考图编码进潜空间；
ReferenceLatent：把编码后的参考潜变量合并进正向 conditioning，再送入采样器。

这条 ReferenceLatent 链是唯一携带参考图信息的路径。链上任何一环断开——FluxKontextImageScale 没接、VAEEncode 没跑、ReferenceLatent 没合并进 conditioning——模型就退化成纯文生图，根本没有身份可以锚定。很多人抱怨”Kontext 不听话、图跟参考完全不像”，排查到最后发现是这条链没接对。记住：FLUX.1 Kontext 的身份锚定不是魔法，是一条具体的节点链。

FluxKontextImageScale 为什么必须用

训练分辨率档位的约束

FLUX.1 Kontext 在训练时只见过一组特定的长宽比档位。如果你的参考图是手机随手拍的 4032×3024，直接进 VAEEncode，得到的潜变量分辨率不在模型熟悉的档位上，输出就会出现身份变形或裁切。FluxKontextImageScale 节点的作用就是把任意输入图缩放并填充到最近的合法档位，本文实测使用 1024×1024 档位。

跳过它的两种典型后果

后果一：身份变形

脸部比例微妙地不对，五官位置发生”整体压缩”，尤其是长图或宽图输入时最明显。这种变形在第一轮可能不明显，但会随着迭代轮数累积放大。

后果二：边缘裁切

构图边缘的元素（手臂、产品包装的一角、背景中的招牌）被悄悄切掉。你以为模型”理解”了你的图，其实它看到的是一张被隐式裁切过的图。

提示词只管变化，潜变量承载身份

理解了上面这条链，你就能理解 FLUX.1 Kontext 的分工哲学：参考潜变量负责”是什么”，文本提示词负责”改什么”。文本编码用标准 CLIPTextEncode（T5-XXL + CLIP-L 组合），它与参考潜变量一起构成 conditioning。”不崩脸”的本质，是身份信息主要来自潜变量这条通路，文本指令只需要描述变化，不需要重复描述要保留的东西——但如后文所述，适当的保留项前置声明仍能显著提升稳定性。这个机制层面的理解，比背一百条提示词技巧都重要。

环境搭建：从零跑通 FLUX.1 Kontext Dev

模型文件与放置位置

FLUX.1 Kontext Dev 需要三个部件，放置位置必须准确，否则加载器里选不到文件：

部件	推荐文件	放置目录	大小	显存要求
Diffusion Model	`flux1-dev-kontext_fp8_scaled.safetensors`	`models/diffusion_models/`	约 11GB	12GB+（最低 11GB）
Diffusion Model（完整精度）	`flux1-kontext-dev.safetensors`	`models/diffusion_models/`	约 24GB	24GB+
VAE	`ae.safetensors`	`models/vae/`	—	—
文本编码器	`clip_l` 与 `t5xxl`	`models/text_encoders/`	—	—

放好后刷新模型列表或重启 ComfyUI，确认每个加载器都能选到对应文件。找不到模型时，优先检查文件夹、文件名和下载完整性。

打开官方工作流模板

更新 ComfyUI 到最新版本（本文使用 v0.3.42），在 Workflow Templates 中找到官方的 Flux.1 Kontext Dev 模板并打开。这个模板已经把 LoadImage → FluxKontextImageScale → VAEEncode → ReferenceLatent 的完整链路接好，是最不容易出错的起点。强烈建议新手直接从模板改，而不是从零拼节点——因为 ReferenceLatent 的接线方式对新手来说不直观，漏接一条线就会退化成文生图。

基准参数与显存配置

本文实测的参考参数：1024×1024、steps 20、guidance 2.5。在 RTX 4090（24GB）上，这套参数可以稳定运行。如果你的显存更紧张，可以参考下表做取舍：

显存档位	推荐配置	说明
24GB+	完整精度 24GB 模型或 FP8，1024 档位，T5 常驻	体验最佳，迭代速度最快
12GB–24GB	`flux1-dev-kontext_fp8_scaled.safetensors`（11GB，最低显存 11GB），1024 档位	FP8 模型质量与速度的平衡点，本文推荐
12GB 以下	评估 GGUF 量化版、启用 offload，或降低分辨率	速度明显下降；预算允许时改用 API 更省心

核心实操：一句”只改背景、人物不动”的完整接线

节点链逐段拆解

第一段：图像入口

从 LoadImage（或 Load Image (from output)）载入你的参考图。这一步之后立即保存这张未编辑的基准图——它是你整个迭代流程的”创世备份”，后面所有轮次的回退终点都指向它。很多人跳过这一步，等发现第 8 轮已经崩了，却找不到第 3 轮那张干净图。

第二段：分辨率归一

LoadImage 输出接入 FluxKontextImageScale。这一节点不是可选优化，而是必选项，原因见前文机制部分。任何跳过它的接线，都是在给身份漂移埋雷。

第三段：潜变量编码与条件合并

VAEEncode

用 ae.safetensors 把归一后的参考图编码进潜空间。确保 VAE 加载器选中的就是 models/vae/ 下的 ae.safetensors，不要混用其他模型的 VAE。

ReferenceLatent 合并进 conditioning

ReferenceLatent 节点接收两个输入：标准 CLIPTextEncode（T5-XXL + CLIP-L）产出的正向 conditioning，以及 VAEEncode 产出的参考潜变量。它的输出才是真正送入采样器的正向条件。负向 conditioning 走独立的 CLIPTextEncode，不接 ReferenceLatent。请对照模板逐一确认这三条连线，缺一条身份就会丢失。

只改背景的英文提示词模板

ComfyUI 原生 Kontext Dev 工作流中的 CLIP Text Encode 提示词目前只支持英文，直接写英文指令。以下是本文实测有效的”只改背景”模板，可直接复制：

Keep the person's face, hairstyle, pose, and framing unchanged.
Replace the background with a sunlit modern office with large windows.

再给几个不同场景的变体：

Keep the identity, pose, and framing unchanged.
Change the background to a snowy mountain landscape at dusk.

Keep the subject's face, clothing, and position unchanged.
Replace the background with a blurred city street at night.

注意模板结构：保留项前置（Keep … unchanged 开头），再写修改内容（Replace / Change / Add 开头）。模型对 conditioning 开头的声明权重更高，这个顺序不是装饰，是实打实影响输出稳定性。

官方示例的语法特征

官方给出的示例 She is now holding an orange umbrella and smiling 揭示了 FLUX.1 Kontext 提示词的三个语法特征：单条陈述式指令、祈使语气、一次只描述一个修改点。它不是对话，不是描述整个画面，而是一条”编辑命令”。这个心智模型请贯穿你所有的提示词写作。

提示词写法：FLUX.1 Kontext 的语言契约

单条陈述式指令：一次只改一件事

什么是好的指令

好的 FLUX.1 Kontext 指令是单一、具体、主动的陈述：”把背景换成 X”、”给她加一把橙色雨伞”、”移除画面左侧的水印”。每条指令只描述一个修改点，模型才有明确的优化目标。

什么是坏的指令

复合提示词——”改 A、加 B、删 C”——是最典型的反模式，会导致漂移：模型在多个变化目标之间分配注意力，结果每个变化都做不干净，还把不该动的部分一起搅动。同理，被动语态（”the background was replaced with…”）的可靠性明显更低，请一律用主动祈使句。

保留项前置：用开头声明锁住不动的部分

以 Keep [identity/pose/framing/brand] unchanged. 开头，再写修改内容。例如改背景时，保留项通常包括脸、发型、姿势、构图；改商业物料时，务必把 Logo 与标签声明为不变项。这个技巧利用了模型对 conditioning 开头内容的更高敏感度，成本为零、收益显著，请固化成习惯。

长宽比与多图限制的硬约束

两个必须知道的硬约束：其一，长宽比要从 FLUX.1 Kontext 支持的枚举值里选，不在列表内的值会被裁切或直接返回 422 错误；其二，FLUX.1 Kontext 只支持单张参考图，不支持多图。想”参考 A 的脸 + B 的服装”这种多图融合任务，Kontext Dev 本地版做不到，请直接转向 LoRA 或 IPAdapter 方案。

迭代纪律：八步法，让每一轮都”可回退”

完整八步清单（可复制）

更新 ComfyUI，打开 Workflow Templates 中的 Flux.1 Kontext Dev 模板。

放好 diffusion model / VAE / CLIP-T5 编码器，刷新或重启，确认加载器能选到文件。

Load Image (from output) 载入授权或自有图，保存这张未编辑的基准图。

在 CLIP Text Encode 用英文写明要改的对象，并列出必须保持不变的脸、姿势、比例或构图。

保存第一轮输出，检查脸、发型、Logo、材质、位置、清晰度，通过后才作为下一轮输入。

按背景 → 服装或配饰 → 轻微动作 → 光照或风格的顺序推进，每轮只改一个主要维度。

一旦脸、产品比例、Logo、清晰度明显变差，回到上一张干净输出，缩小改动范围重试。

需要长期复用角色、严格锁脸或精确姿势时，分别评估 LoRA、FaceID 类方案、ControlNet。

为什么”背景先行”的顺序不能乱

变化幅度决定漂移风险

背景替换是幅度最大、但离主体最远的修改，此时身份信息还处于最”新鲜”的状态，模型锚定力最强。如果反过来先做轻微动作或光照调整，潜变量已经携带了一轮编辑的痕迹，再做大幅度背景替换时漂移概率显著上升。FLUX.1 Kontext 的迭代不是无序的，顺序本身就是风控。

每轮验收标准

每一轮输出必须过一遍检查：脸是否与上一轮一致、发型是否走样、Logo 与标签是否完好、材质是否退化、物体位置是否漂移、整体清晰度是否下降。任何一项不合格，本轮输出不得作为下一轮输入。

“可回退”是工程价值，不是妥协

这里要纠正一个普遍的误解：FLUX.1 Kontext 的卖点不是”永不漂移”，而是”每次修改有明确上下文 + 允许回到最近的干净版本”。传统 inpaint 工作流一旦第 5 轮崩了，你往往说不清是哪一轮开始崩的；而 Kontext 的每轮输入输出都有存档，崩了就回退一轮、缩小改动重试，损失被限制在单轮之内。把这套”回退 + 缩小改动”当成标准操作流程，你的成品率会远高于那些幻想”一次调好”的用户。

大多数人做错的地方：五个反模式与纠正

反模式一：把 Kontext 当文生图用

最大的错误不是提示词写得差，而是 ReferenceLatent 链根本没接对。记住前文结论：这条链是唯一携带参考图的路径，任何一环断开，FLUX.1 Kontext 就退化成纯文生图。症状很典型：输出与参考图毫无关系、换什么提示词都像在凭空生成。先查链，再查词。

反模式二：一上来就堆复合指令

新用户最爱写”把背景换成海边，加一副墨镜，去掉路人，色调调暖”。这条提示词在 FLUX.1 Kontext 上几乎必然漂移。正确做法是拆成四轮：先背景，再墨镜，再去路人，最后色调——每轮一个修改点、一条保留项前置声明。

反模式三：复用已降质的输出继续迭代

第二常见的错误：第 6 轮输出已经轻微发糊，用户没检查就继续拿去改。降质是累积的，糊上加糊到第 10 轮就是废图。纪律是硬性的：每轮输出过验收，不通过就回退到上一张干净输出。这张”干净中间图”的价值，胜过任何参数调优。

反模式四：中文提示词直译硬塞

原生工作流的 CLIP Text Encode 只支持英文，把中文句子机翻成生硬英文（”the background was changed by me to…”）效果很差。直接用 change / replace 等明确动词的主动祈使句，指明具体目标，这是 FLUX.1 Kontext 提示词的语言契约。

反模式五：用 Kontext 硬扛它不擅长的事

FLUX.1 Kontext 是编辑器，不是万能锁。严格锁脸请用 FaceID 类方案（且需肖像授权）；精确姿势与构图约束请用 ControlNet；同一角色的长期批量生产请训练 LoRA。用错工具再怎么调提示词都救不回来——这一点在后文选型章节展开。

故障排查表：症状、先查什么、下一步

完整排查表（可复制）

症状	先查什么	下一步
加载器里找不到模型	文件夹、文件名、下载完整性	刷新模型并重启
提示词几乎没效果	英文措辞、是否指明具体目标	用 change / replace 明确陈述
背景一改脸也变了	一次改的维度太多	补上脸、发型、姿势的不变项声明
每轮越来越糊	复用了已降质的输出	回到上一张干净的中间图
产品 Logo 变了	Logo 与标签没声明为不变项	缩小改动范围，人工复核
构图或姿势漂移	这个任务需要结构控制	换用或叠加 ControlNet
显存不足	FP8、T5、分辨率、多余节点	评估 GGUF、offload 或改用 API

两类高频故障的深入分析

输出与参考图毫无关系

这是 ReferenceLatent 链断裂的典型信号，不是提示词问题。按 LoadImage → FluxKontextImageScale → VAEEncode → ReferenceLatent → 采样器的顺序逐节点检查连线。重点确认 ReferenceLatent 的输出确实接入了采样器的正向 conditioning 输入，而不是被旁路了。

422 错误或输出被裁切

检查长宽比枚举

422 多数来自请求参数不在支持的长宽比枚举内。在 ComfyUI 本地工作流中，对应症状是 FluxKontextImageScale 之后分辨率仍落在非法档位——通常是你绕过了这个节点。回到模板默认的 1024×1024 档位即可恢复。

检查参考图原始分辨率

极端长宽比的输入图（全景图、长截图）即使过了 FluxKontextImageScale，填充比例过大也会损失信息。建议先用外部工具把这类图裁到接近目标档位再进工作流。

工具选型判断：什么时候该放弃 FLUX.1 Kontext

五大场景对照表（可复制）

需求场景	首选方案	理由
短期的背景 / 服装 / 局部 / 概念编辑	FLUX.1 Kontext	指令式编辑最顺手，无需训练
长期生产复用同一角色或风格	LoRA	训练一次，权重固化身份，不受迭代漂移影响
主需求就是”同一张脸”	FaceID 类工具	专为身份保持设计（需肖像授权）
姿势、轮廓、构图必须精确约束	ControlNet	结构控制是 Kontext 没有的能力维度
从参考图注入风格或主体条件	IPAdapter	风格与主体迁移是它的主场

判断标准：任务时长与精度要求

短期任务：Kontext 是效率之王

一次性、十轮以内的编辑任务——改个背景、换个服装、做个概念图——FLUX.1 Kontext 的启动成本几乎为零，不用训练、不用配蒙版，写一条英文指令就能开工。这是它不可替代的价值区间。

长期任务：漂移累积会吃掉优势

一旦任务跨越几十轮、需要跨天跨项目复用同一角色，FLUX.1 Kontext 的迭代漂移即使有回退纪律兜底，累积成本也会超过一次 LoRA 训练。此时的正确做法是：Kontext 用于前期探索和风格尝试，锁定方向后转 LoRA 固化。

混合策略：Kontext + 其他工具的组合拳

高级用户的典型工作流是组合拳：用 FLUX.1 Kontext 快速探索构图与背景方案 → 用 ControlNet 锁定最终姿势与轮廓 → 需要批量出同一角色时训练 LoRA。Kontext 在这条链路里的定位是” ideation 层”，而不是”生产线终端”。认清定位，才不会对它产生不切实际的失望。

许可与合规：本地跑 Kontext Dev 的法律边界

权重许可与输出用途

FLUX.1 Kontext Dev 权重受 FLUX.1 dev Non-Commercial License 约束。需要注意的关键区分：模型卡说输出可用于个人、科研与商业用途，但这不等于可以把 Dev 权重放进付费服务。换句话说，你用本地 Dev 跑出的图拿去商用，通常没问题；但把 Dev 权重部署成一个对外收费的服务，就触碰了许可红线。

Pro / Max 与 API 路线

如果业务需要把 FLUX.1 Kontext 能力集成进产品，正规路径是 Pro / Max 等 API 产品，条款取决于服务商，通常明确覆盖商用集成。个人创作者和本地实验者用 Dev 完全够用；规模化、多用户、对外收费的场景请走 API，这既是合规问题，也是显存经济的现实选择。

Kontext 的定位：不是万能改图，而是可控迭代

把 Kontext 当”万能改图器”是常见的误用。Kontext 的能力边界很清晰：它擅长在保留主体身份的前提下做局部替换与场景迁移，不擅长从零生成新构图，也不擅长一次改多个维度。认清这一点，Kontext 的价值才会显现出来——它是一台”可回退的迭代机器”，不是”许愿机”。

在 ComfyUI 里跑 Kontext，最该建立的习惯是”每轮只改一件事”。这个纪律听起来笨，实际是 Kontext 用出效果的关键：一轮改背景，下一轮改服装，再下一轮调光线。每轮结束都把输出存下来当下一轮的输入，同时保留一张原始基准图。一旦发现脸开始漂，退回上一张干净版本，把改动范围缩小，重跑。这套流程看起来慢，实际比”一次写一大串要求然后全崩”快得多。

另一个容易被忽略的点是 Kontext 的提示词语言。ComfyUI 原生 Kontext 工作流的 CLIP Text Encode 目前只吃英文，中文提示词在这个节点上不会正常生效。这不是模型能力问题，而是这条工作流的文本编码器配置决定的。写英文指令时也不用追求文学性，祈使句加保留项声明就够了，越直白越稳。

FAQ：六个高频问题

FLUX.1 Kontext Dev 最低需要多少显存？

最低 11GB（使用 FP8 模型 flux1-dev-kontext_fp8_scaled.safetensors，约 11GB），官方建议 12GB+ 显存以获得流畅体验。完整精度模型约 24GB，需要 24GB+ 显存。显存更紧张时评估 GGUF 量化、offload 或改用 API。

为什么我的 FLUX.1 Kontext 输出和参考图完全不像？

九成情况是 ReferenceLatent 链断了。Kontext 没有独立的视觉文本编码器读图，参考图只能通过 FluxKontextImageScale → VAEEncode → ReferenceLatent 这条链进入模型，任何一环断开就退化成纯文生图。逐节点检查连线，确认 ReferenceLatent 输出接入了采样器的正向 conditioning。

可以用中文提示词吗？

ComfyUI 原生 Kontext Dev 工作流中的 CLIP Text Encode 提示词目前只支持英文，直接写英文指令。用 change / replace 等明确动词的主动祈使句，保留项前置（Keep … unchanged），一次只描述一个修改点。

FLUX.1 Kontext 支持多张参考图吗？

不支持。只支持单张参考图。需要”参考 A 的脸 + B 的服装”这类多图融合，请转向 LoRA 或 IPAdapter 等方案。

迭代多少轮会崩？有上限吗？

没有固定轮数上限，但有累积规律：每轮只改一个维度、保留项前置声明齐全、每轮输出过验收、不达标就回退，十几轮也能稳住；反之复合指令 + 复用降质输出，三四轮就可能崩。Kontext 的优势是可回退，不是永不漂移。

本地跑出的图可以商用吗？

FLUX.1 Kontext Dev 权重受 FLUX.1 dev Non-Commercial License 约束；模型卡说明输出可用于个人、科研与商业用途，但不等于可以把 Dev 权重放进付费服务。要做对外收费的产品集成，请使用 Pro / Max 等 API 产品，条款取决于服务商。

采样与出图参数：FLUX.1 Kontext 的稳定区间

参考参数的来龙去脉

本文实测采用的参考参数是 1024×1024、steps 20、guidance 2.5。这三个数字不是随手填的，而是一个经过验证的稳定区间：1024×1024 对应 FluxKontextImageScale 归一后的合法档位，潜变量分辨率落在 FLUX.1 Kontext 训练分布的中心；steps 20 在编辑任务上已经足够收敛，更多步数对身份保持没有实质帮助，反而拉长每轮迭代时间，让你更不愿意执行”每轮验收”纪律；guidance 2.5 是低 CFG 值，这是 FLUX 系列的共性——guidance 拉太高会过度放大文本条件的权重，压缩参考潜变量的影响空间，直接后果就是脸开始漂。

参数调优的优先级

先调提示词，再调参数

很多用户一看到崩脸就跑去改 steps 和 guidance，这是本末倒置。在 FLUX.1 Kontext 上，影响输出稳定性的因素排序是：ReferenceLatent 链完整性 > 提示词结构（保留项前置、单一修改点）> 分辨率档位 > guidance > steps。前两项不出错时，默认参数几乎不需要动。把参数当成最后手段，你会省下大量时间。

guidance 的危险区

低于 2 的风险

guidance 过低（如 1.0–1.5）时，模型对文本指令的服从度下降，可能出现”指令没执行”的输出——背景根本没换。此时不要加大修改幅度，先把 guidance 回调到 2.5 附近重试。

高于 3.5 的风险

guidance 过高（3.5 以上）时，文本条件挤压参考潜变量的话语权，身份漂移概率明显上升。如果你发现”指令执行得很彻底但脸变了”，第一反应就应该是降 guidance，而不是重写提示词。

批量出图与种子策略

编辑类任务与文生图不同：同一参考图 + 同一指令的多次采样，结果差异远小于文生图。实践中建议每轮固定跑 2–4 张、挑验收通过的那张进入下一轮，并为每张记录种子。一旦某轮全军覆没，可回退上一张干净输出并更换种子重试——种子是”缩小改动范围重试”这个动作里最廉价、最有效的变量。

提示词进阶：从”能跑”到”稳定复现”

动词库与指令措辞速查

FLUX.1 Kontext 对动词的选择有明显的敏感度差异。实测可靠的动词按用途归类如下：

替换类：replace、change、switch ... to —— 适合背景、服装整体替换；
增补类：add、give her/him ... —— 适合新增配饰、道具（如官方示例的橙色雨伞）；
删除类：remove、delete —— 适合去水印、去路人，指令中要指明位置（”the watermark in the top-left corner”）；
调整类：make the lighting warmer、change the color of ... to ... —— 适合光照与颜色微调，通常放在迭代后期。

不要使用被动语态（”the background was replaced with…”），可靠性明显更低；也不要用疑问句式或对话式措辞，FLUX.1 Kontext 的提示词是命令，不是聊天。

描述”位置”与”范围”的技巧

位置词让指令更精准

删除类与修改类指令中，加入明确的位置限定词能显著降低误伤率：in the background、on the left side、behind the person、at the top of the frame。没有位置限定的 remove the person 可能把画面主体也一起处理掉，而 remove the person in the background behind her 则目标明确。FLUX.1 Kontext 的条件注入是全局的，你的措辞越局部化，改动就越局部化。

范围词防止过度编辑

only / just 的保护作用

在修改句中加入 only（如 Change only the background）是一层廉价保险，配合保留项前置声明形成双重约束。实测中这类范围词对产品图、电商图等”主体绝不能动”的场景尤其有效。

商业物料场景的保留清单

处理带 Logo、标签、包装的产品图时，保留项前置声明应覆盖：品牌 Logo、文字标签、产品比例、包装材质、标签清晰度。任何一项漏写都可能被模型”顺手重绘”——FLUX.1 Kontext 生成文字细节的能力有限，Logo 变形是商业场景最高频的翻车点，务必每轮人工复核。

一个完整的五轮迭代提示词实例

以下是一个电商场景的真实迭代序列，展示”单一修改点 + 保留项前置”如何贯穿始终：

Round 1（背景）:
Keep the product, its label, and its position in the frame unchanged.
Replace the background with a clean white studio backdrop with soft shadow.

Round 2（道具）:
Keep the product, its label, and the white studio backdrop unchanged.
Add a green leaf beside the product on the right side.

Round 3（光照）:
Keep the product, its label, the backdrop, and the leaf unchanged.
Make the lighting brighter with a subtle warm tone.

Round 4（氛围）:
Keep everything in the composition unchanged.
Change only the backdrop color to a soft mint gradient.

Round 5（细节收尾）:
Keep the product, its label, and the composition unchanged.
Make the label slightly sharper and cleaner.

注意每一轮的保留项都在累加前几轮的成果——背景在第 2 轮起进入保留清单，道具在第 3 轮起进入保留清单。这就是 FLUX.1 Kontext 迭代编辑的核心节奏：已完成的成果，立刻固化为下一轮的保留项。同时，每一轮输出都单独存档（round1.png、round2.png……），这是”可回退”原则在文件管理上的落点。

身份漂移的微观机制：漂移从哪里开始

漂移不是突变，而是累积

理解 FLUX.1 Kontext 的一个关键认知修正：身份漂移不是某个阈值上的”崩坏事件”，而是一个随迭代轮数单调累积的过程。每一轮编辑，模型都从上一轮的输出图重新编码潜变量，这个再编码过程会引入微小的重建误差——脸的轮廓、发丝的纹理、眼睛的高光，每一轮都丢失一点点。单轮看不出来，五轮对比图、十轮对比图就能看出”人像被轻轻重画过”。这就是为什么本文反复强调每轮存档与验收：你不是在对抗一次故障，而是在管理一条误差累积曲线。

哪些修改类型最伤身份

按风险从高到低排序

基于本文在 RTX 4090 上的实测，各类修改对身份稳定性的影响大致排序如下：

整体风格转换（如转成油画、动漫风）：风险最高，风格条件与身份信息竞争最激烈；
大幅度光照重构：强逆光、夜景会迫使模型重绘面部细节；
服装全身替换：改动范围贴近面部边界时风险上升；
配饰增补（雨伞、墨镜）：局部改动，风险较低——但墨镜会遮挡眼部，属于例外；
背景替换：风险最低，与主体在构图上分离，这正是”背景先行”顺序的依据。

高风险任务的对策

风格转换：降预期或换工具

需要整体风格转换时，不要指望 FLUX.1 Kontext 十轮内保持同一张脸。合理做法是：用 Kontext 做一轮风格转换拿到方向稿，然后立即切换到 LoRA 或 FaceID 类方案锁定身份。把风格转换放在迭代序列的最后一步也是一个实用策略——即使身份有轻微变化，也不会污染后续轮次。

墨镜类遮挡：单独成轮并放宽验收

给人物加墨镜、口罩这类遮挡面部的配饰时，眼部信息被物理遮挡，模型对”脸没变”的还原度天然受限。这类修改应单独成轮，验收标准也要相应放宽为”下半张脸与脸型一致”，不要苛求完全像素级一致。

验收的实操方法：并排对比，而非凭记忆

最后一项工程建议：不要凭记忆判断”脸有没有变”。人眼对陌生面孔的记忆极其不可靠，两轮间隔十分钟你就已经记不清了。正确做法是把上一轮输出与本轮输出并排放进图片查看器，重点对比瞳距、鼻翼宽度、下颌线与发型边缘四处。养成这个 30 秒的习惯，你就能在漂移的最早阶段截住它，而不是在第 8 轮才惊觉整批图作废。

结语前的最后一张检查单（可复制）

ReferenceLatent 链四节点完整：LoadImage → FluxKontextImageScale → VAEEncode → ReferenceLatent。

提示词为英文，保留项前置，单一修改点，主动祈使句。

基准图与每轮输出均已单独存档，文件名带轮次编号。

顺序为背景 → 服装或配饰 → 轻微动作 → 光照或风格。

guidance 在 2.5 附近，steps 20，分辨率 1024×1024。

每轮并排对比瞳距、鼻翼、下颌线、发型边缘四处再放行。

任务性质超出编辑范畴时，已评估 LoRA / FaceID / ControlNet / IPAdapter。

结语：把 Kontext 当成”有存档的编辑器”

回到标题那句话：”只改背景、人物不动”。FLUX.1 Kontext 能做到，靠的是 ReferenceLatent 潜变量承载身份、提示词只管变化这个机制分工；而它能持续做到，靠的是你的迭代纪律——基准图存档、每轮验收、背景先行、可回退优先。本地跑通 FLUX.1 Kontext Dev 不难，难的是把它放进一个有工程纪律的工作流。愿你的每一轮迭代，都有退路。

THE END