简介：AI小说创作助手是一套面向小说作者与写作爱好者的智能创作生产力工具，基于人工智能与提示词技术，帮助解决灵感枯竭、框架搭建困难、文本润色耗时等痛点，适合从入门写手到职业作者的多层级用户。资源包共52个文件，约3.48MB，以Python脚本与JavaScript模块为主，辅以PNG界面截图、Markdown教程文档、HTML页面及配置说明，涵盖多模型接入脚本、提示词编辑器、拆书与思维导图模块、小说编辑器教程等，结构清晰便于二次开发与功能扩展。目前已有52人学习下载。通过该资源，读者可获取智能拆书、书名与简介生成、正文润色、错别字修正等完整功能实现思路，并参考多平台大模型接入脚本与提示词优化文档，快速搭建属于自己的AI写作工作流，提升创作效率与作品质量。
1. 从一份 Shi.zip 说起：AI 小说创作助手到底能替你做哪几步
如果你写过网文，大概经历过这种循环：想书名想到凌晨两点，简介改了七版还是不满意，正文写到第三章发现节奏塌了，回头拆别人的爆款又拆不出结构。AI 小说创作助手就是冲着这几个环节来的——它把「智能拆书、生成书名与简介、正文润色」这几件事打包成一个本地工具，核心驱动是提示词技术，而不是某个云端黑盒。你拿到手的 Shi.zip 解压后是一套可运行的创作工作台，提示词管理是它的骨架：拆书用一套模板，起名用一套模板，润色又是另一套，彼此独立又能串起来用。适合谁？日更压力大的网文作者、想批量产出短篇的运营、以及需要把提示词工程落到具体写作场景的 AI 应用开发者。它不替你写完整本书，但能把「从灵感到可发布章节」之间的机械劳动压掉一大半。
2. 拆开 Shi.zip：目录结构、提示词管理与运行环境
2.1 解压后先看什么：目录骨架与文件职责
拿到 Shi.zip 别急着双击运行，先解压到一个纯英文路径下——中文路径在部分 Python 依赖加载时会出编码问题，这是血泪经验。解压后典型结构大致是这样（不同打包版本文件名可能略有出入，以实际为准）：
ai-novel-assistant/ ├── main.py # 入口，启动交互界面或命令行 ├── config/ │ ├── settings.json # 模型接口、温度、最大 token 等全局配置 │ └── prompts/ # 提示词模板目录，核心资产 │ ├── dismantle.txt # 拆书模板 │ ├── title.txt # 书名生成模板 │ ├── intro.txt # 简介生成模板 │ └── polish.txt # 润色模板 ├── core/ │ ├── llm_client.py # 模型调用封装 │ ├── prompt_manager.py # 提示词加载、变量替换、版本切换 │ └── novel_parser.py # 拆书时的文本分章、结构提取 ├── data/ │ └── samples/ # 示例文本，用来跑通流程 └── requirements.txt # 依赖清单config/prompts/是整个工具最值钱的地方。它把「拆书」「起名」「简介」「润色」拆成独立模板文件，每个文件里用占位符标记变量，比如{chapter_text}、{style}、{word_count}。prompt_manager.py负责读模板、替换变量、拼最终请求。你改提示词不用动代码，改 txt 就行——这一点对非程序员作者非常友好。
2.2 运行环境与依赖安装
工具基于 Python，常见做法是建虚拟环境再装依赖，避免污染系统包。步骤如下：
# 进入解压后的目录 cd ai-novel-assistant # 创建虚拟环境（Python 3.9 以上） python -m venv venv # 激活：Windows venv\Scripts\activate # 激活：macOS / Linux source venv/bin/activate # 安装依赖 pip install -r requirements.txtrequirements.txt里通常包含requests、jieba（中文分词，拆书时用）、rich（终端美化输出）等。如果安装卡在某个包上，先升级 pip：pip install --upgrade pip。装完后别急着跑main.py，先确认config/settings.json里的模型接口配置。
2.3 settings.json 里必须改的三个参数
打开config/settings.json，你会看到类似结构：
{ "api_base": "https://your-endpoint/v1", "api_key": "sk-xxxxxxxx", "model": "your-model-name", "temperature": 0.8, "max_tokens": 2048, "top_p": 0.9 }api_base和api_key填你自己可用的模型服务地址与密钥，model填对应模型名。这三个不改，后面所有功能都跑不起来。temperature控制创造性：拆书建议 0.3～0.5，要的是稳定提取结构；起书名和简介可以 0.8～1.0，要的是发散。max_tokens决定单次输出长度，润色长章节时如果发现输出被截断，就把它调到 4096 或更高。top_p一般保持 0.9 不动，除非你明确知道自己在调什么。
提示：改完 settings.json 后先跑一次
python main.py --test（如果打包版本带这个参数），确认模型能通再进入正式创作，否则后面报错你分不清是提示词问题还是接口问题。
3. 智能拆书实战：把一本爆款拆成可复用的结构模板
3.1 拆书模板里到底在拆什么
拆书不是让 AI 写读后感，而是提取可迁移的结构。dismantle.txt模板通常要求模型输出几个固定维度：章节节奏（每章推进了什么）、冲突类型（人际/环境/内心）、钩子位置（章末悬念在第几段）、人物出场密度。这些维度是网文写作里真正能复用的东西。模板里一般有类似这样的指令：
请对以下章节文本进行结构拆解，输出 JSON 格式： { "chapter_index": 章节序号, "main_event": "本章核心事件，一句话", "conflict_type": "冲突类型", "hook_position": "钩子出现在全文百分比位置", "hook_text": "钩子原文摘录", "pacing": "节奏评价：快/中/慢" } 文本：{chapter_text}{chapter_text}是变量，由novel_parser.py按章节切好后注入。chapter_index让你后续能按顺序拼出整本书的节奏曲线。hook_position用百分比而不是绝对段号，是为了跨章节对比——爆款书的钩子往往集中在 85%～95% 位置，如果你拆出来发现自己的书钩子在 60% 就泄了，那就是节奏问题。
3.2 跑一次完整拆书的命令与参数
假设你把要拆的小说存成了data/samples/novel.txt，按章用空行或「第X章」分隔。运行：
python main.py --mode dismantle --input data/samples/novel.txt --output data/output/dismantle_result.json --batch-size 3--mode dismantle指定走拆书流程。--input是源文本路径。--output是结果落盘位置，建议单独建 output 目录。--batch-size 3表示每次送 3 章给模型，太大容易超 token 限制，太小则调用次数多、慢。拆书结果是一个 JSON 数组，每章一个对象。拿到结果后你可以用 pandas 快速看节奏分布：
import json import pandas as pd with open("data/output/dismantle_result.json", "r", encoding="utf-8") as f: data = json.load(f) df = pd.DataFrame(data) # 看钩子位置分布 print(df["hook_position"].describe()) # 看冲突类型占比 print(df["conflict_type"].value_counts())describe()给你钩子位置的均值、四分位数，均值在 0.85 以上说明这本书钩子压得靠后、留人能力强。value_counts()看冲突类型是否单一——如果一本 100 万字的书 90% 都是人际冲突，那它的冲突设计其实很集中，这是可以学的策略。
3.3 拆书结果怎么反哺自己的写作
拆完不是看完就完了。把dismantle_result.json里的main_event列单独抽出来，按顺序读一遍，你得到的是这本书的「事件骨架」。然后拿你自己的大纲对照：你的事件密度是每章一个还是每三章一个？爆款书通常每章至少一个明确事件，哪怕是小事件。另一个用法是把hook_text全部导出，做成一个钩子素材库，写到自己章末卡住时翻一翻，找同类情境的钩子写法。注意，拆书结果只做参考，不要直接套用具体情节，套了就是洗稿，这里说的是结构层面的借鉴。
4. 书名、简介与正文润色：提示词模板怎么改才不翻车
4.1 书名生成：从关键词到候选列表
title.txt模板一般要求输入题材、核心设定、目标读者，输出 10 个候选书名。模板里常见的变量是{genre}、{core_setting}、{target_reader}。调用方式：
python main.py --mode title --genre "都市异能" --setting "主角能听见物品的记忆" --reader "男频，18-30岁" --count 10--count 10控制候选数量。生成结果会直接打印在终端，同时存一份到data/output/titles.txt。这里有个参数值得注意：模板里通常有一个style_hint变量，默认可能是「简洁有力」，你可以改成「悬念感强」或「口语化」，出来的书名风格差别很大。我一般会跑三轮：第一轮默认，第二轮改成「悬念感强」，第三轮改成「两个字以内」，然后从 30 个里挑。别指望一次出爆款名，书名是筛出来的不是生成出来的。
4.2 简介生成：控制信息密度和钩子位置
简介模板intro.txt的关键变量是{title}、{protagonist}、{core_conflict}、{word_limit}。word_limit一般设 150～200 字，这是多数平台简介的舒适区。模板里会要求模型把最强钩子放在前 30 字内，因为读者在列表页只扫一眼。跑法：
python main.py --mode intro --title "听见记忆的人" --protagonist "能读取物品记忆的旧货店老板" --conflict "被卷入一桩二十年前的悬案" --limit 180生成后别直接复制。检查两点：前 30 字有没有具体画面（「旧货店老板摸到一枚戒指，听见了哭声」比「主角拥有特殊能力」强十倍）；结尾有没有留一个未解问题。如果模板默认输出偏平，就在intro.txt里加一句指令：「前 30 字必须包含一个具体动作或感官细节，结尾必须是一个未回答的问题。」
4.3 正文润色：温度、分段与「不要改剧情」
润色模板polish.txt最容易翻车。很多人把整章丢进去让 AI「润色」，结果 AI 把剧情也改了。正确做法是在模板里明确约束：
请对以下文本进行润色，要求： 1. 不改变任何情节、人物动作和对话内容 2. 只优化：用词重复、句式单调、过渡生硬 3. 保持原有段落划分 4. 输出仅包含润色后正文，不要解释 文本：{chapter_text}调用时temperature要调低，0.3 左右，太高会「自由发挥」。命令：
python main.py --mode polish --input data/samples/chapter_01.txt --output data/output/chapter_01_polished.txt --temperature 0.3润色后一定要 diff 对比原文，看有没有被悄悄改掉的情节。常见翻车是 AI 把「他推开门」改成「他缓缓推开门」——加了一个副词，节奏就慢了。如果发现这类改动频繁，在模板里再加一条：「不添加原文没有的副词和形容词。」
5. 避坑与排查：拆书、起名、润色里最容易翻车的五件事
5.1 拆书输出不是 JSON，而是一段散文
现象：跑完拆书，dismantle_result.json打开是自然语言段落，程序解析报错。原因：模型没有严格按 JSON 格式输出，尤其在temperature偏高或模板指令不够强硬时。解决：在dismantle.txt开头加「你必须只输出 JSON，不要任何解释文字」，并把temperature降到 0.3；如果还不行，在llm_client.py里加一层正则提取，把第一个{到最后一个}之间的内容截出来再解析。
5.2 书名生成全是「XX之XX」的模板感
现象：10 个候选里 8 个是「XX之XX」「XX纪元」「XX觉醒」。原因：模板里缺少风格约束，模型退回到训练数据里最高频的网文命名模式。解决：在title.txt里加负面指令「禁止使用『之』『纪元』『觉醒』『重生』等词」，并加一个style_hint变量，每次跑换一种风格提示。另外把temperature提到 0.9～1.0，给模型更多发散空间。
5.3 润色后字数暴涨或暴跌
现象：原文 2000 字，润色后变成 2800 字或 1500 字。原因：max_tokens设得太小导致截断，或者模型在「润色」时自行扩写/缩写。解决：先确认max_tokens大于原文 token 数的 1.5 倍；然后在模板里加「输出字数与原文误差不超过 10%」。如果还是暴涨，检查是不是把temperature设太高了。
5.4 拆书时章节切分错乱
现象：novel_parser.py把两章合并成一章，或者把一章切成三段。原因：源文本的章节分隔符不统一，有的用「第X章」，有的用空行，有的用「Chapter X」。解决：先手动统一源文本的分隔符，全部改成「第X章 」开头，章与章之间空一行。如果书很长，写个简单脚本批量替换：
import re with open("data/samples/novel_raw.txt", "r", encoding="utf-8") as f: text = f.read() # 把各种章节标记统一成「第X章 」 text = re.sub(r"Chapter\s*(\d+)", r"第\1章 ", text) text = re.sub(r"第(\d+)节", r"第\1章 ", text) with open("data/samples/novel.txt", "w", encoding="utf-8") as f: f.write(text)5.5 模型接口超时或返回空
现象：跑批量拆书时，中间某几章返回空，或者直接超时。原因：单次请求 token 太多、网络抖动、或接口限流。解决：把--batch-size从 3 降到 1，在llm_client.py里加超时重试（常见做法是重试 3 次，每次间隔 2 秒）。如果接口本身有限流，在批量任务里加time.sleep(1)控制请求频率。
6. 进阶：把提示词模板版本化，做自己的创作流水线
拆书、起名、简介、润色跑通之后，真正拉开差距的是提示词模板的迭代管理。我一般会在config/prompts/下再建一层版本目录，比如prompts/v1/、prompts/v2/，每次改模板前先复制一份旧版。这样当你发现某次改动后书名质量下降，可以立刻回滚。prompt_manager.py里通常有一个prompt_version配置项，指向当前使用的版本目录，改一行就能切换。
更进一步，把四个环节串成一条流水线：拆书结果里的main_event和hook_text可以作为起名和简介的输入变量。比如你拆完一本爆款，提取出它的核心冲突类型，然后把这个类型作为{core_conflict}传给简介模板，生成的简介会天然带有那本书的结构基因。这不是抄袭，是把结构分析的结果喂给生成环节，让 AI 的输出有参照系。
验证模板改动是否有效，别凭感觉。每次改完模板，用同一组输入跑 5 次，把输出存下来对比。书名看候选里「能用的」比例，简介看前 30 字有没有画面，润色看 diff 里情节改动条数。我自己的习惯是：任何模板改动，至少跑 5 组输入、每组 3 次，确认稳定后才替换线上版本。从那以后我每次改polish.txt都强制走一遍 diff 检查，再也没出现过润色把剧情改跑的事。希望帮到你。
本文还有配套的精品资源，点击获取