简介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/放提示词 JSONsrc/放核心 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(encodingutf-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: fBearer {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轻松)}], temperaturerandom.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, flagsre.MULTILINE) return text这个预处理的关键在于把「人类看着别扭但说不清哪里别扭」的地方显式标记出来。re.sub里那个 60 字的阈值你可以自己调写严肃文学建议设置在 40 到 50 之间因为长句在这种文体里是风格的一部分不宜过度切分。对话标签去重用的是反向断言只替换重复出现的「他说」第一次出现的保留。4.2 风格迁移与上下文裁剪「像你写的」而不是「像 AI 写的」改完基本的文字问题润色的重头戏是风格一致。工具在提示词里要求大模型模仿用户提供的「风格锚文本」——也就是你自己写的三到五个自然段让模型学习你的用词习惯和句式节奏。这比直接说「要幽默」「要犀利」靠谱得多因为风格是无法用抽象形容词定义清楚的。但「把锚文本放进提示词」这件事有个技术边界上下文窗口有限放太多锚文本会挤占正文空间放太少又学不像。工具的解决方法是滑动窗口裁剪只从锚文本中截取最近 800 字作为风格样本正文分片处理每片 1500 字前后片保留 200 字重叠用于过渡衔接。def split_with_overlap(text, chunk_size1500, overlap200): 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( textinput_text, rewrite_strength0.5, replacement_rate0.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/目录并带上日期后缀。有一次我把「主角视角」相关的约束重写了一遍结果整章生成出来变成了第二人称叙述当时没有备份找了半天才从编辑记录里翻到旧版本重跑。从那以后我每次改提示词都强制走一遍「备份、测试、对比、上线」四步流程再没出过类似事故。这个习惯我希望你也能用上希望帮到你。本文还有配套的精品资源点击获取 AI小说创作助手：提示词工程驱动的写作效率提升方案
简介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/放提示词 JSONsrc/放核心 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(encodingutf-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: fBearer {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轻松)}], temperaturerandom.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, flagsre.MULTILINE) return text这个预处理的关键在于把「人类看着别扭但说不清哪里别扭」的地方显式标记出来。re.sub里那个 60 字的阈值你可以自己调写严肃文学建议设置在 40 到 50 之间因为长句在这种文体里是风格的一部分不宜过度切分。对话标签去重用的是反向断言只替换重复出现的「他说」第一次出现的保留。4.2 风格迁移与上下文裁剪「像你写的」而不是「像 AI 写的」改完基本的文字问题润色的重头戏是风格一致。工具在提示词里要求大模型模仿用户提供的「风格锚文本」——也就是你自己写的三到五个自然段让模型学习你的用词习惯和句式节奏。这比直接说「要幽默」「要犀利」靠谱得多因为风格是无法用抽象形容词定义清楚的。但「把锚文本放进提示词」这件事有个技术边界上下文窗口有限放太多锚文本会挤占正文空间放太少又学不像。工具的解决方法是滑动窗口裁剪只从锚文本中截取最近 800 字作为风格样本正文分片处理每片 1500 字前后片保留 200 字重叠用于过渡衔接。def split_with_overlap(text, chunk_size1500, overlap200): 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( textinput_text, rewrite_strength0.5, replacement_rate0.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/目录并带上日期后缀。有一次我把「主角视角」相关的约束重写了一遍结果整章生成出来变成了第二人称叙述当时没有备份找了半天才从编辑记录里翻到旧版本重跑。从那以后我每次改提示词都强制走一遍「备份、测试、对比、上线」四步流程再没出过类似事故。这个习惯我希望你也能用上希望帮到你。本文还有配套的精品资源点击获取