“藿藿”这个名字一出来，熟悉《崩坏：星穹铁道》的玩家基本都能对上号——白发、狐耳、身后还跟着一截不安分的小尾巴。但在 AI 绘图社区里，“藿藿”还有另一层含义：它经常被当作检验“角色一致性工作流”是否成熟的试金石。原因很简单，藿藿这个角色有非常明确的辨识度：发色、瞳色、兽耳、尾巴、服装花纹，任何一项跑偏，角色就“不像”了。
这篇文章不是某个开源模型的广告，而是围绕“藿藿”这个角色 IP，整理一套可以在本地跑通的 AI 绘图工作流。你会看到文生图、图生图、局部重绘、批量生成、API 接入、以及角色 LoRA 训练这几个环节怎么组合使用，让最终输出结果更像藿藿本人。如果你正准备训练某个二次元角色 LoRA，或者想搭建一套角色卡批量出图流水线，这篇文章可以直接收藏。
1. 核心能力速览
由于本文是工作流方案而非单一项目，下面的速览以“整套本地 AI 绘图工具链”为对象。
| 能力项 | 说明 |
|---|---|
| 项目类型 | 本地 Stable Diffusion 绘图工作流 + 角色 LoRA 训练方案 |
| 主要功能 | 文生图、图生图、局部重绘、角色一致性出图、批量生成、API 调用 |
| 推荐硬件 | NVIDIA 显卡优先，8G 及以上显存体验较好；6G 可跑基础出图，4G 需要开启显存优化 |
| 显存占用 | 需以实际模型、分辨率、步数为准；512×512 基础出图通常不会太高，1024×1024 会明显增加 |
| 支持平台 | Windows / Linux，macOS 可用 CPU 或 MPS 跑，但速度明显偏慢 |
| 启动方式 | 一键包 / 命令行启动 / WebUI / ComfyUI 工作流 |
| 是否支持 API | 支持。WebUI 原生提供/sdapi/v1/txt2img等接口，ComfyUI 也可通过 API 方式提交工作流 |
| 是否支持批量任务 | 支持。可脚本批量出图、批量重绘，也可以用目录轮询方式做队列 |
| 适合场景 | 同人角色创作、角色设定稿、漫画分镜、素材批量生产、LoRA 训练效果验证 |
这里要强调一个原则：显存占用、出图速度、接口路径这类参数，在不同版本、不同模型、不同显卡上会有差异，实操时要以本机环境为准。下面所有命令和参数，都是通用模板，需要按你的实际目录和版本做替换。
2. 适用场景与使用边界
2.1 这套工作流适合谁
第一类是二次元同人创作者。想在本地稳定地生成“藿藿”相关插图，而不是每次抽卡碰运气。第二类是想要训练角色 LoRA 的实践者。藿藿这类头部特征明显的角色，非常适合作为训练对象，效果好坏一眼就能看出来。第三类是做批量素材生产的人。比如给视频配图、做表情包素材、给文章配封面，都需要一个能自动化出图的链路。
2.2 使用边界与合规提醒
这里必须把话说清楚：藿藿是《崩坏：星穹铁道》的角色，版权归属米哈游。用 AI 做同人图用于个人学习、技术验证、非商业展示，属于社区常见的二次创作范畴，但要注意三点。
第一，不要用官方原画、官方立绘直接垫图做商用输出，更不要直接售卖“官方风格”的图像内容。第二，如果生成内容涉及真人容貌、他人肖像，必须获得明确授权。第三，AI 绘图的随机性可能导致输出带有不可控元素，发布前务必人工审核，避免误解。
合规不是限制你折腾，而是让你在安全边界内放心折腾。本文所有演示都默认用于本地技术验证和个人创作。
3. 环境准备与前置条件
本地部署 AI 绘图，最核心的不是“命令背得多熟”，而是环境匹配。下面是通用检查清单。
3.1 操作系统与显卡
Windows 10/11 是大多数用户的主力系统，兼容性最好。Linux 适合长期批量跑任务，显存管理和进程控制更稳。macOS 可以跑，但速度不如 NVIDIA 显卡。
显卡方面，NVIDIA 显卡优先考虑，因为 CUDA 生态最成熟。显存容量上，8G 是“比较舒服”的入门线，6G 可以跑但需要开优化，4G 建议用低分辨率加显存清理插件。AMD 显卡理论上可用，但兼容性折腾成本高，遇到问题排查难度大。
3.2 Python 与依赖环境
多数 WebUI 和 ComfyUI 发行版自带 Python 运行时，不推荐自己手动装一堆依赖，容易版本冲突。如果是手动部署，建议用虚拟环境隔离：
# 创建并激活虚拟环境，Python 版本建议 3.10 或 3.11 python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate依赖安装顺序一般是：PyTorch（带 CUDA 版本）→ xformers（可选，显存优化）→ 具体 UI 项目的 requirements。
3.3 模型文件准备
文生图需要一个基础二次元大模型。常见选择包括 Anything V5、Counterfeit、MeinaMix 等。这类模型文件体积一般在 2GB 到 7GB 之间，放在 WebUI 的models/Stable-diffusion目录或 ComfyUI 的models/checkpoints目录下。
如果要用 LoRA，还需要把 LoRA 文件放入models/Lora目录。这里只是通用目录说明，具体名称和版本请按你下载的模型实际文件来写，不要照抄文件名。
3.4 磁盘与端口
模型文件比较大，建议预留 30GB 以上磁盘空间。默认端口一般是 7860（WebUI）或 8188（ComfyUI）。如果端口被占用，启动时会报错，需要手动换端口。
4. 安装部署与启动方式
4.1 WebUI 一键包启动
目前社区常见做法是下载整合包，解压后双击webui-user.bat启动。Windows 下首次启动会自动下载依赖和部分模型，耗时较长。
:: Windows 一键包示例，实际脚本名称按你下载的整合包为准 webui-user.bat启动成功后，浏览器访问http://127.0.0.1:7860。日志里看到Running on local URL: http://127.0.0.1:7860就说明服务已经起来了。
4.2 ComfyUI 启动
ComfyUI 对显存占用更友好，适合做工作流复现。启动方式如下：
# 进入 ComfyUI 目录后执行 python main.py --listen 127.0.0.1 --port 8188启动后访问http://127.0.0.1:8188。ComfyUI 默认是节点式界面，适合把整套流程固化成工作流文件，下次直接拖入就能复现。
4.3 命令行启动与参数调整
手动部署时，可以用命令行参数控制监听地址和端口。之前提到过，默认监听127.0.0.1，也就是只有本机可以访问。如果需要局域网内其他设备访问，可以把--listen改成0.0.0.0。做接口集成时，建议还是保持本机访问，更安全。
# 启动 WebUI 并指定端口，实际路径按你的安装目录调整 python launch.py --listen 127.0.0.1 --port 78604.4 启动失败怎么办
启动失败最常见两个原因。第一是显存不足，表现为启动过程中直接报 CUDA out of memory。第二是模型文件路径不对，UI 里模型下拉框是空的。先看启动日志，再检查模型目录，通常能解决大部分问题。
5. 角色基线测试：文生图
环境跑通之后，第一件事不是急着调参，而是验证“默认参数下能否出藿藿”。这一步我习惯叫角色基线测试。
5.1 设置提示词
藿藿的核心特征包括白发、狐耳、绿色眼睛、兽尾、狐人少女。注意，不同画师对角色的理解有差异，提示词要给出“核心特征 + 基础画质词”的结构。
masterpiece, best quality, 1girl, huohuo (honkai: star rail), white hair, fox ears, green eyes, fox tail, standing, upper body, simple background这里huohuo (honkai: star rail)的作用是唤起模型对角色名的认知。如果基础大模型不认识这个角色名，出图效果会不稳定，这时候就需要 LoRA 来兜底。Negative prompt 建议写常见的画质负向词：
lowres, bad anatomy, bad hands, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, jpeg artifacts5.2 参数设置
第一次测试不建议直接挑战高分辨率。推荐从 512×512 或 512×768 开始，采样步数 20 到 25 步，采样器用 Euler a 或 DPM++ 2M Karras，CFG Scale 设置在 7 左右。批量数可以先设为 1，确认效果后再加大。
5.3 判断是否成功
判断标准很直观：第一眼能不能认出是藿藿。具体可以看几个点：发色是否稳定、狐耳是否自然、尾巴是否出现、眼睛颜色是否正确。如果画质崩坏，优先检查大模型是否适合二次元；如果画质没问题但不像藿藿，说明基础模型不认角色名，下一步就是测试 LoRA 或换用角色特征更明确的提示词。
写到这里，补充一个容易踩的坑：不要在一开始就叠加大量角色 tag，比如同时写white hair, long hair, fox girl, animal ears等。tag 越堆越多，角色特征会互相污染，画面容易乱。先跑通“最小角色特征”基线，再逐步加细节。
6. 图生图与角色一致性验证
文生图验证通过后，下一步测试图生图。图生图的作用有两个：一是把粗略草稿变成成品，二是微调已有图的方向。
6.1 图生图基本操作
在 WebUI 切到“图生图”标签，上传一张参考图。Denoising strength（重绘幅度）是核心参数。数值越低，结果越接近原图；数值太高，原图结构会被改得面目全非。做角色微调时，建议从 0.4 到 0.6 开始。
假设你上传了一张构图满意的藿藿草图，希望补全背景。提示词可以简化为：
masterpiece, best quality, huohuo (honkai: star rail), white hair, fox ears, green eyes, outdoor, park重绘幅度控制在 0.5 左右，模型会根据提示词重绘背景，同时尽量保留原图的角色结构。
6.2 局部重绘：只改细节
如果对整张图基本满意，只有某个细节不对，比如尾巴方向错了，可以用局部重绘。在 WebUI 中打开图片编辑器，用画笔涂抹需要修改的区域，然后在提示词中明确写出该区域应该是什么样的。
局部重绘的要点是：涂抹范围宁大勿小，太小会导致边缘过渡不自然；重绘幅度可以比整图重绘低一些，0.3 到 0.5 之间比较稳。
6.3 一致性验证方法
角色一致性验证不是看一张图，而是看三张图。用同一组提示词，开启批量生成，每次生成 4 张，观察角色特征是否能在多张图中保持一致。真正的角色一致性还需要 LoRA 参与，后面专门讲。
7. 接口 API 与批量生成实践
本地调试通过后，如果需要接入自己的工具链，就要用 API。WebUI 原生提供了一套/sdapi/v1/接口，ComfyUI 也可以通过 API 方式提交工作流。
7.1 WebUI API 调用示例
前端页面能做的操作，大部分都有对应的 API。最常使用的是txt2img接口：
import requests import base64 import json import time url = "http://127.0.0.1:7860/sdapi/v1/txt2img" payload = { "prompt": "masterpiece, best quality, huohuo (honkai: star rail), white hair, fox ears, green eyes, standing", "negative_prompt": "lowres, bad anatomy, bad hands", "steps": 25, "width": 512, "height": 768, "batch_size": 2, "cfg_scale": 7, "sampler_name": "Euler a" } response = requests.post(url, json=payload, timeout=120) data = response.json() for idx, img_b64 in enumerate(data["images"]): img_bytes = base64.b64decode(img_b64) with open(f"output_huohuo_{int(time.time())}_{idx}.png", "wb") as f: f.write(img_bytes) print(f"Saved output_huohuo_{idx}.png")这段脚本的逻辑是：调用接口生成图片，把返回的 base64 字符串解码成二进制，写入本地 PNG 文件。batch_size设置 2，表示一次请求生成两张。
7.2 批量任务怎么设计
批量任务最常见的做法，是把提示词放到一个 JSON 配置文件里，程序逐条读取并调用接口：
{ "tasks": [ { "name": "huohuo_portrait", "prompt": "masterpiece, huohuo (honkai: star rail), white hair, fox ears, green eyes, portrait, looking at viewer", "width": 512, "height": 768 }, { "name": "huohuo_fullbody", "prompt": "masterpiece, huohuo (honkai: star rail), white hair, fox ears, green eyes, full body, dynamic pose", "width": 512, "height": 1024 } ] }然后在 Python 脚本里读取这个 JSON，逐条调用 API，并为每条任务增加失败重试。批量任务最容易踩的坑是服务端并发处理不过来导致超时。解决办法是加请求间隔，或者把batch_size控制在 1 到 2，按顺序跑。
7.3 ComfyUI API 调用
ComfyUI 的 API 调用方式不太一样。你需要先把节点工作流导出为 API 格式，再通过/prompt接口提交。基本流程是：
curl -X POST http://127.0.0.1:8188/prompt \ -H "Content-Type: application/json" \ -d @workflow_api.jsonworkflow_api.json是 ComfyUI 中“导出为 API 格式”的产物，不同工作流内容不同，这里没法给固定模板。使用时直接导入自己搭建好的工作流即可。
8. 资源占用与性能观察
跑 AI 绘图，显存占用是绕不开的话题。给出一个通用观察思路，具体数字以你本机为准。
8.1 怎么查看显存占用
Windows 下打开任务管理器，切到“性能”标签，看 GPU 的“专用 GPU 内存”。也可以在命令行执行：
nvidia-smi输出里能看到显存使用率、显存温度、当前进程。建议在生成前、生成中、生成后各看一次，通过差值估算单次任务显存峰值。
8.2 哪些参数影响显存
分辨率是显存大户。512×512 的显存占用比 1024×1024 低很多。步数对显存影响不大，主要影响生成时间。批量数batch_size直接影响显存峰值，批量越大显存占用越高。开启 xformers 可以降低部分显存占用，代价是速度可能略降。
8.3 显存不够怎么办
如果提示CUDA out of memory，按顺序尝试这几步：降低分辨率到 512×512；开启显存优化开关；把批量数改成 1；关闭其他占用显存的程序。实在不行，用 SD WebUI 的--medvram或--lowvram参数启动。
python launch.py --medvram注意--medvram和--lowvram不能和 xformers 同时使用，否则可能报错。
8.4 端口与进程残留
长时间批量任务容易出现端口被占用的报错。这是因为之前的 Python 进程没有完全退出。Windows 下可以这样查：
netstat -ano | findstr 7860 taskkill /PID 12345 /F把 12345 换成实际占用的 PID 即可。Linux 下用lsof -i:7860或fuser -k 7860/tcp。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 启动后页面打不开 | 端口被占用或服务未启动 | 检查启动日志和端口占用 | 更换端口或重启服务 |
| 模型下拉框为空 | 模型文件目录设置错误 | 检查models/Stable-diffusion目录 | 将模型文件放入正确目录并刷新 |
| 生成后图片是纯黑/纯白 | 模型加载失败、显存不足 | 查看日志是否报 CUDA 错误 | 降低分辨率、启用显存优化 |
| 角色不像藿藿 | 基础模型不认识角色名 | 对比有无 LoRA 的差异 | 训练角色 LoRA 或强化特征描述 |
| 手部崩坏 | 基础模型能力不足或 CFG 过高 | 检查 negative prompt 和 CFG | 使用手部修复或局部重绘 |
| API 请求超时 | 单次生成时间过长 | 查看服务端日志 | 降低分辨率、减小 batch_size |
| 批量任务中途卡住 | 服务端并发处理不过来 | 观察显存和 CPU 占用 | 增加请求间隔、顺序执行 |
| 显存不足报错 | 分辨率或批量数过高 | 查看显存占用情况 | 使用--medvram或降低参数 |
9.1 关于 LoRA 生效但效果弱
这是训练中最常遇到的问题。LoRA 模型权重已经加载，但生成结果变化不大，通常有三个原因：权重设置过低，一般需要 0.6 到 1.0 才明显；或者训练集图片数量太少，特征没有学进去；也可能是提示词里没有写触发词。LoRA 文件一般会在文档里说明触发词，训练时需要把触发词加入提示词。
9.2 关于“越调越糊”
很多新手在批量生成时，发现图片质量不稳定。常见原因是提示词里塞了太多互相冲突的标签，或者 CFG Scale 调得过高。CFG 超过 12 后，画面容易过饱和，颜色发油。建议 CFG 固定在 6 到 8 之间，不要频繁变动。
10. 角色 LoRA 训练入门
如果你发现基础模型无论如何都不认识“藿藿”，或者只能在特定角度下才像，那就需要自己训练一个角色 LoRA。训练量不大，但数据准备是关键。
10.1 数据准备
先收集藿藿的图片，建议 30 到 60 张。图片要有变化：不同角度、不同表情、不同构图。尽量避开官方原画、带水印大图、画面里有大量遮挡的图。图片尺寸统一裁剪到 512×512 或 768×768，分辨率太低会影响特征学习。
10.2 打标
每张训练图需要配一个文本标签作为描述。可以用 WD14 Tagger 之类的工具自动打标。打完标之后，把所有通用特征标签删掉，比如masterpiece, best quality, 1girl这类影响训练方向的标签。只保留角色特征标签：white hair, fox ears, green eyes, fox tail。
这里有个技巧：训练一个角色 LoRA 时，特征标签要保留，但不要每个角色特征都写进 tag，而是让模型“看到图片时自己联想”。实际上这种做法并不常见。更常见的做法是：在 tag 里保留通用的外观描述，同时给角色加一个唯一的触发词，比如huohuo，触发词的作用是让 LoRA 能被提示词唤醒。
10.3 训练参数建议
不同训练脚本参数差异较大，这里给一个通用参考区间，不代表最优，需要以实际效果为准。
学习率：1e-4 到 2e-4 训练步数：2000 到 5000 步 批量大小：2 到 4 网络维度：32 到 64 网络 alpha：16 到 32 """ 从 3000 步左右开始做中间态测试，生成几张验证图对比效果。训练步数太少，特征学不到位；步数太多，可能出现过拟合，生成的图千篇一律。 ### 10.4 LoRA 验证流程 训练完成后，把 LoRA 文件放到 `models/Lora` 目录，然后在提示词中加入 `lora:huohuo:0.8`，其中 0.8 是权重。生成时同时写角色名和特征词： ```text masterpiece, best quality, huohuo, white hair, fox ears, green eyes, standing对比不加 LoRA 和加 LoRA 的输出。如果加 LoRA 后角色形象明显更接近训练集风格，说明训练成功。如果角色变成“塑料感”，说明权重过高，调低到 0.5 到 0.6 再试。
11. 批量生成与工程化经验
本地部署最大的优势是可以把生成过程脚本化、自动化。这里分享几个工程化经验。
11.1 输入素材滚动队列
批量任务不一定只跑一次。更实用的设计是：一个输入目录放提示词 JSON 文件，程序启动后扫描目录，有新任务就提交给 API，完成后把结果移动到归档目录。这样可以用定时任务实现无人值守。
简单做法：
# 伪代码，实际用 Python 或 shell 实现 watchdir=/data/tasks outputdir=/data/output # 扫描 watchdir，有新文件就执行生成脚本 python batch_generate.py --watch /data/tasks --output /data/output难点不在 API 本身，而在任务失败重试和输出文件命名。建议输出文件名带时间戳和任务名，避免批量任务过程中互相覆盖。
11.2 目录管理规范
模型、输入、输出分开放。建议目录结构如下：
|-- models | |-- Stable-diffusion | |-- Lora |-- inputs | |-- tasks |-- outputs |-- logs日志单独放在logs目录。批量任务跑完后，翻日志定位问题比猜原因快得多。
11.3 接口服务安全
如果 API 绑定到局域网，建议加上访问控制或者只跑在本机。--listen 0.0.0.0虽然方便，但也意味着局域网内任何人都能调用你的服务。AI 绘图接口没有鉴权，违规使用会被当成你本人的操作。所以，默认保持127.0.0.1，需要外部访问时再显式对外开放，并加防火墙规则。
12. 总结与下一步
围绕“藿藿”这个角色，本文打通了本地 AI 绘图的完整链路：环境部署、文生图基线测试、图生图局部重绘、API 接入、批量任务、资源优化、LoRA 训练验证。如果你只想做一件事，我建议先跑一遍“第 5 章的文生图基线测试”，用最少的配置确认工具链没有硬伤，再逐步叠加功能。
最值得优先验证的功能是角色一致性。先测试基础模型对藿藿的识别度，再决定要不要训练 LoRA。最容易踩的坑还是显存不足和模型路径配错，这两类问题占了本地部署报错的绝大多数。排查时记住“先看日志，再查目录，最后调参数”，基本能解决九成问题。
后续扩展方向有三个：一是把批量化脚本接到定时任务里，实现固定流程自动出图；二是尝试用 ControlNet 控制构图，让角色姿势更可控；三是把训练好的 LoRA 分享给社区，但分享时要标注“非官方同人模型”，不要做任何授权外商用。
本地 AI 绘图不是把模型下载下来就结束的事，而是“工程化”的过程。把你的角色提示词、参数配置、工作流文件都保存好，下次想复现时，你会发现这套沉淀比任何参数秘诀都值钱。建议收藏备用。
