书里每死一个人，后面都跟着一句「事情就是这样」。流浪汉第九天死了，最后一句话还在说这不算糟，事情就是这样。冯内古特不给死亡加感叹号，叙事照旧往前走。

我从 2025 年 3 月起把决定论当世界观。一切都有因果，没有偶然，自由意志不存在。这个想法听上去像坏消息，落到生活里却相反。如果每一刻早就在那里，后悔昨天和担心明天都没有意义。我一直觉得，人生的一大痛苦是悔恨过去的同时又恐惧将来。决定论把这两头一起放下了。

「事情就是这样」还有一层意思。它是决定论者的口头禅，说出来像冷淡，其实是承认事情已经定了，不跟它较劲。旁人听着像放弃，自己知道那是省力。已经发生的事不会因为你不接受而改变，愤怒和懊悔只是在多付一笔利息。该做的事照样做，做完之后不回头审自己。

书的写法也值得说。比利在时间里乱跳，1955 年、1963 年、特拉法玛多星球，顺序全乱了。特拉法玛多人看时间像看一片山脉，所有时刻同时摊开在那里。他们的书没有开头和结尾，只有一个个片段。冯内古特就把小说写成那样。形式跟着内容走，如果按年份从头写到尾，特拉法玛多人的时间就没法成立。合上书，我想的还是自己的日子。

好的生活是随性活在当下。不担心明天，也不后悔昨天。读完这本书，我更确定了一点。所有的时刻都在那里，山脉一样，我只是正走在其中一段上。

工具是六月上线的。《看 AI 画像素画》写过它的来历。stevibe 发明了一种视觉评测方法，给模型一张 emoji，让它用 tool call 在 16×16 的网格上逐格画像素画。我觉得有意思，把它做成了网页工具，还能实时围观 AI 作画。

之后的两个多月，我反复折腾这个工具。换上 NES 十六色调色板，通信从 SSE 改成 WebSocket，加了作品画廊。单代理架构太慢，又拆成识图、绘图、验图三个阶段，一百秒压到四十八秒。再往后加风格档，一种风格就是一套完整的画法。

它工作得很好。问题只有一个，模型长大了。

当年那套设计，全建立在一个前提上。模型直接画像素画画不好，整图直出，颜色失控，轮廓糊成一团。只好把画面拆成二百五十六个格子，让模型一格一格填，每步只做一个最小的决定。逐格画是对模型能力的迁就。调色板是迁就，验图兜底也是迁就。

最近我把当年测过的 emoji 扔给刚发布的 Claude Opus 5.5。不用拆格子，不用调色板对照表，它一轮就填完了整幅 16×16 的网格，轮廓干净，颜色克制，像素画的规矩全都在。我盯着屏幕想了一会儿，这个工具没有存在的理由了。

逐格画的全部优势，是当年模型画不好整图。现在整图直出，质量追平甚至超过了流水线。后来 Opus 5.5 干脆写段代码就生成整幅像素画，质量更好，连逐格都省了。少一条链路要维护，少一套提示词要调，工具存在的理由没了。

这类工具的寿命，写在模型的能力曲线上。为模型的短板定制的工具，价值等于缺口的宽度。缺口有多宽，工具就有多大的空间。缺口合拢的那天，再精巧的设计一起作废。三阶段架构、流式推送、验图评分，每一处都花了心思，如今是一次整整齐齐的删除。

所以现在给模型造工具，我会先多问一句。这个缺口还能存在多久。模型的发布节奏摆在那里，大半年就是一代。如果答案撑不过一代模型，就要想清楚，更新换代的那天，自己愿不愿意亲手把它删掉。

工具下线了，我不惋惜。画廊的作品存了档，逐格作画的四篇记录也跟着收了起来。那条能力曲线还在往上走，下一个翻过去的，也许就是我现在引以为豪的东西。

这个前提正在消失。

用 Claude Design 生成一个交互原型，与用 Claude Code 生成一个可运行的实现，成本已经非常接近。Magic Patterns、WeaveFox、Variant 这类工具更进一步，一次提示可以输出多个可运行的方案，让你直接比较。选择发生的节点从「做出来之前」移到了「做出来之后」。决策从一堆草图变成了一堆能跑的实现。我也顺着这个思路做了一个多变体生成器，输入一句话描述你想要的界面，选三种风格，AI 并行生成三个不同风格的完整 UI，并排呈现让你比较。90 种设计风格可按名称搜索，生成结果先完成先展示，AI 还会自动评估各变体并合并出最优版本。

xAI 的 Grok Build 把这个思路推到了极限。一次可以拉起 8 个 Agent 同时工作，各自规划、搜索、写代码，最后用 Arena Mode 自动排名。Agent 自己探索解空间，自动收敛到最优结果。

这不是资源浪费。当并行成本足够低，同时实现所有方向就是最优路径。

丰田生产方式里有个概念叫单件流，核心理念是批量越小、反馈越快、浪费越少。AI 并行生成多变体，某种程度上是把单件流推到了极限。批量等于全集，反馈立即发生。你不再需要判断哪个方案值得实现，因为所有方案都已经实现了。小孩子才做选择，大人全都要。多变体生成器的名字就来自这句话。当并行生成的成本足够低，这句话就从玩笑变成了工程方法。

传统的原型工作流是：想法 → 草图 → 低保真原型 → 评审 → 选择一个方向 → 实现。每一步都在做选择，每一个选择都在排除可能性。AI 带来的新工作流是：想法 → 并行生成多个可运行实现 → 自动筛选 → 人做最终选择。多变体生成器就是这个流程的缩影。你只给一句话，工具同时出三版风格各异的界面，你只需要看哪个好。选择的次数变少了，但选择基于的信息量变大了。你不再是在几张草图里猜哪个好，而是在几个能跑的程序里看哪个好。

这种转变的核心不是「AI 做得快」，而是「选择发生在实现之后」。传统流程里，选择是最昂贵的动作，因为选错了要重来。AI 把选择的成本压到了接近零。选错了？再生成一批。并行化有两种基本模式。一种是切分，把一个任务拆成多个独立子任务，每个 Agent 负责一块，最后合并。比如实现一个仪表盘，一个 Agent 写后端 API，一个写前端组件，一个写数据库迁移，三者并行完成后合成。另一种是投票，同一任务发给多个 Agent，每个用不同的 prompt 或不同的模型独立实现，然后比较输出选最优。多变体生成器用的是投票模式，同一个界面描述发给三次 AI，每次附带不同的风格指令，最后由人做最终裁决。

Anthropic 的 Agent 研究报告把这两种模式称为 sectioning 和 voting。两种模式组合起来，就能覆盖大多数并行场景。切分解决的是「怎么做」的并行，投票解决的是「做什么」的并行。原型时代只需要切分，因为方向是提前定好的。多变体时代还需要投票，因为方向本身就是并行探索的。

并行生成也改变了评估的方式。人工评审草图的价值在下降，Agent 自动筛选可运行结果的价值在上升。让人等程序先跑一轮筛选，把明显不行的去掉，最后交给人的是少量的高质量候选。新的核心能力也变了。并行生成需要能控制多个 Agent 不打架、不重复工作。结果比对需要能判断哪个实现更好，标准是什么。自动收敛需要能识别不同方案的共同点和差异，合并有效部分。这些能力在原型时代不存在，因为原型时代一次只做一版。

Amp 在 2026 年 2 月宣布关闭编辑器插件，理由是模型本身已经足够强大，不再需要编辑器辅助这层脚手架。原型也是一层脚手架。当「直接实现」的成本接近「先做个原型」的成本，原型的存在根基就消失了。原型的假设是「实现是昂贵的」，这个前提已经不在了。

但原型和 Demo 不是同一回事。原型用来降低决策成本，在实现太贵时验证方向。Demo 用来展示和沟通，证明一个想法可以被实现。原型假设的是实现很贵，Demo 假设的是沟通很重要。AI 让生成 Demo 的成本几乎为零。为一个想法生成一个可运行的界面、一个交互流程或一套 API 已经不需要人写多少代码。这些 Demo 不是产品，但它们真实可运行。它们承担了原型曾经的功能，又超出了原型的范畴。

Aspire 团队的实践说清楚了其中的区别。他们用 AI 做生产工程，不是做 Demo。生产软件需要面对真正的代码库、客户和维护成本。Demo 不需要。生产变便宜了，但维护没有。Demo 没有维护负担，所以它不受「实现贵」这个前提的约束。

每一代工具死亡，死掉的都是背后的假设。原型死于实现变便宜。替代原型的不是更快的原型工具，而是全新的工作流：先全部做出来，再选择。

本文假设你已经有一台国内云服务器，能用 SSH 登录，会跑基本命令。下面三种方式按"优雅程度"递进，最后一种实测速度差距悬殊。

方式一：修改脚本里的 GitHub 地址

最直白的做法，把脚本下载下来手动改地址。

wget https://bun.sh/install -O bun-install.sh
# 编辑 bun-install.sh，把 GITHUB 默认值改成 gh-proxy 镜像
# GITHUB=${GITHUB-"https://hk.gh-proxy.com/https://github.com"}
bash bun-install.sh

能用，但绕远路。

方式二：通过环境变量覆盖（无需改文件）

读一下安装脚本就会发现，脚本本身就把 GITHUB 设计成可被环境变量覆盖：

GITHUB=${GITHUB-"https://github.com"}
github_repo="$GITHUB/oven-sh/bun"

${VAR-default} 是 shell 的默认值语法：环境里有 GITHUB 就用环境的，没有才用默认。所以一行就够了：

curl -fsSL https://bun.sh/install | GITHUB="https://hk.gh-proxy.com/https://github.com" bash

不下载临时文件，不留垃圾。这条思路适用于任何"读脚本前先看看作者留没留口子"的场景。

方式三：用自己的境外 VPS 走 SOCKS 代理（推荐）

公益镜像如 gh-proxy.com 有限速、可能跑路、可能被封。如果你已经有一台境外 VPS（比如 Vultr、搬瓦工、腾讯云香港轻量，月付几美元就能拿到），并且配好了 SSH 免密登录，就可以用 SSH 动态转发开一个 SOCKS5 端口：

# 1. 临时建立到境外 VPS 的 SOCKS5 隧道（-f 后台运行，-N 不执行命令）
ssh -fN -D 127.0.0.1:1080 your-overseas-host

# 2. 让安装脚本走代理
ALL_PROXY=socks5h://127.0.0.1:1080 bash -c "$(curl -fsSL --socks5-hostname 127.0.0.1:1080 https://bun.sh/install)"

# 3. 用完记得关掉，否则隧道会一直挂在后台
pkill -f 'ssh -fN -D 127.0.0.1:1080'

socks5h 和 --socks5-hostname 表示让 DNS 解析也走代理，避免国内 DNS 污染导致解析到错误地址。

这套方案的好处：

• 公益镜像通常被很多人共用并限速，而你自己的 VPS 带宽只有你在用，速度通常远快于公益 CDN。
• 不依赖任何第三方服务，自己的机器自己掌控。
• 通用性强，套到 nvm、rustup、deno、ollama 等任何 GitHub 安装脚本都生效。

实测对比

同一台上海 VPS 安装 Bun 1.3.13：

差了约 16 倍。

三种方式各有归宿：临时一次性安装用方式二最省事；长期在国内开发，方式三一次配置长期受益；方式一只在你想看清脚本逻辑时才有意义。如果你在国内长期搞开发，配一台便宜的境外小鸡当跳板，回报远超那点月租。

顺手补一句：如果你还没机器，先把一台稳定的境外轻量服务器配起来最省心。像腾讯云 Lighthouse 这种按场景卖的轻量机型，就很适合拿来做这类代理跳板和临时开发机。

如果你正好想找一台境外轻量服务器来做这件事，可以直接看这个腾讯云 Lighthouse 活动页： 【腾讯云】Lighthouse助力跨境电商业务扬帆出海。它和这里的场景是贴合的：拿一台香港轻量做跳板、代理、测试机都比较顺手。

然后我开始整理我的博客和书架。删除了大部分和技术相关的文章，也开始清理那些我一直想读但还没读的技术书籍。

我其实很享受阅读技术书籍。我喜欢那种学到新东西的感觉，喜欢深入一个技术领域去探索。但问题是，现在我不再需要从书里学那些纯粹技术型的知识了。

之前我会买「TypeScript 深入解析」或者「React 完全指南」，因为我需要靠这些知识来工作。我需要知道某个特性怎么用、某个 API 的细节、某种模式什么时候该用。这些知识是稀缺的，是我必须自己去掌握的。

但现在，这些问题我都可以问 AI。它能告诉我 TypeScript 的任何细节，能帮我写出符合最佳实践的 React 代码。我不再需要花时间读这些书来掌握这些知识。

技术书的价值并未消亡，只是对我而言，纯粹的技术知识已不再稀贵。我不再需要为了掌握那些细节而去阅读。

所以那些还没读的技术书，我就没必要留了。清理书架的时候，我一本本地移除它们。

删除博客里的技术文章也是一样的道理。我过去写那些「怎样用 TypeScript 实现某个功能」的文章，因为这是有价值的知识分享。但现在，任何人都能用 AI 生成这些东西。我再写这样的文章，就没有意义了。

现在我更关心的，是那些 AI 没有办法替代的东西。为什么你需要这样的工具？这个方案的权衡是什么？在选择技术时应该考虑什么？这些问题的答案来自经验和思考，而不是技术细节。

这个转变带来了现实的收获。我的生产力提升了，因为我不再需要在查资料和学细节这些事情上花时间了。我也不需要追随最新的技术进展，去担心自己是否掌握了最新的框架或特性。对于自己未知的领域，反而能毫无畏惧地投入其中，因为我知道 AI 能帮我快速掌握基础。原本用来钻研代码细节的时间，现在转而用来思考问题本身。

我还会读书，也还会写。但读和写的东西会不一样。

作为一部小说，作者又在其中塞入了太多哲学与价值观的讨论。阅读过程中，多次想要放弃。作为作者的最后一本书，我能感觉到，作者想把自己整个的人生体会和思想，通过这本书表现出来。虽然作者在这本书中，写到对说教式教育的反感，在阅读本书的过程中，我仍然感受到某种说教的感觉，我不喜欢这种说教式的感觉。

这本书中有趣的地方在于作者对东方文化的兴趣，其中出现的静坐冥想和中国文化，带给我一种异域的氛围感。

而作为很重要的玻璃球游戏概念，始终困扰着我，每次看到玻璃球游戏，都很疑惑。对于玻璃球游戏中，需要将不同的事物相互关联的说法，让我想到了候世达的《表象与本质》，思维的本质是类比的观点。

而通过克乃西特这一角色，我感觉作者试图呼吁人们，不要固步自封，满足现状，要对不同的观点和文化更加包容，尊崇自己的内心，而不是被外部的存在而影响。就像书中对于太极这一观点的阐述，完美和巅峰，往往意味着衰退的开始，唯有包容与融合，才能带来长久的和谐。结合当前俄乌战争、以及中美之间的对抗，愈发的感觉其中的警示性作用。

对于这本书，之所以难读和不算喜欢，我想更多的还是来自于自身的局限性，导致我难以体验，或者拒绝接受书中的一些想法和表达形式，但愿以后能够更喜欢这本书。

在译本序中，译者写到：“它用一系列象征和譬喻编织起一种哲学上的乌托邦设想，虚构了一个发生在二十世纪后未来世界的寓言。”对于结局，刚刚回归世俗世界的克乃西特就遭遇了结局，这样的结局意味着什么？

在《传统即创造》这本书中，读到一种名为借景式庭园的设计风格。

有一种庭园叫“借景式庭园”。设计者将园外风光巧妙纳入园内，让其成为组成庭园的一部分。如此一来，即便庭园面积有限，也能欣赏到磅礴景致。外部自然美与内部人工美的绝妙搭配，自会呈现一派和谐景象。

这种设计思路，本身就依赖于外部事物。时至今日，随着时代的变迁，外部的景物也逐渐的产生了变化，庭园也无法体现当时的设计。

在软件开发中，当我们的服务，或者能力，依赖于第三方的时候，同样也会存在这个问题。第三方依赖不能被视为稳定的。

例如，一些个人开发者开发的微博第三方客户端，随着微博政策的变化，随时可能被扼杀。

读《王羲之放鹅记》时，看到一段关于周昉画画方式的小故事，故事如下：

周昉和韩幹都是唐朝的大画家。周昉善画人物、佛像，称绝一时。长安城里新修章明寺，请周昉画壁画。画完以后，京城人都涌入寺内观看。有人称好，也有人说某些地方不够好。周昉躲在屋里偷听，把大家的意见都记下来，等晚上人散去后偷偷修改。这样改了一个月，来人再看，无不惊叹画得精妙。

周昉躲在屋后偷听，收集意见，然后，按照收集的意见，修改画作这件事，像极了产品开发中的快速迭代。

在快速迭代中，收集用户操作信息，相当于躲在屋后偷听；获取反馈，相当于收集意见；发布新版本，相当于修改画作。

前端里的 Babel 也是类似的角色。它把新的 JavaScript 语法转换成更多环境能理解的代码，让不同浏览器和运行时之间的语言鸿沟变得没那么明显。用 Babel Fish 来命名这样一个工具，确实很贴切。

Babel 这个名字也的确来自这里。

Babel 一词来源于道格拉斯·亚当斯（Douglas Adams）所著的《银河系漫游指南》里的通天鱼（Babel Fish），它是一个能帮助人类理解任何语言的虚构物种，同时也恰好向通天塔（Babel Tower）的故事致敬。《创世纪》中正是通天塔的坠落造就了各种各样的语言。

这个设定本身就很妙。BBC 介绍 Babel Fish 时，用很短的话就把它说清了：它能把一种语言直接变成另一种语言，让原本无法沟通的物种也能彼此听懂。这样回头看 Babel 这个名字，会觉得它几乎不可能有比这更合适的来源。

去找图的时候，又顺手看了一眼 Wikimedia Commons 上的 Babel Fish 图标。那种老图标的风格，倒也挺符合这篇小文章的气质。书的页面也一起翻到了，是 Open Library 上的《The Hitchhiker's Guide to the Galaxy》。

关于 Babel 名称来源的转述，先记这个出处。