ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

100天AI绘画实战:秦良玉与甲骨文风格生成全流程

100天AI绘画实战:秦良玉与甲骨文风格生成全流程 “秦良玉 - 甲骨文》本萌新ai之100天”这个项目名第一眼就很有辨识度。它不是一个复杂的企业级框架也不是某个大厂刚开源的模型而是一个把历史人物、古文字和 AI 生成工作流串起来的 100 天实战记录。项目核心就三件事用 AI 稳定地画出秦良玉相关的历史题材内容把甲骨文的视觉元素做成可复用的风格提示再把这套流程从“单张测试图”升级成批量任务和接口服务。这篇文章会把整个项目拆开讲从硬件门槛、环境准备、部署启动到文生图、图生图、风格化字卡、短片分镜测试再到批量目录任务和 API 调用示例。最后补一份 100 天实践路线和常用问题排查清单。适合两类读者一是想做历史、文化、文创方向 AI 内容的人二是刚接触本地部署和 API 封装的开发者想找一个完整的项目流程参考。1. 核心能力速览先给一张速览表。这里要特别说明项目本身的细节材料不多下表按项目定位和通用 AI 创作工作流整理具体参数需要以你实际运行的模型和环境为准。能力项说明项目定位以“秦良玉 甲骨文”为主题的历史文化向 AI 创作实践核心功能文生图、图生图、风格化参考、古文字字卡/海报、短片与漫剧分镜素材、批量任务、API 服务封装项目来源个人 AI 学习记录项目重点是可复现的工作流而非单一开源模型涉及技术Python、PyTorch/CUDA 依赖、扩散模型推理、FastAPI 接口封装、批量脚本推荐硬件有 NVIDIA 显卡优先显存较小的建议从低分辨率、少步数开始测试纯 CPU 可跑但速度较慢显存占用取决于具体模型版本、分辨率、步数和批量大小需以本机实测为准支持平台Windows / Linux / macOS主要看依赖是否支持对应系统启动方式命令行启动、一键脚本、WebUI 界面、API 服务是否支持 API可以通过 FastAPI 等框架对推理接口做一层封装是否支持批量任务支持可用输入输出目录批量处理适合场景历史题材图文创作、古文字科普内容、文创素材批量生产、AI 工程化练习从项目标题的“100天”能看出它不是一条命令跑完就结束的玩具项目而是一个持续迭代的创作系统。前 30 天大概率在搭环境和调提示词中间 30 天在解决风格统一和批量产出最后阶段才是在做接口化和工程化。这也是我认为这个项目值得参考的原因它把 AI 内容创作从“能出图”推进到了“能稳定产出”的阶段。2. 项目背景与适用场景2.1 为什么是秦良玉和甲骨文秦良玉是明末著名女将中国历史上罕见被列入正史将相列传的女性军事人物。这个题材本身就自带画面感铠甲、战马、帅旗、历史场景这些都是文生图和图生图模型比较擅长表达的内容。同时历史人物类创作不需要担心人物版权问题只要保持形象的基本尊重创作空间很大。甲骨文则是另一种视觉元素。作为中国已知最早的成系统文字它的笔画结构和图形化特征非常强很适合拿来测试风格迁移、纹理叠加和字卡排版。项目把这两个主题组合在一起本质是在做一个“可控风格”练习既要有历史人物的辨识度又要有甲骨文的符号感这比随便生成一张风景图要难得多也更有复盘价值。这里需要说明如果读者看到“甲骨文”联想到的是 Oracle 数据库或云计算那和这个项目的方向不同。项目标题里的“甲骨文”明显指向殷商时期的古文字。2.2 适合谁用第一类历史、文化、文创方向的 AI 创作者。比如要做历史人物科普配图、漫剧分镜、短剧封面、文创海报这个项目提供了一套从提示词到批量产出的完整示例。第二类AI 本地部署入门者。想搞清楚模型文件怎么放、显存怎么看、启动脚本怎么写、接口怎么封装的开发者可以按这个项目的流程走一遍。第三类想复用自己的主题做 AI 工作流的人。秦良玉和甲骨文只是一个锚点换成地方文化、品牌 IP、游戏角色流程是一样的。2.3 使用边界与合规提醒写这节不是走形式。历史人物题材和古文字素材在内容安全上要特别注意生成秦良玉相关图像时应保持对历史人物的基本尊重不做丑化、恶搞或严重失实的改编。如果做商用项目需要确认参考素材、训练素材和最终输出结果是否可商用。历史古画、网络图片的授权状态不同不能默认都能用。涉及真实人脸、真人声音、他人肖像和作品元素时必须先获得授权。甲骨文是重要的文化遗产可以在创作中使用其字形风格但不要伪造、曲解或做误导性历史解读。批量产出的内容正式发布前建议人工复核一遍避免出现文字变形、历史细节错误等问题。3. 环境准备与前置条件3.1 软件依赖清单项目无论采用哪种模型底层基本都是 Python 环境加 PyTorch/CUDA 推理栈。准备环境时按下面这套通用清单来核对操作系统Windows 10/11、Ubuntu 20.04 以上或 macOS 12 以上。Python建议 3.10 或 3.11避免 Python 3.13 刚发布时部分深度学习依赖还没适配。包管理工具pip、conda 二选一更推荐 conda 管理 Python 虚拟环境。Git用于拉取项目代码和模型配置。CUDA / cuDNNNVIDIA 显卡用户需要安装具体版本根据 PyTorch 的要求选择。模型文件单独建一个模型目录存放不要和代码混在一起。以下是一套常见的虚拟环境创建命令实际项目名称以你使用的工作流为准# 创建并激活虚拟环境 conda create -n qi-ai python3.10 -y conda activate qi-ai # 或使用 venv # python -m venv venv # source venv/bin/activate # Windows 使用 venv\Scripts\activate3.2 硬件确认本地运行 AI 绘图模型第一看显卡第二看显存第三看内存。有 NVIDIA 显卡的机器先用nvidia-smi看一下显卡型号和显存大小。显存较小的比如 4G 到 6G优先选择低分辨率模式例如 512x512 或 512x768步数控制在 20 到 30 步。显存较大的可以往上加分辨率也可以测试图生图和批量任务。没有独立显卡的机器可以走 CPU 推理。纯 CPU 模式适合验证流程、跑通脚本但生成一张图的时间和 GPU 比会慢很多。如果项目带有 ONNX 或量化版本CPU 体验会好一些但需要按实际项目支持情况来判断。磁盘方面一个基础模型文件通常会占几 GB 到十几 GB再加上依赖包、输入素材和输出结果建议预留至少 30 GB 空间。如果还打算做视频类测试空间需求会更明显。3.3 端口与访问检查启动 API 服务或 WebUI 时要提前确认端口没被占用。常用的 WebUI 端口是 7860API 端口可能是 8000 或自定义端口。可以在启动前检查# Linux / macOS lsof -i :7860 # Windows netstat -ano | findstr :7860如果端口被占启动参数里换一个端口即可后面会单独讲。4. 部署与启动方式4.1 获取项目代码并安装依赖假设这个 100 天项目已经整理成了若干脚本和配置文件先从仓库拉取。实际地址需要替换成作者公开的仓库路径下面用占位符表示git clone https://github.com/yourname/qin-liangyu-oracle-ai.git cd qin-liangyu-oracle-ai进入项目后安装依赖。如果项目提供requirements.txt直接安装# 建议在虚拟环境中执行 pip install -r requirements.txt如果项目用的是 ComfyUI 或 WebUI 这类现成框架则不需要自己写推理代码只需要把模型文件放到指定目录再导入工作流 JSON。这类框架一般自带依赖安装脚本按官方说明执行即可。4.2 模型文件准备无论是直接调用 diffusers 还是使用 WebUI/ComfyUI模型文件都是必需的。先把下载好的模型文件放到统一目录models/ ├── checkpoints/ # 主模型 ├── loras/ # LoRA 风格模型 ├── controlnet/ # ControlNet 模型 └── vae/ # VAE 文件注意模型文件版本和主程序版本要匹配。常见的坑是下载了新版模型但程序内置的配置文件还是旧版导致加载报错。判断标准很简单——启动日志里只要出现模型加载失败的红色报错优先检查文件路径和版本。4.3 启动推理服务多数 AI 绘图项目都提供命令行启动方式。下面是一个通用启动示例具体脚本名和参数需要按项目实际结构调整# 启动 WebUI 或推理服务端口自定义 python app.py --host 127.0.0.1 --port 7860启动过程通常会经历加载配置、检查依赖、加载模型、输出访问地址。等日志出现Running on local URL: http://127.0.0.1:7860之类的提示就说明服务已经起来。启动后先在浏览器打开本地地址确认页面能正常显示。如果页面空白或一直转圈回到终端看日志重点排查端口占用、模型加载失败、依赖缺失三类问题。4.4 一键脚本方式对于不需要改代码的日常使用可以在项目根目录写一个启动脚本。Windows 下用run.batecho off call conda activate qi-ai cd /d %~dp0 python app.py --host 127.0.0.1 --port 7860 pauseLinux / macOS 下用run.sh#!/bin/bash source activate qi-ai || conda activate qi-ai cd $(dirname $0) python app.py --host 127.0.0.1 --port 7860写好后Linux 下记得加执行权限chmod x run.sh ./run.sh一键脚本的价值不只是省命令而是把“固定启动参数”固化下来。这样即使隔几天再回来跑也不会忘记用什么端口、什么参数。5. 功能测试与效果验证5.1 文生图基础测试秦良玉题材先做最基础的一项用一句完整的提示词生成秦良玉题材图。测试目的验证模型能不能理解历史人物描述能不能输出符合预期的构图。输入提示词示例明朝女将军秦良玉身着明式铠甲头戴帅盔背景为古代战场水墨国画风格细腻历史感操作步骤打开 WebUI 或调用本地 API。将提示词粘贴到输入框。分辨率先设 512x768步数 25 到 30 步。点击生成。预期效果输出一张有人物、有铠甲、有古风背景的图片整体构图和风格描述一致。判断标准人物主体是否清晰铠甲等历史元素是否出现明显变形。背景是否贴合“古战场”描述。如果生成结果出现大量多余肢体、脸部崩坏说明主模型对中文提示词理解有限可以换用英文提示词或配合负面提示词处理。如果输出质量不稳定优先检查是不是模型版本问题而不是马上加 LoRA。5.2 图生图测试甲骨文风格融合第二项测试是图生图目标是把甲骨文的视觉特征融合到已有图片中。测试目的验证 ControlNet 或 img2img 路径是否正常工作甲骨文元素能否作为风格条件参与生成。操作步骤准备一张甲骨文拓片或书法字参考图。在图生图区域上传这张参考图。提示词写“甲骨文纹理青铜器质感篆刻风格背景装饰”。控制重绘幅度在 0.3 到 0.5 之间避免原始构图被完全覆盖。这里的控制参数很关键。重绘幅度太低甲骨文纹理融合不进去太高秦良玉人物本身会被破坏。实际操作时建议先用 0.4 左右跑一张再根据结果微调。判断标准甲骨文纹理是否自然出现在画面中是否与人物之间存在明显割裂。如果纹理像贴纸一样硬贴上去而不是融入画面可能需要用到 ControlNet 的 depth 或 tile 模型让纹理跟随画面结构变化。这一步也是项目最有价值的部分因为“风格融合”才是真正拉开体验差距的地方。5.3 古文字字卡与海报生成接下来把甲骨文当作画面主体来生成字卡或海报。测试目的验证文字图形类内容的生成能力以及后续批量输出基础图库的可行性。输入示例甲骨文“马”字居中排版深色背景金色文字古朴质感字卡设计高清操作步骤以文字描述为提示词生成基础字卡。检查生成的文字笔画是否接近甲骨文风格。如果模型把文字画成乱码可以叠加参考图使用图生图方式修正。这里要提醒一点大模型对“文字字形”的还原能力是有限度的尤其是甲骨文这种非日常字形。想要精准字形更可靠的做法是先做一张字形参考图再通过图生图或 ControlNet 引导生成。单纯靠提示词很难稳定复现准确的甲骨文字形。判断标准最终输出的字卡是否能用于科普、海报、文创场景。如果能直接入库说明这条工作流已经具备生产价值。5.4 分镜素材测试人物一致性做漫剧或短剧分镜时最大的痛点是“同一个角色在不同图片里长得不一样”。项目如果涉及 AIGC 短片制作需要专门测一下人物一致性。测试目的验证固定角色描述能否跨图保持相似性。操作步骤选定一张满意的秦良玉全身像作为角色基准图。写一组分镜提示词例如“秦良玉站在城墙上远望”“秦良玉骑马冲锋”“秦良玉在营帐内查看地图”。每张图都使用同一个角色描述前缀并固定画风关键词。推荐提示词结构角色前缀 动作/场景描述 画风描述 明朝女将军秦良玉穿着明式铠甲长发束起面容坚毅水墨国画风格判断标准多张结果中人物的铠甲、发型、气质是否保持一致。如果偏差明显就需要引入角色 LoRA 或 IP-Adapter 这类角色一致性方案。这一步属于进阶玩法在 100 天项目的后半段出现比较合理。6. 批量任务与 API 调用6.1 批量目录任务设计从“测试单张图”到“批量生产”是整个项目工程化最关键的一步。设计批量任务时建议采用目录输入、目录输出的结构inputs/ ├── oracle_01.png ├── oracle_02.png └── qin_liangyu_ref.png outputs/ ├── result_01.png └── result_02.png批量任务脚本只需要做三件事读取输入目录按规则生成把结果写入输出目录。如果中途失败记录错误日志并继续处理下一项不要因为一张图卡死整个任务。以下是一个批量脚本的通用思路from pathlib import Path import logging input_dir Path(./inputs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) logging.basicConfig( filename./batch.log, levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, ) for index, image_path in enumerate(input_dir.glob(*.png)): try: # 实际调用生成函数这里以占位函数为例 result generate_from_image(str(image_path), promptdefault_prompt) output_path output_dir / fresult_{index:03d}.png result.save(output_path) logging.info(fsuccess: {image_path.name}) except Exception as exc: logging.error(ffailed: {image_path.name}, error: {exc})批量任务里日志比结果更重要。没有日志一旦遇到坏图或内存溢出很难定位是哪一张图导致的问题。6.2 用 FastAPI 封装推理服务项目原版不一定自带 API但通过 FastAPI 把推理封装成 HTTP 服务并不难。这也是把 AI 能力接到自己的工具、网页或小程序里的常用做法。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class GenerateRequest(BaseModel): prompt: str width: int 512 height: int 512 steps: int 25 app.post(/api/generate) def generate_image(req: GenerateRequest): try: # 假设项目里已有的生成函数是 generate() image generate( promptreq.prompt, widthreq.width, heightreq.height, stepsreq.steps, ) # 实际项目里通常会返回图片路径或 base64 内容 return {code: 0, message: success, data: {image: str(image)}} except Exception as exc: raise HTTPException(status_code500, detailstr(exc)) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)封装时要注意图像生成通常比较耗时直接同步返回容易被请求超时拦住。更稳妥的做法是先把任务放进队列返回一个 task_id再用另一个接口查询任务状态。不过在 100 天实践的前期先做同步接口就够了重点是打通 HTTP 调用链路。6.3 客户端调用示例接口起来以后用 Python 或 curl 都能调用。下面是 Python 客户端示例import requests url http://127.0.0.1:8000/api/generate payload { prompt: 明朝女将军秦良玉铠甲水墨风格, width: 512, height: 768, steps: 25, } response requests.post(url, jsonpayload, timeout120) print(response.json())curl 版本curl -X POST http://127.0.0.1:8000/api/generate \ -H Content-Type: application/json \ -d {prompt: 明朝女将军秦良玉铠甲水墨风格, width: 512, height: 768, steps: 25}如果返回结果包含 base64 图片可以在客户端解码保存import base64 data response.json()[data][image] with open(output.png, wb) as f: f.write(base64.b64decode(data))调通之后这个接口就可以被其他工具链复用比如批量网页脚本、公众号配图工具、自动出图机器人。6.4 失败重试与任务队列批量任务和 API 服务都会有偶发失败。最常见的失败原因是显存不足和临时网络错误。建议在客户端加一个简单的重试逻辑import time for attempt in range(3): try: response requests.post(url, jsonpayload, timeout120) response.raise_for_status() break except Exception as exc: print(fattempt {attempt 1} failed: {exc}) if attempt 2: raise time.sleep(5)服务端也要注意不要因为一个请求失败就崩溃。没有用到队列之前至少要做两件事请求参数校验、生成异常捕获。7. 资源占用与性能观察7.1 显存怎么看本地部署 AI 绘图模型显存是第一个瓶颈。启动服务前先记录基线生成任务过程中通过nvidia-smi实时观察nvidia-smi更精细的观察可以隔 1 秒刷新一次watch -n 1 nvidia-smiWindows 下可以用nvidia-smi -l 1重点看两列Memory-Usage 和 GPU-Util。Memory-Usage 决定你还能不能往上加分辨率GPU-Util 决定是否真的在用显卡计算。7.2 哪些参数影响资源占用影响资源占用的因素按影响程度排序分辨率从 512x512 提升到 1024x1024显存占用会成倍增长。步数步数主要影响耗时对显存影响相对小。批量大小一次同时生成多张图显存压力最大。附加模型ControlNet、风格参考、IP-Adapter 都会额外占用显存。视频生成涉及多帧处理显存需求会明显高于单图生成。长文本/多模态输入文本长度对显存影响不大但对内存和处理时间有影响。从项目实践角度看第一次先在 512x512、20 步、批量 1 的条件下跑通再逐步加压。不要一上来就跑 1024 甚至更高分辨率否则很容易出现显存溢出。7.3 CPU 与 GPU 推理差异有显卡的情况下优先用 GPU。CPU 推理虽然能跑但同样参数下耗时可能是 GPU 的几十倍。性能紧张时CPU 模式比较适合做的事是验证代码逻辑、检查项目依赖是否完整、测试 API 返回格式。GPU 模式下如果显存不够可以尝试降低分辨率或减少批量而不是直接换 CPU。7.4 降低显存占用的方法如果遇到显存不足按优先级尝试降低分辨率从 768 降到 640 或 512。减小批量大小改成 batch size 1。关闭 ControlNet 或风格参考模型先跑通主流程。在框架里开启显存优化选项例如低显存模式、模型卸载。清理后台进程关掉浏览器多余标签页和占显存的软件。8. 常见问题与排查方法100 天实践里遇到的坑很大一部分都集中在环境、模型和资源这三块。下面给出一张排查对照表。问题现象可能原因排查方式解决方案启动后页面打不开端口被占用或服务未启动检查终端日志查看端口监听更换端口或杀掉占用进程后重启导入依赖时报错Python 版本不匹配或缺少系统库查看报错堆栈执行python --version切换到项目推荐的 Python 版本重装依赖模型加载失败模型文件路径错误或版本不兼容检查模型目录和启动日志确认模型文件完整并匹配程序版本生成图片速度极慢使用了 CPU 推理或显卡未识别执行nvidia-smi查看日志是否有 CUDA安装匹配的 CUDA 驱动或确认启动参数启用了 GPU显存不足报错分辨率、步数或批量参数过高查看显存占用和报错信息降低分辨率减小批量开启显存优化生成结果人物崩坏模型版本较弱或提示词不准确逐步简化提示词测试换更强的基础模型加负面提示词或引入 LoRAAPI 请求超时单张生成耗时过长检查生成耗时的日志改为异步任务队列或提高客户端超时时间批量任务中途卡住单张图片处理失败导致进程阻塞查看日志和任务目录增加异常捕获和失败跳过记录错误后继续风格参考不生效参考图权重太低或模型不支持检查参数配置调高参考权重或改用 ControlNet 路径排查问题的核心逻辑是先看日志再复现最后改参数。不要一上来就重装环境那样既浪费时间又很可能复发。9. 100 天实践计划与最佳实践9.1 100 天怎么拆项目标题里的“100天”是重点。如果把它当作一个学习计划可以按四个阶段拆第 1 到 30 天环境搭建与基础生成。完成 Python 环境配置、依赖安装、模型下载跑通第一张文生图。这段时间先把提示词基础打牢不要急着碰图生图和 ControlNet。第 31 到 60 天风格融合与主题沉淀。开始做图生图测试把甲骨文元素融入秦良玉题材。找一个固定的画风关键词组确定一套“角色 场景 画风”的提示词模板。这个阶段重点输出一组风格统一的样图。第 61 到 90 天批量生产与接口封装。把单张生成脚本改成批量目录任务加上日志和错误跳过。用 FastAPI 封装 API让外部程序可以调用。如果条件允许开始测试人物一致性方案。第 91 到 100 天复盘与沉淀。整理出一份完整的工作流文档记录项目用到的脚本、模型、提示词模板和踩坑记录。最后做成一个可复用模板后续换其他主题时不需要从零开始。9.2 工程化建议目录管理。模型、输入、输出、日志分开存放不要都堆在项目根目录。qin-liangyu-oracle-ai/ ├── models/ # 模型文件 ├── inputs/ # 输入素材 ├── outputs/ # 生成结果 ├── logs/ # 日志文件 ├── scripts/ # 常用脚本 └── docs/ # 文档和复盘记录配置文件统一管理。把分辨率、步数、提示词、端口这些参数放到一个 JSON 或 YAML 文件里而不是散落在代码中。{ model: qin-liangyu-mix, prompt: 明朝女将军秦良玉铠甲水墨风格, width: 512, height: 768, steps: 25, batch_size: 1, output_dir: ./outputs }批量任务必须加日志和失败重试。批量生成越到后期越长任何一张图出错都不应该中断整体流程。接口服务要限制访问范围。本地调试时 API 监听127.0.0.1即可不要直接暴露到公网。如果必须远程访问至少加一层 Token 校验。定期清理输出目录。批量任务跑几天后输出文件会非常多。建议按任务名和时间建子目录避免所有结果混在一起。10. 总结与下一步这个项目最值得尝试的点是它把“历史主题”和“AI 生成”结合得很具体。秦良玉提供人物和场景甲骨文提供风格和纹理中间再穿插文生图、图生图、批量任务和 API 封装完整覆盖了一条 AI 内容创作的工程链路。如果你也想上手最先要验证的是文生图基础能力也就是用一段秦良玉题材的提示词跑通第一张图。这一步能确认环境没问题、模型能加载、显存够用。然后才是图生图风格融合这是项目最核心也最容易出效果的部分。最容易踩的坑有两个一是显存不足二是模型文件与框架不匹配。显存问题通过降低分辨率和批量大小就能缓解模型版本问题则需要在下载时就要看清来源和说明不要只看文件名。后续可以继续扩展的方向很多自动提示词、ControlNet 深度控制、角色一致性 LoRA、短视频分镜生成、AIGC 短剧素材库、甲骨文主题文创产品图批量输出。这些方向其实都是在当前工作流上做加法100 天之后再回头看最初“能出图”早就不是目标稳定、批量、接口化才是真正拉开差距的地方。建议把这套项目流程先跑通再逐步往自己的业务需求上靠。
返回列表