Claude Haiku 5.5 把运行成本压低约 75%、GPT-6 在对话里开始自己搭界面，与阿波罗软件负责人 Margaret Hamilton 逝世——Hacker News Top 20（2026 年 10 月 8 日）

1. Claude Haiku 5.5

• 原文入口：Anthropic · Introducing Claude Haiku 5.5
• HN 讨论：49996437
• 提交者：sfkgtbor（提交于 2026-10-08 02:01）
• 快照热度：633 points | 319 comments
• 原文日期：2026-10-07
• 中文要点：Anthropic 发布 Claude Haiku 5.5，自称是它做过的最便宜、最快、能力最强的小模型，面向高频且对成本敏感的任务：摘要、压缩、数据库查询、分类；也适合给 Opus 5.5 与 Sonnet 5.5 当编码用的子智能体，以及实时客服、浏览器操作这类对速度敏感的场景。官方说它的平均运行成本比 Haiku 4.5 低约 75%；按单价算，10 万 token 以内的请求是输入每百万 0.10 美元、输出 0.50 美元、缓存读 0.01 美元，超过 10 万 token 后这几项都翻五倍，而 Haiku 4.5 的输入输出是 1 美元与 5 美元。Haiku 这一档第一次带上可调 effort 设置。基准上，GDPval-AA v2.1 从 Haiku 4.5 的 735 提到 1620（Sonnet 5.5 是 1840），Humanity's Last Exam 无工具从 10.2% 提到 45.9%，OSWorld 2.1 离线子集从 15.7% 提到 72.4%，Terminal-Bench 4.0 从 0% 提到 39.2%。同一批更新里 Sonnet 5.5 的缓存读从每百万 0.20 美元降到 0.10 美元，Anthropic 称这让它在多数 agentic 任务上的成本降约 20%；Max 与 Team 订阅者还会拿到每月 API 额度，Max 5x 是 100 美元、Max 20x 是 200 美元、Team 最多 500 美元共享。319 条评论里价格是第一条主线：有人指出 10 万 token 这个分档门槛对 agent 场景偏低、很快就会越过，也有人算出它比 GPT-6 Luna 的 0.10/0.50 更有竞争力，还有人专门为 Sonnet 缓存读降价叫好；第二条线是安全策略，评论引用官方说法说它在网络安全上比 Haiku 4.5 更严、但仍会拦下渗透测试与「更可能被攻击者使用的手法」，并质疑这样还剩下多少可用的防御任务；此外有人问 Haiku 4.5 是不是就此没人用了。

2. Margaret Hamilton has died

• 原文入口：MIT News · Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90
• HN 讨论：49998895
• 提交者：muglug（提交于 2026-10-08 05:16）
• 快照热度：431 points | 43 comments
• 原文日期：2026-10-07（页面标注；她于 9 月 30 日去世）
• 中文要点：Margaret Hamilton 于 9 月 30 日去世，享年 90 岁。她是阿波罗计划期间 MIT 仪器实验室软件团队的负责人，写过 130 多篇论文，也是把「软件工程」确立为一个独立学科的主要推手之一。她 1936 年生于印第安纳州 Paoli，1958 年在厄勒姆学院拿到数学学士，1959 年搬到波士顿后进入 MIT，一路做到 1970 年代中期；1976 年创办第一家软件公司 Higher Order Software，十年后又创办 Hamilton Technologies，后者的旗舰产品是系统建模语言 USL，设计出发点都是错误预防与容错。2016 年她获颁总统自由勋章，此外还拿过 2003 年 NASA 杰出太空法案奖、2017 年计算机历史博物馆 Fellow、2019 年无畏号终身成就奖，2022 年入选美国国家航空名人堂；她与 MIT 团队那份阿波罗代码于 2015 年整份放上 GitHub，2017 年她还成了一枚乐高小人偶。她生前接受采访时说，当年提出「软件工程」这个词时被当成笑话，别人拿她的「激进想法」开玩笑。43 条评论里，有人把她称作「黑条事件」级别的人物，有人贴出计算机历史博物馆的口述史，并据此推测 Levy《黑客》一书里那段深夜在 TX-0 上写坏气象模拟代码的故事主角可能就是她；也有人补充「软件工程」这个词出自她，并引用她解释为什么要把软件和硬件放到同等的工程地位。

3. GPT‑6 and Intelligent UI for everyone

• 原文入口：OpenAI · GPT‑6 and Intelligent UI for everyone
• HN 讨论：49996425
• 提交者：joshuawright11（提交于 2026-10-08 02:00）
• 快照热度：467 points | 238 comments
• 原文日期：2026-10-07
• 中文要点：OpenAI 把 GPT-6 推给 ChatGPT 的全体用户，并带上一个新能力 Intelligent UI：模型可以不再只用文字回答，而是当场拼出可点的按钮、表单、图表和能直接操作的界面。做法是给模型一套原生、可流式渲染的组件库，加一个边生成边编译的编译器，所以界面是逐步出现而不是等整段回答写完。训练上他们扩展了方法，让模型自己去判断该用文字、图形还是交互元素，并评估生成的界面是否清晰、有用、完整。同一版里还改了回答节奏：ChatGPT 可以在继续思考的同时开始作答，官方称在一组高价值日常 agentic 任务上，GPT-6 Extra High 开始作答的时间与 GPT-5.6 Medium 相当，分数却高于 GPT-5.6 Extra High；需要联网搜索的问题上，GPT-6 Instant 平均比 GPT-5.6 Instant 早 44% 开始回答。今天先向 Plus、Pro、Business、Enterprise 推送，明天扩到 Free 与 Go；Plus 及以上由 GPT-6 Sol 驱动，Free 与 Go 用 GPT-6 Luna，Work 与 Codex 这次不变。238 条评论里最集中的是「模型选择看不懂」：有人问为什么给 ChatGPT 配上比它弱的老模型，也有人担心输出变成界面之后不好导出、不好再加工；另一条线是它更像在补 Anthropic 的 artifact 能力；还有人对示范视频里「看纸质说明书很吃力、所以需要交互式解说」的说法不服，认为纸质手册本来就带图。

4. 'Jonathan' is the oldest land animal on Earth

• 原文入口：404 Media · 'Jonathan' Is the Oldest Land Animal on Earth. He Could Hold the Secrets to Defying Death
• HN 讨论：49998066
• 提交者：gumby（提交于 2026-10-08 04:01）
• 快照热度：17 points | 3 comments
• 原文日期：2026-10-07（页面标注）
• 中文要点：圣赫勒拿岛上的亚达伯拉象龟 Jonathan 大约 194 岁，是目前已知最长寿的陆生动物；研究人员首次测序了它的基因组，论文 10 月 7 日发表在《Science Advances》。它约 1832 年孵于塞舌尔，达尔文发表《物种起源》时它才二十多岁，1880 年代作为礼物送给英国殖民地总督时被带到圣赫勒拿岛，此后一直住在那里。研究拿它的脸颊拭子与另外几只象龟（包括一只 36 岁的 Tank）做对比，发现它在 DNA 修复、胰岛素调节、线粒体功能以及「低熵」甲基化等多数衰老通路上都带有独特的基因变异。研究作者、非营利机构 Kallel Foundation 的衰老研究者 Stephen Clark 说，他 2017 年就联系上它的饲养者，因为抽血风险太高改成引它张嘴取拭子，中间又遇到样本不完整、疫情与访问新规，样本最后由美国太空军从圣赫勒拿送到佛罗里达。快照时刻这条只有 3 条评论，其中一条拿游戏术语开玩笑，说这是把长寿点满、牺牲了速度和魅力。

5. Docker Agent

• 原文入口：GitHub · docker/docker-agent
• HN 讨论：49996259
• 提交者：saikatsg（提交于 2026-10-08 01:48）
• 快照热度：164 points | 77 comments
• 原文日期：日期未确认（仓库页不标发布日期；仓库创建于 2025-09-01，最近一次推送为 2026-10-07）
• 中文要点：Docker 放出 docker-agent，一个用声明式 YAML 配置就能创建、运行、分享 AI 智能体的工具，仓库描述是「Docker Engineering 出的 AI 智能体构建器与运行时」，Apache-2.0 许可，目前 3673 star。它本身是 Docker CLI 插件，可以直接跑 docker agent；Docker Desktop 4.63 以上已预装，也提供 Homebrew 与二进制发布。写法上在 YAML 里声明智能体、给它工具集，就能跑：工具既可以用内置的，也可以接任意本地、远程或跑在 Docker 里的 MCP 服务器；模型不限厂商，OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI 与 Docker Model Runner 都能接，也可以完全用本地模型。功能上强调多智能体分工协作、内置 think/todo/memory 工具、可插拔的 RAG（BM25、嵌入、混合检索与重排），以及把智能体推到任意 OCI registry 再拉下来跑。77 条评论里，第一条主线是「Docker 出这个干嘛」：有人问它和 Docker 有什么关系、有人觉得这是又一个 agent harness，像当年的 JS 框架一样人人都要发一个；第二条线是文档质量，有人专门贴出沙箱配置的链接说安全信息在正文里找不到；也有评论认为它在写论文、需要别人复现实验的场景下有用，但 uv 之类已经够用，而且它的隔离能力不如 Modal、E2B 或 Cloudflare 那类方案。

6. How did Rosalind Franklin miss the helix in her iconic DNA image? She didn't

• 原文入口：Science · Exclusive: How did Rosalind Franklin miss the helix in her iconic DNA image? She didn't
• HN 讨论：49969073
• 提交者：pavel_lishin（提交于 2026-10-06 03:07）
• 快照热度：35 points | 30 comments
• 原文日期：2026-10-05
• 中文要点：一篇新论文推翻了「Rosalind Franklin 没看懂自己那张 DNA 照片」的说法。沃森在 1968 年的《双螺旋》里写他看到第 51 号照片时「嘴巴张开、脉搏加快」，暗示那个顿悟只属于他；后来的通俗叙述也常说 Franklin 错过了照片的意义。科学史学者 Alistair Sponsel 与晶体学家 Brian Sutton 在《Journal of the History of Biology》上撰文，把注意力移到她几天前用同一份 DNA 样品拍的第 49 号照片：那张照片虽然有缺陷、衍射图样偏心且一边被截断（相机的底片夹滑动了），她却给它写了大量笔记，认出它提示螺旋结构，并第一次算出每一圈的螺距 34 埃、以及「每一圈螺旋的碱基数量（如果那确实是螺旋的话）」。所以他们推断第 51 号照片之所以在笔记里几乎没有记录，是因为她认为不必重复自己——她在几小时内重拍，是为了得到一张能拿去发表的干净底片。论文并不否认沃森与克里克的贡献：他们那个两条链反向、碱基互补配对模型解释了 DNA 如何携带遗传信息和复制，远远超出 Franklin 当时的理解，而且到 1952 年其他研究者也多半猜到分子是螺旋。Franklin 1958 年因癌症去世，无法回应沃森的叙述。30 条评论里，一条自称「DNA 爱好者」的评论说这是他第一次看到 Franklin 确实想到过双螺旋与中央碱基配对的实证，并想去重读 Judson 的《创世第八天》；另一条争论文章到底证明了什么，认为发现双螺旋的仍是沃森与克里克，Franklin 只是写下了别人没读到的单螺旋；还有人说纤维衍射本来就基本等于「螺旋」，真正有争议的是她有没有看懂螺旋参数的意义。

7. Show HN: Bigwords.page – Turn any screen into a sign. The URL is the app

• 原文入口：Bigwords.page · Turn any screen into a sign
• HN 讨论：49994443
• 提交者：SpeakingOfBrad（提交于 2026-10-07 23:44）
• 快照热度：322 points | 103 comments
• 原文日期：日期未确认（产品页不标发布日期）
• 中文要点：Bigwords.page 把整条链接当成一块显示屏：打开网址，文字自动放大填满屏幕，手机横过来就是接机牌、电视上就是倒计时、前台就是 Wi-Fi 密码牌。它没有账号、没有 App，也不需要服务端——所有内容写在 URL 的 fragment 里，浏览器不会把 fragment 发给服务器，所以站点自己也看不到你写了什么。手工拼链接的规则很简单：# 后面写正文，&key=value 加设置，%0A 换行，|| 分隔多张幻灯片并按 &interval 轮播，还能用 {countdown} 加 &until 或 &timer 做倒计时，二维码、链接、Wi-Fi、电话、短信、邮件都在浏览器里本地生成。作者在 HN 帖子下说，他做这个是因为要给一台只能远程管理、不能物理接触的平板推消息，把消息写进链接是最省事的办法；代码 MIT 许可，可以自建。103 条评论里，多数在夸这个「链接即应用」的做法简洁好用，还有人建议做成 Apple TV / Google TV 应用好让任何一块屏都能变成标牌；反面的声音有两类，一类是「我们以前管这个叫网站」，另一类是建议接语音控制。

8. Push ifs up and fors down: The idiom, its algebra, and its limits

• 原文入口：Debasish Ghosh · Push Ifs Up and Fors Down: The Idiom, Its Algebra, and Its Limits
• HN 讨论：49997073
• 提交者：speckx（提交于 2026-10-08 02:43）
• 快照热度：92 points | 43 comments
• 原文日期：日期未确认（博客页不标发布日期）
• 中文要点：作者从 TigerBeetle 的 Tiger Style 文档里那条建议出发——拆分大函数时把 switch/if 留在父函数里、把没有分支的逻辑挪到辅助函数，即「把 if 往上推、把 for 往下推」——追问这条经验法则背后的代数，以及它在什么条件下才成立。他先在中转举例：数据库查询里把投影和过滤尽早做（选择下推到连接之前），只有谓词引用的是连接同一侧的列时才合法；再在函数式语言里把选择写成 filter p . map f，用 catMaybes 的自然性推出 filter p . map f == map f . filter (p . f)，并指出重写只有在 p . f 能化简成作用于输入的廉价谓词（通常因为 p 只看 f 不动的那部分）时才真的省事——两边都是一次 O(n) 遍历，省的是对注定被丢掉的那些元素调用 f。结论是「fors down」更多是成本问题，其余改写是否合法由代数说了算，而每条法则都带着必须跨越组件成立的前提。43 条评论里，第一条很直接地批评这类文章：把琐碎的想法写成又长又绕、堆满类比的文章；另一条指出文中缺基准测试，而且 C# 从 C# 9 起、现代的 gcc/llvm 在判定安全时本来就会自动做这个优化，作者却一条都没提；也有人表示自己多年来一直这么做，理由是代码更好读、更好维护，跟速度无关。

9. In Vienna and Beijing, the first (thorium) nuclear clocks begin to tick

• 原文入口：The New York Times · In Vienna and Beijing, the First Nuclear Clocks Begin to Tick
• HN 讨论：49996406
• 提交者：gumby（提交于 2026-10-08 01:59）
• 快照热度：8 points | 1 comment
• 原文日期：2026-10-07
• 中文要点：维也纳与北京的两个独立团队同时造出了第一批「核钟」——靠数钍-229 原子核的压缩与回弹来计时，而不是数电子振荡或钟摆。成果 10 月 7 日（周三）发表在《Nature》上：这些钟大约每几百万年才会差一秒。审稿人把它称为核钟这个新兴领域的重要里程碑，加州大学洛杉矶分校也在做核钟、但未参与这项研究的物理学家 Eric Hudson 说这个方向「正在飞速前进」。它不会立刻取代全球原子钟网络——GPS 与「秒」的定义都还靠后者，而且最精密的原子钟要过一千多亿年才差一秒，精度比核钟高约一万倍。但核钟有一批潜在优势：未来可能比最好的原子钟更可靠、能做得更便携，还能用来搜寻某些暗物质——暗物质粒子穿过钍核时，会让原本平稳的核钟出现一次抖动。文章在 10 月 7 日做过一处更正，说明用来做钟的激光，148 纳米是波长而不是频率。快照时刻这条只有 1 条评论，没有形成讨论。

10. Shipping JPEG XL in Chrome

• 原文入口：Chrome for Developers · Shipping JPEG XL in Chrome
• HN 讨论：49991227
• 提交者：AshleysBrain（提交于 2026-10-07 19:25）
• 快照热度：472 points | 304 comments
• 原文日期：2026-10-06
• 中文要点：Chrome 从 155 版开始提供 JPEG XL（.jxl）的解码支持。官方给出的理由是它比 JPEG 压缩率好 30% 到 50%，同时支持无损压缩、内置 HDR，还能无损转码已有的 JPEG；他们建议 AVIF 与 JPEG XL 都试，并认为 JPEG XL 在高保真、无损压缩和需要细粒度渐进解码的场景里更有优势。博客重点讲了两件事。一是安全：图像解码器是浏览器里最关键的攻击面之一，所以他们没有复用 C++ 的参考实现，而是接入纯 Rust 重写的 jxl-rs，用内存安全从源头消掉越界读、堆溢出、释放后使用这类漏洞；为了不牺牲性能，他们推动了 Rust 的 target_feature_11 稳定，让 SIMD 指令不必写在 unsafe 里，并仿照 C++ 的 Highway（本身就出自 libjxl）做了一层 SIMD 抽象。二是验证：他们用 fuzzing 与 AI 代码审查跑过整个实现历史，没有发现内存安全漏洞。304 条评论里，最高的一条是被删掉之前的抱怨——Google 此前把 Chromium 里的 JPEG XL 支持移除过，如今又加回来，评论区列出了四场旧讨论的链接；有人希望文章能讲讲内部那场拉锯，并猜测工程师并没有说服高管，是其他浏览器都支持之后高管放弃了；另一条线是兼容性，有人回忆 WebP 直到今天在 Telegram、macOS 与各家看图应用里的遭遇，也有人指出 Safari 至今没打开 libjxl 的渐进加载。

11. If somebody tries to hot-patch an already-hot-patched function

• 原文入口：The Old New Thing · If somebody tries to hot-patch an already-hot-patched function
• HN 讨论：49978315
• 提交者：ibobev（提交于 2026-10-06 21:39）
• 快照热度：31 points | 7 comments
• 原文日期：2026-10-05
• 中文要点：Raymond Chen 回答一个假设性问题：如果有人去热补丁一个已经被热补丁过的函数会怎样。答案是「那就说明出事了」——热补丁这块空间只授权给 Windows Update 使用，在支持热补丁的系统上（按他掌握的情况是 Windows Server，以及较新的 Windows 11 企业版）管理员勾选之后，更新里标记为「可安全热补丁」的文件会用预留空间在运行中替换函数；既然只有 Windows Update 有权用这块空间，系统本来不需要处理「已经被别人补过」的情况。但如果有未授权代码用 detour 之类的手段改过函数，他读代码的判断是热补丁逻辑会把这个文件判定为不可热补丁，于是系统只能重启；更麻烦的是竞态：预扫描通过之后、补到一半时才发现某个函数被改过，此时既不能继续往前补，也不能可靠回滚（回滚大概也会因为补丁被二次覆盖而失败），内存里就留下一个补到一半的二进制文件。他还提醒，不是所有改动都能安全热补丁，比如改动数据结构布局或不变量的就不行，因为热补丁之前创建的那些实例会处于非法状态。7 条评论里，一条补充说 Windows 的并行 DLL 加载在发现某些 NT DLL 函数被 hook 时也会自我保护性地关掉自己；另一条说眼下 AI 正在冲击计算机安全，及时打补丁比以往更重要，重启的代价比过去更贵，所以世界需要更多热补丁；也有人指出把 hook 说成「未授权」的措辞奇怪，因为 detours 库本来就是微软自己做的。

12. Navier–Stokes Lost in Translation

• 原文入口：arXiv · Navier-Stokes lost in translation: Why Lean verification of AI autoformalisation does not guarantee correct natural language proofs
• HN 讨论：49994145
• 提交者：nill0（提交于 2026-10-07 23:24）
• 快照热度：237 points | 150 comments
• 原文日期：2026-10-06（arXiv 提交日）
• 中文要点：Alexander Bastounis、Fabian Circelli 与 Anders C. Hansen 这篇论文要说明的是：把一段自然语言数学文本交给 AI 翻成 Lean，再用机器检查通过，并不等于原来那段自然语言论证是对的，因为翻译本身很难做到语义忠实。他们指出，要消除数学自然语言里的歧义，这个问题在可解复杂性指数（SCI）层级里任意高——SCI 等于无穷，也就是说比停机问题（SCI 为 1）还难；换句话说，「语义忠实地自动形式化」比任何可计算问题都难。为了说明后果，他们给出一批 AI 把自然语言命题与证明译进 Lean 的实例，里面出现了错译，导致自然语言证明与 Lean 里的「验证」对不上，其中包括 OpenAI 宣布的那份 Navier–Stokes 证明——论文称那份形式化证明与「解发生爆破」的自然语言证明并不对应。150 条评论里，第一条长评把问题概括得很清楚：数学是逻辑的，但数学写作仍然是自然语言，符号会重载、惯例不写明、很多东西靠上下文，所以模型可以证明一个能通过检查的命题，而那个命题并不是数学家原本想说的；他问这是否意味着一些已宣布的 LLM 证明在人工复核后会站不住。有评论者分享自己花三周用 Claude 形式化一篇关于借用检查器的论文，形式化跑通了，却反过来暴露出原文里好几处错误；也有人给出反面意见，认为形式化至少抓住了原文漏掉的东西。

13. How machines learned precision

• 原文入口：Gary Linscott · How Machines Learned Precision
• HN 讨论：49980626
• 提交者：glinscott（提交于 2026-10-07 00:14）
• 快照热度：94 points | 42 comments
• 原文日期：2026-10-01（页面标注）
• 中文要点：作者 Gary Linscott 用一批可旋转、可缩放的三维插图讲工业革命里的精度是怎么被造出来的，是他之前那篇梁式蒸汽机文章的续篇。起点是瓦特蒸汽机气缸的加工：当时的大炮镗床把刀具装在一根只有一端受支撑的长杆上，杆子自己会下垂、又被凹凸不平的缸壁推来推去，于是刀跟着歪走；1775 年前后 John Wilkinson 把镗杆改成穿过气缸、两端都有轴承支撑，刀头就像铅笔沿着尺子走。1776 年 Matthew Boulton 写信说，Wilkinson 镗的一只 50 英寸气缸「任何部位的误差都不超过一枚旧先令的厚度」——不到一毫米，相对尺寸比瓦特七年前的试验气缸准约 30 倍。接着是车床的刀架：手工扶着刀具车铁会被切削力推开，留下凸起、下一转又撞回刀具，形成颤振；把刀具夹在铸铁滑座里、用丝杠推进，力就由铁来承担。有了刀架，刀具开始复制导轨的弯曲，于是需要一块平的基准面。文章详细讲了刮研和三板法：用涂色法找出高点、用刮刀每次刮掉几微米，再把三块平板互相配对研磨——两块凸凹相配可以互相贴合，只有三块板在任何配对与朝向下都能贴合时，它们才是平的，这样就能在没有平面可抄的情况下造出平面。到 1856 年，Whitworth 已经造出能分辨一百万分之一英寸差值的测量机。42 条评论里，作者自己出面说是梁式机那篇的续作、越挖越远；有人引用文中「五十牙一英寸的主丝杠不够准，那就做一个一英尺长、六百牙同时啮合的螺母」这段，说这才是技术史好看的地方；也有人问那些动画怎么做出来的，说静态插图很难看懂机械系统。

14. Animated ASCII Art for Web Pages

• 原文入口：ascii.rest · animated ascii art for web pages, by @bas3line
• HN 讨论：49993857
• 提交者：turrini（提交于 2026-10-07 23:05）
• 快照热度：274 points | 56 comments
• 原文日期：日期未确认（产品页不标发布日期）
• 中文要点：ascii.rest 收了 191 件可以在网页里直接跑的动画 ASCII 作品，用 TypeScript 写成、没有任何依赖，MIT 许可，React、Next.js、Astro 或者一个 HTML 标签都能用。全部按类别分好：13 个整幅场景（高山黎明、峡湾极光、深海礁石、沙漠之夜、地出、京都黄昏、雾林、夜海岸、海上日落、风暴平原、泰姬陵黎明、瓦拉纳西河坛等），12 个界面件（启动日志、日历、数字钟、文件树、表单控件、进度条、骨架屏、终端等），10 个数据可视化（柱状图、K 线、CPU 表、均衡器、仪表、心跳、热力图、雷达、迷你趋势线、在线时长条），9 种文字效果（打字机、马赛克、故障、跑马灯、摩斯码等），27 个编程语言 logo、22 个 Linux 发行版标识、12 个几何形状、11 个太空题材、14 个物理模拟、16 个自然题材、10 个生物、14 个物件、13 个生成艺术和 8 个特效。站点还给每件作品标了 GitHub 入口。56 条评论里，有人夸好看但直言「这不算 ASCII 艺术吧，那些大小不一的圆点不是 ASCII 字符」，有人发现大约一半动画的行序是乱的，也有人觉得它更像一种「技术苦修的做派」；支持的一方说最早在拨号 BBS 上就是靠这种动画过日子的，还有人提到自己做类似效果是为了给终端或文档加一点动感。

15. A new write and space optimized storage engine for MySQL is here

• 原文入口：TidesDB · TidesDB now available for MySQL v9, v26
• HN 讨论：49963568
• 提交者：alexpadula（提交于 2026-10-05 19:40）
• 快照热度：14 points | 1 comment
• 原文日期：2026-10-05
• 中文要点：TidesDB 现在作为外部插件形式的存储引擎提供给 MySQL，作者说这个项目最初就是从 MySQL 分支起家的，当时社区没法把它做成插件，绕了一年才终于落地。它不是一个分支：你在原版 MySQL 里加载引擎，同一台服务器上 TidesDB 的表可以和 InnoDB 的表并排放；这一版配的是 TideSQL-MySQL v2.0.0 加 TidesDB v10.1.1，测试对象是 MySQL v9.7.0 与 v26.7.0。因为 MySQL 没有引擎专属的建表语法，表的 TidesDB 选项写在 ENGINE_ATTRIBUTE 这个 JSON 里，名字由引擎定义，写错会直接报错而不是被忽略；每个选项背后都有一个 tidesdb_default_* 会话变量，可以一次设好让所有建表语句继承。默认打开压缩，可选 NONE、SNAPPY、LZ4、ZSTD 与 LZ4_FAST，默认 LZ4；LSM 的层数比例、最小层数、第一层文件数触发阈值都由用户设，压实策略不用选，引擎按树的状态在三种合并方式里自己挑；耐久性只有 tidesdb_memtable_sync_mode 一个开关，因为所有表共用库的预写日志。快照时刻这条只有 1 条评论，是作者自己出来说这是 TideSQL for MySQL 的第一个正式版本、事务型存储引擎、自研且对标 InnoDB，邀请大家试用。

16. Brownian Motion

• 原文入口：Gregory Gundersen · Brownian Motion
• HN 讨论：49976818
• 提交者：signa11（提交于 2026-10-06 19:11）
• 快照热度：23 points | 0 comments
• 原文日期：2026-04-22（页面标注的原始发布日期）
• 中文要点：这篇 4 月写的文章用一条离散时间的随机游走推出布朗运动的边缘分布，帮读者建立直观。作者从一杯水里悬浮的花粉颗粒讲起：如果记录它的垂直位置，会得到一条锯齿状的随机路径；把这条离散游走在时间与空间上按同一比例缩放，就能取到一个连续的极限过程，而这个极限过程的高斯分布可以直接算出来。文章按这个思路一步步给出期望、方差与转移密度的推导，是给概率与随机过程做入门直觉的一篇笔记。这条在快照时刻是 0 条评论，没有讨论可供参考。

17. A font recreated from photographs of classic Commodore 64 keycaps

• 原文入口：GitHub · szabadkai/c64-keyboard-font
• HN 讨论：49990224
• 提交者：sohkamyung（提交于 2026-10-07 17:17）
• 快照热度：374 points | 62 comments
• 原文日期：2026-10-05（仓库创建日；仓库页不标发布日期）
• 中文要点：Levente Szabadkai 照着自家一台中欧版 Commodore 64 的键帽照片，重制出了名为 C64 Keyboard 的字体，并且把字形的形状清理过、比例统一。它复刻的是键帽上印的字符，不是屏幕上的点阵字库：包含大写字母、数字、标点、箭头、英镑符号与 π，部分带音标的字母（含匈牙利语字符），f1 到 f12 的功能键标注，以及全部 63 个 PETSCII 图形符——这些图形符是按几何形状重新画出来的平滑轮廓。字形来自他自己的机器，身份与键位对照参考《Ultimate Commodore 64 Reference》，线条粗细、弧度和印刷比例则从键盘照片推断，作者说明这不是照片描摹。当前版本 1.112，提供 TTF、OTF、Webfont 与完整包，还有浏览器预览页可以点功能键与 PETSCII 按钮试打字；作者把这套字体连同可编辑轮廓、构建脚本一起以 CC0 1.0 放入公有领域，商用、修改、再分发都不需要署名，但用于描摹的键帽特写照片没有包含在内，历史键帽设计与商标的权利也不在授权范围内。62 条评论里，有人先问下载链接是不是坏了，也有人马上说想要 ZX Spectrum、Apple II 版；一条评论指出原版键帽的字体其实是现成的字体（VIC-20 早期版本用的是 Microgramma），并好奇 C64 键盘原本用的是哪款；还有人提到 C64C 的键帽字体与这台机器差别很大，而因为复古审美，原版那套字反而显得更现代。

18. Meta and Microsoft take steps to reduce employee usage of Claude AI

• 原文入口：RS Web Solutions · Meta and Microsoft Limit Employee Use of Claude AI Tools
• HN 讨论：49997161
• 提交者：speckx（提交于 2026-10-08 02:49）
• 快照热度：252 points | 246 comments
• 原文日期：2026-10-07
• 中文要点：这篇文章转述《The Information》10 月 5 日的报道：Meta 与微软都开始明显压低内部员工对 Anthropic Claude 的使用量，转向自家的编码工具。微软此前预计内部一年用在 Anthropic 技术上的支出会超过 10 亿美元，在管理层要求员工少用 Claude、多用 GitHub Copilot 与 OpenAI 之后，这个估计被下调了三分之一以上；在其云与 AI 部门，每名员工每月的 AI 花费上限据称从 10 万美元降到多数情况下约 1 万美元。需要说明的是这些是上限而不是实际支出，而且降的是内部预算，不等于微软把 Claude 从对外产品里撤掉——报道说客户通过微软企业平台使用 Anthropic 模型的支出仍在上涨。Meta 那边，Claude Code 的使用人数从今年早些时候的约 6 万人降到约 3 万人，裁员有影响，但报道把主因归给公司转向自家 AI 方案。246 条评论里，多数人认为这是「自家产品要优先自用」而不是能力或省钱问题：一家既雇工程师又在做 AI 产品的公司，内部使用首先是为了改进自己的产品；也有人算账，说按 Claude Team 每开发者每月 25 美元计，能花到这个量级的团队本身就有问题；还有评论说这已经是「够用就好」的时代，多数场景并不需要最好的模型，另有人担心这会影响 Anthropic 的收入，反驳者指出真正付钱的是企业客户。

19. Sharing AI progress in mathematics

• 原文入口：OpenAI · Sharing AI progress in mathematics
• HN 讨论：49984923
• 提交者：OfficialTurkey（提交于 2026-10-07 06:17）
• 快照热度：1219 points | 1393 comments
• 原文日期：2026-10-06
• 中文要点：这条是 10 月 7 日那期写过的同一个 HN 条目，页面内容没有变化——OpenAI 把一批由内部前沿模型产出的数学结果放进 GitHub 仓库，配 Lean 形式化、10 份模型推理摘要、按 ChatGPT Pro 用量折算的算力估计与尝试题目数统计，并且说自己是在与高等研究院的「数学与人工智能顾问组」（AGMAI）沟通、参考其 9 月 29 日公开建议之后才这样发布的。变化在讨论：一天之内点数从 253 涨到 1219、评论从 213 条涨到 1393 条，成了当天首页讨论最厚的一条。第一天的争论主要是这次公布算不算尊重数学界，以及这些结果有没有被抽查过；这一天新长出来的讨论更具体：有人逐条点出其中几个结果的意义，认为黎曼、Hodge 与 Unique Games 这些方向上的进展如果成立，等于把人类几十年的数学进度压缩进来，还有人专门给出 Unique Games 猜想在不可近似性结果里的地位；质疑的一方继续追问按这个数量和覆盖面根本不可能仔细复核，预言其中会有一条是错的，并把矛头指向「Lean 之外还有自然语言到形式的翻译这一层」——这正好与本期第 12 条那篇论文是同一场争论的两端；也有在读博士生问，如果自己写的题目已经被「预印本」覆盖了该往哪走。

20. House with 15m underground tunnels for sale for 300k

• 原文入口：Reading Chronicle · House with 15m underground tunnels on sale for £300k
• HN 讨论：49992125
• 提交者：librasteve（提交于 2026-10-07 20:57）
• 快照热度：149 points | 154 comments
• 原文日期：2026-10-06
• 中文要点：雷丁 Tilehurst 一栋带地下隧道网的房子以 30 万英镑挂牌。土木工程师 Tony Deane 从 1980 到 1990 年代带着六个孩子，用桶和独轮车手工挖出了这套地下工程：向下四层、深度超过 15 米，地下面积 1300 多平方英尺，包含隧道、储藏室，还有一条他自己修的运土小铁路。里面有一台一吨的货运升降机、两扇暗门（其中一扇是 1.5 吨重的滑动混凝土墙），还有一个房间的入口藏在水池边一枚 23 英尺高的火箭模型里——Deane 家的地下工程更早就开始了，1960 年代他们就在泳池旁挖过地下更衣室。挖的多是白垩，本身有自承能力，需要的地方再用混凝土手工浇筑；这条隧道网几十年里基本不为外人所知，连邻居都不知道。拍卖方 BTG Eddisons 的拍卖师 Richard Worrall 说他从业以来没见过这样的东西。154 条评论里，开头几条在纠正标题的读法（是地下 15 米，不是 15 百万条隧道）；往下分成几支：有人担心挖到邻居地基下面、以及地下管线怎么办，立刻有人回忆起伦敦富人向下扩建导致整条街沉降的旧闻；有人嫌文章广告太多、也不给房源直链，于是有评论补上拍卖页链接，说那里有更多照片和地下平面图；还有人算了一下发现带泳池的独栋只要 30 万英镑相当便宜，并和「Colin Furze」这类地下爱好者联系起来。