2024年12月，我在旧金山拜访期间，幸运地获邀参加了一场仅在那里可能出现的聚会，庆祝超媒体（hypermedia）先驱泰德·尼尔森（Ted Nelson）1974年的宣言《计算机自由/梦幻机器》（Computer Lib/Dream Machines）问世50周年，该宣言推崇萨纳杜计划（Project Xanadu）的超文本（hypertext）愿景。我已在英文维基百科贡献20年，断断续续经营Gwern.net也已15年，自然不会错过这场聚集了众多对超文本有强烈看法的人的聚会。

2024年12月，我在旧金山参加了一场专属于那里的聚会：庆祝泰德·尼尔森1974年的超媒体宣言《计算机解放/梦幻机器》问世50周年。这本书推崇的是Project Xanadu的超文本愿景。我已在英文维基百科贡献了20年，断断续续运营Gwern.net也有15年，自然不会错过这场云集了众多超文本爱好者的派对。

我们的东道主詹姆斯收藏了大量尼尔森的纪念品：不仅有那本书的实体版（比想象中厚重得多，类似缩印版牛津词典，还得配放大镜阅读），还有他1997年的著作《信息的未来》，以及他在斯沃斯莫尔学院时期用油印机印制的杂志。最令人惊叹的是几台运行着不同版本Xanadu实现的古董电脑。

当时87岁的泰德·尼尔森未能到场，但幸运的是，一位Autodesk时期的Xanadu前程序员（约1988年至1993年）也在现场，我们得以听他讲了不少往事。

这些故事提醒我们，虽然我们常浪漫化早期计算机时代，但当时的硬件限制极其严苛，严重阻碍了高效开发。许多过去软件系统的遗憾，在考虑到人们为规避限制所耗费的时间和巧思后，就更容易理解了。比如1982年麦克罗伊为把拼写检查器塞进1MB内存，花了数月设计优化算法，这放在今天只需几行JavaScript代码（甚至能让大语言模型完成）。

这位程序员提到，他们最初用Smalltalk原型化Xanadu——这门语言高效易用，其面向对象模型与超媒体完美契合——但之后必须交叉编译成C++，而编译过程整整花了一周。不是一分钟、一小时，甚至不是一天，而是一周。我原以为Gwern.net数小时的编译时间已经够拖慢开发速度了，相比之下简直不值一提。他还得花大量时间处理C++的奇怪问题和编译错误。

让这些系统在当时个人电脑上跑起来本身就是个挑战，这也是举办这场聚会的原因之一。

我得承认，自己曾疑惑Autodesk投入了多年全职人力，Xanadu却几乎没什么成果，而Gwern.net上实现各种客户端嵌入或弹出功能，通常只需Said Achmiz花几天时间。但亲耳听到这些一线故事后，我才正确看待了这件事，意识到当时的计算资源有多匮乏。比CPU更糟的是存储：我现在随手就能托管需要的PDF、PostScript或HTML文件，但我托管的大量文档大小，都超过了1990年中期个人电脑的总硬盘容量（当时可能只有50MB）。而Gwern.net的Markdown源文件本身就有约40MB，注释是它的两倍，最终整个站点达221438MB。

那些大学杂志令人惊喜，翻阅起来很有趣：年轻的泰德就很爱写作，还经常给出各种建议。有人提到尼尔森曾梦想当好莱坞导演，后悔入了技术行当，我觉得这很合理，能解释他开发软件的“作者导演”风格——比如他坚持说自己“不是程序员”，以及使用“编辑决策列表”这类电影剪辑隐喻。

我之前从未认真读过《计算机解放/梦幻机器》，这次翻了几页。这本书篇幅惊人，用了多栏排版来塞下更多内容：尼尔森没法假设读者懂计算机，得从字节、文件这些基础概念讲起，年纪大的人读起来真得配个放大镜。

后来那本更冷门的《信息的未来》结构也很特别，章节可以按多种顺序阅读，还有个核心总结章。

Yuxi Liu指出，Xanadu很像另一个著名的长期宏大项目：与数据库和AI紧密关联、有魅力十足且从不改变想法的领导者、反感开源、出现了类似“病态科学”迹象的道格拉斯·莱纳特的Cyc项目。我仔细琢磨并重读Xanadu相关资料后，也认同这个对比。

我简单摆弄了下那些Xanadu电脑，惊讶于它们居然能运行，但我和大多数来宾都很快就放弃了。界面太陌生了，我们需要詹姆斯做个演示才行：超文本系统本就不适合直接探索，更何况运行在没人用过25年的操作系统上。

不过我不用多操作，只要看屏幕上显示的Xanadu经典演示——打开《创世记》，著名的经文向右延伸出锯齿线表示嵌入或注释——就突然反应过来：

“天啊——这完全没法读。”

那些线条是混乱的视觉干扰，尤其是交叉缠绕的时候（这是侧边注布局的老问题，轮廓线让情况更糟）。屏幕太小，所有“侧边注”都看不清。哪怕只是滚动页面，在很多位置下，那些线条都会让你什么都读不了。一个经常让人什么都看不清的文档界面，怎么会曾被认为是个好主意？哪怕是在我4K显示器这样的大屏幕上，我也不想用这样的设计。

接着我想到演示选的文本，意识到界面不是真正的问题，这么多年来的问题也不在全团队。

整个“并排范围嵌入”概念，本身就是个寻找问题的解决方案。

针对特定范围的嵌入和注释，用《创世记》来演示确实合理：那里每行都有详细注释，还有大量圣经批判用来梳理多个矛盾文本拼接而成的内容（比如著名的多个创世故事矛盾）。但我转念想到：“嘿，Gwern.net也能做侧边注、范围嵌入/注释和双向反向链接啊，我那篇《苏珊娜·德拉热》短篇分析里就这么做了！”突然就意识到：我们能做，但大多时候不做，因为根本没人需要。看看泰德·尼尔森的“平行文档示例”就更清楚了：还是文本批判（圣经、《哈姆雷特》、“罗生门”小说vs电影），牵强的例子（弗吉尼亚权利宣言影响美国权利法案），还有很可疑的例子——圣徒列表、机构内部电话记录、喜剧电视节目……

世界上几乎没多少文本真的需要被逐行批注，或者需要嵌入特定行或段落；也没多少人在做层层嵌套的塔木德式注释。大多数实际引用都是引用整个目标。就算是这类引用，99%我们也不想看到，剩下1%也不知道怎么组织，因为各自的用途可能完全不同。（看看网络评论就知道了：要按日期排、按热度排、按长度排，还是按作者是否回复排？）

回头看，《计算机解放/梦幻机器》和《信息的未来》里，我都没看到任何纸面上的“嵌入”实例。尼尔森完全可以在自己的书里用任何并排布局或范围嵌入，因为软件不是障碍：他是手工排版，想画什么、插什么、怎么排都行。但他没这么做，原因很简单——对书籍来说，这根本没那么有用，连他自己的书都不需要。（能直接引用早先的段落，就用不着嵌入。）

哪怕是电影，把两个画面并排放在一起让一个“评论”另一个很容易，但也很少这么做。电影不用水平或垂直并置，而是用时间这个第三维度，发展出丰富的剪辑和其他转场技巧，实现类似效果（要是不看《战舰波将金号》之前的电影，我们根本意识不到这些技巧的存在）。空间并置只在某些场景下用，远不是默认做法。只有类似画中画布局才是常规操作，主要场景是直播——没法多角度拍摄再连贯剪辑，比如直播访谈时常规做法是两人头像同时出现，但后期剪辑时往往会改成逐切序列。主播没法轻易“剪辑”，因为要忙着直播，没有大量素材可切，也没有专业团队操作，但如果做“精彩集锦”，就会重新编排甚至放大细节。（我敢打赌，Hololive主播在投资数千万美元的大型年会上表演时，不会用直播式的并排格式，而是用典型的演唱会运镜，就像初音未来演唱会那样。）值得注意的是，NBA、NFL比赛或大都会歌剧院高清直播这类预算极高、对质量要求顶级的直播，有大量摄像机和导演及团队，也不会满足于静态画中画或并排布局，而是快速在不同摄像机之间切换单一画面，跟踪动作，提前调度机位创造新角度，再根据比赛节奏创造有意义的节律。

这也是为什么我们直到2023年左右，因为要做短篇文学分析，才给Gwern.net加上那种特定嵌入功能。我不需要，英文维基百科不需要，Reddit不需要，Twitter不需要，几乎100%的个人博客都不需要……除非你在做文本文学批评或注释，而这几乎占不到万维网的0%（2025年或1989年都一样）。那些线条看着酷炫未来感十足，但一想到要在实际的Gwern.net文章里用、读起来会是什么样，我就头疼。

Xanadu著名的界面/体验是种“科幻界面”，就像《少数派报告》里的3D手势界面或《雪崩》里的虚拟现实：所有人看着都惊叹于它的酷炫，但实际用起来糟透了，还会让你得“大猩猩手臂”症。你试下原型或 mockup，刚用没多久就会意识到这根本行不通，只能彻底扔掉。

这让我想起好莱坞导演的那个说法：可以说Project Xanadu就是好莱坞导演想象中的万维网。只有从没真的用它做过实际项目的人，才会相信它。如果泰德·尼尔森没那么有魅力、没那么会写、对自己的愿景没那么笃定，这个问题早就清楚了。正因为不是这样，他和道格拉斯·恩格尔巴特一样，成了坎宁安定律的活例证：成了那种因为在一个重要议题上错得如此离谱，反而激励其他人做对的历史人物。

事实上，这也解释了Xanadu一直让我困惑的一点：它对版权的强调。很难想象现代世界里还有什么比现行的极端版权法更有害、更抵触实用超文本系统的了，但Xanadu的17条原则里，花在让网络对版权方安全上的篇幅，比“嵌入”这种小事多得多——它需要支持任意层级的微支付，需要默认许可，要摒弃网络中立，允许无许可嵌入任意资源等等。

Xanadu 17条原则（维基百科版） 1. 每个Xanadu服务器都有唯一安全的标识。 2. 每个Xanadu服务器可独立运行，也可联网运行。 3. 每个用户都有唯一安全的标识。 4. 每个用户都可以搜索、检索、创建和存储文档。 5. 每个文档可由任意数量的部分组成，每个部分可以是任意数据类型。 6. 每个文档可以包含任意类型的链接，包括指向系统中所有者可访问的其他文档的虚拟副本（“嵌入”）。 7. 链接可见，且可以从所有端点跟随。 8. 链接到文档的权限通过发布行为明确授予。 9. 每个文档都可以在任意粒度设置版税机制，确保访问任何部分（包括全部或部分文档的虚拟副本“嵌入”）时都能获得支付。 10. 每个文档都有唯一安全的标识。 11. 每个文档都可以有安全访问控制。 12. 每个文档都可以快速搜索、存储和检索，用户无需知道其物理存储位置。 13. 每个文档都会自动移动到适合其从任意给定位置访问频率的物理存储中。 14. 每个文档都会自动冗余存储，即使发生灾难也能保持可用。 15. 每个Xanadu服务提供商可以按自己选择的任何费率向用户收取文档存储、检索和发布费用。 16. 每笔交易都是安全的，且只能由交易各方审计。 17. Xanadu客户端-服务器通信协议是公开发布的标准。 鼓励第三方软件开发和集成。

我一直想不通怎么会有人觉得这些既可能又值得：版权方当然会拒绝遵守任何这些内容，会恐惧厌恶任何Xanadu，因为它会摧毁无数商业模式、知识产权体系和交易，还会立刻陷入反公地悲剧、钉子户、各方掣肘等问题。但如果从骨子里觉得自己是好莱坞导演，你就会对版权的神圣性有强烈执念，会坚决反对从嵌入逻辑推导出自由软件/开源（尽管有最后一条原则，尼尔森似乎从不相信自由开源软件，还坚持要签保密协议），会相信某种语义网——真的指望什么都行得通。

而现实是80亿人上网、世界大部分运行在互联网上之后的样子：一个噩梦般的黑暗森林，所有可能出错的事每天都会出无数次；你相信的每一个不变式，在世界的某个角落都会被打破；每一个好功能——比如反向链接——都会被垃圾邮件发送者、蠢货、恶棍、国家行为体、突发漏洞或黑客无情滥用。

那些原则大多只有在不实际落地的时候才说得通，真做起来就会发现很多不仅价值存疑、会被各方强烈反对，甚至直接违法。（最能体现去中心化文件存储原则的系统之一是Freenet，它刚上线就因为儿童色情内容臭名昭著。）

所以对我来说，Project Xanadu是一个案例：说明设计者必须在投入太多之前，先做mockup和原型。Xanadu不是“更糟即更好”的受害者，它只是个寻找问题的解决方案。（类似的情况似乎也适用于Arbital：它只有一个真实用户，也就是构想它的埃利泽·尤德科夫斯基，但他很难传达愿景、做出清晰的原型和用例，也没按需要做mockup；和Xanadu一样，它本该是长期非营利自由开源项目，却被塞进了软件创业公司的框架里。）

那些Xanadu的演示和用例，哪怕用剪刀胶水在纸上摆出来过吗？为什么永远只有《创世记》这种极端不具代表性的用例？要是你试着把普通技术文档或手边的杂志做成一堆范围嵌入，效果会怎么样？有多少文本能、又应该被嵌入内容穿插？哪怕在这篇讲Xanadu的文章里，到目前为止我也只需要一处从别处嵌入的大段内容，就是从维基百科复制的Xanadu原则列表——这已经用弹出链接覆盖了，直接内联也很简单。

我觉得真做起来，答案很快就是：“是的，我需要超链接，这太有用了；我需要能链接任意媒体类型，比如图片、音频、视频，或者书籍的特定页码；我需要不会链接失效的链接；我需要脚本语言（Xanadu对此只字未提），但……我真的不需要其他大部分东西。如果我在做Google Docs那样的分布式协作编辑器，可能才需要CRDT或Xanadu类似的‘enfilades’，但我的已发布写作完全用不上！”

对我而言，开始做Gwern.net时，几乎所有功能都是我有了实际需求才做的（主要是我懒）；哪怕和Said Achmiz合作，我们的做法也是等有了几个用例，再一起实现，同时覆盖所有需求。（ invariably，随着Gwern.net变得庞大复杂，我们会发现边缘情况，不得不修改设计，很多改动最后只能放弃。）

对于超文本，我问自己：“我需要什么是一个基础博客HTML页或英文维基百科页提供不了的？”答案是：“我不需要随便嵌入一个URL里的几个段落。我不需要像GNU Info鼓励的那样，写一堆1句话的原子页面，目录比内容还长。我需要的是某种摘要或抽象。我需要读者能尽可能快、无摩擦地浏览，快速扫过参考文献或追踪感兴趣的引用。我需要类似Lupin的维基百科弹出工具——只要随意移动鼠标就能导航维基百科，但要更强大。”

我会说Xanadu界面的缺陷在于把嵌入当成“水平”并排，假设所有读写都必须在文本的最原始层面进行（所以搞出了“转轮”之类的东西），而它本该是“垂直”的，用弹出框，在不同抽象层级“放大”“缩小”（链接图标→标题→摘要→章节等），这会带来完全不同的考量——指定任意范围的重要性会低得多，因为任何关键范围都可以直接提升到更高层级。

一旦有了弹出框提供无缝导航，你其实到处都在用嵌入——只不过是在弹出框里。而一旦你全力为所有内容提供摘要，自然会泛化它：如果一个URL有两个版本，一个“小”（摘要）一个“大”（完整内容），为什么不能有“中”的呢？

这里没有自然终点，所以你可以直接采用大纲式的“语义缩放”层级视图。这催生了很多优雅的Gwern.net设计模式：比如折叠/展开功能，允许对从章节到段落句子的所有内容就地缩放；比如标签目录（大量用嵌入摘要代替完整链接，生成“注释书目”）；比如反向链接，比Xanadu或英文维基百科的反向链接好得多——它会做“反向”嵌入，显示其他页面里的嵌入/链接上下文。还有本地归档系统，不仅链接不会断，还能弹出并嵌入清理后的本地归档版本来“预览”很多URL。

讨论的气氛是“既佩服又摇头”：不少人承认 Xanadu 像疯狂的超前工程，却认为它并非死于“太理想”或“ Worse is Better”，而是版权、微支付等真实世界的约束让它无路可走；另一边则坚持它看到的痛点至今仍在。技术评论倾向于把跨文档引用的理念拆出来，放到 Git、diff 和视频剪辑这些实际工具里检验。

Xanadu 预见了今天依然存在的日常痛处

• 直接反驳“它在寻找问题”的判断：手机没空间但笔记本空着、跨设备统一备份很麻烦、给家人传文件仍不顺手、担心被云厂商锁定——这些日常问题与 Xanadu 想解决的完全重合，而且今天并未好转。（认可度：少数人，但反驳很切中要害） > 手机没空间而笔记本有大量空间；备份、分享、不被供应商锁死——这些麻烦正是 Xanadu 的原则早就尝试对付的。（@Rygian）

跨文档引用本身没问题，错的是把字节偏移当锚点

• 把跨文档引用建立在字节偏移上确实不适合 Web，但如果换成有意义的知识单位——比如大纲条目、术语定义——就能在大型工程里用起来；他本人就有基于这种思路的成功实现。（认可度：少数人）

  被引用的单位若是一个大纲条目而不是某个字节位置，这种机制立刻会变得很实际；Xanadu 的失败是没有选好该封装的知识单位。（@Rochus）

• 更温和的路径是“在 Git 上增量长出 Xanadu”：并排的 diff 视图本身就是某种跨文档引用；只要重构 Git 的索引，再配合 CRDT 合并，就能逐步实现双向链接和跨仓库元数据检索，未必需要重建整个 Xanadu。（认可度：少数人）

  Xanadu 式的能力离我们不远，缺的不是天降一大步，而是许多小而扎实的局部改进。（@gritzko）

真正让 Xanadu 走投无路的是版权

• 即便技术上可以做到“无损引用”，法律也不允许：想要引用别人的影片或书稿，哪怕只取一小段，都要面对无穷无尽的逐案谈判与判例。Xanadu 想靠预置结算解决版权，结果只会让盗版更容易，让开放标准更不可能。（认可度：较多人） > 你没法直接从别人的原始素材里取一段做评论；这从来不是技术问题，而是版权不同意。（@kmeisthax）

幸好 Xanadu 没成功：把知识变成付费围墙才是最可怕的结局

• 极少数人庆幸 Xanadu 失败：它设计的每一条内容都带微支付，甚至读一页网页都要交钱，最终只会形成一座只让富人进入的知识围城。今天的 Web 再乱，至少还保住了开放的公共讨论空间。（认可度：少数人） > 如果每个词都挂上价格标签，交流就会死掉；它被丢进历史垃圾桶，我实在庆幸。（@nekusar）

Xanadu 的价值不是产品，而是批量提供思想

• 即使整个计划充满了内在矛盾，也不能否认它向世界泼出了大量想法；真正被后人采用的往往只是一小部分，但如果没有那一百个想法，十个可用的也不存在。（认可度：少数人） > 你必须先给人一百个想法，他们才可能真正用上十个；他恰好做到了这一点。（@pmkary）

有价值的补充

• 现代非线性视频剪辑就是 Xanadu 式“无损引用”的日常版本：原始素材全部保留，剪辑只是在时间轴上引用它们，直到导出才生成成品；但这套流程只适用于自己的素材，一旦想引用别人的素材就撞上版权墙。
• Web 能普及，部分功劳要记在妥协上：Tim Berners-Lee 后来把 URL 名字里的“通用”改成“统一”，这种不值得宣传的小让步，恰恰是让系统得以部署的关键。
• 讨论时不要混淆：GitHub 上有一个同名的 ATS-Xanadu 项目，属于编程语言研究，和 Ted Nelson 的超文本工程没有任何关系。