一個和酒館 json 互轉的插件，豈非時下之需？
v2.5.0 版本更新发布
更新内容
新功能
- 叙事记忆系统：每章完成后 AI 提取大纲未覆盖的关键叙事细节，存入
progress.memory_entries；写作与事实核查 prompt 注入记忆及自动截取的原文片段 - 记忆观测页：新增只读
#memory页，展示统计、列表/时间线视图、分类/章节筛选及原文片段预览 - 专有名词标记：角色名称可使用
「」括号标记，防止中文生成分词问题 - 配置变更确认：AI 不可静默覆盖用户已填故事配置；冲突写入
pending_config_changes.json，在 ConfigChangePanel 待用户勾选采纳 - 竖排侧边栏导航：页面导航从横向标签改为左侧竖排导航（约 176px），图标 + 文字
- 大纲字数约束：按
target_words_per_chapter计算每章大纲建议字数区间；不足时自动重试；生成时注入已登记角色白名单 - 大纲人物一致性检查：生成后 AI + 启发式检查未登记人物；SSE
outline_character_suggestions支持一键创建角色 - 章节字数控制：以 prose 单位校验章节字数并自动重试；选最优稿并跳过有害扩写；持续失败时回退用户审核
- Agent 梗概字数建议：梗概建议字数按全书计划规模（
chapter_count × target_words_per_chapter）缩放
Bug 修复
- 助理重复回复：修复异步工具子任务期间会话 reload 后 SSE 延迟 flush 导致 assistant 消息重复展示
- Token 数字动画：TaskTokenBadge 线性插值；目标值低于当前显示时从 0 重新向上插值
- delete_chapter 前沿定位：Agent
delete_chapter改为删除写作前沿章节，而非大纲尾部
文档
- README 新增网络权限说明
- README 新增 Windows SmartScreen 拦截提示
- README 与 Agent 系统提示中补充大纲重新生成工作流说明
完整变更日志: Comparing v2.4.0...v2.5.0 · Nigh/show-me-the-story · GitHub
看介绍我还以为是个很大的应用呢，没想到那么小巧，厉害
1 个赞
因为没有引入平台相关的GUI，直接serve了一个前端作为GUI，所以基本上体积都是功能带来的。没有引入什么额外的东西。
遇到个严重的问题，就是在模型地址那块，你似乎是写死了要加v1/chat，但是z.ai是加的v4，而且coding plan前面的链接也不一样，https://docs.z.ai/guides/overview/quick-start，导致我现在用不了
确实现在只考虑了常见的端点格式，我会加一个完全可由用户定义的API地址的选项来兼容非常见端点的情况。
我自己也开发了一个AI应用（讨论小说剧本的聊天室，ai会扮演不同角色，从不同角度提出自己的建议，自己用），我在这方面的设计是默认用用户提供的URL，如果连接有问题，则自动尝试OpenAI和Claude格式的链接后缀，如果都无效再提示错误
可以纳入考虑。但我会希望行为更加直接更加可见一些。
@skystar 目前的处理方式是新增了严格模式。严格模式下只补全/chat/completions。常规模式也进行了优化，当 url 中含有任意版本号时，则不补全版本号，只有不含版本号时才自动补v1。
最后，在输入框下方也增加了补全后的完整 url 可以供用户核对。
楼楼有没有试过长篇大概能实现多少字数呢 例如我现在想实现一本400章左右每章3000左右的小说，这个长度幻觉会严重吗
在目前的架构下，根据不同模型和上下文窗口大小所估算的支持的内容长度范围在 README 中有详细描述。
对于超长篇作品的创作需要对整体架构方式进行升级，这也是我下一步的主要工作内容。
1 个赞
现在可以了，谢谢，继续试用软件，以前遇到最大的问题应该是字数不好控制
希望连接测试有一个长状态的显示，比如在按钮左侧显示一个带颜色的小点，不知道为什么我这里连接测试很慢，然后等我切标签回来就不知道到底连接成功没有了
合理需求。下一版加上。
早上发起的大纲任务，刚去看了发现重试了409次。。
是模型的api不通么。
429，看来glm他们服务器还是紧张啊，不过我主要想说的是这个重试机制，一般多次失败都会延长重试时间，不会无限发起重试的
重试间隔有做指数退避。说明里面也写了是无限重试。除非是致命错误才会停止。由于重试没有什么副作用，而且鉴于LLM api的不稳定性，这个机制目前无需修改。
我这里一直是稳定间隔30秒在重试
30秒已经是很长间隔了。