12月21日更新：昨天上线后后端出了问题，导致无法一键开坑，昨晚已经修复了。
我的小说已经快20万字了。今天有了一点质量倒退的痕迹，在薅了无数根头发后，我构思出一个升级方案，落地测试一天比较满意~ 
主要在RAG和不同的上下文来源权重做了优化和升级。Rag由串行改为并发，并升级为三层召回+流式topK 召回精度和速度都提升明显，在今天的试用中，除了客串的人物外（出现重名），13个主要人物人设毫无漂移。甚至能在 姓 名 英文口语简称 中文简称中自动切换不出错误。
ps ： 用claude做plan模型 效果非常得好！
下面是旧内容
经过几个佬友的测试，现在基本能在生产环境使用。就目前来说还没有特别大的坑，出文的质量，剧情连续性都没有问题。 我用来开发插件测试的小说已经出到10万多字了 也有了稿费了……前天签约的，截止昨天到账1毛钱 
先说说思路和这个插件的具体成文逻辑。
先开始是看到群里几个佬友讨论好几个线上的小说生成，在一定的上下文后剧情和世界观都会崩塌。正好最近我比较闲，就想到基于flymd做一个纯本地的AI小说引擎。纯本地的优势在于数据的存储和多样性以及更好的读写性能。 构思了下午后就开始搞了。
剧情和世界观都会崩塌就在于AI的上下文能力和忘事，普遍的解决方法是加入RAG，但是RAG在一定的数据量之后也会因为各种原因力不从心（模型能力 检索速度 索引体积 服务器算力）等。而且在增量索引上还有各种坑……常见的Json和sqlite方案 体积爆炸，对算力要求还高还复杂。对于小说这个项目来说纯粹拖后腿
不过Rag我使用强度很高，之前也开发了rag的插件，直接复用了rag插件的那套逻辑。特点就是体积小，加载索引快 增量更新方便 但是牺牲了一些查询和过滤能力。这个牺牲的部分我通过后端弥补了自己使用下来非常满意~
Rag索引自动更新维护，一般情况下无须人工干预
光有RAG是不行的，还得建立AI和用户自己都能维护的“数据库”插件里我叫资料库如图
每个小说文件作为一个项目单位，根目录00-06（首次生成或者导入现有文稿生成）这个项目单位的资料库，这些资料首次是自动生成的，用户也能够手动维护（实际上不怎么需要介入） 部分资料是随章节更新自动更新（进度脉络，人物状态）还可以在小说目录下新建txt或者md手动补充一些额外资料，插件在写的时候也会加入参考。上下文占比可以在设置中自定义，也可以用设置中我调试好的（不是越大越好！） 写作的时候 我服务器上的后端还会对这些进行整理拼接。保证上下文质量。
资料库的质量，对小说的质量有决定性影响！
写作模式
分普通模式和agent模式，
普通模式工作逻辑和目前已有的线上项目基本一致，但是会有更好的上下文处理（后端拼接截取）效果也足够使用（节约token和字符）
agent模式会调用plan模型（可单独设置）在续写的时候 根据走向设定和用户指令只来细化写作方案再发给写作模型（如图）
写作模型会按照这些方案进行分段写作，提供三种思考模式
普通思考的质量已经足以应对90%以上情况 ，每次写作会和后端进行交互，在写作的时候就完成润色和修改。 下方是Claude的的交互示例
如果你选择了中等思考和强思考会额外在每段写作后加入质询甚至每段根据内容都进行一次索引
实际使用中提升效果属于成本>收益…… 建议使用普通
另外 还有自动审计功能，用于升级剧情的一致性，但是在现在这个版本 已经没啥用了………一致性刚刚的。
我小说并没有太用心 主要是调试插件 一个角色在第一卷第五章和主角团队发生冲突，到第二卷第九章，我直接零指令让AI续写 AI都还记得之前的冲突，对人物心里进行了描写（中间差不多有5万字了）
另外 提供了在没有思路的时候 完全让AI根据剧情和世界观等提供走向选择 但是这个极其耗费token和字符！ 慎用
AI写好后，第一步是追加草稿，这部分会被两个AINOVEL:drifID包裹，审阅后直接和AI对话可以让AI进行修改（高token消耗），直到你手动删除首尾的AINOVEL:drifID
续写的时候会带上人物状态（新建章节后自动生成（也可以手动维护06_任务状态），请务必等生成完毕）致力可以指定出场或者该人物的后续指向，比如 死 死 死 死 死！
先写到这里吧， 想要尝试的可以下载flymd 后现在程序库管理制定好库文件夹 再去扩展市场下载AI小说引擎插件 就可以使用了~ 测试期间只要我服务器还撑得住（撑不住我就不送咯） 注册就送百万字符 大家慢慢玩
的 都是 修仙啊 都市啊 穿越啊 同人啊 类似短剧那种不过脑子的口水文…… 大部分人追求爽 不会在乎质量的 在乎质量的人 不看这写类型 