本地大模型写作辅助流水线：角色卡、设定检索与批量续写

写这类“穿越斗罗大陆、觉醒系统、开局送模板”的长篇同人，读者追的是爽点密度，作者扛的是设定一致性。几十万字下去，最容易翻车的往往不是文笔，而是人设漂移、魂力等级写串、伏笔断线——上一章唐三还在史莱克，下一章就把玉小刚写成了路人。这篇不讲怎么写爽文，讲怎么用一套本地部署的大模型流水线，把“角色卡、设定库、章节续写、批量生成、接口调用”串起来，让写作辅助真正能落地。

这套方案的核心思路是把模型放在本机跑：正文不出本地，隐私可控；上下文可以按需拼接，不依赖平台额度；提供 HTTP 接口，能直接接到自己的写作脚本里；支持批量章节任务，一次跑十几章草稿；显存门槛取决于所选模型规模，7B 级量化模型在消费级显卡上通常能跑，具体占用以本机实测为准。它不是替你写小说，而是替你守住设定、补足过渡段落、批量出草稿。

本文会按“环境准备 → 服务启动 → 功能测试 → 接口调用 → 批量任务 → 资源观察 → 排错”的顺序走一遍。你会看到角色卡怎么组织、检索怎么做、章节批量脚本怎么写、显存怎么观察、端口冲突怎么处理。全文给的是可复制的命令和骨架代码，路径和模型名需要按你的实际环境替换。

适合两类读者：一是正在写长篇同人或连载、被设定一致性折磨的作者；二是想把本地大模型接进自己内容生产工具链的开发者。如果你只想要一个网页对话框，这篇文章的部分内容会显得重，但如果你要的是“跑得稳、能批量、可复现”，下面的流程可以直接照搬。

1. 核心能力速览

先把这套方案能干的事摆清楚，避免看到后面才发现方向不对。

有一点必须说在前面：这套东西的定位是“辅助”。模型能给你一个通顺的过渡段、能提醒你某个角色的口头禅前后不一致、能按大纲铺出三千字草稿，但它不知道你埋了三章的伏笔打算在哪一章收。设定库和角色卡的价值，恰恰是把这些只有作者知道的信息，变成模型每次生成都能读到的上下文。

从上表也能看出，真正决定体验的不是模型多大，而是你的“上下文工程质量”。同样一个 7B 模型，喂给它一份结构清晰的角色卡和最近三章正文，输出质量会明显好于只丢一句“续写下一章”。所以后面的章节里，检索和模板的篇幅会比模型参数更多，这是有意为之。

2. 适用场景与创作边界

2.1 这套流程适合谁

第一类是长连载作者。日更压力下，最耗时间的往往不是高潮章节，而是过渡章节和配角戏。这类内容有固定套路，交给模型出草稿、自己改，效率提升明显。第二类是同人创作者，原作设定庞杂，写之前要反复核对人物关系和时间线，用检索把设定片段自动带进上下文，能省下大量翻资料的时间。第三类是内容工具开发者，想做一个自己的写作助手，需要一个能本地跑、能调接口、不依赖外部服务的后端。

反过来说，如果你写的是短篇、每篇独立、不需要维护长期设定，那这套流水线的收益很有限，直接用一个网页对话框更省事。如果你的机器只有核显、内存也不宽裕，CPU 推理跑长上下文会非常慢，体验会很差，这种情况建议先降低模型规模或者缩短上下文再评估。

还有一个现实问题：模型生成的草稿需要人来判断好坏。它能写出语法正确的句子，但判断不了“这段爽不爽”。所以流程设计上一定要留人工复核环节，别做成全自动发布。批量脚本跑完，输出目录里的文件应该被当作待审稿件，而不是成稿。

2.2 版权与合规边界

这一点必须写清楚。同人创作涉及原作版权，不同平台对同人内容的政策差异很大，发布前要确认目标平台的具体规则。用模型生成的内容，其可版权性在不同法域存在争议，商业使用前建议做专业咨询。更实际的一条：不要用模型去批量生成带有明显侵权风险的商业化内容，也不要把原作大段原文直接喂进模型做“改写洗稿”，这类做法风险很高。

另外，如果你在处理真实人物的素材（比如把身边朋友写进小说），要注意个人信息保护，避免未经允许使用他人真实姓名、经历、照片。模型服务部署在本机、正文不出内网，本身就是一层保护，但日志、缓存目录里同样会留下文本，定期清理是必要的习惯。

3. 环境准备与前置条件

3.1 硬件与系统检查

先确认机器底子。显卡方面，独立显卡优先，显存越大能承载的模型规模和上下文越长；没有独显也能跑，走 CPU 推理即可，只是长文本生成会明显变慢。内存方面，模型加载时会占用系统内存，建议留足余量，别让系统和模型抢内存导致频繁换页。磁盘方面，一个 7B 级量化模型通常几个 GB 起步，多准备几个模型的话，几十 GB 空间是常见需求。

系统层面，Windows 10/11、主流 Linux 发行版、macOS 都可以。Windows 上建议用 PowerShell 或 Windows Terminal，避免在老旧 cmd 里遇到编码问题。Linux 上确认一下端口没有被占用，尤其是 11434 这类常用端口。macOS 的 Apple Silicon 芯片可以直接利用统一内存跑推理，体验比同价位独显机器有时更好。

动手前先跑几条检查命令，把环境信息记录下来，后面排错会用到。

bash复制# 检查显卡与驱动（NVIDIA 环境）
nvidia-smi

# 检查内存与磁盘
free -h
df -h

# 检查端口占用（Linux / macOS）
lsof -i :11434

powershell复制# Windows PowerShell 下的端口检查
Get-NetTCPConnection -LocalPort 11434 -ErrorAction SilentlyContinue

如果 nvidia-smi 报错或者显示驱动版本异常，先解决驱动问题，不要急着装推理框架。驱动版本过旧会导致推理服务启动失败或直接回落到 CPU，表现是“能跑但慢得离谱”，很容易误判成模型问题。

3.2 软件依赖与目录规划

软件依赖不多：推理服务本体、Python 环境（跑批量脚本用）、可选的一个向量检索库。Python 建议 3.10 及以上，用虚拟环境隔离依赖，别往系统环境里装。

目录规划这件事很多人忽略，但它直接影响后期维护成本。建议从第一天就分成四个目录：models 放模型文件，settings 放角色卡和世界观设定，inputs 放章节大纲和待处理文本，outputs 放生成结果。这样批量脚本的路径参数好写，出问题也好定位。

bash复制# 目录骨架示例
mkdir -p ~/novel-assist/{models,settings,inputs,outputs,scripts,logs}

# Python 虚拟环境
cd ~/novel-assist
python -m venv .venv
source .venv/bin/activate      # Windows 使用 .venv\Scripts\activate
pip install requests

powershell复制# Windows 下的目录创建
New-Item -ItemType Directory -Force -Path "$HOME\novel-assist\models","$HOME\novel-assist\settings","$HOME\novel-assist\inputs","$HOME\novel-assist\outputs"

依赖装完之后，先别急着写业务脚本，用最简单的 requests 请求验证一下网络和 Python 环境是否正常。这一步看着多余，但能提前排除掉代理配置、防火墙、证书这类问题，省得后面排查时把环境问题和模型问题混在一起。

4. 本地部署与启动方式

4.1 启动推理服务

安装推理服务的方式按官方文档走，安装完成后服务通常会自动注册成一个本地后台进程。手动启动的方式如下，Windows 和 Linux 都是同一条命令，只是终端不同。

bash复制# 启动本地推理服务，默认监听 11434
ollama serve

服务启动后不要关这个终端，另开一个窗口做后续操作。接着拉取模型。模型选择上，7B 级的中文能力通常够用于草稿生成，如果你的机器显存宽裕，可以选更大参数量的版本，但要注意上下文长度和显存是此消彼长的关系。

bash复制# 拉取模型，实际可用的标签以本地服务返回的列表为准
ollama pull qwen2.5:7b

# 查看已安装模型
ollama list

# 交互式试跑，输入 /bye 退出
ollama run qwen2.5:7b

第一次拉取会下载几个 GB 的数据，网速一般的话需要等一会儿。下载完成后先做一次最简单的对话测试，确认模型能正常响应，再进入写作场景。

4.2 验证服务可用性

服务起来之后，用一条 HTTP 请求确认接口能通。这一步是后面所有脚本的前提。

bash复制# 检查服务状态
curl http://127.0.0.1:11434/api/tags

# 最简生成请求
curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "用一句话说明什么是魂力等级。",
  "stream": false
}'

返回体里如果有正常的文本内容，说明链路通了。如果返回连接拒绝，检查服务进程是否还在；如果返回模型不存在，检查 ollama list 里的标签名是否和请求里写的一致。这两个错误占了新手问题的一大半。

4.3 可选：接一个图形界面

命令行毕竟不方便改提示词。想要图形界面的话，可以接一个开源的前端，把接口地址指向本地服务即可。这里不指定具体产品，只给通用配置思路：在设置里填写 API 基地址为 http://127.0.0.1:11434，模型名填你拉取的那个标签，超时时间调大一些，因为长文本生成耗时可能超过默认值。

配置完成后，在建会话时把角色卡和设定片段作为“系统提示”粘进去，就能开始试写。图形界面的价值在于快速迭代提示词，等你把模板调稳了，再固化成脚本。

5. 功能测试与效果验证

5.1 角色卡一致性测试

测试目的很明确：同一个角色，在不同章节的对话里，性格和口吻是否稳定。做法是先写一份角色卡，包含身份、目标、说话习惯、禁忌事项，然后把角色卡塞进系统提示，连续生成三段不同场景的对话，人眼比对。

角色卡不要写成小作文，用结构化字段更有效。字段越具体，模型的漂移空间越小。

json复制{
  "character": "主角",
  "identity": "穿越者，觉醒低级武魂，持有系统模板",
  "goal": "在不暴露底牌的前提下积累实力",
  "speech_style": "心理活动多，对外说话简短，习惯先观察再开口",
  "taboo": ["不主动提及系统", "不在陌生人面前展示武魂"],
  "relationships": [
    {"name": "某导师角色", "attitude": "表面恭敬，内心保留判断"}
  ]
}

判断成功的标准不是文笔多好，而是三次生成里这个角色有没有出现“突然话多”“突然炫耀底牌”这类越界行为。如果有，先检查角色卡字段是否太抽象，把“性格谨慎”改成具体的“遇到陌生强者先退半步再说话”这种可执行描述，效果通常立刻不同。

常见失败原因是角色卡太长、重点被稀释。建议单个角色卡控制在几百字以内，核心约束放最前面。另外，多个角色卡拼在一起时，要给每个角色加清晰的分隔标记，否则模型容易把两个人的设定混在一起。

5.2 章节续写测试

这是最核心的场景。输入是上一章末尾的几百字加本章大纲，输出是本章草稿。操作步骤是：先准备一段真实的上文，再写三条以内的大纲要点，然后发起生成。

测试时要观察三件事：一是承接是否自然，有没有重复上文最后一句；二是大纲要点是否都覆盖到；三是字数是否落在你要求的区间。模型很容易出现的问题是“开头复读上文”，解决办法是在提示里明确写“不要重复上文内容，直接从下一场景开始”。

预期输出应该是一段有场景、有对话、有推进的草稿，而不是大纲的扩写版。如果输出读起来像流水账，说明大纲给得太粗，补充一两个关键动作或冲突点再试。判断成功的标准可以定得务实一些：草稿里至少有七成句子你能直接用或小改，剩下的需要重写，这就算合格。

失败时优先排查上下文长度。上文给太多，模型会抓不住重点；给太少，又接不上。经验上，上文保留一两千字效果比较均衡，具体还要看模型上下文窗口大小。

5.3 设定检索测试

写到后期，设定库会变得很大，不可能全部塞进上下文。这时候需要检索：根据当前章节的关键词，从设定库里捞出最相关的几条，拼进提示词。

先做一个最小可用的版本，不必上向量数据库，用关键词匹配就能跑起来。

python复制import json
from pathlib import Path

def load_settings(path: str) -> list[dict]:
    return json.loads(Path(path).read_text(encoding="utf-8"))

def retrieve(settings: list[dict], keywords: list[str], top_k: int = 3) -> list[dict]:
    scored = []
    for item in settings:
        text = item.get("content", "")
        score = sum(1 for kw in keywords if kw in text)
        if score > 0:
            scored.append((score, item))
    scored.sort(key=lambda x: x[0], reverse=True)
    return [item for _, item in scored[:top_k]]

检索结果拼进提示词时，要标注来源，方便后续核对。测试方法是：拿一个你熟悉的章节大纲，看检索出来的设定是不是你真正需要的那几条。如果捞出来一堆无关内容，说明关键词选得不好，或者设定条目切得太碎。设定条目建议按“人物 / 地点 / 势力 / 道具 / 时间线”分类，每类单独一个文件，检索时按类型加权。

5.4 批量章节生成测试

单章跑通之后，再考虑批量。测试时不要一上来就跑二十章，先跑两章，确认输出文件命名、目录结构、日志记录都符合预期，再加量。

批量任务的关键不是生成，而是“失败可恢复”。脚本里要记录每一章的状态，成功写完成标记，失败写错误原因，重跑时跳过已完成的。这个设计能省掉大量重复劳动。

6. 接口 API 与批量任务

6.1 单轮生成接口

本地服务提供的是 HTTP 接口，POST 请求，JSON 体。核心参数是模型名、提示词、是否流式返回。流式返回适合边生成边看，批量任务里建议关掉流式，一次性拿完整结果更好处理。

python复制import requests

def generate(prompt: str, model: str = "qwen2.5:7b", timeout: int = 300) -> str:
    url = "http://127.0.0.1:11434/api/generate"
    payload = {
        "model": model,
        "prompt": prompt,
        "stream": False,
        "options": {
            "temperature": 0.8,
            "top_p": 0.9,
            "num_ctx": 4096
        }
    }
    resp = requests.post(url, json=payload, timeout=timeout)
    resp.raise_for_status()
    return resp.json().get("response", "")

if __name__ == "__main__":
    print(generate("写一段三百字的场景描写，主角在夜里观察对手的武魂。"))

num_ctx 是上下文窗口大小，调大能塞更多设定，但显存占用也会上去。这个参数不要盲目拉满，按你的实际显存和需求平衡。temperature 控制随机性，写小说一般 0.7 到 0.9 之间，太低会写得干巴，太高容易跑偏。

6.2 兼容接口写法

除了原生接口，本地服务通常还提供一套兼容常见 SDK 的接口路径，好处是可以直接复用现成的客户端代码。

python复制from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:11434/v1",
    api_key="local"   # 本地服务通常不校验，占位即可
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[
        {"role": "system", "content": "你是一名小说写作助手，严格遵守角色卡设定。"},
        {"role": "user", "content": "根据大纲续写本章开头三百字。"}
    ],
    temperature=0.8
)
print(resp.choices[0].message.content)

用这套写法的好处是切换后端成本低——哪天你想换成别的推理服务，只改 base_url 和模型名就行，业务代码不用动。这一点在项目长期维护中很关键。

6.3 批量任务脚本骨架

批量脚本的结构建议分成四层：读任务清单、组装提示词、调接口生成、落盘并记录状态。下面是一个可以直接改用的骨架。

python复制import json
from pathlib import Path
from datetime import datetime

ROOT = Path.home() / "novel-assist"
INPUT_DIR = ROOT / "inputs"
OUTPUT_DIR = ROOT / "outputs"
LOG_DIR = ROOT / "logs"
STATE_FILE = ROOT / "outputs" / "state.json"

def load_state() -> dict:
    if STATE_FILE.exists():
        return json.loads(STATE_FILE.read_text(encoding="utf-8"))
    return {}

def save_state(state: dict) -> None:
    STATE_FILE.write_text(
        json.dumps(state, ensure_ascii=False, indent=2), encoding="utf-8"
    )

def build_prompt(chapter: dict, character_card: str) -> str:
    return f"""【角色卡】
{character_card}

【本章大纲】
{chapter['outline']}

【写作要求】
1. 承接上一章结尾，但不要重复上文句子；
2. 只写本章内容，不要提前展开后文；
3. 对话符合角色说话习惯，避免书面腔；
4. 篇幅控制在 2500 字左右。

请开始写作。
"""

def run_batch(model: str = "qwen2.5:7b") -> None:
    state = load_state()
    character_card = (ROOT / "settings" / "characters.md").read_text(encoding="utf-8")
    tasks = json.loads((INPUT_DIR / "chapters.json").read_text(encoding="utf-8"))

    for task in tasks:
        key = task["id"]
        if state.get(key, {}).get("status") == "done":
            continue
        try:
            content = generate(build_prompt(task, character_card), model=model)
            out = OUTPUT_DIR / f"{key}.md"
            out.write_text(content, encoding="utf-8")
            state[key] = {"status": "done", "at": datetime.now().isoformat()}
        except Exception as exc:
            state[key] = {"status": "failed", "error": str(exc)}
        save_state(state)

if __name__ == "__main__":
    run_batch()

配套的任务清单长这样，放 inputs/chapters.json：

json复制[
  {
    "id": "ch001",
    "outline": "主角初入学院，被分到最弱的班级，暗中观察同学武魂。"
  },
  {
    "id": "ch002",
    "outline": "第一次班级对抗，主角刻意藏拙，只展露基础魂力。"
  }
]

这个骨架里最值得保留的是状态文件。跑几十章的时候，中途某章超时失败很正常，有了状态文件，重跑只补失败的那几章，不用从头再来。日志目录建议同时保留原始请求和返回，出问题时能复盘到底是提示词的问题还是模型的问题。

7. 资源占用与性能观察

7.1 怎么观察占用

观察显存最直接的方式是循环执行 nvidia-smi，看模型加载后和生成过程中的占用峰值。模型加载完成的那一刻占用最高，之后每次请求会有小幅波动。CPU 和内存用 htop 或任务管理器看，重点看有没有出现内存打满后频繁换页的情况，那种状态下生成速度会断崖式下跌。

bash复制# 每 2 秒刷新一次，观察显存变化
watch -n 2 nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv

这里不给具体数字，因为不同量化方式、不同上下文长度、不同批量大小下的占用差异很大，照抄别人的数字没有意义。你要建立的是自己机器上的基线：先跑一个短提示，记下占用；再把上下文加倍，再记一次；再开批量，再记一次。三条数据下来，你对这台机器的能力就有判断了。

7.2 影响性能的几个参数

按影响从大到小排：上下文长度、模型规模、生成长度、批量并发数。上下文翻倍，显存占用通常上升明显，因为注意力计算的开销随长度增长很快。生成长度影响的是耗时而不是峰值显存，输出 3000 字和 800 字的时间差很直观。批量并发数则同时吃显存和内存，本地单卡环境不建议开高并发，串行跑通常更稳。

还有一个容易被忽略的因素：提示词本身的长短。很多人把设定库整个塞进系统提示，动辄上万字，结果每次请求都在为同一段重复内容付出计算成本。正确做法是先检索再拼接，只带相关的几条。

7.3 降低占用的常用手段

如果显存吃紧，按这个顺序尝试：第一，换更小参数的模型或更高压缩的量化版本；第二，把上下文长度降下来，配套用检索减少必填内容；第三，降低批量并发；第四，把特别长的设定拆成多轮对话，而不是一次全塞。

反过来，如果你显存宽裕但生成质量不理想，优先调的不是参数，而是提示词结构。把角色卡、本章大纲、上文摘要、写作要求分成明确区块，比调 temperature 有用得多。

8. 常见问题与排查方法

表格里最后一条特别值得展开。很多人以为上下文窗口越大越好，实际使用中，即使窗口够大，长文本的后段质量也常常下滑。稳妥做法是把长章节拆成两三段生成，每段都带上“上一段结尾”作为衔接，比一次性生成五千字稳定得多。

另一类高频问题是编码。Windows 上默认编码不是 UTF-8 的情况很常见，读写文件时显式指定 encoding="utf-8"，能避免掉一大半“文件打开是乱码”的求助。批量脚本里所有 read_text、write_text 都加上这个参数，是成本最低的防御性写法。

9. 最佳实践与使用建议

第一，模型和业务解耦。所有调用都走一层薄封装，模型名、地址、超时集中在一个配置文件里。这样换模型、换机器、换端口，只改一处，不用满项目搜索替换。

json复制{
  "base_url": "http://127.0.0.1:11434",
  "model": "qwen2.5:7b",
  "timeout": 300,
  "options": {
    "temperature": 0.8,
    "num_ctx": 4096
  }
}

第二，设定库要像代码一样维护。角色卡、时间线、势力关系，都放版本管理里，每次大改留一条记录。写到两百万字的时候，你会庆幸当初做了这件事。设定条目尽量原子化，一条只说一件事，检索时才好精确命中。

第三，批量任务一定要有“最小可运行样本”。新写一个脚本，先用两条任务跑通，确认输出目录、命名、日志都对，再放量。直接上千条任务跑一夜，第二天发现路径写错，这种坑踩一次就够记一辈子。

第四，人工复核环节不能省。给输出文件加一个状态字段，draft、reviewed、published，脚本只处理 draft。复核的时候重点看三件事：设定有没有冲突、角色口吻有没有跑偏、有没有出现和前文矛盾的细节。

第五，涉及原作角色和真实素材时，先确认授权与平台规则。同人创作的法律边界因地区和平台而异，商用前务必做合规评估。不要把模型输出直接当作可发布内容，人工改写和判断是必要环节。

第六，定期清理缓存和日志。本地服务会在磁盘上留模型缓存，写作脚本会留请求日志，这些内容含正文片段，长期堆积既是空间问题也是隐私问题。设一个定期清理的任务，比事后补救省心。

10. 总结与下一步

这套流程真正值钱的地方不在模型，而在于把“角色卡、设定检索、提示词模板、批量脚本、状态记录”这五件事串成了一条可复现的线。模型会换代，接口地址会变，但这套结构不变。你先把它跑通一次，后面换任何模型都只是改一个配置字段的事。

如果只打算试一件事，建议从角色卡一致性测试开始。它成本最低，收益最直观，而且能立刻暴露你设定文档里那些含糊其辞的地方——很多作者是在写角色卡的时候，才第一次想清楚配角到底想要什么。

最容易踩的坑有三个：一是提示词里塞太多内容，导致模型抓不住重点；二是批量任务没有状态记录，失败一次全部重跑；三是忽视了编码和路径，在 Windows 上尤其常见。这三个问题的共同点是，它们都不是模型能力问题，而是工程细节问题。

往后可以继续扩展的方向：把设定检索从关键词升级成向量召回，提升长设定库的命中率；给不同章节类型（打斗、对话、过渡）配不同的提示词模板；把人工复核结果回流成评分数据，用来筛选更合适的模型；如果多人协作，可以把设定库放到共享目录，用文件锁避免并发写冲突。

建议把这篇收藏一下，尤其是第 8 节那张排查表和第 6.3 节的批量骨架，实际动手的时候翻出来对照，比从头读一遍文档快得多。