2. V2EX
  3. [开源自荐] 做了一个完整不到 5 MB 的本地 AI 长篇小说创作工具

[开源自荐] 做了一个完整不到 5 MB 的本地 AI 长篇小说创作工具

xianii 2026-09-11 18:02 1

最近一直在维护一个开源项目：Show Me The Story


GitHub：https://github.com/Nigh/show-me-the-story


它是一个用于 AI 长篇小说创作 的本地应用。和单纯的「输入 Prompt → 生成一段文字」不同，我更希望它能覆盖真正写一部长篇小说时需要的完整流程：



  • 故事设定、人物、世界观和关系管理

  • 分批规划章节大纲

  • 逐章生成、审阅和修改正文

  • 段落级定向修改

  • 已发生事实与设定变化的记录

  • 伏笔跟踪

  • 长篇一致性检查

  • 全文校对

  • 导入已有作品并继续创作

  • 最终导出与项目备份


模型方面没有绑定特定厂商，只需要配置一个 OpenAI-compatible API，可以自己选择模型和服务商。


一个我自己比较喜欢的地方：整个程序不到 5 MB


这个项目没有 Electron ，也不需要额外安装 Node 、Python 、数据库或者其他运行时。


前端使用 Svelte ，后端使用 Go ，构建时把 Web UI 和内置资源全部嵌入可执行文件。


最终就是一个：



不到 5 MB 的单一可执行文件



下载、解压、运行，然后浏览器打开本地地址就可以使用。


项目数据也直接保存在本地目录里，不依赖云端账号系统。


我一直比较喜欢这种「一个文件就是一个完整应用」的发布方式，所以即使现在功能已经比较完整，也一直尽量控制依赖和体积。


为什么做这个项目


最开始是觉得目前很多 AI 写作工具比较擅长生成某一段文字，但一旦篇幅变成长篇，问题就开始出现：


角色信息越来越多、设定会变化、前文发生过什么需要记忆，还有伏笔、长期剧情方向、章节之间的衔接等等。


所以这个项目现在更像一个围绕长篇创作搭起来的工作台，而不是简单套一层聊天界面。


基本工作流大概是：


设定故事

  ↓

规划一批章节

  ↓

生成章节

  ↓

人工审阅 / 修改

  ↓

确认事实、设定变化和伏笔

  ↓

继续下一章 / 下一批章节

  ↓

最终校对和导出

人仍然负责决定故事往哪里走，AI 主要承担规划辅助、正文生成、检查和修改这些重复工作。


技术栈


后端：


Go

前端：


Svelte

Vite

Tailwind CSS

DaisyUI

前端资源直接 embed 到 Go executable 中。


没有独立数据库服务，也没有额外 runtime 。


当前状态和一些还没做好的地方


项目现在已经可以完整走通从建立故事、规划大纲、逐章创作，到校对和导出的流程，不过目前也还有一些比较明显的不足。


其中一个是 完全依靠 AI 会话来进行创作的体验还不够流畅。


项目里已经有 Assistant / 会话能力，但现阶段我更建议把它当成辅助入口，而不是主创作界面。真正写长篇时，设定、规划、写作、修改、事实确认、伏笔管理这些步骤最好还是走工作台里的对应流程。


原因也很简单：长篇创作有很多结构化状态需要维护，如果全部塞进一个连续会话里，目前不管是交互还是上下文管理，都没有工作台模式稳定。


这个方向之后还会继续优化，但现阶段项目的核心仍然是：



AI 辅助的结构化长篇创作工作台，而不是一个“和 AI 聊天就自动写完小说”的聊天机器人。



另外一个比较现实的问题是——开发和测试这个东西还挺烧 Token 的。


我现在每次测试完整体验，通常不会只生成两三章看看有没有报错，而是真的从头走一遍流程，至少写一个 12 章左右的小故事。


大纲、正文、修改、事实提取、校对这些流程全跑下来，一轮测试经常就要花掉十几、二十块的 Token 钱。


所以现在每次准备做比较大的流程改动时，除了想：



“这个功能会不会坏？”



还会顺便想一下：



“这次回归测试又要烧多少钱……”



不过反过来说，这也逼着我尽量用真实的长篇工作流来测试，而不是只验证几个孤立的 Prompt 。


当前状态


项目目前还在持续开发和维护，已经可以完整走通从建立故事到长篇写作、校对和导出的流程。


支持 Windows / Linux 等平台，项目本身是 MIT License 。


GitHub：


https://github.com/Nigh/show-me-the-story


Release：


https://github.com/Nigh/show-me-the-story/releases


README 里面有界面截图和完整使用说明。



也想听听 V 友的意见，尤其是：



  1. 对这种 本地 + BYO API 的 AI 应用形态有没有什么明显痛点？

  2. 长篇 AI 写作还有哪些功能是实际使用时比较关键，但现在容易被忽略的？

  3. 对于这种 Go + embedded Web UI 的单文件应用，有没有什么进一步值得优化的地方？


如果有人真的拿它写过比较长的内容，也很欢迎反馈在长上下文、一致性或者工作流上遇到的问题。

最新回复 (4)
  • codehz 09-11 20:59
    1楼
    我选择直接做成一个 agent ，现在 ai 都往 agent 方向发展，为什么不直接白嫖 agent 能力呢（固定的流程只能一开始设计好，后期调整空间有限，用 agent 的话，只要工具调用设计完，就基本无限可扩展了），将创意性内容交给特定的子代理来写，主代理就负责做 orchestrator ，就可以基本解决当前 ai agent 能力越强，创意写作能力越差的问题
    https://v2ex.com/i/BFOqjkdZ.png
  • xianii 楼主 09-12 00:46
    2楼
    @codehz 这个方向其实我也认同，而且项目目前已经有一个 AI 会话窗口，后面也有计划 fork 一版，尝试以 AI 会话 / Agent 为主导的创作流程。

    现在这个版本还是刻意选择了工作台优先。主要考虑不是 Agent 做不到，而是我希望先保留足够强的可观测性、可控性和人工介入空间。

    长篇写作里很多状态其实比较适合显式暴露出来，比如人物设定、世界观、章节规划、已发生事实、伏笔、设定变更、当前章节状态等。工作台模式下，用户可以明确看到 AI 现在在依据什么、修改什么，也可以在每个阶段介入，而不是把大量状态隐含在 Agent 的 context / memory / tool calls 里。

    Agent 方案的扩展性确实更好，我也比较看好类似你说的这种结构：

    主 Agent 做 orchestrator → 调用规划、检索、状态管理等工具 → 再把具体创意写作交给专门的子 Agent / 模型。

    所以我现在更倾向于把这两种模式看成两层：底层先把长篇写作需要的状态和工具能力做完整、做稳定；上层既可以是现在这种显式工作台，也可以以后再套一个 Agent ，让它自动操作这些工具。

    这样 Agent 能力越来越强的时候可以直接吃到收益，但用户如果想手动控制，也不会只能去翻 Agent 的 log

    至于最后会不会变成 Agent-first ，我觉得很可能会，只是现阶段我更想先把“可控的长篇写作系统”这层打稳。
  • NLL 09-12 08:55
    3楼
    @codehz 请教下这个是用的哪个 IDE ？
  • codehz 09-12 09:33
    4楼
    @NLL 完全自制的，只是抄了 vsc 的 UI repo:codehz/NovelEvolver 虽然体积上大概是没救了
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐