- xianii2026-09-11
最近一直在维护一个开源项目：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 的单文件应用，有没有什么进一步值得优化的地方？
如果有人真的拿它写过比较长的内容，也很欢迎反馈在长上下文、一致性或者工作流上遇到的问题。
主楼 - codehz2026-09-11
我选择直接做成一个 agent ，现在 ai 都往 agent 方向发展，为什么不直接白嫖 agent 能力呢（固定的流程只能一开始设计好，后期调整空间有限，用 agent 的话，只要工具调用设计完，就基本无限可扩展了），将创意性内容交给特定的子代理来写，主代理就负责做 orchestrator ，就可以基本解决当前 ai agent 能力越强，创意写作能力越差的问题
https://v2ex.com/i/BFOqjkdZ.png - xianii2026-09-12
@codehz 这个方向其实我也认同，而且项目目前已经有一个 AI 会话窗口，后面也有计划 fork 一版，尝试以 AI 会话 / Agent 为主导的创作流程。
现在这个版本还是刻意选择了工作台优先。主要考虑不是 Agent 做不到，而是我希望先保留足够强的可观测性、可控性和人工介入空间。
长篇写作里很多状态其实比较适合显式暴露出来，比如人物设定、世界观、章节规划、已发生事实、伏笔、设定变更、当前章节状态等。工作台模式下，用户可以明确看到 AI 现在在依据什么、修改什么，也可以在每个阶段介入，而不是把大量状态隐含在 Agent 的 context / memory / tool calls 里。
Agent 方案的扩展性确实更好，我也比较看好类似你说的这种结构：
主 Agent 做 orchestrator → 调用规划、检索、状态管理等工具 → 再把具体创意写作交给专门的子 Agent / 模型。
所以我现在更倾向于把这两种模式看成两层：底层先把长篇写作需要的状态和工具能力做完整、做稳定；上层既可以是现在这种显式工作台，也可以以后再套一个 Agent ，让它自动操作这些工具。
这样 Agent 能力越来越强的时候可以直接吃到收益，但用户如果想手动控制，也不会只能去翻 Agent 的 log
至于最后会不会变成 Agent-first ，我觉得很可能会，只是现阶段我更想先把“可控的长篇写作系统”这层打稳。
- NLL2026-09-12
- codehz2026-09-12