本地AI图像生成与修图全流程指南：文生图、图生图到局部重绘

标题带着数字 4，看起来是某个进阶系列的某一篇，但这篇文章可以独立阅读。它讨论的不是某个画图软件的操作题，而是本地图像工作流里最核心的一段：先用文生图把画面画出来，再用图生图和局部重绘把不满意的地方修掉。很多 AI 绘图工具，不管界面是网页还是节点式画布，底层逻辑都绕不开这条链路，所以把这一套流程跑通后，换工具的成本会低很多。

先给结论：只要环境准备好，本地绘制和修饰图像的完整流程并不复杂。第一步是选一个能跑通的项目并完成部署；第二步是小分辨率、小步数先验证能不能正常出图；第三步才是调整模型、提示词、重绘幅度这些细节，去追求画面质量。如果你已经有一张图，想换背景、补局部细节或者统一风格，直接做修饰比重新生成更稳，也更省资源。下面按环境准备、启动部署、绘制测试、修饰测试、API 批量、资源占用和问题排查的顺序展开，末尾会给出可复用的一组最小验证清单。适合三类读者：正在搭本地图像流程的技术人员、需要批量处理视觉素材的开发者、想评估 AI 绘图能不能进入自己生产链路的内容团队。

1. 绘制和修饰图像核心能力速览

先把绘制和修饰图像涉及的能力罗列出来。很多人以为“AI 画图”只有一个文生图功能，实际落到工作流里，至少包含这几个环节：生成、编辑、局部修复、放大、批量处理和接口调用。下面这张表可以作为你评估工具时的对照清单。

需要说明的是，以上是常见本地图像绘制与修饰框架的通用能力集，不是某一个具体软件的完整功能列表。实际项目可能只包含其中一部分，也可能提供更多扩展。你在读项目文档时，应先确认它实现的是哪几个能力，再决定是否适合自己。绘图类项目往往安装包大、依赖多，不建议没有明确用途就直接下载，先用一张表列出你的需求，再按表去对照。

2. 适用场景与合规使用边界

绘制和修饰图像最常用的场景有三个。第一是内容配图，比如公众号文章、技术教程、视频封面，文生图可以快速产出草图和风格参考；第二是设计辅助，设计师拿到一张构图不够理想的原图，可以用图生图快速切换背景、光影或气氛；第三是电商素材批处理，把商品图批量放到统一背景、统一色调，这时候批量任务和 API 比手动导图高效得多。

但这类工具也有限制。AI 生成模型擅长表现“看起来合理”的画面，并不擅长工程制图、医学影像、带精确文字的排版成品。只要涉及像素级尺寸、严格文字内容、特定产品结构，都不能把最终交付直接交给生成模型，只能把它放在初稿和参考阶段。另一个限制是风格和一致性。同一个提示词在不同采样参数、不同分辨率下会产生差异，如果企业项目需要严格的品牌色、固定人物形象，就必须建立稳定提示词模板和标准测试集，每次换模型、换参数都要做对比回归。不要出现“上一张还行，这次换了显卡后完全不是同一个风格”的情况。

合规边界比功能更重要。使用图像生成与修饰工具时，必须注意四件事：

• 训练模型的来源是否合法，是否允许商用。不同模型的 License 差别很大，尤其是从社区下载的 checkpoint 和 LoRA，下载页面如果写了非商用或只限个人测试，就不能直接进入商业链路。
• 参考图和修饰图的版权授权。图生图和局部重绘如果使用他人拍摄的照片、设计师作品、影视截图等素材，需要确认来源和你是否有修改权。文章封面、商家图、商品详情页里的视觉效果，都可能涉及版权纠纷。
• 人脸和真实人物肖像问题。对真实人物照片进行生成、修饰、年龄变换或风格化，需要获得本人授权，并且不能用于误导性内容。
• 不要生成违法、低俗、歧视、仇恨、侵权类内容。有些内容并不是“技术上画不出来”，而是从使用边界上就不应该画。

3. 本地部署环境准备与前置条件

绘制和修饰图像的本地环境没有统一标准，但检查的顺序是固定的。建议先去确认操作系统、Python、Git、显卡驱动、磁盘空间，而不是直接装项目依赖，否则很容易出现“项目装到一半才发现某个底层库装不上”的情况。

以下是推荐的前置检查流程：

# 查看显卡型号、驱动版本和显存 nvidia-smi # 查看 Python 版本，一般建议 3.10 及以上，但具体看项目要求 python --version # 查看 Git 是否可用 git --version

如果你的电脑没有 NVIDIA 显卡，有些项目仍然支持 CPU 推理，只是速度会明显变慢。一张 512 分辨率的图，在 GPU 上通常几十秒内可以完成，在 CPU 上可能需要几分钟，反复调参时会比较痛苦。如果你只有 CPU 环境，建议先确认项目文档是否写了 CPU 模式，并尽量使用更小的模型和小尺寸测试图。AMD 显卡和 Intel 显卡在个别项目里有支持方案，但问题排查成本更高，第一次尝试不建议直接用。磁盘空间方面，绘图项目至少需要预留几十 GB，因为项目依赖和模型文件都是大头，不同体积的 checkpoint 模型从 1GB 到 7GB 不等，如果还要下载多个风格模型，空间需求会进一步上升。

依赖管理是另一个容易踩坑的地方。WebUI 类项目通常自带一套安装脚本，会创建虚拟环境并安装 PyTorch、相关依赖；源码启动项目则需要你手动创建虚拟环境。无论哪种方式，都建议把项目本身和 Python 环境隔离，避免污染系统 Python。安装时如果看到 pip 网络报错，可能是默认源不稳定，换成国内镜像源可以解决，但镜像源地址要以你所在网络环境实际情况为准。

4. 模型文件与输入输出目录规划

本地图像项目最忌讳的是模型文件乱放。很多用户把模型下载到“下载”目录，然后找不到文件路径，最后在启动时不断报错。建议从第一次部署起就建立固定的目录结构。下面是一个通用规划示例：

local-image-tools/ ├── models/ │ ├── Stable-diffusion/ │ ├── Lora/ │ ├── VAE/ │ └── ControlNet/ ├── inputs/ │ ├── reference/ │ └── batch/ ├── outputs/ │ ├── txt2img/ │ ├── img2img/ │ └── inpaint/ ├── scripts/ └── logs/

模型文件位置一般由项目的启动参数或配置决定。WebUI 类项目在界面上往往有“模型目录”设置项；ComfyUI 类项目则通过 models 目录下的子目录自动识别。图生图和局部重绘过程中使用的参考图，统一放在 inputs 目录，生成结果默认保存到 outputs 目录，这样批量任务脚本只需要读取固定目录，不需要每次去翻浏览器下载的文件。

下载模型时也要看文件格式。许多绘图模型以 safetensors 格式分发，它比旧式 ckpt 格式更安全，不会在加载时执行额外 Python 代码。如果看到一个模型文件是 exe、bat 或加密压缩包，在官方可靠渠道之外，通常不建议运行。开源社区里曾有模型仓库用恶意文件诱导下载的事件，这个风险不可忽视。选择模型时还要看模型适用的 Stable Diffusion 版本，比如 SD1.5 系列、SDXL、SD3 以及各种 faster 类架构，它们的提示词习惯、显存占用和支持插件都不一样。把 SD1.5 的 LoRA 强行装到 SDXL 模型上，通常不会生效，界面也未必会报错，只会出图结果异常。

5. 启动本地绘制服务与 Web 界面访问

启动方式由具体项目决定，但大体可以分成三类：整合包启动、源码命令启动、Docker 启动。整合包适合第一次体验，双击启动脚本即可；源码启动适合需要修改源码、调试插件的人；Docker 启动适合有 Linux 服务器、希望隔离环境的人。第一轮建议先用最简单的启动方式跑通，不要同时装很多插件。

启动前先确认端口是否被占用。Linux 和 macOS 上可以用 lsof 检查，Windows 上可以用 netstat 检查：

# 查看 7860 端口是否被占用 lsof -i :7860 # Windows 下查看端口占用 netstat -ano | findstr :7860

如果 7860 被占用，可以换一个端口。源码启动的常见入口是 launch.py 或 app.py，命令模板如下，实际路径以你的项目为准：

python launch.py --listen 127.0.0.1 --port 7860

如果你部署的是 WebUI 类整合包，通常会有 webui-user.bat 或 start.sh。启动后日志里出现类似 “Running on local URL” 的内容，就说明服务已经起来了。之后打开浏览器访问http://127.0.0.1:7860，就能看到绘图界面。需要注意，如果启动脚本里没有加--listen，默认只会监听本机 127.0.0.1，这是安全默认值，其他设备无法直接访问。如果你想在同一局域网的其他电脑上打开界面，才需要显式设置监听地址，同时要考虑访问权限问题，不要轻易把绘图 API 暴露到公网。即使只在本机使用，API 服务也存在未授权调用风险，建议通过本机防火墙限制访问范围。

启动后的第一件事不是立刻进入高参数绘图，而是确认以下几项：页面能正常加载、模型下拉框出现了你放的模型、显存占用没有异常飙满。如果页面能打开但模型列表为空，大概率是模型目录配置不对，或者模型文件没有放到项目要求的位置。

6. 绘制图像：文生图功能测试与参数调整

文生图是绘制图像的第一关。无论你之后要用图生图还是局部重绘，文生图都能帮你快速验证模型、提示词和采样参数是否正常。先给出一套低门槛测试建议：尺寸用 512x512 或 768x768，步数先用 20 左右，采样器先选默认项，其他参数暂时不动。这样可以把变量控制到最小，如果生成失败，问题更容易定位。

测试流程如下：

1. 启动服务并打开 WebUI 页面。
2. 在模型下拉框中确认已经选择目标主模型。
3. 在正向提示词输入框写一段包含主体、环境、光源、画质的描述。
4. 点击生成按钮，观察日志中的进度和耗时。
5. 在输出面板确认生成结果，并记录本次的种子、参数和显存占用。

为了减少变量，可以先使用一段稳定的示例提示词：

a small cafe on a rainy street, warm window light, people sitting inside, view from outside, photorealistic, high detail

生成完成后，判断成功的标准不是“图片好不好看”，而是：输出图与提示词描述基本匹配；没有大面积黑块、花屏或结构崩坏；生成过程没有报错；显存占用保持在正常范围。如果这些条件都满足，说明部署链路已经通了。

接下来可以调参数。这里需要重点区分两组概念：步数与采样器，CFG 与种子。步数影响生成质量在低步数区间很明显，步数从 10 提到 20，细节通常会更充分，但超过一定步数后收益会递减。CFG Scale 控制提示词对画面影响的程度，太高时颜色过饱和、画面生硬，太低时画面容易偏离提示词。种子是随机数起点，固定种子可以在相同参数下复现同一张构图，这对批量测试和问题定位很有用。绘图参数没有绝对正确，在一个项目上表现好的参数，换到另一个模型上可能需要重新测试。

文生图测试阶段最常见的问题出在提示词写法上。不要以为把一堆“masterpiece, best quality, 8k, ultra detailed”堆在开头就能提升画质。很多现代模型对这种堆叠词越来越不敏感，更有用的做法是写清主体、动作、环境、光线、镜头视角和风格。负面提示词也不是越多越好，写 “lowres, text, watermark, blurry” 这类常见干扰项就够，负面提示词写太长反而可能限制画面表现力。

7. 修饰图像：图生图、局部重绘与高清修复

绘制环节解决“从无到有”，修饰环节解决“从有到优”。修饰图像最常用的三个功能是图生图、局部重绘和高清修复，它们在很多工具里是独立标签页，或者以功能模块形式放在接口里。

图像整体重绘适合先选一张底图，再描述希望保留和改变的部分，核心参数是“重绘幅度”。重绘幅度在界面里通常用 Denoising strength 表示，意思是对原始图像的改动程度。如果取值在 0.1 到 0.4，画面结构基本保留，适合微调和统一风格；取值在 0.5 到 0.8 之间，构图会明显变化；接近 1 时，原始画面基本被重画，效果接近从提示词重新生成。做修饰第一步要用低重绘幅度，把原图和结果对比，确认主要结构没有崩掉，再逐步提高。

局部重绘是修饰图像里使用频率最高的功能，适用于修复手指、更换衣服、改背景、消除画面中多余物体等任务。操作逻辑是：上传原始图像，用蒙版工具把需要改变的区域涂抹出来，然后只对这个区域生成新内容。涂抹范围不要太大，能覆盖目标区域即可，范围过大容易让画面边缘不自然。局部重绘时，提示词只描述涂抹区域内希望出现的新内容，保持与周边画面的风格一致。如果修复的是脸部或手部，建议把小图单独裁切出来放大修复，再贴回原图，复杂操作不要在整张大图上直接做。

高清修复是用来解决小图放大模糊的问题。低分辨率图直接拉伸会损失细节，高清修复会先生成一张高分辨率图像或在放大过程中补充细节。使用它的主要场景是：文生图的第一步只用了小尺寸快速出图，选到满意构图后，再开启放大修复得到可商用的大图。需要注意的是，由于高清修复消耗显存远高于普通生成，如果总是报显存不足，可以先关闭修复，或者使用分块处理方式。另外，放大算法对不同内容类型有偏好，有些适合照片，有些适合线条插画，多试几种再选。

修饰阶段的成功判断标准更严格：未涂抹区域与原图接近，涂抹区域风格、光影和边缘融合自然，没有明显的接缝或结构冲突；整张图放大到实际使用尺寸后，细节仍然可用。如果在黑白照片转彩色、旧照片修复等任务上测试，要先确认原图版权归属，并且不要把私人照片上传到不可控的云端服务。

8. 把绘制和修饰流程接入 API 与批量任务

当你确认 UI 操作稳定，下一步就是把流程变成服务。很多本地绘图项目启动时开启 API 参数后，会提供 HTTP 接口，常见路径类似/sdapi/v1/txt2img和/sdapi/v1/img2img。不同工具的项目结构不同，接口不一定完全一致，所以第一次调用前先看日志和项目文档，确认实际可用路径。这里给出一套常见 WebUI 类项目的调用模板，用来展示入参和出参结构，不能直接套用到所有项目上。

启动时先加上 API 参数，例如：

python launch.py --api --listen 127.0.0.1 --port 7860

然后用 curl 做连通性测试：

curl -X POST http://127.0.0.1:7860/sdapi/v1/txt2img \ -H "Content-Type: application/json" \ -d '{"prompt":"a red apple on white background","steps":20}'

如果需要更完整的批量处理，可以用 Python 调用。下面这段代码从 inputs 目录读取输入图，对每张图执行一次图生图修饰，并把结果保存到 outputs 目录。实际项目下的 API 地址、参数字段和返回字段可能需要替换。

import os import time import requests import base64 API_URL = "http://127.0.0.1:7860/sdapi/v1/img2img" INPUT_DIR = "./inputs/batch" OUTPUT_DIR = "./outputs/img2img" LOG_FILE = "./logs/img2img.log" os.makedirs(OUTPUT_DIR, exist_ok=True) os.makedirs(os.path.dirname(LOG_FILE), exist_ok=True) def log(msg): line = time.strftime("%Y-%m-%d %H:%M:%S") + " " + msg print(line) with open(LOG_FILE, "a", encoding="utf-8") as f: f.write(line + "\n") def process_one(image_path, prompt): with open(image_path, "rb") as f: image_data = base64.b64encode(f.read()).decode("utf-8") payload = { "init_images": [image_data], "prompt": prompt, "negative_prompt": "lowres, text, watermark", "steps": 20, "width": 768, "height": 768, "denoising_strength": 0.4, } try: response = requests.post(API_URL, json=payload, timeout=180) response.raise_for_status() result = response.json() image_b64 = result["images"][0] output_name = os.path.splitext(os.path.basename(image_path))[0] + "_edited.png" output_path = os.path.join(OUTPUT_DIR, output_name) with open(output_path, "wb") as out_f: out_f.write(base64.b64decode(image_b64)) log(f"OK {image_path} -> {output_path}") return True except Exception as e: log(f"FAIL {image_path} error={e}") return False if __name__ == "__main__": prompt = "change background to a clean studio, warm light, same product" files = [f for f in os.listdir(INPUT_DIR) if f.lower().endswith((".png", ".jpg", ".jpeg"))] for file_name in files: image_path = os.path.join(INPUT_DIR, file_name) process_one(image_path, prompt)

编写批量脚本时，要在早期就加入日志和失败重试机制。不要直接处理百万张图，第一轮跑 10 到 20 张，确认接口稳定后再扩大规模。如果一张图处理失败，脚本应该能记录是哪张图、报了什么错，然后继续下一张，而不是整个进程崩溃。多次调用后显存不会自动完全释放，连续处理几十张图可能会导致后续请求变慢或显存不足，必要时可以在脚本里设置固定间隔“休息”，或者定时重启服务来释放显存。

图片来源需要非常明确。批量处理商品图、人物图或他人提供的素材之前，必须取得处理授权。尤其是商品图如果外包给远程 API 处理，数据会经过第三方服务，还要确认是否符合客户的数据安全要求。本地部署最大的价值是素材不离开你的机器，如果因为调用远程服务而破坏这一点，就需要重新评估风险。

9. 资源占用观察与性能优化思路

本地绘图服务的资源占用问题值得单独写一节，因为它在真实使用中最能影响体验。这里不提供特定配置下的数值，因为显存占用和模型大小、分辨率、采样步数、是否使用 ControlNet 都相关，同一段代码在不同硬件上表现差异很大。更稳定的做法是掌握观测方法，然后用你的设备测出自己的参考值。

在 Windows 上可以直接看任务管理器里的 GPU 显存曲线，NVIDIA 显卡可以在命令行里持续观察：

nvidia-smi -l 1

这条命令每一秒刷新一次显存使用情况。开始绘图前先记录闲置显存，生成过程中观察峰值显存和 GPU 利用率。如果生成结束后显存占用没有回落，说明进程可能有内存泄漏，需要重启服务。多数绘图项目日志里也会显示单步耗时，单位通常是 it/s 或 s/it，通过这个数字可以判断当前设置是快还是慢，也能判断换参数后性能是否改善。

影响资源占用的因素按重要程度排序大致是这样的：

• 分辨率：分辨率对显存和计算时间影响最大。从 512 提升到 1024，计算量不是翻倍，而是面积增加，资源消耗会大幅上升。
• 批量大小：一次生成多张图，能提高吞吐，但显存峰值会显著增加。
• 采样步数：步数主要增加计算时间，对显存峰值影响较低。
• ControlNet 等辅助模块：每增加一个辅助模型，都会同时增加固定显存开销和推理时间。
• 高性能放大和修复：部分修复流程会把整张大图放进模型，显存消耗可能超过普通文生图。

如果你的显卡可用显存有限，优化顺序推荐是先降分辨率，再关掉多余的后处理功能，最后再考虑降低批次数。有些项目提供 “medvram” 或 “lowvram” 这类降低显存占用的启动选项，它们也会明显降低生成速度。另一些项目支持 Tiled VAE 或分块放大，图像会切成块处理再拼回一整张，这是一个显存不足时值得尝试的方案。CPU 推理仍然可用，但如果图形界面卡顿，建议把 WebUI 和实际生成放到不同线程，或者直接接受较低分辨率，否则反复试参数时整体体验会比较差。

10. 常见问题与排查方法

在部署和调参过程中，报错信息往往比想象中更有价值。很多问题不是显卡不够，而是依赖没装对、文件放错位置或服务启动参数不正确。下面这张表覆盖了绘制和修饰图像流程里最常见的故障。

排查问题有一个基本顺序：先看服务端日志，再看浏览器控制台，最后检查硬件资源。日志通常会把异常原因写得比较清楚。如果 API 调用失败，先用 Postman 或 curl 发一个最小参数请求，不要把批量脚本整个跑起来再找问题。局部重绘结果难看，很可能是蒙版选得过大，而不是模型本身有问题；可以先保存一张只重绘极小区域的测试图，确认边缘融合正常后再扩展。

11. 最佳实践：可复用工作流与合规提醒

绘制和修饰图像虽然功能眼花缭乱，进入生产使用后真正重要的是可重复性。建议从第一次测试时就建立一套“基准请求”：固定一张测试图、一组提示词、一个固定种子、固定分辨率和步数。每次更换模型、升级工具版本、增加插件之后，先用基准请求跑一遍，输出图能维持接近原图的质量和风格，再切换其他任务。

文件管理要遵守几个简单原则。项目、模型、输入素材、输出结果分开目录存放，不要一边下载一边乱放。模型文件建议单独放一个磁盘分区或独立目录，因为模型体积大，频繁重装项目时如果混在项目目录里很容易被误删。批量处理脚本要为每次任务生成独立的时间戳目录，例如outputs/20250115_batch1/，避免结果互相覆盖。

日志不是可选项。任何批量任务都要记录每一张图的输入路径、请求参数、耗时、结果路径和错误信息。失败的文件名要单独收集起来，方便处理完第一轮后重新跑一次失败列表。如果不加日志，批量任务出错后你很难判断是整个系统的问题还是某些特殊图片的问题。下面这个目录结构适合大多数自动化流程：

20250115_batch1/ ├── inputs/ ├── outputs/ ├── logs/ │ ├── success.log │ └── failed.log └── config.json

关于技术选型，第一次尝试不要追求大而全的整合包。一个允许你直接选择模型、调整参数、把结果保存到指定目录的最小项目，比带几十个插件的复杂环境更容易排查问题。插件装得越多，启动越慢，出现冲突的概率也越大。你需要的先不是“更多功能”，而是“稳定复现结果”。等基础链路稳定后，再逐步添加 ControlNet、风格化 LoRA 等扩展功能。

合规提醒需要放在使用流程里反复强调。团队内部使用时，要把素材授权信息记录清楚，包括图片来源、人物肖像授权、版权归属、是否允许修改、是否允许商用。生成结果的版权归属与训练模型、参考素材都有关联，在商用之前不要只看生成效果就决定上线。很多 AI 绘图项目支持导入 LoRA 来模仿特定画风，如果在未经作者允许的情况下用他人作品做训练或风格参考，可能涉及侵权。更稳妥的做法是只使用授权素材、开源素材或你自己创作的图像。

12. 总结：先跑通最小链路再扩展

绘制和修饰图像的能力并不神秘，但它确实是一个依赖多、参数多、出错点多的工程链路。这篇文章值得保存下来作为对照清单：先搭好环境，确认文生图能出图；再测图生图，确认重绘幅度对结果的影响；然后练局部重绘，把蒙版控制和边缘融合掌握好；最后才接 API 和批量任务。顺序不要反，一上来就追求复杂功能，出了问题很难定位是模型问题、参数问题还是脚本问题。

最值得尝试的点是：文生图确实能快速出草图，图生图和局部重绘能明显降低从零生成的不确定性。最先应该验证的功能是：一张最简单的文生图能不能在本机跑通，这决定了之后所有功能是否值得继续装。最容易踩的坑有三个：显存不足、模型文件放错位置、不加日志直接跑批量，前两个会让你误判工具能力，第三个会让你在生产任务里追悔莫及。

下一步可以扩展的方向是：把绘制和修饰能力封装成一个内部服务，让它处理你日常固定的“出图、改图、存档”任务；配合 ControlNet 或专用模型处理更细分的场景；把重绘幅度、种子、分辨率这些参数做成配置文件，让非技术同事也能在固定模板下生成效果。最后补一句部署层面的建议：很多启动问题不是显卡不够，而是路径没放对、端口被占用、依赖没装全。建议新建一个干净的测试目录，把模型、输出、脚本分开，先跑通最小链路再套到实际生产流程里，把这套验证过程作为基准测试保存下来，以后换显卡、换模型、换平台，都可以用同一组参数快速比较。