企业官网建设流程全解析

这次我们来看一个比较有意思的 AI 绘画需求：围绕“C108 すずら 原神 桑多涅”这一组合，做一套完整的本地角色同人出图流程。“C108”指的是同人展会 Comic Market 108 的创作场景，“すずら”是常见的铃兰风格/画师风格参考词，“桑多涅”则是原神中愚人众执行官“木偶”(Sandrone) 的中文社区常用译名。简单说，目标就是：在本地部署一套可控的 AI 绘图环境，稳定生成桑多涅的同人角色图，并且支持批量出图、风格微调和角色一致性控制。

这个需求最核心的价值不是“能不能画”，而是“能不能稳定地画出同一个角色”。桑多涅这类游戏角色，外观细节多、服装结构复杂，随便写提示词能出图，但很难保证每个批次的脸部、发型、服装保持一致。所以要解决的是三个问题：一是本地环境怎么搭，二是角色特征怎么锁住，三是批量任务怎么跑。这篇文章会围绕这三件事，从环境准备、模型加载、角色一致性测试、批量出图到参数调优，按一条完整的实操链路讲清楚。

先给结论：这套流程不需要很高的硬件门槛。主流做法是用 Stable Diffusion 的 WebUI 或 ComfyUI，基础模型加 LoRA 角色卡，6GB 显存起步就能跑出可用结果，更高显存可以获得更大分辨率和更高批量。支持 CPU 推理但速度很慢，只适合验证流程。支持 API 调用，ComfyUI 和 WebUI 都开放了 HTTP 接口，批量任务可以写在脚本里循环执行。这篇文章适合三类读者：喜欢原神角色并想自己出同人图的玩家、想把角色图批量做成素材库的画师或内容创作者、以及刚接触本地 AI 绘画想搞清楚部署和批量流程的技术用户。

1. 核心能力速览

这里需要明确一个边界：标题里的 C108 和すずら 是创作场景和风格参考，不是某个开源项目的名称。这套流程的核心技术载体是 Stable Diffusion 生态，角色识别依赖“基础模型 + 角色 LoRA + 提示词”三者配合。显存占用会随模型版本、分辨率、采样步数和批次数变化，实际数字要看本机跑出来的结果，不要照抄任何人的固定数值。

2. 适用场景与使用边界

这套流程适合谁？先说适合的人。第一种是原神玩家，想给桑多涅出同人图做头像、壁纸或者表情包。第二种是画师和内容创作者，在创作前生成角色参考图，用来辅助构图、配色和服装细节设计。第三种是技术型用户，把这套环境改造成一个可重复使用的“角色素材生成服务”，接进自己的工作流里，比如批量生成角色差分图、不同服装版式、不同背景构图。

能解决什么问题？核心是“同一角色多角度出图”。手工画一张桑多涅立绘需要很长时间，AI 出图可以快速产出十几个构图版本，再用图生图和局部重绘把不满意的细节修掉。对于需要大量角色素材的场景，这套流程的效率优势非常明显。

不适合什么场景？第一，不适合直接商用。原神角色版权属于米哈游，桑多涅这个形象的商业使用需要获得授权。同人创作是否允许盈利、允许到什么程度，要遵守官方同人规则和发布平台的具体条款，不要默认“AI 画的就能卖”。第二，不适合用来“冒充官方立绘”。AI 生成的图不是游戏官方素材，发布时必须标注清楚。第三，不适合在低端设备上追求高分辨率大图。集显或 4GB 显存做 1024x1024 以上的出图会频繁爆显存，体验很差。

合规提醒必须放在前面：本地出图工具本身是中性技术，但使用对象是受版权保护的游戏角色，因此要遵循三条底线。一是只做个人学习和小范围展示，不直接售卖；二是生成图涉及真人脸模、特定画师风格模仿时，要确认有无肖像权或版权争议，尤其是不建议用“すずら”等具体画师名去训练或模拟其个人风格；三是发布的图片要保留创作来源说明，避免平台判定为侵权内容。

3. 环境准备与前置条件

这里先给一套通用检查清单，按顺序确认，缺哪块补哪块。

硬件方面：

• CPU：近五年主流处理器即可，AI 绘画推理主要看显卡。
• 显卡：优先 NVIDIA，因为 CUDA 生态最成熟。显存 6GB 起步，8GB 可以流畅跑 SD 1.5 的高分辨率图，12GB 以上可以跑 SDXL 和更大的批量。
• 内存：建议 16GB 以上。加载大模型和批量处理时，内存不足会导致直接闪退。
• 磁盘：预留至少 30GB 空间。基础模型文件一般 2GB 到 7GB，LoRA、VAE、ControlNet 模型会越攒越多。

软件方面：

• 操作系统：Windows 10/11 最省心，Linux 也可以。macOS 需要看是否有对应版本的 PyTorch 和显卡支持，AMD 显卡在 Windows 下需要走 DirectML，配置更麻烦。
• 显卡驱动：更新到 NVIDIA 官方最新稳定版，避免 CUDA 版本不匹配。
• Python：推荐 3.10 到 3.11。Stable Diffusion WebUI 和 ComfyUI 的主流分支在这个版本段兼容性最好。
• CUDA 与 PyTorch：安装对应 CUDA 版本的 PyTorch。具体规定是“安装 PyTorch 时选择带 CUDA 的版本”，不是单独装一个 CUDA 工具包就能解决。

端口方面：WebUI 默认用 7860，ComfyUI 默认用 8188。如果本机端口被占用，启动时指定新端口即可。后面会给出命令。

4. 本地部署与基础模型加载

4.1 搭建 ComfyUI

推荐优先使用 ComfyUI，原因是它更适合“固定工作流 + 批量执行”的角色出图场景。先把仓库克隆到本地：

# 示例命令，实际路径按你的目录调整 git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI

然后创建 Python 虚拟环境并安装依赖：

# Windows 示例 python -m venv venv venv\Scripts\activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txt

如果使用 Stable Diffusion WebUI，也可以用官方一键安装脚本，但建议用 git clone 方式管理，后续更新更容易。这里不写死某个整合包，因为整合包版本更新频繁，直接读项目的 README 更可靠。

4.2 准备模型文件

基础模型要放到 ComfyUI 的models/checkpoints目录，LoRA 放到models/loras，VAE 放到models/vae。文件结构大致如下：

ComfyUI/ └── models/ ├── checkpoints/ # 放基础模型，如 SD1.5 或 SDXL 的 safetensors 文件 ├── loras/ # 放角色 LoRA / 风格 LoRA ├── vae/ # 放 VAE 文件 └── controlnet/ # 放 ControlNet 模型

启动命令：

# 在 ComfyUI 根目录执行 python main.py --listen 127.0.0.1 --port 8188

启动成功后，浏览器打开http://127.0.0.1:8188，看到工作台界面就说明服务正常。如果打不开，先看终端日志有没有报错，再确认端口是否被占用。换端口示例：

python main.py --listen 127.0.0.1 --port 8288

4.3 加载基础模型与 LoRA

在工作台里添加 Checkpoint Loader 节点，选择你下载的基础模型。再添加 LoraLoader 节点，选择桑多涅的角色 LoRA。连接方式是从 Checkpoint Loader 的 MODEL 输出接到 LoraLoader 的 MODEL 输入，再从 LoraLoader 的 MODEL 输出接给采样器。角色 LoRA 如果没有现成的开源资源，可以考虑自己采集几十张角色全身图做训练，但训练素材必须来自合法渠道，并且要注意版权边界。这里不展开训练教程，只提醒一点：训练 LoRA 用的图片数量、标注质量、学习率会直接影响角色还原度，效果需要多次实验才能稳定。

5. 功能测试与效果验证

5.1 文生图测试

先做最小可行性测试。输入一组最简提示词，确认环境能跑通。

positive: sandrone, genshin impact, official style, upper body, looking at viewer, detailed face negative: lowres, bad anatomy, bad hands, extra fingers, blurry, watermark

在采样器节点设置步数 20，采样器选择 Euler a，尺寸 512x768，种子随意。点击 Queue 执行，第一次出图时模型加载较慢，后续会快很多。判断成功的标准是：能在几秒到一两分钟内输出一张正常的角色图，脸部无明显畸形，整体构图符合预期。如果输出全黑或报错，优先查 VAE 是否缺失、显存是否爆了、模型文件是否损坏。

5.2 加入角色 LoRA 做一致性测试

配置 LoRA 节点后，把权重控制在 0.7 到 0.9 起步。权重太低角色特征不明显，权重太高容易过拟合导致画面脏。连续生成 4 到 8 张图，把种子固定，只微调提示词里的表情、动作、背景，观察角色脸部是否保持稳定。这个环节的意义在于验证 LoRA 是否真正“锁住”了角色，而不是每张图都换一个人。判断标准：多张图之间的发型、瞳孔颜色、服装核心元素保持基本一致，就可以进入批量阶段。

5.3 图生图与局部重绘测试

图生图适合把一张构图不错的图拿来改细节。把角色图传入 Load Image 节点，用 Image Resize 控制目标尺寸，再用 VAE Encode 把图转成潜空间输入采样器。局部重绘用 Mask 控制修改区域，适合修正脸部崩坏、衣服褶皱不自然、饰品结构错误等问题。操作方法：导入原图，画一个覆盖要修改区域的 mask，选择 “Inpaint” 节点，让采样器只重绘 mask 区域，其余部分保持原样。这里有一个经验：局部重绘的 denoise 强度设置在 0.4 到 0.6 之间比较合适，太高会把原图结构改乱，太低则修不掉瑕疵。

5.4 分辨率与细节测试

确认基础流程没问题后，把分辨率逐步提高。512x768 能跑通后，再试 768x1152、1024x1536。显存不够时用 Hires Fix（WebUI）或 Upscale 节点（ComfyUI）先出低分辨率图再做高清放大，而不是直接硬拉大分辨率。每次改分辨率后要注意显存占用和出图耗时变化，这个数据会直接影响后面的批量参数设计。

6. 批量出图与参数调优

批量任务是这套流程真正拉开效率差距的地方。ComfyUI 支持在 API 模式下通过脚本反复调用工作流，SD WebUI 也有--api模式。批量任务的核心是把变与不变分开：模型、LoRA、采样器、尺寸设为固定值；提示词、种子、LoRA 权重设为循环变量。

6.1 API 启动与调用

ComfyUI 加参数启动：

# 开启 API 模式，允许脚本访问工作流接口 python main.py --listen 127.0.0.1 --port 8188 --enable-cors-header

查询接口状态：

curl http://127.0.0.1:8188/system_stats

返回 JSON 中包含设备信息和显存情况，能正常返回就说明接口服务可用。

6.2 Python 批量任务脚本

下面给一个通用批量脚本模板。它读取一个提示词列表，逐条替换工作流中的文本节点，然后提交到 ComfyUI 的任务队列。实际使用时要先在图上面板里导出自己的 workflow JSON，再替换脚本中的节点 ID。

import json import uuid import requests COMFYUI_URL = "http://127.0.0.1:8188" # 提示词列表：每条记录是一个出图批次 prompts = [ { "name": "sandrone_neutral", "positive": "sandrone, genshin impact, official style, upper body, neutral expression", "negative": "lowres, bad anatomy, bad hands, extra fingers, blurry, watermark", "seed": 1001, "lora_weight": 0.8, }, { "name": "sandrone_serious", "positive": "sandrone, genshin impact, official style, upper body, serious expression, dark background", "negative": "lowres, bad anatomy, bad hands, extra fingers, blurry, watermark", "seed": 1002, "lora_weight": 0.85, }, ] def build_workflow(item): # 这里必须替换成 ComfyUI 里导出的真实工作流 workflow = { "3": { "inputs": { "text": item["positive"], }, "class_type": "CLIPTextEncode" }, "4": { "inputs": { "text": item["negative"], }, "class_type": "CLIPTextEncode" }, "6": { "inputs": { "seed": item["seed"], "steps": 20, "cfg": 7.0, "sampler_name": "euler", "scheduler": "normal", }, "class_type": "KSampler" } } return workflow def submit_prompt(workflow): prompt_id = str(uuid.uuid4()) payload = { "prompt": workflow, "client_id": prompt_id, } resp = requests.post(f"{COMFYUI_URL}/prompt", json=payload, timeout=30) resp.raise_for_status() return resp.json() for item in prompts: wf = build_workflow(item) try: result = submit_prompt(wf) print(f"submitted: {item['name']} -> {result}") except Exception as exc: print(f"failed: {item['name']} -> {exc}")

这段脚本的思路是逐条提交、逐条打印结果，适合跑几十个批次的批量出图。如果批量很大，建议在脚本里加一个 sleep 间隔，避免请求过密导致任务队列堆积。另外要控制steps、batch_size和lora_weight三个关键参数。步数从 20 起步，批量数建议先用 1 验证单张质量，确认稳定后再提 batch size。

6.3 批量任务架构建议

批量出图不是简单地把循环写长就完事，还要考虑几个工程问题。一是失败重试：单张图可能因为显存波动或网络超时失败，脚本里要记录失败任务并在全部跑完后重新提交。二是输出命名：建议用“角色_表情_服装_种子编号”的结构命名，比如sandrone_serious_1002.png，方便后续筛选。三是目录分离：输入素材、LoRA、输出结果分别放不同文件夹，批量任务结束后直接按目录打包，避免混在一起。

7. 资源占用与性能观察

资源占用是整个本地部署最需要实际测量的部分。先看怎么观察：Windows 下用任务管理器查看显存，Linux 下用nvidia-smi。以nvidia-smi为例，重点看显存占用和显卡利用率两列：

nvidia-smi

+-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ... ... ... ... ... ... ... | | 0 0 0 1234 C python.exe 5120MiB | +-----------------------------------------------------------------------------+

看到类似5120MiB这样的数字，就是当前进程占用的显存。要在同一配置下记录不同分辨率、不同步数的显存差异，形成一张自己的“参数与显存对照表”。比如同一模型，512x768 步数 20 可能只占 4GB 左右，1024x1024 步数 30 可能翻倍。但具体数值要按本机环境测，不同模型文件、不同 LoRA 数量、不同扩展都会影响。更稳妥的做法是每换一个模型，就重新测一轮，不要沿用旧参数。

性能方面有几个明显规律：分辨率对显存的影响通常大于步数，因为分辨率直接决定潜空间张量的尺寸；批量数每加 1，显存占用近似线性增加；CFG 太高会拖慢采样速度；SDE 类采样器比原来的 Euler 要慢，但细节表现不同。降低显存占用有几个常用手段：开启--lowvram或--medvram启动参数，让模型分块加载；使用 FP16 精度；降低 batch size；先用低分辨率出图再用放大模型补细节。要注意的是，这些手段会牺牲部分速度或画质，需要在“能跑”和“跑得好”之间找平衡。

进程残留也值得注意。批量任务中断后，显卡显存可能被未退出的进程占用，下次启动直接报 OOM。处理方式：

# 查看残留进程 tasklist | findstr python # 按 PID 结束残留进程（替换成实际 PID） taskkill /PID 12345 /F

8. 常见问题与排查方法

最容易踩的三个坑是：模型文件不完整导致出图异常、端口冲突导致服务起不来、批量任务没加失败重试导致中途中断。这三类问题都能通过日志和进程检查快速定位，关键是养成“先看日志再问原因”的排查习惯。

9. 最佳实践与使用建议

把这套流程用得更顺，有几个工程化建议可以提前做。

第一，第一次跑通流程时只用最小参数。模型、LoRA、提示词全部用最简配置，步数 20，分辨率 512x768，单张出图。先把“能不能跑”压实，再谈画质和效率。

第二，维护一套最小可运行配置。把“基础模型 + LoRA + 采样器 + 固定提示词模板”保存成一套参数文件，每次换新环境、换新显卡，先把这套配置跑通，再往里面加复杂功能。这套配置就是你整个流程的“基准线”。

第三，目录管理提前规划。建议按这样的结构组织：

sandrone-project/ ├── checkpoints/ # 基础模型 ├── loras/ # 角色 LoRA ├── inputs/ # 参考图、姿势图、mask 图 ├── outputs/ # 最终出图 │ ├── raw/ # 原始出图，不覆盖 │ ├── upscaled/ # 高清放大后 │ └── chosen/ # 筛选出的可用图 └── logs/ # 批量任务日志

第四，批量任务一定要加日志和失败重试。就算批量脚本写得再完整，显卡压力一大也会偶发出错。脚本把成功、失败、超时三种结果分开记录，跑完后看日志决定是否补跑。

第五，接口服务要限制访问范围。--listen 127.0.0.1默认只有本机能访问，如果确实需要局域网内其他机器调用，也要注意服务开放后的访问控制，接口无鉴权时不要直接暴露到公网。

第六，版权和授权必须前置。涉及原神角色桑多涅的生成图，只在个人学习和平台允许的同人展示范围内使用。任何涉及人脸、真人声音、特定画师个人风格模仿的素材，都要先确认肖像权、隐私权、版权授权，拿不准就不做。发布和商用之前还要做一次效果复核，确认图片没有明显模仿官方素材的痕迹。

10. 总结与下一步

这套“C108 すずら 原神 桑多涅”需求的本地出图方案，最值得尝试的点是：用一套开源的 AI 绘画环境，把特定角色的同人出图做成可控、可批量、可复用的流程。它的核心不是某个花哨功能，而是“角色一致性”和“批量效率”的组合：LoRA 负责锁住角色，脚本负责批量推进，ComfyUI 或 WebUI 负责把两者串起来。

上手后最先应该验证的是文生图的基础流程。用最简提示词、20 步、512x768 跑一张图出来，确认环境没问题，再逐步加 LoRA、调权重、测试图生图和局部重绘。最容易踩的坑在三个位置：模型文件路径放错、显存参数估算过高、批量脚本缺少失败重试。这几个坑都能提前规避。

后续可以继续扩展的方向：一是给角色 LoRA 做多角度、多服装版本，建一个桑多涅素材库；二是把批量脚本升级成带队列状态和输出预览的小工具，接进自己的内容生产流程；三是加入 ControlNet，用姿势骨架图控制角色动作，把出图范围从“半身立绘”扩展到“全动态姿势”；四是如果角色授权条件允许，再把流程拓展到更复杂的分镜和漫画辅助创作。先跑通最小流程，再逐步加控制环节，这个思路比一上来就追求完美配置要靠谱得多。建议把这篇的部署步骤和排查表格收藏备用，下次换环境、换显卡、换模型时可以直接对照操作。