企业官网建设流程全解析

“Of course she is lovely♥lovable”，这个标题第一眼看上去不像一个技术项目，更像一句带有情绪的表达。但如果把它放到 AI 绘画和角色创作这个语境里看，它其实是一个很好的主题：用可控的生成流程，把“可爱、讨喜”这种主观感觉变成一组参数稳定、风格统一、可以直接复用的人物图集或角色 IP 素材。

这篇文章不打算解释某个具体的开源模型权重怎么下，而是围绕 Stable Diffusion WebUI / ComfyUI 这条主流本地部署路线，讲清楚一套能落地执行的完整流程：从提示词设计、角色一致性控制、批量出图、API 调用，到显存观察和常见问题排查。你可以把这套流程理解成一个“角色出图工作流模板”，核心目标是把“lovely and lovable”这种抽象风格，转成可以重复生产、批量生成的工程化配置。

文章会包含硬件门槛判断、环境准备、启动方式、提示词示例、批量任务设计、curl 和 Python 调用示例，以及排错清单。适合想把本地 AI 出图做成稳定生产流程的读者，也适合刚接触这类工具、想少踩坑的新手。

1. 核心能力速览

在开始部署前，先把这套流程的关键能力列清楚。下面这张表覆盖的是通用 Stable Diffusion WebUI / ComfyUI 工作流的能力范围，具体数值以你本机模型版本和推理参数为准。

这里要特别强调一点：不要把“支持”和“默认配置就能跑得很好”划等号。从材料看，这类工作流的能力边界基本由三件事决定：显卡显存、模型文件版本、推理参数。显存越大，能跑的分辨率和批量数越高；模型越新，出图质量和语义理解越好；但模型越新，对 CUDA 和 PyTorch 版本的匹配要求也越高。

2. 适用场景与使用边界

这套工作流适合谁？适合以下读者：

• 想稳定生成一组“风格统一、人物一致”的图片，而不是每次随机碰运气。
• 需要处理批量任务，比如给 20 个角色设定各出 10 张表情差分图。
• 想把图片生成能力接入自己的工具链，通过 API 自动触发。
• 想在本地跑通全流程，不依赖在线服务，保证素材不在云端留存。

不适合的场景也很明确：

• 没有独立显卡，又要求高分辨率、速度快的场景。
• 需要训练完全全新的角色模型，而不只是用 LoRA 微调风格。
• 需要商用级别的高精度人脸还原，这类需求建议先确认授权与合规路径。

如果把“Of course she is lovely♥lovable”作为主题，它的使用边界更需要注意：这句话描述的是一类角色气质，不是某个具体真人。生成过程中如果参考了真实人物照片、具体角色设计稿或受版权保护的素材，必须确认授权。涉及人脸生成、风情镜头、拟真风格时，要遵守平台规则和当地法律，不能在未授权的情况下生成特定人物的图像，更不能把生成内容用于误导、欺诈或侵权用途。

隐私方面，本地部署的优势是素材不用上传到第三方服务器，但本机数据安全仍然要负责。模型文件要保留官方或可信来源，输入图片和输出结果建议分类存放，批量任务完成后及时清理临时文件。特别是使用图生图功能时，输入素材本身就是一份隐私数据。

3. 环境准备与前置条件

先把环境检查一遍，避免后续所有操作都在一个不稳定底座上跑。下面的清单适用于主流 Stable Diffusion WebUI 和 ComfyUI 本地部署场景，具体版本号以你使用的项目最新要求为准。

3.1 硬件配置

如果你使用的是较新的 50 系显卡，需要特别确认两个问题：显卡驱动是否支持你需要的 CUDA 版本，推理库是否有对应编译版本。这类新硬件在刚发布阶段，部分第三方整合包可能不支持，更稳妥的方式是先用官方发布说明确认。

3.2 软件依赖

通用依赖如下。没有给出具体版本号，因为不同模型和项目对版本的要求差异很大，写死版本反而容易误导。

• Python 3.10 或 3.11（具体看项目要求）
• Git
• CUDA 工具包（如果使用 GPU 推理）
• PyTorch 及对应 CUDA 版本
• Stable Diffusion WebUI 或 ComfyUI
• 对应基础模型文件（如 SD 系、Flux 系等）
• LoRA、ControlNet 等扩展模块（按工具分别安装）

安装依赖时，最容易出现的问题是 PyTorch 与 CUDA 不匹配。先用下面的命令确认当前环境状态：

nvidia-smi python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

正常运行后，torch.cuda.is_available()应该返回True。如果返回False，说明 PyTorch 安装的是 CPU 版本，或者 CUDA 版本不匹配，需要重装对应的 PyTorch 版本。

4. 模型与提示词设计

4.1 基础模型选择

“Of course she is lovely♥lovable”这一主题，重点在“可爱”与“讨喜”的氛围，对模型的要求是：擅长大头比例、柔光、暖色调、人物表情自然。你可以按以下思路选型：

• 如果使用 SD 系列模型，优先选择写实偏动漫或二次元混合风格的 checkpoint，这类模型对“可爱”语义理解更好。
• 如果使用 Flux 系列，语义理解更强，提示词可以写得更自然，比如直接描述角色的笑容、姿态、服饰和光线。
• 如果只有通用模型，也可以通过加 LoRA 补足风格短板，LoRA 文件几十到几百 MB，训练成本比完整模型低得多，非常适合做角色风格锁定。

更稳妥的判断是：先在同一个模型下测试少量提示词，观察输出风格是否符合目标。因为同一句“lovely and lovable”，在不同模型上生成的结果差异可能非常大。

4.2 提示词结构

把“她可爱又讨人喜欢”翻译成提示词时，不要只写一个单词。提示词可以让 AI 理解成一张图在解构之后的视觉要素。下面是一套适合出角色图的提示词模板：

masterpiece, best quality, 1girl, (平视构图视角), gentle smile, bright eyes, soft blush, long hair, (发色和发型描述), wearing (服装描述，例如白色针织连衣裙), warm sunlight, cozy cafe background, soft lighting, dreamy atmosphere, lovely, lovable, cute charm, heart symbol accents

负面提示词建议写清楚不想出现的内容：

lowres, bad anatomy, bad hands, extra fingers, missing fingers, worst quality, low quality, jpeg artifacts, signature, watermark, blurry, deformed, disfigured

这里的核心逻辑是把“可爱”拆解为可生成的具体元素：笑容、眼睛、腮红、发型、光线、背景氛围。提示词不是越长越好，而是每个词都要对应可渲染的画面元素。

4.3 使用 LoRA 做角色一致性

如果目标是围绕同一个角色生成多张图，需要保证角色特征稳定。最常用的方案是训练 LoRA 模型，然后在生成时调用 LoRA 权重。调用格式因 WebUI 和 ComfyUI 不同略有差异，通用写法是加入触发词，并在提示词中指定 LoRA 名称和权重。

以 WebUI 风格为例，提示词中会包含类似这样的片段：

<lora:character_name_v1:0.8> character_name

权重在 0.6 到 0.9 之间比较常见。权重太低，角色特征不明显；权重太高，其他元素可能被过度风格化，导致画面死板。具体权重需要根据 LoRA 训练时的数据分布来调，没有统一最优值。

5. 安装部署与启动方式

这里给出两套可选的部署路线：Stable Diffusion WebUI 和 ComfyUI。前者适合快速验证和 batch 操作，后者适合把工作流固化成节点图，复用性更强。

5.1 Stable Diffusion WebUI 一键启动

如果你在 Windows 上部署，最直接的方式是到官方仓库拉取代码，然后运行启动脚本。下面是通用命令示例，建议在目录名称上按实际项目调整：

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui

首次运行时执行：

python launch.py

或者 Windows 下使用项目自带的webui-user.bat。启动脚本会自动检查依赖，并下载部分默认配置。首次启动时间较长，之后再次启动会快很多。

启动成功后，终端会给出一个地址，例如：

http://127.0.0.1:7860

打开地址即可进入 WebUI。模型文件放在models/Stable-diffusion目录，LoRA 文件放在models/Lora目录。这个目录结构是这套工具约定俗成的，如果找不到，优先检查项目说明书中的目录路径。

5.2 ComfyUI 工作流加载

ComfyUI 适合把生成流程管理得更有条理。拉取后启动方式类似：

git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI python main.py

默认访问地址也是http://127.0.0.1:8188这类端口。ComfyUI 的界面是节点图，你可以把“加载模型、输入提示词、设置采样器、保存图片”串成一张图。第一次使用建议先用项目内置的默认工作流跑通，再改提示词和模型路径。

从实际使用体验看，ComfyUI 启动比 WebUI 更轻量，资源占用少一些，但操作上手门槛更高。如果你对节点图不熟悉，建议先用 WebUI 完成功能测试，熟练后再迁移到 ComfyUI 固化工作流。

5.3 端口冲突处理

启动时如果看到端口被占用的报错，可以在启动命令中指定新的端口：

python main.py --port 8190

WebUI 也有类似参数：

python launch.py --port 7861

端口冲突往往是因为之前启动的服务进程没有退出。Windows 下可以用下面的命令查找占用进程：

netstat -ano | findstr "7860" taskkill /PID <PID> /F

6. 功能测试与效果验证

部署完成后，先不要急着批量生产。按下面的顺序做功能测试，每一项都有明确的判断标准。

6.1 基础文生图测试

测试目的：确认模型加载正常，提示词能产生有效的图像输出。

操作步骤：

1. 打开 WebUI，选择目标模型。
2. 填入正面提示词和负面提示词。
3. 分辨率先设置为 512x768 或 768x1024。
4. 采样步数设置 20 到 30 步。
5. 点击 Generate。

判断成功的标准：

• 图片生成完成，没有报错。
• 图片内容与提示词大致匹配，人物结构正常。
• 生成时间在可接受范围内。

如果图片出现人物手指异常、脸部畸形，优先检查模型文件是否完整、负面提示词是否包含 anatomy 相关词、采样器和步数选择是否正确。

6.2 图生图重绘测试

图生图适合调整构图、改变画风、修复局部细节。测试目的是确认输入图像能正常参与生成流程。

操作步骤：

1. 准备一张合法的测试图片，确认你有权使用。
2. 使用图生图模式上传图片。
3. 调节 denoising strength 参数，建议从 0.5 开始。
4. 修改提示词，观察输出差异。

判断标准：

• 输出图片保留了原图的大致构图，但风格或细节发生了符合提示词的变化。
• denoising strength 越低，图像变化越小；越高，越接近重绘。实践中建议先用 0.4 到 0.6 测试，再根据需求调整。

6.3 角色一致性测试

这一步针对“Of course she is lovely♥lovable”这类角色主题项目。测试目的是验证同角色连续出图的稳定性。

操作步骤：

1. 选择一个固定的描述句子，作为角色的核心设定。
2. 在同一提示词基础上，只改变场景和光线描述。
3. 生成 4 到 8 张图，观察人物五官、发型、服装是否保持一致。
4. 如果使用 LoRA，记得加入触发词并设置权重。

判断标准：

• 多张图中角色可辨识度是否一致。
• 发型、瞳色、服装元素是否漂移。
• 如果每张图都像不同的人，需要提高 LoRA 权重或调整提示词固定更多角色细节。

6.4 自定义分辨率测试

不同输出场景对分辨率的尺寸要求不同。测试目的是验证模型在非默认分辨率下的表现。

操作建议：

• 单图时优先保持 2:3 或 3:4 比例，比如 768x1152。
• 批量出图时先测试小分辨率，比如 512x768，确认稳定后，再评估是否提高分辨率。
• 继续加大分辨率会显著提升显存占用和单张耗时，在相同显存下可能造成生成失败。

判断标准：输出是否出现对象结构扭曲、元素重复或直接报错。出现此类问题通常不是模型问题，而是分辨率设置超出能力范围。

6.5 批量任务测试

在 WebUI 中调整批量数量是最直接的批量方式。操作前先做显存预留，否则容易直接爆显存。

操作步骤：

1. 在 batch count 或 batch size 中设置数量，例如 2 或 4。
2. 固定提示词和采样参数。
3. 分批生成，观察显存占用变化。

判断标准：

• 连续生成过程是否稳定，有没有中途失败。
• 显存是否接近或超过显卡物理显存上限。
• 单批数量从 1 增加到 2、4 时，单张耗时会上升还是保持稳定。

首次批量测试，建议把 batch size 设为 1，用 batch count 控制总任务数。这样可以避免多张图同时推理导致显存溢出，同时能比较单张耗时和整批耗时的规律。

7. 批量任务与接口 API 调用

如果只是偶尔出几张图，WebUI 手动操作完全够用。但要进入“批量生产”阶段，一定要设计好任务管理和接口调用方式。这里给出通用的实现思路和代码示例。

7.1 接口启动方式

Stable Diffusion WebUI 启动时，添加--api参数即可启用接口服务：

python launch.py --api --port 7860

ComfyUI 本身会启动一个 WebSocket 和 HTTP 混合的接口服务，通过 REST 方式提交工作流。这里以 WebUI 通用接口为例，提供一个示例地址和调用格式。注意：不同版本接口路径可能变化，实际调用前先用浏览器打开接口文档页确认。

通用示例地址：

http://127.0.0.1:7860/sdapi/v1/txt2img

如果这个路径不可用，到浏览器访问http://127.0.0.1:7860/docs，查看当前版本的接口列表。

7.2 使用 curl 调用文生图

先来看一个最小可用的 curl 请求。下面的示例用于生成一张图，返回的是 base64 编码的图片数据：

curl -X POST "http://127.0.0.1:7860/sdapi/v1/txt2img" \ -H "Content-Type: application/json" \ -d '{ "prompt": "1girl, gentle smile, warm sunlight, lovely, lovable, masterpiece, best quality", "negative_prompt": "lowres, bad anatomy, bad hands, worst quality", "steps": 25, "width": 768, "height": 1024, "batch_size": 1, "cfg_scale": 7 }'

返回 JSON 中images字段是图片的 base64 字符串。保存时需要先解码再写文件。

7.3 使用 Python 调用并批量保存

Python 更适合处理批量任务。下面脚本按目录读取提示词列表，逐条请求 API，并把结果保存到指定目录。示例脚本是通用模板，实际使用时需要按接口返回格式调整解析方式：

import base64 import json import os import time import requests API_URL = "http://127.0.0.1:7860/sdapi/v1/txt2img" OUTPUT_DIR = "./outputs" os.makedirs(OUTPUT_DIR, exist_ok=True) prompts = [ "1girl, gentle smile, warm sunlight, lovely, lovable", "1girl, shy expression, cherry blossom background, lovely", ] payload = { "prompt": "", "negative_prompt": "lowres, bad anatomy, bad hands, worst quality", "steps": 25, "width": 768, "height": 1024, "cfg_scale": 7, "batch_size": 1, } for i, prompt in enumerate(prompts): payload["prompt"] = prompt try: response = requests.post(API_URL, json=payload, timeout=180) response.raise_for_status() data = response.json() for idx, img_b64 in enumerate(data.get("images", [])): img_bytes = base64.b64decode(img_b64) file_path = os.path.join(OUTPUT_DIR, f"result_{i}_{idx}.png") with open(file_path, "wb") as f: f.write(img_bytes) print(f"saved: {file_path}") except Exception as e: print(f"request {i} failed: {e}") time.sleep(1)

7.4 批量任务的工程化建议

• 输入提示词建议放在统一的文本文件或 JSON 配置中，不要散落在脚本里。
• 输出文件按“任务名_序号”命名，避免覆盖。
• 添加请求间隔，比如 1 到 3 秒，降低服务压力。
• 使用try-except捕获单次任务异常，记录失败原因，而不是中断整个任务队列。
• 批量任务结束后检查输出目录文件数量是否符合预期，少于预期时查看失败日志。

设计批量任务时，更稳妥的思路是先跑一个小批次，比如 5 条，验证接口、目录、保存逻辑都正常后，再扩展到全量。避免一上来就提交 100 个任务，结果第 10 个开始全部失败。

8. 资源占用与性能观察

生成类任务最关心的基本都是同一个问题：显存占用到底是多少？这个数值没有统一答案，因为它由模型精度、分辨率、步数、批量数、是否开启 ControlNet 等多个因素共同决定。下面给出观察方法和判断逻辑。

8.1 如何观察显存占用

Windows 推荐用任务管理器 GPU 性能面板，或者使用nvidia-smi：

nvidia-smi -l 2

参数-l 2表示每 2 秒刷新一次。运行生成任务时，观察Memory-Usage列的变化曲线。重点看两个时刻：

• 加载模型时的峰值。
• 单张图生成过程中的稳定占用。

如果显存占用长期接近 100%，说明当前配置已经贴近上限。此时需要降低分辨率、减少批量数、缩短步数，或换用更小的模型变体。

8.2 CPU 推理和 GPU 推理的差异

虽然支持 CPU 推理，但不推荐。CPU 的算力峰值远低于 GPU，同样的 512x768、25 步生成任务，GPU 可能只要几十秒，CPU 可能要几分钟甚至更久。CPU 部署只适合没有 NVIDIA 显卡，或需要先验证模型是否能加载的场景，不适合批量生产。

8.3 影响性能的几个关键参数

8.4 如何降低显存占用

• 降低分辨率，批量任务先用 512x768 测试。
• batch size 从 1 开始，不要一次性开 8 图同出。
• 使用--medvram或--lowvram启动参数（WebUI 支持），可以降低显存压力，但会牺牲速度。
• 更新到最新版 PyTorch，新版本对编译和图编译优化更好。
• 设置输出格式为 JPG，虽然对显存影响不大，但能减少磁盘占用。

这些参数的效果因机器而不同，修改后要重新观察nvidia-smi。

9. 常见问题与排查方法

下面是一份通用排查清单。遇到问题先对照表格检查，不要急着重装环境。

如果遇到“页面能打开但生成按钮无响应”的情况，大概率是前端 JS 报错或后端进程阻塞。最有效的办法是先看终端日志，终端输出的是真正的运行信息，前端页面反而会掩盖部分错误。

10. 最佳实践与使用建议

到这里，工作流的搭建和测试已经完成。下面这些工程建议是从实际项目维护角度总结的，对长期使用这套流程很有帮助。

一定不要一上来就追求一次生成大量图片。先设置最小参数，生成 1 到 2 张，确认流程能跑通，再决定提高分辨率或批量数。最小可运行配置建议保存下来，后面遇到问题可以恢复到基础状态。

模型文件、输入素材、输出结果要分目录管理。推荐结构：

project/ ├── models/ # 基础模型和 LoRA ├── inputs/ # 图生图输入素材 ├── outputs/ # 批量生成结果 │ ├── 2025-06-01_trial/ │ └── 2025-06-02_batch/ └── prompts/ # 提示词配置文件

批量任务必须加日志。每条任务记录时间、输入提示词、输出文件名、是否成功。不要只靠眼睛盯着一批图看。批量任务还要考虑失败重试。更稳妥的做法是先跑一次全量 5% 的小批量，确认接口和参数都没问题，再提交全量任务。

接口服务如果部署在公网或局域网，一定要限制访问范围。可以绑定本机地址127.0.0.1启动，或者通过防火墙限制端口访问。WebUI 的默认配置通常不包含身份认证，完全暴露在公网会有安全隐患。

涉及人脸、真实人物照片、版权素材时，必须确认授权。即使只是拿一张图做图生图测试，也要尊重原图版权和使用边界。发布或商用前做一次完整效果复核，不只有单张质量，还要检查批量输出中是否出现不适内容。

使用 LoRA 时，建议对每次训练的权重做标注。记录训练数据、epoch、触发词和推荐权重范围，这样后续复用时不需要反复试错。

11. 总结与下一步

这套工作流最值得尝试的地方在于，它把一个模糊的“可爱又讨喜”的想法，通过提示词设计、模型选择和参数控制，固化成一个可重复、可批量、可接口化的本地生成流程。后续无论你要做角色设定图、插画素材，还是搭建个人出图服务，都可以在这套基础上扩展。

第一步建议先做的是：准备一张合法的角色设定参考图，尝试图生图和小批量文生图，重点验证角色一致性和显存占用。最容易踩的坑是提示词写得太抽象、太短，导致生成结果不稳定；优先把“可爱”拆成笑容、眼神、光线、服饰、背景等可渲染元素。

后续可以继续扩展的方向包括：训练专属 LoRA 固定角色风格，引入 ControlNet 控制构图，或把 API 调用接入自己的自动化脚本。建议收藏备用，实际操作时对照文章逐项验证，能少走不少弯路。