最近一直在维护一个开源项目：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 友的意见，尤其是：
- 对这种 本地 + BYO API 的 AI 应用形态有没有什么明显痛点？
- 长篇 AI 写作还有哪些功能是实际使用时比较关键，但现在容易被忽略的？
- 对于这种 Go + embedded Web UI 的单文件应用，有没有什么进一步值得优化的地方？
如果有人真的拿它写过比较长的内容，也很欢迎反馈在长上下文、一致性或者工作流上遇到的问题。
Select Language