StoryForge · 故事熔炉

写出故事，也走进故事。

简体中文 · English · Français · Deutsch · Italiano · Español · Português · 日本語 · 한국어

教程与交流： B 站视频教程 · 知乎专栏 · QQ 交流群：1082374587 · 更多联系方式

开源、本地优先的 AI 叙事创作与体验工具。创作长短篇小说，将小说改编成剧本或漫画；也可以派生世界，制作跑团等互动体验。

开始创作 · 体验《雾港》 · 查看技术架构

长篇、短篇、剧本、漫画和世界引擎提供正式入口；节点与互动产品为预览。README 提供九种语言；界面及关联文档的语言覆盖请以实际内容为准。

先体验一个故事

《雾港：失潮钟声》· 无需 API 的内置作品

启动项目后，在首页点击 雾港：失潮钟声，或打开本地站点的 /storyforge/play/mist-harbor。选择视觉小说或文字冒险，点击“开始故事”即可游玩，不需要模型 API。

恢复自原路演故事，包含 18 个叙事节点、158 个节拍、三条结局，以及 17 项原版背景、立绘和 CG。文字冒险可观察、交谈、取证；视觉小说可逐句阅读、选择分支并保存舞台进度。首次开始会创建独立的雾港世界与产品发布，已有项目保持原样；“继续游玩”恢复进度，“从头开始”另建存档。完整项目备份包含剧本、产品媒资与存档。

这是预写的内置作品，无运行时模型对话或配音；不代表通用文字游戏生成能力已完成。原稿可从作品页进入世界工作区查看，修改原稿不会自动改写已发布游戏。

《雾港：最后一盏灯》· 原创跑团社区预览

今夜的归航，十年前的真相。最后一盏潮灯即将熄灭，你与同伴需要调查旧海难，为今夜归航的人选择一条出路。

!跑团作品页：《雾港：最后一盏灯》的开局入口

由 AI KP 主持，你与同伴调查旧海难、寻找线索并决定结局。游戏包随仓库提供，配置自己的模型 API 后即可开始。上图展示实际试玩入口。

体验过程： 提出行动 → 规则结算 → KP 回应 → 查看线索 → 保存并继续。

运行与模型配置 · 玩家说明 · 真实制作及试玩记录

为什么选择 StoryForge

• 长篇有可追溯的记忆。 原文、事实、摘要和按需检索帮助找回早期伏笔；章后整理让已确认的变化进入后续创作。了解长篇
• 每种作品都有专用生产流程。 短篇有篇幅与成稿检查，剧本保留改编依据，漫画分别管理页格、画面与排字。了解独立创作产品
• AI 生成由你掌控。 正式创作先产出候选，作者确认后写回；Harness 提供版本保护、运行证据与恢复机制。查看架构与测试证据

快速开始

版本说明：界面与操作路径于 2026-09-15 更新为当前青绿 UI。长篇、短篇、剧本、漫画和世界引擎已提供正式入口；文字冒险和文字开放世界仍在开发；在线服务与各产品专项能力以页面说明为准。旧 Release 是固定版本，不包含后续主干全部功能；在线站点可能有部署时差。体验本文新功能，推荐使用最新主干源码。

在线打开

访问 StoryForge 在线版。当前源码以新版青绿 UI 为正式入口，各产品在自己的页面内创建与管理作品；首页「示例作品」提供已有作品的阅读与体验。文字冒险和文字开放世界仍标注为开发中、非正式功能。

核心本地创作无需注册 StoryForge 账号；AI 生成需要你配置模型服务。第一次使用可以先手工创建作品、填写设定，再接入 AI。

如在线版与本文界面不同，或模型接口受浏览器跨域限制，请使用下面的本地方式。网站和本地地址拥有各自的浏览器数据，切换前请先导出备份。

本地运行

推荐 Node.js 24（与 CI 一致）和 npm。Windows、macOS、Linux 都可通过源码运行。

git clone https://github.com/yuanbw2025/storyforge.git
cd storyforge
npm ci
npm run dev

打开终端显示的地址，应用路径为 /storyforge/。例如默认端口可用时是 http://localhost:5173/storyforge/；端口被占用时以终端输出为准。使用期间保持终端运行，退出时按 Ctrl+C。

不使用 Git 也可以下载最新 main 源码 ZIP，解压后在项目目录运行 npm ci 和 npm run dev。

已发布版本与更新说明用于查看固定历史版本。源码 ZIP 需要上述运行步骤，不是双击安装包。

第一次接入 AI

1. 点击首页右上角 “模型与本地设置”，或在长篇工作区左侧进入 “设置”。
2. 选择服务商，填写自己的 API Key、Base URL 和模型名称；模型需在你的账户中实际可调用。
3. 使用连接测试检查配置，再以一次小规模生成验证任务效果。连接成功不代表余额、输出长度和所有任务能力都已满足。
4. 出现跨域错误时，按设置页提示使用本地代理。不要把 API Key 填进作品简介、提示词或公开反馈。

从你的目标开始

!StoryForge 当前首页：独立作品、世界引擎和互动体验入口

| 你想做什么 | 从哪里进入 | 你能得到什么 | |---|---|---| | 写长篇小说、网文或系列故事 | 长篇 → 作品库 → 新建长篇 | 从设定、角色、卷章大纲到正文，并持续管理伏笔、事实和角色状态 | | 完成一篇结构紧凑的故事 | 短篇 → 作品库 → 新建短篇 | 故事设计、章节卡、逐章创作、审校与成稿导出 | | 把已有小说改成剧本 | 剧本 → 作品库 | 来源分析、改编规划、场景写作与 Fountain / FDX / 打印导出 | | 把已有小说改成漫画 | 漫画 → 作品库 | 分页、分镜、角色视觉资料、图像与排字、分镜版或视觉版导出 | | 搭建可复用的故事世界 | 世界引擎 → 我的世界 → 新建世界 | 独立设定、角色与规则；确认后封存为可引用的世界版本 | | 自由组合长篇创作步骤 | 长篇 → 长篇工作台 → 节点创作 | 在可视节点中连接资料与生成动作，复用长篇的数据与能力 | | 先玩一段现成的故事 | 跑团 → 作品库 / 游玩 | 《雾港：最后一盏灯》：AI KP、调查、同伴、秘密与结局选择 | | 制作角色互动或文字游戏 | 角色聊天 / AI 小镇 / AVG；文字冒险与开放世界开发中 | 基于已封存世界制作自己的独立体验，按各产品成熟度试用 |

只写小说不需要先建立世界引擎。 长篇和短篇可以在作者确认后派生世界；剧本、漫画有各自独立的改编流程。游玩已提供的跑团作品也不需要先制作世界。

第一次创作

!长篇作品库：在产品自己的页面创建作品

以长篇为例，你可以这样完成第一轮：

1. 创建作品：顶部进入“长篇”，在作品库点击“新建长篇”，输入名称。项目文件夹可以稍后设置。
2. 说明想写什么：在长篇工作台的“作品概况”“灵感与参考”“故事设计”中整理目标、参考和要求。只填这次创作需要的内容，不必先填满全部设定。
3. 建立故事骨架：在“故事设计”“角色设计”中确定冲突、人物和动机，再进入“大纲”安排卷与章节。可以手写，也可以请求 AI 候选后修改和确认。
4. 写第一章：进入“章节”，从大纲和细纲推进正文，使用生成、续写或编辑工具。先看候选，再决定是否采纳。
5. 整理后续影响：检查本章带来的事实、人物状态、关系和伏笔变化，确认需要保留的内容，为下一章准备依据。
6. 带走作品：进入“版本与导出”，用 Markdown / TXT 导出正文，用 JSON 保存完整备份。

StoryForge 为创作多做了什么

故事变长后，需要找回很久以前的伏笔；小说变成剧本，需要重新安排冲突与场次；漫画有了漂亮画面，还需要正确的阅读顺序、对白和连续性。StoryForge 围绕这些具体问题，为不同产品建立了各自的生产流程，并共享可追溯、可恢复的 AI 执行底座。

长篇与节点

从设定到正文的分步骤创作

!分步骤长篇：设定导航、卷章结构与可编辑大纲

长篇工作区把创作过程中需要反复查看的内容放在一起：

| 创作环节 | 主要工具 | 对作者的帮助 | |---|---|---| | 构思与资料 | 灵感反推、项目参考、文档解析、资料与检索库 | 把零散想法和参考资料转成后续创作依据 | | 世界与背景 | 世界起源、自然/人文环境、历史年表、世界地图、重要地点 | 管理作品内部的设定与空间关系 | | 故事与人物 | 故事设计、主支线、角色生成与档案、关系网、角色驱动 | 让人物动机、冲突和情节规划相互关联 | | 大纲与写作 | 卷纲、章纲、细纲、章节编辑、续写、扩写、重写、润色 | 在整体规划与逐章写作之间来回调整 | | 连续性管理 | 伏笔、事实库、状态表、物品栏、故事年表、章后整理 | 跟踪写过的事实与变化，减少长篇中的遗漏和冲突 | | 风格与控制 | 文风学习、创作规则、提示词库、上下文查看、AI 对话副驾 | 明确自己的写作要求，检查并决定 AI 的输入与结果 | | 保存与恢复 | 自动保存、版本历史、完整备份、本地记忆工作区 | 保留作品与创作过程，便于备份和继续工作 |

长篇记忆：早期线索有依据，后续变化有去向

为跨章连续性建立四层资料链。 正文保留原始证据，事实、人物关系、事件与主支线保存结构化状态，章节/卷/全局摘要帮助定位，检索索引负责找回相关片段。生成任务通过 Context Gateway 先查目录、再按需读取细节，并记录实际使用的来源。摘要与索引会核对原文内容指纹；过期或缺失时保留原文回查路径。

例如写到后半部再次出现一件旧物时，检索链可以定位前文记载，再读取原文核对持有者、约定和出现时间。作品作用域与章节时间边界也参与过滤，减少混入其他作品内容或提前泄露后续情节的风险。作者可检查取到了哪些依据、还缺哪些内容。

为“写完一章之后怎么办”建立确认流程。 正文采纳后，章后整理提出事实、人物状态、关系、物品、年表、伏笔与主支线等变化候选，再由作者确认。主支线偏差与设定变化进入未来影响分析：已确认历史保持稳定，需要调整的后续规划标记为待处理，作者决定如何修订。

例如你提前揭开了一个秘密，可以检查哪些未来章纲和伏笔安排需要调整，再逐项处理。生成、修改与正式写回都有版本检查；等待确认期间原文发生变化，旧候选会被拦截，避免覆盖刚完成的编辑。

实现入口：长篇检索、章后整理、长篇产品契约与验收边界。

长篇已完成当前工程主链与 10 万 / 30 万 / 100 万字符规模验证。它证明数据与检索链路具备工程扩展基础；实际文学质量、长程一致性与费用仍取决于作品、模型和作者审校，不能理解为“一键生成百万字精品”。

节点创作：把长篇流程摆在画布上

节点模式用于查看、拆解和组合中间产物：连接资料、生成步骤和后续处理，检查每一步的输入输出。官方节点动作绑定长篇的正式领域 Skill，沿用同一份作品、上下文和候选采纳机制；开发者扩展节点时也沿用这些边界。

这种架构让“标准步骤”与“自由编排”可以共享能力：作者可围绕角色、场景或章节组织更细的工作流，某个正式生成动作的质量改进也能供两种入口复用。实验节点的草稿不能直接采纳为正式作品内容。

当前为预览，完整跨模式互操作仍在持续验证。日常写作可从分步骤模式开始，熟悉后再探索节点工作流。

短篇、剧本与漫画

三种产品在“新建”中各有入口，拥有自己的作品结构、审校和导出方式。

短篇小说

面向 5,000～25,000 字、3～8 章的独立故事，为短篇单独实现了创作要求、故事设计、章节规划、正文、全篇审校与定向重写的生产链。

• 把篇幅目标变成完成条件。 创作要求与故事设计先确认，再逐章生成、编辑和采纳。完成检查读取实际正文长度、章节卡与正文完整性，显示与目标字数的偏差，帮助作者控制短篇规模。
• 让审校意见落到原文。 问题带有章节和证据，重写针对具体章节；审校记录绑定本次手稿的内容指纹。正文改动后需要重新审校，避免拿旧报告给新稿盖章。
• 保留可交付的定稿。 缺失章节、待处理候选和未解决的严重问题会阻止发布。通过检查后新增冻结作品版本，后续继续修订可保留原版，导出 Markdown、TXT、JSON。

小说转剧本

从本地小说选择来源后，系统冻结本次改编的内容与范围，再把原文组织成可追踪的事实、因果关系和改编决定，逐步推进到节拍、场景卡和场景正文。

• 把改编选择保存成独立资料。 关键事实、人物动机与因果关系关联原文，删改决定继续关联后面的节拍和场景。作者可以检查一次人物合并或事件删减的依据，再判断是否接受。
• 用结构化剧本组织场景。 场景正文采用 AST（结构化语法树）表示剧本块，配合场景卡管理动作和对白。格式由代码校验，同一份结构可导出 Fountain、FDX 或打印版本，便于继续编剧工作。
• 把忠实度与戏剧性分开审。 来源忠实度审查和戏剧结构审查分别记录问题；修订补丁指定场景、问题和预期版本。已锁定场景需先解锁，过期修订无法直接写入，作者可以逐场改进而保留其余内容。

实现入口：剧本生产与定向修订、版本封存、格式渲染。

小说转漫画

漫画采用分阶段生产：先把小说转成漫画脚本、节拍、分页和页格，再制作视觉素材与排字。作者可以在花费生图费用之前，先检查故事是否适合这样分镜。

• 把阅读顺序写进数据结构。 页与格有稳定标识、布局和显式阅读链，保存镜头、动作、对白及来源关联。系统检查阅读顺序和页格结构，叙事审查再检查节奏与信息表达，问题可以定位到具体一页或一格。
• 为角色与场景建立视觉档案。 人物、地点、道具有稳定身份、特征和选定参考素材；图片候选记录服务商、请求与实际参考图传输证据。作者可追踪一张图的来源，并为不合适的格子重新选图或生成。
• 把画面与文字分层制作。 生图请求为对白区域留空间；气泡、旁白和拟声由本地 SVG 排字层渲染，可独立修改文字、字体和位置。对白错字无需重画整格，检查器会提示文字容量、重叠与边界问题；画面遮挡仍需作者审看。
• 分别交付分镜版与视觉版。 两种版本有各自的完成检查；视觉版还检查选定图片和实际二进制内容。发布版本保留对图片 Blob 的强引用，避免仅因工作稿换图就丢失旧版媒资；通过对应检查后可导出 PNG、WebP、CBZ 或 PDF。

实现入口：漫画生产、媒资与生成证据、本地排字、双版本质量检查。

以上三个产品已完成当前主干的工程闭环，内容质量和不同服务商的实际效果仍持续评测。各格式的具体适用条件以产品工作台为准。

世界与互动体验

世界引擎用于把设定、角色、关系与规则整理成可以被重复引用的世界。你可以从零构建，也可以由长篇或短篇显式派生；封存后，互动产品使用确定的世界版本。

flowchart LR
  A[长篇小说] -->|作者选择派生| W[世界草稿]
  B[短篇小说] -->|作者选择派生| W
  C[从零构建世界] --> W
  W -->|确认并封存| V[世界版本]
  V --> P[在具体产品中配置并开始制作]
  P --> R[发布作品并游玩]
  N[小说来源] --> S[独立剧本改编]
  N --> M[独立漫画改编]

小说本身就是完整作品；派生世界是可选的下一步。原作品的后续修改不会自动同步到派生世界，游戏进度也不会自动改写共享世界。

世界引擎：让故事资产可以稳定复用

我们为世界建立了独立身份、来源记录和不可变版本。 从小说派生时保存作者选定的内容范围、作品版本与内容指纹；封存时只收集设定、人物、关系等语义内容。图片、剧本成品和游戏存档由各产品自己管理。

不同产品按自己的需要读世界。 跑团需要规则和秘密，角色聊天需要人物与关系，小镇需要居民和地点。各产品声明必读、选读与禁止读取的内容，在开始制作前冻结来源计划（SourcePlan）；通过 describe / search / read 逐步读取，并留下每次读取记录和最终来源清单（SourceManifest）。这些记录把“计划使用什么”和“实际使用了什么”关联起来。

这让作者可以用世界第一版发布一场跑团，同时继续编辑第二版设定。已有游戏仍引用第一版，另一部作品可以明确选择新版本；开发者也能接入新的叙事产品，而无需让它直接遍历世界引擎的内部数据库。

实现入口：世界版本读取接口、世界引擎契约。

互动产品：为不同体验建立专用运行机制

以下机制已经进入当前主干实现；各产品仍为预览，工程结构与完整体验的验收进度分别列出。

| 产品 | 已实现的具体机制 | 带来的体验价值与当前边界 | |---|---|---| | 跑团 / AI KP | 规则包、骰点与效果结算；KP、玩家与 NPC 的上下文分工；秘密按接收者过滤；事件记录、检查点与分支 | 判定有证据，角色按可知信息行动，暂停后可继续。《雾港》已有实际模型制作与试玩记录；公共联网多人未部署 | | 角色聊天 | 冻结角色档案与语气规则；场景目标；承诺、秘密、冲突等分类记忆；信任、亲近、戒备、尊重等关系状态 | 对话可以留下后续可用的记忆与关系变化，各会话独立保存；长期角色表现仍需持续验收 | | 后日谈 AI 小镇 | 六时段日程、地点开放与移动规则；居民各自的知识、对话记忆和关系；轻经营、离线时间补算、事件回放与检查点 | 作者能观察原作结局之后角色在哪里生活、遇到谁、发生了什么；已有 14 天回放验证，长期模型与非测试媒资质量仍在验证 | | 文字冒险 | 行动前置条件、背包与资源、能力和状态、任务目标；阈值、随机或资源支付判定；效果与奖励结算 | 获得钥匙、消耗资源、完成目标能改变后续可做的行动；完整体验按具体作品继续验证 | | AVG | 剧情节拍绑定声明式演出指令；背景、角色、音频分层；媒资引用校验与舞台快照 | 作者能把某句对白与立绘、背景、声音对应起来，恢复时重建演出状态；完整视听交付仍需验收 | | 文字开放世界 | 地区与旅行路径、资源和势力影响、角色日程、任务卡与模板、时间推进和区域变化传播 | 探索与任务可以关联持续变化的地区状态；完整生产流程和长期游玩质量仍在建设 |

以跑团的秘密为例，系统区分主持人掌握的事实和玩家已得知的信息，按接收者组织上下文；规则允许的状态变化再通过事件写入存档。小镇则按居民日程与可知信息组织生活过程。这些机制为“角色为什么知道这件事、这次行动改变了什么”提供了可检查的依据。

实现入口：跑团信息边界、角色互动、小镇、文字冒险、AVG 演出、开放世界。

在线社区、交易与全平台商业服务仍是后续方向。最新逐项状态见能力基线；界面入口及预览标记由产品目录控制。

共享技术底座

项目架构：独立产品，共享受治理的 AI 执行能力

不同产品有各自的领域服务、章节、场景、页格或运行状态。Harness 是模型调用外围的执行与校验系统：它负责记录一次任务的约定、实际输入、候选、版本、检查点与结果，再把这些证据连接到作品数据。

flowchart TB
  subgraph PRODUCTS["产品层 · 各自的领域服务与数据所有权"]
    L["长篇 / 节点"]
    C["短篇 / 剧本 / 漫画"]
    W["世界引擎"]
    I["跑团 / 角色聊天 / 小镇 / 文字游戏"]
  end
  L & C & W & I --> H["共享 Harness · 正式 AI 任务<br/>Skill + Run Contract · 预算 · 版本 · 恢复"]
  H --> G["Context Gateway / 记忆<br/>登记来源 · 按需读取 · 原文溯源"]
  H --> M["模型适配器<br/>生成候选 · 返回原始响应"]
  H --> A["正式创作采纳<br/>作者确认 · 校验 · adopt"]
  H -.-> E["持久化运行账本<br/>事件 · 检查点 · 验收回执"]
  G -->|"作用域内读取"| D["本地数据与文件<br/>IndexedDB / 文件与媒资存储<br/>PROJECT_TABLES 治理生命周期"]
  A -->|"事务写入与回读"| D
  E --> D
  classDef engine fill:#e8f0fa,stroke:#5279a4,color:#18324f
  classDef author fill:#fff2df,stroke:#b58a45,color:#593b16
  classDef data fill:#eaf4ee,stroke:#628b73,color:#254a34
  class H,M,E engine
  class A author
  class G,D data

图中箭头表示依赖或数据访问，Harness 下方各模块并非执行顺序。长篇和短篇独立创作，不以世界引擎为前置；互动运行按产品命令与状态机推进，媒资和存档归各产品。下面以正式长篇创作说明执行顺序。

Harness 如何维护长期一致性

长期一致性依赖“依据可回查、变化经确认、下一步读到正确版本”的持续循环。 一章的生成只是其中一次运行；跨章记忆、审校、写回和未来规划共同构成闭环。

flowchart TB
  K["已确认资料<br/>原文 / 事实 / 状态 / 伏笔"]
  K --> R["1. 冻结任务与按需读取<br/>记录作用域、时间、版本与缺失"]
  R --> C["2. 生成并检查候选<br/>结构 / 信息边界 / 按需语义审查"]
  C --> A["3. 作者确认与版本检查<br/>采纳 → 回读 → 验收回执"]
  A --> P["4. 章后整理与未来影响<br/>提出变化 → 作者确认"]
  P -->|"更新资料与索引 · 供后续章节使用"| K
  R -. "必需证据不足" .-> X["暂停 / 拒绝写回<br/>保留证据，等待处理"]
  A -. "来源或目标已过期" .-> X
  classDef engine fill:#e8f0fa,stroke:#5279a4,color:#18324f
  classDef author fill:#fff2df,stroke:#b58a45,color:#593b16
  classDef data fill:#eaf4ee,stroke:#628b73,color:#254a34
  classDef paused fill:#f7eaea,stroke:#b27a7a,color:#6a3030
  class R,C engine
  class A,P author
  class K data
  class X paused

每个正式运行另有持久化账本与检查点；章后整理和未来修订由独立、有限的运行承接，也需要各自的版本检查与确认。图中的循环可以跨多次创作会话完成。

| 一致性问题 | Harness 与领域机制如何处理 | 给作者留下的依据 | |---|---|---| | 早期事实、伏笔被遗忘 | 结构化事实、分层摘要与长尾检索定位证据，再核对原文；必需来源不足时阻止继续 | Context Manifest 记录来源、内容指纹、实际读取与缺失 | | 引入错误作品或过早知道后文 | 按作品/世界作用域与任务时间边界过滤来源，并检查信息边界 | 可检查的来源范围与边界证据 | | 生成期间作者修改了设定 | 采纳前复查关键上下文与目标 revision；旧候选标记 stale，不能直接覆盖 | 候选绑定的输入版本、过期原因与原始输出 | | 写入成功但后续没有承接 | adopt() 后回读实际状态；章后整理连接记忆、检索与故事线，未来影响候选由作者处理 | 写回事件、post-state、后续运行关联与验收回执 | | 审校结论落后于手稿 | 显式一致性审计绑定正文 hash；正文变化使旧审计凭据失效 | 可恢复的审计候选、所用来源与问题记录 | | 刷新或中断打断创作链 | 从已验证检查点恢复并复查版本；已保存候选可复用，结果未知的外部请求不盲目重发 | run / attempt / checkpoint 与失败或完成记录 |

例如，第 8 章确定某件信物只能由一人持有，第 80 章又要用到它：检索提供原文和已确认的归属状态，当前任务记录这些依据；如果你在候选生成后改了信物归属，版本检查会阻止旧候选直接采纳。采纳新章后，归属变化再进入章后整理，经确认供后续章节读取。这是机制示例；能否识别所有隐含矛盾，仍取决于审查能力和作者判断。

可以检查哪些证据

架构图概括代码分工，回归测试检验具体承诺。以下入口覆盖成功路径和故障反例，可在仓库中查看和运行：

| 需要验证的承诺 | 源码或回归测试 | |---|---| | 10 万 / 30 万 / 100 万字符下召回远中近证据，并隔离未来和错误世界 | 长篇规模门 | | 必需证据缺失时停止；精确编辑目标不能退化为截取前缀 | Gateway 执行与缺失检查 | | 正文或上游设定变化后，旧候选不能覆盖作者编辑 | 正文采纳与版本反例 | | 章后候选中断后恢复，已有候选无需再次调用模型 | 章后整理与恢复 | | 一致性审计随正文变化失效，结果未知时不自动重试 | 显式一致性审计 | | 已写历史保持稳定，上游变化使旧未来计划失效 | 未来演化边界 |

深入实现：正式正文运行、验收回执结构、架构总览、Harness 质量标准。

保障范围： 版本、作用域、结构、状态转换和写回规则由确定性代码检查；语义审查按任务配置或作者触发，隐喻、潜台词、未登记伏笔与文学效果仍需要模型和作者判断。规模测试使用工程夹具，不能等同于真实百万字小说已达到文学一致性。恢复覆盖已持久化的状态；辅助或实验入口按自己的登记边界执行，不自动拥有图中的完整链路。

模型与费用

StoryForge 使用你自己的模型服务，API 费用由相应服务商收取。开源代码和本地数据管理不意味着云端生成免费。

| 接入方式 | 设置页提供的选项 | |---|---| | 云端文本服务 | DeepSeek、通义千问、豆包、MiniMax、智谱、文心、Kimi、OpenAI、Claude、Gemini 等 | | 聚合与兼容接口 | Poe、NVIDIA NIM、魔搭等预设，以及自定义 Base URL | | 本地模型 | Ollama、LM Studio 等本地兼容服务 | | 图像与其他媒资 | 在具体产品中配置对应 provider；与文本生成能力分别验证 |

这些是当前接入选项，不是每个模型都已通过所有产品的效果测试。模型名称、可用额度与能力以服务商账户为准。完整设置实现见 AIConfigPanel。

• 提示词可查看与调整：可使用提示词库、创作规则和补充要求来控制任务。
• 上下文按任务组织：从作品设定、角色、大纲、正文与记忆等来源选取；可检查上下文和运行证据。
• 费用可观察：通过消耗统计了解调用；先用小任务验证，再扩大篇幅。
• 本地模型取决于设备与模型能力：不需要购买某个指定云服务，但复杂规划、结构化输出和生成速度可能存在差异。

备份与隐私

!数据管理：完整备份、正文导出和本地工作区

| 数据与操作 | 保存位置或去向 | |---|---| | 作品、设定与本地存档 | 当前站点地址下的浏览器 IndexedDB | | 模型 API Key | 默认仅本次浏览器会话；明确勾选“在本机记住”后写入 localStorage | | 云端 AI 请求 | 当前任务所需内容发送到你配置的模型服务 | | 本地模型请求 | 发送到你配置的本地服务地址 | | JSON 备份、正文导出 | 下载到你选择的位置；正文导出不能替代完整备份 | | 本地记忆工作区 | 用户授权的文件夹；按界面手动核对和确认读写 | | 可选 GitHub Gist 备份 | 完整项目 JSON 上传至自己的私密 Gist；它不是端到端加密存储 |

第一次创作后就做一次 JSON 备份。 在长篇工作区打开“数据管理 → 导出 / 导入 → 导出 JSON”。换电脑、换域名、切换本地端口或清理浏览器数据前，先确认备份已保存；应用自动保存不等于跨设备同步。

本地文件夹的配置与恢复见本地记忆工作区指南。涉及漫画等媒资时，应使用对应产品和工作区提供的完整导出方式，不能仅备份正文。

常见问题

我必须会编程才能用吗？

在线版可以直接打开；本地源码版需要安装 Node.js 并运行几条命令。创作主要在界面中进行。旧视频的菜单可能与新版不同，请对照本页“第一次创作”。

为什么下载 Release 后没有这里的新功能？

Release 对应发布当时的固定代码。本文描述当前主干，使用最新源码才能取得后续更新；运行中的版本号也包含提交标识，反馈时可以一起提供。

为什么模型连接失败，或测试成功却生成失败？

检查 API Key、账户额度、Base URL、模型访问权限与上下文限制。跨域问题按设置页提示使用本地代理。连接测试与实际创作任务不同；先读取错误说明，修正配置后再明确继续。

换浏览器以后为什么作品不见了？

本地数据属于特定浏览器配置和站点地址，localhost、127.0.0.1 与不同端口也不共享数据。回原地址查看，并通过完整备份迁移。

能不能只写小说，不碰世界引擎或游戏？

可以。长篇、短篇和两种改编产品独立成立。世界与互动路线是可选能力。

AI 会自动覆盖我的正文或设定吗？

正式创作流程先产生候选，由作者编辑、采纳或拒绝；涉及来源变化的旧候选会接受过期检查。重要调整前仍建议保存完整备份。

可不可以拿去商用？

仓库代码使用 MIT 许可；模型服务、第三方素材、原作授权与生成内容另按各自条款处理。代码开源许可不代替原作与素材授权。

交流与支持

| 入口 | 用途 | |---|---| | B 站项目视频说明书 | 历史视频教程，帮助了解分步骤创作；新版入口以当前界面为准 | | 知乎项目介绍 | 历史功能介绍与创作思路 | | 开发者知乎主页 | 项目与开发内容 | | 悬象 · 开发者项目主页 | StoryForge 与其他作品入口 | | QQ 交流群：1082374587 | 交流使用经验、反馈问题与分享创作 | | GitHub Issues | 可复现的问题、需求与改进建议 |

反馈时请提供：使用版本、浏览器/系统、具体操作、预期结果与实际结果；模型问题可附服务商和模型名称。分享截图或日志前移除 API Key、私密原文和个人信息。也欢迎展示自己愿意公开的作品片段与使用过程。

如果这个项目对你有帮助，欢迎 Star、分享教程、提交问题或参与贡献。

给开发者

StoryForge 使用 React、TypeScript、Vite、Zustand、TipTap 与 Dexie / IndexedDB。正式 AI 任务由 Agent Skill、运行契约与 durable Harness 管理上下文、候选、恢复和采纳。

| 工程入口 | 职责 | |---|---| | CONTEXT_SOURCES + assembleContext() | AI 从哪些登记来源读取内容 | | FIELD_REGISTRY + AdoptionSchema + adopt() | 候选如何校验并进入正式作品 | | PROJECT_TABLES | 数据的导出、导入、删除、作用域与生命周期 |

世界只保存可版本化的语义内容。跑团、聊天和游戏引用冻结版本，分别拥有自己的媒资、发布与运行数据；共享世界不会被一次游戏自动改写。

npm run ci       # 注册表、架构、文档、类型、覆盖率与生产构建
npm run ci:e2e   # 隔离快照中的浏览器用户路径

单独构建并预览：

npm run build
npm run preview

欢迎改进产品体验、模型兼容性、回归测试、文档、翻译和示例作品。贡献前阅读 AGENTS.md、贡献指南和协作流程；在独立分支工作，通过 PR 交付。

收藏趋势

图表由 GitHub stargazer 时间数据生成，每 15 分钟刷新至独立的 readme-assets 分支。维护方式见 star-history.yml。

自愿赞助

StoryForge 的全部功能与后续更新不会因是否赞助而有区别。赞助款主要用于缓解开发者的大模型订阅和项目维护成本，并帮助项目继续迭代。

感谢每一份支持。希望 StoryForge 能帮助更多人把脑海中的想法完成为真正的作品，再让作品中的世界获得被阅读、游玩、共同创造和持续演化的生命。

许可

代码使用 MIT License。第三方模型、素材与输出须遵守各自许可；TTRPG SRD 引用见 SRD 许可说明。