《雾雾恋综》这个项目第一眼看上去更像一部网文或者短剧选题双女主、恋综、悬念感。但真正让我感兴趣的是它能不能不再靠人工逐段憋稿而是变成一条可由本地大模型驱动的剧本文案生产线。这篇文章就围绕这个题材拆解一套可在普通 Windows 或 Linux 机器上落地的文本生成方案覆盖人物设定、分集大纲、对白脚本、批量生成、接口 API 调用、资源占用与问题排查。整个方案的重点不是“某个神奇的一键软件”而是把大语言模型接进内容生产流程你给结构化提示词模型输出结构化的剧本文案你再通过批量任务生成多个版本做筛选。先给结论这套流程适合内容团队、短剧编剧、小说作者、电台或播客制作人也适合想折腾本地大模型的开发者。核心能力是可以基于开源大模型做题材化文本生成支持批次扩写、剧情线管理、人设卡维护以及通过兼容 OpenAI 的 API 接入自己的内容管线。硬件门槛根据模型规模浮动7B 量化模型通常 6G 到 8G 显存可以跑14B 模型建议 12G 以上纯 CPU 也能跑但生成速度明显下降。下面我会从项目定位、环境准备、部署启动、功能测试、API 批量调用、性能观察和排查清单这几个维度把《雾雾恋综》的本地内容生产工作流完整过一遍。1. 核心能力速览在开始部署之前先把《雾雾恋综》这套流程的能力边界画清楚。它不是一个传统意义上的单文件软件而是一套“以本地大语言模型为核心的内容生成工作流”题材对象是“双女主恋综”相关的剧本、企划案、人物设定和宣传文案。能力项说明项目类型题材化 AI 文本生成工作流可用于剧本、小说、短剧、综艺企划内容生产题材范围以双女主视角为主的恋综剧情包括人物设定、分集大纲、对白脚本、节目策划案核心功能人设卡生成、剧情大纲扩写、分集对白生成、批量多版本文案、API 接入推理方式本地大语言模型推理支持 GPU/CPU 两种模式硬件需求需按实际模型版本确认7B 量化模型通常 6G 到 8G 显存可跑14B 建议 12G 以上启动方式命令行启动模型服务再通过 WebUI 或 API 访问是否支持 API支持可使用 Ollama / vLLM 等方式暴露 OpenAI 兼容接口是否支持批量任务支持可通过脚本批量生成并输出到指定目录输出格式Markdown、JSON、TXT取决于提示词结构和后处理脚本适合场景短剧剧本预研、网文选题、综艺企划、角色设定、批量文案生成、个人写作辅助需要提醒的是上表中的显存占用不是某个固定项目给出的实测数值而是通用模型部署经验。真正跑起来之前建议先用最小参数做一次推理观察本机显存和内存占用再逐步放大上下文长度和 batch 数量。2. 双女主恋综题材的内容生产难点《雾雾恋综》这个题材看起来简单真要批量生产内容有三个问题必须先解决。第一个问题是人物一致性。双女主恋爱综艺题材中两位女主角的性格、说话方式、成长线必须连贯。如果每段对白都靠模型自由发挥很容易出现上一章还是一号女主下一章就变成另一个人格的情况。解决方案是把人设卡作为固定上下文注入提示词或者放到系统提示词里让模型每次生成都先参考人物设定。第二个问题是剧情节奏。恋综题材本质是“情感关系推进 综艺事件推进”的复合结构既有嘉宾互动又有节目组企划、观众反应甚至幕后冲突。没有结构化大纲模型生成的短段落往往停留在对话层面缺少事件驱动。更稳的做法是先让模型生成分集大纲再由大纲扩写出对白和场景。第三个问题是批量生产与版本对比。内容生产最怕的是“一句话只有一条路”。人工写作可以反复改但成本高用模型做批量生成一次可以产出五到十个版本然后由人来判断哪一条关系线更合理、哪一段对白更像主角。这个流程能不能跑通直接决定了《雾雾恋综》这套方案的生产效率。这也是为什么文章后面会把 API 和批量任务单独拿出来讲。相比一个接一个地在网页对话框里提问写成脚本批量调用才是内容团队真正可用的状态。3. 环境准备与模型选型3.1 操作系统与基础环境这套流程支持 Windows、Linux、macOS但实际内容生产建议优先用 Linux 或 Windows 加 WSL2原因是大模型推理类工具对 NVIDIA 显卡驱动的支持更成熟。无论哪种系统先确认显卡驱动已安装再确认能看到 CUDA 版本。命令行里可以执行nvidia-smi如果输出里能看到显卡型号和显存大小说明驱动已就绪。接下来需要准备的是 Python 环境和依赖管理工具。Python 版本建议用 3.10 或 3.11避免某些推理框架对 3.12 的兼容性还没跟上。python --version pip --version3.2 模型服务组件选型模型服务组件是整个流程的核心。目前常见的选择有 Ollama、vLLM、llama.cpp、Transformers 加载脚本等。对于内容生产者来说Ollama 的优势是安装简单、命令统一、能直接暴露 OpenAI 兼容 APIvLLM 的优势是高吞吐适合服务端多人使用llama.cpp 则适合老显卡和 CPU 推理。如果只是个人写作辅助Ollama 是最快能跑起来的路径。安装 Ollama 后拉取模型示例ollama pull qwen2.5:7b也可以按需选择其他开源模型。模型名称和版本以实际下载到的模型为准。拉取完成后启动服务ollama serve服务默认监听 11434 端口。保持这个服务在后台运行后面所有 API 调用和批量任务都走它。3.3 模型体积与量化选择大语言模型的体积差异很大同一个 7B 模型FP16 版本和量化版本体积能差一倍以上。显存不充足的机器建议优先选择量化版本例如 Q4_K_M 或 Q5_K_M。一般来说7B 量化模型需要 6G 到 8G 显存14B 量化模型需要 12G 到 16G 显存具体数值要看上下文长度和模型实现。如果不确定先拉小模型跑通流程再换大模型。模型的下载位置、脚本目录、输出目录建议分开管理。下面是一个推荐的目录结构雾雾恋综/ ├── models/ # 模型文件或用 ollama 管理 ├── scripts/ # 生成脚本、批量任务脚本 ├── prompts/ # 人设卡、大纲模板、提示词模板 ├── inputs/ # 输入素材例如参考文案、分集要求 ├── outputs/ # 生成结果按任务和时间分目录 └── logs/ # 批量任务日志这样做的原因是批量任务一旦跑起来输出文件会非常多。如果全部堆在同一个目录后续对比版本和回溯历史会很痛苦。4. 本地部署与启动流程4.1 启动模型服务先确保 Ollama 服务已经运行。如果服务没有启动直接在终端执行ollama serve在另一个终端窗口确认模型列表和服务状态ollama list ollama psollama list用于查看本地已经拉取哪些模型ollama ps用于查看当前正在运行的模型、显存占用和上下文大小。如果服务正常执行一个简单请求来验证curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 请用一句话介绍《雾雾恋综》 }这里的模型名需要替换成你实际拉取的模型。能返回文字结果说明服务链路已经通了。4.2 暴露 OpenAI 兼容 APIOllama 默认提供的是/api/generate和/api/chat两个接口。为了方便后续接入 Python 脚本可以使用它的 OpenAI 兼容接口默认地址是http://127.0.0.1:11434/v1有了这个地址就可以用常见的 OpenAI SDK 或者 requests 直接调用。如果使用的是 vLLM一个典型的启动命令是python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name misty_show \ --port 8000具体参数以 vLLM 官方文档为准。无论用哪种方式关键是先确认 API 地址、端口和模型名这三个参数会写进后面的所有脚本里。4.3 验证 WebUI 是否可用如果不想只靠命令行交互可以给模型服务套一个 WebUI 界面。常见做法是使用 Open WebUI 或 Chatbot UI。启动后浏览器访问 WebUI 页面能看到一个聊天窗口。WebUI 最大的作用是调试提示词你可以先人工测试几轮确认提示词能让模型稳定输出再把这些提示词固化到批量脚本里。需要注意WebUI 和模型服务未必在同一台机器也可能不在同一端口。如果页面打不开优先检查服务进程是否还在端口是否被防火墙拦截。5. 功能测试与效果验证5.1 人设卡生成测试《雾雾恋综》的人物设定是整个内容生产的地基。人设卡不清晰后面生成的所有对白和大纲都会漂移。测试时可以给模型一个初始需求让它输出结构化的人设卡。输入示例请为《雾雾恋综》设计两位女主角的人设卡要求包含姓名、年龄、职业、性格特点、说话风格、综艺节目中的角色定位、隐藏矛盾。风格要求真实、有反差感、适合恋爱综艺节目。预期结果是一份结构化的人设卡。判断标准包括两位主角性格是否有明显区分说话风格是否具体到可以执行隐藏矛盾是否具备后续剧情展开空间是否给出了综艺节目中的角色定位比如“观察担当”“话题制造者”等。如果生成结果仍然是泛泛而谈可以在提示词里补充一句“请在每一项后给出一个具体的情境示例”。这样能让模型从抽象设定落到可用的剧情素材上。5.2 分集大纲生成测试人物定下来后第二步是生成分集大纲。测试时把第一轮的人设卡粘贴到系统提示词中然后要求模型生成 8 集或 12 集的节目大纲。输入示例基于以下人设卡为《雾雾恋综》生成 8 集分集大纲。 每一集需要包含本集主题、节目事件、两位女主的关系变化、观众可能关注的话题点。 第一集需要建立人物关系最后一集要形成完整的情感闭环。预期输出的核心是“关系变化是可追踪的”。比如第一集两位女主是节目组安排的同组搭档第三集出现信任危机第五集因为一个任务重新配合第八集完成和解。这个结构比单集精彩更重要。如果生成的大纲每一集看起来都差不多说明模型没有理解“关系递进”。此时需要在大纲提示词里加入“前一条事件必须成为后一条事件的触发原因”并要求在输出表格里增加“上一集结果影响”字段。5.3 对白脚本生成测试对白测试是最直观的验证环节。恋爱综艺对白需要有潜台词不能只是表面问答。测试时选一个具体场景要求模型生成带动作描写和语气提示的对白脚本。输入示例场景第二集两位女主在节目组的双人任务中必须合作完成任务。 任务背景她们前一天刚因为对节目规则的理解不同发生过争执。 请生成 500 字左右的对白脚本要包含动作描写、语气提示、潜台词。预期结果是“说得少、暗示多”。如果模型生成的全是“你还好吗”“我还好”这类无效对白说明提示词没有给出人物关系和情绪状态。补充人设卡和情感冲突背景后通常能明显改善。判断标准每句对白是否可以反推说话者的性格对白之间有没有停顿和动作支撑争执和合作是否同时存在而不是直接和好。5.4 综艺名场面生成测试名场面是恋综项目最容易传播的内容单元。测试时要求模型生成“一个可以上热搜的节目瞬间”。输入示例请为《雾雾恋综》设计一个适合剪进预告片的名场面。 要求有画面感、有反转、两位女主都有高光表现。 字数 300 字以内以场景描述为主。判断标准是这段文字在脑内能不能形成可拍摄画面。如果能明显看到画面切换、镜头细节、情绪爆发点就说明生成质量达标。如果只是抽象的“她哭了她笑了”则需要在提示词里加入“用画面代替情绪形容词”并给出一个示例句式。6. 接口 API 调用与批量任务6.1 基础 API 调用模型服务跑通之后最常用的方式是调用 OpenAI 兼容接口。以下是 Python 调用示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是《雾雾恋综》的编剧助手擅长双女主恋爱综艺内容创作。}, {role: user, content: 请为第二集生成一个双女主合作任务的完整场景脚本。} ], temperature0.8, max_tokens2048 ) print(response.choices[0].message.content)这里使用的model名称必须和实际拉取的模型一致。base_url需要根据实际服务地址调整。如果使用 vLLM 的 8000 端口就需要改成http://127.0.0.1:8000/v1。api_key在本地服务中往往不校验但为了兼容代码一般还是会传一个占位字符串。6.2 curl 方式验证接口如果不想写 Python 脚本可以先通过 curl 验证接口是否正常curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: system, content: 你是《雾雾恋综》的编剧助手。}, {role: user, content: 请生成一位女主角的自我介绍对白。} ], temperature: 0.7 }返回内容里会包含choices数组里面就是模型生成的文本。如果返回空内容优先检查服务日志和控制台输出。6.3 批量任务设计批量生成的核心思路是准备一组结构化输入逐条发送请求把结果写入独立文件。这样可以一次生成多个分集剧本、多个版本对白或者多个预告片文案。建议把提示词模板放到独立的 Python 字典或 JSON 文件里方便维护。下面是一个简单的批量生成脚本骨架import json import time from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) tasks [ { scene: 第一集开场, requirement: 双女主初次见面各自用一句话介绍自己。, output_file: outputs/01_opening.txt }, { scene: 第三集合作任务, requirement: 在双人任务中产生误解但最后选择配合完成。, output_file: outputs/03_cooperation.txt } ] for task in tasks: prompt f场景{task[scene]}\n要求{task[requirement]}\n请生成 400 字内容。 try: response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是《雾雾恋综》的编剧助手。}, {role: user, content: prompt} ], temperature0.85, max_tokens1500 ) result response.choices[0].message.content with open(task[output_file], w, encodingutf-8) as f: f.write(result) print(f成功{task[output_file]}) except Exception as e: print(f失败{task[scene]} - {e}) time.sleep(0.5)这个脚本会遍历任务列表把每个场景的生成结果写入对应文件。生产环境里还应该加上日志记录、失败重试、输出格式校验。比如生成结果为空时重新请求一次连续失败两次则跳过并写入错误日志。批量任务的目录管理很重要。每个批次建议用时间戳作为目录名例如outputs/20250217_1800/里面按场景分文件。这样后续筛选版本时可以通过目录名回溯当时用了哪个模型、哪套提示词。6.4 批量结果筛选批量生成不等于全部采用。模型生成的结果里通常有 20% 左右能直接用剩下的要么情节重复要么人物语气不对。建议在批量脚本里额外输出一份summary.json记录每个任务的输入、输出文件、生成时间和模型名方便后续人工筛选时对比。筛选阶段可以把结果贴回 WebUI让别人设卡作为系统提示词要求模型“在不改变情节的前提下把这段对白改得更符合一号女主性格”。这样相当于又做一轮精修比全部手写效率高很多。7. 资源占用与性能观察7.1 显存与内存观察方法模型服务跑起来之后观察资源占用的第一步是ollama ps。它会显示当前加载到显存里的模型、上下文大小和占用情况。ollama ps也可以使用nvidia-smi查看 GPU 使用率、温度、显存占用。关键指标有三个显存占用是否稳定GPU 利用率是否波动CPU 是否飙升。如果显存占用接近上限但生成速度很慢说明模型参数和上下文长度设置偏大需要降低上下文长度或者换更小模型。7.2 CPU 推理与 GPU 推理的差异纯 CPU 推理是可行的但速度会明显下降尤其是生成 500 字以上内容时等待时间会从几秒变成几十秒甚至更长。GPU 推理的优势不只是速度快还在于可以让模型处理更长的上下文因为显存带宽比内存高很多。如果机器只有 CPU 可用建议使用较小参数的量化模型并把max_tokens控制在 800 以内减少单次等待时间。7.3 影响生成速度的参数生成时间主要受四个因素影响模型参数大小、量化方式、生成长度max_tokens、并行批次大小。批量任务里最容易忽略的是max_tokens设置过大。比如一个对白脚本只需要 500 字却把max_tokens设为 4096资源会被白白浪费。更合理的做法是先人工测试几次找到目标内容长度的上限再在脚本里设置一个 1.2 倍到 1.5 倍的余量。7.4 降低显存占用的方法如果显存不足可以按顺序尝试以下方法换用更小的量化模型降低上下文长度关闭多余的后台应用使用ollama stop释放不再使用的模型在代码里减少max_tokens和批量并发数。多分身窗口同时运行多个模型也是常见的显存超占原因使用频率不高的模型应及时卸载。7.5 进程与端口冲突排查服务跑久了容易出现重复进程和端口冲突。如果发现 11434 端口被占用先查端口占用情况netstat -ano | findstr 11434在 Linux 下可以使用lsof -i :11434确认是哪个进程占用后再决定是否 kill 旧进程重新启动。更稳妥的办法是固定一个端口不要频繁切换服务地址否则脚本里的base_url也会跟着改。8. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回为空模型名错误或提示词触发生成终止查看服务日志检查返回 message 内容确认模型名调整提示词增加max_tokens启动后页面打不开WebUI 端口被占用或模型服务未启动检查服务进程和端口监听状态更换端口或重启模型服务显存不足模型过大或上下文长度设置过长查看ollama ps或nvidia-smi换小模型、降低上下文、关闭其他占用程序生成内容人物性格漂移人设卡没有进入系统提示词检查 API 请求里的 messages 结构把人设卡放进 system 或固定上下文批量任务偶尔失败网络超时或模型服务压力过大查看脚本异常日志增加time.sleep请求异常时重试一次CPU 推理速度很慢模型参数过大或 CPU 内存带宽不足监控 CPU 利用率和内存占用换量化小模型、缩短生成长度两次生成结果差异很大temperature 设置过高查看请求参数把 temperature 降到 0.7 到 0.8端口冲突上一次服务未关闭用 netstat 或 lsof 查看端口kill 旧进程或更换端口资源占用过高多个模型同时加载到显存查看ollama psollama stop卸载不用的模型生成结果含有不合适内容未设置足够的内容约束提示词检查输出样例在系统提示词中加入明确的内容边界要求排查问题时建议遵循“先服务、后接口、再提示词”的顺序。先确认服务进程是否正常再确认接口返回状态码是否为 200最后再检查提示词和生成结果之间的关系。不要一上来就怀疑模型能力大部分问题出在服务环节或提示词结构上。9. 最佳实践与合规边界9.1 从最小用例起步第一次测试不要直接跑全部分集脚本。先用一个 200 字左右的对白测试确认模型逻辑正常再逐步扩展到完整剧本。这样可以在投入大量资源前发现模型选型是否合适。9.2 维护一套固定的提示词模板人设卡、分集大纲、对白脚本应该分别保存为独立模板文件。使用《雾雾恋综》各章节时直接复用模板只替换其中的主角名字、场景和冲突点。这样既保证输出风格统一也方便团队协作时对齐标准。比较推荐的做法是使用 JSON 保存模板{ system_prompt: 你是《雾雾恋综》的编剧助手负责双女主恋爱综艺剧本创作。, character_card_path: prompts/characters.json, storyline_path: prompts/storyline.md, output_rule: 输出内容使用中文包含动作描写、语气提示和潜台词。 }9.3 明确合规边界《雾雾恋综》这类恋爱题材内容生产需要注意几个边界。第一是版权问题使用开源模型和素材时确认模型许可与商用条件自己训练或微调时确认训练数据来源合法。第二是内容规范问题恋爱题材内容要避免低俗化、直白性描写生成结果需要人工审核后再发布。第三是肖像授权问题如果参考了现实人物、艺人或真实综艺素材必须确认授权否则不要使用。第四是主体身份问题涉及数字人、真人形象、声音时必须获得明确授权并遵循平台规则。9.4 生成内容需要人工复核大模型生成内容天然存在事实幻觉和逻辑漏洞尤其是长剧本场景人物出场顺序和关系变化容易前后矛盾。批量生成后至少需要经过一轮人工复核检查人物是否一致、时间线是否合理、是否存在不适宜传播内容。不能直接拿模型输出上线。9.5 建议建立版本管理《雾雾恋综》如果没有版本管理几天后你可能已经分不清某个版本的剧本用了哪套提示词。建议把提示词模板、模型名称、模型版本、生成参数、输出文件作为一个整体记录。最简单的方式是每次批量任务生成前把提示词模板复制到对应输出目录里保留一份参数快照。10. 总结与下一步《雾雾恋综》这套方案最值得尝试的点是把一个偏感性创作的题材拆成了可批量生产的流程人设卡、分集大纲、对白脚本、名场面、批量生成、API 接入每一环都能用本地大模型完成。最先应该验证的功能是“人设卡到分集大纲”的提示词链路因为这决定了后续所有输出的稳定性。最容易踩的坑是模型选型过大导致显存不足以及批量任务中缺少失败重试导致生成中断。后续可以扩展的方向有三个一是为《雾雾恋综》定制一套更细的提示词模板库针对不同类型的分集做专属模板二是接上批量脚本和 WebUI让团队协作时不需要每个人单独跑命令行三是积累一批经过人工确认的高质量样本文案用来做微调或 Few-shot 示例提升模型对双女主恋综题材的把控力。如果你手头正好有一台能跑 7B 或 14B 量化模型的机器建议从最小用例开始先跑通一个 200 字对白再逐步扩展到完整的《雾雾恋综》分集剧本。这套流程跑顺以后不光能用在这个题材上换成其他类型的短剧、综艺企划或小说大纲同样可以复用。 
长河君 · 2026/9/1 7:46:14 · 阅读 1.2k 《雾雾恋综》本地大模型驱动的剧本文案生产线搭建指南
《雾雾恋综》这个项目第一眼看上去更像一部网文或者短剧选题双女主、恋综、悬念感。但真正让我感兴趣的是它能不能不再靠人工逐段憋稿而是变成一条可由本地大模型驱动的剧本文案生产线。这篇文章就围绕这个题材拆解一套可在普通 Windows 或 Linux 机器上落地的文本生成方案覆盖人物设定、分集大纲、对白脚本、批量生成、接口 API 调用、资源占用与问题排查。整个方案的重点不是“某个神奇的一键软件”而是把大语言模型接进内容生产流程你给结构化提示词模型输出结构化的剧本文案你再通过批量任务生成多个版本做筛选。先给结论这套流程适合内容团队、短剧编剧、小说作者、电台或播客制作人也适合想折腾本地大模型的开发者。核心能力是可以基于开源大模型做题材化文本生成支持批次扩写、剧情线管理、人设卡维护以及通过兼容 OpenAI 的 API 接入自己的内容管线。硬件门槛根据模型规模浮动7B 量化模型通常 6G 到 8G 显存可以跑14B 模型建议 12G 以上纯 CPU 也能跑但生成速度明显下降。下面我会从项目定位、环境准备、部署启动、功能测试、API 批量调用、性能观察和排查清单这几个维度把《雾雾恋综》的本地内容生产工作流完整过一遍。1. 核心能力速览在开始部署之前先把《雾雾恋综》这套流程的能力边界画清楚。它不是一个传统意义上的单文件软件而是一套“以本地大语言模型为核心的内容生成工作流”题材对象是“双女主恋综”相关的剧本、企划案、人物设定和宣传文案。能力项说明项目类型题材化 AI 文本生成工作流可用于剧本、小说、短剧、综艺企划内容生产题材范围以双女主视角为主的恋综剧情包括人物设定、分集大纲、对白脚本、节目策划案核心功能人设卡生成、剧情大纲扩写、分集对白生成、批量多版本文案、API 接入推理方式本地大语言模型推理支持 GPU/CPU 两种模式硬件需求需按实际模型版本确认7B 量化模型通常 6G 到 8G 显存可跑14B 建议 12G 以上启动方式命令行启动模型服务再通过 WebUI 或 API 访问是否支持 API支持可使用 Ollama / vLLM 等方式暴露 OpenAI 兼容接口是否支持批量任务支持可通过脚本批量生成并输出到指定目录输出格式Markdown、JSON、TXT取决于提示词结构和后处理脚本适合场景短剧剧本预研、网文选题、综艺企划、角色设定、批量文案生成、个人写作辅助需要提醒的是上表中的显存占用不是某个固定项目给出的实测数值而是通用模型部署经验。真正跑起来之前建议先用最小参数做一次推理观察本机显存和内存占用再逐步放大上下文长度和 batch 数量。2. 双女主恋综题材的内容生产难点《雾雾恋综》这个题材看起来简单真要批量生产内容有三个问题必须先解决。第一个问题是人物一致性。双女主恋爱综艺题材中两位女主角的性格、说话方式、成长线必须连贯。如果每段对白都靠模型自由发挥很容易出现上一章还是一号女主下一章就变成另一个人格的情况。解决方案是把人设卡作为固定上下文注入提示词或者放到系统提示词里让模型每次生成都先参考人物设定。第二个问题是剧情节奏。恋综题材本质是“情感关系推进 综艺事件推进”的复合结构既有嘉宾互动又有节目组企划、观众反应甚至幕后冲突。没有结构化大纲模型生成的短段落往往停留在对话层面缺少事件驱动。更稳的做法是先让模型生成分集大纲再由大纲扩写出对白和场景。第三个问题是批量生产与版本对比。内容生产最怕的是“一句话只有一条路”。人工写作可以反复改但成本高用模型做批量生成一次可以产出五到十个版本然后由人来判断哪一条关系线更合理、哪一段对白更像主角。这个流程能不能跑通直接决定了《雾雾恋综》这套方案的生产效率。这也是为什么文章后面会把 API 和批量任务单独拿出来讲。相比一个接一个地在网页对话框里提问写成脚本批量调用才是内容团队真正可用的状态。3. 环境准备与模型选型3.1 操作系统与基础环境这套流程支持 Windows、Linux、macOS但实际内容生产建议优先用 Linux 或 Windows 加 WSL2原因是大模型推理类工具对 NVIDIA 显卡驱动的支持更成熟。无论哪种系统先确认显卡驱动已安装再确认能看到 CUDA 版本。命令行里可以执行nvidia-smi如果输出里能看到显卡型号和显存大小说明驱动已就绪。接下来需要准备的是 Python 环境和依赖管理工具。Python 版本建议用 3.10 或 3.11避免某些推理框架对 3.12 的兼容性还没跟上。python --version pip --version3.2 模型服务组件选型模型服务组件是整个流程的核心。目前常见的选择有 Ollama、vLLM、llama.cpp、Transformers 加载脚本等。对于内容生产者来说Ollama 的优势是安装简单、命令统一、能直接暴露 OpenAI 兼容 APIvLLM 的优势是高吞吐适合服务端多人使用llama.cpp 则适合老显卡和 CPU 推理。如果只是个人写作辅助Ollama 是最快能跑起来的路径。安装 Ollama 后拉取模型示例ollama pull qwen2.5:7b也可以按需选择其他开源模型。模型名称和版本以实际下载到的模型为准。拉取完成后启动服务ollama serve服务默认监听 11434 端口。保持这个服务在后台运行后面所有 API 调用和批量任务都走它。3.3 模型体积与量化选择大语言模型的体积差异很大同一个 7B 模型FP16 版本和量化版本体积能差一倍以上。显存不充足的机器建议优先选择量化版本例如 Q4_K_M 或 Q5_K_M。一般来说7B 量化模型需要 6G 到 8G 显存14B 量化模型需要 12G 到 16G 显存具体数值要看上下文长度和模型实现。如果不确定先拉小模型跑通流程再换大模型。模型的下载位置、脚本目录、输出目录建议分开管理。下面是一个推荐的目录结构雾雾恋综/ ├── models/ # 模型文件或用 ollama 管理 ├── scripts/ # 生成脚本、批量任务脚本 ├── prompts/ # 人设卡、大纲模板、提示词模板 ├── inputs/ # 输入素材例如参考文案、分集要求 ├── outputs/ # 生成结果按任务和时间分目录 └── logs/ # 批量任务日志这样做的原因是批量任务一旦跑起来输出文件会非常多。如果全部堆在同一个目录后续对比版本和回溯历史会很痛苦。4. 本地部署与启动流程4.1 启动模型服务先确保 Ollama 服务已经运行。如果服务没有启动直接在终端执行ollama serve在另一个终端窗口确认模型列表和服务状态ollama list ollama psollama list用于查看本地已经拉取哪些模型ollama ps用于查看当前正在运行的模型、显存占用和上下文大小。如果服务正常执行一个简单请求来验证curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 请用一句话介绍《雾雾恋综》 }这里的模型名需要替换成你实际拉取的模型。能返回文字结果说明服务链路已经通了。4.2 暴露 OpenAI 兼容 APIOllama 默认提供的是/api/generate和/api/chat两个接口。为了方便后续接入 Python 脚本可以使用它的 OpenAI 兼容接口默认地址是http://127.0.0.1:11434/v1有了这个地址就可以用常见的 OpenAI SDK 或者 requests 直接调用。如果使用的是 vLLM一个典型的启动命令是python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name misty_show \ --port 8000具体参数以 vLLM 官方文档为准。无论用哪种方式关键是先确认 API 地址、端口和模型名这三个参数会写进后面的所有脚本里。4.3 验证 WebUI 是否可用如果不想只靠命令行交互可以给模型服务套一个 WebUI 界面。常见做法是使用 Open WebUI 或 Chatbot UI。启动后浏览器访问 WebUI 页面能看到一个聊天窗口。WebUI 最大的作用是调试提示词你可以先人工测试几轮确认提示词能让模型稳定输出再把这些提示词固化到批量脚本里。需要注意WebUI 和模型服务未必在同一台机器也可能不在同一端口。如果页面打不开优先检查服务进程是否还在端口是否被防火墙拦截。5. 功能测试与效果验证5.1 人设卡生成测试《雾雾恋综》的人物设定是整个内容生产的地基。人设卡不清晰后面生成的所有对白和大纲都会漂移。测试时可以给模型一个初始需求让它输出结构化的人设卡。输入示例请为《雾雾恋综》设计两位女主角的人设卡要求包含姓名、年龄、职业、性格特点、说话风格、综艺节目中的角色定位、隐藏矛盾。风格要求真实、有反差感、适合恋爱综艺节目。预期结果是一份结构化的人设卡。判断标准包括两位主角性格是否有明显区分说话风格是否具体到可以执行隐藏矛盾是否具备后续剧情展开空间是否给出了综艺节目中的角色定位比如“观察担当”“话题制造者”等。如果生成结果仍然是泛泛而谈可以在提示词里补充一句“请在每一项后给出一个具体的情境示例”。这样能让模型从抽象设定落到可用的剧情素材上。5.2 分集大纲生成测试人物定下来后第二步是生成分集大纲。测试时把第一轮的人设卡粘贴到系统提示词中然后要求模型生成 8 集或 12 集的节目大纲。输入示例基于以下人设卡为《雾雾恋综》生成 8 集分集大纲。 每一集需要包含本集主题、节目事件、两位女主的关系变化、观众可能关注的话题点。 第一集需要建立人物关系最后一集要形成完整的情感闭环。预期输出的核心是“关系变化是可追踪的”。比如第一集两位女主是节目组安排的同组搭档第三集出现信任危机第五集因为一个任务重新配合第八集完成和解。这个结构比单集精彩更重要。如果生成的大纲每一集看起来都差不多说明模型没有理解“关系递进”。此时需要在大纲提示词里加入“前一条事件必须成为后一条事件的触发原因”并要求在输出表格里增加“上一集结果影响”字段。5.3 对白脚本生成测试对白测试是最直观的验证环节。恋爱综艺对白需要有潜台词不能只是表面问答。测试时选一个具体场景要求模型生成带动作描写和语气提示的对白脚本。输入示例场景第二集两位女主在节目组的双人任务中必须合作完成任务。 任务背景她们前一天刚因为对节目规则的理解不同发生过争执。 请生成 500 字左右的对白脚本要包含动作描写、语气提示、潜台词。预期结果是“说得少、暗示多”。如果模型生成的全是“你还好吗”“我还好”这类无效对白说明提示词没有给出人物关系和情绪状态。补充人设卡和情感冲突背景后通常能明显改善。判断标准每句对白是否可以反推说话者的性格对白之间有没有停顿和动作支撑争执和合作是否同时存在而不是直接和好。5.4 综艺名场面生成测试名场面是恋综项目最容易传播的内容单元。测试时要求模型生成“一个可以上热搜的节目瞬间”。输入示例请为《雾雾恋综》设计一个适合剪进预告片的名场面。 要求有画面感、有反转、两位女主都有高光表现。 字数 300 字以内以场景描述为主。判断标准是这段文字在脑内能不能形成可拍摄画面。如果能明显看到画面切换、镜头细节、情绪爆发点就说明生成质量达标。如果只是抽象的“她哭了她笑了”则需要在提示词里加入“用画面代替情绪形容词”并给出一个示例句式。6. 接口 API 调用与批量任务6.1 基础 API 调用模型服务跑通之后最常用的方式是调用 OpenAI 兼容接口。以下是 Python 调用示例from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是《雾雾恋综》的编剧助手擅长双女主恋爱综艺内容创作。}, {role: user, content: 请为第二集生成一个双女主合作任务的完整场景脚本。} ], temperature0.8, max_tokens2048 ) print(response.choices[0].message.content)这里使用的model名称必须和实际拉取的模型一致。base_url需要根据实际服务地址调整。如果使用 vLLM 的 8000 端口就需要改成http://127.0.0.1:8000/v1。api_key在本地服务中往往不校验但为了兼容代码一般还是会传一个占位字符串。6.2 curl 方式验证接口如果不想写 Python 脚本可以先通过 curl 验证接口是否正常curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: system, content: 你是《雾雾恋综》的编剧助手。}, {role: user, content: 请生成一位女主角的自我介绍对白。} ], temperature: 0.7 }返回内容里会包含choices数组里面就是模型生成的文本。如果返回空内容优先检查服务日志和控制台输出。6.3 批量任务设计批量生成的核心思路是准备一组结构化输入逐条发送请求把结果写入独立文件。这样可以一次生成多个分集剧本、多个版本对白或者多个预告片文案。建议把提示词模板放到独立的 Python 字典或 JSON 文件里方便维护。下面是一个简单的批量生成脚本骨架import json import time from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) tasks [ { scene: 第一集开场, requirement: 双女主初次见面各自用一句话介绍自己。, output_file: outputs/01_opening.txt }, { scene: 第三集合作任务, requirement: 在双人任务中产生误解但最后选择配合完成。, output_file: outputs/03_cooperation.txt } ] for task in tasks: prompt f场景{task[scene]}\n要求{task[requirement]}\n请生成 400 字内容。 try: response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是《雾雾恋综》的编剧助手。}, {role: user, content: prompt} ], temperature0.85, max_tokens1500 ) result response.choices[0].message.content with open(task[output_file], w, encodingutf-8) as f: f.write(result) print(f成功{task[output_file]}) except Exception as e: print(f失败{task[scene]} - {e}) time.sleep(0.5)这个脚本会遍历任务列表把每个场景的生成结果写入对应文件。生产环境里还应该加上日志记录、失败重试、输出格式校验。比如生成结果为空时重新请求一次连续失败两次则跳过并写入错误日志。批量任务的目录管理很重要。每个批次建议用时间戳作为目录名例如outputs/20250217_1800/里面按场景分文件。这样后续筛选版本时可以通过目录名回溯当时用了哪个模型、哪套提示词。6.4 批量结果筛选批量生成不等于全部采用。模型生成的结果里通常有 20% 左右能直接用剩下的要么情节重复要么人物语气不对。建议在批量脚本里额外输出一份summary.json记录每个任务的输入、输出文件、生成时间和模型名方便后续人工筛选时对比。筛选阶段可以把结果贴回 WebUI让别人设卡作为系统提示词要求模型“在不改变情节的前提下把这段对白改得更符合一号女主性格”。这样相当于又做一轮精修比全部手写效率高很多。7. 资源占用与性能观察7.1 显存与内存观察方法模型服务跑起来之后观察资源占用的第一步是ollama ps。它会显示当前加载到显存里的模型、上下文大小和占用情况。ollama ps也可以使用nvidia-smi查看 GPU 使用率、温度、显存占用。关键指标有三个显存占用是否稳定GPU 利用率是否波动CPU 是否飙升。如果显存占用接近上限但生成速度很慢说明模型参数和上下文长度设置偏大需要降低上下文长度或者换更小模型。7.2 CPU 推理与 GPU 推理的差异纯 CPU 推理是可行的但速度会明显下降尤其是生成 500 字以上内容时等待时间会从几秒变成几十秒甚至更长。GPU 推理的优势不只是速度快还在于可以让模型处理更长的上下文因为显存带宽比内存高很多。如果机器只有 CPU 可用建议使用较小参数的量化模型并把max_tokens控制在 800 以内减少单次等待时间。7.3 影响生成速度的参数生成时间主要受四个因素影响模型参数大小、量化方式、生成长度max_tokens、并行批次大小。批量任务里最容易忽略的是max_tokens设置过大。比如一个对白脚本只需要 500 字却把max_tokens设为 4096资源会被白白浪费。更合理的做法是先人工测试几次找到目标内容长度的上限再在脚本里设置一个 1.2 倍到 1.5 倍的余量。7.4 降低显存占用的方法如果显存不足可以按顺序尝试以下方法换用更小的量化模型降低上下文长度关闭多余的后台应用使用ollama stop释放不再使用的模型在代码里减少max_tokens和批量并发数。多分身窗口同时运行多个模型也是常见的显存超占原因使用频率不高的模型应及时卸载。7.5 进程与端口冲突排查服务跑久了容易出现重复进程和端口冲突。如果发现 11434 端口被占用先查端口占用情况netstat -ano | findstr 11434在 Linux 下可以使用lsof -i :11434确认是哪个进程占用后再决定是否 kill 旧进程重新启动。更稳妥的办法是固定一个端口不要频繁切换服务地址否则脚本里的base_url也会跟着改。8. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回为空模型名错误或提示词触发生成终止查看服务日志检查返回 message 内容确认模型名调整提示词增加max_tokens启动后页面打不开WebUI 端口被占用或模型服务未启动检查服务进程和端口监听状态更换端口或重启模型服务显存不足模型过大或上下文长度设置过长查看ollama ps或nvidia-smi换小模型、降低上下文、关闭其他占用程序生成内容人物性格漂移人设卡没有进入系统提示词检查 API 请求里的 messages 结构把人设卡放进 system 或固定上下文批量任务偶尔失败网络超时或模型服务压力过大查看脚本异常日志增加time.sleep请求异常时重试一次CPU 推理速度很慢模型参数过大或 CPU 内存带宽不足监控 CPU 利用率和内存占用换量化小模型、缩短生成长度两次生成结果差异很大temperature 设置过高查看请求参数把 temperature 降到 0.7 到 0.8端口冲突上一次服务未关闭用 netstat 或 lsof 查看端口kill 旧进程或更换端口资源占用过高多个模型同时加载到显存查看ollama psollama stop卸载不用的模型生成结果含有不合适内容未设置足够的内容约束提示词检查输出样例在系统提示词中加入明确的内容边界要求排查问题时建议遵循“先服务、后接口、再提示词”的顺序。先确认服务进程是否正常再确认接口返回状态码是否为 200最后再检查提示词和生成结果之间的关系。不要一上来就怀疑模型能力大部分问题出在服务环节或提示词结构上。9. 最佳实践与合规边界9.1 从最小用例起步第一次测试不要直接跑全部分集脚本。先用一个 200 字左右的对白测试确认模型逻辑正常再逐步扩展到完整剧本。这样可以在投入大量资源前发现模型选型是否合适。9.2 维护一套固定的提示词模板人设卡、分集大纲、对白脚本应该分别保存为独立模板文件。使用《雾雾恋综》各章节时直接复用模板只替换其中的主角名字、场景和冲突点。这样既保证输出风格统一也方便团队协作时对齐标准。比较推荐的做法是使用 JSON 保存模板{ system_prompt: 你是《雾雾恋综》的编剧助手负责双女主恋爱综艺剧本创作。, character_card_path: prompts/characters.json, storyline_path: prompts/storyline.md, output_rule: 输出内容使用中文包含动作描写、语气提示和潜台词。 }9.3 明确合规边界《雾雾恋综》这类恋爱题材内容生产需要注意几个边界。第一是版权问题使用开源模型和素材时确认模型许可与商用条件自己训练或微调时确认训练数据来源合法。第二是内容规范问题恋爱题材内容要避免低俗化、直白性描写生成结果需要人工审核后再发布。第三是肖像授权问题如果参考了现实人物、艺人或真实综艺素材必须确认授权否则不要使用。第四是主体身份问题涉及数字人、真人形象、声音时必须获得明确授权并遵循平台规则。9.4 生成内容需要人工复核大模型生成内容天然存在事实幻觉和逻辑漏洞尤其是长剧本场景人物出场顺序和关系变化容易前后矛盾。批量生成后至少需要经过一轮人工复核检查人物是否一致、时间线是否合理、是否存在不适宜传播内容。不能直接拿模型输出上线。9.5 建议建立版本管理《雾雾恋综》如果没有版本管理几天后你可能已经分不清某个版本的剧本用了哪套提示词。建议把提示词模板、模型名称、模型版本、生成参数、输出文件作为一个整体记录。最简单的方式是每次批量任务生成前把提示词模板复制到对应输出目录里保留一份参数快照。10. 总结与下一步《雾雾恋综》这套方案最值得尝试的点是把一个偏感性创作的题材拆成了可批量生产的流程人设卡、分集大纲、对白脚本、名场面、批量生成、API 接入每一环都能用本地大模型完成。最先应该验证的功能是“人设卡到分集大纲”的提示词链路因为这决定了后续所有输出的稳定性。最容易踩的坑是模型选型过大导致显存不足以及批量任务中缺少失败重试导致生成中断。后续可以扩展的方向有三个一是为《雾雾恋综》定制一套更细的提示词模板库针对不同类型的分集做专属模板二是接上批量脚本和 WebUI让团队协作时不需要每个人单独跑命令行三是积累一批经过人工确认的高质量样本文案用来做微调或 Few-shot 示例提升模型对双女主恋综题材的把控力。如果你手头正好有一台能跑 7B 或 14B 量化模型的机器建议从最小用例开始先跑通一个 200 字对白再逐步扩展到完整的《雾雾恋综》分集剧本。这套流程跑顺以后不光能用在这个题材上换成其他类型的短剧、综艺企划或小说大纲同样可以复用。