简介：AI小说创作助手是一套面向小说作者与写作爱好者的实用型创作工具，基于人工智能与提示词技术，覆盖灵感触发、框架拆解、书名与简介生成、正文润色、错别字与语法修正等完整创作环节，适合想要提升写作效率、突破创作瓶颈的各类作者使用。资源包共包含52个文件，以17个Python脚本和13个JavaScript文件为主体，前者提供多模型API调用与后端逻辑，后者承载前端交互与编辑界面；另含10张PNG界面图与思维导图，以及TXT、MD、DOCX等说明文档，便于理解工具结构和使用方式，整体体积约3.48MB。目前已有52人学习/下载。通过该资源可拿到完整可运行的创作助手源码及配套文档，包含提示词管理、智能拆书、书名简介生成、多模型切换等模块，同时保留教程与界面预览，方便直接部署、二次开发或作为学习AI写作工具设计的参考。
1. AI小说创作助手：把提示词管起来，创作效率才能提上去
做网文或者短篇创作的，应该都有过这种体验：用 ChatGPT、Claude 这类大模型写东西，开头几章还行，写到后面风格就飘了；换个模型、换个对话窗口，之前攒的设定和语气全得重新讲一遍。AI 不是不能写，是没人把「怎么写」这件事沉淀成可复用的东西。这个 AI 小说创作助手，干的就是这件事——它把提示词工程做成了生产力工具，内置智能拆书、书名与简介生成、正文润色这些针对小说场景的功能，所有提示词模板集中管理，一次调好，后面反复调用。它不是来替你想故事的，它是把你和大模型之间的沟通成本压到最低。适合每天产出几千字的连载作者、做写作教学的博主，以及想批量验证创意但不想在提示词上反复返工的人。整个资源打完包就是一个 zip 压缩包，里面是源码、提示词库和配置模板，拉到本地就能跑。
2. 提示词工程与资源包结构：先弄明白这个 zip 里装了什么
2.1 提示词模板的分层设计：角色、任务、约束、变量
拆开这个压缩包之前，得先理解它背后的提示词设计思路。好的小说提示词不是一段「请帮我写一章」这么简单，而是要拆成四层：角色定义、任务说明、约束条件、变量插槽。
角色定义解决「你是谁」的问题，比如「你是一个擅长写东方玄幻的资深网文作者，文风爽快、节奏密集，擅长在章末埋钩子」。任务说明解决「做什么」的问题，比如「根据大纲和角色卡，续写本章 3000 字」。约束条件解决「不许做什么」的问题，比如「不使用现代词汇，不出现网络梗，对话要符合人物性格」。变量插槽则是留给每次调用动态填充的部分，比如{章节号}、{主角状态}、{前情提要}，这些内容每章都不一样，模板本身不写死。
这个工具把四层结构可视化地存成了 JSON 配置文件，每条提示词对应一个独立 ID，调用时底层代码先做变量替换，再拼装成最终发给大模型的完整消息。这样一来，提示词变成了可维护的资产，而不是散落在聊天记录里的片段。实际拆包后你会看到prompts/目录下有role_system、task_user、constraint三类文件，稍后我会把核心的加载逻辑贴出来。
2.2 压缩包目录结构与启动流程：先跑通最小可用的路径
整个 zip 解压之后，目录结构大致是这样：config/放模型网关配置与密钥占位符；prompts/放提示词 JSON；src/放核心 Python 代码；outputs/放生成结果；根目录有一个requirements.txt和README.md。这个结构对常写脚本的人来说很熟悉，但对刚开始接触 Python 工具的新手，建议先别急着改代码，按下面这个顺序跑通最小路径。
先安装依赖，再检查配置文件，然后调用一次「书名生成」功能验证链路是否通。我习惯先看一眼requirements.txt，里面对应的依赖版本说明了它适配 Python 3.10 左右的环境，如果本机版本过低，后面跑模型网关时会遇到编译错误。跑通之后再去看提示词库，这时候你对模板的理解就是有实感的了。
import json from pathlib import Path prompt_dir = Path("./prompts") loaded = {} for f in prompt_dir.glob("*.json"): data = json.loads(f.read_text(encoding="utf-8")) loaded[data["id"]] = data # 以 book_title 这个模板为例 tmpl = loaded["book_title"] print(tmpl["role"]) # 角色层 print(tmpl["constraints"]) # 约束层 print(tmpl["user_template"]) # 用户消息模板，里面有 {题材}、{风格} 这种插槽这段代码的逻辑很简单：遍历prompts目录下所有 JSON 文件，按id建立索引。这样做的意义在于，后续调用 API 时不需要在代码里拼提示词字符串，而是从配置中心取模板，改提示词不需要动业务代码。参数说明里要注意glob("*.json")只匹配一层目录，如果模板分了子目录，需要改成rglob，这是新手很容易踩的坑。
2.3 可插拔模型网关：一个 base_url 从云端切到本地
拆包之后还有一个关键设计：模型网关。它不直接绑定某一家大模型厂商，而是抽象出一层通用调用接口，配置项里写着api_type、base_url、api_key、model_name。这套设计让工具能同时对接 OpenAI、DeepSeek、Kimi，以及本地部署的 Ollama。
我实际用过两种模式。联网模式直接填云端 API，适合追求生成质量、不差 token 费的用户；本地模式把base_url改成http://localhost:11434，模型名填qwen2:7b这类 Ollama 里的名称，完全不花 API 费用，速度慢一些但有隐私优势。工具在代码里对这两种模式做了统一处理，差异只在配置，这降低了从免费本地模型切换到商用 API 的学习成本。
# src/llm_gateway.py 的简化版 import requests def chat(messages: list[dict], temperature: float = 0.8, max_tokens: int = 2000): cfg = load_config() endpoint = f"{cfg['base_url']}/chat/completions" if cfg["api_type"] == "openai": resp = requests.post(endpoint, headers={ "Authorization": f"Bearer {cfg['api_key']}", }, json={ "model": cfg["model_name"], "messages": messages, "temperature": temperature, "max_tokens": max_tokens, }) else: # ollama 也用同一套 messages 格式 resp = requests.post(endpoint, json={ "model": cfg["model_name"], "messages": messages, "stream": False, }) return resp.json()["choices"][0]["message"]["content"]这段代码核心是把需要的鉴权和请求地址做了一层转发。api_type判断走哪套认证逻辑，但 messages 结构保持统一，所以换模型时提示词模板完全不用改。我在本地环境一般把temperature调成0.7，云端模型调成0.9，因为本地小模型本身输出偏保守，不提升抽样温度会显得很干。
3. 智能拆书与书名生成：一个完整的工作流拆给你看
3.1 拆书模块的本质：把「这本书好看」翻译成参数
很多人第一次用拆书功能时以为它是批量摘要，其实不是。这个模块做的是把一本小说「为什么好看」拆成可量化的维度，包括节奏密度、爽点频率、钩子位置、人物弧光、视角切换点。拆书的结果不是一段总结，而是一张结构化表格，后端会把大模型输出解析成 JSON 再落盘。
拆书的工作流分三步：第一步，把全书文本按章切成片段，每段不超过 3000 字，避免超出上下文窗口；第二步，每章调用一次分析提示词，输出该章的钩子数量、情感曲线、冲突类型；第三步，把所有章节的分析结果汇总，用一次聚合提示词生成全书报告。这个思路很聪明，它把长文本处理拆成了「分片分析 + 汇总归纳」两个阶段，避开了上下文工程里最头疼的长文丢失问题。
拆书提示词本身我也研究了一下，它在 user 模板里要求大模型按固定格式输出，比如冲突类型: 派系斗争; 激烈程度: 高; 章末钩子: 女主身世揭穿。用固定的标签结构约束输出格式，后续做统计聚合就会非常简单。
3.2 批量书名生成：temperature 与候选池的配合
书名生成是这个工具里上手最快、也最容易看到效果的功能。它一次生成 10 到 20 个候选书名，每个书名附上简短的解释。核心参数是temperature：太低书名会高度雷同，太高书名天马行空但完全不像网文。我自己试下来0.9到1.1之间最合适，既有变化又保留文感。
除了温度，它还用了「候选池 + 过滤规则」的组合策略。生成完一批后，先跑一遍本地过滤：书名长度超过 15 个字直接扔掉，命中敏感词库的扔掉，和已有书名重复度太高的扔掉，剩下的才输出给用户。这个设计深得我心，因为大模型输出具有随机性，与其靠一次生成碰运气，不如先批量产、再规则筛，还能省去人工二审的时间。
import random candidates = [] for i in range(10): response = chat( messages=[{"role": "user", "content": tmpl.render(topic="修仙", style="轻松")}], temperature=random.uniform(0.9, 1.1), # 每次调用温度微浮动 ) candidates.append(response) def clean(candidates): seen = set() result = [] for c in candidates: title = c.strip()[:15] if title in seen or len(title) > 15: continue seen.add(title) result.append(title) return result[:5]这里每次调用都让 temperature 在一个区间内随机浮动，而不是固定值，这样候选池的多样性会更好。random.uniform(0.9, 1.1)这段是新增的微随机逻辑，如果你希望完全可控，可以把区间直接设成固定值。参数调整的原则很简单：书名风格越严肃越要低温度，越要脑洞越大越要往 1.2 顶。
3.3 简介生成的三段式模板：钩子、卖点、预期管理
简介比书名更重要，因为读者翻到详情页，决定下载与否就看这几十个字。工具的简介模板设计了一个三段式结构：第一段用一句话抛出悬念或冲突，第二段交代世界观和主角目标，第三段管理读者预期，暗示后续会更加精彩。
这个三段式不是拍脑袋定的，它对应的是读者决策心理：先被钩子抓住，再有足够的信息判断题材对不对味，最后建立阅读期待。工具把这三段做成了模板里的三个占位段落，每段有独立的字符上限提醒，最后拼接输出。
// 简介生成的拼接规则（前端预览用） const introTemplate = { hook: "首段不超过40字，必须包含悬念词：突然、竟然、没想到", setup: "中段交代主角处境与目标，引用世界观关键词", promise: "末段暗示冲突升级，用词偏向：绝不、势必、谁能想到" };这段代码虽然只是前端展示用的对象定义，但它把简介结构的约束可视化出来了。参数上要留意「悬念词」不是每本都适用，写甜宠文时「突然」这种词反而破坏氛围。我的习惯是先用模板生成一版，再手动把语气词替换成符合题材风格的版本，模板负责结构，人工负责语感。
4. 正文润色与风格一致性：搭一套双通道处理管线
4.1 本地规则前置处理：润色之前先自己动手
润色是最容易翻车的功能，因为大模型改写长文时经常「用力过猛」，把原本有辨识度的文字改得平淡无奇。这个工具处理得比较聪明：它不是把全文扔给大模型重写，而是先做本地规则处理，只有规则覆盖不了的部分才交给 AI。
本地规则处理包含三件事：错别字纠正、超长句切分、重复词替换。比如「他说」「她说」在一段对话里连续出现三次，规则引擎会先替换后两处；比如单句超过 60 字，规则引擎会按逗号位置切分成两句。这些操作不消耗 token，响应是毫秒级的，处理完之后的文本再送进大模型，改写压力小很多，输出质量也更稳。
import re def preprocess(text): # 超长句切分：按标点断句，避免 AI 改写时句子臃肿 text = re.sub(r"[^。！？]{60,}", lambda m: m.group(0)[:50] + "，", text) # 对话标签去重 text = re.sub(r"(“他说”)(?=.*?\1)", "他又开口", text, flags=re.MULTILINE) return text这个预处理的关键在于把「人类看着别扭但说不清哪里别扭」的地方显式标记出来。re.sub里那个 60 字的阈值你可以自己调，写严肃文学建议设置在 40 到 50 之间，因为长句在这种文体里是风格的一部分，不宜过度切分。对话标签去重用的是反向断言，只替换重复出现的「他说」，第一次出现的保留。
4.2 风格迁移与上下文裁剪：「像你写的」而不是「像 AI 写的」
改完基本的文字问题，润色的重头戏是风格一致。工具在提示词里要求大模型模仿用户提供的「风格锚文本」——也就是你自己写的三到五个自然段，让模型学习你的用词习惯和句式节奏。这比直接说「要幽默」「要犀利」靠谱得多，因为风格是无法用抽象形容词定义清楚的。
但「把锚文本放进提示词」这件事有个技术边界：上下文窗口有限，放太多锚文本会挤占正文空间，放太少又学不像。工具的解决方法是滑动窗口裁剪，只从锚文本中截取最近 800 字作为风格样本，正文分片处理每片 1500 字，前后片保留 200 字重叠用于过渡衔接。
def split_with_overlap(text, chunk_size=1500, overlap=200): chunks = [] start = 0 while start < len(text): end = min(start + chunk_size, len(text)) chunks.append(text[start:end]) if end == len(text): break start = end - overlap return chunks这段代码的关键参数在overlap，它保证上下文在切分处不断裂。我之前自己写过不用 overlap 的版本，结果润色到某一章中间时突然换了人称，就是因为切分处丢失了前文信息。后来学了乖，所有分片处理都保留重叠区，输出就稳定多了。
4.3 降 AI 味的两个实操参数：重写强度和词汇替换率
很多用这个工具的人都在关心一个话题：怎么让生成出来的文字不那么「AI 味」。工具里对应的是两个参数——rewrite_strength和replacement_rate。前者控制模型改写的幅度，取值范围 0 到 1；后者控制同义词替换的密度，比如「高兴」被替换成「雀跃」「欢喜」「乐呵」的概率。
rewrite_strength调到0.8以上时，模型的输出已经基本是重写而不是润色，句子结构和语序都会大变，适合编辑对稿件做大调整；调到0.3以下则基本保留原句，只修正语病，适合把 AI 生成的内容改得更像人话。replacement_rate我一般建议0.4左右，太高会出现用词刻意、生硬的问题。
message = instruction_template.format( text=input_text, rewrite_strength=0.5, replacement_rate=0.4, )参数之外还有更有效的降 AI 味手段：主动制造「瑕疵」。我给模型加了两个约束条件——「允许并且鼓励在对话中使用不完整句」和「每章至少插入一次环境感官描写，而非单纯推进剧情」。因为 AI 默认的输出太「工整」了，人类写作的特点是情绪起伏会扭曲句式。这两个约束本质上是给模型一个「偏离规范」的借口，效果比单纯降参数好很多。
5. 安装部署与常见问题排查：五个真实翻车现场
5.1 现象：解压 zip 之后运行python main.py直接报 ModuleNotFoundError
原因：压缩包里的requirements.txt是基于 Python 3.10 生成的，但本机默认的 Python 版本是 3.7 或 3.8，部分依赖包在新版本才提供预编译 wheel。解决：不要直接pip install -r requirements.txt，先确认 Python 版本，再创建独立虚拟环境。
python3.10 -m venv venv source venv/bin/activate pip install -r requirements.txt我犯过的错误是在全局环境里硬装，结果装到一半和系统自带的requests版本冲突，把整个环境搞坏了。从那以后任何项目我第一次运行都先建虚拟环境，这也是这份资源里 README 反复强调的步骤，千万别跳过。
5.2 现象：拆书任务跑到一半，输出开始循环重复同一句话
原因：文本切片时没有保留重叠区，模型在长文本尾部丢失了前文信息，于是进入「复读机模式」。这个坑在长短篇小说上表现不同：短篇是突然中断，长篇是后半部分人物立场莫名反转。解决：按上一章的split_with_overlap方案，强制所有分片之间保留 200 字重叠，再让每个分片独立输出分析报告，最后合并。
5.3 现象：zip 包在 Windows 下解压正常，在 Mac 下中文文件名乱码
原因：压缩包在打包时使用了 GBK 编码的文件名标记，而 macOS 的解压工具默认按 UTF-8 解码。解决：不要用系统自带的归档实用工具，改用跨平台工具重新解压或在 Linux 下用unzip -O gbk指定编码。
unzip -O GBK Shi.zip -d novel-tool如果你手头只有 Windows 和 Mac，最简单的方案是把压缩包传到云服务器上解压，再同步回来。比起在系统设置里折腾编码，这个路径更省事，而且不会留下半解压的损坏文件。
5.4 现象：双击 zip 提示需要密码，但压缩包说明里没给密码
原因：资源包打包时开启了 zip 伪加密标志，文件中央目录的记录标记为加密，但实际数据流未加密。很多下载站为了防盗链会这么干，或者打包工具误设了该标志位。解决：查看 README 或者资源说明里是否有附带密码；没有的话，可以用 7-Zip 打开后尝试直接解压，伪加密文件通常能直接解出来。不要随便去找所谓的破解工具，那些大多捆绑了风险程序，直接卸载即可。
5.5 现象：本地 Ollama 模式下生成特别慢，几秒钟才出一个字
原因：本地模型跑在 CPU 上而不是 GPU，尤其是模型参数量超过 7B 之后，推理延迟非常夸张。解决：第一步确认有没有可用的 NVIDIA 显卡，有的话检查驱动和 CUDA 是否被 Ollama 识别；没有 GPU 就换小模型，比如qwen2:1.5b，或者直接把api_type切回云端，用 API 模式。
ollama list ollama run qwen2:1.5b我自己的经验是 7B 模型在 M 系列芯片上最高跑到每秒 20 token，而 1.5B 能到 60 token。日更能达到 3000 字的人要权衡时间成本，本地模型适合做提示词调试，正式批量生成还是得交给云端。
6. 提示词回归测试：让每一次改动都能追责
提示词写多了之后会有一个困惑：这版提示词和上一版到底哪个更好？光靠「感觉」判断不可靠，因为大模型输出有随机性，今天觉得 A 好，明天换了个模型版本可能又觉得 B 好。我给这套工具补了一个简单但有效的验证流程——提示词回归测试，核心思想是把提示词当作代码来管，每次改动前先锁基准。
具体做法是准备一个包含 20 组测试输入的固定样本集，覆盖不同类型的题材和风格要求。每次修改提示词后，跑一遍样本集，记录输出结果的命中率和风格偏移度。命中率指输出是否符合格式要求；风格偏移度则是我自己写的一段 Python 脚本，比较新输出与基准输出的句子长度标准差和词汇分布差异。这两个指标一量化，提示词的优劣就不靠运气了。
最后一个我从失败里学到的习惯：每次改提示词之前，先复制一份到prompts/backup/目录并带上日期后缀。有一次我把「主角视角」相关的约束重写了一遍，结果整章生成出来变成了第二人称叙述，当时没有备份，找了半天才从编辑记录里翻到旧版本重跑。从那以后我每次改提示词都强制走一遍「备份、测试、对比、上线」四步流程，再没出过类似事故。这个习惯我希望你也能用上，希望帮到你。
本文还有配套的精品资源，点击获取
