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

HN 每日深度阅读 · 2026-08-03

本期整体偏向"工具与语言"的多线并进：既有 Karpathy 用大模型程序化生成《魔戒》、青蛙 SVG 基准等对 LLM 能力边界的试探，也有 F*、Fuse、Cyber 等语言项目和 Kakehashi、Bor、Meshdiff 等系统与桌面工具的持续打磨。

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

共 20 篇 · 约 12,080 字 · 约 30 分钟读完

1. Karpathy 用 Opus 5 渲染《魔戒》：从”鹈鹕骑车”到程序化生成世界

Andrej Karpathy 在推特上分享了一个新实验：他将《魔戒》第一段文字交给 Opus 5，给予约 100 万 token（约 10 美元）的预算，让模型用 three.js 渲染出来。模型运行约两小时，生成了 5500 行代码，程序化地渲染了这段故事。Karpathy 承认成品”有点粗糙”，但认为令人惊讶的是 LLM 能够在 (x,y,z) 坐标中放置和编排多边形资产，并写出动画代码。

他借此提出”鹈鹕骑自行车”式的 SVG 测试已经不够用了，需要新的评测方式。他还引申出两点观察：一是 LLM 拥有”无限耐心”，可以完成”没人愿意做”的超定制化工作，未来或许能按需生成”临时版 GTA”式的沉浸世界；二是这类任务暴露了 LLM 的弱点——它们无法高效地感知视频或玩游戏，Opus 5 只能通过反复截图来审查自己的成果，过程中出错不少。

HN 评论对这一框架反应两极。多位评论者指出，反复观看 AI 生成内容让人们对”质量”的期望大幅下降——一只笨拙的鹈鹕就被宣告”问题已解决”。有人认为 Anthropic 模型显然专门针对 three.js 做了训练，因此 three.js demo 并不能代表通用能力，就像”厄多斯证明”无法说明模型能否运营一台自动售货机。也有评论者为该基准辩护，认为它把评测从静态图像推进到了对物理世界理解的定性衡量。还有人批评 Karpathy 关注短视频式炫技指标，真正的评测应该是在自己的真实工作负载上做 evals，建立成本/质量/速度画像。此外有评论指出，模型对文本的理解也不到位，比如把比尔博的”消失”误解为魔法传送。另有人提议用 LLM 找《威利在哪里》来做基准，发现目前没有模型能稳定完成。

2. 从”山羊”到”尽管”：70 年英语核心词汇变迁反映的世界

Pudding.cool 的一篇可视化长文对比了两份面向英语学习者的”通用服务词表”：1953 年版约 2300 词，2023 年新版约 2800 词。两份词表都能覆盖日常英语用法的 84%–90%。70 年间约 600 个词被移除，1100 多个被加入。

一些变化直观可解释：telegraph（电报）消失，computer、website、blog 加入；tobacco 被 cigarette 取代；motherhood 变成 mom，dad 也进入词表。但更耐人寻味的是：apple、fork、soap、umbrella、leaf 都没进入新词表；goat、donkey 消失但 dog 保留；bread 留下但 flour、wheat 被移除；cook 在新表里，boil、bake、fry 却不在。新增的词多是 mortgage、corporation、appropriate、analysis、fairly、despite 这类抽象概念。

作者用 UCREL 语义分析系统将词按 21 个主题分类，发现萎缩的类别几乎都与”直接的物理世界”有关，而扩张的都是远离身体经验的抽象领域。她把类别按”物理范围”分为五层：自我、周遭、制度、社交、抽象/普适，发现词汇明显向后两层迁移。这与劳动结构变化吻合——1957 年美国白领首次超过蓝领，2000 年体力劳动者已不到四分之一。作者还用 concreteness rating（1–5 具体度评分）验证：高度具体词从 1953 年的 21% 降至 2023 年的 14%。她援引”双重编码理论”指出具体词更易被大脑记忆，而抽象词只走语言通道。

HN 讨论中，一位曾尝试给英语学习 App 排序词汇难度的开发者指出根本没有”标准答案”：面向旅行、看电视、读报纸、日常生活的词表差别巨大，且日常口语几乎没有可靠的语料统计。有评论者认为词表中 humble、loyalty、fellowship 让位给 community、identity、ethnic、gender、narrative，反映了不平等加剧下的部落化倾向。还有人分享构建德语类似词表遭遇的偏差问题（如维基百科语料让 Datenschutz、Impressum 意外高频）。大量评论则集中吐槽该页面的 scrolljacking 阅读体验极差，让空格翻页和键盘滚动都无法正常工作。

3. 挪威三文鱼帝国：从”Project Japan”到峡湾生态危机

ABC News 长文回顾了挪威三文鱼养殖业的兴起与代价。1980 年代中期，挪威终于培育出可圈养的大西洋三文鱼——一种比野生祖先更温顺、生长更快的品种。为打开日本市场，挪威政府启动了为期十年的”Project Japan”营销计划：当时日本人认为生三文鱼多寄生虫、口感不佳，只吃金枪鱼。在一家三文鱼合作社破产后，政府将 5000 吨积压三文鱼卖到日本，并在东京大使馆持续游说进口商与餐厅。十年后，三文鱼寿司成为日本料理主食。

叠加 80–90 年代 omega-3 热潮，挪威如今供应全球一半以上的大西洋三文鱼，产业规模是塔斯马尼亚的 18 倍，在苏格兰、法罗群岛、智利均有养殖场。三文鱼是挪威仅次于石油的第二大出口，被视为”下一桶石油”。但代价日益显现：绝大多数网箱没有底部，鱼粪、尿液和残饵直接进入峡湾，成为富营养化的”肥料”，助长有害藻类，压制海带林、耗尽氧气。Hardangerfjord 深处的氧气含量自 1950 年代以来下降了约三分之一。摄影师兼自由潜水员 Aleksander Nordahl 记录了三年间峡湾水下从原始海带林到褐色藻毯的剧烈变化。政府在”可持续”旗号下仍支持产业扩张，反对者被视为”反对挪威的未来”。

HN 评论涉及多个层面。有评论者指出深海远洋养殖能大幅缓解问题，只是成本更高，并预测中国养殖崛起后 10–20 年内挪威份额将大幅萎缩。有人揭露产业界雇佣退休教授撰写”科研报告”游说地方议员的做法。多位评论者补充了文章未提及的重要问题：养殖三文鱼逃逸与野生种群交配，正在破坏野生三文鱼溯河产卵能力；养殖三文鱼肉本身是灰色的，鲜艳橙红色来自饲料着色剂。也有近期到过日本的读者反映当地寿司店并没有三文鱼选项，被告知”三文鱼是给小孩吃的”，与文章的”日本主食”说法存在出入。另有挪威居民表示因政治、生态和动物福利原因，全家已不吃养殖鱼。挪威本土记者则称国内媒体多年批评鱼虱问题，庆幸终于获得国际关注。

4. “整垮这个女人”：eBay 高管骚扰博主案 5600 万美元赔偿

FT 报道了 eBay 前高管针对一对独立电商 newsletter 作者夫妇的骚扰活动最终以 5600 万美元民事赔偿收尾。这对夫妇 Steiner 长期在其电商时事通讯中批评 eBay，招致时任 eBay 高层的报复。一句”crush this lady”（整垮这个女人）被披露为内部指令。eBay 全球安全团队的七名成员——其中包括前警队队长——协作策划了骚扰计划，向 Steiner 家寄送死鱼、活蟑螂、色情杂志订阅、丧葬花圈等物品，并驱车前往对方所在地实施跟踪与安装 GPS。

刑事层面，多名前 eBay 员工已陆续被判刑：前安全高级总监 Jim Baugh 获刑 57 个月，前全球韧性总监 David Harville 24 个月，前情报高级经理 Stephanie Popp 12 个月，前安全运营高级经理 Philip Cooke 18 个月加 12 个月居家监禁，以及若干其他判决与居家监禁。此次 5600 万美元的民事赔偿是这一系列诉讼的延续。

HN 讨论集中在几个疑点。多位评论者难以相信这是唯一一次此类行动——eBay 有大量在线批评者，安全团队涉及多名前警官，“很难相信这些人某天早上突然决定飞越全国去破坏别人家”，希望有人调查这些人的更早履历。有评论者不解为何”董事和分析师”级别的人会因一份 newsletter 就集体参与如此明目张胆的犯罪，而更高层高管却未被追诉，怀疑存在掩盖。也有人借此讨论 eBay 作为平台的其他问题，例如对商品价、运费甚至税费总计约 13% 的抽成；法国竞争者 Leboncoin 仅对商品价抽 5%。另有引用 Scott Adams 观点的评论：只要有作弊机会而无监管，人就必然会作恶。

5. F*：面向证明的通用编程语言

F*（读作 F star）是一门面向证明（proof-oriented）的通用编程语言，同时支持纯函数式和带副作用的编程。它将依赖类型的表达力与基于 SMT 求解的证明自动化以及基于 tactic 的交互式定理证明相结合。F* 程序默认编译到 OCaml，部分子集可通过 KaRaMeL 工具抽取为 F#、C 或 Wasm，或通过 Vale 工具链抽取为汇编。F* 本身用 F* 实现，用 OCaml 做 bootstrap。项目在 Apache 2.0 许可下开源，由微软研究院、Inria 和社区共同开发。

F* 的一个低级子集 Low* 可以编译为 C，是 Project Everest 高保障安全通信软件项目的基础。基于 F*/Low* 的成果已进入多项生产系统：HACL*/EverCrypt 密码学库被用于 Mozilla Firefox、Linux 内核、Python、mbedTLS、Tezos 区块链、ElectionGuard 电子投票 SDK 和 Wireguard VPN；EverParse 二进制格式解析器生成的 C 代码用于 Windows Hyper-V，Azure 云平台每一个经过的网络包都由它先解析验证，也用于 ebpf-for-windows。学术层面 F* 有一系列 POPL/ICFP/ESOP 论文，涉及依赖类型与多单子效应、Low* 低层验证、Vale 可验证汇编、Meta-F* 元编程系统和 indexed effects 等。

HN 讨论主要集中在两点。首先是官网体验：不少评论者抱怨点了好几页也没看到一段代码示例，认为新语言的主页应该像游戏发布页展示截图那样”把语法直接摆在正中央”，否则难以判断是否值得学。第二个议题是实际使用情况：有人问 F* 是否在工业界被使用、用于什么类型的软件；有实际用户反馈其”允许在渐进迁移已有 C 代码库时调用外部库”的能力很有价值，语言本身”非常扎实”。也有评论指出 F* 更像是”五种不同语言和证明系统的集合”，从未真正搞清结构，并追问其是否像 Lean 那样正确处理减法和 u8 这类基本运算。还有人好奇它是否适合用来实现编译器并对编译器做形式化证明。

6. 开发者依恋工具，是因为工具承载着信任

Stack Overflow 博客的这篇文章从六年前一篇”IDE 已经强大到不该有人还用 Vim/Emacs”的旧文谈起，反思开发者为何对工具有深厚感情。作者引用《The Pragmatic Programmer》的观点：开发者需要”锋利的工具”，像自己手的延伸一样。Vim 和 Emacs 通过无限可定制性契合每个人的手型和工作流；花时间建立熟练度和信任是长期回报。

在 agentic engineering 时代，新工具变成了”用自然语言对话的终端”。Coding agent 缺少开发者写代码时的精确性，但能在极短时间内产出整个应用。Stack Overflow 2025 年开发者调查显示：AI 使用率从 76% 升到 84%，但信任度从 40% 跌到 29%。作者打了个比方：如果厨房里的刀每次都变形、变重、变刃，就很难与它建立信任。AI 工具的能力还在剧烈波动，这不仅是工具问题，也暴露了围绕它的流程缺陷。

文章引用开发者生产力倡导者 Tricia Gee 的话：熟悉的 IDE 让人快，因为”手指知道该怎么做”，那是无意识的胜任感。作者还引用 Bjarne Stroustrup：“代码是对解决方案的精确表述，英语是表达无歧义事物的糟糕语言。“传统工具——linter、单元测试、CI/CD——编码了流程但不是流程本身，而 agentic 工具正在渗透 SDLC 每个环节，让不信任蔓延到整个过程。代码变得几乎免费，新瓶颈是代码评审——老笑话说”想让 PR 快速通过，就改 100 行”，而 coding agent 一瞬间产出几百行 diff。LLM-as-a-judge 是一种可扩展方案，但让 AI 审查 AI 写的代码本身也需要工程投入。

HN 讨论中，最高赞评论把”工具不断变形”的问题追溯到更早的自动更新时代——Windows 因用户拒绝 ME 和 Vista 曾被迫回退，如今工作流被自动更新任意打断已成常态，而 Vim 因界面几十年不变成为例外，也因此值得信任。另一条高赞引用 Joel Spolsky 2000 年那篇讲”控制自己环境让人幸福”的博客，把 AI agent 类比成他年轻时在面包房里那台不可预测的和面机——每次大模型更新或系统提示微调都改变行为，让人不再有掌控感、只剩按按钮碰运气，工程师从工匠变成了不可预测 AI 的经理。也有评论批评文章”用一大堆词说了空话”，是典型的思想领导力文风；并指出 CI 在 agentic 时代该怎么演进这类抽象讨论意义有限，真正需要的是像 gh 新增 repo read-file 子命令这类具体、动手的工具改造。还有教师视角评论提到”人学习速度不同”，新工具产生的速度已经超过自己能学会的速度，这也是依恋既有工具的原因之一。

7. Holocloth：可交互的全息布料网页 demo

Holocloth 是一个部署在 Vercel 上的网页 demo，展示了一块可通过鼠标拖拽交互的”全息布料”。页面主要靠视觉效果说话，呈现出带虹彩/全息反光的织物在三维空间中飘动和被拉扯的动态。

HN 上评论主要是玩家反馈式的赞叹与改进建议，而非技术深挖。多位评论者被视觉效果吸引，称”就是喜欢全息效果，看起来非常漂亮”，并对作者的完成度表示肯定。功能层面反馈集中在几个具体问题：布料似乎缺少自碰撞检测，会与自身穿插；命中检测并非总是选取离摄像机最近的表面——当有折角在主平面前时，拖动往往作用于后面的主体而不是前面的折角，让人无法单独拖起折角；黑色和铬色的表现和预期不符；效果看起来”无摩擦”，触碰后会永远运动下去。有评论者希望支持多点触控，希望在移动端能隐藏菜单，认为整体效果非常出色。也有人反映页面只显示黑屏。有评论者好奇”目前最先进的真实布料/织物渲染 demo”是什么样，以及布上文字的出处。另有一条戏谑评论说布上的高频”噼啪”噪声让人想起 HPPD（幻视持续症）但”我喜欢”。

8. Kakehashi：在 Linux ARM 上运行 macOS 二进制的实验性用户态方案

Kakehashi 是一个用 Rust 编写的实验性用户态翻译层，目标是在 Linux aarch64 上直接运行 macOS ARM64 的命令行二进制。其思路与 Wine/Proton 类似：加载 Darwin Mach-O 可执行文件，映射一个自制的独立版 libSystem，翻译 BSD 系统调用，从而让 Darwin 版本的程序在 Linux 上原生执行，不依赖 JIT，也不做指令仿真。

项目当前在 Docker/Colima 与 UTM 环境中验证了若干真实工作负载：Darwin 版本的 7-Zip（7zz）可以完成多线程压缩、校验和解压；curl 支持 HTTP/HTTPS 下载并通过约 200 条命令与选项测试；Clang 探针、多线程压缩、freestanding libSystem 等均已跑通。项目通过“bottle”目录模拟 Darwin 文件系统布局，并借助 /Volumes/linux/ 桥接到宿主机根目录。作者还提供了 xcode-tools 中 git 基本命令（init/add/commit）的早期原型。

作者在性能上表现得比较克制：在 UTM 裸金属 Ubuntu aarch64 上，多文件 7zz 压缩比原生 Linux 版本慢约 5.2 倍，主要开销来自 syscall 边界的 TLS 切换、备用栈、NEON 保存/恢复以及路径遍历，而非算法差异；对少文件、压缩为主的负载差距会缩小到 1.1–1.2 倍。作者据此指出，即便有 5 倍差距，用便宜的 Linux ARM Runner 跑 Darwin CLI，相较 GitHub Actions macOS Runner 约 10–12 倍的单价差，在 CI 场景中仍具经济价值。当前明确不覆盖的范围包括：Security.framework、代码签名、GUI、完整的 curl 特性集以及 HTTP/3 端到端。

HN 讨论集中在几个方向：多位评论者立即联想到 Darling 项目及其 ARM64 PR，询问是否可能合作或整合；有人关心是否为洁净室实现，尤其在使用 AI 辅助的情况下如何避免代码派生自 Darling；有人提问若允许直接使用真实 macOS rootfs（类似老游戏机 decomp 项目需要原始 ROM）是否会大幅简化实现；也有人期待未来能在 Linux ARM Runner 上构建 iOS App，或在其上运行 AU 音频插件，参考 yabridge 的思路。整体反馈以观望和鼓励为主，共识是方向有价值但工程量巨大，目前仍属早期。

9. Bor v0.8.0：面向 Linux 桌面的开源策略管理系统

Bor 是一款针对 Linux 桌面机群的开源策略管理平台，定位类似于 Windows 世界的 Intune / 组策略。v0.8.0 版本新增了三类策略：Thunderbird、Microsoft Edge for Business 以及 firewalld zone，并对 Web UI 进行了大规模重构，同时完成一轮专门的安全加固。

在策略类型方面，Thunderbird 复用了 Firefox ESR 的机制，由 Agent 合并所有绑定策略后写入 policies.json，并识别 Flatpak、RPM、DEB 三种安装形式；托管文件由 tamper watcher 监控，外部修改会被立即回滚，移除最后一条策略时会恢复原始文件。Edge 通过写入 bor_managed.json 管理，UI 提供含 JSON 校验与预览的树形编辑器。Firewalld 策略可管理 services、ports、rich rules、masquerade、interfaces、zone target 等，写入 /etc/firewalld/zones/ 前会用 firewall-cmd —check-config 校验并热重载。Polkit 规则新增 action.lookup() 变量条件，例如仅允许挂载可移动设备。

管理侧引入了 per-action RBAC，可对用户与角色管理进行细粒度授权。Web UI 迁移到 PatternFly 6，新增真实 URL 路由、全页策略编辑器、未保存改动提醒、销毁性操作的输入确认、服务端分页/过滤/排序，以及符合 WCAG 2.2 AA 的可访问性改造。Firefox、Thunderbird、Chrome、Edge 的策略目录改由 protobuf 注解生成，server/agent/前端共享同一份定义。

安全加固部分包括：Agent 身份严格绑定 mTLS 客户端证书；SHA-256 加密的 TOTP 密钥透明迁移到 HKDF；PPA/COPR 导入阻止基于重定向的 SSRF；审计日志 CSV 导出防止公式注入；初始管理员密码不再写入服务器日志而是落盘至 root-only 文件；TLS 证书 SAN 与主机名不匹配时自动重签。

HN 讨论中，非营利组织管理员表达了对 Linux Mint/Cinnamon 支持、自定义脚本执行和用户映射机制的需求；多人询问选择 mTLS+gRPC 推送而非 SSH 拉取的理由，认为 inotify 监控父目录以捕获漂移的设计干净利落；也有人关心策略冲突的处理策略（多个策略触及同一文件时是队列协调还是 last-write-wins）、无域单机与 LDAP-only 认证的兼容路径、以及是否可扩展到 SCAP / DISA STIG 合规场景。评论者普遍认可其定位克制，不像同类工具那样臃肿。

10. Meshdiff：浏览器端可视化对比 STL 等 3D 模型差异

Meshdiff 是一个纯浏览器端的 3D 模型差异对比工具，支持 STL、3MF、OBJ 格式。作者的动机很实际：客户常反复发来 part_v3_FINAL.stl 之类的文件，却缺乏快速看出改动的方法。用户拖入两个模型后，工具会在浏览器中通过 voxel（体素）方式渲染差异，绿色表示新增材料，红色表示移除材料，并提供 0.05–1mm 的公差调节以及体积变化指标。

技术栈为 React + TypeScript、React Three Fiber 与自研的体素差异引擎；所有计算都在 Web Worker 中运行，文件不上传到任何服务器，隐私友好。作者特别指出没有采用 Manifold 或 CGAL 等库，因为这些库假设 CSG 拓扑干净，而现实中 STL 常常是“三角面片汤”，无法满足前提。

HN 反馈普遍积极。多人提出的最热门功能建议是三个视口的同步旋转/变换锁定，让对比更直观。还有评论者希望能作为 GitHub PR 触发器嵌入，用于 3D 文件的分支间预览；由于工具已是纯客户端实现，社区也期待推出 CLI 版本以便集成到 CI 流程中生成差异快照。有人反馈了具体 bug：多 group 的 OBJ 只显示第一组、同一文件上传两次时应像 meld 那样给出提示。也有用户表示这正是自己在评估各种 3D 模型生成器时需要的工具。评论区还提到相关方向的项目，如 That Open Company 与 Fovea ArchVision，反映出浏览器端 3D 应用（借助 three.js、WASM 等）正在快速增长。

11. RISC OS Open 二十年：一个小众操作系统的开源长跑

RISC OS Open Ltd（ROOL）于 2006 年 6 月 20 日成立，目标是将当时仍为专有软件的 RISC OS 逐步开放给社区共同开发。文章以每年一个里程碑的方式回顾了这段二十年的历程。

早期几年以“共享源代码”方式分批放出源码：2007 年在 Wakefield Show 首次公开源码；2008 年 IYONIX 上运行含大量社区代码的 RISC OS 5；2009 年建立夜间自动构建；2010 年推出 Bounty Scheme，让社区通过众筹投票决定优先开发的功能，这一机制至今仍在运转。2012 年是关键转折：RISC OS Pi 让该系统登陆树莓派，把 BBC BASIC 带给新一代用户，网站流量记录被冲破。此后陆续支持树莓派 2、4 与 Pi 400，并在 2013 年发布多年来首个稳定 ROM 版本 5.20，同时为 BASIC 五十周年推出直接进入提示符的 Pico。

2018 年迎来最重要的目标：Castle 被 RISC OS Developments 收购后，RISC OS 以 Apache 2.0 协议重新授权，历史上首次可以自由商用与再分发。2019 年整个代码库（含约 10.6 万提交历史）迁移到公开 GitLab。近年新增内容包括 EDID 显示器识别、原生 Git 客户端、开源 SparkFS、NVMe SSD 支持，以及 ABC 编译器利用硬件 FPU 让 Mandelbrot 渲染快 35 倍。BBC BASIC 参考手册也重新印刷。

HN 评论中不乏老用户情怀。有开发者回忆自己曾用 ARM 汇编写出流行的 !Director 桌面定制工具，并通过 Arcade BBS 与 Acorn User 杂志随盘发行。另一位提到 Sibelius 记谱软件最初正是在 Acorn Archimedes 上以 RISC OS 为平台起步的。多位评论者感叹 Archimedes 用户群在 1995 年前后就已大幅流失，比 Amiga、ST 阵营小得多，能坚持二十年实属难得。也有人称赞 RISC OS 在树莓派上的启动速度远快于其他系统，并认为像 ReactOS、Haiku 一类未被广告和 AI 所累的操作系统仍有面向定制硬件的小众市场空间。少数批评意见指向官网缺乏系统截图，对图形操作系统而言略显奇怪。

12. 免费可打印的折纸地球仪与行星模板

Folding Paper Globes 是 MapScaping 推出的免费折纸地球仪项目，提供大量可下载、打印并折叠成球体的纸模板，也支持通过在线 globe builder 自定义形状或标注个人地点。模板分为三大类：太阳系（太阳、月球、水金火木、木卫一、木卫二、土卫六、冥王星、谷神星等）；从太空看地球（夜光地球、蓝色弹珠、植被、海洋温度、洋流生物、无水地球、冰雪、云层、降雨、陆地温度、生物群系、人口密度、撒哈拉沙尘与气溶胶）；以及数据地球（近百年大地震、火山、陨石着陆点、世界遗产、板块构造、时区）。所有底图基于 Natural Earth 等开放数据，每个主题页均列出数据来源。

模型采用的是二十面体（icosahedron）网格展开：将球面数据投影后切分成三角面，再拼接为近似球体。这是低成本教学与展示用途中常见的做法。

HN 讨论呈现两条主线。一是几何优化：有人指出如果将二十面体旋转约 14°，同样一张纸可以做出大约 10% 更大的地球仪；也有人推荐用中断正弦投影（interrupted sinusoidal）或球心投影得到边缘更平滑、失真更小的版本，并批评当前采用 Mercator 后再切割拼球等于失真两次。二是替代工具与创作分享：老牌 Photoshop 插件 Flexify 被反复推荐，可将等距柱状行星图变形为四面体、五面体等各种多面体；Python 库 pydymax 可从 360 度全景照片生成 isosphere；另有人分享了自己用 gores（经度长条）而非二十面体拼接的“真彩色+云层”地球尝试，指出真彩色地球本身没有权威参考，不同卫星的色彩定标差异明显。相当多评论者共同呼吁网站补充组装后的成品照片，因为纯展开图难以想象最终效果。另有家长希望增加带国家和首都的政区版本。

13. 用 C 与 SDL2 编写的 Fasttracker II 克隆

开发者 8bitbubsy 用 C 和 SDL2 编写了一款便携的 Fasttracker II 克隆，力图在现代操作系统上还原 1990 年代这款经典音轨编辑器（tracker）的完整体验。项目提供 Windows 64/32 位、macOS 通用二进制（Intel 与 Apple Silicon）以及 Linux 发行版打包，源码托管在 GitHub。作者详细列出了跨平台使用中的注意事项，例如 Windows 上若安装了 GeForce Experience 需禁用其占用的 ALT+F4/F5 快捷键，以免与 FT2 的复制/粘贴块冲突；macOS 上多个关键快捷键需在系统层重新映射；Linux 上同样需要处理 ALT+F4/F5 的键位冲突；多显示器且刷新率不同的环境可能出现异常。最新版本 v2.22 于 2026 年 7 月发布。

HN 评论区呈现出浓厚的怀旧氛围。有用户回忆当年通过 PC Format 杂志随刊 CD 首次接触 FT2 和数百个 module，从而理解自己听到的欧洲电子舞曲是如何一个音符一个采样地被构造出来，进而开启一生的电子音乐制作兴趣。也有开发者展示了自己多年前用 SDL 写的 Impulse Tracker 风格 MIDI 编辑器 zTrackerPrime，并期待 Ableton Live 即将开放的扩展 API 让 tracker 风格界面能直接接入现代 DAW。另一位则介绍了将该 FT2 克隆封装为 VST 插件的衍生项目，可直接嵌入宿主。

技术层面，多人追问为何选择 SDL2 而非已发布约一年半的 SDL3，作者未在原文中说明。评论中还提到与 ScreamTracker、MilkyTracker、ProTracker 的关系：有人怀念 ScreamTracker 通过并口加几只电阻（Covox Speech Thing 的 DIY 版本）就能在任意音箱上出声的年代；作者本人还维护着 ProTracker 克隆以及一份修复 bug 的 Amiga ProTracker，可用于创作能在真实 Amiga 硬件上回放的音乐。仓库中还内置了小彩蛋——一款贪吃蛇小游戏。此外有人借机感叹，如今游戏配乐普遍是好莱坞式伪管弦，缺乏当年 tracker 音乐和 chiptune 那种鲜明记忆点。

14. Ars Notoria：中世纪版“瞬间掌握知识”的魔法手稿

Public Domain Review 的这篇长文由 Anne Lawrence-Mathers 撰写，介绍了一部在十三世纪之后流传于欧洲的匿名手稿 Ars notoria（“记号之术”）。它以复杂的图示、祷文和仪式承诺让学者在极短时间内掌握中世纪大学教授的全部学科知识——被作者比作 Neo 在《黑客帝国》中瞬间学会功夫的中世纪版本。目前尚存 56 份中世纪抄本，另有近代早期的印刷版本，说明这种“知识捷径”的诱惑跨越了数百年。

Ars notoria 的核心是其图示。与其他魔法文献不同，这些图示并非用于说明文本，也不是要被制成三维法器，而是被当作类似圣像的存在：忠实持有并凝视这些几何符号、字母与难以发音的“词”，同时诵读繁复的祷文，据信能与天使乃至上帝直接沟通。文本自称这些词汇来自希腊语、希伯来语与“迦勒底语”，是与天使沟通的语言，并托名所罗门王所受启示。这使它区别于典型的“违逆教会”的魔法：其外壳极为虔诚。

然而神学界并不买账。托马斯·阿奎那在《神学大全》第二部分第 96 题专门谴责 Ars notoria，认为它既无效（无法真正传授知识）又非法：这些“符号”既不是人类可理解的普通语言，也不是上帝设立的圣事，因此正是圣奥古斯丁警告的、可能诱人与魔鬼订立契约的迷信之物。尽管遭到明确谴责，宗教机构仍在整个中世纪持续抄录和保存该书。现存最早的抄本藏于耶鲁大学图书馆，据推测出自博洛尼亚大学环境，可能是为大学讲师所备——因为正确使用这些复杂而含混的仪式，本身就需要高度的学术训练。

HN 评论围绕几个角度。有人推测 Ars notoria 之所以能长期流行，是因为它宣称提升的“雄辩术”“辩证法”等中世纪科目本身模糊主观，安慰剂效应足以让使用者“感到”有所进步；而若拿到今天的量子力学或 CS 学位课程上，虚假很快会暴露。有评论联想到 Voynich 手稿，猜测其目的可能类似——不是承载真实知识，而是让持有者相信自己被赋予了某种高阶秘传。有人从中读出对“注意力被劫持”的隐喻：真正“恶魔”的地方在于它把本可用于真正学习的精力，导向对不可解符号的仪式化练习，并进一步类比当下人们把时间花在“vibe”式内容消费上。也有人指出标题中的“Artificial Intelligence”较为标题党，但内容仍值得一读。另有评论顺带科普“Chaldean 语”其实是对圣经阿拉姆语的历史性误称。

15. 欧盟年龄验证方案强制硬件绑定证明引发争议

欧盟数字身份钱包项目（EU Digital Identity Wallet）下的开源年龄验证应用，其维护者在 GitHub 上确认「硬件绑定证明（hardware-bound attestation）」是该架构的强制性要求，而非可选实现细节。这意味着密钥必须存储在受保护的硬件中，如 Android TEE、StrongBox 或 Apple Secure Enclave，以防止凭证被复制、克隆或被修改过的客户端重用。项目方表示将发布专门的安全审查与威胁模型，并欢迎替代架构方案。

技术上，方案的目标是让用户在不暴露姓名、确切出生日期或完整身份证件的前提下证明其达到某年龄。然而批评者指出，这种设计使系统依赖于少数「被认可」的设备、操作系统和证明提供方。参考实现中虽未强制要求 root 检测、Google Play Integrity 或 Apple App Attest，但具体部署方可自行加严。此外，Proof of Age 凭证发放方只会为欧盟委员会维护的「合规应用清单」中的应用签发凭证——即使源代码公开，社区自行编译的版本也未必能接入真实服务。Linux 桌面并未被明文禁止，但没有原生钱包，用户需借助已支持的手机扫描二维码；替代移动操作系统（如 GrapheneOS）也难以满足信任条件。

HN 讨论集中在几个方向。有评论认为这暴露了年龄验证的真实目的：把线上活动与强身份标识绑定，先渗透移动端，再扩展到桌面。多人指出这本质上是反竞争问题——政府强制公民必须持有 Google 或 Apple 账号才能参与社会活动。一位技术评论者详细指出硬件证明并不使用零知识证明或盲签名，硬件 ID 在流程中会以证书形式暴露，若 Google/Apple 中介与验证方合谋，甚至加上厂商记录出厂证书与订单的对应关系，就可能实现跨账号乃至跨购买身份的关联，且移动端 API 无法关闭此功能。也有人认为「硬件绑定」本身并不是问题，问题在于绑定范围被限缩到 iPhone 和部分 Android 设备，而不承认其他能安全保管密钥的硬件。还有评论担忧灰色市场 TPM 密钥交易将随之出现。

16. Rust All Hands 2026 回顾：治理、语言演进与互操作成焦点

2026 年 5 月，166 名 Rust 项目成员和受邀嘉宾在荷兰乌得勒支举行 Rust All Hands，这是由 RustNL 组织的第二届恢复传统后的现场协作活动，作为 RustWeek 的一部分举办。与之同场的 RustWeek Unconference 汇集了 Bevy、Ariel OS、Linebender、Safety-Critical Rust Consortium、Rust GPU 和 Rust Embedded 六个生态团队共约 60 位维护者。三天内在 11 个房间开展了 73 场议题讨论，但会议本身不作最终决议。

治理相关议题占据显著比重：Leadership Council 与 Project Directors 的 Q&A、Moderation panel（由 Hachyderm 首席版主 Q 支持）、Project 文化讨论（探讨维护者被削弱话语权的根源）、Project Goals 与 north stars、资金问题，以及借鉴 TC39 流程改进 RFC 机制的探讨。语言演进层面覆盖 const generics、const traits、field projections、reborrowing、in-place initialization、SIMD、allocators、custom lints、库的稳定性属性、rustc as a library、Sized Hierarchy、auto traits，以及大量编译器内部、代码生成、语义、规范、工具链话题。互操作性是另一大主题：Rust/C++ 整体互操作、Crubit 现状、通过结合 LLVM IR 与 Rust MIR 实现更安全的互操作，以及与 Rust for Linux 和 Rust for CPython 的现场协作。参会者平均打分 9.5/10。

HN 讨论较为分散。有评论以「唱反调」视角审视 Unconference 参与组，认为 Rust GPU 相比 Cudarc、WGPU、Nvidia 官方 Cuda-Oxide 是可行性最低的选择，而嵌入式方向由于 Cargo、probe-rs、defmt 等工具链已经非常强，Rust 表现出色。有人对 Rust 的未来做了两极预测：可能因内建的强约束成为 AI 编码代理的首选语言，也可能因编译速度在 LLM 时代成为迭代瓶颈而边缘化。也有开发者抱怨多线程前端存在崩溃问题、拒绝 AI 生成 PR 导致某些问题长期无人修复。对「匿名版主小组」在项目文化中的角色，有评论表达了不安。

17. Fuse：一门编译到 GRIN 的静态类型纯函数式语言

Fuse 是一门静态类型、纯函数式编程语言，支持高阶类型（HKT）和 ad-hoc 多态，编译到 GRIN 全程序优化器，再经 LLVM 生成原生代码。类型系统基于 System F，具备代数数据类型、泛型和 trait；采用双向类型检查，仅要求函数签名带注解，其余类型可推导。语法借鉴 Rust、Python、Scala 和 Haskell，采用缩进块、lambda 表达式和 ML 风格语法，并提供模式匹配、高阶函数和 do 记号。示例代码展示了 Functor trait 及其在 List 上的实现，以及 fmap 泛函数写法。工具链已可在 Linux x86_64 和 macOS ARM64 上安装。

HN 讨论氛围相当正面。多位评论者对能看到一个真实运作的 GRIN 后端表示兴奋，指出 GRIN 涉及部分超编译（supercompilation）技术，理论上可用于证明函数式程序的等价性。有人提出细节疑问：标准库中的字符串类型未做 Unicode 感知，未来添加会影响库设计；语言标榜纯函数式却提供 IO monad，但由于 .exec() 允许任意函数执行 IO，IO 的作用不明；trait 中 HKT 的写法（如 Self[B]）在遇到不依赖类型参数的关联项时如何表达仍有疑问，如何区分 List[A]::Size 与 List[B]::Size；impl 是否自动导出、多个库为同一类型添加同名函数会发生什么、是否支持自动柯里化等。还有人建议提供客观指标：编译速度、运行时性能对比、与 Rust/Scala/Haskell 等价程序的代码长度对比，以及展示 Fuse 编译器能捕获而其他语言遗漏的 bug。语法层面，有评论质疑用 [] 表示类型参数偏离主流 <> 的选择，也有人指出「Fuse」名称与已知的 fusefs 存在混淆风险。项目仓库中已出现 tree-sitter-fuse，有人期待 LSP 等编辑器支持跟进。

18. 用「画一只有哈布斯堡下颌的青蛙 SVG」作为 AI 基准测试

作者建立了一个个人 AI 基准测试站点 FROGS_，对多个大模型使用同一提示词：「Generate an SVG of a frog with a Habsburg jaw.」（生成一只带有哈布斯堡下颌的青蛙 SVG）。每个模型每月获得三次尝试机会。2026 年 8 月的一期覆盖 14 个模型，共 42 次运行，全部成功产出 SVG。站点展示每个模型生成的 SVG 图像、原始代码、耗时和字节数，并附上作者对模型注释风格的点评——例如 Claude Opus 5 在结构性标签之外，还加入了「巨大突出的下颌」「上唇内缩、藏在下颌后方」「下齿突出于上唇之上」等对解剖学的解释性描述，显示模型对「哈布斯堡下颌」这一历史特征有一定语义理解。

该提示的巧妙之处在于同时考察模型的图形生成能力、SVG 语法掌握、对冷门历史概念（哈布斯堡王朝因近亲繁殖导致的下颌前突症）的理解，以及将两者组合到同一图像中的能力。

HN 讨论围绕结果展开。多数人认为 Opus 5 是唯一接近「通过」测试的模型，评价大致是 Opus 5 > Kimi K3 > Grok 4.5。许多失败案例中模型能画出还算像样的青蛙脸，也知道哈布斯堡下颌意味着「突出的下巴」，但两者未能自然融合到同一张脸上。有人指出 Gemini 2.5 Pro 虽然失败，但呈现出独特的艺术风格且理解阴影层次；Gemini 3.6-flash 在第 2、3 次尝试中较好回应了「王室肖像」的语境暗示。作者本人在评论区回应说站点被 HN 流量压垮，正在提高稳定性。也有评论提醒：优秀的评测题一旦公开曝光就会失去价值，因为可能被纳入未来的训练数据。还有人建议提供人类画师的对照图，以及讨论 LLM 究竟以何种方式「推理」SVG——是像文本 token 一样逐段生成，还是有类似 GAN 的机制。

19. 关于笔记与个人知识管理（PKM）的一次反驳

作者针对 Brennan Kenneth Brown 的文章《What have note-taking PKMs accomplished, really?》撰写了详尽回应。Brennan 的核心质疑是：Obsidian 面世六年，是否带来了「面向公众的理解与知识」的可观增长？作者认为这一问题的框架本身就有问题——用单一软件对世界的「贡献」来衡量其价值是荒谬的。Emacs 与 vim 存在数十年，也无法说它们本身贡献了知识，但它们让人们写出了代码、论文、书籍。工具不做贡献，工具让人得以做贡献。

作者进一步指出 Brennan 对 Obsidian 官方立场的引用存在误读：官方文档并未使用「data privacy」「portability」「future-proofing」这些词，也没有把 Obsidian 塑造为具有「higher-brow」的认识论价值的产品；相反，官方明确表示「笔记是高度个人化的活动，没有一体适用的方案」，Obsidian 只提供一个基础和积木让用户搭建自己的系统。作者认为 Brennan 混淆了 Obsidian 本身和围绕它形成的（有时令人反感的）社区生态，也把 Obsidian 与 PARA、Zettelkasten、Johnny Decimal、GTD、Commonplace Book 等具体 PKM 框架混为一谈。对 Brennan 提出的四个衡量问题——什么算重要贡献、PKM 是否被顶尖学者所用、真实写作者的流程是什么样、PKM 拥趸的产出如何——作者逐一质疑其内在假设。

HN 讨论延伸出多条思路。有人拿出 Henry Ford 的「jot books」举例，说明有成就的人几乎都以某种形式做笔记，写作是思考方式，但工具本身不能被神话；就像好相机不能造就好摄影师一样。另有开发者坦言，自己搭建繁复笔记系统的倾向其实是对学习焦虑的应对——通过 Anki 卡片和 Obsidian 链接网获得掌控感，但过度外化知识反而削弱了对自身内在能力的信心。多位评论者指出关于「笔记」的讨论常常混淆三种不同用途：便于事后检索、辅助学习、以及为向他人分享或创作而写，三者的最优策略完全不同。也有人回归纸笔手写，或表示 AI 记忆系统已经取代了他们的 PKM。

20. Cyber：一门主打脚本用途、内嵌 JIT 的新语言

Cyber（cyberscript.dev）是一门定位为「快速且愉悦的脚本语言」的新语言，特性包括：易学、动态类型与可选静态类型并存、基于 fiber 的并发、内存安全、支持 FFI 与嵌入、带 JIT 的快速 VM、跨平台。示例代码展示了字符串插值、循环、可选的静态函数签名，以及 coinit/coresume/coyield 风格的协程。语言用 Zig 实现，libcyber 允许作为库嵌入应用；FFI API 支持任何 C ABI 兼容库，附带的 cbindgen.cy 可从 C 头文件自动生成绑定，已有 Raylib 和 LLVM 的示例绑定。

性能页面展示了递归 Fibonacci 基准：VM 模式下 Cyber 用时约 19ms，与 LuaJIT（21ms）接近，好于 wasm3、luau、lua、quickjs、wren、python3、ruby、node 等；JIT 模式下 Cyber 与 LuaJIT 均为 5ms 一档。

HN 讨论以质疑为主。多位评论者观察到项目仓库最近一次发布在 2023 年，最新提交也在 8 个月前，看起来接近停滞。有人认为在当下开发新编程语言（除爱好项目外）已基本走到尽头：主流用途已被覆盖，工业界更倾向选择久经考验、生态庞大的语言，而且随着越来越多代码由 AI 读写，语言人体工学的重要性在下降。有评论指出「Cyber」这一命名在开放互联网上极难搜索，是新语言常见的营销失误。技术层面，有人认为 Cyber 与其硬拼不如直接用 Lua+LuaJIT；也有人担心新语言默认字符串使用 UTF-8 会给 HTTP 头等场景带来解析漏洞。基准页面本身也被质疑：灰色和橙色柱含义未说明、可能把启动时间不成比例地计入某些语言、其他语言的测量脚本未公开，可比性存疑。也有人希望看到与现有游戏引擎的集成示例，因为脚本语言的典型用途之一就是游戏脚本。