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