在画同人、角色设定或者概念设计的时候遇到“把某个角色换成另一种画风”的需求是很常见的但真正动手做的人会发现这个操作远比想象中容易翻车。尤其当你手上有一个明确角色、想从旧画风平滑切到新画风时翻车概率几乎是百分之百。我最近就在一个内部练习项目「Ontology 单人向」里踩了这个大坑。项目目标很简单用 AI 绘画工具生成一个角色“Ontology”的单人立绘并比较旧画风与新画风的差异。听起来很简单但实际结果却不忍直视可以称得上是我做过最失败的一次绘图实验。这件事真正有意思的地方在于失败不是偶然而是暴露了 AI 绘画中“画风切换”和“角色一致性”这对矛盾在真实工程场景里有多难处理。本文不是一篇纯翻车吐槽也不是简单的“我试了A模型和B模型”。我会把这次失败拆成技术问题来做一次完整复盘画风在模型层面到底是什么为什么新旧画风切换会翻车如何用可控的工作流把失败率降下来以及如果放到工程里应该怎么沉淀这次经验。如果你也经常用 Stable Diffusion 或 ComfyUI 做角色向生成这篇文章应该对你有用。1. 这次复盘要回答的问题1.1 一个看起来“翻车”的生成结果先描述一下当时的场景。项目名「Ontology 单人向」目标是围绕“Ontology”这个角色制作一组图像要求人物形象一致但画风从旧画风迁移到新画风。这里所谓的“旧画风”指那些偏经典、偏厚涂、层次感强但线条较松的风格“新画风”则指向线稿干净、高饱和、光影简约、接近现代商业立绘的风格。第一次尝试时我用同一组提示词只是把模型从旧底模换成了新底模结果出现了几个非常典型的问题角色脸部完全变样和原始设定对不上衣服结构随机崩坏飘带、肩甲和装饰物互相穿模风格没有统一画面出现“半旧半新”的混搭感背景和角色不在同一图层像硬拼上去的同一 Seed 下重跑结果依然不稳定。从产品角度看这组图属于完全不可用的状态。但问题是生成失败的规律非常明显这说明背后一定存在可解释的技术原因而不是单纯“运气不好”。1.2 真正值得拆解的变量很多人遇到这种情况会立刻归结为“模型不行”然后换一个模型重试。这是最容易踩的误区。这次失败涉及的变量远比“模型好坏”多底模本身的风格先验提示词里的风格描述与底模是否匹配局部重绘、图生图、ControlNet 等控制手段是否介入角色一致性是否依赖 LoRA / 参考图 / 人物特征描述采样器、CFG、步数等参数是否针对当前模型调优图片尺寸、高清修复、重绘幅度也会影响画风表现。如果只看到“旧画风到新画风”这一层你就永远无法解释为什么换了模型之后角色会跟着崩掉。真正要回答的问题是画风迁移过程中如何把“风格变量”和“角色变量”解耦。1.3 适合阅读本文的读者这篇文章面向这几类读者用 Stable Diffusion WebUI 或 ComfyUI 做角色设计、同人图、游戏原画概念图的创作者团队里需要维护角色一致性的 AI 绘图工作流负责人对“画风迁移”“风格一致性”“角色一致性”比较困惑的 AI 绘画进阶用户想把 AI 绘画生成能力沉淀成可复用工程资产的技术人员。如果你只是随便玩玩随手生成几张图那这篇文章可能偏重。但如果你经历过“同一个角色换画风就换脸”的痛苦那下面的内容应该会帮你省下大量试错时间。2. AI 绘画里的“画风”到底是什么2.1 画风不是滤镜而是模型先验在 AI 绘画里我们常说“这个模型画风好”其实不是在夸某个滤镜。画风的本质是模型在训练阶段见过的图像分布决定了它对“什么是好看的图”的先验理解。以 Stable Diffusion 系列模型为例底模的权重里包含了海量图文对。底模学到的不仅是“猫有四条腿”还包括“商业插画应该长什么样”“厚涂原画的边缘和配色通常如何组织”。这些偏向会以隐式方式驻留在 UNet 的交叉注意力层和噪声预测器里最终表现为不同模型在相同提示词下的构图、配色、线条和材质倾向差异。所以画风迁移其实就是模型先验的迁移。旧画风模型长于体积感、笔触感和光影层次新画风模型则偏向整洁线条和通透色彩。两者在潜空间里的概率分布不同对提示词中关键词的激活方式也不同。2.2 新旧画风的真实区别拿“旧画风”和“新画风”放在一起对比从技术上看至少有四层差异维度旧画风传统厚涂/经典原画新画风现代商业立绘线条边缘弱化以光影塑形线条清晰闭合度高色彩低饱和倾向冷暖对比强高饱和通透大面积平涂光影多光源层次细腻单主光源简化阴影细节策略材质与结构并重优先保证轮廓和辨识度这四层差异会直接影响模型对提示词的响应。你在旧画风模型下写 detailed lighting 和 soft shadows它会理解成一种细腻的古典光照但在新画风模型下同样的词可能只会触发轻微的渐变阴影。也就是说提示词不变换底模后输出画风不一致这是非常正常的。2.3 风格切换为什么会失败现在可以回答最开始的问题了为什么“旧画风切换到新画风”容易翻车第一个原因是耦合。你的角色设定和旧画风是共同生长出来的提示词里的很多形容词本身就是旧画风的产物。你把底模换掉但提示词还带着旧画风语境新模型读出来的就不是同一个角色而是一个“被旧提示词绑架的新角色”。第二个原因是多头注意力冲突。生成时的每个 token 都会影响全局特征角色特征、服装结构、背景氛围、画风词汇全都混在同一组 token 序列里。画风词汇会污染角色特征角色特征又会反向压制画风表现。如果没有额外的结构控制两者很难同时满足。第三个原因是缺少锚点。新画风模型不理解你的“Ontology 角色长什么样”它只理解“类似画风的角色通常长什么样”。没有参考图、没有 LoRA、没有 ControlNet 来固定角色锚点那生成结果自然会漂移。所以失败不是“一步没做对”而是“变量分离这步没做”。接下来要做的就是把风格和角色拆开分别控制。3. 环境准备与工具链选择3.1 运行环境在开始实验之前我先说明环境要求。我的实验环境是基于 Linux NVIDIA GPU显存 12GB 以上。因为要在同一个工作流里切换多个模型并进行对比显卡显存不够的话模型加载和切换会很痛苦。如果本地没有 GPU可以考虑云 GPU 实例。但有两个问题要提前注意一是数据管理LoRA、ControlNet 模型、底模体积都不小每次重新上传很浪费时间二是版本一致性云环境偶尔会有预装依赖和你本地不一致的情况到时候报错很难排查。3.2 安装 WebUI / ComfyUI 并启动如果只是做简单的新旧画风对比Stable Diffusion WebUI 就够用了。但考虑到后面要做 ControlNet 和节点式工作流我建议直接使用 ComfyUI它对控制权更透明也更容易沉淀成可复用的工作流 JSON。以下是一个典型的 ComfyUI 安装和启动示例版本细节请以实际项目为准# 进入工作目录 cd ~/work # 拉取 ComfyUI 代码 git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI # 创建 Python 虚拟环境避免污染系统 Python python3 -m venv venv source venv/bin/activate # 安装依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txt # 启动服务 python main.py --listen 127.0.0.1 --port 8188启动后浏览器访问http://127.0.0.1:8188在 Web 界面加载工作流即可。这里真正容易踩坑的地方是 PyTorch 版本和 CUDA 版本不匹配。如果启动时报 CUDA error优先用nvidia-smi检查驱动支持的 CUDA 版本再选择对应的 PyTorch wheel。3.3 模型目录与风格隔离另一个细节是模型目录管理。新旧画风对比实验一定要把底模分清楚否则 ComfyUI 会缓存加载过的模型导致你以为是新模型实际跑的还是旧模型。我的建议是目录里明确区分。底模放models/checkpointsLoRA 放models/lorasControlNet 放models/controlnet并且命名时带上风格标签比如models/checkpoints/old_painterly_v2.safetensors models/checkpoints/new_clean_v3.safetensors models/loras/ontology_char_lora_v1.safetensors这里的关键点在于用文件名把版本和画风信息固化下来。很多人做风格对比时模型命名是model1.safetensors、model2.safetensors跑完三天后根本分不清谁是谁复盘自然也无从谈起。4. 旧画风与新画风的完整生成实验4.1 工作流 A旧画风旧画风的生成目标是保留传统厚涂的层次质感同时保证角色主体清晰。为了让结果可复现我把所有参数固定下来只留风格词汇做变化。这是实验 A 的提示词模板masterpiece, best quality, 1girl, solo, ontology_character, wearing dark armor with gold trim, long white hair, glowing blue eyes, old painterly style, thick brush strokes, dramatic lighting, rich contrast, dark textured background, detailed illustration, depth of field, film grain其中ontology_character是项目内部用来描述角色特征的标签。如果没有任何 LoRA 或嵌入这个标签其实只是一个弱提示模型对它的理解取决于底模训练数据里有没有类似概念所以后面必须引入角色 LoRA 来控制。4.2 工作流 B新画风新画风的目标是干净利落的商业立绘风格强调线条、高饱和和大平涂。masterpiece, best quality, 1girl, solo, ontology_character, wearing dark armor with gold trim, long white hair, glowing blue eyes, modern anime style, clean lineart, bright colors, cel shading, simple gradient background, full body shot, high resolution, sharp focus可以看到角色描述部分完全一样画风词汇和背景描述换了。这样的设计是有意的我们希望对比被限制在“画风”这个变量上而不是连角色的服装和气质都一起改掉。4.3 关键参数对比与出图结果我在两个工作流中分别使用了对应画风的底模并固定以下核心参数参数旧画风实验新画风实验采样器Euler aDPM 2M Karras步数3528CFG6.56.0宽高832x1216832x1216Seed固定固定重绘幅度无无实验结果是如果只看单张生成两个工作流分别都能产出漂亮但风格明显不同的图。问题出在角色一致性上把两张图放在一起几乎看不出是同一个角色。脸型角度不同瞳孔颜色深浅不一致盔甲上的纹样也发生了形变。也就是说独立跑通两种画风不难难的是让同一个“Ontology”在两套画风下保持身份统一。这恰好是我最开始说的“最失败的一次”的核心问题。失败的不是生成了两张风格图而是整组图无法作为一个角色的系列设定使用。5. “最失败的一次”全过程复盘5.1 失败现象记录我按时间顺序记录了几类主要故障第一类直接换模型提示词不变。结果角色被新画风模型重新理解脸部特征漂移到完全不同的程度。第二类提示词里同时保留旧画风描述和新画风描述。结果画面出现风格冲突背景是旧画质的厚涂人物是新画风的干净线稿非常不协调。第三类只加了角色 LoRA但没有固定 Seed 和采样器。结果虽然角色相似度提高了但每次生成的脸部角度和表情不同系列感不足。第四类全参数固定但没有加 ControlNet 姿态控制。结果角色脸部保持一致了但肢体结构出现概率性错误手部和武器穿模严重。5.2 失败原因定位复盘下来这几个问题分别对应不同的技术根因第一类失败的原因是模型先验覆盖了角色特征。新画风模型对“如何画脸”的先验非常强角色特征 token 在交叉注意力层被风格 token 稀释了。第二类失败的原因是提示词冲突。旧画风词汇和新画风词汇在同一序列里激活了互相矛盾的视觉特征注意力机制无法同时满足两个要求。第三类失败的原因是对采样器的理解不足。不同采样器的收敛路径不同DPM 与 Euler a 即使步数相同最终落点也会不同角色 LoRA 只能约束局部特征无法约束全局构图。第四类失败的原因则是姿态不可控。角色一致性不只是“脸像”还包括体态、透视、服装在肢体动作下的形变。没有姿态引导模型会在自由发挥时出错。5.3 从失败到可复现的修正修正思路可以总结成一句话把风格和角色拆分到不同控制层。角色一致性交给 LoRA 参考图 固定 Seed。姿态与构图交给 ControlNet OpenPose / Depth。画风只通过底模切换和风格描述词控制。系列一致性固定采样器、CFG、步数、分辨率。这样做的原因是不同控制层解决不同问题互不干扰。LoRA 负责“这是谁”ControlNet 负责“动作是什么”底模负责“长什么样才算好看”。当这些变量不再混在提示词里互相竞争时新旧画风切换的稳定性会大幅提升。下面是一个修正后的 ComfyUI 关键节点示例{ checkpoint: new_clean_v3.safetensors, lora: { name: ontology_char_lora_v1.safetensors, strength: 0.85 }, controlnet: { module: openpose, model: control_v11p_sd15_openpose.pth, strength: 0.7 }, positive_prompt: ..., negative_prompt: bad hands, extra fingers, deformed, low quality, sampler: dpmpp_2m, scheduler: karras, steps: 28, cfg: 6.0, seed: 20240601 }这段配置的核心价值在于它把“画风由 checkpoint 决定、角色由 LoRA 决定、动作由 ControlNet 决定”的职责分工固化了下来。之后每次切画风只需要替换 checkpoint 和风格提示词角色与动作部分保持不动。6. 稳定复现画风的实践路径6.1 角色锚点怎么做如果你希望角色在新旧画风之间保持一致强烈建议给角色炼制一个 LoRA。这个 LoRA 应当只学习角色本身的特征而不是学习某个画风。使用角色图片训练 LoRA 时要注意用于训练的图片应该尽量来自同一角色在不同角度、不同表情、不同服装下的图。这样 LoRA 才能学到面部结构、发型、瞳色这些稳定的身份特征而不是某一张图里的光照或画风。训练时一个常见问题是数据集里混入多种画风导致 LoRA 学了各种风格特征生成时角色不稳定。我的建议是如果现有素材画风不统一优先用同一画风的图训练或者在训练时加入风格标签让 LoRA 把画风视为独立变量。6.2 风格与角色的解耦画风与角色解耦是这次复盘里最重要的方法论。解开耦的思路可以这样理解角色是“内容”画风是“渲染器”。理想工作流中内容只在 LoRA / 参考图 / ControlNet 层流动渲染只在 checkpoint / 风格描述词层流动。任何出现在提示词里的画风形容词都要确保它不会破坏角色 token 的注意力权重。实际项目中我建议把提示词拆成四段角色描述1girl, long white hair, glowing blue eyes, dark armor with gold trim 画风描述modern anime style, clean lineart, bright colors 背景描述simple gradient background 质量词masterpiece, best quality这样做的好处是你可以针对画风替换第二段而不会动到角色描述。如果替换后角色发生漂移就去检查第一段和 LoRA 的权重而不是继续调提示词。6.3 版本管理与回归测试当一个角色反复用于多组生成时版本管理非常重要。推荐用文件命名或配置 JSON 管理以下信息底模名称和来源LoRA 名称和强度ControlNet 模型和强度提示词全文采样器、CFG、步数、分辨率生成批次和 Seed。把这些信息保存成config.json每次生成后记录输出图像的 batch_id后续复盘时直接对比配置差异。回归测试方面可以每次只改一个变量例如只换底模、只换 LoRA 强度、只换 ControlNet 模型对比输出变化。这套机制一开始看起来有点重但当角色数量多起来之后你会发现它能帮你节省大量重复试错的时间。7. 常见问题与排查方法问题现象可能原因排查方式解决方案换画风后角色完全变成另一个人角色特征被画风 token 稀释查看提示词中角色描述占比检查 LoRA 是否加载成功增加 LoRA 权重固定角色特征提示词减少画风形容词生成图出现半旧半新的画风拼凑感提示词同时包含两套画风描述检查提示词是否还残留旧画风词汇清理提示词只保留目标画风词汇同一 Seed 重跑结果仍不一致使用了错误的采样器或非确定性环境检查采样器、调度器、是否用了 xformers固定采样器和调度器确认版本一致角色脸稳了但手部结构崩坏缺少姿态与结构控制检查 ControlNet 是否启用使用 OpenPose / Depth ControlNet 控制姿态新画风生成结果色彩过淡底模与画风描述不匹配查看底模风格先验是否偏写实更换更符合目标画风的底模调整 CFG 和步数ComfyUI 加载模型后不生效模型被缓存加载了旧路径查看启动日志中的模型路径清理缓存重新提交任务如果生成失败我建议先从“运行日志”看起再检查“配置 JSON”最后才去动提示词。很多时候问题不在提示词而在配置状态不一致。8. 工程建议与避坑清单这篇复盘虽然是针对「Ontology 单人向」这个具体项目的但里面的经验完全可以泛化到更广的 AI 绘画工程场景永远把画风当作独立参数不要和角色设定混写在同一段提示词里。角色一致性优先依赖 LoRA 和参考图不依赖提示词玄学。切换画风时只切换 checkpoint 和画风描述词其他参数保持稳定。每个实验必须记录配置和输出否则失败后无法复盘。ControlNet 是画风切换场景下的稳定器尤其是 OpenPose 和 Depth。新模型未必更“好用”选择底模时要看它的风格先验是否符合目标画风。负面提示词要按模型单独调整不同模型对“bad hands”等词的理解权重不同。生成角色系列图是典型的批次任务不适合在聊天式界面里逐张跑。另外补充一个安全提醒如果这些生成结果会用于对外发布或商业项目请确保你使用的底模、LoRA 和数据集的许可协议允许该用途。训练 LoRA 和生成图片时要遵守相应模型与素材的授权要求不要使用来源不明的素材或未经授权的他人作品。9. 总结与后续方向这次「Ontology 单人向」的失败实验表面上是“旧画风切新画风翻车”本质上是一次典型的控制变量失败。画风与角色被混在同一层进行控制导致任何一方变化都会破坏另一方。我最终得到的结论是AI 绘画中的画风迁移不应该靠“换模型 改提示词”硬切而应该把角色特征、姿态结构、画风渲染分别交给不同的控制层去管理。具体来说就是用 LoRA 固定角色用 ControlNet 固定姿态用 checkpoint 切换画风再通过固定 Seed 和采样器保证可复现。这套方法论可以在不同角色、不同画风之间反复使用。如果要把这次经验继续深化有三个方向值得研究一是利用 IP-Adapter 做更精细的参考图引导二是尝试在不同底模之间训练统一的画风 LoRA三是把前面提到的配置 JSON 升级成团队内部可共享的画风库让不同成员只改动画风字段就能批量产出风格统一、角色一致的素材。如果你也正在做类似“同一角色多种画风”的生成任务建议先复制一份对照组配置角色 LoRA 和 ControlNet 保持不动只替换 checkpoint 与画风提示词不要一上来就追求完美画风。等整条链路跑稳了再去调风格细节。说到底AI 绘画的稳定性不是靠一次灵光一现的提示词而是靠一套能复盘的流程。
