看到这个标题第一反应是网文不是技术题。但把标题拆开会发现一条非常标准的内容生产链路确认 IP 题材、设计爽点、固化人设、维持更新最后用工具批量生成章节。这条链路放到程序员的视角里就是一个“同人创作辅助系统”。这篇文章不评价小说内容本身而是拿这个标题当案例拆解如何把一个网文选题变成可执行的工程流程怎么设计标题模板、怎么把角色和队伍写成结构化数据、怎么用本地部署的大模型批量生成章节、怎么验证输出质量以及这套流程的资源边界在哪。整个方案里最值得关注的不是某个模型跑分而是两个工程点一是把创作过程拆成可组合的模块设定库、标题模板、生成脚本各自独立坏了能单独换二是把批量能力留出来单章生成和整卷生成之间只差一个循环。适合想给同人写作搭一套半自动管线的读者也适合把文本生成任务接到自己工具链里的开发者。先看整体能力再讲怎么部署和验证。整个链路可以用普通消费级显卡跑也可以用纯 CPU 跑小参数模型具体取决于你的模型选择。文章末尾会给出排查清单。1. 核心能力速览这套方案的本质是把“宝可梦同人小说创作”拆成几个可调用的模块标题生成、设定数据化、章节生成、批量任务、效果校验。下面按项目能力速览表格给出整体规格。能力项说明项目类型同人创作辅助工作流含标题模板、设定库、本地大模型文本生成输入素材小说标题、角色设定、队伍配置、章节大纲主要功能标题批量生成、角色设定结构化、章节文本生成、字数与一致性检查模型要求本地大模型CPU 可跑小参数GPU 可跑更大参数显存以实际模型为准启动方式本地模型服务启动 Python 脚本调用是否支持 API支持本地模型服务通常提供 HTTP 接口是否支持批量任务支持章节生成可写成目录批量任务适合场景同人小说辅助创作、文本批量生成测试、设定问答扩展这里需要说明表格里的“项目”不是现成的开源仓库而是一套可以照着搭的方法论。标题里的“黑喷”“三首恶龙”“晴天队”等内容本文只作为案例字段使用不涉及原作剧情评价。宝可梦是第三方 IP实际创作前要确认平台规范和使用授权这部分到第 9 章专门展开。2. 同人创作辅助系统的适用边界这套工作流不是只能用于网文。它适合的是一类典型任务给定一批结构化输入让大模型稳定产出大量中文文本并且产出内容能通过关键词和字数校验。具体到标题里的场景就是固定一个宝可梦世界观保存一批角色和队伍设定然后让模型按章节生成剧情。它解决的核心问题有三个保持设定一致。人设、宝可梦、天气队逻辑不会写到后面就乱。批量更新。几十个章节可以排队生成不需要人工复制提示词。可回滚。设定和正文分开存改设定不影响已经生成的章节。不适合什么场景也要说清楚。如果做严肃文学、追求完全原创和独特文风当前这套“模板 大模型”的流程会显得生硬。如果目标是直接发布到商业平台并产生收益还需要额外确认 IP 方的衍生内容政策不能默认同人创作可以随意商用。使用边界方面涉及版权、隐私和安全。本地部署模型时素材不出本机隐私风险低如果使用在线 API需要把提示词中的非公开设定脱敏后再发送。凡是生成内容里出现真实人物、真实声音、真实肖像的都必须在授权范围内使用。本文案例只涉及虚构角色和游戏设定不涉及真实人物。3. 爆款标题的工程化拆解先看这个标题本身【宝可梦 超长同人文】【宝可梦我用黑喷走向巅峰之路】龙系天王老爸搂着三首恶龙问我要啥龙系精灵我嫌弃地选晴天队系统绑定还送闪光爆棚功能把它拆成模块是这样几层IP 前缀【宝可梦】题材标注【超长同人文】主标题我用黑喷走向巅峰之路冲突场景龙系天王老爸搂着三首恶龙问我要啥龙系精灵选择反转我嫌弃地选晴天队系统金手指系统绑定额外爽点还送闪光爆棚功能这基本覆盖了网文标题的高频套路明确 IP 归属、点出长文属性、给出角色画像、制造选择冲突、塞入一个金手指、最后加一个增量爽点。工程上这种组合关系非常适合作成模板。可以写成 Python 模板生成器每次替换槽位即可生成大量候选标题# -*- coding: utf-8 -*- 宝可梦题材网文标题生成器示例 import itertools templates [ 【宝可梦 超长同人文】【宝可梦{主标题}】{人物冲突}{主角选择}{金手指}, 【宝可梦 超长同人文】【宝可梦{主标题}】{人物冲突}问我要啥{属性}精灵{主角选择}{金手指}, ] elements { 主标题: [我用黑喷走向巅峰之路, 我用晴天队一路碾压, 从拒绝龙系开始], 人物冲突: [龙系天王老爸搂着三首恶龙], 属性: [龙系], 主角选择: [我嫌弃地选了晴天队, 我反手掏出黑喷], 金手指: [系统绑定还送闪光爆棚功能, 系统送出一整套天气对战卡], } for t in templates: for combo in itertools.product(*elements.values()): title t.format(**dict(zip(elements.keys(), combo))) print(title)输出结果是一批同风格候选标题。这个脚本的价值不在标题本身而是把“标题风格”从个人感觉变成了可替换配置。后续要换题材只需要替换 elements 字典。标题元素对应工程概念示例值IP 前缀命名空间宝可梦题材标注标签分类超长同人文主标题核心定位我用黑喷走向巅峰之路人物冲突角色关系条件龙系天王老爸搂着三首恶龙选择反转行为分支我嫌弃地选晴天队系统金手指外挂机制系统绑定爽点预期收益闪光爆棚功能注意标题里的“黑喷”属于粉丝群体常见称呼实际指代的可能是闪光喷火龙或特定 Mega 进化形态。同人创作如果沿用这类称呼最好在开篇或设定页写清楚自己的定义避免和官方设定混淆。“三首恶龙”是龙属性宝可梦属于标题中“龙系天王”配置的核心搭档设定数据化时需要记录这些关系。4. 设定数据化角色、队伍与天气队逻辑标题里信息量最大的不是冲突而是三套设定人设龙系天王老爸、宝可梦绑定三首恶龙、黑喷、队伍思路晴天队。把这三样写成结构化数据后续提示词就不用手写。JSON 是合适的格式。下面给出一份设定文件示例包含世界、角色、队伍三个维度{ world: { ip: pokemon, fanwork_type: 超长同人文, region: 自设地区需在正文中定义 }, characters: [ { name: 主角, partner: 黑色喷火龙, note: 黑色外观来自同人设定需与官方世界观保持兼容, goal: 走向巅峰之路 }, { name: 龙系天王老爸, role: 主角父亲专精龙属性宝可梦, pokemon: [三首恶龙, 其他龙系宝可梦], encounter_settings: 开场要求主角选择龙系精灵 } ], combat_team: { name: 晴天队, weather: sunny, core_mechanic: 通过日照天气强化火属性和部分草属性招式, key_skills: [日照, 火属性输出, 叶绿素提速, 阳光烈焰], advantage: 覆盖标题冲突先拒绝龙系再建立晴天体系 } }这份 JSON 不只是给人看的。后续所有生成脚本都可以读取它把关键字段拼进提示词。比如生成第一章时提示词里自动带上“角色主角”“伙伴黑色喷火龙”“开局场景龙系天王老爸搂着三首恶龙要求选择龙系精灵”。这样章节内容就不会偏离标题设定。队伍逻辑也要数据化。晴天队是宝可梦对战里的一种天气体系核心思路是通过日照天气强化火系技能并让部分草系宝可梦获得速度加成。如果剧情写到对战需要让模型理解这套逻辑而不是让它随便写几个技能名。可以在设定库里增加一个“天气体系说明”字段{ weather_system: { sunny_team: { trigger: 天气从普通变为日照, effects: [火属性招式威力提高, 日光束可缩短蓄力, 部分宝可梦速度提升], counter: 需要防范天气被覆盖或对手使用雨天/沙暴体系 } } }设定越结构化批量生成的一致性越高。需要扩展时直接往 JSON 里加字段即可不用改任何生成逻辑。5. 环境准备与本地创作模型部署真正跑章节生成前先检查环境。下面是一份通用检查清单具体版本和安装方式要以实际项目文档为准操作系统Windows 10/11、Ubuntu 20.04、macOS 均可选熟悉的一套。Python建议 3.10 及以上用于运行标题生成、批量调用脚本。本地模型运行时Ollama、llama.cpp、vLLM 等任选一个负责加载模型并提供 HTTP 服务。模型文件根据显存和磁盘选择CPU 跑小参数模型GPU 跑更大参数。CUDA 环境如果使用 N 卡 GPU 加速需要安装对应版本驱动和 CUDA 工具链。磁盘空间模型文件从几 GB 到几十 GB 不等预留足够空间。端口模型服务默认端口可能冲突启动前检查。启动本地模型服务时先启动服务端再用脚本去访问。以 llama.cpp 的 server 为例命令格式如下# 启动 llama.cpp server 示例实际路径和端口按本机替换 ./llama-server -m ./models/example-model.gguf --host 127.0.0.1 --port 8080如果使用 Ollama命令模板是# 启动 Ollama 后台服务 ollama serve拉取模型时需要先确认模型库里实际存在的名字不要照抄网上的任意名称。示例命令写出来是为了展示流程真实环境要以ollama list或模型库页面为准# 拉取模型示例模型名需要改成你环境中真实可用的 ollama pull qwen2.5:14b服务起来后先做一次最简单的连通性测试。用 curl 请求生成接口确认返回正常# 连通性测试接口路径按实际模型服务文档调整 curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:example-model,messages:[{role:user,content:你好}],stream:false}能拿到 JSON 响应说明服务正常可以进入功能测试阶段。这里“模型名”“端口”都是占位值换成实际值后再跑。6. 章节生成验证与效果检查部署完成后用一个小数据集做功能测试。测试目标是验证五个维度基础生成、角色一致性、设定一致性、字数达标、稳定性。设计一个测试用例。输入是大纲字符串输出是章节内容。用 Python 脚本读取设定库把关键字段拼进提示词然后调用本地模型服务# -*- coding: utf-8 -*- import json import requests from pathlib import Path # 读取设定库 setup json.loads(Path(setup.json).read_text(encodingutf-8)) character setup[characters][0] dad setup[characters][1] outline 主角拿到黑色喷火龙龙系天王老爸要求他选择龙系精灵主角拒绝并选择晴天队。 prompt f 你是一位宝可梦同人小说作者。请根据以下设定和 3000 字章节大纲只输出小说正文。 世界{setup[world][ip]}同人 主角{character[name]}搭档是{character[partner]} 父亲{dad[name]}专精龙系搭档包括三首恶龙 队伍{setup[combat_team][name]}核心是{setup[combat_team][core_mechanic]} 大纲 {outline} .strip() resp requests.post( http://127.0.0.1:8080/v1/chat/completions, json{ model: example-model, messages: [{role: user, content: prompt}], temperature: 0.8, max_tokens: 4096, stream: False, }, timeout600, ) content resp.json()[choices][0][message][content] Path(chapter_test.md).write_text(content, encodingutf-8) print(生成完成字符数, len(content))运行后从输出文件检查三个点字数是否接近预期。3000 字大纲生成结果如果只有 500 字说明 max_tokens 设置偏小。角色是否保持稳定。文中是否出现了“三首恶龙”“黑色喷火龙”“晴天队”等关键设定。天气队逻辑是否合理。写到对战时是否出现日照天气带来的火系增强或草系加速描述。可以写一个简单的关键词校验脚本不依赖人工逐字读# -*- coding: utf-8 -*- from pathlib import Path text Path(chapter_test.md).read_text(encodingutf-8) keywords [三首恶龙, 黑喷, 晴天队, 日照, 火] for kw in keywords: count text.count(kw) status 通过 if count 0 else 缺失 print(f{kw}: {count} 次{status})这个脚本是锦上添花。真正判断质量还是要人读一遍尤其是剧情转折、角色动机这些模型容易写飘的地方。基础生成通过后再进入批量任务。7. 批量任务与接口 API 调用批量生成的核心是循环。把大纲文件放到一个目录里遍历文件逐个调用模型接口输出章节到另一个目录。目录结构可以设计成project/ ├── setup.json ├── outlines/ │ ├── chapter_01.txt │ ├── chapter_02.txt │ └── chapter_03.txt ├── outputs/ │ ├── chapter_01.md │ ├── chapter_02.md │ └── chapter_03.md └── logs/ └── run_20250101.log批量脚本示例# -*- coding: utf-8 -*- import json import time import requests from pathlib import Path API_URL http://127.0.0.1:8080/v1/chat/completions MODEL_NAME example-model setup json.loads(Path(setup.json).read_text(encodingutf-8)) def generate_chapter(outline_path: Path, output_dir: Path) - bool: outline outline_path.read_text(encodingutf-8) prompt f根据以下大纲生成一章宝可梦同人小说要求保持设定一致。\n\n{outline} try: resp requests.post( API_URL, json{ model: MODEL_NAME, messages: [{role: user, content: prompt}], temperature: 0.8, max_tokens: 4096, stream: False, }, timeout600, ) resp.raise_for_status() content resp.json()[choices][0][message][content] output_dir.mkdir(parentsTrue, exist_okTrue) (output_dir / (outline_path.stem .md)).write_text(content, encodingutf-8) return True except Exception as exc: print(f失败: {outline_path.name}, {exc}) return False outlines sorted(Path(outlines).glob(*.txt)) for idx, op in enumerate(outlines, 1): ok generate_chapter(op, Path(outputs)) print(f[{idx}/{len(outlines)}] {op.name}: {成功 if ok else 失败}) time.sleep(1)批量任务最容易踩的坑是超时和断连。模型服务如果同时处理多个请求可能排队超时时间要设置足够大。建议在脚本里加失败重试指数退避即可不要无限重试。接口 API 的调用格式不固定。不同模型服务的路径、请求体细节有差异上面的请求体是 Chat Completions 风格如果用的是非 OpenAI 兼容接口需要按实际文档调整。关键是把“输入大纲目录”到“输出章节目录”这个批处理逻辑固定下来接口变化只改一个函数。8. 资源占用与性能观察本地部署文本生成模型最关心的就是显存和内存。不同参数规模的模型差异很大这里不给死数字重点讲清楚观察方法和降占用手段。观察资源的常用命令# 查看 GPU 显存占用NVIDIA 显卡 nvidia-smi # 查看模型服务进程内存占用 ps aux | grep llama-server # Windows 下可用 tasklist 查看进程推理时参数对性能的影响生成长度越长耗时和显存占用越高。批量生成章节时max_tokens 设 2048 和 4096 的差别很明显。并发请求数越高显存占用和内存占用越高。本地测试建议先用单请求跑通再考虑并发。上下文长度越长显存占用越高。保持设定一致需要把设定库放进提示词但不必把整本书设定全塞进去只放当前章节相关字段。CPU 推理可用但速度慢。小参数模型在 CPU 上能跑更大参数模型建议 GPU。降低显存占用有几个通用办法换更小参数的模型、使用量化版本、缩短上下文、关闭多余并发、降低 max_tokens。如果 8G 显存跑不动某个模型通常不是代码问题而是模型超出硬件范围换小一号模型是最快的解决办法。性能验证也分两部分。一是单次生成耗时记录从请求发出到返回完整 JSON 的时间二是批量任务整体耗时记录整个循环执行完的时间。把这两个数字写进脚本日志后续换模型或调参数时可以直接对比。9. 常见问题排查与最佳实践问题现象可能原因排查方式解决方案模型服务起不来端口被占用、模型文件缺失查看启动日志检查端口换端口检查模型路径请求返回 404接口路径不对查看模型服务文档改用正确的 API 路径生成内容走题提示词不够明确设定库未拼入检查 prompt 是否包含角色与队伍字段把关键设定直接写进提示词显存不足模型参数过大或上下文过长观察 nvidia-smi 占用换小模型或量化模型缩短上下文章节字数不够max_tokens 设置过小查看返回内容是否被截断增大 max_tokens批量任务卡住单请求超时或服务无响应查看日志超时时间增加 timeout加入失败重试关键词缺失模型没理解设定检查提示词中的设定说明增加设定摘要多次生成对比再补充一些工程化建议第一次测试用小参数模型、小大纲先跑通全链路再慢慢加模型参数。保留一套最小可运行配置。把模型名、端口、目录结构写成配置文件别改一次换一次。设定库、大纲、输出目录分清楚不要混在一个文件夹里。批量任务必须加日志。运行日期、成功失败、耗时都记录下来方便排查。接口服务只绑定到 127.0.0.1不要暴露到公网尤其在有敏感设定的情况下。生成内容发布前必须人工复核。大模型可能输出看似合理但偏离设定的内容同人作品需要保持读者体验一致。涉及宝可梦 IP 的同人创作要遵守平台规范和原 IP 方政策不默认可以商用。涉及真实人物、声音、肖像的内容必须确认授权。涉及“闪光”“换色”“替换角色”等设定时注意与官方设定的区分避免误导读者。这套流程跑通之后后续可以扩展的方向很多把设定 JSON 接入检索问答让模型在生成前自动查询相关设定把普通文本生成升级为多角色对话式生成把章节分成大纲、草稿、成稿三个阶段分别用不同模型和参数处理。总之先用最小链路验证价值再逐步加模块。这套工作流最值得尝试的点是把“标题拆解”和“设定结构化”做成工程读者可以先从标题模板生成器开始验证整套思路是否适合自己。最容易踩的坑不是模型跑不动而是设定没结构化导致生成内容前后矛盾。建议先把 setup.json 写好再谈生成。