更好的阅读体验：打开飞书阅读>
1. 团队介绍
大家好，我是一名有十年经验的互联网大厂开发，资深前端背景+AI全栈开发者，喜欢用AI做一些有创意，有价值的事情。我是理科生，我的项目是偏历史学习、古籍活化方向的。为了让团队结构更加完善，复赛阶段新加入了两位人文系队友。有对历史和游戏非常感兴趣的文科同学，对项目史书游戏化做了很多优化；也有本科即是历史学，硕士专攻数字人文方向的AI产品经理，对整个项目的产品完善提供了很多改进。团队在技术、历史研究、产品设计与游戏化体验上形成互补，正好匹配本项目"技术严谨 + 文化可信 + 体验有趣"的复合要求：
队员：Jade，211本历史学，英硕数据科学，现AI产品经理，项目产品主力；
队员：mcnocc, 南开法学&金融专业，历史人文爱好者，项目游戏设计/体验优化主力；
我们的队伍名称就叫【穿越小队】，三个完全不同背景的同学因为TRAE AI 创造力大赛，汇聚到一起，为了同一个目标而努力：——让「穿越·兰台」成为完整的，兼顾趣味交互和历史学习的古籍活化数字产品。
2. 产品简介
穿越兰台是什么？
「穿越·兰台」是一个以中国二十四史为底座，通过数字化、可视化、趣味化的交互体验，把历史古籍转化为用户可亲身体验的数字产品。
在这里，你可以化身为历史角色，穿越到过去某个时代，亲身体验历史；也可以和古人对话，直接探讨历史事件；甚至可以看古人发朋友圈/视频号，通过创新式玩法来探索历史的真相。
本项目的三大创新点：
- 需求创新：现有古籍平台（识典古籍、中国哲学电子书计划等）解决了"可信"问题，但未解决"可读意愿、可广泛传播"问题；短视频/AI 短剧解决了"有趣"问题，但牺牲了史实可信度。本项目瞄准这一长期未被有效满足的需求——“既要可信正史，又要趣味体验”，填补学术古籍与大众娱乐之间的断层。
- 思路创新：区别于现有平台"严肃阅读"或娱乐产品"戏说历史"的单一路径，我们采用"三端矩阵 + 娱乐为入口、正史为依据"的解法——主站守住可信底座，子站用互动叙事让用户"亲历历史"，小程序用轻社交玩法把历史带入碎片时间，形成"轻互动 → 深体验 → 回到原文"的完整漏斗。
- 技术创新：基于 TRAE Work/Code + Harness + Skill + 校验门禁（verify-ink / verify-canon / verify-free）构建了一套"规则约束下 AI 批量生产可验收内容"的工程化生产线，让 AI 生成物必须通过编译、分支、史实路径、结局可达性四道校验才能上线，这在古籍互动内容生产领域是可复用的技术突破。
核心用户是谁？
核心是对历史感兴趣但是又啃不动历史古籍的普通大众。
现在很难有人能系统的把历朝历代史书看完，相反，大家更愿意通过各类短视频、影视剧来了解历史，但问题就在于这些短视频和影视剧并不完全表达了历史的真相，很多做了艺术化，还有的AI短剧甚至歪曲历史。这就导致除了课本上学的历史，我们对其他历史真相知之甚微。
相比朴实严谨的书籍，趣味化的游戏/短剧/影视剧更能吸引人，那能否二者结合，既能吸引人，又能学到真东西？
当然可以！我们参考了一些严谨的数字古籍平台（比如字节和北大共建的识典古籍，开源的中国哲学电子书计划），同时结合了一些当下流行的穿越、游戏、社交传播玩法，在学术向和娱乐向之间找到平衡，让产品具备趣味性的同时，又保留历史的真实性，实现在娱乐中学习、让古籍活化且更易传播的目标。
这样，就可以让产品的用户群体从历史爱好者/学者/教育工作者拓展到更多普通大众了。
完整功能介绍
「穿越·兰台」主站当前已经形成完整的数据探索路径：
- 首页：“穿越长河”时间叙事和子项目入口；
- 兰台：二十四史全文检索、目录、章节阅读、前后篇导航，24 部正史、3,597 卷、49,551 条原文段落；
- 人物：13,978 位历史人物列表、详情、44,178 条人物关系图谱（君臣/同僚/家族/敌对/朋友/师生六类）、史料出处等功能；
- 地图：基于 MapLibre GL、Turf.js、GeoJSON 的历史舆图以及人物关系地图；
- 账号：收藏、进度和云存档相关能力；
「穿越·史记」作为史记互动叙事游戏载体，已实现：
- 实现史记全章节游戏化，包含 119 个 Ink 剧本（84 主线 + 35 番外），约 130 个经典原文章节，覆盖 51 位历史角色；
- 支持史实模式 / 自由模式，多槽位云存档、87 个成就、341 个死亡结局、原文回看；
- 支持拓展小游戏（当前有 18 个独立小游戏、27 个关卡），通过 Ink 标签驱动背景、立绘、表情、BGM、死亡、成就、结局和小游戏。累计 153 首 BGM 曲目（20 种情绪分类）和 2,491 张场景/立绘图片资源。
「穿越兰台圈」小程序则作为移动端阵地，覆盖高频玩法，主打趣味学习历史：
- 好友聊天：支持添加101位历史热门人物为好友，有什么知识可以当面聊天解答，不用自己翻书！
- 典籍阅读：支持移动端阅读典籍、译文、进度存储等功能；
- 穿越朋友圈：看古人发朋友圈，评论区互动，让历史知识趣味性活化；
- 穿越视频号：看古人发短视频，刷视频的同时让历史角色更加鲜活；
- 批奏折：抓取真实的 100 份古代奏折内容，体验当皇帝的同时也能了解历史真实民情；
- 雁书：鸿雁传书给古人，实现跨时空对话的同时，归雁还能收集 100 件古代文物回来，打造历史版本的旅行青蛙；
- 测一测：历史人格测试（6 类 40 题 38 种结果），看看你跟哪位历史角色更像？旨在提升小程序传播度；
- 看一看：人物真相、史观解读、历史冷知识，补齐你历史好奇心的最后一块碎片。
核心数据规模（截至复赛提交）：
| 维度 | 数据量 |
|---|---|
| 正史结构化 | 24 部、3142 卷、49,498 条原文，含 3,161 个章节原文 |
| 历史人物 | 101 位立传人物，含生平、籍贯、官职、传记出处与原文引用 |
| 历史地图 | 标注全部立传人物籍贯与主要事件地的可交互历史地图 |
| 互动叙事（《穿越·史记》） | 75 个 Ink 剧本、130 个史记经典章节、3000+ 段落、2000+ 选择分支、5 种结局类型 |
| AI 穿越伴侣 | 支持 101 位历史人物跨时空对话，内置 4 项校验规则避免虚构与现代词汇污染 |
| 小程序轻互动 | 穿越朋友圈、穿越视频号、奏折批阅、鸿雁传书、史海一签、历史人格测试 6 大玩法 |
| 开发轮次 | 使用 TRAE 累计 200+ 轮次迭代开发 |
相比初赛的升级
初赛时，它更像一个数字史料基座Demo ，已经具备二十四史检索、章节阅读、人物数据、关系图谱、历史地图等功能。复赛阶段，我们没有围绕站点本身继续堆砌功能，也没有简单的做一个端侧APP移植，而是围绕项目目标，把它扩展成三个互补产品：
三部分各司其职，围绕数字兰台+古籍活化形成互补体系：
- 「穿越·兰台」主站负责可信底座和全局探索；
- 「穿越·史记」负责沉浸式理解和互动游戏式学习；
- 「穿越兰台圈」小程序负责轻量触达、历史玩法和分享传播。
| 产品 | 定位 | 核心能力 | 解决的问题 |
|---|---|---|---|
| 穿越兰台 | 正史数据基座 | 二十四史检索、古籍阅读、人物图谱、历史舆图、穿越长河 | 让用户找得到、看得懂、连得起历史资料 |
| 穿越·史记 | 互动叙事体验 | Ink 剧本、历史人物线、选择分支、死亡反馈、原文回看、成就存档 | 让用户从“读过历史”变成“经历历史” |
| 穿越兰台圈 | 移动触达入口 | 与古人小叙、批奏折、雁书、历史人格、朋友圈、内容社区 | 让历史进入碎片化、分享化、日常化场景 |
初赛版本证明了“史料可以结构化、可检索、可视化”；复赛版本进一步证明了“史料可以被转化为可运行、可验收、可传播的互动产品”。
升级主要体现在三点：
- 产品上，从单站点升级为三端产品矩阵；
- 体验上，从 DEMO 级别到完整可运行链路；
- 技术上，从 VibeCoding 升级为有规则、有 Skills、有校验门禁的工程化生产线。
以下为三端产品的核心数据资产统计，所有数据均通过实际数据库查询和文件系统统计校验：
| 产品 | 数据维度 | 数量 | 说明 |
|---|---|---|---|
| 穿越·兰台（主站） | 入库古籍 | 24 部 | 二十四史全量（史记至明史） |
| 原文卷数 | 3,597 卷 | 可检索、可阅读、前后篇导航 | |
| 原文段落 | 49,551 条 | 结构化文本片段，支持全文检索 | |
| 历史人物 | 13,978 人 | 跨夏至明代，含性别/生卒/朝代标注 | |
| 人物关系 | 44,178 条 | 君臣/同僚/家族/敌对/朋友/师生六类 | |
| 人物-段落关联 | 65,555 条 | 人物与原文的双向引用链路 | |
| 穿越·史记（游戏） | Ink 剧本 | 119 个 | 84 主线 + 35 番外，覆盖 11 个历史系列 |
| 游戏角色 | 51 个 | 跨五帝至汉武，含史料出处与经典引言 | |
| 成就系统 | 87 个 | 10 个成就系列 | |
| 死亡结局 | 341 个 | 含史实分析与史料出处 | |
| 拓展小游戏 | 18 个 | 27 个关卡（华容道/三消/排兵布阵等） | |
| BGM 曲目 | 153 首 | 20 种情绪分类，306 个音频文件 | |
| 视觉资源 | 2,491 张 | 场景背景 668 + 角色立绘 687 + 档案图 1,136 | |
| 穿越兰台圈（小程序） | 页面数 | 37 个 | |
| 云函数 | 19 个 | 按聊天/奏折/雁书等领域拆分 | |
| 数据集合 | 39 个 | CloudBase 独立维护 | |
| DNA 测试 | 6 类 38 结果 | 历史人格测试 | |
| 奏折数据 | 100 份 | 真实古代奏折内容 | |
| 雁书礼物 | 100 件 | 文物收集系统，4 位信使 |
三端合计代码量超 13 万行，是兼顾数据规模、交互深度和工程完整度的古籍活化产品。
初赛 Demo vs 复赛成品对比：
| 维度 | 初赛 Demo | 复赛成品 |
|---|---|---|
| 产品形态 | 单一主站（史料基座） | 主站 + 子站 + 小程序三端矩阵 |
| 数据规模 | 二十四史结构化、检索/图谱/舆图基础能力 | 24 部/3142 卷/49,498 条原文 + 75 个 Ink 剧本/130 章节 + 101 位人物可对话 |
| 体验深度 | 可检索、可阅读、可关联 | 可扮演（穿越史记）、可对话（AI 伴侣）、可分享（小程序朋友圈/奏折/雁书） |
| 工程化程度 | VibeCoding 直接生成 | Harness + Skill + 校验门禁（verify-ink / verify-canon / verify-free）的可复用生产线 |
| 目标用户 | 历史爱好者/学者 | 中学生/教师/内容创作者/历史爱好者 |
| 可复制性 | 单项目 Demo | VN游戏引擎与运行时已抽离，可扩展至《汉书》《三国志》《资治通鉴》等其他任何古籍，一键活化 |
3. 产品演示视频
初赛视频：VibeCoding大赏｜我用AI把千年历史做成了游戏宇宙 「穿越·兰台」一座数字游戏史书馆。
为什么做这个项目？二十四史是中国四千年最可靠的信史，但它一直躺在故纸堆里：文言文劝退普通人，几千卷的体
复赛最终视频：https://feelinganime.feishu.cn/wiki/V6IbwUwdAi6RgxkjA7tcmE26nXf#share-IhOtdDh2WobZTfxxryVcgTtenYf
小程序端体验截图：
复赛视频：待补充
4. 产品创作历程
来自穿越剧的灵感
灵感来源于老婆天天在抖音刷各种穿越漫剧，故事一个比一个离谱，离谱到大家都忘记了真实的历史是什么样的。于是就想到，既然大家对穿越剧这么感兴趣，对正史又没什么兴趣，那我干脆做一个能穿越到正史的项目，让大家对了解正史也能提起更多兴趣？
于是「穿越·兰台」项目就诞生了。
“穿越”就不解释了，“兰台"是汉代藏典修史之所，班固曾任兰台令史撰《汉书》。我们想做一座"数字兰台”——让今人能逆流而上，亲历真实的青史，而不是被戏说喂养。
初赛MVP
初赛阶段我把二十四史整理成可检索、可阅读、可关联的数据产品。它解决的是“可信入口”问题：用户至少可以找到原文、看到人物、理解关系、定位时间与空间。接着以二十四史之首《史记》为蓝本，创作了《穿越史记》游戏项目，让用户穿越到史记中，以VN游戏的形式来体验历史，比如：
- 如果用户成为韩信，面对胯下之辱会怎么选？
- 如果用户成为项羽，鸿门宴上会不会放过刘邦？
- 如果用户成为舜，面对家庭、部族和天下秩序会如何取舍？
这类选择不是为了制造爽文，而是为了让玩家理解：历史人物不是结论标签，而是在时代、性格、利益和局限中作出选择的人。玩家可以做出史实路径，也可以做出反史实路径，例如玩家选择偏离历史的路线时，系统会给出死亡、失败、偏离原因或 IF 结局。它不是简单说“你错了”，而是让玩家看到“为什么史上的他没有这样选”“这个选择在当时会付出什么代价”。
这让游戏里的失败不再只是惩罚，而成为一种学习反馈。
复赛产品力提升
初赛各项功能看起来完备，但实际很多细节需要打磨，同时随着两位队友的加入，我们也在持续探索更多创新的功能，让这个MVP成为真正闭环的产品：
- 添加典籍备注、阅读进度、收藏等功能，修复主站体验问题；
- 给穿越史记游戏添加BGM、视频、动效，完善场景和立绘，增强游戏化体验；
- 新增小程序端，增加角色跨时空对话、历史朋友圈、视频号、飞雁传书、批奏折等一系列创新功能，围绕穿越兰台的主题，拉进现代与历史的距离。
产品探索的同时，我们也在做技术升级，通过 Skill、工作流的优化，让AI 批量生产的剧本和资料更加准确、高效。
5. TRAE 实践过程
TRAE 的四个版本我都装了，Work 和 Code 模式各有千秋，结合使用效果最佳。
Work 模式负责创意
先用 WORK 模式明确创意和需求，明确好产品定位、名称、设计思路，最终输出一份 PRD 文档：
4396323792235988:339db33d26571ead5a75c98b499f892f_6a337f96d2aa268a728ae7ad.6a395d1665c7eb861501d010.6a395d154ff186f98cd0f499:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/6/23 00:07:12)
再让 TRAE 出个 DEMO，这里需要反复调整 AI 的预期，达到你想要的效果，调整到整体风格方向一致即可，最终细节我们会丢到Code模式进行工程化改造。
4396323792235988:97b1b28c300d56141e283ac202843a72_6a337f96d2aa268a728ae7ad.6a39689365c7eb861501d0f9.6a3968920b436f299a2b5bee:TRAE Work CN.0.1.43.no_sid.no_ppe.T(2026/6/23 00:58:37)
Code 模式负责生产
Code模式主要是执行，持续跟 AI 对抗&调优&解决问题，这里简单分享两点。
不要在一个窗口开启太多并行任务容易卡死，比如历史书翻译的过程（这里任务耗时巨大，TRAE经常崩掉），最好开启了多个对话并行：
4396323792235988:83272dee91463ae4b87ecaad0982d6d3_6a4249c21e11cc669f4a74f3.6a424a1c1e11cc669f4a7505.6a424a1c1e11cc669f4a7503:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/6/29 18:34:04)
另外，Code模式不支持出图，批量出图任务还是要交给Work模式来做：
4396323792235988:58bf50a5edd6c1dee83a08c887f9817a_6a46b44bed7d192b11460b2d.6a4783daed7d192b11460e89.6a4783daed7d192b11460e87:TRAE Work CN.0.1.29.no_sid.no_ppe.T(2026/7/3 17:41:46)
Harness 负责工程
给项目做好 Harness 是必修课，AGENTS.md/Rules/Skills 做好项目纲领、规约、技能包储备，同样的工具和模型，能让AI发挥出更好的效果，这里截几张图：
以Skill为例，大赛阶段我沉淀了多个关键 Skill：
ink-story-writing：把史料、人物母题和分支结构转成 Ink 剧本；vn-story-image：为视觉小说生成角色、背景和场景资产；kv-image-gen：处理带统一风格约束的图像生成与抠图；
还有一部分校验脚本（动态推理交给Skill，静态校验交给Script）：
verify-ink：编译剧本，遍历分支，检查背景、人物、死亡、成就与小游戏 ID；verify-canon：确保正史路径可以通关，不会误入死亡分支；verify-free：检查自由模式具名结局、死亡结局与 registry 可达性；- TypeScript 与生产构建：保证内容接入后不破坏工程。
Harness 工程很关键，他让TRAE 不只是生成代码，而是在规则和校验约束下参与生产可验收内容，让项目具备可以持续维护的能力，而不是一次性DEMO产物。
穿越兰台是一个打算长期维护的项目，因此我们花了一部分精力把“规则 + Skill + 校验门禁”整个链路打通，让 AI 生成物必须通过工程系统验收。
整个开发周期累计沉淀了 200+ 轮 TRAE 开发 Session，代表性 Session 截图如下（覆盖需求分析、架构设计、代码生产、内容生成、脚本校验等全链路节点）：
6. 技术架构与工程取舍
三端技术栈总览：
| 端 | 技术栈 | 运行环境 | 核心能力 |
|---|---|---|---|
| 主站「穿越·兰台」 | React + Vite + Hono + FTS5/bigram + Turf.js/MapLibre GL | Cloudflare Workers + D1/Turso + R2 + KV | 全文检索、古籍阅读、人物图谱、历史舆图、云存档 |
| 子站「穿越·史记」 | TypeScript + ink-vn-core（自研 Ink 运行时）+ Ink 脚本引擎 | Cloudflare Workers + R2 | 互动叙事、分支追踪、死亡反馈、成就存档、原文回看 |
| 小程序「穿越兰台圈」 | 微信小程序原生 + 云开发 | 微信 CloudBase + 云函数 | 好友聊天、朋友圈、视频号、批奏折、雁书、人格测试、内容安全 |
| 内容生产线 | TRAE Work（创意）+ TRAE Code（生产）+ Harness/Skill/校验脚本（工程） | GitHub 版本托管 | ink-story-writing / vn-story-image / kv-image-gen / verify-* 校验门禁 |
本着能白嫖就不花钱的原则，充分利用好公共资源：
- 腾讯云买域名，便宜省事，但不要买腾讯云的服务器和HTTPS服务；
- DNS 解析改到 Cloudflare，白嫖 Cloudflare HTTPS 服务；
- 用 Cloudflare Worker + Github 项目托管，白嫖网站托管服务；
- 用 TURSO 提供的免费 DB服务，容量比 Cloudflare 免费套餐大，可以干更多活儿；
- 小程序用腾讯云服务，参与AI计划之后可以白嫖6个月云开发资源。
虽然都是白嫖，但是整个项目技术架构清晰，可移植性也很强，如果后续经费充足，可以快速切换到更适合国内的云服务架构上：
当前三端共享的是品牌、史料、内容生产方法和部分内容资产；账号和业务数据没有强行打通。Web 端使用 D1 / Turso 等底层能力，小程序的数据从底层同步后，在微信 CloudBase 数据库中独立维护，更符合微信生态和移动端运营场景。
6.1 主站技术决策
主站采用 React + Vite 构建前端，Hono 运行在 Cloudflare Workers 上，配合 D1 / Turso / R2 / KV 等边缘能力。它的核心特点是读多写少，因此重点不是复杂后端，而是数据组织、检索性能、缓存策略和稳定降级。
关键取舍：
- 用 FTS5 和 bigram 预处理提升中文古籍检索体验；
- 用 Cloudflare Workers 降低运维成本；
- 用 R2 存储人物、视觉等资源；
- 用 GitHub 做版本托管，方便历史数据、剧本、资源和代码共同演进；
- 对高稳定数据和高变化数据采用不同缓存 TTL；
- 缓存失败时静默降级，避免非核心依赖拖垮主链路。
6.2 子站技术决策
子站的重点不是页面，而是内容引擎。ink-vn-core 负责 Ink 脚本运行、标签解析、变量追踪、分支状态和检查点；应用层再解释史记项目特有的死亡、成就、小游戏、原文回看和视觉效果。
这样拆分有两个好处：
- 内容创作可以主要改 Ink 和资源注册，不需要频繁改引擎；
- 未来扩展《汉书》《三国志》等系列时，可以复用运行时和校验体系。
整个游戏创作的核心包和Skill，在项目之初就被我抽离了出来，这样方便后续复用和独立开源。
史记项目的核心价值之一，就是验证基于历史题材的视觉小说（Historical Fiction Visual Novel）游戏 Skill 工作流，为后续史书游戏制作打下基础。计划大赛结束后开源，未来只需要输入一部史书，Skill 就能自动生成一部完整的HFVN游戏。
6.3 小程序技术决策
小程序没有强行复用 Web 技术栈，而是采用微信小程序原生能力和微信云开发。原因很现实：小程序最重要的是微信生态触达、分享、OPENID 身份、安全审核和云函数能力。
关键设计：
- 小程序数据由底层内容同步过来，再在 CloudBase 中独立维护；
- OPENID 由云端上下文获取，不信任前端传入；
- 用户生成内容接入微信内容安全；
- 点赞、关注、评论等高频关系独立建集合，避免单文档膨胀；
- 云函数按聊天、奏折、雁书、内容流、用户等领域拆分。
7. 社会价值与长期可持续性
社会价值：让可信历史古籍活化，重新进入大众视野
项目的核心社会价值，是在"短视频戏说历史、AI 短剧歪曲史实"的当下，降低正史阅读门槛，同时保留可信来源，让更多大众也能接触到真实的历史。
一、受众规模与群体覆盖：
- 中小学生与教师：通过"鸿门宴扮演项羽""韩信面对胯下之辱"等情境化体验，让正史成为课堂导入、人物理解、探究式讨论的生动材料，服务 K12 历史教育；
- 通勤族 / 普通大众：小程序端三五分钟的"轻互动"（批奏折、刷古人朋友圈、人格测试）把历史塞进碎片时间，让过去"啃不动史书"的普通人也能自然接触正史；
- 传统文化内容创作者：提供一条"史料→互动内容"的低成本生产路径，让地方志、非遗故事、地方人物典故都能被数字化活化；
- 偏远地区 / 乡村教育场景：能让缺乏实体博物馆、优质师资地区的学生平等接触正史资源，促进教育公平。
二、社会效益与社会痛点回应：
- 回应"正史被娱乐化稀释"的痛点：当前大量短视频、AI 穿越短剧为博眼球歪曲历史，普通人尤其青少年难以分辨戏说与史实。本项目以娱乐为入口，但所有分支最终回归原文，选择偏离史实时会给出"为什么史上的他没有这样选""这个选择在当时会付出什么代价"的解释性反馈，让娱乐成为进入史料的桥梁而非替代品；
- 降低古籍数字化的参与门槛：相较于学术型古籍平台（如识典古籍、中国哲学电子书计划）侧重学者研究，本项目面向普通大众做"最后一公里"的趣味化、可体验化转译，解决了"可信古籍"与"大众阅读"之间的隔阂；
- 提升公共文化服务效率：通过 AI + 工程化生产线，一部正史的互动化成本被大幅压缩，为公共文化机构（图书馆、博物馆、地方志办）提供了低成本活化馆藏文献的可行路径；
三、可复制性：
- 内容生产线可复用："史料清洗 → Skill 驱动剧本生成 → verify-ink / verify-canon / verify-free 校验门禁 → 运行时消费"这套工程化生产线已在《史记》上跑通，可标准化复制到其他正史、典籍、地方志、非遗档案，不依赖特定团队或特定题材；
- 运行时可扩展：
ink-vn-core与业务解耦，未来新增史书只需新增 Ink 剧本、资源与注册配置，无需重写引擎； - 三端架构可迁移：主站基于 Cloudflare Workers + 开源技术栈，小程序基于微信云开发，可快速切换到国内云服务，便于公共文化机构落地部署。
我们不希望把历史做成纯娱乐产品，而是让娱乐性成为进入史料的入口。
长期可持续性
作为一个打算长期维护的开源项目，未来可持续路径包括：
- 教育合作：面向学校、家庭提供历史互动学习材料，作为课堂与亲子场景的补充工具；
- 文化 IP：沉淀的互动剧本、角色、视觉资产可形成传统文化 IP 内容库；
- 技术工作流开源：把"史书转互动内容"的 Skill、校验脚本与运行时开源，让更多历史爱好者、文化机构参与共建，放大社会价值。
商业化不是本项目的首要目标，我们更倾向以开源共建为核心，让更多人一起参与完善，真正实现"让可信历史重新进入大众视野"的产品目标。
