CoC跑团Replay制作全流程：从Log清洗到AI配音与视频封装

从《卡森德拉的黑色嘉年华》第 55 回这种长篇连载跑团 Replay 切入很多人关心的问题其实不是“剧情讲了什么”而是“这种动辄几十集的 Replay 是怎么稳定产出、不会断更的”。作为路过技术区的观众今天不聊模组剧透只聊一个更实在的方向把 CoC 跑团 Replay 当成一个内容工程来做从 Log 文本整理、AI 配音、场景图生成到字幕封装每一步有哪些工具、要踩哪些坑、怎么用最低的成本把流程跑起来。整个系列能连载到“晚安被命运击落的海燕”这个阶段说明制作侧的流程已经相当稳定。对想自己做 Replay 的新人来说最值得学习的不是某一期的特效有多花而是这套“稳定生产”的工作流输入是跑团语音记录或文字 Log中间经过文本清洗、分句、角色标注、语音合成、配图生成、字幕对齐最后输出一条可发布的横屏视频。本文就把这条流水线拆开讲并给出一套可以直接复制的工具链思路。1. CoC 跑团 Replay 项目核心能力速览先给一张速览表把“做一个跑团 Replay”需要关心的核心维度列清楚。这里的参数不是某个固定工具的官方参数而是按常见制作流程给出的参考范围实际数值要根据你本机的模型版本、采样分辨率和素材大小重新测。能力项说明项目类型CoC 跑团 Replay 视频制作流程输入素材跑团语音记录、跑团 Log 文本、骰点记录、玩家口述对话主要产出带配音、配图、字幕、音效的横屏叙事视频核心环节Log 文本清洗、角色对话分句、AI 语音合成、场景图生成、字幕对齐、剪辑封装硬件门槛纯文本 云端 TTS 流程对显卡要求很低本地 SD 绘图建议 8G 以上显存本地 TTS 或大模型总结建议 12G 以上显存显存占用不确定需按实际模型版本测试绘图和本地 TTS 是主要占用来源支持 CPU 推理文本清洗和剪辑可纯 CPU本地图像生成与 TTS 用 CPU 可用但速度较慢批量任务文本分句、批量生成音频、批量渲染图片、FFmpeg 批量封装均可脚本化接口能力TTS 服务多数提供 HTTP APISD 可通过 WebUI/ComfyUI 的 API 调用适合场景长篇跑团 Replay 连载、模组剧情可视化、语音小说制作、TRPG 内容二创这套流程最大的优势是“可拆分”。Log 整理、配音、画图、剪辑四部分互相独立可以分批做、断点续做也能多人协作。第 55 回这种长篇连载本质上就是一条持续运转的内容流水线而不是单次手工制作。2. 适用场景与使用边界跑团 Replay 的适用人群主要有三类跑团主持人KP和玩家想把自己真实的跑团过程记录下来做成能反复看的视频。TRPG 剧情解说 UP 主希望把长模组的剧情用更电影化的方式呈现提升观看体验。音频 / 视频内容创作者把手头已有的跑团语音素材或文字 Replay 记录重新包装成有声内容。这个流程能解决的核心问题是“如何把几小时的即兴对话变成有结构、有视觉、有节奏的视频内容”。跑团实录往往包含大量闲聊、跑题和重复直接剪辑会非常耗时。通过文本化处理后重新组织可以把叙事节奏控制得更紧也更适合观众观看。不适合的场景也要说清楚不适合追求“实时原声现场感”的观众因为 AI 配音和补录会改变原始氛围。不适合对画面精细度要求极高的“电影级重制”它更适合中低成本的中长视频。不适合直接搬运未授权模组内容或未经授权的声音素材。合规边界是硬性的。CoC 模组文本通常有版权重写和解说时要确认模组作者是否允许二次创作使用真实玩家录音时要在录制前征得同意使用 AI 声音克隆时必须获得声音本人的明确授权。不能拿陌生人的声音去合成对白也不能用真人配音音频做未经许可的音色训练。图片素材也一样如果要商用或公开发布要避免直接使用版权不明的美术资源。3. 制作 Replay 的环境准备与前置条件Replay 制作不是单一个软件而是一组环境的组合。从零搭建时建议按下面这个清单做检查。首先是操作系统。Windows、macOS、Linux 都可以做但 Windows 是相对省心的选择绝大部分一键包和整合包都优先支持 Windows。如果要用 ComfyUI 或本地大模型Windows 下驱动和 CUDA 的问题也好解决一些。其次是 Python 环境。文本处理、TTS 调用、图片生成脚本大多依赖 Python 3.10 到 3.11。安装时要特别注意包版本冲突建议在项目目录下单独创建虚拟环境不要直接装到系统 Python 里。显卡方面如果走“云端 TTS 在线绘图”路线核显也能完成剪辑和字幕工作如果走“本地 Stable Diffusion 出图 本地 TTS 配音”一张 8G 显存的 NVIDIA 显卡是比较舒服的起步配置。A 卡和 Intel 显卡不是不能用但不少成熟的 ComfyUI 节点和 TTS 项目会优先适配 CUDAA 卡用户需要多看加速文档踩坑成本会高一些。磁盘空间主要花在三个地方Python 虚拟环境和依赖包约 10G 到 20G 空间。本地图像模型SD 1.5 系列模型文件 4G 左右SDXL 系列 7G 左右。中间产物音频、图片、字幕、渲染缓存一集 20 分钟的视频可能产生几十 G 的临时文件。端口也是一个容易忽略的点。ComfyUI 默认监听 8188 端口SD WebUI 是 7860部分 TTS 项目用 8000 或 9880如果本地已经跑着其他服务启动前先检查端口占用避免出现“服务启动了但页面打不开”的问题。4. Log 文本清洗与分句处理Replay 视频的第一步不是录音而是把文本弄干净。跑团 Log 一般包含玩家昵称、动作描述、旁白、对话、骰点记录这些混在一起的内容。要变成 TTS 能用的分句文本通常要经过三步清洗、角色分离、分句。清洗环节要删掉刷屏的掷骰命令、重复的空行、时间戳、非剧情讨论。角色分离要标记出哪个昵称对应哪个角色方便后续为不同角色分配不同音色。分句则是按标点符号把长段文字切成短句因为 TTS 对过长文本的处理稳定性较差短句更容易控制语速和停顿。这里给一个简单的 Python 清洗脚本示例实际使用时要根据自己的 Log 格式调整正则和角色映射表import re RAW_LOG logs/raw_session_55.txt CLEAN_LOG logs/clean_session_55.txt # 昵称到角色名的映射按实际车卡情况修改 PLAYER_MAP { KP: kp, 海燕: haiyan, 鲨鱼: shayu, 猫猫: maomao, } # 需要过滤的噪声行 NOISE_PATTERNS [ r^\d{2}:\d{2}:\d{2}, # 时间戳 r^【.*?】, # 系统提示块 r^\[.*?\], # 动作代码块 r^\s*(骰|检定|伤害|命中|失败|成功|大失败|大成功), # 骰点摘要 ] def clean_line(line: str) - str | None: line line.strip() if not line: return None for pattern in NOISE_PATTERNS: if re.search(pattern, line): return None # 把昵称行转换为角色名保留正文 for nick, role in PLAYER_MAP.items(): if line.startswith(nick): body line[len(nick):].lstrip(:\s) return f{role}: {body} return None with open(RAW_LOG, r, encodingutf-8) as f: lines f.readlines() cleaned [] for line in lines: result clean_line(line) if result: cleaned.append(result) with open(CLEAN_LOG, w, encodingutf-8) as f: f.write(\n.join(cleaned)) print(f清洗完成保留 {len(cleaned)} 行有效文本)清洗完成后再做分句。一个简单可靠的做法是先把“角色: 内容”按角色分组再把每个角色的长段内容按句号、问号、叹号切分成短句。这样后续喂给 TTS 时每个音频片段对应一句字幕对齐也方便。5. AI 配音与 TTS 工具链选择配音是 Replay 观感提升最明显的一环。从技术方案上可以分成三种路线。路线一在线 TTS 服务使用微软 Edge TTS、阿里云、腾讯云等在线语音接口。优点是配置简单、音色稳定、不占本地显存缺点是需要网络且批量调用有配额限制。Edge TTS 因为免费且调用方便很多制作组会拿来做旁白和路人角色音色。用 Edge TTS 时需要注意它的服务条款免费接口不建议做大规模商用或高频轮询。批量合成时建议控制并发数避免触发限流。路线二本地开源 TTS对角色声音一致性要求高的 Replay本地 TTS 是更好的选择。常见的思路有ChatTTS对话场景自然度较好适合日常对白。GPT-SoVITS支持少样本音色迁移可以固定角色音色但需要一定的配置成本。Fish Speech英文和中文支持都可以API 调用比较方便。本地 TTS 的核心问题是音色授权。如果你要用某个真人声线做固定角色必须有声音本人的书面授权。用开源模型自带的预设音色或自己合成的原创音色则不存在这个问题。路线三真人配音 AI 辅助对质量要求更高的团队可以让玩家自己补录对白再用 AI 做音频降噪、对齐和音效增强。这种方案最自然但成本和沟通成本也最高。不管选哪条路线建议在工程上统一用“角色名 → 音频文件”的目录结构来管理素材assets/audio/haiyan/001_晚安海燕.wav assets/audio/haiyan/002_命运从那天开始倾斜.wav assets/audio/shayu/001_你想清楚了吗.wav assets/audio/kp/001_夜色中的卡森德拉依旧潮湿.wav这样后续剪辑时可以直接按文件名把音频片段拖进时间线不会出现“不知道这句是哪段”的问题。给一个简单的本地 TTS Python 调用模板。不同项目的接口差异很大这里只是示意路径和参数需要按你实际使用的模型调整import requests TTS_URL http://127.0.0.1:9880/tts payload { text: 夜晚的卡森德拉镇像一只被雨水打湿翅膀的海燕。, speaker: kp, language: zh, speed: 1.0, output_format: wav, } response requests.post(TTS_URL, jsonpayload, timeout120) if response.status_code 200: with open(output_kp_001.wav, wb) as f: f.write(response.content) print(音频生成成功) else: print(TTS 调用失败, response.status_code, response.text)调用失败时优先检查模型是否加载完成、端口是否监听、说话人 ID 是否在项目支持的列表中。6. 场景图生成与视觉素材制作Replay 的画面需求通常有两类一类是剧情需要的场景插画比如卡森德拉的街道、废弃仓库、雾中的灯塔另一类是角色立绘和图标用于界面展示。这些都可以用 Stable Diffusion WebUI 或 ComfyUI 批量生成。如果是单人制作建议先用 ComfyUI 搭一套固定工作流固定 SD 版本、固定采样器、固定提示词风格骨架只替换每个场景的主体描述词。这样能保证系列视频的画风统一不会出现上一集是厚涂、下一集变成水彩的割裂感。显存方面SD 1.5 出 512x512 或 768x7688G 显存可以跑得比较舒服SDXL 出 1024x1024建议 12G 以上显存。显存不够时可以降低 batch size、开启低显存优化或用 CPU 慢慢跑但速度会明显变慢。场景图的批量生成思路用 ComfyUI 的 API 会方便很多。先在 ComfyUI 里加载一个构图工作流导出为 API 格式然后写一个 Python 脚本循环替换提示词中的场景、时间和风格标签批量提交任务。这里不展开具体节点细节只说一个关键点不要一上来就追求大尺寸高细节。Replay 画面通常是视频背景16:9 的 1280x720 分辨率加适度细节已经足够超高分辨率会让推理时间翻倍对最终视频观感提升有限。控制角色一致性是另一个坑。如果能找到稳定的角色参考图可以用 ControlNet 或 IPAdapter 固定角色外貌如果做不到建议在系列中用“文字描述 立绘固定 场景不露脸”的方式来规避角色漂移问题。换一个说法长期连载的 Replay角色一致性比单张图的惊艳程度更重要。7. 字幕、音频处理与视频封装字幕和音频处理是 Replay 工程里最容易被低估的部分。配音生成后还要做音量标准化、去除首尾空白、统一响度。字幕则需要和每个音频片段对齐如果逐句手动对半小时的视频可能要花大半天。推荐的路线是“先有音频再按音频时长生成字幕”而不是先写字幕再配音。因为 TTS 生成的实际音频时长和预估时长会有偏差先出音频再对齐字幕时间轴更准。简单的音频标准化可以直接用 FFmpeg# 将单个音频文件标准化到 -16 LUFS去掉首尾静音 ffmpeg -i assets/audio/haiyan/001.wav \ -af loudnormI-16:TP-1.5:LRA11,silenceremovestart_periods1:start_threshold-50dB:start_silence0.5,areverse,silenceremovestart_periods1:start_threshold-50dB:start_silence0.5,areverse \ -ar 44100 -ac 2 assets/audio/haiyan/001_norm.wav带areverse的那一段是为了同时去掉开头和结尾的静音。实际参数要根据音频情况调整如果原声本身有混响过度切除反而会显得突兀。视频封装阶段最简单的方式是用 FFmpeg 把图片、字幕和最终混音合并起来。给一个通用的拼接思路# 将一组数字编号的图片按 30 秒一张轮播配合最终音频生成视频 ffmpeg -framerate 0.033 -i frames/scene_%03d.png \ -i final_mix.wav \ -vf scale1280:720,subtitlessubtitle.ass \ -c:v libx264 -crf 20 -preset medium \ -c:a aac -b:a 192k \ -shortest \ -pix_fmt yuv420p output_ep55.mp4-framerate 0.033表示平均每张图片停留约 30 秒实际项目里要根据分镜长度手动调整。如果你用剪辑软件也可以在软件里直接完成这些操作FFmpeg 适合批量生成或自动合成。字幕建议使用 ASS 格式它对中文排版更友好能控制字体、字号、位置和描边。用 Whisper 做语音识别自动生成原始字幕是可行的但 Replay 场景里最好拿“角色名 原始文本”直接生成 ASS这样准确率能到 100%不需要再修改。8. 接口 API 与批量任务Replay 项目里最耗时的部分恰恰是最适合自动化的部分。如果把整个制作流程里重复性强的动作都脚本化效率提升非常明显。文本分句、音频生成、图片生成、字幕生成、视频封装这五步都可以挂到同一个 JSON 配置下一步一脚本执行{ project: kassandra_ep55, episode: 55, raw_log: ./logs/raw_session_55.txt, clean_log: ./logs/clean_session_55.txt, characters: { kp: {audio_dir: ./assets/audio/kp, voice: narrator}, haiyan: {audio_dir: ./assets/audio/haiyan, voice: female_01}, shayu: {audio_dir: ./assets/audio/shayu, voice: male_01}, maomao: {audio_dir: ./assets/audio/maomao, voice: female_02} }, tts: { url: http://127.0.0.1:9880/tts, language: zh, speed: 1.0 }, image: { engine: comfyui, url: http://127.0.0.1:8188/api, workflow_template: ./workflows/scene.json, output_dir: ./frames }, video: { width: 1280, height: 720, fps: 30, output: ./output/ep55_final.mp4 } }批量任务设计的核心是“失败重试”。TTS 生成一个长对话时网络抖动或显存峰值都可能导致某个音频片段失败。建议每生成一个片段就落盘一个文件并记录成功清单下次重跑时跳过已有文件只补失败的部分。这样即使中间断了也不会从头开始。接口安全方面如果 TTS 或 ComfyUI 服务监听在局域网或公网一定要设置访问控制。默认端口裸奔在公网上容易被陌生人扫到后刷爆任务队列。最稳妥的做法是只监听127.0.0.1或者在前面加一层带鉴权的代理。9. 资源占用与性能观察Replay 流程中最吃性能的环节通常是本地 TTS 和图片生成。观察资源占用时重点关注三块显存、内存、磁盘读写。显存可以用nvidia-smi命令实时查看。启动服务后打开另一个终端输入nvidia-smi -l 5每隔 5 秒刷新一次可以看到每个进程的显存占用。如果你发现显存长期超过 90%就要考虑调低 batch size、降低分辨率或者关闭其他后台显存占用程序。如果显存不足最常见的表现是“服务进程还在但任务提交后不返回结果”此时日志里通常会报 CUDA out of memory。内存方面Python 脚本加载大模型后通常占几 G 到十几 G如果本机内存只有 16G跑 SDXL 加 TTS 同时运行时可能会拖慢整个系统。此时建议把不需要的服务先关掉或者把图片输出和音频输出放到不同的磁盘目录。CPU 推理和 GPU 推理的差异在图片生成上最明显。同样一张图GPU 可能几秒到几十秒CPU 可能要几分钟到十几分钟。TTS 的差异相对小一些但长时间批量生成时依然能感觉出来。如果只能 CPU 跑建议把批量任务压缩到夜间后台执行不要影响白天剪辑。分辨率、步数、批量数对性能的影响也很大。图像生成从 512x512 提升到 1024x1024显存占用和耗时可能翻倍采样步数从 20 提到 40耗时接近翻倍但画质提升不一定明显批量数从 1 提到 2显存占用会直线上升。第一次跑项目建议用 512x512、20 步、batch 1 先验证流程不要一上来就上大图高步数。音频生成方面长文本拆分为短句后单个 TTS 请求处理时间通常不会太长。如果某个句子特别长合成耗时可能异常增长属于正常现象建议把超过 80 个字符的句子再拆一次。10. 常见问题与排查方法Replay 制作流程环节多各种问题都会冒出来。下面这张表归纳了最常见的几类现象和处理思路具体故障日志要按自己使用的工具版本去搜索。问题现象可能原因排查方式解决方案启动 TTS 服务后调用失败端口被占用或模型未加载完成查看启动日志、检查端口监听更换端口等待“服务已就绪”日志再调用生成音频时长和文本明显不匹配文本里含有特殊符号或数字检查清洗后的文本内容把数字改成中文读法去掉多余符号图片生成时 CUDA out of memory显存不足运行 nvidia-smi 观察显存占用降低分辨率、降低 batch或换轻量模型同一角色每张脸都不一样缺少角色一致性约束对比同一角色不同场景图使用 ControlNet/IPAdapter或固定少量不露脸构图字幕和配音对不上音频有首尾静音听一下每个音频片段统一做静音切除和响度标准化视频画面模糊源图分辨率低或导出码率低检查源图尺寸和导出参数提高源图分辨率导出码率不低于 8Mbps批量任务跑到一半卡住某个请求无响应查看任务日志和进程状态脚本增加超时和失败重试机制系列画风不统一提示词风格标签不一致对比每集提示词固定风格后缀例如“cinematic, dark, rain”11. 最佳实践与使用建议给准备长期更新 Replay 的制作组一些工程化建议。第一目录结构从一开始就要规范。建议按“项目名/集数/输入/输出/中间产物”分目录管理不要把音频、图片、草稿全堆在桌面。Replay 做到第 50 集以后素材管理混乱会直接成为断更原因。第二建立一套“最小可用配置”并保存好。对 SD 绘图来说保存一个已经调好的 ComfyUI 工作流 JSON对 TTS 来说保存好每个角色的音色配置和参数组合。新开一集时直接复用而不是重新调参。第三批量任务必须加日志。每次跑完批量生成输出一个 success.txt 和 failed.txt记录哪些片段成功、哪些失败。失败列表不能空着要能直接重新喂给脚本重试。第四接口服务一定要限流和鉴权。如果 TTS 服务监听在局域网至少加一个 token 校验如果只是为了本地制作只监听 127.0.0.1 即可。第五素材版权要提前梳理。跑团模组文本是否允许二创需要看原作者说明玩家台词是否允许公开发布需要玩家本人确认AI 生成角色的声音要确认音色来源是否合规。这些前期确认工作比剪辑和配音更重要。第六第一集不要追求大而全。用第 55 回这个系列来对标没问题但新项目第一次做建议只做 3 分钟以内的测试片段把文本、配音、图片、字幕这条链路完整跑通确认每步输出符合预期再开始做完整章。12. 总结与下一步《卡森德拉的黑色嘉年华》第 55 回能连载到这个深度背后代表的是一套稳定成熟的 Replay 内容管线。对普通观众来说看到的是剧情推进到“晚安被命运击落的海燕”这一情感节点对想入坑制作的人来说更值得关注的是它作为内容工程的稳定性——Log 文本清洗、TTS 配音、场景图生成、字幕对齐、FFmpeg 封装每一步都能独立执行也都能自动化。最先应该验证的功能是“文本清洗 → TTS 合成 → 得到可用音频”这一段。因为这条链路是 Replay 的基础也是影响更新速度的关键。先跑通这一步再考虑要不要上本地图片生成。最容易踩的坑有两个一是角色一致性问题图像和配音的角色一致性都会直接影响系列观感二是版权边界使用真人声线、未授权模组文本和来源不明的美术素材都会给连载埋下隐患。后续可以继续扩展的方向包括用大模型为 Replay 自动生成剧情梗概和标题、用 ComfyUI 工作流做多镜头场景批量生成、用 Whisper 做音频质检、用 Automator 或计划任务做夜间自动批量渲染。内容工程化做到位之后长篇 Replay 就不会再消耗全部周末而是变成一条可以稳定运行的流水线。