简介这是一款基于人工智能与提示词技术的小说创作辅助工具可应用于智能拆书、书名与简介生成、正文润色、错别字修正等写作场景面向职业作家、写作爱好者以及希望研究AI写作技术的开发者帮助用户显著提升创作效率。资源包共52个文件包含17个Python脚本、13个JavaScript文件、10张PNG截图、TXT/MD说明文档及HTML页面等整体压缩包约3.48MB结构清晰便于本地运行与二次开发。目前已有52人学习下载。通过它可了解ChatGPT、Claude、Gemini、文心一言等多模型接入的具体实现掌握提示词管理、小说框架生成、内容拆分等完整流程附带的教程文档、思维导图和附赠资源还能进一步辅助学习适合作为AI写作工具研发或小说创作效率提升的参考。1. AI小说创作助手解决的不只是“让AI替你写”如果你写过网文一定经历过这种晚上第一章三千字改了三遍人物动机拧成麻花新建文档比写正文还多。这时候你打开一个对话框说“帮我写”模型确实能吐两千字但读起来像材料汇编主角说话像客服。AI小说创作助手这类工具本质是把“用AI写小说”从碰运气变成流水线基于大模型做生成靠提示词管理把风格、设定、输出格式固定下来再通过智能拆书、书名简介生成、正文润色这些具体功能把“灵感→初稿→可发布”的链条压缩到几分钟。适合兼职作者、想快速验证脑洞的新手以及要给编辑交样章的老写手。这篇笔记就按实际用的顺序把原理、参数和坑一次讲完。2. 大模型与提示词工程AI小说创作助手的地基2.1 为什么小说生成必须走提示词工程而不是开个对话框就写很多第一次用这类工具的人会问大模型对话能力已经很强为什么还要多做一层提示词管理你把一个问题丢进对话框模型能答但小说不是一次问答是几十万字的长程生成。直接对话的问题出在“语境漂移”上。你让模型接着上一段写它会越写越顺滑但主角的口吻开始像解说员环境描写开始堆成语三章之后人物关系甚至可能对不上。这不是模型变笨了而是对话式交互没有把“作者意图”固化成约束。提示词工程要做的就是把“我想要一部什么样的作品”翻译成模型能稳定遵循的指令结构。具体到小说场景提示词工程至少要管住四件事风格锚点是冷峻还是话痨、角色设定每个角色的语气和禁忌、结构指令这段是铺垫还是高潮、输出格式对话、旁白、心理描写的排版。这四样在对话框里靠复制粘贴撑不过三章在提示词管理里则是结构化字段每次生成都原样注入。顺便说一句这类AI小说创作助手背后一般接的是通用对话大模型或专门微调过的写作模型但不管接谁提示词工程都是决定成品像不像“人写的”的关键。模型是引擎提示词才是方向盘。2.2 选型通用大模型、写作专用模型与本地部署怎么选这个工具到底该接哪种大模型直接决定生成质量、成本和你能不能跑起来。别一上来就追最强模型先看你的写作场景吃哪头。维度通用对话大模型写作辅助模型开源本地部署模型中文语感稳定偏稳健好网文风格明显看微调程度上下文长度中等偏上长适合长章节受显存限制风格可控性靠提示词强约束本身带文风偏置可微调门槛高隐私数据出本地数据出本地全本地成本按token计费通常更便宜一次算力成本适合人群想快速验证的人写网文/小说的人对数据敏感或要离线的人我一般建议纯网文作者先试写作辅助模型它天生带“爽点”和“对话流”的偏置润色时少操一半心。如果你要处理长篇几十万字的小说通用大模型的上下文窗口和价格会是瓶颈别等到账单吓人才换。本地部署适合的是团队或对数据敏感的人个人作者折腾显卡不太值。选型时记住一个下限模型的中文语感不能弱生成结果不要有明显的“翻译腔”。这类问题没法靠提示词补救属于模型本身的底子。2.3 一个最小可跑的提示词模板系统指令、风格锚点与输出约束在实际搭AI小说创作助手时我会把提示词拆成三块系统指令、风格锚点、输出格式。下面这个JSON模板是润色功能的最小骨架你复制下来就能当起点。{ system: 你是一位资深网文编辑擅长商业类型小说。你的任务是修改用户提供的章节保留原有情节和人物行为逻辑只优化表达。, style_anchor: { 叙述视角: 第三人称限知不写主角视角之外的内心活动, 句式偏好: 短句为主对话不追求书面语要有口语节奏, 禁用表达: [窗外, 与此同时, 不禁, 微微一笑], 节奏要求: 段落间要有动作、有停顿不要连续三句话都在描述环境 }, output_format: { 返回内容: 只返回润色后的正文不要返回任何分析或解释, 章节长度: 与原章长度接近浮动不超过10%, 对话格式: 对话独立成行使用破折号引出 } }这段模板的关键在于把“文风”从玄学变成字段。你不需要写“请写得好看一点”而是用“禁用表达”和“句式偏好”这类可执行的约束让模型知道边界在哪里。调用时把这段JSON作为system_prompt注入把待润色的章节内容作为user_prompt传入。Python侧的最小代码长这样import json import requests def run_llm(system_prompt, user_prompt, api_key, temperature0.7): url https://api.example.com/v1/chat/completions # 替换为你的服务商地址 headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: writing-model, # 按实际可用模型名替换 messages: [ {role: system, content: json.dumps(system_prompt, ensure_asciiFalse)}, {role: user, content: user_prompt} ], temperature: temperature, max_tokens: 1800 } resp requests.post(url, headersheaders, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content]这里有两个参数直接影响生成质量。temperature控制随机性润色场景我一般设在0.7到0.8之间太低会机械重复太高会放飞叙事。max_tokens按章节长度给单章3000字对应的生成量建议设到1800左右宁可多调一次不要让它在章节中间截断。3. 提示词管理把散落的灵感变成可复用的资产3.1 提示词管理解决的三个痛点散落、漂移、难复用AI小说创作助手里“配备完善的提示词管理功能”这句话实际使用中对应三个非常具体的痛点。第一是散落。你昨天写好的角色设定提示词贴在备忘录里今天用的润色模板在另一个文件里明天想给新书生成简介又得重新写。提示词管理把所有的提示词集中到一个库里按类型组织随取随用。第二是漂移。同一个角色你第一次描写用“冷峻寡言”第二次提示词里写“说话带刺”模型就会把角色写成两个人。提示词管理里的角色模板是统一入口所有章节生成都从这里注入就不会出现人格分裂。第三是难复用。拆书模板敲了一遍换一本书又要重写。成熟的做法是把提示词做成带变量的模板只替换小说名和设定结构不变。这本质上是在建你自己的提示词资产库写书越多资产越厚。3.2 结构化存储与变量注入作者视角、主角设定、场景状态分开存提示词管理功能落地时最忌讳把所有内容塞进一个大文本里。我习惯在本地保持这样一套目录结构prompts/ ├── roles/ # 角色设定模板 │ ├── 主角.json │ └── 配角.json ├── scenes/ # 场景提示词 │ ├── 打斗.json │ ├── 谈判.json │ └── 感情戏.json ├── styles/ # 风格锚点库 │ ├── 都市冷硬.json │ └── 古风言情.json ├── pipelines/ # 组合式工作流 │ ├── 拆书.json │ ├── 书名生成.json │ └── 润色.json └── variables/ # 每本书的变量值 └── 当前作品.json这样做的好处是风格锚点管“文风”角色模板管“人设”场景提示词管“桥段”互不污染。生成时通过变量注入把三块拼成一次调用的完整提示词。下面是加载模板并注入变量的示例import json from copy import deepcopy def load_and_fill(template_name, variables, prompts_dirprompts): with open(f{prompts_dir}/pipelines/{template_name}.json, encodingutf-8) as f: template json.load(f) filled deepcopy(template) # 将变量注入到模板里的 {占位符} for key, value in variables.items(): placeholder { key } # 递归替换所有字符串里的占位符 walk_and_replace(filled, placeholder, value) return filled def walk_and_replace(obj, placeholder, value): if isinstance(obj, dict): for k, v in obj.items(): if isinstance(v, str) and placeholder in v: obj[k] v.replace(placeholder, value) else: walk_and_replace(v, placeholder, value) elif isinstance(obj, list): for i, v in enumerate(obj): if isinstance(v, str) and placeholder in v: obj[i] v.replace(placeholder, value) else: walk_and_replace(v, placeholder, value) # 使用示例 variables { 主角名: 陈默, 主角性格: 沉默寡言观察力极强, 当前场景: 废弃工厂谈判 } pipeline load_and_fill(润色, variables) user_prompt 请按模板处理以下章节\n chapter_text参数说明模板文件名对应pipelines目录下的JSONvariables提供本次作品的主角名、性格、场景状态。deepcopy是为了防止反复注入时污染原始模板文件这是多人协作时最容易踩的坑。占位符统一用{主角名}这种大括号格式和JSON语法兼容替换逻辑也简单。3.3 标签体系与版本管理几百条提示词之后靠什么找提示词库一旦超过一百条就得靠标签而不是靠记忆。我不建议建复杂的分类树扁平标签加多属性检索更实用。每个提示词打三个维度标签维度取值示例作用功能类型拆书、润色、取名、扩写决定在哪条流程里出现题材/风格都市、古风、悬疑、爽文决定配哪本文使用语料来源网文、出版小说、知乎体决定文风边界比如你要给一本“都市悬疑”书润色搜索条件就是润色 都市 悬疑命中一个模板组合再替换变量即可。这套逻辑不需要开发成复杂系统一个JSON文件加几行Python过滤就够。版本管理这块很多人忽略。提示词模板改了一版效果反而变差想回滚却找不回旧版。我用的是最土的办法每个模板文件头部保留version字段改动前复制一份带日期的备份。脚本生成时先读version写到日志里这样哪个章节用哪个版本的提示词事后可查。不要小看这一步长篇写作中风格前后不一致多半就是版本乱了。4. 智能拆书与书名简介生成从结构里找灵感4.1 智能拆书拆的是什么结构、节奏与人物关系智能拆书这个功能说白了就是让大模型当你的“读稿编辑”把一本完本小说拆成可复用的结构数据。它的输入是一整本小说的文本输出是一份结构报告通常包括主要人物关系网、剧情主线拆段、高潮节点的位置与触发条件、每卷的节奏曲线、伏笔与回收的对应关系。拆书的目的不是“分析名著”而是让你看到“别人是怎么把故事撑起来的”。比如你卡在中期情节疲软拆一本同类型完本看看它在第40章到第60章之间安排了什么事件密度如何就能照猫画虎地给你的作品补上节奏。拆书的质量取决于两个东西模型的上下文能力和提示词里对“结构”的定义。如果提示词只写“分析这本书的结构”模型会给你一堆正确的废话。必须明确要求输出“人物关系表”“高潮节点清单”“每万字事件密度”这类可读的结构字段。4.2 分卷拆书代码示例与三个影响结果的参数长篇小说不可能一次性塞进模型常见做法是分卷拆书按章节切段分批调用模型最后合并成一份完整报告。下面是我常用的切分思路def split_chapters(text, min_chars3000, overlap_chars200): 将整本小说切成适合模型处理的分段。 min_chars: 单段目标长度按模型上下文窗口打折后设定 overlap_chars: 相邻段重叠字数防止章节边界信息丢失 paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) min_chars: current \n\n para else: chunks.append(current) current para # 边界重叠取上一段末尾若干字符粘到下一段开头 result [] for i, chunk in enumerate(chunks): if i 0: result.append(chunk) else: overlap chunks[i-1][-overlap_chars:] result.append(overlap \n\n chunk) return result调用拆书模型时我一般把temperature设到0.3以下。拆书是结构化任务不需要创意的随机性温度高了会编造书中不存在的情节。另外两个参数是max_tokens和top_p。拆书输出的结构报告尽量一次生成完整max_tokens给足top_p保持默认0.9即可这个参数在拆书场景影响不大真正影响质量的是分段长度。分段长度上单段不要超过模型上下文窗口的三分之一。因为拆书报告本身也要占输出长度输入占太多输出的结构字段会被截断。我用3000字作为默认分段超过5000字的时候后半段的拆书结果开始出现“只概括不分析”的偷懒现象。4.3 从拆书报告生成书名与简介约束条件与示例模板拆完结构后书名和简介的生成就有据可依了。智能生成书名不是让模型瞎编几个词而是从拆书报告里抽取核心卖点再按类型规则组合。书名生成的提示词模板里我会强制两类约束一是题材必须出现在书名里或给人明确类型预期二是字数限制在8到14字之间太短没信息量太长不像网文。简介的约束更细一般控制在150到250字要求第一句抛悬念、第二段交代设定、最后一句给期待感。麻烦的是模型更容易把简介写成产品说明书。解决方法是把拆书报告里的“高潮节点”直接作为素材注入简介模板让模型把最刺激的情节点改写成悬念句。下面这个JSON是简介生成的最小模板{ system: 你是一位图书编辑擅长写商业小说简介。只输出简介正文不输出分析。, inputs: { 类型: 都市异能, 核心卖点: 主角能看见他人死亡倒计时但不能说出来否则规则反噬, 开篇悬念: 主角在电梯里看见整栋楼的人倒计时都是5分钟, 字数范围: 160到220字, 语气要求: 冷峻、克制不用感叹号 } }注意语气要求里明确写了“不用感叹号”这是针对模型总想煽情的对症下药。简介这东西感叹号越多越掉档次。如果你遇到的模型屡教不改就把这个限制写进system层而不是inputs层system层的指令优先级更高。5. 全流程常见问题排查润色参数、zip解压与上下文超限5.1 两种润色模式整章重写与逐段打磨正文润色是这个工具里使用频率最高的功能但很多人一上来就用错模式。润色至少有两种整章重写和逐段打磨适用场景完全不同。整章重写适合“情节对但表达全垮”的章节。模型拿到整章按风格锚点重写一遍效率最高但风险是模型会顺手改掉你的情节细节。逐段打磨适合“大部分能看个别句子刺眼”的情况改得少保留原味但耗时长、调用次数多。模式输入粒度优点风险适合场景整章重写整章3000字风格统一情节细节被改草稿初写完逐段打磨每段500字改动最小风格可能不连贯修改已发布章节对话精修仅对话行保住口吻上下文不足角色OOC严重时我自己的习惯是新章节先整章重写再对主角的对话单独精修一次。这两个步骤拆开来比一次调用让模型“既改表达又管对白”稳定得多。5.2 润色调用示例与四个必调采样参数小说润色不是把prompt写好就完事模型推理参数才是真正决定“像不像人写的”的那只手。下面是润色调用的核心代码def polish_chapter(chapter_text, style_anchor_text, api_key): system_prompt f 你是一名资深网文编辑。请按以下风格要求润色给定章节 保留原情节、人物行为与对话内容只优化表达。 风格要求{style_anchor_text} 只输出润色后的正文。 payload { model: writing-model, messages: [ {role: system, content: system_prompt}, {role: user, content: chapter_text} ], temperature: 0.75, top_p: 0.9, presence_penalty: 0.5, frequency_penalty: 0.3, max_tokens: 1800 } # 调用逻辑与前文相同省略 return run_llm(payload)这里的presence_penalty和frequency_penalty是润色场景最容易忽略的两个参数。很多人遇到“AI味”的第一反应是换大模型其实先调这两个参数更实际。参数推荐范围作用调错的表现temperature0.7-0.8整体随机性太低像复读机太高开始乱编top_p0.85-0.95候选词截断配合temperature调单独动它效果不明显presence_penalty0.3-0.6惩罚重复话题太高会让句子变得刻意跳跃frequency_penalty0.2-0.5惩罚高频词重复太高会出现生硬换词如果润色出来的文本满篇“然而”“不禁”“仿佛”把frequency_penalty往上加到0.5同时把“不禁”“仿佛”写进风格锚点的禁用表达里。这比单纯调参好用因为是根据你的具体文本定制的。5.3 排障一Shi.zip解压乱码、路径异常导致模型加载失败现象拿到AI小说创作助手的压缩包Shi.zip解压后运行脚本日志报错提示找不到模型文件或配置文件路径为空。原因这个工具包是多层目录结构压缩包里的中文文件名在Windows默认解压工具下容易出现乱码或者被安全软件拦了部分文件。最常见的是解压工具把嵌套目录压平了脚本里relative_path找不到目标。解决用7-Zip按原始路径解压不要用系统自带的“全部解压”。解压后检查第一层目录下是否有app.py或main.py这类入口文件如果没有说明解压时目录层级丢了。重新解压一次并确认路径中没有空格和特殊符号。再把脚本里所有读取路径改成相对路径而不是绝对路径换一台电脑也不至于翻车。这个坑看起来低级但在下载类工具包里是最常见的第一道门槛。先排除它再谈功能。5.4 排障二拆书后半段格式崩塌、输出越来越像流水账现象同一本书前半部分的拆书报告有结构、有事件密度分析后半部分开始退化成“第几章到第几章讲了什么事”的流水账人物关系也丢失了。原因模型上下文超限。长文本拆书时前面的分析结果累积到上下文中后面的输入挤占了输出空间模型就开始偷懒只做摘要不做分析。另外分段太长也会让每段的信息密度下降模型分不清主次只好平均用力。解决把拆书分段从3000字下调到2000字同时给每段拆书任务增加一个“本节重点”参数明确告诉模型这一段重点看什么。比如循环时轮流指定“关注人物关系变化”“关注冲突升级”“关注伏笔”。不要把整本书一次拆完拆完一卷就把报告存下来清空上下文再拆下一卷。这一步是“后悔药”式的调整不用推翻重来但能明显改善后半段质量。5.5 排障三润色后“AI味”太重、角色口吻千篇一律现象润色过的章节读起来通顺但主角、反派、配角的对话全部一个腔调且频繁出现“然而”“在这时”之类的连接词。原因采样参数和风格锚点都没到位。对话口吻千篇一律往往是temperature太低模型倾向于生成“最安全”的表达连接词高频重复则是frequency_penalty没起作用。另外你会把角色的说话习惯写进风格锚点吗如果没写模型只会按默认的“普通话书面语”生成所有角色当然一个样。解决把temperature回到0.75frequency_penalty调到0.4以上。然后在风格锚点里为每个主要角色单独加一条“对话特征”例如主角“说话短、少用成语”反派“爱用反问句”。润色时把当前章节出现的角色名单及其对话特征注入到system里。做完这三步AI味至少能感觉消失一大半。不用迷信那些降AI率工具把参数和锚点调正才是根本。6. 一套标准验收流程用一个800字章节检验整条流水线功能都能跑通之后还要确认“跑出来的东西能不能用”。我的一套折腾下来的验收流程固定用一个800字章节做试金石所以不是每次都要拿全书去测。这个800字章节我会故意写成带三种缺陷的样本一段对白干瘪、一段环境描写堆砌、一处情节亮点被淹没。然后依次跑一遍拆书、书名简介生成、正文润色看三件事。第一润色后是否还保留原章节里的情节动作。模型最擅长把“他推开门”改成“他推开那扇沉重的铁门”但这种扩写未必更好。验收时对比改写前后动作是否丢失。第二对话是否有辨识度。把润色后所有角色的对白单独拉出来遮住人名如果你分不清谁在说话说明角色锚点没生效这条路子不能用于全文。第三AI味检查点。数一下润色后的文本里“然而”“与此同时”“仿佛”“不禁”这四类词的出现频率如果每千字超过两次就回到5.5的调参步骤。我的验收习惯是新写的章节先用这套流程过一遍达标了才发出去不达标的直接回退上一版提示词重新调参。宁可多花十分钟跑验收不要等写到三十章发现风格已经在第八章就崩了。这套流程在几本书上折腾了大半年是踩坑踩出来的血泪经验希望帮到你。本文还有配套的精品资源点击获取