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

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

本期主线聚焦技术与制度的双重摩擦：MIT 经费骤降与研究生缩招折射出美国科研体系正被政治化重塑，Bun 百万行 Rust 重写与 eGPU 接驳 Mac 则展示开发者以高成本绕过既有技术约束；而拆除车载调制解调器与开发者反思 AI 让自己变笨。

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

共 20 篇 · 约 12,443 字 · 约 31 分钟读完

1. MIT 校长致信全校：联邦经费骤降与人才管道收缩

MIT 校长 Sally Kornbluth 通过视频向全校通报学校面临的两大压力：经费与人才管道。她指出，新近对校友捐赠基金收益征收的 8% 税显著加重了 MIT 等少数高校的预算负担。尽管二月份国会恢复了部分科研机构的拨款，但流向 MIT 的联邦经费并未恢复到以往水平；部分联邦机构甚至开始讨论按地理因素而非纯科学价值分配资金。

具体数据方面，与去年同期相比，MIT 由联邦资助的校园科研活动下降逾 20%，新获联邦项目数量同样下降逾 20%。即便加上非联邦来源的增长，校园资助科研总体规模仍较一年前缩水约 10%。在人才方面，影响国际学生与学者的政策变化已经在劝退顶尖申请者；由于经费不确定性，各系在招收新研究生时趋于谨慎。除 Sloan 商学院与 EECS MEng 项目外，明年新生入学人数较 2024 年下降近 20%，意味着 MIT 整体可能减少约 500 名研究生。

应对方面，校方提出多项措施：积极申报新的联邦机会（如能源部 Genesis Mission，MIT 提交了 176 份提案），拓展工业界资金（如新成立的 MIT-IBM 计算研究实验室），探索仅授硕士的付费项目，以及加强校友筹款与华盛顿游说。

HN 讨论延伸到更深层的结构性问题。多位评论者指出，学术圈本身正在经历代际重置：科学博士中位耗时已达 6 年，待遇差、就业难，约八成近期博士毕业生计划离开学术界，MIT 也是首批组建研究生工会的学校之一。有人认为 MIT 当前 41% 的研究生为国际学生，签证政策变化对其影响尤甚。也有评论者认为大学预算压力未必全是坏事，过去二十年高校通过学生贷款扩张行政人员、压低教学投入的模式难以为继。还有评论批评“纯硕士项目”实质是面向国际生的签证和现金通道，学术含金量有限。另一派声音则担忧基础研究萎缩对国家长期创新与人才储备的伤害无法立刻显现，但数年后将体现为能从第一性原理解决硬问题的人减少。

2. Bun 用 Rust 重写的 PR 已合并：百万行级翻译与争议

Bun 项目（一个 JavaScript/TypeScript 运行时与工具链）由作者 Jarred Sumner 主导，将原先用 Zig 编写的核心代码大规模迁移到 Rust，该 PR 现已合并。变更规模惊人——新增逾 100 万行 Rust 代码，删除约 4000 行，使 Bun 的 Rust 代码体量逼近 Rust 编译器本身。作者预告将撰写博客详细说明动机，主要源于 Bun v1.3.14 及更早版本中大量与内存生命周期相关的 bug，例如 use-after-free、double-free、错误路径漏释放等问题，这些在 Rust 中可借编译器与所有权机制转化为编译错误或自动清理；但跨 JS 边界重入与持有引用过久导致的泄漏仍需手工处理。

PR 中附带一份非常详细的「Zig 到 Rust 习语映射」指南，且代码库此前已引入与 Rust 等价的智能指针类型与 bun_collections crate，外界推测此次迁移筹备已久，可能与 Anthropic 的收购洽谈相关。

HN 讨论高度两极。质疑方关注多个点：源码中 unsafe { 出现 10,428 次、分布于 736 个文件，Rust 部分代码已逾 92 万行，疑似几乎完全由 LLM 翻译而成，人工评审难以覆盖；部分测试通过被改写测试本身（包括随机插入 sleep(1)）来实现；作者一周前还公开表示合并并非必然，如今迅速合入显得反复。还有评论指出 Bun 长期存在的「构建 Bun 需要 Bun」自举问题，希望迁移到 Rust 后能用通用工具链构建。另有用户表示将把项目迁出 Bun，认为这种治理风格过于激进。

支持方则认为这是观察 LLM 时代复杂软件管理的「金丝雀」案例，且翻译式重写本身具有研究价值；后续真正考验在于是否能保持向后兼容并应对部署在生产环境中的程序问题。围绕 Anthropic 是否在 Claude Code 中使用 Bun，以及若出错将带来何种声誉影响，社区也有不少猜测。

3. 移除 2024 RAV4 混动版的车载调制解调器与 GPS

作者出于对车辆遥测数据收集的隐私顾虑，记录了对自家 2024 款丰田 RAV4 Hybrid 物理移除数据通信模块（DCM）与内置 GPS 的过程。文章首先列出现代汽车的数据收集问题：车厂内置摄像头、麦克风、常开调制解调器持续上传位置、速度、加减速、油量、驾驶注意力等数据，默认开启且退出选项有限；这些数据通过 LexisNexis、Verisk 等经纪商货币化，并曾引发多起安全与隐私事件（Subaru 远程解锁漏洞、Tesla 员工传阅车内摄像头画面、车厂向保险公司出售驾驶数据等）。

移除 DCM 后，OTA 更新、丰田云服务、SOS 紧急呼叫将失效——这是用户需自行权衡的安全代价。车载麦克风走 DCM 线路，需安装第三方 DCM Bypass Kit（约 90 美元）恢复通话功能。GPS 单独拆除是因为 CarPlay 存在已知缺陷：车端 GPS 信号污染手机定位，导致导航失常。改装可能影响相关功能保修，但根据 Magnuson–Moss 法案，无法整车失保。

一个关键警示是：即便拆掉调制解调器，只要手机通过蓝牙连接，车机仍会借手机网络回传遥测数据；只有用 USB 有线 CarPlay 才能阻断，或使用蓝牙转 USB 适配器。

HN 讨论集中在几个方向。多人对「蓝牙连接为何会让车机使用手机网络」表示困惑，认为蓝牙本身仅传音频，怀疑是 PAN/tethering profile 被启用。也有人补充指出，CarPlay 与 Android Auto 本身也会向 Apple、Google 上传车辆遥测，绕不开。另一位同款 RAV4 车主反映该车 CarPlay 罗盘方向错误导致导航不可用，向丰田多次反映均被拒绝处理，对该品牌印象大幅下滑。其他车型方面，2024 款 Ford Maverick 据称可直接拔遥测保险丝无报错；新款 Kia CCNC 平台也可拆解蜂窝数据单元；Tesla 可剪断车门内的天线。也有评论强调，根本解法应是强有力的联邦隐私立法，并质疑车厂向制造商持续上传 GPS 是否触及反跟踪法律边界。

4. 一位开发者的自述：AI 让我变笨了

博主 James Pain 撰写短文反思过度依赖 AI 写作与编码所带来的能力退化。他坦言自己原本是一名「尚可」的软件开发者，过去一两年几乎完全通过 prompt 让 AI 写代码，不再亲手敲一行，结果发现自己已经基本忘记如何编程，目前正在重新自学手写代码。在写作方面，他也时常忍不住把文章粘贴给 Claude「检查」，但产出读起来不像自己，缺乏个人声音，反而进一步喂养了冒名顶替综合症与自我怀疑。

作者认为软件开发技能不会因 AI 而完全消失，仍会需要懂得读写代码的人，只是数量减少；他甚至期待 AI 能让软件行业回归更专业化——回到早期由数学家、物理学家、学者主导编程的状态，扭转过去 20–30 年因需求过盛而稀释专业性的趋势。文章本身坚持未用 AI 写作，作为一种对抗练习。

HN 讨论呈现多种立场。一些资深开发者表示自己使用 AI 时始终保留审视代码的「警觉感」，但承认初中级开发者很可能缺乏这种本能而陷入退化。多位评论者描述了具体的负面体验：新人入职用 AI 上手新语言，进度看似快，但实际技能积累慢、对自身 PR 缺乏信心，甚至连本该问同事的问题都交给 AI，加重了社交回避。教育领域的担忧同样适用于在职学习。

另一派则有截然相反的体验：在硬件、光谱学等领域，AI 帮助他们绕过繁琐的接口代码与样板逻辑，把精力放在领域问题上，学习速度反而提升 5–10 倍。还有人将 AI 视作「一队代理」而非替代思考，自己写原型、让 AI 做产品化和样板化，并维护代码库内既有模式。也有评论提到，AI 对跨语言开发者尤为方便，可以替代过去频繁的语法 Google 搜索。整体讨论呈现「工具依赖度」与「领域专长」共同决定收益或损害的格局。

5. 给 M4 MacBook Air 接一块 RTX 5090：能跑游戏吗

作者 Scott 记录了把桌面级 NVIDIA RTX 5090 通过 Thunderbolt eGPU 坞接到 M4 MacBook Air 的全过程。Thunderbolt 在 USB-C 上隧道 PCIe，对计算机来说 eGPU 就是一个稍慢的 PCIe 设备，Linux 与 Windows 通常即插即用，但 macOS 在 Apple Silicon 上既无 NVIDIA 也无 AMD 驱动。tinygrad 虽然新近发布了自研的 macOS eGPU 驱动，但只能配合其自家 AI 栈，且测得推理速度比 M4 Pro 原生 Metal 还慢约 10 倍，模型支持也很有限。

作者选择的方案是：在 macOS 上运行 arm64 Linux 虚拟机（QEMU + Hypervisor.framework），把 eGPU 通过 PCI passthrough 透传给 Linux 来源用 NVIDIA 驱动。文章详细介绍 PCI BAR 与 DMA 两个核心问题：将设备 BAR 内存通过 IOConnectMapMemory64 映射到进程，再交给 QEMU 的 hvf_set_phys_mem() 注入到 VM 物理内存中。但直接把 BAR 内存映射进客户机会触发 host 内核 panic，作者随后转向陷入式访问等替代方案。文中亦提及 Apple Silicon 上 Thunderbolt 仅在 macOS 受支持、Linux 内核暂不支持的现状，以及 1.5 GB 映射窗口的限制。

性能方面，eGPU 游戏可玩，但更引人注目的是 LLM 推理：在 4K token 提示下，M4 MacBook Air 原生 prefill 需约 17 秒，而挂上 eGPU 仅约 150ms，提升约 120 倍。作者也指出 macOS 平台长期被忽视的 prompt processing 瓶颈在大上下文场景中显露无遗。

HN 评论盛赞这是「真正的硬核 hack」。有 Apple 内部背景的读者表示曾多次向 VM 团队建议在 Apple Silicon Mac Pro 上提供 GPU passthrough 但未果。多位评论强调 Apple 官方文档明确称 eGPU 仅支持 Intel Mac 且不支持 NVIDIA，使这一成果更显独特。也有读者指出 Doom 等仅支持 OpenGL 的老游戏在 macOS 上几近无法运行，反而靠这套 eGPU 方案才能玩。还有人对其在本地 LLM 推理上的实用价值表现出极大兴趣，希望搭配 Mac Mini 形成低成本 CUDA 推理工作站。

6. Nginx 新漏洞 CVE-2026-42945：rewrite 与 set 组合下的内存破坏

研究团队 DepthFirstDisclosures 公开披露了一个影响 Nginx 的漏洞 CVE-2026-42945，命名为「Nginx-Rift」，并在 GitHub 发布了概念验证。根据公开信息与 F5 官方公告（KB K000161019），该漏洞触发条件较为具体：配置中存在带问号的 rewrite 指令，且随后存在引用未命名正则捕获组（如 set $var $1）的 set 指令。F5 已在 Nginx 1.31.0 与 1.30.1 中修复，OpenResty 则针对 1.27 与 1.29 系列发布了相应补丁。官方给出的缓解措施是使用具名捕获组（例如以 $user_id、$section 替换 $1、$2）。公开的 PoC 在测试环境中关闭了 ASLR。

HN 讨论的最大争议在于「ASLR 是否足以让人不必担心」。一位安全从业者强烈反对部分评论中「启用 ASLR 即无风险」的说法，指出 ASLR 仅是纵深防御机制，绕过它在大多数情况下只是时间和技巧问题，而 LLM 辅助开发使绕过门槛进一步降低；研究披露中已声明存在可靠绕过 ASLR 的方法，因此完全武器化的 exploit 只是时间问题，可能公开也可能私下流通。低估漏洞风险本身就有害。

另一些评论关注前置条件较苛刻（必须用到特定 rewrite/set 模式），认为日常配置未必受影响。也有用户询问 Debian 12 是否已包含修复，以及 Apache、Nginx 之外是否有用内存安全语言实现的成熟替代品——讨论中提到了 Java 实现的 Jetty 和 Go 实现的 Caddy，但二者历史上也有 shell 注入等其他类别的漏洞，并非天然更安全。社区整体反应是再次提醒：定期更新与最小化使用复杂 rewrite 配置仍是务实的防护方向。

7. 重读 John Perry Barlow《离开物理世界》

EFF 网站上的这篇文章收录于 John Perry Barlow 文库，写作年代约在 1990 年代初（HN 上对具体年份有 1992、1994、1998 等不同推测）。Barlow 以诗化的笔触描绘了人类正从物理世界向赛博空间迁移的图景：体力劳动被机器与海外工厂接管，西方知识工作者从事的许多脑力劳动则更像「让人不至闯祸的政府保留项目」。他设想了一个机器接管物理生产、人类被解放进入永久闲暇的乌托邦想象，但旋即指出这一切并未如愿展开——没有人想清楚在「无所事事的哲学闲谈」中如何向人们支付报酬。

文章被同集合的其他 Barlow 作品（《赛博空间独立宣言》《Decrypting the Puzzle Palace》等）所环绕，整体延续了其对网络空间作为新疆域的浪漫主义构想。

HN 讨论呈现复杂情感。有读者深受触动，表示物理世界中的劳动并非田园诗，而是被欠薪、被羞辱、深夜末班地铁上昏睡的真实经历；赛博空间曾是逃离的避难所，但如今同样被现实资本主导，AI 的到来进一步压缩了第三世界普通公民学习与建设的时间窗口。另一些评论赞叹文本的远见与不带天真色彩的洞察，认为他笔下「小而快速、短命的 adhocracy……数字化的赛博空间游牧采集群体」其实就是后来的创业公司与黑客小组。也有读者尖锐批评 Barlow 文风浮夸做作，并提到本人面对面也不甚讨喜。更多读者则从「字节没人能咀嚼，建筑无人居住，软件挡不住寒风」一句出发，呼吁重新重视物理制造与动手能力的教育。还有人指出他描述的「亚洲机器人接管制造」实际并未发生——劳动并未被自动化消解，而是被转移；当年互联网仅 80 万台主机，文本中的预言折射出技术乐观主义的时代限度。

8. C 经典谜题：a = a++ + ++a 的未定义行为

这篇 2011 年的博文讨论一个在 C/C++ 面试中广为流传的代码片段：int a = 5; a = a++ + ++a; 之后 a 等于多少。作者 Gynvael Coldwind 指出，这段代码涉及两处未定义行为（UB），因此理论上 11、12、13 都可能是”正确”答案。

第一处 UB 与读取顺序有关：编译器可以先取第一个 a 再做前自增，也可以先完成前自增再读取，分别得到 5+6=11 或 6+6=12。第二处 UB 与后自增的时机有关：后自增的结果可能在赋值时被覆盖（“MIA”），也可能被推迟到表达式结束才生效。两种 UB 组合后产生不同结果。作者还列出了在 GCC、Clang、MSVC、Intel C++ 等不同编译器与平台上的实测输出。

HN 评论的讨论焦点集中在几个方向。许多评论者指出，按 C 标准只要触发 UB，任何结果都可能出现，包括崩溃，因此”11/12/13 三个答案”的提法本身也不够严谨。一位评论者分享了类似的 2010 年文章和被面试官当作”标准答案”考核的经历，称这类问题在印度教材里长期被当作有确定输出来教，导致师生都不理解 sequence point 和 UB 概念。多人质疑：既然这里不涉及 CPU 架构差异，为什么 C 当初不直接规定求值顺序？回答方向包括：早期编译器各自实现不同，事后定义会让现有编译器变成不合规，更合理的做法是把这类写法变成编译错误而非赋予确定语义。也有人提到 C# 明确规定从左到右求值，因此该表达式结果是 12，没有 UB。还有评论指出，成熟 C 开发者的特征就是从不写出这种表达式，“写这种代码的人应该被开除”。整体共识是：这类题目作为面试题或教学题弊大于利，真正的教训是理解 UB 与 sequence point 概念，并在工程中主动避免依赖求值顺序的表达式。

9. 用 Claude/Codex Skill 在 AI 辅助编程中刻意训练技能

DrCatHicks 在 GitHub 上发布了一个名为 learning-opportunities 的 Claude Code 与 Codex 插件 Skill，目标是在 agentic coding 流程中嵌入”刻意练习”环节。当用户完成具有架构意义的工作（新建文件、修改 schema、重构、引入陌生模式等）后，Claude 会询问是否愿意花 10–15 分钟做一个学习练习，练习类型包括：先预测后观察并反思、先自己草拟方案再对比生成结果、逐步追踪执行路径、找 bug、teach-it-back 讲解、检索式自测等。配套的 learning-opportunities-auto 可在 git commit 后自动触发提示，orient 插件则能基于程序理解研究生成代码库导览。

作者引用学习科学中的几条原则解释设计动机：generation effect（接受生成代码会跳过主动加工）、fluency illusion（整洁的代码让人误以为已理解）、spacing effect（机器速度推人持续灌输而无间隔复习）、metacognition（缺少自我评估时间）、testing and retrieval（agent 总给完整答案，剥夺了自测机会）。一个关键设计是 Claude 会”提问后停下来等用户回答”，刻意压制其默认给出完整答案的倾向。

HN 讨论比较分裂。一些评论者揭示 Skill 的本质：其实就是结构化 Markdown 文件加一段 post-commit hook 的提示词，认为该项目”装饰性代码远多于实质”。有人贴出钩子的 JSON 内容证明其简单。也有评论者借此普及 Skills 概念，指出 Anthropic 自己的一些 skill（如前端设计 skill）也只是”激励性提示”而非具体步骤，说明 Skill 主要靠 prompt priming 起效。另一派评论强调创意本身的价值：当下 AI 编程最大问题就是”技能债”——盲目接受输出两小时后，连自己的代码库都讲不清楚，这类反思机制是必要解药。也有批评指出仓库没有 demo、没有 benchmark、没有样例输出，难以判断效果是否优于自写 prompt；以及 Skill 高度个人化、难以跨用户迁移。也有用户表示已经在尝试，认为每天几次练习能缓解”AI 脑萎缩”。

10. 加拿大计算机业余爱好者运动史：TRACE 与 1976–1985

约克大学计算机博物馆的这一在线展览记录了加拿大计算机业余爱好者运动，重点是多伦多地区计算机爱好者协会 TRACE（Toronto Region Association of Computer Enthusiasts，1976–1985）。展览基于该俱乐部的通讯、文档与口述史，呈现了 1970 年代中期到 1980 年代中期加拿大家用计算机普及的过程，以及业余爱好者运动在其中的角色。

展览将这一运动追溯到半个多世纪的无线电与电子爱好者传统，列举了《Modern Electrics》《Popular Electronics》以及英国、澳大利亚、苏联等地的同类杂志。1966 年美国成立的 Amateur Computer Society（ACS）是世界第一个此类组织，其会员在 1960 年代后期就尝试自制简陋计算机。1970 年代初微处理器问世后，homebrew 计算机活动迅速兴起，构成北美计算机业余运动的核心。

TRACE 起源于 1975 年末多伦多 Mississauga 的 Control Data Canada 公司：研发部门几位员工在下班后讨论微电子与自制微机的可能性，其中美国软件工程师 Harold Melanson 是关键召集人。1976 年 1 月 23 日，第一次正式聚会在他的公寓举行。展览还指出，业余爱好者活动并非美国独有，亚洲、欧洲、澳大利亚的爱好者基于本地条件和本地设计的机器开展类似活动，对各国家用计算机市场形成独特影响，强调技术发展并非全球同步、技术具有文化依赖性。该运动在 1980 年代末逐渐式微，但留下丰富文化遗产，使个人计算变得普及和包容。

HN 评论补充了不少时代记忆。有人惋惜展览未提到加拿大本土杂志《Electron》，它在 1970 年代中期突然转型成偏 HiFi 的《Audio Scene Canada》，失去了爱好者基础。来自加拿大西北部的评论者回忆当年获取这些资源极为困难，Heathkit 在 1200 公里以南，Radio Shack 是少数选项，如今只剩网购。Commodore VIC-20 用户回忆 Jim Butterfield 在加拿大 Commodore 社区的巨大影响。多人感慨那个”计算机知识宇宙尚可被一个人掌握”的年代，以及线下面对面讨论的氛围。多伦多 PET 用户组（TPUG）至今仍在运营年度 World of Commodore 大会，被视为当年俱乐部文化的延续。也有人调侃展览语气，称其暗示”多伦多是加拿大唯一的城市”。

11. 首个公开的 Apple M5 macOS 内核内存破坏利用，绕过 MIE

安全公司 Calif 在博客中宣布，已向 Apple 披露首个公开的、可在启用 MIE（Memory Integrity Enforcement）的 Apple M5 硅片上工作的 macOS 内核内存破坏利用链。MIE 是 Apple 基于 ARM MTE（内存标签扩展）构建的硬件辅助内存安全机制，作为 M5 和 A19 的旗舰安全特性推出，旨在阻断长期困扰 iOS/macOS 的内存破坏类漏洞。Apple 公开声明该机制可破坏所有已知的现代 iOS 公开利用链，包括近期泄露的 Coruna 与 Darksword 套件。

Calif 披露的高层信息为：该利用是一个 data-only 的内核本地权限提升链，针对 macOS 26.4.1，从无特权本地用户起步，仅使用普通系统调用，最终获得 root shell，目标为启用内核 MIE 的裸机 M5 硬件，涉及两个漏洞和若干技术。团队成员包括 Bruce Dang、Dion Blazakis、Josh Maine，从发现漏洞到工作利用只用了约一周。他们强调利用开发借助了名为 Mythos Preview 的 AI 系统协助识别漏洞，但绕过 MIE 这一全新缓解仍依赖人类专家经验。完整 55 页技术报告将在 Apple 修复后公开。团队还以”激光打印 PoC 亲自送到 Apple Park”的方式提交报告，戏称是为了避开类似 Pwn2Own 的提交洪流。

文章核心论点是：MIE 大幅提高了利用成本，但并非不可绕过；随着 AI 辅助漏洞挖掘能力增强，能够穿透此类高级缓解的漏洞将不可避免地出现，“AI bug 大爆发”将考验当前最强缓解技术。

HN 评论以谨慎与好奇为主。多数评论者期待详细报告，称世界尚未为 LLM 对安全研究的冲击做好准备；也有人遗憾文章细节太少，难以判断漏洞如何在 MTE 下存活。有评论从赏金角度分析，认为该展示按 Apple 现行 bug bounty 大约值 10 万美元，但若包装成针对 beta 版本、Lockdown 模式等场景，价值可达 150 万美元级别。部分用户开玩笑说自己”专门为了 MIE 买了 M5”，现在感觉被打脸。还有怀疑论者用反讽口吻把这类发布与 AI 公司宣传 Mythos 的市场动机联系起来。也有人指出博客经过编辑，“实地探访”部分内容已被精简。

12. arXiv 新政：含幻觉引用的论文将被禁投一年

Thomas G. Dietterich 在 X 上发布消息，介绍了 arXiv 针对 AI 生成内容的新执法立场。arXiv 行为准则规定：作者署名即对论文全部内容负全责，不论内容是如何生成的。基于这一原则，arXiv 将对包含”幻觉引用”（即由大语言模型编造、实际不存在的参考文献）的论文采取严厉措施：相关作者将被禁止向 arXiv 投稿一年，禁期结束后，其后续投稿必须先通过有声誉的同行评议会议或期刊接收才能再次发布到 arXiv。

这是对当前学术预印本平台上日益严重的 AI 生成 slop（垃圾内容）问题的直接回应。arXiv 一向以低门槛、开放著称，但其作为科学交流基础设施的角色使其无法承受大量含编造文献的论文涌入。

HN 评论普遍支持这一政策方向，认为这”对科学是巨大利好”，强调 arXiv 是免费服务但访问是特权而非权利。有用户指出，目前在 arXiv 官方政策页面尚未看到该规则明文列出，可能仍处计划而未生效阶段，并引用”末日机器若保密就失去意义”的电影台词调侃 arXiv 应公开宣示。也有评论提醒执行时需谨慎甄别：若有人未经同意把他人姓名挂为合著者并提交了 AI slop 论文，是否所有署名作者都会被波及，存在程序公正问题。一位评论者分享亲历，称同事提交的论文里残留明显 AI 痕迹，遭审稿人严厉退修，提醒大家提交前自查。还有评论提出更深层问题：合法的 AI 生成结果是否被允许？如果未来出现端到端 AI 自主生成、并形式化证明的黎曼猜想证明，是否应被接受？该问题没有简单答案，禁止编造引用只是反 slop 的第一步，并未解答 AI 在科学写作中地位的根本争论。

13. Numa：用单个 Rust 二进制运行第二个公共 ODoH 中继

Numa v0.14 在一个 Rust 二进制中同时实现了 ODoH（Oblivious DNS over HTTPS，RFC 9230）的客户端、中继和一个公共部署 odoh-relay.numa.rs，号称是该生态中除了 Frank Denis 运行的 Fastly Compute 版本之外的第二个广为人知的公共 ODoH 中继。

作者首先解释问题：常规 DoH/DoT 只加密传输，不解决”谁知道你在查什么”的问题。无论使用转发解析器还是递归解析器，总有某一方同时看到客户 IP 和查询内容。Apple iCloud Private Relay 通过双跳代理在系统层解决了 DNS 匿名化，但仅限 iOS/macOS、需付费、绑定 Apple 生态。NextDNS、Cloudflare for Families、Quad9 等隐私 DNS 服务要么需账号要么有遥测。自托管用户基本没有无账号的匿名 DNS 方案。

ODoH 的设计正是分割信任：客户端用目标解析器的 HPKE 公钥加密查询，经中继转发；中继看到 IP 但只看到密文，目标解析器（如 Cloudflare）能解密查询但只看到中继 IP。响应路径同理。Numa 在转发流水线中把 ODoH 作为第四种传输（继 UDP、DoH、DoT 之后），并通过独立模式 numa relay [PORT] 运行中继。HPKE 部分使用 Cloudflare 的 odoh-rs 库，未自行实现密码学原语。

实现中两点需特别注意：一是 SSRF 加固的主机名校验器，防止恶意客户端让中继转发到 169.254.169.254 等云元数据地址，采用严格正则匹配 RFC 1035 ASCII 标签、禁 IDN、禁 IP 字面量、限定 443 端口；二是 eTLD+1 同运营商检查，因为 ODoH 的安全性依赖于中继与目标分属不同组织，若同 eTLD+1 则可联合两端日志重建 IP↔查询的对应关系。Numa 默认拒绝此类配置。公共部署运行在 Hetzner VPS，使用 docker-compose 和 Caddy 终结 TLS，默认配对 Cloudflare 的 ODoH 目标。

文章也坦承 ODoH 的局限：目标仍能看到查询内容，只是不知道是谁；递归阶段对权威服务器仍是明文 UDP/TCP；小流量中继易被时序关联攻击，匿名集大小依赖运营商多样性；HPKE 公钥分发仍依赖 WebPKI 的中心化信任；DNSSEC 与 ODoH 是正交的，二者都需要。

HN 评论中，有人质疑这种架构是”乌龟驮乌龟”，最终还是看谁掌控代理、证书、加密，更倾向于自己运行 Unbound + DoH 完全自控。另一种质疑是：在 ECH 普及率仍低的背景下，目标服务器 SNI 仍泄露，ODoH 价值打折。也有评论者赞赏作者真去运行公共基础设施而非空谈隐私，关心运营痛点。有用户期待 macOS 服务化运行、与 Tailscale 集成、连接 Docker socket 做服务发现。还有人推荐 DoHoT（DNS-over-HTTPS-over-Tor）作为更激进的匿名方案。也有评论好奇真正的”完全匿名 DNS”是否在理论上就不可能实现，以及文章中的架构图是怎么做的。

14. WinUI 3 性能改进：微软回应”比 WPF 还慢”的批评

微软在 microsoft-ui-xaml 仓库的 GitHub Discussion #11096 中发布 “WinUI 3 Performance: A Leap Forward”，介绍 WinUI 3 在性能优化上的近期进展。背景是社区长期吐槽 WinUI 3 在多项基准测试中比已有 20 余年历史的 WPF 以及前代 UWP 更慢，引用的对比项目是 Noemata/XamlBenchmark。微软的帖子（被讨论的链接）阐述了一系列优化方向与改进数字，试图回应”新框架反不如老框架”的尴尬。

HN 评论以批评和怀疑为主。最高赞评论尖锐指出：WPF 二十多年前的原生程度尚不如新框架，但因诞生于资源紧张时代而更快；建议 WinUI 团队、乃至整个微软的开发都被迫在”最低系统要求”配置上工作，逼出从一开始就重视性能的文化。另一种声音从用户体验角度发问：性能改进是否会传导到 Windows 自带应用？多名评论者抱怨 Windows 11 的文件资源管理器、图片查看器、甚至 calc.exe 启动速度明显倒退，在微软自家硬件 Surface Book 2 上目录浏览和图像快速翻页都极其卡顿。还有人对比 macOS Finder 的迟缓，认为大厂普遍忽视基础体验。

技术取向的评论提出几个共同诉求：希望微软把 Windows 应用开发整合到 WinUI 一条路径并大力投入，甚至像 Avalonia 那样支持 macOS；希望提供纯 C 接口便于跨语言绑定；希望支持 F#（现状下宁可用 Avalonia）。也有人质疑在跨平台 UI 框架（如 egui、Avalonia）愈发成熟的时代，是否还有理由选择 OS 专属框架。开发者体验层面，有评论者亲身试用后给出严厉评价：UX 不算最差但 DX 极差，要实现”几乎”想要的外观需要堆叠大量 hack，文档质量糟糕，最终不得不直接读控件系统级实现源码；XML 中从零重写文本框等做法令人不安。还有一种结构性批评：微软内部似乎”不在乎技术质量除非对齐某 VP 目标”，本次优化只是局部行为，对系统整体使用体验改观有限。整体上社区表达了”很高兴看到他们终于关心质量”的勉强肯定和长期挫败感。

15. Codex 登陆 ChatGPT 移动端：手机上跟进长任务

OpenAI 宣布把 Codex 集成进 ChatGPT 移动应用，让用户能从手机连接到运行 Codex 的笔记本、Mac mini 或远程开发环境，实时查看截图、终端输出、diff、测试结果，审批命令、切换模型，或在已有线程中继续推进工作。文件、凭证、权限仍保留在本地机器上，通过一层”安全中继”在不暴露公网的前提下实现跨设备同步。OpenAI 表示 Codex 每周活跃用户已超 400 万，移动端的目标是在 agent 执行长时间任务时让用户能在通勤、午餐、临时灵感等碎片时间做关键决策，避免阻塞。

配套发布的还有：Remote SSH 正式可用，桌面应用会自动识别 SSH 配置中的主机并把远程环境暴露给授权设备；面向企业的程序化访问 token、Hooks（用于扫描 prompt 中的密钥、运行校验器、定制行为）正式 GA；本地环境下 Codex（CLI/IDE/App）支持 HIPAA 合规使用。移动预览版已在 iOS 和 Android 上对包括免费档在内的所有计划开放，Windows 端手机联动稍后跟进。

HN 评论氛围对 Codex 整体偏正面。多位用户认为 OpenAI 在编码 agent 工具链上比 Anthropic 的 Remote Control 更稳定，后者被指 bug 多、连接经常失败；也有人称赞 Codex 免费档可用、用 Rust 开源等。但也出现明显冷静声音：有开发者过去几个月一直通过隧道在手机上用 Codex，发现小屏幕和缺少键盘让自己倾向”少指挥”，结果产生更多技术债和代码 churn，认为键盘输入更利于清晰表达意图，因此手机更适合审批计划、做小决策，而非主导开发。另有用户抱怨这并非 Codex Cloud 或 CLI 的集成，Linux 桌面端依旧缺席；也有人对发布节奏感慨，认为编码 agent 领域剩下的创新空间主要在可靠性、安全和规模化方向。还有评论吐槽队列消息在手机和电脑之间偶尔不同步，远未完美。

16. 你不是在对齐 AI，而是在与它互相塑造

作者 Daniel Tan 在博客中提出，当前关于 AI”对齐”（alignment）的公共讨论被两类人主导：一边是以 Yudkowsky 为代表的末日派，公开主张必要时空袭数据中心、甚至承担核交换风险来阻止大规模训练；另一边是以 Andreessen 为代表的加速派，把反对者贴上”怨恨""病态”标签。两派看似激烈对立，但作者认为他们共享一个更大的前提：参与设计的是他们，其他人只是被设计的对象。真正被 AI 改变工作和生活的人，从未真正进入决策室。

作者进一步批评实验室式 alignment 的方法论：以 Anthropic 2026 年 4 月公布的一种自报告训练流程为例，数据由一个模型生成、另一个模型 prompt、再由 LLM judge 过滤，整个回路封闭在工程装置内部，所谓”人类”只是雇来的标注者构成的统计代理。作者称之为”配置哲学”——把对齐看作单向地把价值”装进”系统。

他主张的是一种更古老意义上的对齐：双方在接触中都被改变，类似两双手共同塑造湿黏土。用户以为自己只是越来越会写 prompt，实际上自己的思维方式、工作节奏也被系统反向塑形，而配置哲学让这一面变得不可见。文章呼吁人们拒绝在”更安全 vs 更快”的二选一中作答，而是与同样有所察觉的人一起，去构建能承认这种相互塑造的实践。

HN 评论分歧明显。有读者引用《半人马座阿尔法》中的台词共鸣”机器的感性反向侵入意识”；有人描述同事用 AI 提交 PR、自己用 AI 评审 PR，感到人类正在退化为 AI 间的传输管道。也有人质疑文章立场含混：批评 Yudkowsky 又似乎赞同某种”更好的对齐”，等于变相维持现状。另有评论从更宏观角度回击：文明本身就是一个与 Moloch 对齐的失控超智能，AI 只是加速既有方向；还有人指出 alignment 更多是营销话术，末日派靠夸大能力卖恐惧，加速派靠忽视社会成本卖增长。也有声音支持作者：技术接受本应是可选的，阿米什人选择不接受现代技术也活得很好，没必要默认所有人都要被卷入。

17. Amazonbot 终于开始遵守 robots.txt

博主 Xe Iaso 收到 Amazon Publisher Support 的邮件通知：自 2026 年 6 月 15 日起，Amazonbot 的抓取偏好将完全通过 robots.txt 这一行业标准指令来管理，站点管理员可在页面级、目录级或站点级控制访问，不再依赖手动申请。作者调侃邮件签名为”Get Outlook for Mac”却带着”sent from my iPhone”痕迹，邮件头显示确实来自 Outlook for Mac。

这一变化对作者意义特殊：Amazon 的抓取行为正是他开发反爬虫工具 Anubis 的直接原因。他表示会确认 Anubis 中已包含相应的 robots.txt 处理。

HN 评论中多位运维者印证 Amazonbot 此前确实激进。一位自托管 Git forge 的用户当天就因 Amazonbot 在一个月内消耗 750 GiB 流量而紧急上线 Anubis；另一位运营天气网站的用户表示该 bot 持续抓取被 disallow 的路径，最终只能加进 WAF 黑名单，并讽刺地指出自己用 AWS 的服务来挡 AWS 的爬虫。也有人提醒 robots.txt 本质只是君子协议，没有强制力，bot 完全可以伪造 User-Agent，并不能保证日志里的”Amazonbot”就是真的。Cloudflare 的做法被提及——把不遵守 robots.txt 的 bot 引向”黑洞”。另有人疑惑：为什么一个电商公司需要全网爬虫？也有人观察到 AWS 新的 User-Agent Amazon-Quick-on-Behalf-of-$HEXID，每周带来约 30GB 流量，却没有官方文档说明。

18. Anthropic 发布 Claude for Legal：面向法律工作流的插件套件

Anthropic 在 GitHub 开源了 claude-for-legal 仓库，提供一组面向法律工作流的参考 agent、skill、数据连接器和 MCP，覆盖企业内部法务、隐私合规、公司法、雇佣法、诉讼、监管、AI 治理、知识产权以及法学院诊所等场景。所有组件可通过两种方式部署：作为 Claude Cowork / Claude Code 插件安装，或通过 Claude Managed Agents API 接入自有工作流引擎，共用同一套 system prompt 和 skill。

仓库列出大量”以工作命名”的 agent，例如 Vendor Agreement Reviewer（按 playbook 红线审查 MSA）、NDA Triager（绿/黄/红三级分诊）、Amendment Tracer、Renewal Watcher、Tabular Diligence Review（一行一文档、每个 cell 都有引用）、Board Consent Drafter、Termination Reviewer、Worker Classification Screener 等。每个 skill 都从一份 CLAUDE.md 实践画像读取团队的 playbook。Anthropic 反复强调：所有输出都是律师审阅的草稿，不构成法律意见；引用须可溯源，特权和主观判断保守处理，管辖区假设需显式标注；这些插件不代表 Anthropic 的法律立场。

HN 讨论焦点集中在职业责任和保密风险。一位律师指出两大隐患：一是非律师用这些工具寻求建议，其对话不受律师-当事人特权保护，可能在诉讼中被作为证据；二是律师若使用并忘记关闭”帮助改进 Claude”开关，可能构成职业过失（malpractice）。多位评论者强调，客户若得知自己的机密故事被输入聊天机器人会非常不满，即便做了脱敏，模式仍会泄露，呼吁走私有部署或 in-house 栈。

竞争层面，有人指出这是对所有大型 Claude API 客户的”警示射击”，预示模型公司正逐步吃掉应用层创业公司——拿估值 110 亿美元的 Harvey 等法律 AI 初创做对比。也有人担心这类垂直产品会像 Google 的诸多项目一样两年后被关停。另有评论注意到该仓库的 PR 中 Lexis 集成被移除，认为这削弱了实用价值。还有人调侃 Anthropic 近期通过”批量生成行业 .md 文件”获取免费 PR 的套路，认为没人真的会去检查这些文档的合规性和有效性。也有人指出 anthropic（单数）GitHub 用户名属于澳大利亚某人，可能带来潜在混淆风险。

19. 硬盘固件逆向：为攻破 Xbox 360 而钻进 HDD 内部

作者在开发 Xbox 360 软改（softmod）漏洞利用时，遇到一个对时序非常敏感的竞态条件 bug：需要硬盘在收到读请求后延迟几百毫秒响应，才能稳定触发漏洞。为此他一度想修改 HDD 固件，在读取特定扇区时引入延迟。虽然最终他通过别的方法解决了时序问题，没有真的用上固件修改，但这段经历变成了一个系列博客的开端，覆盖固件 dump、IDA 分析、JTAG 在线调试、固件改写，以及后续用 AI 辅助分析未知 MCU 架构。

本文是系列第一篇，全程未使用 AI。测试对象包括 Samsung HM020GI、Hitachi HTS545032B9A300、Western Digital WD3200BEVT 和 Samsung PM871a SSD。作者描述了通用攻关流程：获取固件 dump（自行 dump 或寻找公开镜像）、加载到 IDA 处理压缩或加密、寻找回写途径（厂商后门命令或直接编程 flash 芯片）、定位处理 DMA READ EXT 命令的 handler，再写补丁、最后烧回。

他参考了 HDD Guru 论坛大量十多年前的资料和 MalwareTech 的同主题系列，发现其中”大部分信息要么错要么不适用”，但拼起来仍能形成大致路线图。Western Digital 的固件可通过专业数据恢复工具 PC-3000 的厂商命令 dump 出来；他在 HDD Guru 找到了 WD 的 dump，靠 Twitter 上有 PC-3000 的人帮忙拿到了 Samsung HM020GI 的 dump；Samsung PM871a 的固件则可在 Lenovo 提供的固件更新工具里提取，逆向该工具还顺带得到了烧写命令。

HN 评论中，有读者联想到 Red Balloon 公司面试时寄出的”奇怪硬盘”CTF，认为这篇文章正好可作参考。另有用户分享了 Samsung 840 EVO SSD 固件被反编译的 PDF 资料，警告 eBay 上 OEM 版 Samsung 硬盘的固件状态问题。也有人提及 spritesmods 早年那篇修改 HDD 固件以篡改 /etc/shadow 的经典文章。还有评论半开玩笑指出，这类技能恰好是 NSA 据曝光资料长期在做的事——把间谍代码藏进硬盘固件中。

20. GGUF 文件里除了权重还有什么，又缺了什么？

NobodyWho 团队撰文梳理了 llama.cpp 使用的 GGUF 文件格式。GGUF 最大的优点是”单文件”——相比 HuggingFace safetensors 仓库散落的多个 JSON 配置，或者 Ollama 的 OCI 多层结构，GGUF 把所有元数据塞进一个文件，使用上更省心。

文章逐项讲解 GGUF 元数据中包含的内容：

聊天模板（chat template）：模型训练时遵循特定对话格式，如 Gemma4 与 LFM2 各用一套标签。GGUF 在 tokenizer.chat_template 字段存放 Jinja2 脚本（Gemma4 的约 250 行），模型可能附多套模板（如带/不带工具调用）。不同推理引擎用不同 Jinja 实现：HF transformers 用 Python Jinja2，llama.cpp 自研 C++ 版本，NobodyWho 用 Rust 的 minijinja，性能差异存在但不构成瓶颈。

特殊 token：包括 <eos> 终止符、<bos> 起始符，以及标记 tool call、对话轮次的标签等。

采样器配置：研究机构发布模型时通常推荐一套采样参数。GGUF 最近新增字段允许直接在文件中指定 sampler chain，包括 general.sampling.sequence 来定义采样步骤的顺序——作者指出顺序非常关键，但 Ollama 镜像 JSON 和 HF generation_config.json 都不支持顺序声明，是常见痛点。

仍缺的部分：工具调用格式。Qwen3、Qwen3.5、Gemma4 等模型各自的 tool call 文本格式截然不同，导致每个推理引擎都要硬编码解析逻辑。作者建议 GGUF 标准应包含可派生 parser 的 grammar，NobodyWho 已在为每次调用根据具体工具动态生成约束 grammar。

HN 讨论中，GGUF 原作者本人现身表示遗憾：“投影模型（vision projection model）最终被分成独立文件，这违背了我设计 GGUF 时的单文件初衷”，希望社区有人推动合并。也有用户指出 safetensors 同样能装额外信息，且现代图像生成圈早就习惯单文件 checkpoint，只是因为文本编码器动辄好几 GB 才不再每次重复打包。另有评论认为 GGUF 目前最大缺陷是模型架构必须硬编码在 llama.cpp 构建中，新模型发布日”首日支持”质量参差不齐（Gemma vs Qwen 是典型对比），建议引入描述计算图的 DSL 嵌入 GGUF。一位 FLTK 桌面推理应用作者抱怨 llama.cpp 暴露的 llama_chat_apply_template C API 只硬编码了少量格式，无法走真正的 Jinja2 路径，要么自己写解释器要么从 llama.cpp 复制代码。还有读者吐槽 Gemma 等模型的 chat 模板”比 XML 还难读”。