把DEV.to搬进3D图书馆后，我修bug修到崩溃

把DEV.to做成一个能走进去的3D图书馆，听起来是个一句话就能讲完的好点子。真正动手之后，大部分时间都花在了意料之外的崩溃上，然后一个个查明白为什么。

这不是一个主题场景里飘着几张文章卡片，而是把真实的线上目录，通过Forem API拉取，渲染成一个可以行走的档案库。有书架，有房间，有分区。真实的封面图贴在真实的书脊上。你用WASD移动，而不是滚动信息流。

整个项目一开始是氛围编程，几乎完全是为了Sanity和Dev.to的黑客松。我描述想要什么，它就出现了——电影级灯光、空间音频，还有一堆我自己都没完全想清楚的系统。

这套做法在项目小的时候很好用，直到项目大到某些东西开始以重新生成一段回复根本修不好的方式崩掉。当目录变成真实的，场景要承受成千上万篇实时文章涌入，而不是十几篇模拟数据时，我就没法靠描述绕开问题了。我必须打开动画循环，追踪引用，真正搞懂底层在发生什么——不是我想这么做，而是"再试一次"不管用了。

没有可视化编辑器，一切靠数字

项目基于Next.js和Three.js，没有游戏引擎，没有可视化场景编辑器，没有任何可以拖动物体看它移动的视口。Three.js是一个用WebGL在浏览器里渲染3D图形的JavaScript库，里面的一切都是代码。没有带X/Y/Z输入框、能用方向键微调的检查面板。如果一个书架悬空了六个单位，你不能把它拖下来，只能找到设置它位置的那行代码，改数字。

听起来只是小麻烦，直到你要在一条弯曲的、程序生成的长廊里摆放几百个书架。在Unity或Unreal里，你会立刻看到错位，然后拖到正确位置。在Three.js里，你是在盲算坐标——改一个数字，等场景重建，用WASD走进去看对不对，不对就再来一遍。这个项目里每一个位置、旋转和偏移，都只是某个函数里的一个数字，不是你能看见并抓住的东西。

这也是为什么下面很多bug是关于东西在哪，而不是东西长什么样。坐标数学不像视觉样式那样容忍氛围编程——颜色稍微偏一点看着还行，但书架位置稍微偏一点，要么穿墙，要么飘在虚空里，而且你不亲自走过去看，根本不知道是哪种。

它最初不是这个项目

它一开始叫Oniria，简称Oni，是一个第一人称3D梦境日记。记忆是发光的球体，它们之间有可以实际飞行的关系连线。它长得很快：电影级灯光、空间音频、递归梦境潜入、记忆衰减，还有一个"天文台"模式，可以拉远看到全部梦境历史。等我停下来环顾四周时，已经比主分支领先197次提交、一万三千行代码，我不得不问那个显而易见的问题：这对一个黑客松来说是不是太多了？

答案没有缩小问题，而是重新定义了问题：如果继续把每个想法都当成同等重要，那范围对黑客松来说确实太大。但这不意味着Oniria本身"太多"。问题变成了产品聚焦，而不是野心。

于是我挑了一个90秒的体验，把其他一切冻结在它后面。在这个过程中，我看着自己实际做出来的东西——在一个由相互关联的事物组成的图里第一人称飞行——然后问了另一个问题：如果这跟梦境根本没关系呢？

先冒出来的是一个代码库浏览器想法（文件夹是世界，导入是走廊）。它没上线，但撬开了一点：这个引擎其实不是关于梦的，它是一种把任何相互关联、可浏览的结构变成场所的方式。于是我要了一个更奇怪的东西——把整个DEV.to网站导入引擎。字面意义上的网上冲浪。

第一个版本是一块阴谋论板

它技术上能跑。文章、个人资料、标签、搜索结果，全部同时漂浮在空间里。技术上很唬人。完全没法导航——你会出生在一团互不相关的节点云里，不知道先看哪里。

这与其说是bug，不如说是设计失败，但它定下了之后一切的基调：修复方式不是新功能，而是一个隐喻。一座图书馆。房间是主题，书架是信息流，书是文章。人有自己的房间。这一个想法对可用性的提升，超过了我此前做过的所有渲染改进，因为建筑结构能告诉你该往哪走，而漂浮的标签永远做不到。

图书馆在我站着的时候自己重新排列

当真实的DEV文章开始涌入，而不是十几篇模拟数据时，图书馆需要几百个、然后几千个书架。导航就在这时悄悄坏掉了。

原因是：书架一直在相对彼此定位。听起来合理，直到你意识到这意味着导航是布局的附带产物，而不是这个世界真正保证的东西。每当又有一页文章流入，书架位置就可能在玩家脚下移动。在普通网站上，重新渲染一个列表很无聊。在一个第一人称空间里，它能把站在里面的人直接传送走。

这就是整个项目最终依赖的那个架构决策：路径是权威的，其他一切都只是装饰路径。

一条确定性的堤道成了整个图书馆的坐标系统——一个叫archivePathPoint(bay)的函数，把逻辑上的"bay"索引转换成世界空间位置。书架、雾、天际线、能量通道、相机限制，现在全都从同一条固定路线采样，而不是各自即兴定位。