Soda · Photos 奇鸟行状录
A quiet archive · Est. 2026 · JUL 01, 2026
HN Daily Reading · 每日阅读

HN 每日深度阅读 · 2026-05-26

本期主线落在“技术不是中立的”这一判断上：从教宗通谕把 AI 治理、数字权力纳入天主教社会训导，到加州试图用年龄验证法切割开源与商业操作系统的责任边界，制度层面正重新划定技术与人的关系；与此同时，工程侧的迁移指南、围绕 DeepSeek 缓存的编码代理。

2026.05.26 20 篇摘录
← 返回每日阅读列表

共 20 篇 · 约 13,624 字 · 约 34 分钟读完

1. 教宗良十四世发布通谕《Magnifica Humanitas》：科技、AI 与人的尊严

梵蒂冈发布教宗良十四世的通谕《Magnifica Humanitas》，延续天主教社会训导传统，把焦点放在数字时代、技术权力与人工智能对人类处境的影响。通谕分四章：第一章回顾从教宗良十三世以来社会训导的发展脉络；第二章重申社会训导的基础与原则，包括人的尊严、人权至上、共同善、财物的普遍归向、辅助性、团结与社会正义；第三章专门讨论“技术与支配”，分析技术官僚范式、数字权力、AI 的治理与透明度，并批判超人类主义与后人类主义叙事；第四章谈在转型时代如何守护真理、劳动与自由，涉及真理作为共同善、民主、传播生态以及面向数字时代的教育联盟。

通谕的核心论点是：技术本身既非与人类对立，也非天然邪恶，但“技术从来不是中立的，它承载着设计、出资、监管和使用者的特征”。文件特别指出，主导技术发展的不再主要是国家，而是资源超过许多政府的跨国私营主体，使得引导技术服务于共同善更加困难。对 AI，通谕主张人类必须保持警觉、强调责任、透明与治理，并提醒不可在效率追求中失去人之为人的部分——心、限度与恩典。

HN 讨论氛围相当正面，包括不少自称无神论者的评论者表示，梵蒂冈在科技伦理上的立场比许多政府和机构都更细致、技术素养更高。有评论将核心讯息总结为：建造者应当问的不只是“能不能造”和“用户想不想要”，而是“该不该造”和“这是否让人类变得更好”。也有人指出，如果把文中“AI”一词替换为“公司”，许多论断同样成立，问题本质在于权力集中而非技术本身。另一些讨论延伸到历史：例如 20 世纪中产阶级崛起部分源于工业技术需要大量人手，而非道德选择；如今 AI 是否还存在类似的结构性激励仍不明朗。还有读者制作了 EPUB 版本方便离线阅读，并讨论阿米什人对技术的选择性接受。

2. 从 Go 迁移到 Rust：一份偏后端视角的对比指南

Rust 咨询公司 corrode 发布一份面向 Go 开发者的迁移指南，重点放在后端服务场景。作者坦承自己不喜欢 Go，认为它把“容易”与“简单”混淆，对 nil、错误处理作为约定而非类型、长期缺失泛型等设计持批评态度，但承认 Go 在 JetBrains 调查中长期占 17–19% 份额，是成功的语言。指南声明立场后，逐项对比两者的工具链（cargo 与 go 工具一一对应）、并发模型、错误处理、内存与资源管理。

核心论点是：从 Go 迁移到 Rust，本质是把原本依赖约定、lint 工具和运行时检测（如 -race、errcheck）的检查“拉进类型系统”。Rust 用所有权、Send/Sync、Result<T,E>、Option、Mutex<T> 等类型把空值处理、错误传播、数据竞争、资源生命周期等强制为编译期约束。作者以 Mutex<T> 为例：访问受保护数据的唯一路径就是 .lock() 拿到 guard，没有“忘记加锁”的路径存在。代价是更陡的学习曲线和更慢的编译。指南也说明哪些场景应继续用 Go，以及如何渐进式迁移服务。

HN 讨论非常激烈，评论数超过 400。多数高赞评论持批评或平衡态度。一位评论者认为文章把 Go 的“有意设计”重新框定为缺陷，例如把 Go 的数据竞争问题描述得过于极端，却忽略 atomics、channel 等同步原语。另一位资深 harness 作者指出，opencode 等工具刻意打破前缀缓存往往是基于测试结果，并非愚蠢。还有读者批评 Rust 的依赖树过于庞大——一个包含 rusqlite、clap、ratatui、tauri 的项目有 400 多个依赖，担心供应链攻击。也有人指出 Rust 在错误类型上分裂（io::Error、thiserror、anyhow），跨调用链传递痛苦，而 Go vs Rust 的争论已成为“行业里一处奇怪而尴尬的角落”。有评论者敏锐识别出文中频繁出现的“genuinely”一词，怀疑是 AI 辅助写作的痕迹。

3. Reasonix：围绕 DeepSeek 前缀缓存设计的终端编码代理

Reasonix 是一个开源（MIT）的命令行编码代理，专门针对 DeepSeek API 进行工程优化。它直接调用 api.deepseek.com，循环采用 append-only（仅追加）的消息结构，针对 DeepSeek 的字节稳定前缀缓存机制设计——长会话据称可保持 94%+ 的缓存命中率，输入 token 成本降到约 1/5。V4-Flash 默认价格为 $0.07/Mtok（未命中）和 $0.014/Mtok（命中）。

设计上有三大支柱：缓存优先循环（消息只追加，不重排，不依赖 cache_control 标记，时间戳确定性）、R1 思维链回收（捕捉模型逃逸的工具调用）、工具调用自我修复（基于 schema）。功能层面包括终端原生 TUI、V4 双层模型切换（/pro 临时升级）、一等公民的 MCP 支持（stdio、SSE、Streamable HTTP）、沙箱与 /plan 只读审计门、基于 Markdown 的可组合 skills、完整事件回放与统计。FAQ 中明确表示只支持 DeepSeek 是“设计选择”：通用后端（Aider、Cline、Continue）会压缩历史从而破坏字节稳定性，指向 Anthropic 兼容端点又会破坏 cache_control 标记。

HN 讨论分为几条主线。一是质疑必要性：有评论者展示自己写的简单桥接，把 DeepSeek V4 Pro 接到 Codex，缓存命中已超 39M tokens，认为通用 harness（如 OpenCode）配合 DeepSeek API 已能获得高缓存命中。二是对宣传页的强烈不满：动画打字效果导致下方内容不断上下抖动，移动端体验差，整体被认为像 Codex 生成的“过度设计”模板。三是建议 DeepSeek 官方推出自家代理，对标 OpenAI Codex 和 Claude Code。四是有 harness 老兵指出，opencode 等项目选择性破坏前缀缓存通常是测试后发现整体效果更好，盲目坚持“永远 append-only”未必正确，应提交带证据的 PR 而非另起炉灶。还有评论提到 DeepSeek API 文档质量差，且会自动给编码客户端分配最高 thinking effort，难以关闭。

4. 加州在反对声中拟将 Linux 排除出操作系统年龄验证法

加州一项要求操作系统提供商进行年龄验证的法律在引发广泛反对后，原起草议员提出修正案，拟豁免 Linux 等开源操作系统。修正案的关键措辞是：“操作系统提供商”不包括以允许接收者复制、再分发和修改软件的许可条款分发操作系统或应用的实体——这一定义实际上覆盖了所有自由/开源软件，而不仅是 Linux。原法律要求操作系统在用户设置时询问年龄，违反者将被视为提供缺陷产品，用户可要求退款。

HN 讨论对修正案本身的评价并不正面。一种观点认为豁免开源反而是坏事：法律本身只是“询问年龄”而非“验证年龄”，如果该询问有正当性，那么 Linux 同样应当询问；豁免相当于让基于 Linux 的商业发行（如 Red Hat）获得免责，而开源软件本就免费无保证，惩罚机制对其无意义。一位偏怀疑的评论者推测，立法者豁免开源是为了让 Linux 开发者失去基于第一修正案挑战该法律的诉讼资格。也有评论担心反向效果：网站会把 Linux 客户端默认当作未验证用户拒绝服务，形成新的歧视。

更深层的讨论指向立法过程本身：谁在起草这些将影响全美乃至全球互联网的加州法律？是否咨询过加州的互联网公司？多位家长评论者表达对现有家长控制工具的不满——平台按自己的标准决定哪些内容对儿童不合适，常与家长判断不一致，且缺乏可由家长自行配置的细粒度工具。SteamOS 等基于 Linux 但有自家账号体系的发行版是否真的能豁免也存在疑问。一些评论者认为，根本问题是公共机构丧失了监管大公司的能力或意愿，转而把负担转嫁给消费者和操作系统层。还有人提出更技术性的替代方案：浏览器检测家长控制开关 + 网站的 RTA 头部，作为侵入性更小的方向。

5. 用 50 小时手绘一张折线图

艺术家 Doug MacDowell 记录了自己用尺、铅笔、墨水和字模手工绘制一张统计精确的折线图、前后花费 50 小时的过程。这张图表展示他此前“咖啡机电脑”项目的温度数据，被 Hackaday 评价为“像出自 1970 年代大学教材”。文章核心不是炫技，而是把数据可视化重新理解为一门绘图工艺：从绷纸、贴胶带、画边距、用 T 形尺和三角尺打方格开始，逐步引入字模套件、圆形模板（用于保证线宽一致）、Micron 笔、Bristol 卡纸等工具。

作者推荐了一组几乎全部可在 Internet Archive 免费获取的经典著作，包括 Tufte 的《The Visual Display of Quantitative Information》、W.E.B. Du Bois 的数据肖像集、Willard Brinton 1914 与 1939 年的两部图示方法著作、Karl Karsten 1925 年的《Charts and Graphs》以及若干 20 世纪初的机械制图教材。文章把这种慢工艺定位为“在软件 20 分钟能完成的事情上花一周以上”的反生产力实践，也是一种学习艺术与工具感的方式。

HN 评论氛围温暖。多位读者分享自己的手工经验：一位家具设计师建议用 6H–9H 硬铅打底稿以便擦除，并推荐 K&E 削铅器和 lead holder；另一位前德国联邦统计局实习生回忆 1980–90 年代仍在岗的助理们仍会手工绘制数百页对齐表格。还有评论者把这种手绘比作竞技项目，戏谑地“评分”作者的斜接角处理。一位 90 年代写研究生论文的读者回忆当时用 Rotring 针管笔和字模制图，再翻拍成投影片用于答辩。也有人借此反思：折线图等基本可视化形式在 18 世纪末才由 William Playfair 发明，看似平凡的图形其实凝结了大量创造性思考；更多图表如果像作者那样标出数据点和插值方式会更有价值。一位长期潜水的读者因此文专门注册账号上来点赞。

6. AudioMass：一个完全在浏览器中运行的开源多轨音频编辑器

AudioMass 是一个免费、开源、纯浏览器运行的波形与多轨音频编辑器，无需后端、无需插件。功能覆盖文件加载（本地、URL、录音）、剪辑（撤销重做、复制粘贴剪切、插入静音、反转、反相、移除静音）以及一系列效果：增益、淡入淡出、语音降噪、参量与图形 EQ（含 20 段）、压缩器、归一化、硬限幅、延迟、失真、混响、变速变调、音频修复等。视图功能包括频率分析仪、频谱分析仪、多轨混音器、节拍工具、ID3 标签编辑。此次提交链接指向多轨 Beta 版本，支持每个通道独立的音量、声像、静音、独奏与录音触发，并带有节拍标记和吸附功能、BPM 与拍号设置。项目可作为 PWA 离线安装，源代码托管在 GitHub。

HN 反响普遍积极。多位评论者欣赏其代码风格——使用安全闭包、函数赋值、顺序变量声明等“老派”JavaScript 写法。一些读者称其界面和体验让人想起 Adobe 收购前的 Cool Edit Pro 2，认为这是一款“拒绝走向臃肿”的工具，且 PWA 离线模式被认为是“Web 平台本该有的样子”。也有用户在使用中遇到问题：双击样本后陷入某个视图无法返回主界面；Fade In 效果无法控制作用区间；XM 等老式 tracker 格式暂不支持。另一条受欢迎的讨论方向是“云端协作版”想象——有人提出做一个类似 GitHub 的 RiffHub，让用户能 checkout 别人的鼓点循环，加上吉他段落后再 commit 回去，认为远程合奏是音乐中最有乐趣的体验之一。还有评论拿它与 OpenDAW 比较，并称赞它原生支持 FLAC 文件。

7. 2006 年随机对照试验：吹迪吉里杜管可缓解中度阻塞性睡眠呼吸暂停

这是一项 2006 年发表的瑞士随机对照试验。研究者招募了 25 名年龄大于 18 岁、呼吸暂停低通气指数（AHI）在 15–30 之间的中度阻塞性睡眠呼吸暂停综合征患者并伴有打鼾，随机分为干预组（接受迪吉里杜管课程并在家练习四个月）和对照组（等候名单，期间不允许练习）。干预组使用统一规格的亚克力迪吉里杜管，每周至少练习五天、每天 20 分钟以上，课程内容包括基础发声、循环呼吸技术以及优化嘴唇、声道与气流的互动。

主要终点为 Epworth 日间嗜睡评分。结果显示，干预组平均每周练习 5.9 天、每次 25.3 分钟。与对照组相比，干预组日间嗜睡显著改善（差异 -3.0，P=0.03），AHI 显著下降（差异 -6.2，P=0.05），伴侣报告的睡眠干扰显著减少（差异 -2.8，P<0.01）；睡眠质量（PSQI）与 SF-36 健康相关生活质量两组无显著差异。睡眠相关综合 z 评分差异为 -0.78 SD，效应中等偏大。研究者推断，迪吉里杜管练习训练了控制气道扩张和管壁僵度的上呼吸道肌群，是中度 OSA 患者可接受的替代疗法。

HN 讨论中既有玩笑也有亲身经验。多位读者表示自己学过迪吉里杜管或正在尝试这种疗法：有人花一两年掌握循环呼吸后，鼻腔通气感大幅改善；有人分享在淋浴时含水、用鼻吸气同时用嘴喷水来练习循环呼吸的技巧；一位读者在体重下降治愈 OSA 后开始吹奏作为长期预防手段。也有用户正在进行结构化的三个月、每天 15 分钟实验，配合鼻中隔手术与 CPAP 历史。讨论延伸到其他口咽肌训练替代方案：snoregym、每天嚼口香糖（注意双侧均衡）、双簧管等需要高气压的乐器，以及一位朋友通过“用吸管往水里吹泡泡”改善了打鼾、呼吸暂停甚至体重。批评意见集中在研究方法上：对照组只是课程等候名单，没有真正的安慰剂控制；也有人调侃迪吉里杜管的低频噪音对伴侣睡眠的影响未必比打鼾小。

8. Jira 是图灵完备的：用工单系统搭建 Minsky 机

作者 Nicolas Seriot 给出了一个严格证明：Atlassian 的 Jira 项目管理工具在自动化能力上是图灵完备的。此前社区一直流传这种说法但缺乏可验证的构造，本文通过将 Minsky 双计数器寄存器机（Minsky 在 1967 年证明其等价于图灵机）规约到 Jira Automation，补上了这一缺口。

具体映射方式为：寄存器 A 用关联到某个 Epic 的 Bug 数量表示，寄存器 B 用 Task 数量表示，程序计数器由该 Epic 的状态字段编码，调度表由每条指令对应的一条 Automation 规则组成，时钟由自动化触发的级联跳转或人工重新触发来推动。INC 与 DEC 通过创建与删除被关联的 issue 实现，条件分支则由 JQL 条件规则完成。

作者给出了一个最小可运行实例：在真实的 *.atlassian.net 实例上做 2+3=5 的加法运算，配置包含 BACKLOG/TODO/DEV/PROD 四个状态和两条规则，启动后 Epic 在五次状态跳转后停在 PROD，关联出 5 个 Task。文章进一步利用 Jira 的 Convert Issue Type 功能（等价于 DEC+INC，不增强计算能力但显著压缩状态表），用三个寄存器、三个状态实现了斐波那契生成器，由于 Jira Cloud 对级联触发深度有 10 层上限，需要操作者周期性地手工重启级联，作者认为这相当于人工提供时钟，规约本身仍然成立。

HN 讨论分为几个方向。一部分评论以调侃为主，例如「Jira 烂到能模拟任何形式的烂」「现在终于能在 Jira 里玩 Doom 了」「难怪没人能判断一个 Jira 操作会不会停机」。也有评论指出，所有工作流与编排引擎本质上都是图灵完备的，这并不令人意外，作者的贡献在于给出了具体构造。

另一些评论转向对 Jira 本身的吐槽：界面卡顿、布局抖动导致误点、相比早期 Jira Server 4.0 的简洁版本现版本充满细节瑕疵、不少团队用 Trello 就够用却被迫上 Jira。也有人分享了正面用法，例如用 Automation 自动汇总子任务故事点、自动把信息不全的工单移回 backlog，认为这些本应是默认行为。还有评论提到企业程序员可以用 Python 脚本和 API 包装器把 Jira 自动化到「武器化」程度，作为自我保护工具。Azure Boards 则被多次提及为「让人开始怀念 Jira」的对照组。

9. 用 Jujutsu 对抗 Git 提交整理疲劳

作者描述了一种在开发大功能时常见的困境：理想中的提交历史应该是「定义类型 → 加数据库函数 → 服务端 CRUD → 客户端 API → 客户端 UI」这种线性、单一关注点的序列，便于 reviewer 逐步阅读。但实际开发中，提交往往是「WIP 测试代码、修 DB 函数、修 UI bug、再修一个 UI bug、重构 CRUD」这种交错混乱的状态，后面的提交常常覆盖前面的工作，叙事被破坏。作者称之为「git rigour fatigue」——维持提交整洁所需的心智负担。

Jujutsu（jj）虽然让跨 commit 跳转和小步迭代更容易，但作者认为 jj absorb 会按「最近修改过该文件的提交」分配变更，未必对应正确归属；jj squash -i 又容易在边界不清时陷入合并冲突地狱。

作者提出的工作流可以概括为：先用 jj new -B/-A 在乱糟糟的提交序列之前/之间创建好理想中的空提交骨架（red、blue 等占位），然后用 jj squash —from..—into 把所有实际改动合并到一个「万能 commit」里，再通过 jj squash -i 交互式地把这个大 commit 中的内容按颜色/主题逐步分发到各个占位提交，直到「万能 commit」清空。相比 jj split，这种方式在漏掉某个 hunk 时不需要反复 split+squash，也能优先处理最容易归类的部分，且因为最终态来自同一个无冲突 commit，整理过程不会引入冲突。缺点是中间提交不保证可编译。

HN 讨论分歧明显。支持者认为 Jujutsu 把工作区当作 commit 的设计消除了 Git rebase 工作流的大量摩擦，jj new 在开始新工作前显式创建变更点，比「先写再 commit」更贴近思维模型。也有人指出 jj absorb 实际上是基于 diff 分析的，并非作者描述的那样粗糙。

反对意见主要有几类：一是分支管理被认为是 jj 的弱项，有评论者表示在多人协作、并行多个命名分支的场景下，jj 让保持分支跟进 commit 变得很繁琐；二是 jj 要求所有文件被跟踪/提交的模型干扰了「工作区允许临时脏」的习惯；三是有人质疑这套流程与「先 squash 全部、reset 到工作区、再按 hunk 分别 commit」的传统 Git 操作并无本质区别，git rebase -i、fixup/autosquash 已能完成类似任务。还有评论提到完全拥抱 PR squash merge 之后，精雕细琢的提交历史已经没那么重要；另一派则坚持线性整洁历史对 git bisect 调试至关重要，希望 VCS 能同时保存「真实发生的历史」和「整理后的历史」。

10. 表面越光滑阻力越小？航空工程的一条基本假设被推翻

Wired 报道了一项颠覆航空工程长期共识的研究。传统观点认为，机翼或车身表面越光滑，边界层越能长时间保持低摩擦的层流状态，从而降低气动阻力，因此减阻的关键是延迟层流到湍流的转捩。这一假设自 1940 年日本科学家谷一郎（Ichiro Tani）的研究以来主导了航空设计长达 80 余年——他当时认为，制造工艺造成的表面粗糙不可避免地促进了湍流转捩，妨碍了层流的实现。

新研究表明，适度的微观粗糙度实际上可以延迟流动分离并降低整体阻力，并非「越光滑越好」。文章还提到，谷一郎本人在 1989 年重新解读 1930 年代 Nikuradse 关于粗糙管道流的实验数据时，已经提出「粗糙未必只促进湍流转捩并增加阻力」的可能性，但他在次年去世，相当于他在同一个问题上工作了将近 49 年。研究使用了磁悬浮天平系统，在风洞中通过电磁力无接触悬浮流线型模型测量阻力。

由于 Wired 的付费墙，文章主体内容在评论区被截断，许多 HN 评论者只读到了开头几段，引发了一些讨论失焦。

HN 评论中最常被提及的对照是高尔夫球的酒窝（dimples）能减阻这一早已熟知的现象，许多人质疑「光滑最优」从未真正是一条普适规则。还有竞技帆船和水翼爱好者指出，水下表面用 1000–1500 目细砂纸打磨后摩擦最低、层流最好，水中早已是常识，作者惊讶于空气中长期未被同样认知，怀疑这其实是「实践者知道但论文作者不知道」。

一位有流体力学背景的评论者指出，这一发现并不算「推翻基本原理」：流体阻力本来就分形阻力（压差阻力）与摩擦阻力，两者随雷诺数权衡。保持层流减少摩擦阻力，但人为诱导湍流可以延迟分离从而减少形阻（高尔夫球即为此例），「越光滑越低阻」从来不是普适定律，只在特定尺度成立。新研究的贡献更像是找到一种在保持层流的同时延迟分离的方式，而非颠覆基础。

也有评论关注工程可行性：如果实际工艺只是喷砂级别的粗糙化，那么对现役飞机改装的成本可能很低；但文章只给出了「转捩区内」的百分比改进，缺乏对整条剖面的净收益数据，且在真实环境中维持精确的微观粗糙度并不容易，容易被污染或进一步磨损。多位评论者表示要等真实飞机的燃油效率实测数据出来才能下结论。

11. 用 Pi 开发 Pi：在 AI 协作时代维护开源项目的新困境

Armin Ronacher 撰文记录了在 Earendil 旗下的 AI 编程工具 Pi 项目中，他与 Mario Zechner 一起「用 Pi 开发 Pi」时所遇到的新型开源协作问题。核心观察是：在 LLM 代理大规模介入开源后，issue tracker 的角色发生了微妙变化——issue 描述既是用户向维护者的沟通，也是直接喂给代理的提示词，因此 issue 的「形态」变得前所未有地重要。

作者描述了几类典型问题。第一是「Slop Issues」：大量 issue 由 5% 的人类观察加 95% 的 LLM 改写组成，原本简洁的事实性 bug 报告被 LLM 扩展成自信但错误的根因分析、伪造的最小复现、可疑的代码引用和成串的错误类别推测。比无诊断更糟，因为当维护者把它再交给 Pi 时，Pi 不会把 issue 当作传闻而是当作证据，会顺着错误路径走下去。作者团队为 Pi 加了 /is 斜杠命令，明确指示「不要信任 issue 中的分析，要从代码与执行路径独立验证」，但效果有限。他希望 issue 回归四件事：我运行了什么、期待发生什么、实际发生什么、确切的错误或日志。

第二是「Slop Begets Slop」：LLM 生成的代码倾向过度工程。对于 Pi 核心的会话日志（session log），其设计基于必须严格维持的不变量，但代理面对一个畸形数据导致的崩溃，第一反应是写更宽容的读取器、加 fallback、加迁移、加调试日志，而正确做法应是让畸形状态从一开始就不可能产生。LLM 总是局部地防御局部失败，维护者必须不断把对话拉回全局不变量。

第三是「Volume Is The Problem」。过去 90 天 Pi 仓库收到 3145 个外部 issue 和 PR，其中 2504 个被自动关闭（来自未审核贡献者），最终被重新打开的占 17%，若算上间接被主分支修复引用的则升到 26%；PR 的接受率仅约 8%（60/714）。垃圾来源包括 OpenClaw 实例以及一些鼓励创建 issue 的 skill 提示。作者认为锅不在 GitHub，而在于让代理随意污染他人 issue tracker 的人。

文章最后简述了团队对受控并行的实践：通过 .pi 目录下的小型配置，让 Pi 主要在「复现 issue」这一相对独立的任务上并行运行，距离 Bun、OpenClaw 那种「黑灯工厂式自动化软件工程」仍有距离，且目前既不具备能力也不打算追求。

HN 讨论集中在几个点。最受共鸣的是「局部修复 vs 全局不变量」的根本难题，许多人认为这几乎是 LLM 编码工具的结构性缺陷，难以靠 prompt 解决。有人建议把用户原始消息单独记录到文件中，对照计划与实际产出审查，以防代理偏离意图。也有评论质疑：既然希望 issue 遵循固定四段格式，为什么不让 issue 模板强制结构化，而 LLM 反而应该比人类更擅长按指令填写？关于不变量被忽视，有评论指出文档化是否充分是个独立问题。另一些讨论偏离主题，例如对作者使用「clanker」一词（贬称 AI 代理）的争议、对项目命名（Pi 与 Raspberry Pi 撞名、Earendil 借用托尔金）的吐槽，以及对网站水波动画实现的好奇。

12. 社区反对下，微软撤回 Caledonia 244 英亩数据中心计划（2025）

TMJ4 的这则 2025 年报道讲述了微软放弃在威斯康星州 Racine 县 Caledonia 兴建一座 244 英亩数据中心的计划，原因是当地社区的持续反对。由于原文链接因法律原因（HTTP 451）无法在部分地区访问，HN 上的讨论主要基于标题和已有的背景知识。

该选址位置接近此前富士康承诺建设但最终大幅缩水的「世界第八大奇迹」园区，当年富士康号称带来上万就业但最终落空，给当地居民留下了对大型开发项目的深度怀疑。这次微软项目同样在土地、用水、用电、税收激励等议题上引发争议，最终撤回。

HN 讨论沿几条线展开。一是程序与公平性问题：有评论者询问这类项目的实际审批流程——是否需要先购地再申请许可，如果是，那么大型企业凭借自融资能力可以承担长期持有非生产性资产的成本，小企业难以参与，这会导致土地用途结构性地偏向大公司偏好。

二是规模的直观感受。有评论者表示 244 英亩用于一个数据中心听起来非常夸张，但承认自己对行业基准缺乏了解，希望知道像 AWS us-east-1 这种大型数据中心实际占地多大，并抱怨这类数据难以通过搜索引擎获得。

三是地缘与基础设施视角。一条高赞评论认为，这是一个位于两条输电线路交汇处、且水资源近乎无限的优秀选址，「富裕的白人飞地」用环境正义的语言成功将廉价的燃煤电力保留给自己，作者称这是「非常美式的结局」。也有评论从产业角度遐想，美国未来可能像煤矿小镇那样出现「数据中心小镇」，形成独特的经济与文化生态，前提是 NIMBY 阻力没那么大。还有人调侃说应该去加拿大建——能源更便宜——但马上自我否定，因为加拿大反工业开发和邻避主义比美国更强。也有评论从微软业务角度评论，如果 Copilot 战略失败，CEO 可能也会随之离任。此外，多名评论者吐槽自己的 IP 被网站的 Cloudflare 策略拦截，连联系网站的入口都看不到，认为这种「友善的封锁」正在割裂网络。

13. 荷兰扣押 800 台服务器，逮捕两名为俄罗斯网络攻击提供基础设施的嫌疑人

KrebsOnSecurity 报道，荷兰金融犯罪机构 FIOD 于 5 月 18 日逮捕了两名嫌疑人——57 岁的阿姆斯特丹居民 Youssef Zinad 与 39 岁、出生于俄罗斯下诺夫哥罗德的 Andrey Nesterenko，指控他们违反制裁法、直接或间接向受欧盟制裁的实体提供经济资源。同时被搜查的还有 Enschede、Almere 的三处办公地点以及 Dronten 和 Schiphol-Rijk 的两个数据中心，超过 800 台服务器、笔记本电脑和手机被扣押。

调查焦点是 Stark Industries Solutions，一家在俄罗斯入侵乌克兰前两周突然成立的托管服务商，长期被指为针对欧洲目标的大规模 DDoS 攻击、代理和匿名服务的温床，多次出现在与俄罗斯背景黑客组织相关的攻击中。Krebs 在 2024 年 5 月的调查中识别出 Stark 的两个主要上游之一是摩尔多瓦兄弟 Ivan 与 Yuri Neculiti 名下的 PQHosting；2025 年 5 月欧盟对二人及 PQHosting 实施制裁，但 Stark 的另一上游——Nesterenko 在荷兰运营的 MIRhosting——未被纳入制裁。

报道指出，制裁消息在正式宣布前约两周已经在媒体泄露，期间 Stark 的网络资产被从 PQHosting 转移到名为 the[.]hosting 的新实体，其背后是荷兰公司 WorkTitans BV，而 WorkTitans 由 Nesterenko 与 Zinad（此前在 MIRhosting 工作过）控制，连接互联网完全依赖 MIRhosting。荷兰报纸 de Volkskrant 援引数据称，在 2025 年 11 月 13 日至 19 日丹麦市政选举期间，WorkTitans 与 MIRhosting 是亲俄势力针对丹麦政府机构发起攻击中使用最多的网络。

Nesterenko 本人是钢琴神童出身，2004 年创办 MIRhosting 的母公司 Innovation IT Solutions Corp.；该公司还以曾托管 2008 年俄格冲突期间组织对格鲁吉亚网络攻击的 stopgeorgia.ru 而著称——那被认为是第一场同时进行实体军事行动与显著网络攻击的战争。Nesterenko 否认知情，称已在 2025 年 5 月制裁生效时终止与 Neculiti 兄弟的所有服务，向 the.hosting 的过渡也不是为了规避制裁，硬件与客户在制裁出台前就已转移。MIRhosting 发表声明称已启动内部调查，暂停对 WorkTitans 的服务，并表示其网络流量没有出现可被解读为大规模 DDoS 的异常峰值。Zinad 则一直保持低调，其 LinkedIn 资料被关闭，对邮件、WhatsApp 和电话长期不回复，称因病减少社交活动。

HN 评论强调这些并非「问得少」的灰色托管商，而是直接的俄罗斯情报机构前台公司，本身不向普通用户提供服务，有评论者自述曾尝试购买但被拒绝。另有评论对比德国邮件服务商「pissmail」运营者因有人用其服务发垃圾邮件而入狱的案例，认为两类执法力度反差强烈。也有从业者表示，看到这些人投入大量工程精力为犯罪基础设施服务，仍然感到困惑——他们本可在合法领域有不错收入。一些评论从地理观察出发，发现荷兰在攻击流量来源中长期与俄罗斯、中国并列，并联系到知名的 CyberBunker 案例。还有评论希望执法不止追责基础设施提供者，也能揭露并起诉真正出资发动攻击的客户方。

14. Launch HN：Chert（YC P26）——面向 iMessage 的 Twilio

YC P26 批次的初创公司 Chert 推出了一套面向开发者的 iMessage 基础设施 API，定位为「iMessage 版 Twilio」，主打让 GTM（市场销售）团队和 AI 代理通过真实的蓝色气泡 iMessage 线程与终端用户交互，包括打字指示、tapback 表情回应、群聊、多收件人、附件、网络回执，以及在收件人不使用 iMessage 时自动 fallback 到 SMS/RCS。公司宣称冷外联回复率显著高于 SMS，并对接 Salesforce、HubSpot、Attio、Close、Slack、Vapi、GoHighLevel 等 CRM 与外呼工具。

针对「这是否合规、是否会被 Apple 封禁」的 FAQ，Chert 表示走的是真正的 iMessage 协议而非 SMS，但承认会通过轮换发送身份、逐步预热、限制每个身份每日发送量来规避 Apple 的滥用检测启发式，并讽刺「承诺无限群发的同行随时可能消失」。

HN 讨论几乎一边倒地质疑其合法性、伦理与可持续性。第一类质疑指向 Apple ToS：iMessage 明文规定用于亲友通信、不得用于商业活动，且 Apple 即使无法识别每一个被创建的账号，也完全可以作为法人实体直接封禁并起诉造成损失。多位评论者指出，Apple 已经提供官方的 iMessage for Business 渠道，虽然接入流程极其繁琐，但才是受支持的方式——一个更有建设性的方向是做「iMessage for Business 的 Vercel/Resend」，简化官方流程而非绕过它。

第二类质疑涉及商业模式与平台风险：Chert 的存续完全依赖 Apple 不出手，而 Apple 一旦行动，客户搭建的所有集成都需要重做。评论者引用类似产品 Sendblue、Bloo、Lindy 已经存在，以及 Beeper 因类似定位被封的先例，怀疑 YC 为何在这种平台风险下仍然投资。

第三类质疑是伦理与社会层面的。许多评论者直接称之为冷外联垃圾信息，认为他们之所以喜欢 iMessage 正是因为商业方难以入侵；如果 Chert 成功，最愿意付费的客户恰恰是想突破现有反垃圾屏障的人。还有评论质疑「让 AI 代理显得更像人类」的叙事本身：当代理明显不是人时，为什么应该追求让对方误以为是人？另有担忧此类产品即使初心是良性，也会很快被广告金主用于滥用，难以拒绝资金诱惑。

也有少数中性意见，提出实际建议，例如希望 Chert 支持 iMessage 应用 payload、支付场景等 Sendblue 当下未覆盖的能力。还有围观者调侃：如果这真的可行，Twilio 早就自己做了，过去十年 B2C 消息应用社区一直希望有人解决这个问题，结果是 WhatsApp 占了主导。

15. Gnutella：一个比创造它的世界活得更久的协议

作者 Rick Carlino 撰写了一封”过分热情的情书”献给 Gnutella 这一被大多数人遗忘的去中心化文件共享协议。文章回顾了 Gnutella 的诞生：它最初是 Nullsoft 的内部演示，在 AOL 收购后被取消，但凭借其无服务器的去中心化设计，一旦泄露便无法收回。它通过 LimeWire、BearShare、GTK-Gnutella 等多种客户端在 2000 年代支撑起数百万并发用户的文件共享黄金期，并延续了近十年。

作者强调一个常被误解的观点：Gnutella 并未”失败”。它达成了大规模主流采用，只是它所服务的那个世界——拨号上网普及、流媒体不可行、用户习惯管理文件系统、MP3 播放器兴起、唱片业拒绝转型——已经消失了。本质上 Gnutella 是一个面向二进制 blob 的点对点搜索引擎，理论上可用作穷人版 DNS 或键值查询服务，但历史只记住了它的 MP3 下载用途。技术上它结合了 HTTP 文件传输与节点间的 gossip 查询扩散，依赖当时居民 IP 较少被 NAT/防火墙阻挡的网络环境。作者还提到自己今年用 Bun 实现了一个 Gnutella 客户端，发现协议的实际互操作性近乎奇迹，因为大量行为从未写入规范，却在多客户端生态中有机演化出来。

HN 讨论补充了不少视角。曾开发 Gnucleus 客户端并参与设计 GWebCache 的早期参与者指出，Gnutella 架构的核心问题在于隐私（暴露本机充当节点）与搜索效率（查询无法覆盖全网），BitTorrent 保留了去中心化传输但用中心化 tracker 简化了搜索，因此存活至今。多位评论者认为 Gnutella 的衰落主因就是被 BitTorrent 取代，加之 YouTube 下载器已能满足绝大多数免费获取音乐的需求。还有人提到协议早期版本的可扩展性问题：网络规模一大，查询消息洪泛就会淹没一切。关于”泄露”的说法也被纠正——更准确地讲是 AOL 没搞清楚 Nullsoft 在发布什么，Justin Frankel 借收购后期的混乱期推出了它。也有评论感慨：协议能脱离创造它的公司、设备和文化继续存在，恰恰是因为不需要任何人持续”拥有”它才能继续运转。

16. 每月不到 10 欧元的欧盟独立开发者技术栈

这篇指南面向欧洲独立开发者（bootstrapper），目标是在不依赖美国超大规模云厂商的前提下，用每月接近零的成本搭建一套 100% 欧盟基础设施。文章只收录在撰写时提供永久免费层（而非 14 天试用）的服务商。

在计算资源上，没有欧盟厂商提供永久免费算力，但价格极低：推荐 Hetzner Cloud 的 CX33（4 vCPU、8 GB 内存、80 GB 硬盘，约每月 7 欧元），可舒适运行 Django/Rails 应用加 Postgres、Redis、后台 worker；Netcup 作为备选，价格更低。事务性邮件推荐了三家有可用免费层的欧盟供应商；新闻邮件营销则有两家可支撑数百订阅者。分析层面，作者认为 Google Analytics 是 GDPR 噩梦，推荐 Simple Analytics 和针对移动/桌面应用的 TelemetryDeck。监控方面，UptimeRobot 提供 50 个免费监控点，Healthchecks.io 适合 cron 任务监测且可自托管。表单工具推荐 Tally（无限表单与响应）和开源的 Formbricks。认证可自建，也可使用支持 passkey 的 Hanko。支付方面没有真正免费的选项，但 Mollie 作为欧版 Stripe 仅按交易收费；面向数字产品销售的还有作为 Merchant of Record 的 Creem。文章结论是：唯一固定成本就是 VPS 的 7 欧元，整套栈可以平滑随业务付费升级，所谓”数字主权”在这里并非意识形态，而是上线产品最便宜可信的方式。

HN 讨论中，有人分享了自己组合：IONOS 主机 + Scaleway 邮件 + mailbox.org + statichost.eu。其他被补充推荐的还有 Unikraft、UpDown.io、Dokploy、Coolify 等。也有评论指出文章风格疑似 AI 生成，并怀疑这类”清单文”是新型的潜艇广告或赞助营销。多位评论者点出关键问题：很多”欧盟替代”服务实际仍部署在 AWS/GCP/Azure（Hanko 团队也坦承自己仍在 AWS 法兰克福，但欧盟自有托管即将上线），因此并未真正免除美国《云法案》的管辖风险。还有人质疑 passkey 只是把”密码重置”换成了”passkey 重置”，丢失后的恢复路径仍是悬而未决的问题。也有评论希望看到更彻底的自托管方案（如 mox 邮件服务）。

17. Mullvad 部署对出口 IP 指纹识别的缓解措施

Mullvad 发布了一份运营公告，列出已应用新缓解措施的 WireGuard 出口服务器名单，涉及澳大利亚、加拿大、德国、芬兰、法国、爱尔兰、挪威、瑞典以及美国多地共 13 台服务器。这次更新对应 Mullvad 早前博文中讨论的”VPN 服务器之间的出口 IP 指纹识别”问题——简而言之，攻击者或观测方可能通过对比不同 VPN 出口节点之间的网络指纹差异来识别或关联用户流量。本文本身只是滚动部署进度的状态页，未披露技术细节。

HN 讨论中，最高赞评论指出本帖链接的只是服务器清单，更值得阅读的是 Mullvad 的原始博文，以及 HN 上更早一次关于该指纹问题的讨论。有用户提到 Mullvad Browser 内置的代理不走 WireGuard，因此不受此问题影响，并推荐了浏览器扩展中的 Random Mode 功能——为每个站点分配不同 IP 以提升隐私。

另一条延伸讨论是关于浏览器指纹防护的方向之争：有评论者希望出现一种 Librewolf 衍生版，不再”随机化”指纹数据（随机本身也是一种指纹特征），而是让所有用户呈现完全相同的伪造信息，比如统一的 1080p 分辨率、统一的 GPU 配置、固定的设备时序档案，使指纹失去区分度。还有人询问 VPN 服务商是否向零售 ISP 付费购买出口节点，以及此次缓解是否与美国参议员 Wyden 近期就 VPN 安全发出的国会警告有关、是否还有其他 VPN 厂商就此表态。整体讨论规模有限，更多是技术细节澄清和对相关链接的指引。

18. White Rabbit：面向大型分布式系统的亚纳秒同步技术

White Rabbit 是 CERN 主导的开源硬件项目，为大型分布式系统提供亚纳秒级精度、皮秒级精密度的时间同步，同时在同一以太网链路上承担确定性、可靠的数据传输。其设计指标包括：连接数千个节点、节点间典型距离 10 公里、千兆以太网速率的可靠数据传输，并且硬件、固件和软件全部开源，已有多家厂商商业化生产兼容设备。项目页面同时挂出 CERN 招聘 FPGA 开发者的信息，用于推进 WR 交换机 v4 等后续工作。

技术核心可以从一篇 IBIC2013 论文（papers/IBIC2013 目录下 make 即可生成）中找到。HN 评论指出，这并非常规的以太网：传统千兆以太网中每个网卡使用各自的自由运行时钟，而 White Rabbit 将所有物理层时钟在 L1 层互相同步（千兆以太网始终在传输符号，空闲时发送 idle 符号，这为时钟恢复提供了基础）。本质上是在 PTP 和 SyncE 之上叠加额外的智能化处理。

有评论惊讶于在相距 10 公里的系统间实现亚纳秒同步——10 公里光程约 33 微秒，所以其中必然有针对链路延迟测量与补偿的精巧设计。另一条高赞评论指出，分布式共识在这种性能水平下按常识是不可能达到的，询问 White Rabbit 与”共识”问题的边界差异在哪里——回答方向是：这并非异步分布式共识，而是物理层精确同步加上可预测的确定性传输，两类问题不应混为一谈。有人调侃，如果不是 CERN 出品，看起来简直像在被忽悠；CERN 在页面上挂招聘信息几乎是一种”凡尔赛”。也有人质疑：如果系统设计依赖如此精确的时间同步，是否设计本身就有问题——但显然在粒子加速器、电网、金融交易、射电望远镜阵列等场景中，精确时间是不可回避的硬性需求。

19. Firefox 为 Intel Raptor Lake CPU 的崩溃 Bug 加入规避补丁

Mozilla 工程师 glandium 提交了一个补丁（D301917 / Bug 1950764），用于规避 Intel Raptor Lake 处理器上的一个 CPU 缺陷。问题出在 zlib-rs（Rust 版 zlib）的 deflate 实现中：LLVM 在某些情况下会生成 movb %ch, [mem] 这类从高字节寄存器别名（如 ch、bh）存储的指令模式，而该模式在 Raptor Lake 上会触发一个错误，导致本应写入 2 字节的存储被静默地破坏，连带损坏相邻的 len 字节，造成压缩数据损坏与浏览器崩溃。补丁的修复方式是将两个 dist 字节合并为一个 2 字节存储，从而避开会触发问题的指令模式。

HN 讨论中引用了 Fabian Giesen 在 Oodle 压缩库中遇到同类问题的深度分析文章——同样涉及高寄存器别名的 Huffman 编码场景，且与 boost 时钟频率高度相关。评论者担忧地指出，Intel 对此问题反应迟缓，至今没有官方勘误（errata）条目，难以判断到底是硅片级设计缺陷，还是与 Raptor Lake 此前已知的电压问题、随机位翻转导致的制造后退化有关。Firefox 据称甚至已放弃从 Raptor Lake 自动收集崩溃报告，因为噪声太大、无法复现。

多位评论者表达不满：让每个软件项目各自绕开这个 Bug 显然不是长久之计，应该由 Intel 通过微码更新或由编译器在受影响 CPU 上避免发出该指令模式来统一处理；仅在源码注释里写”不要发出某条指令”是非常脆弱的保障。也有人联想到 9 年前 Intel Skylake/Kaby Lake 的超线程 Bug，认为 Intel 在回归测试上覆盖度不足，建议引入 demoscene 等极致优化代码作为压力样本。还有评论者注意到 Tom’s Hardware 和 Neowin 的相关报道是”AI 生成的水文”，混淆了已知 errata 与微码可修复性，反而让用户产生误解。另一条评论则担心，如果有人基于这类 CPU 错误构造攻击，将带来严重的安全隐患，并借此重申 CPU 设计应当追求简洁性。

20. 那些出现在意想不到地方的字节码虚拟机

作者 Patrick Dubroy 受 SQLite 作者 Richard Hipp 解释”为何 SQLite 用字节码 VM 执行 SQL”的文章启发，盘点了一系列出现在非通用编程语言场景中的字节码虚拟机。

文中举出的例子包括：eBPF——Linux 内核中的扩展机制，原本是 1993 年 USENIX 论文中描述的 Berkeley Packet Filter，用于网络包过滤；2011 年加入 x86-64 JIT，2014 年扩展为通用内核虚拟机，拥有 10 个寄存器和上百条指令。DWARF 表达式——编译器在调试信息中嵌入的小型栈式表达式语言，用于告诉调试器如何计算局部变量的当前位置（寄存器、栈或被优化掉）。GDB agent 表达式——另一个独立的字节码语言，用于让远端 agent 自己求值 trace/collect 表达式，避免在目标机部署完整符号求值器，适合实时系统。WinRAR 的 RarVM——RAR 文件格式内嵌一台类 x86 虚拟机，有 8 个寄存器，用于实现可逆数据变换以提升压缩率，由 Tavis Ormandy 在安全研究中详细分析。GPU 上的灵活着色器——MPR 论文中用通用解释器执行隐式曲面表达式；Dolphin 模拟器的 Ubershader 用一个巨型着色器避免编译停顿。

HN 评论补充了相当多有趣案例。最热门的一条指出，在 GPU kernel 中跑字节码 VM 并不像直觉上那样糟糕：除了 Dolphin 的 Ubershader，Blender Cycles 渲染器的着色图执行系统就是 GPU 上的字节码 VM；ML 框架若想通过 kernel fusion 充分压榨 GPU 性能，“巨 kernel + VM”也是一条切实可行路径。其他补充的字节码 VM 应用还包括：iOS 上著名的 NSO 零点击漏洞——在 JBIG2 PDF 中实现了一台图灵完备的 VM；SBus 外设的 Forth 解释器；ACPI 的 AML 语言；Bitcoin 交易脚本；TrueType 字体提示指令；Quake 系列的 QuakeC 与 Quake3 QVM（可用 LCC 编译 C 代码）；Excel 公式据传也是基于字节码栈机；Go 正则表达式编译为内部字节码；Naughty Dog 在 PS3 的《神秘海域》中为 SPU 实现了自研字节码 VM，编译器用 Scheme 写成；以及 Woz 的 SWEET16。

也有评论提出反思：当每个子系统和数据格式都自带图灵完备的字节码与 JIT 时，安全攻击面急剧扩大——每一台小 VM 都需要单独维持无漏洞，才能确保整体系统安全。一位评论者还指出，比 BPF VM 本身更令人惊讶的是 libpcap 中存在的针对 BPF 的优化编译器。