2024年12月，旧金山一场私人聚会上摆着几台跑着古董操作系统的老式PC，屏幕上是绿色字符拼出的《创世记》文本，旁边斜插出一堆连向注释的线条。这是Project Xanadu当年最经典的演示画面。一位1988到1993年在Autodesk参与过Xanadu开发的老程序员在场，讲了个细节：团队用Smalltalk写好原型后，要交叉编译成C++，编译一次要等一周。
这个细节很容易让人得出一个安慰性结论：Xanadu没做成，是因为那年代硬件太差。但把整个项目的时间线摊开看，这个解释撑不住。
一次重写，四年投入，一个撤资决定
Autodesk 1988年收购XOC八成股权时，承诺18个月内出产品，也就是1989年底交付。团队当时已经把一版名为88.1（后来叫Green）的架构做到接近完成。但他们没有交付它，而是决定推倒重来，转向规模更大的92.1架构（Gold）。
Gold要求同时用ParcPlace Smalltalk和C++维护两套语义等价的代码，测试和实现的负担直接翻倍。18个月的承诺，就是在这次重写里烧掉的。1992年8月，Autodesk新任CEO Carol Bartz 宣布退出Xanadu项目，理由是它不再符合公司聚焦CAD主业的方向。Xanadu方面后来估算，Autodesk四年里投入约500万美元——这是量级估算，不是审计确认的数字，但足够说明规模。1999年，两套历史代码分别开源，成了Udanax Green和Udanax Gold。这时候，Web已经跑了将近十年。
想一次做对一切，就什么都做不出来
Xanadu的野心从来不只是超链接。它要同时解决永久内容寻址、双向链接、完整版本历史、和一套叫“transcopyright”的自动版权计费——读者通过transclusion读取受版权内容时，系统自动结算一笔小额补偿。这不是简单的“每建一条链接就收费”，而是一整套微支付基础设施，得先于超链接本身跑通。
Tim Berners-Lee1989年写Web最初提案时，明确把版权强制执行和复杂计费系统排除在CERN系统的初始需求之外，只求可移植、能跨异构系统搭网关。Web选的是“先能用，再完善”；Xanadu选的是“不完整就不上线”。
局部无需许可的可用性，往往胜过全局正确性。
这句话可以当作两套系统命运分岔的注脚。Web允许链接断掉、允许没有版本历史，用这些“不完美”换来了几乎零协调成本的快速铺开。Xanadu要求每一环都严丝合缝，代价是系统内部耦合度极高——版权计费没做完，版本模型就上不了；版本模型没定型，寻址方案就得跟着改。任何一环推迟，全盘推迟。
- 风险.把多个高难度需求捆绑成必须同时解决的整体架构，任何单点延迟都会拖垮整个交付节奏。
这不完全是硬件问题，是治理问题
老程序员说的“编译一周”是真实的痛苦，但它解释不了为什么团队会在1989年放弃一个接近完工的方案。那是一个决策，不是一个硬件极限。而这个决策背后，还有一层更少被提起的结构：Nelson握着出版权和理念主导权，XOC的工程团队握着实现权，两边权责分裂。愿景不断加码，工程团队只能不断返工。
Yuxi Liu把Xanadu类比成另一个著名的“煮沸海洋”式长期项目——Douglas Lenat的Cyc：都由一位从不改变立场的魅力型领袖主导，都排斥开源，都表现出某种“病态科学”的迹象——项目内部叙事永远是技术精妙、即将完成，外部记录（比如Gary Wolf 1995年对Xanadu的批判性历史记述）看到的却是反复重写、内部冲突、一次次错过的截止日期。两种叙述都得摆在桌上一起看，才算完整。
这个类比有多准？值得说清楚：Cyc到今天仍在封闭运营，Xanadu至少在1999年开源、且理念被后来者部分继承，这点上两者不完全一样。但“领袖意志压过工程节奏”这一条病理，是共通的。
今天Git的内容寻址、笔记软件里的双向链接、静态站点上的悬浮引用，某种程度上都是Xanadu理想的碎片化实现——只是每一片都独立长出来，解决一个具体问题，没人试图一次性做全套。这恰恰印证了当年那个判断：侧边分栏式的transclusion本身是个解在找问题，除了《圣经》文本批评、《哈姆雷特》版本对勘这类需要逐行加注的场景，几乎没人真的需要它。Wikipedia不需要，Reddit不需要，绝大多数博客也不需要。
一个人花几天时间给自己的网站加上局部的transclusion和悬浮注释，和一个团队花几年时间想造出一套通用的、覆盖所有场景的超链接基础设施，这中间的差距不是效率，是目标的形状。前者只解决自己手头的问题，做完就停；后者要求先把宇宙的边界画完，才能画第一条线。半个世纪过去，宇宙的边界还没画完。