本地大模型同人小说批量生成工作流：角色卡、提示词与合规实践

这个标题的信息密度很高：同人IP、穿越设定、系统流、开篇即冲突。很多人看到它第一反应是"又一篇爽文"，但如果你是从技术角度切入，它其实是一个非常好的文本生成需求样本——它有明确的角色库、明确的世界观约束、明确的章节节奏要求，还有明确的"系统流"数值规则。这类需求恰好是本地大模型写作辅助最典型的落地场景：不是让模型自由发挥，而是让它在一套设定约束下稳定产出。

这篇文章不谈剧情好坏，而是把这个开篇设定当成一个工程需求来拆：怎么用本地部署的开源大模型 + 提示词模板 + 角色设定库 + 批量生成脚本，搭一套可复用的同人小说创作工作流。核心结论先给出来：这套东西门槛不高，一张消费级显卡就能跑 7B 级别的量化模型，用 Ollama 或 llama.cpp 启动，对外暴露 OpenAI 兼容接口，再写几十行 Python 就能做章节批量生成；难点不在部署，而在设定一致性控制和内容合规边界。

本文会完整走一遍：需求拆解、工具链选型、环境准备、本地部署、角色卡与世界观配置、开篇生成测试、批量章节任务、接口调用、资源占用观察、常见问题排查。适合三类读者：想把自己的写作流程工程化的网文作者、做二创内容需要批量出稿的创作者、以及想把本地 LLM 接进自己工具链的开发者。所有涉及生成的内容都会强调授权与合规，涉及情色、露骨描写的需求不在本文讨论范围内。

1. 从标题拆解出可执行的技术需求

先把这个标题拆开看。它包含五个可复用的结构要素：IP 锚点（同人作品名）、穿越钩子（睁眼即入戏）、角色冲突（开篇即有人物压制关系）、金手指（系统流）、爽点机制（靠"气人"攒数值抽模板）。这五点里，前四点是内容设定，第五点是规则引擎——它有明确的输入（行为）、计量（数值）、产出（抽卡结果），这是最容易工程化的部分。

对技术侧来说，这意味着我们不能只做一个"输入一句话生成一章"的裸接口。裸接口的问题是每次生成都从零开始，角色口吻会漂移，世界观会自我矛盾，系统数值会前后打架。要解决这个问题，需要三层结构：设定层（角色卡、世界观、规则表）、生成层（分场景的提示词模板）、校验层（生成后的规则一致性检查）。这三层里，设定层用 JSON/YAML 存，生成层用模板拼装，校验层可以用规则脚本也可以用模型自检。

再往下拆，一个开篇章节的生成任务实际上包含这些子任务：开场场景描写、角色出场与外貌点到为止的描写、内心独白、系统激活提示、首次数值结算、章节收尾钩子。每一块的提示词侧重不同，开场要短句、要冲突前置；系统提示要格式化、要像系统面板；章节钩子要留悬念。把这些拆成独立的 prompt 片段，再按顺序拼装，产出的稳定性会明显高于一次性丢一个大 prompt 给模型。

1.1 标题结构要素与技术映射

这张表的价值在于：它把"写作灵感"变成了"可配置项"。你把角色卡换掉，同一套模板可以套到别的同人作品上；你把抽卡池换掉，系统流的产出就变了。工程化的第一收益就是复用。

需要提醒的是，同人创作涉及原作版权。用于个人练笔、小范围分享通常风险较低，但一旦涉及商业发布、付费阅读、改编成其他形式，必须先确认原作方的二创授权政策。本文所有示例都按"个人学习与非商业测试"的前提编写，不构成任何授权建议。

2. 工具链核心能力速览

这套工作流不需要什么特殊软件，全是成熟组件。核心是本地推理引擎 + 一个薄薄的编排层。下面这张表是选型速览，参数部分凡是材料未明确的，我都标成"需按实际环境测试"，不做数字承诺。

这里要说清一个常见的认知偏差：很多人以为"批量生成"是引擎自带的功能，其实不是。Ollama 和 vLLM 提供的是单次请求的推理服务，批量能力来自你的编排脚本——你自己控制并发数、重试、断点续跑、结果落盘。这点想清楚了，后面写脚本就很自然。

关于模型选择，7B 级别在中文创意写作上已经能用，但对"系统面板格式""数值一致性"这类结构化输出，14B 会更稳。如果你的显卡只有 8G 显存，建议直接上 4bit 量化版本，上下文控制在 8K 左右，这是最不容易翻车的配置。显存更大的话，可以放开到 16K 上下文，长章节拼接会更顺。

3. 适用场景与合规边界

先说适合谁。第一类是长篇连载作者，每天要稳定产出两三千字，最痛苦的不是没灵感，而是"昨天写的人设今天自己忘了"。把角色卡和世界观落成结构化文件，每次生成前注入，能省掉大量回翻前文的时间。第二类是二创作者，需要围绕同一组角色产出多个短篇，模板复用价值很高。第三类是开发者，想验证本地模型在创意写作任务上的实际表现，这套脚本可以直接当测试床。

再说边界。第一，涉及真实人物的内容不要生成，包括但不限于对真人进行外貌描写、性格编排、私生活虚构。第二，露骨、低俗、性暗示描写一律不生成，无论提示词怎么包装。第三，原作角色用于商业用途前必须确认授权，同人作品在多数平台发布时也需要标注二创属性。第四，生成内容要人工复核，模型会一本正经地编造原作不存在的情节和设定，这类"设定幻觉"直接发出去会误导读者。

还有一个容易被忽略的点：本地部署不等于数据绝对安全。虽然推理在本地，但你的设定文件、章节草稿、人物卡都存在磁盘上，如果没有加密和访问控制，多人共用一台机器时会互相看到。如果是团队协作，建议把设定库放在独立目录，用文件权限做隔离，接口服务只监听 127.0.0.1，不要图省事开 0.0.0.0 暴露到局域网。

4. 本地部署环境准备

环境这块不需要太复杂，但有几点必须先确认，否则后面会卡在很奇怪的地方。第一是显卡驱动和 CUDA 版本，Ollama 现在自带运行时，一般不需要单独装 CUDA，但如果你用 vLLM，就必须保证驱动版本和 CUDA 版本匹配。第二是磁盘空间，一个 7B 的 4bit 量化模型文件大概几个 GB，14B 翻倍，同时跑两个模型加上缓存，预留 30G 以上比较稳妥。第三是端口，Ollama 默认 11434，vLLM 默认 8000，llama.cpp 默认 8080，如果这些端口已经被占用，启动会直接失败。

操作系统方面，Windows、Linux、macOS 都能跑，Windows 上用 Ollama 最省事，Linux 上想追求吞吐可以上 vLLM。Python 版本建议 3.10 以上，主要是为了兼容现在主流的 HTTP 客户端和异步库。如果你的机器是老显卡，别急着放弃，llama.cpp 的 CPU 推理在 7B 量化模型上大概能跑到每秒几个 token，写小说这种非实时场景完全够用，只是生成一章要等几分钟。

bash复制# 通用环境检查清单，按实际环境执行
nvidia-smi                 # 查看显卡型号、驱动版本、显存占用
python --version           # 建议 3.10 及以上
pip --version
df -h                      # Linux/macOS 查看磁盘剩余空间
netstat -ano | findstr 11434   # Windows 检查端口占用
lsof -i :11434             # Linux/macOS 检查端口占用

检查完之后，建一个独立目录结构，把配置、输入、输出分开，这个习惯后面会救命。很多人的问题是生成结果和提示词混在一个文件夹里，跑几十章之后就完全不知道哪段是哪次生成的。

bash复制# 推荐的最小目录结构，路径按需替换
mkdir -p novel-workflow/{config,inputs,outputs,logs,scripts}
# config    角色卡、世界观、提示词模板
# inputs    章节大纲、待改写草稿
# outputs   生成结果，按章节编号落盘
# logs      请求日志与失败记录
# scripts   编排脚本

5. 本地推理服务启动与接口验证

启动方式有三种，按你的需求选。想最快跑起来，用 Ollama；想精细控制上下文和批处理参数，用 llama.cpp 的 server；想做高并发批量生成，用 vLLM。三者都提供 HTTP 接口，其中 Ollama 和 vLLM 提供 OpenAI 兼容格式，意味着你后面写的调用代码可以几乎不改地在这两个引擎之间切换。

5.1 Ollama 启动与模型拉取

Ollama 的优势是开箱即用，模型管理也简单。拉一个 7B 级别的中文能力较好的指令模型，然后确认服务在跑。

bash复制# 拉取模型，模型名需按你实际选择的版本替换
ollama pull qwen2.5:7b

# 查看本地已有模型
ollama list

# 前台启动服务，默认监听 127.0.0.1:11434
ollama serve

# 简单验证：直接命令行对话
ollama run qwen2.5:7b "用一句话说明什么是系统流小说"

服务起来后，先验证 OpenAI 兼容接口是否可用，这一步很关键，因为后面所有脚本都依赖它。

bash复制# 验证 OpenAI 兼容接口，模型名与上面拉取的一致
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,
    "max_tokens": 256
  }'

如果返回里能看到 choices[0].message.content，说明链路通了。如果报连接被拒绝，先确认 ollama serve 是否还在前台运行；如果报模型不存在，检查模型名有没有写错，ollama list 输出的名字才是准确的名字。

5.2 llama.cpp 与 vLLM 启动模板

llama.cpp 适合显存紧张或者想纯 CPU 跑的场景，需要自己下 gguf 格式的模型文件。vLLM 适合有较大显存、需要并发吞吐的场景，参数量大的模型在它上面表现更好。

bash复制# llama.cpp 启动示例，模型路径和上下文长度按实际替换
llama-server \
  -m ./models/qwen2.5-7b-instruct-q4_k_m.gguf \
  -c 8192 \
  --host 127.0.0.1 \
  --port 8080 \
  -ngl 99

# vLLM 启动示例，需要显存充足，端口与模型名按实际替换
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.85

-ngl 是卸载到 GPU 的层数，99 表示尽量全放显存，如果显存不够就往下调，调到不爆显存为止。--gpu-memory-utilization 是 vLLM 的显存占用上限比例，留一点余量给系统，不要设到 1.0。

6. 角色卡、世界观与提示词模板设计

这是整套流程里最花时间、也最决定成败的部分。模型本身的能力是固定的，产出质量的上限由你的设定文件决定。角色卡不要写成散文，要写成结构化字段，因为结构化字段可以被模板精确注入，也可以被脚本做一致性校验。

角色卡至少包含这些字段：角色名、出处、身份定位、外貌关键词（点到为止，不做身体细节描写）、性格三要素、说话习惯、与主角的关系、当前立场、禁忌行为。其中"说话习惯"和"禁忌行为"最关键，前者决定对白像不像，后者防止模型写出该角色绝不会做的事。

json复制{
  "characters": [
    {
      "id": "char_001",
      "name": "示例角色A",
      "source": "同人作品原作",
      "role": "开篇冲突触发者",
      "appearance_keywords": ["粉发", "冷静", "压迫感强"],
      "personality": ["掌控欲强", "话少", "观察细致"],
      "speech_style": "短句为主，少用形容词，常以反问收尾",
      "relationship": "与主角初次交锋",
      "stance": "中立偏试探",
      "taboo": ["不主动示弱", "不解释动机", "不参与低俗对话"]
    }
  ],
  "world_rules": {
    "power_system": "异人体系，能力来源明确",
    "system_panel": "仅主角可见，以【系统】前缀输出",
    "forbidden": ["低俗描写", "真实人物映射", "原作未设定的能力"]
  }
}

世界观单独用一个 YAML 存，把"能用什么、不能用什么"写清楚。这一步的作用是给模型一个负面清单，比写一堆正面描述更有效。

yaml复制# config/world.yaml
world:
  name: "同人世界示例"
  tone: "都市异能，节奏偏快，对白驱动"
  chapter_length: "2000-3000 字"
  pov: "第一人称"
  rules:
    - "系统提示统一用【系统】开头，单独成行"
    - "每章至少一次数值结算，数值变化需可追溯"
    - "角色出场必须先给动作再给对白"
  forbidden:
    - "露骨或性暗示描写"
    - "对真实人物的影射"
    - "原作中不存在的角色能力"
    - "大段设定说明文字"

提示词模板按场景拆。开篇场景一个模板，系统激活一个模板，数值结算一个模板，章节收尾钩子一个模板。每个模板只解决一件事，拼装的时候按顺序调用。这样做的好处是某一段效果不好，你可以单独改那一段，不用整篇重写。

python复制# scripts/prompt_builder.py
# 提示词拼装示例，字段名与你的角色卡保持一致

OPENING_TEMPLATE = """你在写一部同人小说的开篇章节。

【世界观约束】
{tone}
禁止内容：{forbidden}

【出场角色】
{character_block}

【本章任务】
1. 用不超过 80 字交代主角穿越后的第一感受，不写背景介绍。
2. 角色出场先给一个动作描写，再给一句对白，对白符合其说话习惯。
3. 主角内心独白不超过 3 句。
4. 结尾出现系统激活提示，格式严格为：【系统】+ 一句话。
5. 全章 2000-3000 字，第一人称。

【输出要求】
只输出正文，不要输出大纲、说明或标题以外的内容。
"""

def build_opening_prompt(character: dict, world: dict) -> str:
    character_block = (
        f"姓名：{character['name']}\n"
        f"性格：{'、'.join(character['personality'])}\n"
        f"说话习惯：{character['speech_style']}\n"
        f"禁忌：{'、'.join(character['taboo'])}"
    )
    return OPENING_TEMPLATE.format(
        tone=world["tone"],
        forbidden="、".join(world["rules"]["forbidden"]),
        character_block=character_block,
    )

注意模板里明确写了"不要输出大纲、说明"。不加这句，模型很喜欢先给你一段"好的，下面是正文"然后才开始写，批量跑的时候这些前缀会污染输出文件。

7. 开篇生成测试与效果验证

设定文件准备好之后，先别急着批量跑。第一步永远是用最小参数跑单章，确认输出结构对不对、角色口吻像不像、系统提示格式有没有跑偏。这一步花十分钟，能省掉后面几十章的返工。

7.1 单章生成测试

测试目的是验证三件事：开场是否直接进入场景、角色对白是否符合设定的说话习惯、系统提示是否严格按格式输出。测试时把温度调低一点，比如 0.6，先看稳定性，等模式跑通了再往上调追求变化。

python复制# scripts/gen_one.py
import json
import requests

API_URL = "http://127.0.0.1:11434/v1/chat/completions"
MODEL = "qwen2.5:7b"

with open("config/characters.json", encoding="utf-8") as f:
    chars = json.load(f)["characters"]

with open("config/world.yaml", encoding="utf-8") as f:
    import yaml
    world = yaml.safe_load(f)["world"]

from prompt_builder import build_opening_prompt

prompt = build_opening_prompt(chars[0], world)

payload = {
    "model": MODEL,
    "messages": [
        {"role": "system", "content": "你是一名中文小说写作助手，严格遵循给定的结构约束。"},
        {"role": "user", "content": prompt},
    ],
    "temperature": 0.6,
    "max_tokens": 3000,
}

resp = requests.post(API_URL, json=payload, timeout=300)
resp.raise_for_status()
text = resp.json()["choices"][0]["message"]["content"]

with open("outputs/chapter_001.md", "w", encoding="utf-8") as f:
    f.write(text)

print(f"生成完成，字数约 {len(text)}")

判断成功的标准很直接：第一，开头有没有出现"穿越到某某世界"这类复述式流水账，有就说明开场约束没起作用，需要把"不超过 80 字"这条写得更硬。第二，对白里有没有出现与角色性格矛盾的表达，比如设定"话少"却写了一大段独白。第三，系统提示是不是独立成行且带【系统】前缀。这三条过了，模板基本可用。

常见失败原因也有规律。开场跑偏，多半是系统提示写得太弱，模型把"写作助手"理解成了"随便聊聊"。对白跑偏，是角色卡里的说话习惯描述太抽象，写成"冷静"没用，写成"短句为主，常以反问收尾"才有用。系统格式跑偏，是模板里没说清楚"单独成行"，模型会把它塞进叙述里。

7.2 一致性、长文本与批量测试

单章跑通后，进入三个维度的验证。一致性测试是连着生成三章，检查角色口吻有没有漂移、系统数值有没有前后矛盾。长文本测试是把上下文推到 8K 甚至 16K，看模型在长上下文下会不会"忘记"开头的设定。批量测试是同时跑五到十章，观察服务是否稳定、有没有请求超时。

一致性问题最有效的解法不是加大模型，而是在每次请求时重新注入完整角色卡和最近一章的结尾摘要。注入摘要比注入全文更省上下文，效果也更稳。摘要可以让模型自己生成，也可以人工写一行"上一章结尾：主角首次触发系统，抽到模板 X，代价是数值清零"。这一行信息量极大。

8. 接口调用与批量任务编排

批量任务的核心设计是"任务清单 + 结果落盘 + 失败重试"。不要写一个 for 循环从头跑到尾，中途报错就全断了。正确做法是把每个章节拆成一个任务项，跑完一个写一个文件，失败的记进日志，最后统一重试。这样即使中途断电，也能从断点续跑。

python复制# scripts/batch_generate.py
import json
import time
import requests
from pathlib import Path

API_URL = "http://127.0.0.1:11434/v1/chat/completions"
MODEL = "qwen2.5:7b"
OUT_DIR = Path("outputs")
LOG_FILE = Path("logs/batch.log")

# 任务清单：章节号 + 大纲要点
TASKS = [
    {"chapter": 1, "outline": "穿越开场，角色冲突，系统激活"},
    {"chapter": 2, "outline": "首次数值结算，抽卡结果，新的冲突预告"},
    {"chapter": 3, "outline": "能力初试，遭遇对手，章节钩子"},
]

def call_model(outline: str, max_retry: int = 3) -> str:
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "system", "content": "你是一名中文小说写作助手，只输出正文。"},
            {"role": "user", "content": f"本章大纲：{outline}\n要求：2000-3000 字，第一人称，结尾留钩子。"},
        ],
        "temperature": 0.75,
        "max_tokens": 3200,
    }
    for attempt in range(1, max_retry + 1):
        try:
            resp = requests.post(API_URL, json=payload, timeout=300)
            resp.raise_for_status()
            return resp.json()["choices"][0]["message"]["content"]
        except Exception as e:
            LOG_FILE.parent.mkdir(exist_ok=True)
            with LOG_FILE.open("a", encoding="utf-8") as f:
                f.write(f"[retry {attempt}] chapter outline={outline[:20]} err={e}\n")
            if attempt == max_retry:
                raise
            time.sleep(2 * attempt)

def main():
    OUT_DIR.mkdir(exist_ok=True)
    for task in TASKS:
        target = OUT_DIR / f"chapter_{task['chapter']:03d}.md"
        if target.exists():
            print(f"跳过已存在：{target}")
            continue
        text = call_model(task["outline"])
        target.write_text(text, encoding="utf-8")
        print(f"完成第 {task['chapter']} 章，约 {len(text)} 字")

if __name__ == "__main__":
    main()

这段脚本有三个值得注意的设计。第一，target.exists() 做断点续跑，跑过的章节不重复消耗算力。第二，重试间隔递增，2 * attempt 秒，避免瞬时高并发把本地服务打挂。第三，日志只记失败，成功不记，日志文件不会无限膨胀。如果你要做并发，把 for 循环换成线程池，但并发数建议控制在 2 到 3，本地单卡跑太高并发反而会拖慢整体速度。

9. 资源占用与性能观察方法

这部分必须自己测，任何人给你的数字都只能参考。观察方法很固定：生成过程中开另一个终端看 nvidia-smi 的显存占用和 GPU 利用率，同时记录单章生成耗时和输出 token 数，算出每秒 token 数。这三个数决定了你的产能上限。

影响性能的变量按影响大小排序：上下文长度、模型参数量、量化等级、并发数、生成 token 数。其中上下文长度最容易被低估——把上下文从 4K 提到 16K，显存占用和首 token 延迟都会明显上升，因为缓存要占更多显存。如果你只是写两千字的章节，8K 上下文完全够，没必要拉到 32K。

降低显存占用的手段有四个：换更小的量化等级（q4 比 q8 省不少）、缩短上下文、降低并发到 1、把部分层卸载到 CPU。最后这个手段会牺牲速度，但能让原本跑不动的模型跑起来，属于兜底方案。纯 CPU 推理的话，速度会掉到每秒几个 token，写一章要几分钟，但胜在不需要显卡。

还有一类问题不属于性能，而属于进程管理。Ollama 和 vLLM 都是常驻服务，跑完批量任务记得停掉，否则显存一直占着。Windows 上有时会出现服务已停止但显存没释放的情况，需要去任务管理器确认进程是否真的退出了。端口冲突也常见，11434 被占就换一个，启动参数里指定端口即可。

10. 常见问题与排查方法

排查顺序建议从外往里：先确认端口通不通，再确认模型在不在，再确认提示词有没有生效，最后才怀疑模型能力。绝大多数"模型不行"的判断，最后都定位在提示词或参数上。

11. 最佳实践与使用建议

第一，永远先小后大。先用一章、低温度、短上下文跑通，再逐步加量。一次性上十个并发加 32K 上下文，出问题你根本不知道是哪一环。

第二，设定文件和生成结果严格分目录。config 只放配置，outputs 按章节编号落盘，logs 只记失败。这套结构看着简单，但跑过一百章之后你会感谢自己。

第三，把"负面清单"当成一等公民。告诉模型"不要写什么"比告诉它"要写什么"往往更有效，尤其是防止角色 OOC 和防止生成违规内容这两件事上。

第四，批量任务必须有人工复核环节。模型会编造原作不存在的情节，也会把设定细节记混，直接发出去风险很高。建议在批量脚本后面加一个"待复核"目录，人工过一遍再进正式稿。

第五，接口服务只监听本地。写作辅助不需要对外提供访问，127.0.0.1 就够了。如果确实要给团队用，加一层简单的鉴权，别裸奔。

第六，涉及同人 IP、真实人物、他人作品素材时，先确认授权再动笔。个人练笔和非商业分享风险相对低，但商业用途、付费内容、改编发布都必须走授权流程。这条没有例外。

这套工作流跑顺之后，最值得先验证的不是"能不能生成一章"，而是"能不能稳定生成十章的连续内容"。前者证明链路通，后者证明设定注入真的有效。最容易踩的坑也在这里——很多人第一章惊艳，第三章就开始人设崩塌，原因基本都是没做摘要注入和一致性校验。后面想继续扩展的话，可以往上加一个本地向量库做设定检索，让模型在写之前先"查资料"；也可以加一个规则校验脚本，自动检查系统数值是否前后闭合。这些都不难，难的是先把最小可用版本跑稳。