为什么选 StoryLoom
写网文的人都知道，真正难的不是「写不出字」，而是写到第 30 万字，记不清第 5 万字埋的伏笔、对不上三个月前定的人物性格。StoryLoom（故事织机）就是为这件事而生的。
它解决什么问题
| 痛点 | 传统做法 | StoryLoom 的做法 |
|---|---|---|
| 卡文、断更焦虑 | 干瞪屏幕，或去翻别人的书找灵感 | AI 续写/扩写/卡文救场，先给一段草稿找回手感 |
| 人物前后崩坏 | 翻几十章回忆角色怎么说话 | Story Bible 角色卡随时调取，一致性守护检测矛盾 |
| 世界观自相矛盾 | 设定散落在脑子和草稿里 | 世界观词条 + 时间线集中管理，写作时一键引用 |
| 换 AI 平台要重配 | 每个工具各存一份 Key | 多供应商统一管理，配置可分享导入 |
| 把小说做成漫剧 | 重新找人画分镜、配音 | 角色卡预留一致性字段，分镜→出图→配音→成片一条链 |
设计哲学
1. 编排器，不是模型
StoryLoom 不自研模型。它是「编排器 + 工程管理 + 一致性资产层」：把你和云端大模型之间的协作流程管好，把角色、世界观、时间线这些「一致性资产」沉淀下来。算力走云端 API，你只为用到的 Token 付费。
2. 本地优先，数据是你的
- 小说稿件、角色卡、世界观全部存在本机 SQLite 数据库，断网也能写。
- 所有 AI 调用经 Rust 后端代理，前端 WebView 不直连云 API —— 既绕开跨域，又把 API Key 锁在本机。
- API Key 加密存储，绝不写进对话、不落明文文件。
3. 为「织成漫剧」埋好种子
网文的尽头之一是漫剧 / 有声书。StoryLoom 从写作阶段就在角色卡里预留 参考图 / seed / LoRA 字段——等你要把小说织成画面时，角色形象的一致性早已就位，不用从零对图。
与通用 AI 写作工具的区别
| 维度 | 通用 ChatBot / 网页版 | StoryLoom |
|---|---|---|
| 形态 | 浏览器对话框 | 本地桌面应用（Tauri） |
| 上下文 | 每次重新粘贴设定 | 角色/世界观持久化，自动引用 |
| 数据 | 在别人服务器 | 本机数据库，自己掌控 |
| Key | 网页托管或不可控 | 本机加密，Rust 代理 |
| 一致性 | 靠你自己记 | Story Bible + 一致性守护 |
| 长文 | 容易丢失结构 | 小说工程 + 章节管理 |
适合谁
- 连载中的网文作者：需要管理长篇结构、角色一致性。
- 多线并行的写手：同时开几个项目，各有独立的 Story Bible。
- 想把小说做成漫剧/有声书的创作者：提前沉淀一致性资产。
- 在意数据与 Key 安全的人：不想把稿子和密钥交给网页工具。