本周顶级开源作者在想什么（2026-05-27 ~ 06-03）

本期追踪四位作者：antirez（Redis）、Mitchell Hashimoto（Ghostty / HashiCorp）、DHH（Ruby on Rails / 37signals）、Max Howell（Homebrew）。本周的一条隐线：在 AI 工具快速渗透工程工作流的背景下，这四位都在以不同角度做出技术判断——有人在重新设计数据结构，有人在用实验揭示代理的认知天花板，有人在为基础设施哲学辩护，还有人在重建开发者工具的安全边界。

antirez（Salvatore Sanfilippo）是 Redis 的原始作者，现重归核心开发。本周他亲自参与设计并发布的 Redis 8.8 Array 类型是本期密度最高的技术素材。

Array 的设计出发点来自一个 Redis 长期存在的空缺：当数字下标本身是数据模型的一部分时（「第 47 分钟的传感器读数」「工作流的第 3 步」「日志文件的第 18552 行」），现有数据类型都给不出干净的抽象。List 提供 O(N) 的下标访问，Hash 没有区间查询，Sorted Set 的 score 是元数据而非地址——三者都需要应用层做额外的维护或过滤。1

Array 的内部实现采用稀疏目录结构：索引空间按每组 4096 个槽划分，只有写入过数据的组才分配实际内存，空白组仅占用 8 字节（一个空指针）。一个有 100 万个索引位但只有 200 条实际数据的数组，内存开销接近那 200 条数据本身，而不是 100 万个槽的总和。

扫描操作（ARSCAN、ARGREP）在遍历时直接跳过空指针组，代价与实际数据条目数成正比，而非与索引范围成正比。抓日志里的 ERR|WARN|FATAL 模式是设计者明确测试过的场景——antirez 在设计文档中提到，ARGREP 内置的正则引擎最终选用了 TRE 而非标准 POSIX regex，原因就在于要防止交替模式（alternation）在数据库服务器内部引发最坏情况性能爆炸。2

这个选型决策体现了一种判断优先级：在服务端内部运行的正则必须有可预期的上界，这比功能完备性更重要。

同一天，antirez 还发了一条对中国 AI 供应商的评估，明确区分了两类：DeepSeek 和 MoonshotAI 的特点是低调定价、实际表现超出宣传；另一些供应商的做法相反，在基准测试上表现亮眼，上手一用就原形毕露。3 他目前正在开发 DwarfStar 项目（面向本地 64GB MacBook 的 AI 工具集），在选用量化模型时正经历这种实际落差。

Mitchell Hashimoto 是 Ghostty 终端模拟器和 HashiCorp（Vagrant、Terraform、Vault）的创始人。本周他做了一个耗时 4 小时、花费约 350 美元的 Agent 实验，结论是直接的：Agent 在没有系统级理解的情况下产出的「改进」，和真正理解系统后手写的代码相差 75 倍。4

实验设置：他用 Go 写了一个刻意低效的渲染器（88ms / 帧，150,000 次内存分配），然后让 Agent 在不修改公共 API 和测试的前提下随意优化。4 小时后，Agent 把帧耗时压到了 1.5ms，分配次数降到 500。在不了解系统的读者看来，这是一个令人印象深刻的结果。

实际上，Mitchell 自己随后手写的渲染器跑出了 0.020ms（20 微秒）和 0 次分配。Agent 的「最优解」比人工解慢了 75 倍。原因在于 Agent 没有理解底层系统的内存布局和渲染路径——它在没有地图的情况下优化，把局部最优当作了全局最优。

他在另一条推文里也对「AI slop」做了更细致的区分：slop（初稿质量的 AI 产出）在快速并行实验时很有用，可以帮你在产品方向还不确定时先建出一个可用的 v0，但它不能直接 PR 进其他项目，不能不加审查地交给用户，也不能作为最终答案被接受。5

在 5 月 31 日，他还具体点出了什么是「AI 设计特征」：过细的彩色边框、渐变效果、太多不同字号、垂直对齐混乱、内边距不一致。他用「giveaway」（一眼看穿的标志）来描述这类视觉模式，建议开发者在判断 AI 生成 UI 的质量时把这些作为参考信号。6

DHH（David Heinemeier Hansson）是 Ruby on Rails 的创建者、37signals 的联合创始人兼 CTO。本周他写了一篇标题直接的文章：《Let the agents democratize open source》。

他的核心论点是：开源运动几十年来打的旗号是「让所有人都能自由修改软件」，但当 AI 真的开始让更多人具备这个能力时，部分原有社区成员开始设置新的准入门槛——以代码质量、署名规范、劳工保护为由，实质是保护自己的特权地位。DHH 把这个现象比作勒德运动，认为其本质是地位焦虑，而不是对质量或生态的真实关切。7

这个立场和他在基础设施上的选择是一脉相承的。同周，他披露了 Basecamp 5 的上线状况：在芝加哥、阿什本、阿姆斯特丹、圣何塞四地自建数据中心机架，全部是 on-prem 安装，过去 30 天的 Omarchy 流量达到 600TB，过去两年机房运营的系统正常运行时间记录没有间断。8

自建机房在 2026 年不是唯一选项，甚至不是主流选项。DHH 的判断是：对于 37signals 这个规模的团队和他们对可预测成本的要求，云服务的动态扩容能力带来的灵活性溢价，不值这个价格。他多次说这不是「反云」，而是基于具体规模和成本结构的具体判断。

Basecamp 5 的技术选型里还有一个细节值得记录：编辑器从 Trix 迁移到基于 Meta 的 Lexical 工具包，换来了表格支持、Markdown 支持和实时语法高亮。他在推文里感谢了 Meta 开放这个底层工具。9

Max Howell 是 Homebrew 的创建者，现在在做 AutomicVault，目标是解决 agent 时代开发者环境的凭证安全问题。

他的出发点是一个他认为被大多数人忽视的架构事实：Homebrew 是在「你完全信任用自己电脑的那个人」的时代设计的，那时候开发者和受信任用户是同一个人。在 2026 年，开发者的机器上跑着的不再只有开发者本人——还跑着各种 AI agent，而这些 agent 对凭证的访问方式和人完全不同，没有任何天然的权限边界。10

他本周整理了 2026 年几个主要的供应链攻击案例（TanStack、Nx Console、Bitwarden CLI、LiteLLM、durabletask），指出攻击者的目标不是生产服务器，而是开发者笔记本上的 ~/.ssh、~/.aws、~/.config/gh、.env、kubeconfig 和 Terraform 凭证，以及 AI agent 配置文件。11

攻击路径变成了：开发者笔记本 → 凭证 → 生产环境。而大多数安全配置还停留在「保护服务器」的 2015 年思维。

他的解法是在工具层加人机审批门禁：gh auth token 这类操作必须经过人工确认才能执行，凭证不再以明文形式写入磁盘，二进制文件被加固以防止 RAM 直读。他把 Homebrew 里几百个 package 都做了这类安全补丁，作为 AutomicVault 的产品之一。

在同一周，他描述了自己在 agent 时代的新工作方式：先用 vibe coding 快速迭代出 v0，把所有功能跑通；然后让 agent 生成一份功能和交互模式的文档；人工编辑去掉有问题的部分；最后以那份文档和脑子里已经成型的想法为基础，从头全部重写。12 这是一个「以 slop 为草稿，以理解为终点」的流程，和 Mitchell Hashimoto 对 AI slop 作为工具的看法相近。

本周四人的信号有两个维度的交叉值得单独说明。

关于 AI 工具的位置：Mitchell 的实验和 antirez 对供应商的评估，方向虽然不同，但都在说同一件事——AI 工具有用，但只有在人对底层系统有真实理解的前提下，AI 的产出才能被正确评估。没有基准，就没有「比 AI 更好」的参照；没有系统理解，AI 的改进可能是在局部爬坡而整体方向南辕北辙。这两条推文放在一起，能看到一种判断：AI 工具是放大器，不是替代品，放大的是使用者本身的判断力。

关于依赖与控制：DHH 的自建机房和 mxcl 的安全工具链，都在做一件事——把关键依赖从外部服务收回自主控制。前者是云服务，后者是 CLI 工具链里的凭证管理。具体决策细节和驱动因素各不相同，但在「减少不受自己控制的关键组件」这个方向上是一致的。