1. 团队介绍
大家好，我是一名有十年经验的互联网大厂开发，资深前端背景+AI全栈开发者，喜欢用AI做一些有创意，有价值的事情。我是理科生，我的项目是偏历史学习、古籍活化方向的。为了让团队结构更加完善，复赛阶段新加入了两位人文系队友。有对历史和游戏非常感兴趣的文科同学，对项目史书游戏化做了很多优化；也有本科即是历史学，硕士专攻数字人文方向的AI产品经理，对整个项目的产品完善提供了很多改进。可以说整个团队的人才分布，完全就是为这个项目而生哈哈：
队长：小蜂猫，985软件工程，前阿里/蚂蚁/字节前端，现AI全栈开发，项目研发主力；
队员：Jade，211本历史学，英硕数据科学，现AI产品经理，项目产品主力；
队员：mcnocc, 南开法学&金融专业，历史人文爱好者，项目游戏设计/体验优化主力；
我们的队伍名称就叫【穿越小队】，三个完全不同背景的同学因为TRAE AI 创造力大赛，汇聚到一起，为了同一个目标而努力：——让「穿越·兰台」成为完整的，兼顾趣味交互和历史学习的古籍活化数字产品。
2. 产品简介
穿越兰台是什么？
「穿越·兰台」是一个以中国二十四史为底座，通过数字化、可视化、趣味化的交互体验，把历史古籍转化为用户可亲身体验的数字产品。
在这里，你可以化身为历史角色，穿越到过去某个时代，亲身体验历史；也可以和古人对话，直接探讨历史事件；甚至可以看古人发朋友圈/视频号，通过创新式玩法来探索历史的真相。
核心用户是谁？
核心是对历史感兴趣但是又啃不动历史古籍的普通大众。
现在很难有人能系统的把历朝历代史书看完，相反，大家更愿意通过各类短视频、影视剧来了解历史，但问题就在于这些短视频和影视剧并不完全表达了历史的真相，很多做了艺术化，还有的AI短剧甚至歪曲历史。这就导致除了课本上学的历史，我们对其他历史真相知之甚微。
相比朴实严谨的书籍，趣味化的游戏/短剧/影视剧更能吸引人，那能否二者结合，既能吸引人，又能学到真东西？
当然可以！我们参考了一些严谨的数字古籍平台（比如字节和北大共建的识典古籍，开源的中国哲学电子书计划），同时结合了一些当下流行的穿越、游戏、社交传播玩法，在学术向和娱乐向之间找到平衡，让产品具备趣味性的同时，又保留历史的真实性，实现在娱乐中学习、让古籍活化且更易传播的目标。
这样，就可以让产品的用户群体从历史爱好者/学者/教育工作者拓展到更多普通大众了。
完整功能介绍
「穿越·兰台」主站当前已经形成完整的数据探索路径：
- 首页：“穿越长河”时间叙事和子项目入口；
- 兰台：二十四史全文检索、目录、章节阅读、前后篇导航，24 部正史、3142 卷、49,498 条原文；
- 人物：历史人物列表、详情、关系图谱、史料出处等功能；
- 地图：基于 MapLibre GL、Turf.js、GeoJSON 的历史舆图以及人物关系地图；
- 账号：收藏、进度和云存档相关能力；
「穿越·史记」作为史记互动叙事游戏载体，已实现：
- 实现史记全章节游戏化，包含 75 个 Ink 剧本，约 130 个经典原文章节；
- 支持史实模式 / 自由模式，多槽位云存档、成就系统、死亡图鉴、原文回看；
- 支持拓展小游戏（当前有7个），通过 Ink 标签驱动背景、立绘、表情、BGM、死亡、成就、结局和小游戏。
「穿越兰台圈」小程序则作为移动端阵地，覆盖高频玩法，主打趣味学习历史：
- 好友聊天：支持添加101位历史热门人物为好友，有什么知识可以当面聊天解答，不用自己翻书！
- 典籍阅读：支持移动端阅读典籍、译文、进度存储等功能；
- 穿越朋友圈：看古人发朋友圈，评论区互动，让历史知识趣味性活化；
- 穿越视频号：看古人发短视频，刷视频的同时让历史角色更加鲜活；
- 批奏折：抓取真实的古代奏折内容，体验当皇帝的同时也能了解历史真实民情；
- 雁书：鸿雁传书给古人，实现跨时空对话的同时，归雁还能收集古代文物回来，打造历史版本的旅行青蛙；
- 测一测：历史人格测试，看看你跟哪位历史角色更像？旨在提升小程序传播度；
- 看一看：人物真相、史观解读、历史冷知识，补齐你历史好奇心的最后一块碎片。
相比初赛的升级
初赛时，它更像一个数字史料基座Demo ，已经具备二十四史检索、章节阅读、人物数据、关系图谱、历史地图等功能。复赛阶段，我们没有围绕站点本身继续堆砌功能，也没有简单的做一个端侧APP移植，而是围绕项目目标，把它扩展成三个互补产品：
三部分各司其职，围绕数字兰台+古籍活化形成互补体系：
- 「穿越·兰台」主站负责可信底座和全局探索；
- 「穿越·史记」负责沉浸式理解和互动游戏式学习；
- 「穿越兰台圈」小程序负责轻量触达、历史玩法和分享传播。
| 产品 | 定位 | 核心能力 | 解决的问题 |
|---|---|---|---|
| 穿越兰台 | 正史数据基座 | 二十四史检索、古籍阅读、人物图谱、历史舆图、穿越长河 | 让用户找得到、看得懂、连得起历史资料 |
| 穿越·史记 | 互动叙事体验 | Ink 剧本、历史人物线、选择分支、死亡反馈、原文回看、成就存档 | 让用户从“读过历史”变成“经历历史” |
| 穿越兰台圈 | 移动触达入口 | 与古人小叙、批奏折、雁书、历史人格、朋友圈、内容社区 | 让历史进入碎片化、分享化、日常化场景 |
初赛版本证明了“史料可以结构化、可检索、可视化”；复赛版本进一步证明了“史料可以被转化为可运行、可验收、可传播的互动产品”。
升级主要体现在三点：
- 产品上，从单站点升级为三端产品矩阵；
- 体验上，从 DEMO 级别到完整可运行链路；
- 技术上，从 VibeCoding 升级为有规则、有 Skills、有校验门禁的工程化生产线。
3. 产品演示视频
初赛视频：VibeCoding大赏｜我用AI把千年历史做成了游戏宇宙 「穿越·兰台」一座数字游戏史书馆。
为什么做这个项目？二十四史是中国四千年最可靠的信史，但它一直躺在故纸堆里：文言文劝退普通人，几千卷的体
小程序端体验截图：
复赛视频：待补充
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 生成物必须通过工程系统验收。
实践的 SessionID 太多了，这里直接贴工作截图：
6. 技术架构与工程取舍
本着能白嫖就不花钱的原则，充分利用好公共资源，整个项目耗资最高的是花了15块钱买域名：
- 腾讯云买域名，便宜省事，但不要买腾讯云的服务器和HTTPS服务；
- DNS 解析改到 Cloudflare，白嫖 Cloudflare HTTPS 服务；
- 用 Cloudflare Worker + Github 项目托管，白嫖网站托管服务；
- 用 TURSO 提供的免费 DB服务，容量比 Cloudflare 免费套餐大，可以干更多活儿；
- 小程序用腾讯云服务，参与AI计划之后可以白嫖6个月云开发资源。
虽然都是白嫖，但是整个项目技术架构清晰，可移植性也很强，如果能拿到5W云资源扶持，可以快速切换到更适合国内的云服务架构上：
当前三端共享的是品牌、史料、内容生产方法和部分内容资产；账号和业务数据没有强行打通。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. 商业化或社会价值分析
社会价值：让可信历史古籍活化，重新进入大众视野
项目的核心社会价值，是降低正史阅读门槛，同时保留可信来源：
- 对普通用户，它提供“轻互动 → 深体验 → 回到原文”的路径；
- 对老师和学生，它可以成为课堂导入、人物理解和探究式讨论材料；
- 对传统文化内容创作者，它验证了一条低成本的互动内容生产方式。
我不希望它把历史做成纯娱乐产品，而是让娱乐性成为进入史料的入口。
商业化分析：文化内容 IP 与教育工具
一个是产品本身，一个是产品背靠的 AI 技术工作流：
- 产品：面向学校和家庭的历史互动学习产品、传统文化 IP 的互动内容库；
- 技术：史书转游戏的 Skill 工作流，以及生成的游戏本身可以上架各个平台进行商业化；
作为技术工作者，商业化不是我的强项，我更倾向开源共建发挥其社会价值，让更多的人能一起参与完善，实现产品本身目标。
