Labs · 网页开演
拖一本 txt，
当场演成视觉小说。
不是让 AI 重写你的书——是把书里已有的对话编排上舞台：谁在说话，名牌自动归位；场景自动切分； 台词打字机上屏，AUTO 三档速度自己演。零 AI 调用，一秒开演，原文一字不动。
把一本 txt 拖进来
或点击选择文件 · txt · UTF-8 / GBK / UTF-16 自动识别 · 最大 64MB
全程在你的浏览器里跑，书不离开你的设备。
手边没有 txt？拿公版书试
「谁在说话」是怎么判断的？
一套从我们 App 阅读器里移植出来的规则编译器。它按证据强度依次尝试：说话从句（「林夏说：」以及英文书的 「“…,” said Holmes」倒装）、承前省略的主语（红楼梦里大量的「宝玉便走近……因问：」）、 动作暗示（「她抬起头。“下雨了。”」），最后在两人对话里做严格门控的交替推断。 每一步都有守卫：「对秦朝说道」里的秦朝是听话的人，不是说话的人；「搂了宝玉道」里的宝玉是被搂的， 这些形态都会被排除。全部规则失败，台词进旁白——错归因的伤害大于漏归因，这是整套编译器的第一原则。 这套规则在一本 400 章的真实网文上按人工标注的真值验收过：15 组代表性段落，强归因零错认。
为什么是编译，不是生成
市面上「文字变视觉小说」的服务基本都在烧推理费：把你的文本喂给大模型，让它重新生成场景、立绘、分支。生成一次收一次钱，而且产物跟原文只有大概的关系。这个页面走另一条路——不生成任何新文字，只做结构分析：哪里换场景、哪句是台词、台词是谁的。纯规则，跑在你的浏览器里，所以免费、即时、可以反复开演，原文保证一字不动。
角色名单同样不靠猜：从全书说话从句里统计（一个名字要在主语位稳定出现两次以上），「宝玉」「贾宝玉」自动合并成一人，统计不到的你可以手动补。名单一变，重新开演立刻生效。
哪些书演不好
无引号的意识流、全程转述的第一人称——引语都不带说话从句的书，大部分台词会以旁白演出（内容不丢，但没有名牌）。我们的英文演示书福尔摩斯就是华生转述体，归因率只有一成左右，页面如实显示这个数字而不是藏起来。另外这是素演出：没有立绘、没有配乐、没有选择肢——那些属于 App 里的完整剧场形态。超过 10MB 的书，章节识别只扫前 400 万字；角色统计只扫前 150 万字，找齐主角够用了。
常见问题
为什么有的台词没有名牌、以旁白念出来？
这是刻意设计。规则编译器只在有说话从句证据时才挂名牌——「林夏说：」「“……”秦朝答道」这类形态。证据不足的引语宁可进旁白，也不硬猜：错挂一次名牌，读者对整场演出的信任就没了。我们在一本真实网文上人工标注过归因真值，这套规则的出口门是强归因精确率 100%，代价就是有一部分台词弃权。页面报告里的「归因率」如实显示这个比例。
我的书传到服务器了吗？
没有。解码、章节识别、角色发现、场景编译全部在你浏览器的一个后台线程里跑，页面不发出任何携带书内容的请求。断网状态下（页面加载完成后）一样能用。分享按钮分享的是工具链接或公版演示书的位置，不含你的书。
角色名单是 AI 猜的吗？
不是。名单从说话从句统计而来：一个名字要在「谁说道」的主语位上稳定出现至少两次才进名单，受话方（「对秦朝说道」里的秦朝）、代词、泛称（众人、有人）都会被排除。「宝玉」和「贾宝玉」这类同人异名会自动合并。统计错了可以在报告页手动删改，名单一改，演出立刻按新名单重排。
只有 epub 怎么办？
这一版只吃 txt。epub 是个 zip 容器，在浏览器里做一半的解包会给出比诚实拒绝更糟的结果。桌面阅读器（Calibre 等）都能把 epub 另存为 txt；反过来想把 txt 打包成 epub，站内的 epub 制书间可以做。
章节识别错了、或者整本书被当成一章？
章节规则与站内「txt 体检」工具同一套（生产导入器的移植）：第N章家族、数字标题、Chapter N、序章后记这些形态都认。一本书如果全无可识别的标题行，这里会按行数切成片段演出，并在报告里说明。想单独诊断章节问题，去 txt 体检页看完整报告。
跟 Foreverse App 里的剧场是什么关系？
同一套场景编译规则。网页版是素演出：无立绘、无配乐、演的是你书里已有的文字。App 里的剧场是完整形态——演到分岔处可以选走向，AI 从那一步现场续写成新分支，场景还能配图。网页版章尾的入口指向它。