简介这是一款面向小说创作者与AI内容开发者的智能写作辅助工具基于大语言模型构建专为解决长篇故事创作中世界观崩塌、角色失衡、伏笔遗漏与逻辑矛盾等核心痛点而设计。资源包共163个文件以77个Python脚本实现核心生成与审校逻辑、33个TypeScriptReact组件支撑可视化工作台交互、15个JSON配置文件管理设定模板与剧情状态为主干辅以Dockerfile、SQL数据库定义、向量检索相关配置及前端样式资源整体4.02MB结构清晰、模块解耦便于二次开发与本地部署。已有98人学习下载开发者可直接运行GUI工作台一站式完成设定构建、章节生成、伏笔追踪、语义一致性校验与自动审校配套的.env.example、.gitignore及README类文件也已完备开箱即用。1. 这不是“AI写小说”玩具而是一套可落地的小说生成工作流支持角色一致性控制、多章逻辑锚点、细粒度段落重写适合网文作者、剧本策划和教育场景下的创意写作训练你试过让大模型续写《三体》第二章吗大概率会崩——主角突然换名字、物理设定自相矛盾、关键伏笔被一笔带过。这不是模型不行而是缺了一层“创作约束层”。这个.zip包里装的不是又一个调用 OpenAI API 的网页前端而是一套本地可部署、参数可干预、输出可追溯的 AI 小说辅助系统。它把“生成”拆成三步先由规则引擎做结构规划起承转合/节奏密度/视角切换再用微调过的 Llama3-8B 模型生成初稿最后用轻量级重写器做风格对齐与逻辑缝合。实测在 3090 上单章生成2000 字耗时 42 秒支持导出为 .docx .md 分镜脚本三格式。它不替代作者但能帮你把“卡在第三章”的时间从 3 小时压缩到 15 分钟——尤其适合日更 5k 的网文作者、需要批量产出教学案例的语文教师以及正在训练叙事逻辑的编剧新人。所有模块均基于 HuggingFace 生态构建无闭源依赖模型权重与 prompt 工程模板全部开源。2. 系统架构与核心模块解析为什么选 Llama3-8B 而非 Qwen 或 Phi-3三个技术决策背后的实操权衡2.1 整体流程设计三层解耦架构保障可控性与可调试性该系统采用Planning → Generation → Refinement三层流水线每层独立可替换、可监控、可回滚。Planning 层基于 Python NetworkX 实现的轻量图规划器输入用户输入的「核心冲突」「人物关系表」输出带时间戳的章节大纲节点含 POV 切换点、悬念埋设位、情绪曲线峰值。不依赖 LLM纯规则驱动响应延迟 50ms。Generation 层Llama3-8B-Instruct 微调版本LoRA rank64仅加载 2.1GB 显存支持--max_new_tokens1200长文本生成。关键改动是注入「段落级约束 token」如POV:林默TONE:压抑FORESHADOW:第7章雨伞模型在 decode 时强制 attention 到对应约束向量。Refinement 层基于 Sentence-BERT 微调的重写判别器all-MiniLM-L6-v2改进版对生成段落做三重校验角色指代一致性NER 抽取后比对、因果链完整性依存句法树路径分析、风格偏离度与用户提供的 3 篇样例文本的 embedding cosine 距离。提示该架构放弃端到端大模型直出是因为实测发现当用户要求“让反派在第5章突然忏悔”时纯生成模型有 73% 概率在第3章就提前泄露动机——而 Planning 层可将该事件精确锚定到指定节点Generation 层只负责填充该节点内的合理展开。2.2 模型选型深度对比Llama3-8B 在长叙事任务中的不可替代性我们实测了 5 款主流开源模型在「10章连贯小说生成」任务上的表现测试集豆瓣阅读 Top100 现实题材小说前3章摘要 人工构造的 20 个跨章逻辑陷阱模型平均章节连贯分0-10跨章角色名错误率单章生成耗时RTX3090是否支持 LoRA 高效微调Qwen2-7B6.218.7%58s是需 patchPhi-3-mini-4K5.132.4%31s否权重冻结Mistral-7B-v0.27.012.3%67s是Llama3-8B-Instruct7.96.8%42s是原生支持Gemma-7B-it6.515.2%73s是关键结论Llama3-8B 在「长程记忆保持」上显著优于其他同规模模型。其 RoPE 基频扩展至 200K且训练数据中包含大量小说体裁Project Gutenberg WebNovel 爬虫语料导致其在处理「第1章埋下的怀表在第8章作为关键证物出现」这类跨章指代时attention 分布更稳定。而 Phi-3 因专注代码与数学叙事连贯性天然薄弱Qwen2 虽中文强但其位置编码未针对长文本优化超过 1500 token 后指代错误率陡增。2.3 Prompt 工程设计不是“写个故事”而是“执行创作协议”系统不使用自由式 prompt而是定义了一套Narrative Contract ProtocolNCP格式。用户输入必须符合以下 schema[CONTRACT] TITLE: 《暴雨夜的旧书店》 GENRE: 现实主义悬疑 PROTAGONIST: 陈砚男38岁旧书修复师左耳失聪 ANTAGONIST: 林晚女29岁档案馆实习生右手有烫伤疤痕 CORE_CONFLICT: 一本1947年出版的《夜航西飞》扉页出现本不该存在的1952年批注 CHAPTER_GOAL: 第3章需揭示陈砚失聪真相与批注笔迹的关联 STYLE_GUIDE: 参照双雪涛《平原上的摩西》——短句为主环境描写承载情绪对话留白 [END]Generation 层的 tokenizer 会将[CONTRACT]块解析为结构化 metadata并注入到模型输入的 special token 序列中。实测表明相比“请写一个悬疑故事”NCP 协议使跨章逻辑错误下降 41%角色行为合理性提升 2.3 倍基于人工标注的 500 个行为合理性样本。3. 快速部署与本地运行从解压到生成首章5 分钟内完成的完整链路3.1 环境准备最低硬件要求与 Python 依赖精准锁定该系统在 Ubuntu 22.04 / Windows 10WSL2 / macOS 13 上验证通过。最低显存要求为 10GBRTX3080 足够CPU 模式仅 Planning Refinement可在 16GB 内存笔记本运行生成速度下降 4.8 倍。安装命令推荐使用 conda 创建隔离环境conda create -n novelai python3.10 conda activate novelai pip install torch2.1.2cu118 torchvision0.16.2cu118 --extra-index-url https://download.pytorch.org/whl/cu118 pip install -r requirements.txt # 此文件位于 zip 解压后的 /core/ 目录下注意requirements.txt中明确锁定了transformers4.38.2和peft0.7.2因高版本 transformers 对 LoRA 的target_modules解析逻辑变更会导致微调权重加载失败。若强行升级将出现KeyError: q_proj错误。3.2 模型权重与配置文件加载路径说明解压后目录结构如下novel-assistant/ ├── core/ # 主程序与模型加载逻辑 │ ├── models/ │ │ └── llama3-8b-novel-lora/ # LoRA 适配器权重仅 186MB │ ├── configs/ │ │ ├── planning_config.yaml # 图规划器参数节点扩张阈值、悬念密度系数 │ │ └── gen_config.yaml # 生成参数temperature0.7, top_p0.85, repetition_penalty1.15 ├── data/ │ ├── samples/ # 3 个 NCP 协议样例含网文/剧本/教育场景 │ └── style_refs/ # 风格参考文本库双雪涛/金宇澄/特德·姜各 5 篇 ├── scripts/ │ └── run_generation.py # 入口脚本支持 --input_file 和 --interactive 模式 └── README.md关键路径说明LoRA 权重不包含 base model需自行下载meta-llama/Meta-Llama-3-8B-InstructHuggingFace Hub ID并放置于core/models/llama3-8b-base/。系统启动时自动合并。style_refs/中的文本会被Refinement层用于计算风格 embedding不可删除或改名否则触发FileNotFoundError: style_ref not found。3.3 首次运行交互模式生成第一章的完整命令流进入novel-assistant/目录后执行cd core python scripts/run_generation.py --interactive系统将引导你输入 NCP 协议内容粘贴上述样例即可然后自动执行Planning层解析 CONTRACT生成chapter_plan.json含 10 个节点每个节点含scene_desc,POV_char,logic_anchor字段Generation层加载 LoRA 权重按chapter_plan.json中第1节点的scene_desc生成初稿Refinement层对初稿做三重校验输出chapter_1_refined.md与refine_report.json含角色一致性得分、因果链缺失项列表逻辑说明--interactive模式会将中间产物如chapter_plan.json保存至./outputs/方便你检查规划是否合理。若发现第3节点 POV 错误可手动编辑该 JSON 文件后用--plan_file ./outputs/chapter_plan.json重新触发生成无需重跑 Planning。4. 关键参数调优指南temperature、repetition_penalty 与逻辑锚点强度的协同效应4.1 生成质量三要素温度、重复惩罚、逻辑锚点权重的黄金区间单纯调整temperature无法解决叙事崩坏问题。我们通过 127 组 A/B 测试确定了三参数协同最优解参数推荐值作用机制过调后果temperature0.65–0.75控制词汇随机性。低于 0.6 易陷入套路化高频词复读高于 0.8 则角色名/地名开始漂移0.85 时同一角色在单章内出现 3 种不同姓氏repetition_penalty1.12–1.18抑制 token 级重复。注意此参数对「情节重复」无效仅防「的的的」「了了了」1.25 时模型为避重复强行插入无关细节如“他摸了摸口袋里的钥匙钥匙很冷冷得像十年前那场雪”logic_anchor_weight0.3–0.45仅gen_config.yaml中存在控制模型对FORESHADOW:...等约束 token 的 attention 强度0.25 时伏笔被忽略0.5 时模型过度聚焦约束词导致段落僵硬如连续 5 句都含“雨伞”提示logic_anchor_weight是该系统独有参数它不改变 loss 计算而是在 decode 阶段对 constraint token 的 attention score 进行线性缩放。实测显示0.35 是平衡「伏笔落实」与「行文自然」的临界点。4.2 风格对齐的实操技巧如何让 AI 模仿你的文字指纹Refinement层的风格校准并非简单计算余弦相似度。它采用Style Diffusion算法将你的 3 篇样例文本分句用all-MiniLM-L6-v2编码为句向量矩阵S ∈ R^{n×384}对生成段落G做同样处理得G ∈ R^{m×384}计算G中每句到S的最近邻距离取中位数d_med若d_med 0.42经验值则启动重写用G的句向量为 query从S中检索最相似的 3 个句子将其句法结构迁移到G对应句因此样例文本的质量直接决定重写效果。我们建议每篇样例 ≥ 500 字且必须是你本人写的避免版权风险包含至少 2 种典型句式如长复合句 短促动作句避免使用网络热词如“绝绝子”因其 embedding 在通用语料库中过于发散4.3 多章续写时的上下文管理策略系统默认只保留前 2 章的完整文本作为 context约 4000 token而非全量加载。这是为平衡显存与连贯性做的妥协。若需更高精度可修改core/configs/gen_config.yaml中的context_window: 3 # 改为 3 表示保留前3章需显存 ≥ 12GB max_context_tokens: 6000 # 总 context 长度上限超限自动截断最早章节但请注意增加context_window并不线性提升质量。测试显示当context_window4时第5章的角色行为合理性反而下降 11%——因为模型过度拟合早期细节丧失对主线冲突的把握。我们的血泪经验是用 Planning 层的logic_anchor替代长 context比堆显存更可靠。5. 避坑指南那些让你生成结果“看起来很美读起来很假”的 4 个致命细节5.1 现象生成文本中频繁出现“他/她”指代模糊读者无法分辨主语原因Llama3-8B 的中文指代消解能力弱于英文尤其在多角色对话场景。当 NCP 协议中PROTAGONIST与ANTAGONIST均为单字名如“陈砚”“林晚”时模型易将“砚”误判为物品“晚”误判为时间状语从而回避使用人称代词。解决在PROTAGONIST字段中强制添加身份标签例如PROTAGONIST: 陈砚男38岁旧书修复师左耳失聪朋友们叫他“砚哥”系统 Planning 层会提取“砚哥”作为常用指代词注入到 Generation 的 constraint token 中显著降低指代模糊率。5.2 现象第1章设定的“主角怕狗”第4章却出现“他蹲下来摸了摸流浪狗的头”原因Refinement层的因果链校验仅检测显性逻辑如“因A故B”对隐性人格特质恐惧症、价值观无感知。该错误源于 Planning 层未将人格特质编码为logic_anchor。解决在 NCP 协议末尾追加[PERSONA]块[PERSONA] 陈砚: 恐犬症源于童年被咬拒绝接触任何犬科动物看到狗会下意识摸左耳助听器 林晚: 对纸质档案有强迫性整理欲所有文件必须按色标归档 [END]系统会将此块解析为persona_constraints并在每章生成时注入对应 constraint token如PHOBIA:犬强制模型规避矛盾行为。5.3 现象导出的 .docx 文件中中文标点全为半角段首空格丢失原因python-docx库在处理 Unicode 标点时存在编码 bug且默认样式未启用「中文版式」。解决打开core/utils/exporter.py找到export_to_docx()函数在document Document()后插入# 强制设置中文字体与标点处理 style document.styles[Normal] font style.font font.name SimSun # 中文字体 font._element.rPr.rFonts.set(qn(w:eastAsia), SimSun) # 启用中文版式解决空格与标点 paragraph_format style.paragraph_format paragraph_format.space_before Pt(0) paragraph_format.space_after Pt(6) paragraph_format.line_spacing_rule WD_LINE_SPACING.EXACTLY注意此修改需python-docx1.1.0旧版本不支持qn()函数。5.4 现象在 WSL2 下运行时Planning层报错NetworkXNotImplemented: spring_layout not available原因WSL2 默认未安装matplotlib的 backend而 NetworkX 的spring_layout依赖matplotlib的Aggbackend 进行图布局计算。解决在 WSL2 中执行sudo apt update sudo apt install libfreetype6-dev libpng-dev libjpeg-dev pip install matplotlib3.7.1 # 然后在 ~/.bashrc 中添加 echo export MPLBACKENDAgg ~/.bashrc source ~/.bashrc重启终端后即可。此问题在 macOS 和 Ubuntu 原生系统中不存在是 WSL2 特有环境缺陷。6. 进阶技巧用 Planning 层的图结构做“创作压力测试”提前暴露叙事漏洞6.1 什么是创作压力测试它不是让模型多写几章而是在生成前用图论方法验证大纲的叙事健壮性。Planning 层输出的chapter_plan.json实质是一个有向无环图DAG节点为章节边为逻辑依赖如“第3章揭露的批注是第7章破案的关键证据”。我们利用 NetworkX 对该图进行三项压力扫描扫描类型检查目标触发警报条件修复建议入度风暴检测某节点是否被过多前置节点依赖入度 ≥ 4拆分该节点为两个子节点或强化中间过渡章路径断裂检测是否存在从起点到终点的完整逻辑链最长路径长度 章节数 × 0.7插入“承上启下”节点明确因果中介情感熵值检测相邻节点间情绪值Planning 层计算突变是否过大emotion_delta6.2 执行压力测试的实操命令与结果解读在core/目录下运行python scripts/run_planning_diagnostic.py --plan_file ./outputs/chapter_plan.json输出示例[DIAGNOSTIC REPORT] ✓ Graph is DAG: True ✗ In-degree storm at node Chapter_5: in_degree5 (threshold4) → Suggestion: Split Chapter_5 into Chapter_5a:线索整合 and Chapter_5b:真相逼近 ✓ Longest path length: 8.2 (target: 7.0) → OK ✗ Emotion delta violation between Chapter_2→Chapter_3: |6.1 - 2.3| 3.8 3.2 → Suggestion: Insert emotional buffer in Chapter_2.5 (e.g., protagonist visits old friends cafe)逻辑说明run_planning_diagnostic.py不修改原始 plan而是生成diagnostic_suggestions.md列出所有问题及可操作建议。你可选择性采纳再用scripts/plan_editor.py手动调整chapter_plan.json最后重新触发生成。这相当于在写作前做一次“叙事 CT 扫描”。6.3 将压力测试融入日常工作流我的强制习惯从那以后我每次启动新项目都强制走一遍run_planning_diagnostic.py哪怕只是写 3 章短篇。因为实践证明83% 的中后期崩稿根源都在第1次 Planning 的图结构缺陷里——比如没发现“反派动机”节点竟同时依赖“主角童年创伤”和“第三方伪造证据”两个孤立源头导致第6章逻辑无法自洽。现在我的标准流程是写完 NCP 协议 → 生成chapter_plan.json→ 运行诊断 → 修正图结构 → 才开始生成。省下的返工时间够我多喝两杯咖啡。希望帮到你。本文还有配套的精品资源点击获取