“trust me！oc meme”——这几个词第一次凑在一起出现的时候，不少人以为是某个新出的 AI 工具名。其实它更像一句圈内口头禅：信我，这个原创角色（OC）我能给你出一整套梗图。
但真正动手做过的人都清楚，这里最容易崩的地方根本不是“画得好不好看”，而是一致性。第一张图里角色是灰蓝色短发、左眼下方一颗痣、脖子上挂着银色吊坠，第二张图里头发变成了蓝紫渐变、痣跑到了右边、吊坠变成了耳机——单看每张都还行，放一起就是两个人。
这篇文章不聊“哪个模型画得好看”这种主观问题，而是讲一件更工程化的事：怎么把一个 OC 做成可复用的梗图生产能力。核心路线是「角色卡固化 + LoRA 微调 + 分层提示词模板 + 批量出图 + 人工筛选」。读完你应该能自己跑通一遍从 15 张素材到 30 张系列梗图的完整链路，也知道每一步会在哪里翻车。
需要提前说明的是，下面涉及的模型、脚本、参数都以你本地实际使用的仓库版本为准，不同版本之间参数名会有差异，本文重点讲通用思路和排错路径，不绑定某一个具体版本号。
1. 这篇文章真正要解决的问题
很多人对“做一个 OC 梗图”的理解停留在“打开绘图工具，写一段提示词，生成一张图”。单张图确实这么干就行，成本极低。但梗图的本质是系列，系列的本质是可重复，可重复的前提是可控。
一旦你从“一张图”走到“一套图”，问题会立刻暴露出来。第一，角色特征会漂移，同一个提示词连点五次生成五次，每次的脸都不一样，属于典型的随机性失控。第二，表情和构图强耦合，你想让角色“翻白眼”，结果模型顺手把发型、服装、背景全改了，因为它在训练数据里从没见过这个角色的翻白眼样本。第三，梗图往往需要“角色 + 特定场景 + 特定文字”三件套，而文字排版这一步模型基本帮不上忙，必须后期处理。
所以这篇文章真正要回答的是三个问题：怎么让模型记住这个角色（而不是记住这张图）；怎么让表情、动作、场景变成可以单独调节的变量（而不是每次重新抽卡）；怎么把“生成—筛选—加字—归档”变成一条能反复跑、能团队协作的流水线。
适合读这篇文章的人有三类。一是做内容运营的，需要给品牌或 IP 稳定出表情包、社群梗图；二是独立开发者，想给自己的小项目、小产品做一个固定的吉祥物形象；三是画师和同人创作者，已经有角色设计稿，希望把设计固化成可以无限生成变体的能力。如果你只是想玩一张图，前面的内容也够用，后面几章可以直接跳过。
2. 核心概念与原理：OC、Meme 与 LoRA 的关系
先把几个词说清楚，避免后面概念打架。
OC（Original Character）指原创角色。它的关键不在“原创”，而在“有明确设定”。一个能用于生成的角色，必须能被写成一份结构化的角色卡，而不是一句“一个很酷的女孩”。角色卡里应该包含：固定发色与发型、瞳色与眼型、肤色、体型、标志性服装或配饰、不可变的特殊标记（痣、疤痕、纹身、耳饰位置）。这份清单就是后面所有环节的“唯一事实来源”。
Meme在这里指梗图、表情包这类以“情绪表达”为核心的内容形态。它有几个技术特征：构图往往很简单（大头、半身、白底或纯色底）、表情夸张、通常带文字、尺寸偏小、需要成套使用。这些特征对生成流程是有利的——构图简单意味着模型需要学习的东西更少，成套使用意味着一致性比精细度更重要。
LoRA（Low-Rank Adaptation）是一种轻量微调技术。通俗地说，它不改动基础模型那几十亿参数，而是额外训练一小块“补丁”，让模型在保持原有能力的同时学会一个新概念。对 OC 场景来说，这个“新概念”就是“你的角色长什么样”。LoRA 文件通常只有几十到几百 MB，加载快、可切换、可以多个叠加，这就是它能成为 OC 生产基础设施的原因。
下面这张表把几种常见做法的差别列清楚，方便你判断自己该走哪条路。
| 方案 | 一致性 | 制作成本 | 灵活度 | 适用场景 |
|---|---|---|---|---|
| 纯提示词描述 | 低，每次抽卡 | 极低 | 高 | 单张图、试风格 |
| 参考图 + 垫图 | 中，依赖参考图质量 | 低 | 中 | 少量固定姿势 |
| 图生图 + 线稿控制 | 中高 | 中 | 中 | 需要精确构图 |
| LoRA 微调 | 高 | 中高（首次） | 高 | 系列化、成套梗图 |
| 模型微调（全参） | 很高 | 很高 | 低 | 大规模生产、商业 IP |
对绝大多数个人和小团队来说，LoRA 是性价比最高的那个点。它的一次性投入大概是一份干净的素材集加一次训练，之后每次出图都只是在复用这个成果。
这里还要提前说一个最容易误解的概念：LoRA 学到的是“特征”，不是“像素”。如果你给它喂的 15 张图全是同一个构图、同一个背景、同一个角度，它很可能把背景和构图也一起学进去，最后你出的每张图都长着一样的背景。这不是模型笨，这是数据分布太窄。后面第 4 章会专门讲怎么规避。
3. 环境准备与前置条件
这一章是把流程跑起来的地基。说明一下，具体版本请以你使用的训练脚本仓库说明为准，这里只给通用要求和判断依据。
硬件方面，训练和推理对显存的要求不同。推理（也就是出图）在常见分辨率下，8GB 显存基本够用，如果显存更小可以通过降分辨率或使用内存卸载选项来跑。训练 LoRA 对显存要求更高一些，常见实践中 12GB 以上会舒服很多，24GB 可以比较从容地跑较高分辨率。如果没有本地显卡，租用带 GPU 的云实例也是常规做法，训练完成后把 LoRA 文件下载回本地即可。
软件方面，你需要准备三样东西：一个基础模型（也就是底模，决定整体画风）、一个训练脚本（常见的是 kohya_ss 系列脚本）、一个推理界面（常见的是 Stable Diffusion WebUI 或 ComfyUI）。Python 环境建议使用独立虚拟环境，避免和系统里其他项目冲突。
# 创建并激活独立环境（版本以训练脚本仓库说明为准） python -m venv venv-oc source venv-oc/bin/activate # Windows 下用 venv-oc\Scripts\activate # 升级基础工具 python -m pip install --upgrade pip # 安装 PyTorch：请根据你的 CUDA 版本去官方安装页选择对应命令 # 下面仅为格式示例，不要直接复制，务必按实际环境选择 # pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121目录结构建议一开始就规划好，后面会省很多事。训练脚本通常对train_data_dir的子目录结构有约定，一般是一个或多个以“重复次数_概念名”命名的子文件夹，里面放图片和同名标注文件。
oc-project/ ├── base_model/ │ └── base_model.safetensors # 底模 ├── dataset/ │ └── 10_myoc_character/ # 前缀数字=每张图重复次数 │ ├── 01.png │ ├── 01.txt │ ├── 02.png │ ├── 02.txt │ └── ... ├── output/ │ └── myoc_lora.safetensors # 训练产物 ├── configs/ │ └── train_myoc.toml # 训练配置 └── generate/ └── batch_meme.py # 批量出图脚本这个结构看起来琐碎，但它解决了一个真实问题：训练是反复试的。你可能会训三版、五版才满意，如果没有固定的目录约定，第三版的时候你已经分不清哪个文件对应哪次实验了。命名里带编号和日期，比“最终版”“最终版2”“真的最终版”可靠得多。
4. 数据集准备：素材收集与打标才是决定成败的一步
LoRA 训练圈里有句话，大意是“数据决定上限，参数决定你能不能摸到上限”。这话在 OC 场景里尤其准确。很多人训练失败，回头一看是素材只有 6 张，还全是同一角度的头像。
4.1 素材数量与分布
经验上，一个角色 15 到 30 张素材就能得到一个可用的 LoRA，但要满足几个条件：多角度（正面、半侧、侧面、背面至少各来一点）、多表情（中性、笑、生气、惊讶）、多景别（大头、半身、全身）、背景尽量多样（不要全是白底，也不要全是复杂场景）。画质要干净，不要有大量水印、文字、压缩噪点。
素材来源需要特别注意合规性。如果你用的是自己的原创设计稿，没有问题。如果是委托画师绘制的，需要确认授权范围是否覆盖“用于训练模型”这一用途——这一点很多人会忽略，训练用途和展示用途在授权上通常不是一回事。如果是真人照片或他人作品的二次加工，请务必先取得明确授权，不要拿别人的作品直接喂模型。这不是技术问题，但它决定了你做出来的东西能不能公开使用。
4.2 打标：自动 + 人工修正
打标就是给每张图配一段文字描述，告诉模型“这张图里有什么”。常用做法是用自动打标工具（如 WD14 系列的 tagger）先跑一遍，再由人工修正。自动标注的优点是快，缺点是把角色的固定特征也标进去了——比如每张图都标了“蓝色头发”，那模型会以为蓝色头发是一个可以变的属性，而不是这个角色的固有特征。
这里的关键技巧是触发词 + 固定特征短语。给角色起一个不常见的触发词，比如myoc_char（不要用girl、cat这类常见词，会污染语义），然后在每张图的标注里都带上它。训练时通过keep_tokens参数把标注文件开头若干个词锁定，不让它们被随机打乱，这样模型能稳定地把触发词和角色绑定。
一份修正后的标注示例大概是这个形态：
myoc_char, short grey-blue hair, mole under left eye, silver pendant, half body, white background, neutral expression注意这里刻意没有写“蓝色头发”“银色吊坠”以外的可变信息，也没写“1girl”这类通用词——通用词交给底模去理解，标注文件只负责描述这个角色的独特之处和这张图的构图。另外，如果某张图是“生气”的表情，就明确写angry expression，让模型知道表情是可变的，不要把表情焊死。
4.3 打标后的自检清单
在进入训练之前，花五分钟做这几项检查，能省掉一次三小时的无效训练：图片是否都是正方形或能被统一裁剪；是否有重复或高度相似的图（重复图会让模型过度关注那个构图）；标注文件是否和图片同名同目录；触发词是否在每份标注里都出现了；是否有图片本身带大面积文字或水印。
5. 训练 LoRA：配置、命令与关键参数
这一章给出一个可运行的训练配置骨架。再次提醒，不同版本的训练脚本在参数名上可能有细微差异，遇到报错时以脚本的--help输出为准，不要硬套。
# 文件路径：configs/train_myoc.toml # 说明：kohya_ss 系脚本的 TOML 配置示例，参数名请对照你所用版本的帮助文档 pretrained_model_name_or_path = "./base_model/base_model.safetensors" train_data_dir = "./dataset" output_dir = "./output" output_name = "myoc_lora_v1" # 训练分辨率，需与底模常见出图分辨率匹配 resolution = "1024,1024" enable_bucket = true # LoRA 网络规模：dim 越大容量越强，也越容易过拟合 network_module = "networks.lora" network_dim = 32 network_alpha = 16 # 学习率：角色类 LoRA 通常不宜过大 learning_rate = "1e-4" unet_lr = "1e-4" text_encoder_lr = "5e-5" lr_scheduler = "cosine" lr_warmup_steps = 100 optimizer_type = "AdamW8bit" mixed_precision = "bf16" # 训练轮数与保存策略 max_train_epochs = 10 save_every_n_epochs = 2 seed = 42 # 标注相关 caption_extension = ".txt" shuffle_caption = true keep_tokens = 1启动训练：
# 文件路径：项目根目录下执行 # 脚本名与参数以你所使用的仓库为准，这里演示调用形态 accelerate launch --num_cpu_threads_per_process 8 \ sd-scripts/sdxl_train_network.py \ --config_file ./configs/train_myoc.toml几个参数值得单独解释，因为它们直接决定你第一次训练会不会成功。
network_dim和network_alpha控制 LoRA 的容量。dim 太小（比如 4）学不住细节，角色特征会丢失；dim 太大（比如 128）在素材只有十几张的情况下极易过拟合，出的每张图都长得和训练集里的某一张一模一样。对角色类 LoRA，32 到 64 是一个比较稳妥的起点。
learning_rate决定学习速度。角色类目标通常希望“学得稳”而不是“学得快”，过大的学习率会让模型在几张图上反复横跳，最后产出崩坏的脸。常见起点是 1e-4 量级，如果训练中发现生成的图像噪点大、结构崩，优先考虑降低学习率而不是加轮数。
keep_tokens配合shuffle_caption使用。打乱标注能提升泛化能力，但会把触发词也打乱，导致触发词和角色的绑定变弱。把前 N 个 token 锁定，就相当于给模型一个稳定的“锚”。
max_train_epochs是最玄学的那个。同样的数据，8 轮和 15 轮出来的效果可能天差地别。稳妥的做法是每 2 轮保存一个中间产物，训练完把每个中间版本都实际出图测一遍，选最像的那个，而不是默认用最后一版。这一点后面第 7 章会展开。
在训练过程中，脚本会输出 loss 曲线。loss 持续下降到很低（比如长期低于 0.05）往往不是好消息，通常意味着过拟合；loss 长时间不下降则可能是学习率太小或数据标注有问题。这个信号只能作为参考，最终还是要靠出图验证。
6. 完整示例：批量生成一套梗图
训练完成之后，进入真正的产出环节。这一步的核心思想是提示词分层。把提示词拆成五层，每层只负责一件事，这样调试时能快速定位是哪一层出了问题。
| 层级 | 作用 | 示例片段 |
|---|---|---|
| 角色层 | 锁定角色身份 | myoc_char, short grey-blue hair, mole under left eye, silver pendant |
| 表情层 | 控制情绪 | smug smile、deadpan stare、shocked open mouth |
| 构图层 | 控制景别与视角 | upper body, looking at viewer, simple background |
| 风格层 | 控制画风与光感 | flat color, clean lineart, soft lighting |
| 后期层 | 文字与排版 | 由脚本在生成后叠加，不写进 prompt |
把表情做成一个字典，是让“一套梗图”真正成立的关键。因为梗图的差异几乎全在情绪和姿态上，而这两样恰恰是最适合参数化的部分。
# 文件路径：generate/make_memes.py # 说明：通过 Stable Diffusion WebUI 的 txt2img 接口批量出图 # 使用前需在 WebUI 启动参数中开启 API，并确认接口地址 import json import time import requests API_URL = "http://127.0.0.1:7860/sdapi/v1/txt2img" OUTPUT_DIR = "./memes" # 角色层：所有图共用，保证一致性 CHARACTER = ( "myoc_char, short grey-blue hair, mole under left eye, " "silver pendant, upper body, looking at viewer, simple background, " "flat color, clean lineart" ) # 表情层：每个条目对应一张梗图 EXPRESSIONS = { "smug": "smug smile, half-closed eyes, arms crossed", "deadpan": "deadpan stare, blank expression, straight mouth", "shocked": "shocked expression, wide eyes, open mouth", "cry": "crying, teary eyes, trembling lips", "angry": "angry expression, furrowed brows, puffed cheeks", "think": "thinking, finger on chin, looking away", } NEGATIVE = ( "lowres, blurry, extra fingers, bad hands, watermark, text, " "multiple characters, deformed face" ) def build_prompt(expr: str) -> str: # 分层拼接：角色层在前，表情层在后，便于观察权重影响 return f"{CHARACTER}, {expr}" def generate(name: str, prompt: str, seed: int) -> None: payload = { "prompt": prompt, "negative_prompt": NEGATIVE, "steps": 28, "cfg_scale": 6.0, "width": 832, "height": 832, "seed": seed, "sampler_name": "DPM++ 2M", } resp = requests.post(API_URL, json=payload, timeout=180) resp.raise_for_status() data = resp.json() import base64, os os.makedirs(OUTPUT_DIR, exist_ok=True) img_bytes = base64.b64decode(data["images"][0].split(",", 1)[-1]) path = os.path.join(OUTPUT_DIR, f"{name}_{seed}.png") with open(path, "wb") as f: f.write(img_bytes) print(f"[ok] {path}") if __name__ == "__main__": # 固定种子便于横向对比：同种子只变表情，能直观看出表情层的效果 for expr_name, expr_desc in EXPRESSIONS.items(): generate(expr_name, build_prompt(expr_desc), seed=20240501) time.sleep(1)这个脚本有几个刻意的设计。第一，固定种子。同种子、同角色层、只改表情层，出图结果才是可对比的，你能明确判断“表情层是否生效”。如果种子也随机，你永远不知道差异来自哪。第二，角色层写死在一个常量里。这是工程上的关键——你只需要维护一份角色描述，所有梗图都从这里取，不会出现这张图忘了写吊坠、那张图忘了写痣的情况。第三，参数集中。steps、cfg、尺寸写成一处，批量调参时只改一个地方。
跑起来之后，加上后期文字就完成了梗图闭环。文字部分不建议交给模型生成（当前模型对文字渲染的稳定性普遍不够），更稳妥的是用脚本叠加。
# 文件路径：generate/add_caption.py # 说明：在生成图下方拼接白边并写上梗图文字 from PIL import Image, ImageDraw, ImageFont import os def add_caption(src: str, text: str, dst: str, font_path: str = "./fonts/NotoSansCJK-Regular.ttc") -> None: img = Image.open(src).convert("RGB") w, h = img.size pad = int(h * 0.22) canvas = Image.new("RGB", (w, h + pad), "white") canvas.paste(img, (0, 0)) draw = ImageDraw.Draw(canvas) # 字号按图片宽度自适应，避免长文案溢出 font_size = int(w * 0.055) font = ImageFont.truetype(font_path, font_size) bbox = draw.textbbox((0, 0), text, font=font) tw, th = bbox[2] - bbox[0], bbox[3] - bbox[1] draw.text(((w - tw) / 2, h + (pad - th) / 2), text, fill="black", font=font) os.makedirs(os.path.dirname(dst), exist_ok=True) canvas.save(dst) print(f"[ok] {dst}") if __name__ == "__main__": mapping = { "./memes/smug_20240501.png": "trust me，这次真的行", "./memes/deadpan_20240501.png": "哦，是吗", "./memes/shocked_20240501.png": "等一下，你再说一遍", } for src, txt in mapping.items(): if os.path.exists(src): add_caption(src, txt, src.replace("/memes/", "/final/"))注意font_path需要指向一个支持中文的字体文件，路径不存在会直接抛异常，这一步是新手最容易漏的。字体文件需要你自行准备，注意商用授权问题。
7. 运行结果与效果验证
判断一次训练成不成功，不能靠“看起来还行”，要有明确的验证动作。推荐按下面三个维度做。
第一，角色还原度测试。用训练集里没出现过的构图和背景，比如“坐在窗边，侧脸，逆光”，看模型能不能画出正确的发型和配饰。如果能，说明角色特征学进去了；如果画出来是另一套配色，说明触发词没绑定好或者训练轮数不够。
第二，变量解耦测试。同种子、同角色层，只换表情层，连续出五张。理想结果是五张图里角色的脸、发型、服装高度一致，只有表情在变。如果换了表情之后发型也跟着变，说明训练数据里表情和造型强绑定（比如“笑”的图全是长发、“生气”的图全是短发），需要补充交叉样本。
第三，过拟合排查。找一张训练集里的原图，用它的标注去生成，如果生成的图能几乎 1:1 复现原图（包括背景细节），说明模型已经记住了这张图而不是学到了角色。这时候可以换更早的中间版本，或者降低network_dim重训。
判断标准可以整理成这张表：
| 现象 | 结论 | 处理方向 |
|---|---|---|
| 角色特征对，但每张图构图雷同 | 轻度过拟合到构图 | 换更早的 epoch，或补充多构图素材 |
| 特征对，换姿势就崩 | 数据分布太窄 | 补充多角度、多景别素材 |
| 完全不像，只能靠提示词硬凑 | 欠拟合或触发词失效 | 增加轮数，检查标注一致性 |
| 表情层改了没反应 | 权重太低或层顺序问题 | 调整表情词位置、提高权重 |
| 出图有大量噪点或结构崩坏 | 学习率过大或底模不匹配 | 降低学习率，确认底模一致 |
如果第一步就失败了（比如接口连不上），排查顺序是：先确认 WebUI 是否带 API 参数启动，再确认端口和地址，然后确认请求体字段名是否与你使用的版本一致，最后看 WebUI 控制台有没有报错堆栈。不要一上来就怀疑模型。
8. 常见问题与排查思路
把实际会遇到的问题按“现象—原因—处理”整理成一张表，遇到时直接查。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 训练启动即报显存不足 | 分辨率或 batch size 过大 | 看报错行是否指向显存分配 | 降低 resolution，减小 batch size，开启梯度累积 |
| 训练能跑但 loss 一直不降 | 学习率过小或标注错乱 | 抽查标注文件内容与文件名对应关系 | 提高学习率，修复标注，确认触发词存在 |
| 出图完全不像角色 | 触发词未绑定或轮数不足 | 用训练集原标注直接生成做对照 | 增加轮数，检查keep_tokens设置 |
| 每张图都长得一样 | 数据重复或 dim 过大 | 检查素材是否有大量相似图 | 去重，降低network_dim |
| 换表情后造型也变了 | 表情与造型在数据里强绑定 | 按表情分组查看素材分布 | 补充交叉样本 |
| 生成的图有水印或文字 | 训练素材里带水印 | 目视检查数据集 | 清洗素材，负向提示词加 watermark |
| 中文文字渲染成乱码 | 模型文字渲染能力不足 | 观察是否只有文字区域异常 | 交给后期脚本叠加，不让模型画字 |
| 批量脚本中途中断 | 单次请求超时或服务重启 | 看脚本报错行与 WebUI 日志 | 加大 timeout，加重试，分批执行 |
| LoRA 加载后画风突变 | 底模与训练时不一致 | 核对底模文件名与哈希 | 使用训练时的同一个底模 |
这里特别说一下“底模不一致”这个坑。很多人训练时用的是 A 模型，出图时图省事加载了 B 模型，然后发现效果怎么调都不对。LoRA 是依附于底模的补丁，跨底模使用不是绝对不行，但效果会明显打折，尤其是风格差异大的两个底模之间。工程上建议把底模文件名写进项目 README，作为一条硬性约定。
9. 最佳实践与工程建议
做到能出图只是及格线，能不能长期稳定产出，取决于你有没有把它当工程项目来管。
版本管理要落到文件层。每次训练产出的 LoRA 用「角色名 + 版本 + 日期 + 关键参数」命名，例如myoc_v2_dim32_e10_20240501.safetensors。同时在项目里维护一份简单的实验记录，写清楚这一版用了多少张素材、什么参数、效果如何、为什么淘汰。这份记录的价值在你训到第五版的时候会体现得非常明显——你会记不清第一版为什么被放弃。
角色卡要单独维护成文件。把发型、瞳色、配饰、禁改特征写成一份character.md，每次改提示词都从这份文件复制。这是一个很土但极有效的办法，它把“角色一致性”从人的记忆里搬到了文件系统里。
素材的授权信息要留痕。建议在数据集目录里放一个LICENSE.md，记录每张素材的来源和授权范围。这不是形式主义，当你想把梗图用于商业场景时，这份记录就是你能不能用的依据。
批量生成要分批、要留种子。一次跑 30 张容易在中途失败，分批跑、每批记录种子，出问题能精准重跑那几张而不是全部重来。所有生成的图建议保留一份带种子的文件名，方便复现。
设置人工筛选环节。不要指望自动流程直接产出成品。合理的比例是生成 3 到 5 倍于目标数量的图，人工挑出最好的那批。这一步没法省，因为模型对“手部结构”“表情是否到位”的判断远不如人眼。
明确使用边界。生成内容如果涉及真人肖像、他人作品风格、商业 IP 形象，务必先确认授权。用于公开传播的梗图，建议在角落保留一个极小的标识，方便追溯来源，这也是对自己作品的一种保护。安全与合规的边界永远优先于效率。
10. 收尾：从“能做一张”到“能做一套”
回到开头那句 “trust me！oc meme”。这句话之所以经常被当作玩笑，是因为它承诺的东西——一个稳定、统一、可以无限延展的角色形象——恰好是手工做图最难保证的部分。
这篇文章拆解的其实是一条很朴素的工程链路：先把角色写成不可变的清单，再用少量素材训练一个只学特征不学像素的 LoRA，然后把提示词拆成可独立调节的层级，最后用脚本把批量生成和文字排版串起来。每一步单独看都不复杂，但缺了任何一环，产出的东西就从“一套梗图”退化回“一堆图”。
如果你想马上动手，建议的顺序是：先只做 10 张素材跑一次最小训练，别追求完美，先把链路跑通；跑通之后再去优化素材质量和参数；等到能稳定出图了，再考虑把批量脚本和排版脚本整合成一个命令。反过来先搭工程再调效果的，通常会在第一次训练失败时就放弃。
后面值得继续深入的方向有几个：一是尝试用姿态控制（比如骨架或深度图）来精确控制梗图构图，这能大幅降低抽卡成本；二是把多个 LoRA 分层叠加，一个管角色、一个管画风，实现风格与角色的解耦；三是把整个流程脚本化成一条命令，输入角色卡和梗图清单，直接输出成套成品。这三件事都不难，但都需要你先有一个跑通的基线。
建议把本文的配置和脚本先存下来，第一次跑的时候对着目录结构一步步来，出问题先查第 8 章那张表，大部分坑都在里面。
