DHH、Mitchell Hashimoto、antirez：同一周，三种系统观

本期摘要覆盖 2026 年 5 月 26 日至 6 月 1 日，来自 DHH（Ruby on Rails 作者）、Mitchell Hashimoto（Ghostty / Terraform 作者）、antirez（Redis 作者）在 X 和公开博客的技术表态。三位作者分别触及了同一个底层问题：当 AI 工具快速普及，你如何判断它在某个任务上是否真的好用，而不只是「看起来在工作」。

DHH：云不是信仰，on-prem 才是「Keep it simple」

5 月 26 日，37signals 的 Basecamp 5 正式上线。DHH 发推宣布新增了旧金山圣何塞数据中心，Basecamp 现在在芝加哥、弗吉尼亚、阿姆斯特丹、圣何塞四地运行全自有机柜，uptime 记录在此之前已连续超 22 个月。1

Just show the damn product. Just list the features. Yes, it's agent accessible, but it's not agent hysteric.

这句话是 Basecamp 5 新官网的设计原则。DHH 明确拒绝「AI hysteria」驱动的产品设计——做 agent 集成，但不被它绑架产品主线。

同一天他还发了一张 2004 年和 2026 年 Basecamp 界面的对比截图，配文「Keep it simple」。2 22 年里界面在演化，但信息层级没有膨胀——这背后有一条持续的产品节制哲学。

在编辑器选型上，Basecamp 5 把 Trix 替换成了基于 Meta 开源 Lexical 工具包的 Lexxy。DHH 的理由是：表格、Markdown、代码高亮。3 技术选型的驱动力是具体的功能缺口，不是框架流行度。

基础设施侧，DHH 本周还披露了一个运营数据：Omarchy（他做的 Linux 桌面系统项目）在过去 30 天通过 Cloudflare 服务了 600 TB 流量，环比增长 13%。4 这个项目从 0 开始，目标是让系统完整安装时间从 15 分钟→5 分钟→1 分钟，现在接近 1 分钟。5 他把这个目标本身当架构约束——「用来衡量设计是否足够简单」。

6 月 1 日，DHH 在博客发文阐述了他对 AI 与开源关系的判断：6

开源运动用几十年争取「所有人都能修改软件」的权利。现在 AI 第一次让这个愿景真正落地——但「所有人」原来并不包括所有人。

他的核心论点是：反对 AI 辅助贡献的运动本质是保护主义，是原有程序员圈子在维护稀缺性特权。这跟频道关注的「架构决策」直接相关——DHH 在 on-prem 和开源民主化两件事上，都在用相同的逻辑做选择：工具服务目标，不反过来绑架目标。

콘텐츠 카드를 불러오는 중…

Mitchell Hashimoto：75 倍差距说明了什么

Mitchell Hashimoto 是 Ghostty（终端模拟器）和 Terraform、Vagrant 的作者，本周发出了本月互动量最高的帖子之一。7

他做了一个实验：用 Go 写了一个故意很慢的渲染器（88ms/帧，150,000 次内存分配），然后启动 agent 循环优化，预算不限，只有一条约束：不能改输入数据结构和公开 API。

四小时、$350 之后，agent 把帧时间从 88ms 压到了 1.5ms，内存分配从 150K 降到约 500。

听起来很好，对吗？他手写移植的渲染器，同样的 benchmark：0.02ms，0 次内存分配。

差距：75 倍吞吐量。

他的结论不是「AI 没用」，而是：

不理解系统的人会接受 1.5ms 是了不起的成果。理解系统的人马上能看到更好的方案，做到大约 75 倍的改善。

这跟他 5 月中那篇更早的长推呼应——他把这种现象叫做「AI psychosis」8：

基础设施领域的云迁移时期，我们学过一次教训：可以把自己用自动化做成一台高度弹性的灾难机器。系统在局部指标上看起来很健康，整体却在变得无法理解。Bug 报告下降，但潜在风险在爆炸。

他把这个比喻直接平移到现在的 AI 开发：测试覆盖率上升，语义理解在下降。

同期另一个持续性观点：依赖管理。5 月 20 日（本期窗口外但提供背景）9 他写到了一个他持续了 10 年的立场：

Fork 你的依赖，裁剪成你需要的，永不升级——除非有具体的 commit 是你需要的。供应链攻击频发的现在，他感觉这个方向已经被证明。

他的核心逻辑：更新依赖的风险远大于留着已知的 latent bug（已知的可以监控 CVE，未知的更新引入你没注意到的变化）。在 HashiCorp 时，工程师要换依赖必须先回答「给我看我们需要的那个 commit」。

产品设计侧，他本周对 AI 生成 UI 的识别特征发表了具体判断。10 他说现在 AI 生成设计的显眼特征是：「细彩色边框、渐变、光晕效果、太多不同字号、小字太小、内边距对齐不一致，尤其是垂直方向」。更早的帖子里，他把衬线字体搭斜体列为「现在最新的 AI 设计泄密词」。11

콘텐츠 카드를 불러오는 중…

antirez：为什么用 C 写推理引擎，为什么只支持一个模型

antirez 是 Redis 作者，今年在做一个叫 DwarfStar（ds4）的本地 LLM 推理引擎，专门针对 DeepSeek V4 Flash，12.8k GitHub star，本周仍在活跃开发。12

技术选型的第一个问题：为什么是 C？

DwarfStar 完全不依赖 llama.cpp 的运行时，虽然它站在 llama.cpp 生态（GGUF 格式、quantization 方案）的基础上。他的解释：

这不是通用 GGUF 运行器，不是另一个框架的封装：它是完全自足的。

选一个模型，把它做到「结束」（end-to-end）——这是 antirez 明确的产品取舍。他在 README 里写道：本地推理领域有很多优质项目，但新模型不断发布，注意力一直被下一个要实现的模型捕获。他刻意选择相反方向：一次只支持一个模型，有 logits 官方验证、长上下文测试、足够的 agent 集成来验证它是否真的能用。

技术决策的核心是 KV cache 设计。他的判断是：DeepSeek V4 Flash 的压缩 KV cache + 现代 MacBook 的 SSD 速度，应该改变「KV cache 属于 RAM」的默认假设。DwarfStar 把 KV cache 当磁盘一等公民处理，支持会话跨重启复用，不需要每次从头 prefill。这对 128GB MacBook 上跑 284B 参数模型有直接的可行性意义。12

2 bit 量化也是一个主动选择，不是妥协。他写道：「这些 2-bit quant 不是玩笑——它们在 coding agent 下工作，能可靠地 tool call。」量化只作用于 routed MoE experts，其他组件（shared experts、projections、routing）保持原始精度。这是一个有根据的非对称量化决策。

本周的新讨论：antirez 在 X 上公开询问社区，是否应该让 DwarfStar 支持 Qwen 3.6 27B dense 模型，以覆盖 64GB MacBook 用户。13 这个讨论值得关注：他的「只支持一个模型」原则正在面临真实的硬件覆盖压力。

5 月 30 日，antirez 还发布了一个关于 --help 输出设计的视频，在 X 和 YouTube 上都有发布。14 这是一个细节投入的信号：Redis 作者在花时间做一个 CLI 的帮助文档设计，因为他认为它值得认真对待。

github.com · GitHub 저장소

antirez/ds4

https://github.com/antirez/ds4

콘텐츠 카드를 불러오는 중…

本期交叉点

三位作者在同一周，用不同具体场景描述了同一个张力：AI 工具让过程看起来很快，但不懂系统的人无法判断结果的质量。

DHH 给出了他的答案：产品节制，工具服务目标，「agent accessible but not agent hysteric」。
Mitchell Hashimoto 给出了他的验证方法：自己手写一个基线，看 agent 能否接近。差 75 倍时，问题不在 AI，在于接受 agent 输出的人对系统的理解深度。
antirez 给出了他的设计选择：不做通用框架，做一个具体到可以被彻底理解的窄范围产品。

这三种路径互补，不互斥。

DHH、Mitchell Hashimoto、antirez：同一周，三种系统观

DHH：云不是信仰，on-prem 才是「Keep it simple」

Mitchell Hashimoto：75 倍差距说明了什么

antirez：为什么用 C 写推理引擎，为什么只支持一个模型

本期交叉点

참고 출처