可移植性
导入与导出：故事应始终属于你
这又是一个关于我为什么如此喜欢浏览器和 Web 的故事。得益于它们的快速发展，到了 2026 年，同一个故事已经可以运行在浏览器、离线压缩包、Windows 和 macOS 应用中，而不需要维护几套彼此独立的游戏引擎。
在 2026 年 8 月导入与导出功能上线之前，Romergo 长期存在 vendor lock-in 问题：用户能在系统里创作，却很难把成果完整带走。现在已经不再如此。项目所有者可以下载有完整文档的 .romergo 归档，也可以为 Web、Windows、macOS 和 Microsoft Store 准备独立游戏。项目应始终属于创作者，即使作者有一天决定离开 Romergo。
所以我开始做导入与导出。
Web 为什么让这项工作小了很多
Romergo 已经有一套共用的 Player runtime，能够处理场景、分支、图片、音乐、视频、翻译、RTL 语言和本地存档。平时它从服务端加载已发布的故事，但也可以把故事和 Player 一起打包，并完全关闭网络访问。
Web 构建把 index.html 放在 ZIP 根目录；Windows 和 macOS 用强化过安全设置的 Electron 外壳封装同一个 Player；Microsoft Store 则得到包含同一款游戏的 MSIXUpload。故事逻辑不需要重写四次，变化的只是同一套 runtime 外面的包装。
签名、证书、notarization、商店规则和开发者账户依然存在。但最昂贵的部分不再需要重复：为每个平台开发一套行为不同的游戏客户端。
导出如何工作
Romergo 不会复制编辑器中某个偶然的中间状态。它使用状态为 Saved 的草稿，或者某个明确保存的发布版本。Runtime 和资源都固定到具体 revision；如果项目在构建期间发生变化，任务会重新执行，而不是把旧场景和新文件混在一起。
第一个产物始终是 .romergo：一个结构公开、可文档化的 ZIP。里面包含 manifest、项目、章节、场景、流程图、变量、视觉设置、媒体、credits 和 SHA-256 checksums。归档会保存协作者的公开名称和角色，但不会包含 email 或内部 ID。
已保存的草稿或发布版本
↓
一致的 runtime 与资源 revision
↓
有文档的 .romergo 归档
↓
隔离的平台构建器
↓
私有 ZIP 或 MSIXUpload，保留 7 天每个资源都会读取并计算 hash，在写入前再验证一次。归档以流式方式直接写入私有 R2，因此 Worker 不需要把一个数 GB 的项目全部放进内存。
如果用户需要的是可继续编辑的项目，到这里就完成了。如果需要游戏，.romergo 会进入一个无法访问互联网的隔离 Linux 容器。容器验证归档、加入离线 Player，并生成以下一种结果：
- 根目录含
index.html的 Web / itch.io ZIP； - 带本地存档、SteamPipe 模板和本地 signing kit 的 Windows x64 ZIP；
- 分别面向 Apple Silicon 和 Intel 的 macOS 应用 ZIP；
- 使用用户从 Microsoft Partner Center 获取的 identity 生成的 MSIXUpload。
Romergo 不会索取 Steam credentials、Apple Developer ID、证书或密码。签名和发布始终留在作者自己的账户中。服务只准备可上传的构建，将它私密保存七天，并向所有者提供短时下载链接。
成本也让我意外。production 中的《暴风雪》包含 101 个媒体文件，总计约 30 MB。即使超出 Cloudflare 套餐内资源，一次平台构建按当前价格也只是几美分。主要成本不是 R2 或流量，而是打包完成后容器继续存活的时间。
你可以直接在浏览器中体验 production 版本的《暴风雪》，这就是用于本次测算的同一个项目。
导入要复杂得多
视觉小说编辑器和游戏引擎已经超过十种。有人带来 Twine、ink、Yarn Spinner 或 Ren’Py 项目；有人在记事本、Obsidian 或 Notion 中写作；也有人拿来 PDF、Markdown、表格、录音、视频链接和图片目录。
格式成千上万，而且每年都在出现和消失。如果为每一种格式编写原生 importer，五年后只会留下一个解析器坟场，每个解析器只理解某个外部产品的某个旧版本。
答案其实已经在手边：AI agent。
Agent 可以接收 HTML、Markdown、PDF、音频、图片和链接，恢复内容顺序，识别反复出现的角色，标记不明确的分支，并向作者提问。人只需要引导这个过程并检查结果。
Romergo 本来就支持 MCP。因此，与其让 Romergo 学会世界上的所有格式，我选择提供一个稳定目标：agent 用来创建和验证普通 Romergo 项目的工具。
通过 agent 导入的流程
源文件与链接
↓
用户自己的 MCP agent
↓
清单、预览、问题与 warnings
↓
Romergo MCP 创作工具
↓
持久化回读与项目验证
↓
作者在 Builder 中检查结果用户先连接支持 MCP 的 agent，并把原始资料交给它。Agent 整理章节、场景、角色、地点、媒体、语言和关联关系。对于 HTML、Markdown、TXT 和文字型 PDF，romergo_inspect_story_source 与 romergo_import_story_source 已能执行忠实的线性迁移，不会凭空发明分支。
对于 Twine、ink、Yarn Spinner 和 Ren’Py，agent 会理解原格式，但不会假装所有代码都能自动转换。Passages、knots、nodes、对白、选项和基础变量通常能成为章节、场景和跳转；macros、Python、Unity commands、screens、CSS/JS 与 external functions 会进入 warnings，交由作者决定。
预览确认后，agent 通过 MCP 创建新项目，批量导入附件并写入流程图和场景。大型媒体通过一次性上传直接进入 R2，不会出现在模型响应中。随后 agent 使用 romergo_get_chapter 重新读取已保存的数据，运行 romergo_validate_project，并只在 romergo_verify_quest_change 成功后结束迁移。
AI 不会取代检查
Agent 擅长理解含义，但推测不能变成事实。录音可能需要外部转写；视频链接不等于拥有使用权；复杂的 Ren’Py 代码或 Twine macro 可能本身就是一段程序。因此导入流程会显示预览和 warnings，并在创建项目之前要求用户确认素材权利。
Romergo 的原生上传器只接受 .romergo。这是有意的：自己的开放格式必须确定、安全地导入，而无限多的外部来源更适合交给会推理、也会提问的工具。
面向未来五年
格式会变化，模型和 agent 也会变化，但边界可以稳定：一边是任何人类创作资料，另一边是有文档的 .romergo 格式与 MCP 创作工具。
未来出现新的流行编辑器时，Romergo 不必等待专用 importer。Agent 可以研究它的文件，展示自己的理解，再通过同一个契约写入结果。如果作者决定离开 Romergo，也仍然拥有开放归档和离线游戏。
这就是我认为正确的方向：Romergo 应该是一个方便创作故事的地方，而不是一座无法把故事带走的牢笼。