企业官网建设流程全解析

手书类同人创作看起来是“画一堆图然后剪辑”，但真要把《石纪元》千幻七年if这样的设定做成一支完整视频，就会碰到一连串工程问题：角色在不同镜头里是不是同一张脸、舞蹈动作能不能连续、几十张关键帧怎么批量出、配音和字幕怎么对齐、显卡不够怎么省着跑。这篇文章不聊剧情分析，只把“手书”拆成一条可执行的 AI 辅助生产流程，从环境搭建、角色一致性控制、批量出图到视频合成，给你一套可以直接照做的方案。

先说结论：这套流程不是某个单一软件能完成的，而是由“AI 绘图 + 角色一致性控制 + 批量任务 + 动态化 + 配音 + 剪辑”组合出来的内容生产管线。你不需要写复杂代码，但需要理解每个环节的输入输出，以及最容易翻车的几个点——尤其是角色一致性、显存占用和批量生成的稳定性。下面从能力拆解开始。

1. 核心能力速览

以《石纪元》千幻七年if手书这个项目为例，整条制作流程可以拆成六个环节，每个环节对应一类工具和一组技术约束。

把“做手书”当成一条 pipeline 来看，很多问题就变得可量化：关键帧生成是图像生成任务，动作连续是序列约束任务，配音是 TTS 任务，合成是视频编码任务。每一段都可以单独测试，单独优化。

2. 适用场景与使用边界

这个流程适合以下情况：

• 想做同人手书但不会手绘，希望用 AI 辅助生成画面。
• 已经会用 Stable Diffusion，但需要解决“同一个角色在不同镜头里保持一致”的问题。
• 需要批量出几十张关键帧，不想一张一张手点。
• 想给手书加配音，但暂时没有录音条件，需要 TTS 快速生成参考音轨。
• 想通过 API 把绘图、配音和剪辑串成半自动流程。

不适合的场景也要说清楚：

• 如果你追求完全精确的作画风格，AI 生成的连续性可能达不到手绘标准，需要后期修图。
• 如果你没有角色素材的合法来源，不建议直接抓取第三方图片训练模型。
• 如果你的目标是正式商用或参加商业赛事，请先确认同人授权规则，很多同人设定不允许商业化。

合法合规是底线。同人创作涉及原作角色，使用范围要控制在个人学习、非商业展示、平台允许的同人创作范围内。角色形象、美术风格、音乐素材都要确认授权。涉及声音克隆、真人配音或者对特定声音进行模仿时，必须获得本人授权，不能直接拿别人的声音做合成。发布前要重新确认画面和音频素材的版权状态，避免后续纠纷。

3. 环境准备与前置条件

做这条 AI 手书流程，最核心的环境是绘图服务。下面给出一套通用检查清单，具体版本以你使用的工具为准。

3.1 硬件检查

• GPU：NVIDIA 显卡优先，建议 8GB 以上显存。6GB 显卡也可以跑，但分辨率、模型大小和 batch 数都要保守。
• CPU：只用于数据预处理，不是主要计算单元。没有 GPU 时 CPU 也能推理，但速度会慢很多。
• 内存：16GB 或以上更稳妥。
• 磁盘：模型文件通常需要数 GB 到十几 GB，建议预留至少 20GB 空间。

3.2 软件检查

• Python 3.10 或 3.11，用于 Stable Diffusion WebUI / ComfyUI 运行。
• Git，用于克隆项目仓库。
• FFmpeg，用于视频合成和音频处理。
• NVIDIA 驱动和 CUDA 环境，具体版本以绘图工具要求为准。

3.3 目录结构建议

建议单独建一个工作目录，把输入、中间产物、输出分开，避免几十张图堆在一起。

project_root/ ├── models/ # 大模型、LoRA、VAE ├── inputs/ # 参考图、角色设定图、背景图 ├── outputs/ # 关键帧、视频片段、字幕、最终视频 ├── scripts/ # 批量生成脚本、合成脚本 └── configs/ # 工作流 json、提示词模板

这样的目录结构在批量任务里优势明显：脚本按目录读取输入，按目录写入输出，失败重试时不会把全部文件翻一遍。

4. 安装部署与启动方式

绘图环节建议从 Stable Diffusion WebUI 或 ComfyUI 入手。这里以 WebUI 为例演示通用部署流程，ComfyUI 的方式类似。

4.1 克隆项目并安装依赖

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui python -m venv venv source venv/bin/activate # Windows 下为 venv\Scripts\activate pip install -r requirements.txt

依赖安装耗时较长，建议使用国内镜像源加速。

4.2 准备模型文件

将你选用的底模放入models/Stable-diffusion/目录，角色 LoRA 放入models/Lora/目录。如果你没有现成的角色 LoRA，也可以先用参考图走图生图流程，但一致性会弱一些。

4.3 启动服务

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

启动成功后，浏览器访问http://127.0.0.1:7860。如果端口被占用，换一个端口：

python launch.py --port 7861

如果不需要 Web 界面，只打算用 API 批量提交任务，也要先启动服务，因为 API 依赖同一个后端。

4.4 用 ComfyUI 工作流做关键帧

如果你更习惯节点式流程，ComfyUI 的好处是方便保存工作流参数，换镜头时只改提示词和输入图，其他节点保持不变。你需要先把工作流 json 放进 ComfyUI 的user/default/workflows目录，然后在界面里加载。

ComfyUI 里可以提前封装好“角色一致性检查”的工作流：输入参考图，经过图生图或 ControlNet 控制，输出新镜头关键帧。这样的工作流可以直接复制多份，批量跑不同镜头。

5. 功能测试与效果验证

环境跑起来后，不要直接冲几十张图。先做最小测试，确认每个环节的输出质量稳定，再扩大规模。

5.1 角色设定图测试

测试目的：确认角色形象符合预期，包括发型、服装、配色。

输入示例：

浅雾幻, 石纪元风格, 银紫色长发, 狐狸般微笑, 深色外套, 站姿, 全身, 干净背景, 高细节

操作步骤：

1. 在 WebUI 的 txt2img 页面输入提示词。
2. 分辨率先设 512×768。
3. 采样步数 20 步左右。
4. 生成 4 张，挑选最接近的一张作为角色基准图。

判断是否成功：角色外貌可辨认，画风稳定，没有肢体崩坏。如果这一步都不过关，后面所有镜头都会歪，先调提示词或换模型。

5.2 多视角一致性测试

测试目的：验证角色从不同角度、不同画面构图中仍然保持同一张脸。

操作步骤：

1. 把上一步选中的角色基准图上传到 img2img。
2. 修改提示词描述新姿势、新表情。
3. 重绘幅度控制在 0.4 到 0.6 之间。

如果测试图中脸部“漂移”，优先检查：

• 参考图清晰度是否足够。
• 采样器和步数是否设置过低。
• 是否有适用的角色 LoRA 或 IPAdapter 做特征锁定。

5.3 舞蹈动作连续帧测试

“异常跳舞的女孩”这类镜头最怕动作断裂。先用 5 张关键帧做小规模测试，不要上来就生成 20 张。

操作步骤：

1. 确定舞蹈动作的起止状态。
2. 按时间顺序拆出 5 个关键姿势。
3. 每一张都用上一张作为参考图输入到 img2img，逐步变化。
4. 检查每两张之间的姿势差异是否过大，过大则增加中间帧。

判断成功标准：连续播放 5 张图时，动作变化是渐进的，而不是突变。

5.4 视频合成验证

生成连续帧后，先用 FFmpeg 合成一段短预览：

ffmpeg -framerate 8 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p preview.mp4

这里的frame_%04d.png是连续帧命名规则，8 帧每秒是手书常用低帧率。如果画面有明显跳变，回到上一步补充中间帧。

6. 接口 API 与批量任务

单张出图适合测试，批量出图必须走 API。SD WebUI 启动时默认启用/sdapi/v1/txt2img和/sdapi/v1/img2img接口，可以用脚本批量提交。

6.1 文生图批量生成脚本

下面是一个通用 Python 调用示例，实际地址和参数需要按你本机的接口版本调整。

import requests import json import time api_url = "http://127.0.0.1:7860/sdapi/v1/txt2img" prompts = [ "浅雾幻, 跳舞, 姿势1, 舞台灯光, 高细节", "浅雾幻, 跳舞, 姿势2, 舞台灯光, 高细节", ] for idx, prompt in enumerate(prompts): payload = { "prompt": prompt, "negative_prompt": "lowres, bad anatomy, extra fingers", "width": 512, "height": 768, "steps": 20, "batch_size": 1, "n_iter": 1, } response = requests.post(api_url, json=payload, timeout=300) if response.status_code == 200: data = response.json() with open(f"outputs/frame_{idx:04d}.png", "wb") as f: f.write(base64.b64decode(data["images"][0])) print(f"frame {idx} done") else: print(f"frame {idx} failed: {response.status_code}") time.sleep(1)

脚本里prompts列表可以改成从文本文件读取，便于维护镜头表。建议每张图之间加time.sleep(1)，避免短时间请求过多导致服务不稳定。

6.2 图生图批量关键帧

对连续镜头，用 img2img 接口把上一帧作为输入：

import base64 import requests import json def img2img(input_path, prompt, output_path): with open(input_path, "rb") as f: img_b64 = base64.b64encode(f.read()).decode("utf-8") payload = { "init_images": [img_b64], "prompt": prompt, "denoising_strength": 0.5, "width": 512, "height": 768, "steps": 20, } response = requests.post( "http://127.0.0.1:7860/sdapi/v1/img2img", json=payload, timeout=300, ) if response.status_code == 200: data = response.json() with open(output_path, "wb") as f: f.write(base64.b64decode(data["images"][0])) return True return False

使用图生图时，denoising_strength是关键参数。数值太高会偏离参考图，数值太低则动作变化不明显。建议在 0.4 到 0.6 区间测试。

6.3 批量任务队列建议

批量生成几十张图时，直接在循环里逐个请求不够健壮。更稳妥的做法是：

1. 先把所有镜头的提示词和输入路径写入一个 JSON 配置。
2. 脚本顺序读取并生成。
3. 每张图生成后保存单独日志。
4. 失败任务重试 2 到 3 次；仍失败则记录失败原因，不中断整个队列。

{ "shots": [ { "type": "txt2img", "prompt": "浅雾幻, 跳舞镜头1, 正面", "output": "outputs/shot_001.png" }, { "type": "img2img", "input": "outputs/shot_001.png", "prompt": "浅雾幻, 跳舞镜头2, 侧面", "output": "outputs/shot_002.png" } ] }

这样做的核心价值是断点续跑：某一帧失败时，不会把前面已经生成的结果覆盖掉。

6.4 配音与字幕处理

手书需要配音时，可以单独起一个 TTS 服务。这里以通用 HTTP 接口为例，提交文本返回音频文件。具体工具和参数以你选用的 TTS 项目文档为准，不要假设所有 TTS 服务的接口都一样。

curl -X POST http://127.0.0.1:5000/tts \ -H "Content-Type: application/json" \ -d '{"text": "七年之后的我们，还是走到了这一步。", "voice": "zh-CN-XiaoxiaoNeural"}' \ --output voice_001.mp3

音频生成后，结合 FFmpeg 将音频拼到视频上：

ffmpeg -i preview.mp4 -i voice_001.mp3 -c:v copy -c:a aac -shortest output.mp4

字幕可以用常见剪辑软件直接加，也可以生成 SRT 文件后批量合成。字幕对齐需要按音频实际时长调整，建议先导出音频听一遍再卡时间轴。

7. 资源占用与性能观察

手书类项目最大的资源瓶颈在绘图阶段。下面给出性能观察和降载的思路。

7.1 显存占用怎么看

启动绘图服务后，用 NVIDIA 自带工具实时查看：

nvidia-smi

重点看进程对应的显存占用。显存占用的高低与四个因素直接相关：

• 底模参数量。
• 输出分辨率。
• batch size。
• 是否同时加载了多个 LoRA。

分辨率从 512×512 提高到 1024×1024，显存占用通常会有明显上升。实际数值以你本机测试为准，不要只看别人的配置就照搬。

7.2 如何降低显存占用

如果显存不足，按优先级调整：

1. 降低分辨率，从 512×512 或 512×768 开始。
2. 把 batch size 设为 1。
3. 减小输出批次n_iter。
4. 关闭不需要的扩展插件。
5. 有分辨率插件或分块绘制机制时，按工具文档启用。
6. 关掉其他占用显存的程序。

7.3 CPU 推理的取舍

没有 NVIDIA 显卡时，CPU 也能跑，但速度会慢很多。建议只在测试阶段用 CPU 跑一两张验证效果，正式批量生成仍然建议用 GPU。如果你的机器是 Mac，可以关注对应工具的 Apple Silicon 支持情况，不同框架差异较大，需要单独查文档。

7.4 端口和进程残留

批量任务跑完，服务进程可能仍占着显存和端口。下次启动前，先查看端口占用：

lsof -i :7860

如果端口被占用，要么杀掉旧进程，要么换端口启动。

8. 常见问题与排查方法

排查原则是从日志开始，不是从设置开始。绘图服务启动时控制台会打印大量信息，遇到任何异常，先把控制台日志完整看一遍。

9. 最佳实践与使用建议

9.1 第一次先小规模验证

不要一上来就批量生成 50 张关键帧。先用 5 张走完整个流程：绘图 → 关键帧 → 合成预览 → 配音 → 输出 mp4。任何环节出了问题，都能在小范围内快速定位。

9.2 保留一套最小可运行配置

当你找到合适的提示词、采样器、分辨率和重绘幅度后，把参数整理成配置模板。后续新镜头只改提示词和输入图，不反复调试基础参数。

9.3 文件按“输入 / 中间产物 / 输出”分开管理

脚本运行时统一从inputs读取参考图，把过程图和结果图写入outputs。避免把参考图、生成图、废图混在一起，否则批量任务很难追踪。

9.4 批量任务必须加日志和失败重试

批量生成时，建议每张图都打一条日志，包含文件名、耗时、是否成功。失败任务重试 2 到 3 次，仍失败就跳过并记录原因，最后统一处理。

9.5 接口服务限制访问范围

本地 API 服务建议绑定127.0.0.1，不要直接暴露到公网。如果确实需要局域网访问，要加上访问控制，避免被别人直接调用你的推理资源。

9.6 合规红线要提前确认

同人创作不是无限制使用角色形象的理由。发布前需要确认：

• 是否在原作者和平台允许的同人创作范围内。
• 是否包含商业用途。
• 是否涉及他人肖像或声音。
• 是否包含不适合公开展示的内容。

所有 AI 生成素材、配音素材、背景音乐都要有合法的来源或授权，这是发布前必须做的一道检查。

10. 总结与下一步

这支《石纪元》千幻七年if手书，最有价值的地方不是它作为同人作品的内容设定，而是它完整踩过了 AI 辅助内容生产的所有核心节点：角色一致性、批量关键帧、动作连续性、配音和视频合成。你如果也想做一支类似的手书，最先要验证的不是画质，而是角色在不同镜头里能不能保持“同一张脸”。这个测试不过关，后面批量出多少张都是在浪费时间。

最容易踩的坑有三个：第一是角色一致性，第二是批量生成时任务稳定性，第三是音画合成的对齐问题。前两个都可以用“小批量测试 + 日志 + 重试”解决，第三个需要把音频和视频画到同一时间轴上看节奏。

下一步可以继续扩展的方向包括：用更完整的角色 LoRA 做更细的表情控制；用 ControlNet 或 AnimateDiff 做局部动态效果；把整条流程封装成带配置文件的自动化脚本；如果要做成系列手书，还可以设计统一的镜头脚本模板，实现“一次配置，多集复用”。

建议先跑通“5 张关键帧 + 一段配音 + 一条 8fps 预览视频”，再逐步加大规模。