从LLM到ComfyUI：AI短剧内容生产全链路实践

这次我们来看一个比较特殊的“项目”。标题是：李七夜穿越外星海洋末世，困守四平方米锈铁浮台，靠生存系统把异世界伪装成全息游戏，召唤蓝星玩家降临。

先说明：这不是一个开源仓库，也不是某个现成框架，而是一个带有明显网文/短剧属性的设定，并且规划了 1-2 季。放到 CSDN 的语境里，真正值得拆解的不是剧情走向，而是它背后那条完整的 AI 内容生产链路：文本、画面、声音、动态视频、游戏化外壳、批量任务和接口服务，能不能用现有工具组合起来做出来。

这篇文章不讨论文学价值，只讨论工程落地。我会按一条可执行的内容生产线来展开：先用大语言模型做多季章节批量生成，再用 ComfyUI 工作流解决“四平方米锈铁浮台”和“李七夜”的角色/场景一致性，接着接 TTS 配音、图生视频，最后用一个 Web 面板把“生存系统伪装成全息游戏”的交互外壳搭起来。文中会给出环境准备、部署步骤、API 示例和排错清单。如果读者目标是做 AI 短剧、互动叙事或批量内容生产，这篇文章可以直接收藏。

1. 核心能力速览

这个设定的关键词可以拆成几个技术模块：穿越外星海洋末世、四平方米锈铁浮台、生存系统、伪装成全息游戏、召唤蓝星玩家、1-2 季长篇。落实到 AI 内容生产，大致对应如下能力：

这些能力不是在一个仓库里现成的，而是要用多个开源工具和少量工程代码拼装。文本和图片部分可以直接用开源模型，Web 外壳需要自己写，任务队列和 API 是常规工程问题。整体上，这是一个“用 AI 工具链批量生产多季内容”的实践样例，适合用来验证工作流，而不是开箱即用的一体化产品。

2. 适用场景与使用边界

这套管线比较适合三类人：第一类是网文作者，想批量扩写章节，同时生成角色立绘、场景封面和宣传图；第二类是 AI 短剧或微短剧团队，想做一个“设定可视化 + 批量分镜”的 Demo，快速验证一个 IP 能不能做成短视频内容；第三类是独立开发者，想实践“LLM + ComfyUI + API + Web”的组合管线，熟悉本地部署、批量任务和接口调用。

不适合的场景也要说清楚。它不适合当一个真实游戏引擎来用，标题里的“全息游戏”更多是叙事包装，工程上能做的是 Web 端的游戏化面板；它也不适合完全无人审校的自动生产，长文本、视频、配音这些结果都需要人工复核；如果要追求影视级特效，这套本地工具链的表现也有限。

合规边界是重点。生成角色图片时，如果参考了真人演员形象，必须获得授权；声音克隆更是如此，不能把某个真人歌手或主播的音色拿来直接做商业化内容。图片素材要避免使用未授权的版权图，模型使用前要检查协议是否允许商用。公开发布的内容建议加“AI 生成”标识，尤其是向平台投稿或商业发布时，这个环节不能省。

3. 环境准备与前置条件

本地部署这套管线，先按通用环境准备，不要一开始就追求高配置。

操作系统方面，Windows 10/11 和 Linux 都可以。Python 建议 3.10 或更高，具体版本以你使用的工具官方说明为准。GPU 优先选 NVIDIA 显卡，需要安装匹配的显卡驱动和 CUDA 环境。显存需求取决于你选的模型版本、分辨率和并发数量，不要在准备阶段就轻信“某张卡一定能跑某个模型”，实际占用要以本机测试为准。

磁盘空间按内容规模留。基础模型文件通常几 GB 到几十 GB，如果还要训练 LoRA、保存大量生成图片和视频，建议至少留出 100GB 以上空间，尤其是有多季生产计划时。

启动服务前先检查环境：

nvidia-smi python --version

# Windows PowerShell 下也可以用 nvidia-smi python --version

端口规划建议提前做好。例如文本生成服务用 8000，ComfyUI 默认是 8188，Web 外壳用 8080，具体以实际启动日志为准。如果某个端口被占用，就把对应服务的启动参数改一下，不要硬等。

模型文件要从合法渠道获取。文本模型和图像模型可以从 Hugging Face、ModelScope 等正规模型平台下载，注意核对模型协议的授权要求，尤其要确认是否允许商用。不要下载来源不明的修改版模型，既有安全风险，也可能有版权问题。

4. 文本层：多季章节与剧本批量生成

文本生成是整个管线的基础。先写一个系统提示词，把世界观、主角处境、生存系统规则和“伪装成全息游戏”的核心设定固化下来，然后用脚本批量生成章节。

假设你本地已经启动了一个兼容 OpenAI 格式的 LLM 服务，接口地址可能是http://127.0.0.1:8000/v1/chat/completions，具体以你使用的服务为准。下面是一个批量生成章节的 Python 示例：

import requests import os API_URL = "http://127.0.0.1:8000/v1/chat/completions" OUTPUT_DIR = "./novel_text" os.makedirs(OUTPUT_DIR, exist_ok=True) chapter_synopsis = [ "第一章 锈铁浮台：李七夜确认生存系统的奖励机制", "第二章 第一个蓝星玩家：坐标对接成功，玩家开始进入异世界", "第三章 玩家怀疑这是真实世界：李七夜必须维持全息游戏伪装", ] system_prompt = ( "你是科幻末世题材小说作者。设定：李七夜穿越到外星海洋末世，" "困守四平方米锈铁浮台，靠生存系统把异世界伪装成全息游戏，" "召唤蓝星玩家降临。每章写5000字中文，保持生存系统和玩家玩法的一致性。" ) def generate_chapter(synopsis: str) -> str: payload = { "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": synopsis} ], "temperature": 0.8, "max_tokens": 2000 } r = requests.post(API_URL, json=payload, timeout=300) r.raise_for_status() return r.json()["choices"][0]["message"]["content"] for i, synopsis in enumerate(chapter_synopsis, 1): text = generate_chapter(synopsis) with open(os.path.join(OUTPUT_DIR, f"chapter_{i:03d}.md"), "w", encoding="utf-8") as f: f.write(text) print(f"chapter {i} done")

这个脚本会按章节大纲逐个生成，输出到novel_text目录。接口路径、返回字段和超时时间都要按实际服务调整。

多季内容管理建议用 JSON 大纲驱动。先定义季数和主线节点，再让脚本按节点展开：

{ "season": 1, "title": "锈铁浮台", "episodes": [ "第一章 锈铁浮台", "第二章 第一位玩家", "第三章 生存系统升级" ] }

批量任务最大的问题是长文本生成不稳定。章节长度、角色语气、规则一致性都可能漂移。验证标准很简单：生成后随机抽一章，检查“生存系统规则有没有前后矛盾”“伪装全息游戏有没有被意外拆穿”“章节长度是否达标”。批量任务建议加失败重试：

import time for attempt in range(3): try: text = generate_chapter(synopsis) break except requests.RequestException as e: print(f"attempt {attempt + 1} failed: {e}") time.sleep(10)

文本层跑通以后，后续的视觉、配音、视频都会围绕这些章节内容展开。

5. 视觉层：浮台场景与角色一致性的 ComfyUI 工作流

视觉层是这套设定最容易出效果的部分。核心问题是两个：场景一致性，也就是“四平方米锈铁浮台”每次生成都像同一个地方；角色一致性，也就是“李七夜”每次出现都像同一个人。ComfyUI 是目前组合这些能力比较顺手的工具。

安装 ComfyUI 之后，先准备一个基础图像生成模型，比如 Stable Diffusion 系列检查点文件，放到models/checkpoints目录。启动方式一般是：

python main.py

启动成功后访问http://127.0.0.1:8188，就能看到 WebUI。浏览器访问的地址以启动日志为准。

先用文生图测试场景。正向提示词可以写：

a rusty iron floating platform, four square meters, alien ocean, apocalyptic, storm, overcast, cinematic lighting, wide shot

负向提示词写：

blurry, low quality, deformed, watermark, text

步数先设 20 到 30，分辨率不要一开始就开太高，先 512x512 或 768x512，确认构图没问题再放大。

角色测试建议单独生成。给“李七夜”固定一套描述词：

a young man in dark survival suit, determined expression, long black hair, standing on rusty iron floating platform, full body, concept art

角色一致性有三个常用手段。固定随机种子是最基本的；保存工作流 JSON，记录所有参数；如果要长期使用同一个角色，可以训练一个 LoRA。对于 1-2 季的长内容生产，LoRA 是更稳定的方案，但 LoRA 训练需要额外时间和素材准备。

ComfyUI 还支持 API 模式，方便批量提交任务。用 Python 把工作流 JSON 提交到 ComfyUI 接口：

import json import requests from pathlib import Path workflow_path = Path("workflow/four_sqm_platform.json") workflow = json.loads(workflow_path.read_text(encoding="utf-8")) # 节点 ID 要以你导出的工作流为准，这里只是通用示例 workflow["6"]["inputs"]["text"] = "a rusty iron floating platform, four square meters, alien ocean, apocalyptic, cinematic light" workflow["3"]["inputs"]["seed"] = 20250801 resp = requests.post( "http://127.0.0.1:8188/prompt", json={"prompt": workflow}, timeout=60 ) print(resp.status_code, resp.json())

节点 ID 必须按你实际工作流里的节点编号替换。ComfyUI 的prompt接口是常见提交入口，但不同版本可能略有差异，出问题先查启动日志。

图像层的验证标准比较直观：场景图连续生成 10 张，看浮台结构、海洋颜色、天气氛围是否一致；角色图连续生成 10 张，看五官、服装、气质是否统一。如果角色忽老忽少、服装频繁变化，说明描述词不够固定，或者需要使用 LoRA。

6. 语音层：角色配音与情绪控制

视觉层跑通后，可以给“李七夜”和“生存系统”配音。开源 TTS 方案里，Coqui TTS、XTTS v2 这类工具可以做参考音频克隆，也可以用国内商业 TTS 的 API，看项目预算和部署条件。

测试 TTS 时，先准备一个 3 到 10 秒的干净人声参考音频。参考音频越干净，克隆出来的音色越稳。如果工具要求固定采样率，提前把音频转成对应格式。

配音测试可以分几个维度：

• 参考音频测试：用同一段参考音频，生成“生存系统提示音”和“李七夜台词”，检查音色是否统一。
• 长文本测试：把一章小说转成语音，观察断句、停顿和末尾语气是否自然。
• 多音字测试：类似“重”“行”“传”这类多音字，看 TTS 是否读对。
• 情绪控制：目前很多 TTS 对情绪的控制不稳定，有的靠提示词，有的靠参考音频引导，需要人工试听确认。

示例文本可以直接用设定台词：

生存系统已连接，第一位玩家正在确认坐标。

如果要在视频层使用，建议按句拆分成多个音频文件，方便后续对齐画面。

合规方面要特别强调：不要克隆未授权真人音色，尤其是明星、主播、其他作者的声音。不管技术上行不行，授权是第一道门槛。发布到公开平台时，也要注意平台对 AI 合成声音的规则。

7. 动态层：视频生成与数字人表现

有了场景图和角色图，下一步就是让画面动起来。现在常用的路线有两条：一是图生视频，把“锈铁浮台”静态图作为首帧，让模型生成海浪拍打、乌云移动、镜头缓慢推进的动态片段；二是首尾帧生成，如果工具支持，提供第一帧和最后一帧，减少画面突变。

实际测试时，先选一段短内容跑通：

• 用一张浮台场景图生成 3 到 5 秒的视频，观察主体是否形变。
• 用“李七夜”角色图生成一个转身或抬头动作，观察脸部是否崩坏。
• 如果要补帧和超分，可以接入视频插帧工具，提升流畅度。

视频生成对显存和内存的要求比图像高很多。同一个模型，在低分辨率下先跑通流程，再逐步提高分辨率。一次不要并发太多任务，否则很容易直接把显存占满。

数字人口播是另一个可选方向。如果想做“生存系统公告”或“玩家引导”这类讲解型内容，可以把 TTS 音频和数字人形象合成，生成一段虚拟角色播报视频。这属于完成度更高的生产方式，但参数更多，建议放到基础图文流程跑通后再做。

这里必须再次强调授权问题。不要用未经授权的真人影像做视频合成，尤其不要做换脸、仿冒身份类内容。对外发布前，确认素材版权归属和平台规则。

8. 交互层：把异世界伪装成全息游戏的 Web 外壳

小说设定里“把异世界伪装成全息游戏”，工程上可以落成一个 Web 单页应用：打开页面后，用户看到的不再是普通小说文本，而是一个生存游戏面板，包含任务、资源、生存积分、玩家列表。这部分需要少量后端代码。

先用 Flask 写一个简单的任务接口：

from flask import Flask, jsonify app = Flask(__name__) @app.route("/api/task") def task(): return jsonify({ "title": "修复锈铁浮台的淡水收集器", "description": "外星海洋的侵蚀导致淡水装置故障，需要收集3份海雾结晶。", "reward": "生存积分+50" }) if __name__ == "__main__": app.run(host="127.0.0.1", port=8080)

这个接口返回一个游戏化任务，前端页面用 fetch 获取并展示：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>生存系统面板</title> </head> <body> <h1 id="task-title">正在连接生存系统...</h1> <p id="task-desc"></p> <p id="task-reward"></p> <script> async function fetchTask() { const res = await fetch("http://127.0.0.1:8080/api/task"); const task = await res.json(); document.querySelector("#task-title").textContent = task.title; document.querySelector("#task-desc").textContent = task.description; document.querySelector("#task-reward").textContent = "奖励：" + task.reward; } fetchTask(); </script> </body> </html>

把页面文件放在同一目录，用任意 HTTP 服务打开即可：

python -m http.server 8080

注意这里如果同时用到 Flask 和静态页面，端口不能冲突。更合理的做法是 Flask 既提供接口又托管静态文件，或者前端用独立的静态服务。接口路径、返回字段都可以按自己需求改。

这个外壳的核心不是视觉效果，而是“数据流”：后端生存系统逻辑返回任务和资源，前端把它包装成全息游戏界面。后续可以把文本生成、图片生成的结果都挂到这个面板里，让每一章内容像游戏支线任务一样被解锁。

9. 资源占用与性能观察

本地部署这条管线，资源占用必须实际观察，不能只看估计值。

文本生成阶段，并发请求越多，显存和内存占用越高。如果本地没有大显存，第一版可以把并发数限制为 1，跑完一个章节再跑下一个。观察资源占用可以用：

nvidia-smi -l 2

这个命令每 2 秒刷新一次显存使用，能同时看到显存占用和 GPU 利用率。Windows 下也可以打开任务管理器的“性能”页观察。

图像生成阶段，显存占用和分辨率、步数、模型大小、批量数量直接相关。第一次跑图，用低分辨率、少步数、批量 1，先看能不能正常加载模型。如果显存不够，优先降分辨率，其次减少步数，再考虑使用半精度或量化版本。

视频生成阶段通常比图像更吃资源。一个 3 到 5 秒的短视频，在生成过程中可能长时间占用高显存。建议一次只提交一个视频任务，不要同时开多个视频生成进程。

CPU 推理不是完全不行，但速度会慢很多，尤其是图像和视频。文本和 OCR 类任务，CPU 还能接受；图像、视频生成尽量用 NVIDIA GPU。如果只有 CPU，可以先跑通流程，再决定是否需要升级硬件。

降低资源占用的常用套路包括：半精度推理、低分辨率生成、减少并发、关闭不用的后台服务、用 API 跑批量任务时限制请求速率。每次调整参数后，记录前后对比，找出一套“质量可接受、显存够用”的配置。

10. 常见问题与排查方法

实际操作中，问题大多集中在依赖安装、模型加载、显存和 API 调用几个环节。下面是一份通用排查清单：

遇到问题时，先看日志，再改配置。不要一次性改多个变量，否则很难定位原因。批量任务尤其要注意：加日志、加大任务超时、写失败重试，才能长时间稳定运行。

11. 最佳实践与合规使用建议

工程化地做这类内容生产，建议从一开始就建立规范。

第一，先跑通最小链路，再上批量。第一次不要做 20 章、50 张图，先跑通“1 章文本 + 1 张场景图 + 1 段配音 + 1 个 API 返回”，确认每个环节都稳定，再扩大规模。

第二，目录结构要清晰。建议按项目分目录管理：

projects/li_qi_ye/ ├── season_01/ │ ├── text/ │ ├── images/ │ ├── audio/ │ ├── video/ │ └── workflow/

模型文件、输入素材、输出结果分开放，避免后期找不到文件。

第三，记录关键参数。ComfyUI 工作流 JSON、固定 seed、模型版本、LoRA 权重、提示词模板都值得保存。批量任务一旦出现效果漂移，可以直接对照参数定位问题。

第四，API 服务只绑定本地地址。开发阶段用127.0.0.1，不要随意暴露到公网。如果要远程访问，至少加鉴权，否则批量任务接口很容易被滥用。

第五，合规红线要把牢。涉及真人肖像、声音、版权素材时，必须确认授权。不要合成未经授权的真实人物内容，不要用未授权素材做商业发布。公开内容建议标注“AI 生成”或“虚构创作”，避免误导。

12. 总结与下一步

这个设定真正值得先验证的是两条链路：一条是 LLM 批量生成“生存系统 + 玩家召唤”相关章节，另一条是 ComfyUI 里的角色与场景一致性。先把这两个跑通，后续的视频、配音、Web 外壳只是扩展。

最容易踩的坑有三个：角色一致性不稳定、显存估算不准、依赖版本不匹配。这三个坑都会浪费大量调试时间，所以第一步不要追求多，先把最小链路跑稳定。

下一步可以这样做：选一个 1-2 季大纲，生成第一季第一到第三章文本；用 ComfyUI 生成 5 张“四平方米锈铁浮台”场景图和 10 张李七夜角色图；再用 TTS 生成生存系统公告；最后挂到 Web 面板里，让用户像打开游戏一样查看章节任务。走完这一轮，整套装线的能力边界就清楚了，后续再谈商业化或内容量产也不迟。