提示词:

效果: 编写后换项目测试,不确定是否还有记忆在生效,还是提示词真实起效

经过几个佬友的测试，现在基本能在生产环境使用。就目前来说还没有特别大的坑，出文的质量，剧情连续性都没有问题。 我用来开发插件测试的小说已经出到10万多字了 也有了稿费了……前天签约的，截止昨天到账1毛钱 
先说说思路和这个插件的具体成文逻辑。
先开始是看到群里几个佬友讨论好几个线上的小说生成，在一定的上下文后剧情和世界观都会崩塌。正好最近我比较闲，就想到基于flymd做一个纯本地的AI小说引擎。纯本地的优势在于数据的存储和多样性以及更好的读写性能。 构思了下午后就开始搞了。
剧情和世界观都会崩塌就在于AI的上下文能力和忘事，普遍的解决方法是加入RAG，但是RAG在一定的数据量之后也会因为各种原因力不从心（模型能力 检索速度 索引体积 服务器算力）等。而且在增量索引上还有各种坑……场景的JSon和sqlite方案 体积爆炸，对算力要求还高还复杂。对于小说这个项目来说纯粹拖后腿
不过Rag我使用强度很高，之前也开发了rag的插件，直接复用了rag插件的那套逻辑。特点就是体积小，加载索引快 增量更新方便 但是牺牲了一些查询和过滤能力。这个牺牲的部分我通过后端弥补了自己使用下来非常满意~ 
Rag索引自动更新维护，一般情况下无须人工干预
光有RAG是不行的，还得建立AI和用户自己都能维护的“数据库”插件里我叫资料库如图

每个小说文件作为一个项目单位，根目录00-06（首次生成或者导入现有文稿生成）这个项目单位的资料库，这些资料首次是自动生成的，用户也能够手动维护（实际上不怎么需要介入） 部分资料是随章节更新自动更新（进度脉络，人物状态）还可以在小说目录下新建txt或者md手动补充一些额外资料，插件在写的时候也会加入参考。上下文占比可以在设置中自定义，也可以用设置中我调试好的（不是越大越好！） 写作的时候 我服务器上的后端还会对这些进行整理拼接。保证上下文质量。
资料库的质量，对小说的质量有决定性影响！
写作模式
分普通模式和agent模式，
普通模式工作逻辑和目前已有的线上项目基本一致，但是会有更好的上下文处理（后端拼接截取）效果也足够使用（节约tok

cc的url是https://wzw.de5.net吧，我一直是重新请求

Openrouter 已上线 2025 warpped

Your 2025 Wrapped | OpenRouter
各位佬友来分享一下自己的Card吧