简介这是一套基于大语言模型的智能小说创作助手面向长篇故事创作者、编剧与AI应用开发者重点解决世界观设定不连贯、角色发展缺失、剧情前后矛盾等创作痛点。压缩包内共一百六十三个文件其中Python后端脚本与TypeScript/React前端组件占据主体辅以JSON配置、Markdown文档、SQL数据及模型权重等整体大小约4.02MB源码组织合理便于直接部署与二次开发。工具内置小说设定工坊、智能章节生成、状态追踪与伏笔管理、语义检索引擎、知识库集成及自动审校机制并支持可视化工作台一键操作可有效保障长篇作品设定统一、情节连贯。已有99人学习下载读者不仅能获得完整可运行的AI写作系统还可借此研究多阶段生成、长程上下文维护、矛盾自动检测等模块的具体实现适合作为大模型创意写作应用的参考工程。1. AI 智能小说创作助手.zip拿上手就能产出章节草稿吗写长篇的人都知道卡住的不是“没灵感”而是“有灵感却没结构”一个惊艳的开头写完后第 5 章到第 15 章该怎么铺、配角什么时候登场、伏笔埋在哪里回收全在脑子里打架。这款基于 AI 的智能小说创作助手正是冲着这个痛点来的——zip 包里的东西拆开看通常不只是一个模型壳子而是一条被编排好的创作管线能生成世界观、人物卡、分章大纲也能按章节续写正文再通过回填摘要维持长篇一致性。它适合两类人想用现有大模型批量产出可用草稿的写作者以及正在搭 AI 内容工具的开发者。前者把它当写作搭子后者拿它当地道的工程模板。2. 拆开 zip 看架构从单模型到多角色 AI Agent 的创作管线2.1 为什么单模型写出来像背景板多角色协作才像小说直接给大模型一句“写一个悬疑小说第一章”多数时候你得到的是人物扁平、视角乱跳、对话全是解释性台词的 2000 字。问题不在模型能力而在任务拆得不细。写小说是复合劳动世界观设定、剧情编排、文笔润色、逻辑校验这些职责硬塞给一次生成模型只能取平均。所以常见的做法是把小说创作建模成多 AI 协作的 agent 工作流——一个“主编 Agent”负责任务分发下属有设定 Agent、编剧 Agent、文笔 Agent、校验 Agent。设定 Agent 产出人物卡和世界规则编剧 Agent 按章节拆解“目标-冲突-转折”文笔 Agent 负责把大纲落实成场景和对话校验 Agent 回读上下文检查设定是否吃书。这不只是工程上的炫技它让每个环节的 prompt 短了、参数能单独调出问题时也知道该改谁。zip 包是否能称得上“智能助手”看的不是能不能聊而是有没有把这几类角色拧成一条可控的流水线。2.2 zip 包里常见的模块划分与数据流向我解压过不少同类压缩包它们的目录不一定同名但核心模块基本能对上。这里给一张常见划分表你可以拿它去对照手头 zip 里到底缺了什么模块职责主要产物设定引擎生成并维护世界观、人物卡、势力关系结构化 JSON 设定库大纲编排器把一句话创意扩成卷、章、节三级结构markdown 大纲正文生成器按章执行生成支持续写与批注写作正文文本记忆管理器滚动摘要、检索设定、控制上下文长度摘要库与检索结果数据流大体是单向加回环创意先进设定引擎设定喂给大纲编排器编排结果驱动正文生成器正文写完由记忆管理器抽摘要下一章的生成再带上“历史摘要 相关人物卡 当前大纲”作为上下文。别小看最后的回环没有它第 20 章的模型根本不记得第 1 章埋的伏笔。zip 里如果只有一个可执行文件而没有设定库和摘要目录那它大概率只适合短篇试玩撑不起长篇。2.3 动手部署环境准备、依赖安装与模型接入无论 zip 里是什么形态落地第一步都是把 Python 环境和依赖装干净。我建议先建独立虚拟环境避免把系统 Python 搞乱mkdir ai-novel cd ai-novel python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai python-dotenv这里的openai不是只能连官方服务OpenAI 兼容接口的本地模型服务如 vLLM、Ollama 的 OpenAI 兼容端点都能用同一个客户端。这样 zip 包里的调用代码就不用因为换模型而改。装好后创建.env文件把端点、密钥和模型名写进去# .env BASE_URLhttp://127.0.0.1:8000/v1 API_KEYsk-local MODEL_NAMEqwen2.5-14b-instruct配置要点是BASE_URL和MODEL_NAME一定要从 zip 包里提供的示例配置复制不要自己猜。很多翻车现场就是模型名写错一个下划线导致接口返回 404。用source .venv/bin/activate激活后再跑包里的main.py如果报缺依赖就补一个requirements.txt导入不推荐全局 pip install后面升级模型服务时你会感谢这个隔离环境。3. 把一句话创意跑成第一章编排脚本、提示词模板与生成参数3.1 提示词模板拆解三个必留的插槽小说类提示词的核心是“结构化插槽”而不是整段只读文本。一个经验是至少留三个变量位题材类型、核心设定、目标章节数。用 Python 字符串模板表示就是这样SYSTEM_PROMPT 你是一位资深小说编辑兼编剧擅长类型文学。 你负责把作者的一句话创意扩展成可执行的分卷大纲要求 - 故事必须有明确的对抗力量人、环境、内心冲突均可 - 每一卷必须有独立的危机与解决 - 人物弧光要可追踪不能出场强、后续弱。 USER_TEMPLATE 请基于以下创意规划一部 {genre} 小说。 一句话设定{premise} 计划篇幅{target_chapters} 章 请先输出 3 卷结构再输出第 1 卷的 8 章细纲每章 50 字以内。逻辑说明SYSTEM_PROMPT锁定职业身份和写作纪律USER_TEMPLATE负责注入变化量。这样做的好处是换题材只改genre和premise不用重写一大段提示词。target_chapters这个插槽直接控制输出粒度——写短篇时设 12写长篇设 72模型会按卷章结构去组织内容而不是一股脑输出一个无边无际的文本块。3.2 让步骤串起来一个可复现的编排脚本有模板还不够要把“生成大纲→生成人物卡→生成第一章”串成自动流程。下面这段脚本把三步串成一次执行方便你在命令行直接跑import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(base_urlos.getenv(BASE_URL), api_keyos.getenv(API_KEY)) MODEL os.getenv(MODEL_NAME) def ask(system: str, user: str, temperature: float 0.8) - str: resp client.chat.completions.create( modelMODEL, temperaturetemperature, messages[ {role: system, content: system}, {role: user, content: user}, ], ) return resp.choices[0].message.content def generate_pipeline(premise: str, genre: str, chapters: int): outline ask( SYSTEM_PROMPT, f请规划一部 {genre}{chapters} 章。设定{premise}, ) print(大纲生成完毕长度, len(outline)) character_prompt f根据以下大纲生成 4 个主要人物卡\n{outline} persons ask( 你是人物设定师输出 JSON 格式人物卡包含姓名、性格、动机、缺陷。, character_prompt, temperature0.7, ) print(人物卡生成完毕, persons) chapter_one ask( 你是小说作者只用中文写作开头不解释背景直接进入动作场景。, f请写第一章正文上下文\n大纲{outline}\n人物卡{persons}, temperature0.9, ) print(第一章正文\n, chapter_one) if __name__ __main__: generate_pipeline( premise退休刑警在小区棋摊发现连环案线索, genre悬疑, chapters30, )参数说明temperature在三步里从 0.8 降到 0.7 再升到 0.9是刻意为之。大纲和人物卡需要稳定和逻辑温度太高会产出自相矛盾的设定所以用偏低值正文需要文采和意外感温度调到 0.9 能带来更丰富的遣词变化但代价是偶尔出戏需要在后面靠校验模块兜住。输出里的打印只是给你看的真正的工程包会把大纲和人物卡落盘成 JSON供下一阶段读取。3.3 影响小说质感的核心生成参数同样的提示词参数不同成稿质量能差一个量级。下面是四个方面对照参考也是我调试生成效果时最先动的手参数建议区间调低时的表现调高时的表现temperature0.6 ~ 0.9平实稳定、寡淡词汇丰富、偶尔失控top_p0.85 ~ 0.95收敛、套路化发散、结构松散frequency_penalty0.2 ~ 0.5重复用词增多刻意变换说法、节奏碎presence_penalty0 ~ 0.3话题单调不断引入新话题一句经验top_p不要单独调到 0.99 配合高温度两个随机源叠一起文本会像醉酒说话连标点都飘。我一般固定top_p0.9只调温度和两个 penalty。写对话多的场景frequency_penalty调高到 0.4能明显减少“他笑了笑”“她低声说”这类高频套话的出现。4. 让小说不像“AI 味”风格锚点、防同质化与记忆窗口4.1 风格锚点给模型一个文风指纹而不是“文笔好”让模型“写得好”是无效指令它只会回到训练分布的平均值。工程做法是把风格拆成可量化的锚点写进 system prompt 或生成配置。常见锚点包括句子长度、感官描写密度、比喻偏好和禁用词表。一个可抄作业的写法{ style_anchor: { avg_sentence_length: 15-25 chars, sensory_details: sight and smell only, no sound, metaphor_type: domestic objects, dialogue_style: short sentences, no tags, blocked_phrases: [微微一笑, 眼神深邃, 心中暗想] } }把这些锚点 JSON 拼进正文生成器的系统提示里比写十句“要有文采”更见效。原因是模型对具体约束的遵循度远高于抽象评价。blocked_phrases尤其有用它直接切断 AI 味最重的俗套表达。实测中加与不加这套锚点生成文本的重合度能差出 30% 以上读者第一眼感知就是“像是人写的东西”。4.2 防同质化惩罚重复的同时也要给模型“选择题”许多 zip 包默认把重复惩罚拉满结果模型为了不重复同一个词开始用别扭的同义替换读起来更怪。更稳的组合是frequency_penalty用中等强度同时在提示词里强制模型在生成前先列出三个可选的写法走向。下面是在正文生成器里做候选选择的片段candidate_prompt f 根据当前剧情压力点给出三种下一段的发展可能 A. 主角采取激进行动代价是暴露身份 B. 反派先手主角被迫防守 C. 引入第三方势力打破对峙。 选一种最适合当前氛围的只写发展写完后直接续写正文。 逻辑说明这个技巧把“发散选择”放在正文生成之前让随机性发生在可控的语义空间里而不是发生在措辞层面。A/B/C 三种走向实际上是在给模型做一次可校验的头脑风暴后续无论选哪个正文都会比直接续写更有方向感。zip 包如果已经包含“多走向候选”模块那它的架构是懂长篇创作的如果只有一条生成通路你可以自己加这一层。4.3 长篇记忆滑动窗口与摘要压缩别把全文塞进模型大模型有上下文窗口但长篇小说的全部文本很快会超过任何窗口。我常用的方案是“滚动摘要 关键片段检索”双轨。每章生成完把这一章压缩成 150 字以内的剧情摘要下一章生成时把最近的 5 条摘要拼进上下文同时从人物卡里提取与当前章节相关的内容。这里有一个落地类class MemoryManager: def __init__(self, max_summaries5): self.summaries [] self.max_summaries max_summaries def add(self, chapter_no: int, summary: str): self.summaries.append({chapter: chapter_no, summary: summary}) if len(self.summaries) self.max_summaries: self.summaries.pop(0) def build_context(self, current_chapter: int) - str: recent [s[summary] for s in self.summaries if s[chapter] current_chapter] return \n.join(f第 {i1} 章摘要{s} for i, s in enumerate(recent))参数说明max_summaries5对应大约 5 章的历史记忆足够覆盖中短篇的连续性需求。如果你写的是百万字长篇建议把摘要升级为“分卷摘要 最近章节全文 相关事件检索”三层结构。注意pop(0)会丢弃最老的摘要这对时间线强相关的小说并不完全安全必要时要按“重要事件”分组保存而不是机械按顺序丢弃。5. 避坑清单从 zip 解压到内容审核的五类踩坑记录5.1 解压后第一步就报错依赖装不上、路径带中文现象双击启动脚本后窗口闪过一堆 ModuleNotFoundError 或者 UnicodeDecodeError还没看到界面就退出。原因大多数 zip 包是在 macOS 或 Linux 环境下打包的依赖列表里没锁 Python 版本另外有些 Windows 用户把包解压到了带中文和空格的目录模型加载路径乱码。解决先确认 Python 版本是否在包要求的区间内再换镜像源重装依赖pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple尽量把项目路径改成纯英文且无空格比如D:\novel\ai-novel。如果你解压后看到.venv目录直接删掉自己重新建虚拟环境别用包里面带的——跨操作系统后它基本是坏的。5.2 角色对话稍一出格整章生成被安全策略拦成空白现象模型生成到激烈冲突场景时突然返回空内容或者只给出一句“抱歉我无法生成”。有些本地模型服务会返回 400 或 500 状态码。原因不是你的提示词错了而是底层模型自带的内容安全策略加上部分 zip 包内置了关键词过滤器过滤逻辑粗糙把正常剧情冲突也误判了。解决不要把过滤器全部拆掉这既不安全也容易让生成内容失控。更稳的做法是把词表过滤升级为二次判断命中敏感词时不直接断生成而是给模型追加一条“剧情需要冲突但请改用场景张力描写避免直白暴力词汇”的重写指令。同时小说开篇尽量避免出现此类极端设定先把人物关系和职业背景写扎实后续冲突让模型通过悬念和压力来表现而非依赖敏感描写。5.3 越写越短上下文窗口被历史塞满模型开始“失忆”现象前 10 章每章能生成 3000 字到第 12 章开始输出不到 800 字就停而且人名前后不一致。原因把全部历史章节塞进 system prompt把上下文窗口耗尽了模型生成时只剩很少的可用 token只好提前结束。解决改用第 4.3 节的摘要管理器严格控制送进模型的 token 数。每次生成前打印一下拼接后的上下文字符数超过窗口的 60% 就压缩摘要。另外要提醒max_tokens也要随上下文动态调小否则会报长度超限的错误。5.4 输出格式乱套引号变半角、章节标题带 Markdown 符号现象生成的小说正文里中文和英文引号混用或者段落间冒出**、#这些标记直接发布会被渲染成一堆格式垃圾。原因模型在训练时被大量网络断落污染对中文引号把握差某些 zip 包的后处理脚本没有清理 Markdown 标记。解决在生成后加一道轻量清洗函数把半角标点转全角剥离纯标记行。这一层不要省它是稿子能不能直接进排版系统的关键。正则替换时注意别把**误伤成乘法运算——小说正文里很少出现数学符号但保险起见先判断上下文再替换。5.5 连续生成后吃书人物称呼、时间线前后矛盾现象第 6 章还叫“沈明远”第 8 章就写成了“沈远明”前几天是冬天后一章突然满地落叶。原因每次生成都是独立的请求模型没有可靠的状态同步。人物卡虽然生成了但正文生成器没有强制读取卡上的姓名和时间锚点。解决把“人物卡 当前时间线 历史摘要”拼成一个不可省略的固定前缀并在 system prompt 里加规则“所有姓名、时间、地点必须用前缀中的设定禁止自行变更”。这是成本最低的防吃书手段比靠模型自觉可靠得多。6. 再进一步把创作助手改成长线写作系统的三个进阶技巧技巧一是给每个章节写结构化日志。不要只存正文要把本章的事件、人物状态、伏笔状态拆成字段落盘。一个人物 30 章后的性格变化、一个伏笔从埋下到回收的轨迹靠这些字段能自动校验。zip 包里若没有这个模块建议自己补一个chapter_log.json每次生成后追加记录这能让你肉眼看出哪一章开始人物走形。技巧二是引入轻量检索。当设定库超过几万字时全量塞进上下文既不现实也浪费 token。做法是每次生成前只检索与当前场景相关的人名、地名、事件条检索可以通过简单的关键词匹配完成不一定非要上向量库。关键是把“所有设定都带上”变成“当前场景需要的设定才带上”这样模型注意力更聚焦生成的细节也更贴设定。技巧三是双候选加人工审校。对关键章节同时生成两版正文一版高温度放飞一版低温度保底再让模型以编辑身份挑出更优的一版并说明理由。这个“模型审校模型”的流程比自己一篇篇读效率高很多遇到双版本都不满意的才需要人工干预重写。我自己的经验是20 章以内的中篇双候选加自动审校能把废稿率从 30% 压到 10% 左右而真正重要的高光章节人工修一遍依然不可省。坚持这样跑完整部小说后你会形成一种直觉AI 助手最值得投入的从来不是让它直接写完一整本而是让它在设定、大纲、记忆这些体力活上替你打底把你的精力留给真正的创作时刻。我是从写过几部废稿的写手转来做工具的最深的教训是“别让模型替你决定故事走向但它帮你记住所有决定”。希望帮到你。本文还有配套的精品资源点击获取