简介面向影视编剧、内容创作者及自然语言处理技术爱好者这份二十三页的PDF系统讲解如何借助DeepSeek完成行业语料微调与剧本风格迁移。文档从影视创作与技术融合的背景切入先梳理DeepSeek模型起源、架构与预训练机制再展开行业语料收集、筛选、清洗、标注与预处理的方法微调部分覆盖环境搭建、参数设置、训练流程及过拟合处理风格迁移部分详述编码器—解码器架构、风格特征提取、对抗训练、推理过程与评估指标并配有数据准备、微调、风格迁移、模型评估等关键环节的代码示例。资源为单个PDF文件压缩包约1.83MB目录结构清晰、图文显示正常方便按章节检索阅读。已有75人学习适合希望借助大模型辅助剧本创作、实现个人或平台风格适配的读者作为从入门到进阶的系统参考。1. 为什么让 DeepSeek 直接写剧本总是一股“AI 味”影视剧本创作这件事大多数团队现在的第一反应是“让 DeepSeek 先出个三幕结构”。但你真拿去试过就会发现模型写出来的东西结构上挑不出毛病——起承转合齐全人物弧光也不缺可一落到具体对白和场景描述就露馅了台词像访谈节目人物说话没有潜台词场景描写全是“气氛紧张”“内心复杂”这种黑匣子式形容词。问题不在 DeepSeek 本身而在它训练时看过太多通用文本没看过足够多“真正的剧本”。所谓“真正的剧本”指的是业界实际在用的剧本格式——场景标题、动作描述、角色名冒号对白、括号内的语气提示这些东西和小说、新闻、聊天记录完全不是一个文体。行业语料微调与风格迁移就是把 DeepSeek 从一个什么都懂的通用模型变成一上来就懂“场地、内景、日”这种黑话的影视剧本专用模型。本文不聊那些云端一键微调的噱头直接讲清楚语料怎么洗、LoRA 参数怎么调、风格迁移到底迁移的是什么以及哪些地方会让你白烧几千块 GPU 电费。2. 行业语料准备先让模型“看懂”剧本长什么样2.1 影视剧本语料和普通文本语料的三个本质区别很多人以为“行业语料微调”就是把一堆 PDF 剧本喂给模型让它学。实际上剧本语料的处理难度远高于同量级的新闻或百科语料因为剧本的信息密度分布极其不均匀。第一剧本里有大量“格式即语义”的内容比如“内景 办公室 - 夜”这行字不是描述是场景切换的硬标记模型必须学会把它当成“新一场戏开始”的信号第二对白占比超过百分之六七十而且对白说话人标记角色名冒号一旦丢失整段训练样本就成了无意义的文本流第三剧作里有大量“无效文段”——封面、版权页、演职员表、导演注释、分场大纲这些混进语料会让微调模型学会生成一堆和剧情无关的边角料。所以第一步不是找语料而是定清洗规范。我一般会把语料处理分成三级第一级是格式规范化把 PDF 或 Word 导出的乱码整理成统一的“场景标记 动作描述 角色:对白”结构第二级是内容过滤去掉版权页、片头片尾、剧本分析文章这些非剧本正文第三级是对话块切分保证每个训练样本内部是完整的叙事单元而不是在一场戏中间拦腰截断。2.2 原始剧本转训练集的清洗脚本下面这段代码解决的是第一级和第二级问题的合并处理。它读取一批纯文本格式的剧本文件按场景标记切分并将对白行规范成“角色名 冒号 内容”的模板。import re from pathlib import Path def clean_script(raw_text: str) - list[str]: # 逐行清洗先剔除版权页、页码、演职员表等噪声行 lines raw_text.splitlines() cleaned [] scene_pattern re.compile(r^(内景|外景|内|外)\s.?[\.\-—]\s*(日|夜|黄昏|清晨|白天|晚上)) dialogue_pattern re.compile(r^[A-Z\u4e00-\u9fa5]{1,8}\s?[:]\s?) for line in lines: line line.strip() if not line: continue # 过滤纯数字页码和“第X页”这类内容 if re.fullmatch(r(\d{1,4}|第\s*\d\s*页), line): continue # 过滤版权/演职员关键词开头的行 lower_line line.lower() if any(word in lower_line for word in [copyright, 编剧, 导演, 出品, 主演]): continue # 场景标题行保留并加【场景】标记对白行加【对白】标记 if scene_pattern.match(line): cleaned.append(f【场景】{line}) elif dialogue_pattern.match(line): role, content re.split(r[:], line, maxsplit1) cleaned.append(f【对白】{role.strip()}:{content.strip()}) else: cleaned.append(f【动作】{line}) return cleaned # 处理示例单文件清洗后按500字符切块 if __name__ __main__: raw Path(sample_script.txt).read_text(encodingutf-8) blocks clean_script(raw) chunk, buffer [], [] for block in blocks: buffer.append(block) if sum(len(b) for b in buffer) 500: chunk.append(\n.join(buffer)) buffer [] if buffer: chunk.append(\n.join(buffer)) # chunk 即为可直接用于构造训练样本的文本块这段脚本的核心逻辑有三处值得注意场景标题正则故意覆盖了“内景|外景|内|外”加地点加“日|夜”的常见结构但不覆盖“闪回”“梦境”这类特殊场景标记——这两个标记我建议在清洗之后单独手工处理因为它们在剧本里经常和正常场景混写模型容易误判为动作描述。“对白”正则里的角色名长度限制在 1 到 8 个字符这是因为中文剧本的说话人标记通常不超四个字“林助理”“王总”“母亲”都在范围内但如果你的语料里有“出租车司机甲”这类长角色名这个正则需要放宽到 12 字符。切块策略上500 字符一块不是拍脑袋定的。训练 DeepSeek 这类模型时样本太短学不到上下文太长又把显存和训练时间拖爆。500 到 800 字是剧本对白场景的常见长度区间——大概就是一场两三分钟的戏包含场景描述、人物动作和一段完整对话既能让模型学到“对话怎么接”又不至于让它只盯着长文本的结构。2.3 语料规模、比例与训练验证集切分的实际经验关于行业语料微调被问得最多的问题是“到底要多少数据才够”。我的经验是分场景看如果你只想让 DeepSeek 学会剧本格式和基本的对白节奏五万到十万条清洗后的场景文本块就够做一次像样的 LoRA 微调如果你想让它学会某个特定编剧的风格比如“对白简短、动作描写极简、喜欢用留白”那么这个编剧有署名的作品全集是不够的你需要把他的剧本、访谈、创作谈混在一起凑出至少两万条风格样本才有机会让模型抓住那种“语感”。少于五千条看不出来效果多于三十万条边际收益极低而且训练时间翻倍。训练集和验证集的比例我习惯用 9:1验证集必须保证和训练集来自不同的剧本文件而不是同一部戏里的随机抽段——否则模型见过同一场景的上下文验证 loss 好看但没有实际参考价值。更隐蔽的一个问题是语料的“时代分布”如果你喂进去的剧本有一半是 90 年代的情景喜剧微调出来的模型写对白会带着明显的“室内剧节奏”拍都市短剧就会觉得对话太密、留白不够。所以清洗之后最好按剧本类型做一次粗筛至少要知道语料里“场景喜剧、电视连续剧、电影剧本、话剧”各占多少比例。3. 用 LoRA 做 DeepSeek 行业语料微调训练脚本与关键参数3.1 为什么选 LoRA 而不是全参数微调影视剧本微调有一个很尴尬的处境全参数微调效果好但成本高到大多数工作室承受不起。DeepSeek 这类模型的参数量动辄几十亿甚至上百亿全参数微调需要把完整优化器状态、梯度、参数全塞进显存一张 24GB 的消费级显卡根本跑不动就算用 A100 也得租好几张。而 LoRA 的原理是冻结原始模型权重只训练注入到注意力层和前馈层的低秩矩阵。它的核心思想是“原始模型已经懂语言只需要微调一小部分参数让它懂剧本”实际训练参数量可以压缩到原来的 1% 以下。从效果上说LoRA 在剧本任务上有一个意想不到的优势不易灾难性遗忘。全参数微调的模型在学剧本的同时会逐渐忘记通用能力比如逻辑推理、常识问答而 LoRA 冻结了基座微调完的模型既能写剧本又不至于连“帮我想个短剧选题”这种普通对话都变得只会用剧本腔回答。影视剧本创作这个场景偏偏需要这种“双模”能力——你既要它写场景又要它和你讨论剧情逻辑。3.2 基于 HuggingFace 的 DeepSeek LoRA 训练脚本下面这段脚本是我实际在用的训练流程依赖 transformers、peft、datasets 和 torch基座模型用 DeepSeek 的中文对话版本。训练前需要把上一章清洗好的文本块做成 JSONL 格式每行包含 instruction 和 output 两个字段——instruction 是“请根据以下场景创建一个剧本片段”output 是清洗后的场景文本。这种指令化的格式比单纯喂文本更能让模型学会“被要求创作时输出剧本”的触发条件。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from datasets import load_dataset from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from trl import SFTTrainer # 1. 加载 DeepSeek 基座模型以 7B 级模型为例按实际显存选择 model_name deepseek-ai/deepseek-llm-7b-chat model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue, ) tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) tokenizer.pad_token tokenizer.eos_token # 2. 配置 LoRA 参数 lora_config LoraConfig( r16, # 低秩矩阵的秩决定 LoRA 的容量 lora_alpha32, # 缩放系数实际影响比 lr 更直观 target_modules[q_proj, v_proj, k_proj, o_proj, down_proj, up_proj], lora_dropout0.05, # 防过拟合语料量小时建议调大到 0.1 biasnone, task_typeCAUSAL_LM, ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) # 3. 训练参数核心是学习率和小批量设置 training_args TrainingArguments( output_dir./deepseek_script_lora, num_train_epochs3, per_device_train_batch_size2, per_device_eval_batch_size2, gradient_accumulation_steps8, # 等效 batch size 2*8 16 learning_rate2e-4, # LoRA 学习率通常比全参高 10 倍 warmup_ratio0.03, logging_steps20, eval_strategysteps, eval_steps200, save_steps500, fp16True, # 显存不够时改用 8bit 量化加载基座 remove_unused_columnsFalse, ) # 4. SFTTrainer 自动拼接 instruction output 训练 trainer SFTTrainer( modelmodel, argstraining_args, train_datasetload_dataset(json, data_filestrain.jsonl)[train], eval_datasetload_dataset(json, data_fileseval.jsonl)[train], formatting_funclambda x: f【指令】{x[instruction]}\n【输出】{x[output]}, max_seq_length1024, ) trainer.train()这组参数踩过不少坑逐个解释。r16 是 LoRA 矩阵的秩数值越大模型能记住的风格细节越多但训练参数和显存占用也线性增长。剧本对白这类“风格强、知识弱”的任务r16 到 32 之间够用r64 我试过生成质量没有明显提升训练时间翻了四倍。lora_alpha32 和 r 的比例关系是“2 倍原则”很多新手把 lora_alpha 调到 64 或 128 想增强效果结果模型生成内容变得重复且死板因为缩放系数过大会让新注入的低秩矩阵在和基座权重合并时占比过重压制了模型的原有生成多样性。学习率 2e-4 是 LoRA 训练的最稳起点。全参数微调常用 1e-5 到 5e-5但 LoRA 只训练少量参数需要更高的学习率才能让它们发挥作用。如果你的显卡只支持 8bit 量化加载基座学习率建议降到 1e-4否则量化带来的精度损失会被放大生成文本可能出现乱码。gradient_accumulation_steps8 配合 per_device_batch_size2 的实际效果是等效 batch size 16——这个值对剧本任务很重要batch 太大会让模型忽视风格细节太小则收敛不稳16 是对话生成类任务的甜点位也基本是两张 24GB 显卡能跑动的上限。3.3 训练时长、显存占用与 checkpoint 选择策略LoRA 微调 DeepSeek 7B 级模型单卡 24GB 显存如 RTX 3090/4090可以跑但需要打开 8bit 量化。显存占用大头不是 LoRA 参数而是激活值和优化器状态我实测 bf16 8bit 基座 r16 的情况下峰值显存约 18GB刚好压线。如果是 14B 或更大参数版本别犹豫直接上双卡或租云 GPU。训练时长方面十万条样本、每条约 500 字符、3 个 epoch在单张 4090 上大约需要 6 到 10 小时这取决于序列长度和 batch 设置。checkpoint 不是保存越频繁越好。save_steps500 我建议改成 save_steps200但只保留最后两个 checkpoint因为剧本微调的“过拟合拐点”经常出现在最后一个 epoch 的最后三分之一处。你需要对比的是“epoch 2 结束时的 checkpoint”和“epoch 3 结束时”的生成质量——现象很常见epoch 3 的训练 loss 比 epoch 2 低但生成的对白开始出现“角色 A 说完上句角色 B 复读下句”的退化迹象这说明模型开始机械模仿语料中的高频句式泛化能力反而下降了。保存多个 checkpoint 是事后对比的后悔药不要只留最后一个。4. 风格迁移的本质不是换滤镜是换“台词习惯”4.1 风格迁移到底迁移的是哪个层级的特征很多教程把风格迁移讲得像“给模型加一个风格提示词”比如在 system prompt 里写“请用王家卫的风格写这段戏”——这能改变措辞但改变不了模型对剧本节奏的底层理解。风格迁移在行业语料微调里的真实含义是通过微调让模型的对白分布发生系统性偏移。具体来说不同编剧的对白特征体现在三个可量化的维度句长分布A 编剧平均每句 12 字B 编剧 25 字、语气词密度“嗯”“啊”“那个”出现的频次、信息推进方式靠对话直接推进 vs 靠动作和留白推进。提示词只能改变表面措辞LoRA 微调才能改变这三组统计特征。所以在实操上风格迁移的落地路径是“风格语料提取 → 风格 LoRA 训练 → 风格强度控制”。前两步和上一章的行业语料微调共用同一套训练流程区别在于训练数据要全部换成目标风格的剧本文本第三步则是推断阶段的技巧——把风格 LoRA 做到能随时上线、下线、调节强度。4.2 把“某个编剧风格”做成可切换的 LoRA 权重做法不复杂在基础微调学会剧本格式的 checkpoint 上再用风格语料训练一个独立的 LoRA adapter。推理时先按场景写“格式正确的剧本”再叠加风格 LoRA 做二次生成。这样做的好处是格式能力和风格能力解耦——你换风格不需要重新训练“剧本格式”那部分只需要换一个风格 adapter 文件。from peft import PeftModel, PeftConfig from transformers import AutoModelForCausalLM, AutoTokenizer import torch base_model_name deepseek-ai/deepseek-llm-7b-chat base_model AutoModelForCausalLM.from_pretrained( base_model_name, torch_dtypetorch.bfloat16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(base_model_name) # 加载格式微调 LoRA剧本格式能力 format_adapter PeftModel.from_pretrained( base_model, ./deepseek_script_lora/checkpoint-2000, # 格式微调的最优 checkpoint ) # 在格式模型之上叠加风格 LoRA风格迁移能力 style_path ./style_lora/known_script_style format_adapter.load_adapter(style_path, adapter_namestyle_a) format_adapter.set_adapter(style_a) prompt 【指令】请创作一场两人对话的戏场景是深夜的便利店人物是老陈和陌生女孩。女孩买完东西却不走。要求包含场景描述和对白。 【输出】 inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs format_adapter.generate( **inputs, max_new_tokens800, do_sampleTrue, temperature0.9, top_p0.95, repetition_penalty1.1, ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))这段代码展示了叠加 adapter 的完整流程。有一个关键参数容易被忽略repetition_penalty1.1。风格 LoRA 微调后的模型天然有重复倾向——因为它学到的是某位编剧的惯用语而这些惯用语在语料里反复出现。如果不加 repetition penalty生成到 300 字左右就开始自我重复而设置到 1.1 可以压制这个倾向又不至于让对白变得生硬。如果生成结果还是重复就往上调到 1.15但超过 1.2 会出现“每句话都在故意换词”的怪异感像学生作文。temperature0.9是剧本创作场景的推荐值。写剧本不是解题需要一定的随机性来产生“出乎意料的对白”。温度低于 0.7 生成结果会变得平淡高于 1.0 则会出现逻辑断裂——角色上一句还在讨论去哪吃饭下一句突然开始回忆童年这种断裂在剧本里不是艺术是 bug。4.3 风格强度的量化控制与多风格组合风格 LoRA 的一个独特玩法是“按比例混合多个风格”。比如你想写“悬疑剧的节奏 轻喜剧的对白”可以把悬疑风格 LoRA 和喜剧风格 LoRA 按 0.6:0.4 的权重合并成一个新的 adapter合并过程是对两个 LoRA 矩阵做加权求和。PEFT 库提供了add_weighted_adapter接口但有一个副作用两个 adapter 如果训练自不同 epoch 的基座权重矩阵的尺度可能不同直接相加会引入噪声。经验做法是先把两个 adapter 的矩阵分别做归一化再加权最后再乘回原始尺度。风格强度还有一个更朴素的控制手段训练时在语料里按比例混合风格样本和普通剧本样本。比如风格样本占 30%模型会学到“在保留基本剧本结构的同时带有一点风格倾向”风格样本占 70%风格就压倒了剧本的通用性。我踩过的坑是风格样本占比超过 80% 后模型写所有场景都像同一部戏里的片段——古代宫廷戏、现代职场戏、科幻戏角色说话的方式一模一样这就叫“风格迁移过度”。5. 剧本微调避坑5 个让训练成果报废的常见问题5.1 训练 loss 持续下降但生成文本是完全不通的乱码现象loss 曲线非常漂亮地从 2.1 降到 0.9但推理时输出的中文文本流畅度尚可却夹杂着“㹴”“熌”这类生僻字对白毫无剧情逻辑。原因这是典型的语料编码污染。你的清洗脚本处理的是 UTF-8 编码的文本但很多旧剧本 PDF 转出来的纯文本是 GBK 或 GB18030 编码转换到 UTF-8 时产生了不可见字符或错误映射。模型把这些“看起来很合法”的乱码当作正常文本学习了loss 当然会下降。解决在清洗脚本里增加编码检测步骤遇到非 UTF-8 文件先统一转码并过滤掉所有包含 Unicode 特殊区段字符的行比如 CJK 扩展 B 区以外的生僻字。转码完用“随机抽 200 条样本人工检查”的方式过一遍不要只看 loss 曲线。5.2 微调后角色 A 经常说出角色 B 的台词现象生成的剧本里两个角色在对话但说话内容完全不符合各自的人物设定——女儿说出母亲的台词下属说出老板的台词。原因语料切块时把“说话人标记”和对白内容切开了。清洗脚本按 500 字符切块如果一条样本恰好从对白中间截断下一块样本就没有角色名模型在训练时学到的是“无标记的对白文本”它没有学会“谁在说话”和“说了什么”之间的绑定关系。解决切块必须以“完整对白块”为单位不能以纯字符数为准。我的做法是先把剧本按场景标记切成大块再在每一大块内部按“对白 后续动作描述”为最小单位拼接保证每条训练样本要么是一个完整的对话回合要么是一整场戏。宁可某些样本短到 200 字也不要让一条 800 字样本里出现半截台词。5.3 微调完模型写什么都是“短剧”味现象无论你输入“写一部 90 分钟电影的开场戏”还是“写一段栏目剧片段”模型的输出都是每场 60 到 90 秒的短剧节奏——对白密集、场景转换快、信息量大但情绪深度浅。原因训练语料里以短剧或短视频剧本为主这类剧作的节奏特征就是“快速铺设冲突、三句话一个反转”。模型根据语料统计出的“剧本节奏先验”被短剧模式主导了这和数据量无关是语料类型分布极度偏斜造成的。解决在清洗阶段对语料按类型打标签训练时按类型比例采样把长片剧本的比例人为抬高到 40% 以上。如果你的目标本来就是要做短剧这条可以跳过但需要意识到风格迁移只能改变局部语言习惯改变不了篇幅和叙事节奏这样的全局结构特征——后者必须靠语料比例来约束。5.4 LoRA 权重合并后生成质量反而下降现象单独加载 LoRA adapter 生成效果正常但用merge_and_unload()把 LoRA 权重合并回基座模型后生成质量明显下降甚至出现重复和乱码。原因合并过程把低秩矩阵加回原始权重但 LoRA 的缩放系数 lora_alpha 在推理时会被微调框架自动处理合并为静态权重后这个缩放系数如果和权重矩阵的数值尺度不匹配就会导致注意力机制里的数值分布偏移。解决非必要不合并。推理时直接加载 PeftModel 和 adapter 文件框架会正确处理缩放。如果必须合并做部署优化比如用 vLLM 部署合并后做一次困惑度测试对比合并前后的生成文本困惑度明显上升就改用“运行时加载 LoRA”的方式不要追求静态合并。5.5 多轮对话中剧本创作能力“断崖式消失”现象第一轮输入“写一个两人相遇的场景”模型输出质量不错。接着输入“现在把场景改成雨天”模型突然变得不会写剧本输出退化成普通聊天内容的格式。原因微调时你的训练样本都是单轮的“指令 剧本文本”没有构造“修改剧本”这类多轮监督数据。模型在微调中学会了“有指令就写剧本”但没有学会“在多轮对话的上下文中继续扮演剧本创作助手”。解决训练数据里追加一部分多轮改写样本——把清洗好的剧本场景作为初版输出把修改要求换时间、换地点、增加一个角色作为后续指令构造两到三轮的对话格式。数据量不需要大五千到一万条就能显著改善这个能力。6. 微调后的部署与验证怎么判断这次的训练真的成功了6.1 用 vLLM 做低延迟剧本生成部署微调出来的 LoRA 模型不能老挂着 Python 脚本跑推理生产环境需要一个高吞吐的服务化方案。常见做法是用 vLLM 加载 DeepSeek 基座并指定 LoRA adapter 目录然后通过兼容 OpenAI 格式的 API 对外提供服务。下面是一个最小部署配置# 安装 vLLM 后直接通过命令行指定模型和 LoRA python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-llm-7b-chat \ --enable-lora \ --lora-modules script_lora./deepseek_script_lora/checkpoint-2000 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动后用 curl 就能测接口curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: script_lora, prompt: 【指令】写一段两个律师在法庭外走廊的戏【输出】, max_tokens: 500, temperature: 0.9 }部署时两个参数值得注意。--max-model-len 8192不是越大越好——剧本创作经常需要把前文背景塞进上下文但序列长度和显存占用线性相关如果卡只有 24GB设成 8192 就可能 OOM降到 4096 更稳。--gpu-memory-utilization 0.9是 vLLM 显存分配的硬上限不要设到 0.95 以上推理时如果触发 KV cache 重算延迟会飙升——这是许多人说“vLLM 部署 DeepSeek 变慢了”的主要原因不是 vLLM 慢是显存余量留太少。6.2 剧本质量的 4 项验证指标不只看 loss 曲线训练结束后我习惯用一份固定的“剧本测试集”做四项评分而不是只盯着验证 loss。第一项是“场景标记正确率”——生成的每一场戏是否正确包含场景标题、动作描述、对白标记三项都有的比例超过 95% 才算格式过关。第二项是“角色一致性”——同一角色在五轮对话内的语气和意图是否保持连贯这个指标需要人工打分我会找两个不参与训练的同事分别打取平均值。第三项是“对白推进度”——每段对白是否让剧情状态发生了改变信息变化、关系变化或冲突升级如果连续十组对白都在原地打转说明模型学到了“对话感”但没学到“叙事感”。第四项是“风格距离”——把生成文本和风格语料的句长分布、形容词密度、语气词频率做对比数值接近才说明风格迁移真的起效了。表格对比是最直观的验证方式指标基座模型格式微调后风格微调后场景标记正确率30%95%94%角色一致性满分52.83.54.1对白推进度低中高句长分布差异大中小这条验证流程能帮你区分两种常见情况格式微调有效但风格迁移无效说明风格语料不够或学习率不当格式和风格都有效但角色一致性差说明语料切块时破坏了对白回合的完整性。总之可量化的验证指标是微调项目的终点也是下一次循环的起点。6.3 进阶技巧双阶段生成法解决“长剧本结构崩坏”最后一个值得分享的实战技巧是“双阶段生成法”。直接让模型生成完整 90 分钟电影剧本它一定会崩——前半部分还行后半部分人物动机全乱事件线索丢得七七八八。这不是微调能完全解决的问题因为剧本的结构信息第 1 幕埋的伏笔到第 3 幕要回收超出了单次生成长度的“注意力跨度”。我的做法是分两步先用普通 DeepSeek 对话生成三幕结构大纲和每场戏的核心冲突清单这个过程用基座模型就可以它的通用规划和推理能力足够然后逐一用微调后的模型填充每一场戏的具体对白和动作。填充时把“上一场戏结尾状态”和“本场戏目标”作为前缀塞进 prompt让模型知道每一场戏从哪里开始、要往哪里走。这个习惯我踩过不少坑之后才固定下来。最初总想让一个模型把所有事情做完结果生成的剧本前 30 场戏质量不错后 30 场开始人物动机混乱像换了编剧。后来坚持“大纲用基座、对白用微调”的分工方式生成质量稳定得多也更容易定位问题——如果是大纲问题从头调整结构如果是单场对话问题回炉改语料或调 LoRA 参数不用整锅重烧。现在每做完一次微调我都会把生成样本和验证数据归档成一份固定的“测试基线”下次调整语料或参数时直接对照不再靠感觉判断“这版比上版好”。这个习惯帮我避开了不少玄学调参的弯路希望也能帮到你。本文还有配套的精品资源点击获取