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

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

本期主线指向同一个临界点：算力与模型能力正在重写技术劳动的边界——Bun 用六天和 LLM 完成 Rust 重写、ChatGPT 一小时产出博士级数学论证；与此同时，平台权力也在收紧，AWS 的计费与封号惯性、苹果谷歌借硬件认证排挤 GrapheneOS。

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

共 20 篇 · 约 12,672 字 · 约 32 分钟读完

1. Bun 的 Rust 重写实验在 Linux x64 上达到 99.8% 测试通过率

Bun 创始人 Jarred Sumner 在社交媒体宣布，Bun 运行时的 Rust 重写分支在 Linux x64 glibc 平台上已通过 99.8% 的现有测试套件。该重写从启动到达到这一进展仅用约六天时间，被普遍认为大量借助了 LLM（据评论指向 Anthropic 的 Claude/Mythos）完成代码迁移。Sumner 此前在另一条评论中强调，这只是一个探索性分支，团队尚未承诺正式从 Zig 切换到 Rust，目的是对比 Rust 与 Zig 两种实现的性能、可维护性与开发体验，最终代码完全有可能被废弃。

HN 讨论分为几条主线。第一是对 LLM 大规模代码迁移可行性的震惊：有正在用 LLM 把 TypeScript 移植到 Rust 的开发者表示自己花了 5 个月才达到 99.6% 通过率，认为 Bun 的速度反映出算力（tokens）将成为竞争壁垒——拥有更多计算资源的团队能做到别人做不到的事。多位评论者指出，能在六天内完成这种规模的迁移，前提是 Bun 早已建立了极其完善的测试套件，否则 LLM 的产出无从验证。第二是技术路线之争：不少人认为 Bun 长期以来因 Zig 中大量 unsafe 风格代码而饱受崩溃和内存 bug 困扰，转向 Rust（即便仍含 unsafe）有望改善稳定性，与 Deno 选择 Rust 的路线趋同。一位 Zig 全职开发者也表示这是「双赢」，认为 Bun 的编码风格与 Zig 哲学本就不匹配，分手对双方都好。第三是对 Zig 生态的担忧：Bun 此前是许多人接触 Zig 的入口，并曾 fork Zig 以适配 LLM 重写需求（如非确定性编译），如今转向 Rust 可能削弱 Zig 的可见度。也有较为负面的声音，认为 Bun 的决策更像市场政治而非技术理性，担心其在 Anthropic 的「庇护」下逐步偏离工程严谨性。还有评论将话题引向行业宏观变化，认为「英语正在成为编程语言」，规范、上下文与 TDD 构成新的开发框架，对就业市场的冲击同样令人不安。

2. 陶哲轩同行 Gowers 记录 ChatGPT 5.5 Pro 一小时完成博士级数学研究

菲尔兹奖得主 Timothy Gowers 在博客中描述了一次令他大幅上调对 LLM 数学能力评估的经历。他选用了 Mel Nathanson 在加性数论论文《Diversity, Equity and Inclusion for Problems in Additive Number Theory》中提出的若干公开问题——这类论文通常包含许多作者无暇深究的子问题，传统上是初入研究的学生练手的良好素材。Gowers 让 ChatGPT 5.5 Pro 处理其中关于 h 重和集 hA 的尺寸与所需直径关系的问题。在他几乎未提供数学输入的情况下，模型在大约一小时内产出了一段达到博士研究水准的论证。

Gowers 由此引出更广泛的反思：此前 LLM 在 Erdős 问题上的「解题」常被视作只是从文献中检索或做简单推论，但门槛正在被持续抬高。他指出，给新晋博士生「相对温和的入门题」这一传统训练方式正变得困难——若 LLM 已能解决这类温和问题，研究的下限就被迫提升为「证明 LLM 也证不出的东西」。文章还讨论了一个思想实验：若数学家主要扮演引导者、由 LLM 完成核心论证与关键想法，这是否仍算数学家的成就？Gowers 倾向于否定，但承认这是文化选择。

HN 讨论中，有用户证实 5.5 Pro 是首个能被「驯服」去稳定完成繁琐但路径清晰任务的模型，缺点是 token 消耗与成本极高，且大问题需要不断重建上下文。一位物理学教授分享自己用 Gemini 校阅论文的经验：模型能找出他几天没发现的笔误（如复数表达式中缺失的虚数单位），但在 3D Clifford 代数等概念上反复混淆双向量与赝标量的指数，仍需领域专家把关，更像「读书极快但需大量指导的学生」。John Baez 的评论被广泛引用：数学价值若来自稀缺性，自动化将令其贬值；若来自实用性，则更多好想法反而更好——数学界或许需要从稀缺经济转向丰裕经济。也有研究生坦言这让他对「作品超越自身有限生命」的「不朽」念想感到失落。

3. 一位老用户重返 AWS 后再次确认了离开的理由

作者自述是 AWS 最早的布道者之一，曾在墨尔本组织首场 AWS 活动，整整十五年深度信仰云计算。但关系是逐渐破裂的：他列出了一系列累积的不满——AWS 头六年不提供官方客户端库、长期不迁移到 Python 3、DynamoDB 体验糟糕且账单意外昂贵、出口流量定价高达 9 美分/GB、计费极其复杂且充满双重计费陷阱、IAM 权限系统过度复杂、Lambda 带来严重供应商锁定且实际收益有限，以及 AWS 对 Elasticsearch、Redis、MongoDB 等开源项目以 OpenSearch、Valkey、DocumentDB 形式「掠夺式」分叉，迫使社区转向 SSPL 等防御性许可证。

他几年前已迁出大部分服务，仅保留 Route53 域名、少量 S3 备份与 WorkMail。最近为测试 Bedrock 上的 Claude 与基准测试 192 核 EC2 spot 实例而短暂回归。运行三小时后，AWS 因「疑似账户安全异常」自动限制了其账户——休眠账号突然消费高额算力触发了风控。结果 WorkMail 业务邮箱无法发信，无法创建任何资源；非高级支持的工单 24 小时承诺逾期至三天未回，论坛求助后通过 chat 才得到处理，但账户仍未完全恢复。

HN 讨论补充了多个角度。有人爆料 AWS 所谓「免费数据迁出」实际上要先等一个月才回复初始请求，再填长表回答离开原因，批准后还要再等 60 天才能开始，整体被锁三到四个月。有人反驳关于开源分叉的指控顺序：OpenSearch 与 Valkey 都是在上游修改许可证之后才出现的。也有声音认为这类抱怨忽视了目标用户——AWS 不是为简单 CRUD 站点设计的，IAM 的复杂源于「用户、组、角色、策略、身份提供方、OIDC」本身的复杂性，没有真正简单的实现。还有从业者分享自托管与多云轻量使用的策略：只用各云通用的 Ubuntu VM 和对象存储以保留迁移自由，但抱怨 AWS 的 CPU 性能、EBS 速度与 VM 启动速度都明显偏慢，性价比正在恶化。也有人为 DynamoDB 辩护，认为只要前期认真设计数据模型，可用性与运维负担都极佳。

4. GrapheneOS：硬件认证正在成为巩固垄断的工具

GrapheneOS 团队在长串帖子中系统阐述了对硬件认证（hardware attestation）扩张趋势的批评。Apple 的 App Attest 与 Google 的 Play Integrity API 在结构上高度相似，并正通过 Apple 的 Privacy Pass、Google 计划中的类似机制以及新推出的 reCAPTCHA Mobile Verification 向 Web 与桌面操作系统蔓延。Play Integrity 的 strong 等级已强制硬件认证，device 等级也在逐步收紧。其结果是：要使用越来越多的银行、政府与商业服务，用户必须持有 Apple 或 Google 认证的设备与系统。

GrapheneOS 指出，这套体系以「安全」为名，实质是反竞争锁定。Play Integrity 允许 10 年未打补丁的设备通过，却拒绝比官方系统更安全的 GrapheneOS——原因不是技术安全，而是 GrapheneOS 未签署 GMS 授权、未遵守已在韩国等地被裁定违法的捆绑条款（如强制 Chrome 等）。reCAPTCHA Mobile Verification 进一步把硬件认证延伸到 Windows、Linux、OpenBSD 等平台：在某些场景下需用经认证的智能手机扫描二维码才能通过验证，意味着 Google 凭借 reCAPTCHA 的市场地位，可以变相要求人们持有 iOS 或认证 Android 才能访问大量网站。欧盟在数字身份、支付、年龄验证等领域的政策正主动要求 App Attest/Play Integrity，等于政府亲自参与封锁竞争。GrapheneOS 同时批评 Volla 推动的 Unified Attestation 试图建立另一个集中式授权机构，比 Android 现有相对开放的认证 API 更糟。

HN 讨论中，有人指出 EU Digital Identity Wallet (EUDI) 实际上把欧洲数字身份绑定到美国双寡头的认证体系，所谓数字主权名存实亡。有安全研究者分享通过对 DRAM 数据线进行物理位翻转（针刺/EMFI 手法）可在多数设备上绕过 Play Integrity 的强等级，因为认证只验证启动时内核状态，运行时改动不会被发现，但这只是「越狱」式临时手段。还有评论强调真正的隐私问题在于 attestation 包并未采用零知识证明或盲签名，意味着每次认证都留下可关联到具体设备的痕迹。多位评论者将此与 1999 年 Intel CPU 序列号风波、TPM、Windows 11 的 TPM 要求联系起来，认为「以安全为名牺牲自由」的趋势不断推进，反映出对通用计算的长期围剿，并呼吁立法禁止 SoC 内置不可修改的初始 bootloader，或至少保留维修店级别的事后修改能力。

5. 互联网档案馆在瑞士设立独立分支

Internet Archive 宣布在瑞士圣加仑（St. Gallen）成立独立非营利基金会 Internet Archive Switzerland（internetarchive.ch），加入此前已存在的 Internet Archive Canada 与 Internet Archive Europe，共同构成一个分布式、独立运营但使命一致的数字图书馆网络。新机构初期将聚焦两件事：保护全球处于濒危状态的档案，以及收藏当下生成式 AI 浪潮的产物。后者通过与圣加仑大学计算机科学学院 Damian Borth 教授主持的 Gen AI Archive 项目合作展开，目标是开始系统性地存档 AI 模型本身。圣加仑被选为基地，因其拥有千年修道院图书馆传承与浓厚学术氛围。一场 UNESCO 关于濒危档案的会议计划于 2026 年 11 月在巴黎召开。

HN 讨论的核心关切是治理与抗审查能力。多位评论者认为 IA 应借鉴 Usenet 的拓扑：建立一组所有权分散、地理分布、相互对等同步内容但缺乏跨节点 DMCA 通道的姊妹组织，使得删除内容比上传内容更难，从而抵御日益增长的政治与法律压力。曾在 Internet Archive Canada 工作过的评论者指出，加拿大分支虽名义独立，实际共用 Slack 和 archive.org 邮箱，运作更像子公司；瑞士新机构董事会包含 Brewster Kahle 与 Caslon，独立程度仍待观察，但在当前美国政治环境下，各分支真正独立运作（尤其在资金上）变得愈发关键。

不少评论者吐槽新站点本身打不开或加载极慢，调侃「不如去 archive.org 上的镜像看」。也有人指出新站「关于我们」与联系页面充斥模板占位文本（如「123 Fifth Avenue, NY」、「每只援手都能养育一个孩子」之类），疑似直接套用通用 NGO 模板，且站上几乎找不到实际归档内容，仅有少量 AI 相关链接，认为运营仓促。还有人质疑「收藏生成式 AI 浪潮」的意义何在，但更多人欢迎在美国之外建立独立备份。也有评论提到圣加仑修道院图书馆本身值得参观，将物理与数字档案传统并置。

6. Louis Rossmann 出资为受 Bambu Lab 法律威胁的 OrcaSlicer 开发者支付律师费

3D 打印机厂商 Bambu Lab 对一名社区开发者发出法律威胁，起因据报道是某个 OrcaSlicer 分支直接调用了 Bambu 的非公开云 API，模拟 Bambu Studio 客户端行为；Bambu 称其云服务因此每天收到约 3000 万次「未授权」请求。维修权倡导者、YouTuber Louis Rossmann 公开抨击 Bambu 的诉讼行为，并表示愿意为这位被威胁的开发者承担法律费用。

HN 讨论显示用户对 Bambu 的不满已积累许久。去年 Bambu 曾试图彻底取消离线访问，迫于舆论才回退；不少 X1C 车主表示自己已将打印机离线运行、固件停留旧版、隔离在专门的 Wi-Fi 网络中，并开始考虑转向 Prusa 等更尊重用户的品牌，尽管 Prusa 自身也在变得不那么开放。也有人指出 Bambu 曾在中国试图为多项业内广泛使用的技术申请专利。讨论中亦有理性声音区分本案性质：OrcaSlicer 主线本就支持 Bambu 打印机，本次纠纷涉及的分支据说是冒充官方客户端调用私有云 API，而非简单的本地直连，这与「右修权」议题并不完全等同，但 Bambu 选择诉讼而非技术封堵的做法仍引发广泛反感。

讨论中也涌现替代品比较。Prusa MK3/MK3S 用户抱怨可靠性问题与较高价格，转用 Flashforge Adventurer 5M 后发现自动校准稳定、价格便宜到「坏了直接换新」也无心理负担，但其附带切片软件较差。也有人推荐 Prusa Core One，但批评其仍依赖 3D 打印部件、价格偏高、AMS 系统不如 Bambu 成熟，认为目前在性价比上仍无品牌能正面挑战 Bambu。许多人对此感到矛盾：Bambu 是迄今最易上手的 3D 打印入门方案，但其商业模式实际上是「以补贴价租赁」，用户并不真正拥有自己的设备。Rossmann 被普遍视为虽不总是判断准确、但难得真诚且愿意为弱势个人出钱出力的倡导者。

7. 本地 AI 应该成为常态

作者批评当前软件开发的一种惯性：动辄给应用接入 OpenAI 或 Anthropic 的云端 API 以增加「AI 功能」。他认为这种做法让软件变得脆弱、侵犯隐私、依赖外部计费与网络状况，把本可以是一个本地特性的功能变成了一个「需要花钱维护的分布式系统」。手机里的 Neural Engine 大量闲置，却让用户等待来自弗吉尼亚机房的 JSON 响应，这并不合理。

作者以自己开发的 iOS 客户端 Brutalist Report 为例，展示如何用 Apple 的 FoundationModels 框架在设备本地完成新闻摘要：通过 SystemLanguageModel 与 LanguageModelSession 调用本地模型，对长文本分块产出「事实型」笔记再合并。更值得关注的是 Apple 推动的「类型化输出」模式——使用 @Generable 标注的 Swift struct 与 @Guide 字段描述，让模型直接生成强类型实例，而非让应用解析不可靠的 JSON 或 Markdown。作者认为本地模型并不需要博士级智能，只要能稳定完成总结、分类、抽取、改写、归一化这类「数据变换」任务即可，而这正是它们的强项。隐私承诺的最佳形式不是 2000 字的隐私政策，而是根本不需要这份政策。

HN 讨论延伸出几条主线。一种乐观看法认为本地 AI 的拐点已不远：从大型数据中心，到几张 H100，再到 128GB 显存的 MacBook Pro 或 Strix Halo，未来一年内「云端规划 + 本地执行」会成为企业新常态，并最终演进为「本地搞定一切」。也有人指出当前对 Anthropic、OpenAI 的依赖（尤其是编程场景）极度危险，开放权重模型的存续很大程度上依赖中国实验室的地缘博弈，随时可能中断。Chrome 内置本地 LLM（占用数 GB 空间）引发的反对声音被拿来对比，说明社区在「本地 vs 云端」上的态度并不一致。

反方意见同样强烈。有人认为开发者选择云 API 不是懒惰而是为用户着想——前沿云模型在能力上明显领先，多数用户不会接受次优体验，HN 把所有用户当作「自托管 Linux 隐私狂人」是脱离现实的。也有人主张应将「本地 AI」与「私有 AI」分开讨论：真正需要的是易部署、有租户隔离保证的自托管推理方案（类似「AI 版 Plex」），而非强求模型必须跑在终端设备上。还有评论者展示了 Chrome 新 Prompt API 在受限场景下处理用户自有数据时的实用性，呼应了原文「本地 AI 适合数据变换、不适合做世界知识引擎」的核心判断。

8. 用 ARM64 汇编手写 macOS Web 服务器

作者发布了名为 ymawky 的项目：一个完全用 ARM64 汇编手写、面向 macOS Apple Silicon 的静态文件 Web 服务器。它不依赖 libc，仅通过系统调用工作，采用每连接 fork 一个进程的经典模型。功能涵盖 GET/PUT/DELETE/OPTIONS/HEAD 五种 HTTP 方法，支持 Range 请求（视频拖动可用）、MIME 类型识别、自定义错误页、目录列表、% 十六进制解码、HTTP/1.0 与 1.1 解析，以及对 PUT 上传（最大 1GiB）做原子写入与并发安全处理。

在安全方面，作者实现了路径长度限制、路径穿越检测（能区分 .. 与文件名中合法的多个点）、符号链接拒绝、慢速连接 10 秒超时（基础 Slowloris 防护）、临时文件命名隔离等措施，并坦言项目仅运行在 127.0.0.1 上、可能仍存在未知漏洞。代码组织上还附带了仿 O’Reilly 风格的封面图，被评论区称为点睛之笔。

HN 讨论分为几条主线。一类评论指出，真正用汇编写大型程序时会发现，借助宏和过程抽象后它与高级语言并非本质不同，反而是阅读汇编往往比写更难。另一类则把这种项目类比为 Minecraft 中手工搭建的小地图——在 AI 大规模生成代码的时代，手工打磨出的作品有不可替代的艺术价值，多位评论者表达了类似的”温暖感”和向往。也有人分享了类似的玩具项目，例如 x86 Linux 下的 asmhttpd，以及 RISC-V 上的尝试。

技术层面，有评论提醒 macOS 的系统调用号并不保证稳定，Go 在 1.12 就因此切换为通过 libSystem.dylib 调用，稳定的裸 syscall 实际只是 Linux 的传统，其他系统通常要求经由官方动态库。还有评论好奇与成熟 Web 服务器在 RPS 上的性能对比，虽然作者本人和评论者都承认这种比较意义有限。418 “I’m a teapot” 状态码的实现也被反复提到，被视为这种纯粹爱好项目精神的缩影。

9. Ask HN：2026 年 5 月你在做什么项目

这是 HN 的月度”你在做什么”系列帖，吸引了数百条来自独立开发者、研究者和爱好者的项目分享，呈现出当前个人项目生态的一个横切面。

Web 与 SaaS 类项目仍占多数。thingstohave.app 的作者讲述了从 SvelteKit 迁移到 Hono + Inertia + Vue 的经验，认为 Inertia 是”两全其美”的方案——后端按 MVC 写，前端用现代 JS 框架做模板，并写了自定义 Hono 适配器；巧合的是 Hono 作者随后也发布了官方模块。authproxy 是一个开源 iPaaS 鉴权代理，把第三方 OAuth、token 刷新、审计等繁琐工作从主应用中剥离出来。Drawers 则是一款 macOS 应用，为每个项目提供独立的 dock 和 space，连 Slack 频道这种细粒度资源都能直接放进 dock。

数据与算法方向，foryou.club 是 Bluesky 的协同过滤推荐 feed，基于点赞数据找出兴趣相近用户的最近喜好，已成为该平台被点赞最多的 feed。一位天体力学研究者分享了做了四年的小行星/彗星轨道项目，最近用 AI 工具”vibe coding”出一个可视化 demo（ketev）。

也有不少”反 AI 潮流”的硬核作品。一位写了 20 多年杠铃训练的开发者基于新一代 IMU 硬件做杠铃速度与轨迹追踪传感器，比相机或电机方案更精确便宜。Float-explorer 用于生成精确的汇编程序，深入探究处理器浮点行为的暗角，比如不同的 denormal flushing 定义差异、模拟器是否真在模拟浮点而非委托给宿主硬件。还有人在用 WebAssembly 写软件渲染器，纯粹为了”再次感到被挑战”。

工具与游戏方面，Tiled Words 每日单词谜题游戏运营满半年，作者夫妇坚持每天出新题，刚被 Forbes 报道并上线了用户登录与玩家投稿系统。另有 Ménière 病发作记录 App、个人健康追踪等小而美的”受众只有一人”的项目。

整体看，本月分享既反映了 AI 工具渗入个人开发流程的趋势，也凸显出一批刻意远离 LLM、追求手工与硬件深度的开发者群体共存。

10. 幂等性容易，直到第二个请求与第一个不同

文章反驳了”加个 Idempotency-Key、缓存响应、重试时回放”这种对幂等性的常见简化叙述。作者认为这只覆盖了 happy path，真正困难的部分始于第二个请求——它不一定是第一个的干净重放。

文中列举了重放缓存方案无法解释的关键场景：完成后的重放、首次请求仍在执行时的并发重试、本地成功但下游事件未发布的部分成功、调用支付提供方后进程崩溃导致下游状态未知、相同 key 但请求体不同（例如金额从 10 EUR 变成 100 EUR）、无 key 的重复操作、过期后重试，以及部署/schema 变更/服务跳转/区域故障切换后的重试等。

作者强调幂等性是关于”效果”的——单次或多次执行应产生相同的预期效果。HTTP 方法层面的幂等性（如 PUT、DELETE）并不能阻止 handler 产生重复审计记录、重复领域事件、重复邮件、重复支付调用等业务侧重复。仅靠唯一约束（如 unique(account_id, merchant_reference)）只能防止一类重复，无法给客户端一个正确的重试结果——若行已存在但响应是通用 500，客户端仍无从判断支付是否成功。

对于”同 key 不同 body”的争议场景，作者给出自己的偏好：对副作用 API 应当硬报错，以早期捕获客户端 bug。文章随后展开了一个最小化的 idempotency_requests 表设计，需回答三个问题：谁拥有这个 key、第一条命令意味着什么、可以回放什么结果，并讨论了下游超时是保证终止的边界、回放是契约而非便利、队列消费者也有同样问题、过期是 API 契约的一部分等议题。

HN 讨论高度分化。一派主张极简方案：见到重复 key 就直接返回 409，把判断丢回客户端，配合唯一约束或 Redis 简单存在性检查即可，无需哈希、无需考虑 PII，多个电商 API 都这么做且运转良好。另一派坚持”API 是契约不是猜测”——契约说基于 key 就只看 key，说基于 body hash 就基于 body hash，不要替客户端”猜意图”。也有人指出幂等性本质是状态而非通信，相同支付发两次，应该有一次返回”支付已存在”。还有评论分享了真实事故：用户超时后回到前端追加商品再次提交，因 idempotency key 相同被支付网关误判为重复，最终少发了一单货，由此得出”幂等键应是客户端 key + 请求体哈希的复合键”的教训。亦有评论批评文章带有明显的 AI 写作节奏，可读性受损。

11. Mister 880：印了十年假一美元的老人

文章讲述了 Emerich Juettner（化名 Edward Mueller）的故事——一位在 1938 至 1948 年间默默印刷假一美元钞票近十年的纽约老人，最终成为美国特勤局历史上规模最大、耗时最长的伪钞调查案的主角，案件编号 880。

Juettner 1876 年生于奥匈帝国，移居美国后做过画框镀金匠和公寓维护工。1937 年妻子去世后，60 多岁的他独自以收破烂为生，收入难以糊口。他年轻时学过金属雕刻，又涉猎摄影，于是开始在公寓厨房用低劣材料和原始工艺制造一美元假钞——纸张不对、油墨粗糙、雕版细节缺失，部分钞票甚至有拼写错误，质量按行业标准属于极差。

但他成功了，关键在于刻意保持小规模并精准利用人性。一美元面额无人细看，他每次只投放少量假钞，从不与同一人交易超过一张。特勤局虽察觉到劣质假钞在纽约流通，却因作案模式与逐利型职业伪造者完全不同而困惑——发出 20 万张警示卡、走访上万家商店、调查数十名持币者均一无所获。直到 1948 年 1 月，几个孩子在上西区一处空地的雪中挖出锌版和 30 张”奇怪的钞票”，特勤局才顺藤摸瓜——锌版是几周前邻栋公寓火灾时消防员从堆满杂物的房间扔出窗外的。

Juettner 被捕后坦然承认一切，强调”没人因此损失超过 1 美元”。法官只判处一年零一天监禁，四个月后假释，并罚款 1 美元。1950 年好莱坞将故事拍成电影《Mister 880》，他从电影分成中赚到的钱比印假钞十年还多，最终在长岛安度晚年，1955 年去世。

HN 讨论中，许多人推荐 1949 年《纽约客》一篇更详尽的原始报道。也有人对特勤局把这定为头号大案表示费解：每年损失不过几百美元，对通胀几乎无影响。还有评论换算购买力，1948 年 1 美元约合今天 13.7 美元，足以买耗材但难以付房租，推测他可能拥有住所。一位评论联想起 Nabokov 的小说《The Leonardo》，主角同样是孤独地手工制作少量精致假钞的伪造者；还有人提到艺术家 J. S. G. Boggs 把手绘钞票当作行为艺术。多人都对”罚款 1 美元”是否被收银员仔细查验的彩蛋表示玩味。

12. 卡西欧 S100X 日本漆艺特别版计算器

卡西欧在日本市场推出了 S100X 的日本漆器（urushi）特别版，全球限量 650 台，售价约 99,000 日元（约 630 美元）。该机型在 S100X 高端计算器基础上，由日本漆器工匠手工施以传统涂装，定位是工艺品级的桌面计算器。原始页面在 HN 讨论时已返回 403，多数信息来自评论与第三方报道。

技术细节上，多位评论者强调键盘做工远超普通计算器：键帽采用 double-shot 双色注塑工艺，使用剪刀脚结构（scissor switch），并支持 3 键无冲（3-key rollover）。整机外观、重量手感与漆面光泽在评论中获得高度评价，被定位为”可以用一辈子”的物件。

HN 讨论体现出对这类产品的复杂态度。一部分人坦承被设计精度和工艺细节深深打动，担心买了之后会”对所有日常普通商品产生厌恶感”，变成那种执着于字体和材质的极客。另一部分人则自嘲是”非利士人”，承认自己看不出这与 5 美元的塑料计算器有何差别，并疑惑这究竟是面向收藏家还是更广泛受众。也有较冷静的评价：和劳力士一样，这是 vanity item，从纯实用角度并不出色——若真用它处理大量计算，更应反思工作流，改用电子表格或 Python 脚本。

围绕”日本漆艺为何突然走红”，有评论列出近期一系列相关产品与活动：MSI Prestige 13 AI+ 浮世绘版、V&A 博物馆刚开幕的漆艺展、《泰晤士报》专题，以及 PFU 富士通 HHKB 十周年漆器键盘等，怀疑是否有行业推广在背后操作。也有人提到二级市场上该机型已涨至约 1000 美元一台，并询问哪里能持续追踪这类”日用奢侈品”新品的发布信息。少量评论调侃更想看到漆艺版的 Casio F-91W 手表，或自己动手给老式 HP-80 计算器做漆面。

13. 事故报告：CVE-2024-YIKES（虚构供应链攻击讽刺文）

这是一篇精心写就的供应链攻击讽刺小说，以正式的”事故报告”格式虚构了一起跨 npm、Cargo、PyPI 三大生态的级联式攻击事件，因细节过于真实，许多读者初读时一度以为是真实事故。

故事主线是一连串荒诞但完全合乎逻辑的事件链：某周下载 8.47 亿次的 npm 包 left-justify 的维护者 Marcus Chen 被偷了 YubiKey，谷歌搜索补购时点进 AI Overview 推荐的钓鱼站 yubikey-official-store.net，输入 npm 凭据；攻击者随即发布带 postinstall 脚本的恶意版本，外泄 .npmrc、.pypirc、~/.cargo/credentials 等多种凭据。其中包括 Rust 库 vulpine-lz4 维护者的凭据——该库只有 12 颗星但是 cargo 的传递依赖。攻击者借此发布带 build.rs 后门的新版本，仅在主机名包含 build/ci/jenkins 等关键词时触发（且莫名其妙包含 “karen”）。Python 构建工具 snekpack 因”Rust 是内存安全的”而 vendored 该库，把恶意代码扩散给约 400 万开发者。

讽刺笔法贯穿全文：维护者被报告时正在葡萄牙研究山羊养殖（中了 230 万欧元欧洲百万乐透），事故响应频道因”compromised 的拼写”陷入 45 楼讨论，恶意软件的副作用之一是把用户默认 shell 改成 fish（被怀疑是 bug），最终事故被一只无关的加密货币挖矿蠕虫 cryptobro-9000 误打误撞修复——它运行 npm update 后顺手把 snekpack 升级到了已回滚 vulpine-lz4 的合法版本。CVE 在 MITRE 与 GitHub Security Advisories 就 CWE 分类争论六周后才正式发布。

HN 讨论中，最受关注的是有人据此真去翻了 Cargo 构建链中已有 build.rs 的 crates 清单，列出 flate2、tar、curl-sys、libgit2-sys、openssl-sys、libsqlite3-sys、blake3、libz-sys、zstd-sys、cc 等都是潜在高价值目标，并指出攻陷 xz2 还能波及 rustup。多位评论者感慨这篇虚构作品几乎可以无缝替换为真实事故，正说明当前供应链安全状况之糟。也有人借此讨论 agentic 开发可能加剧的长尾安全风险——开发者越来越快地拉入依赖、放弃对复杂系统的人类心智模型。Fish shell 用户对”非恶意软件，只是感觉像”的吐槽表示既被攻击又被理解。原 SCP 风格的写作、“Karen”触发条件、$4 假 YubiKey 包装的”lol”README 等段子被多次引用。

14. 在 Linux 上玩 Windows XP 经典游戏 Space Cadet Pinball

作者写了一篇怀旧科普：Windows XP 自带的 3D Pinball Space Cadet 如今可以原生在 Linux 上运行。背后是有人通过反编译和逆向工程重建了源代码，并将其移植到包括 Linux、macOS、Windows、Android、Nintendo Switch 等多个平台，项目托管在 GitHub（k4zmu2a/SpaceCadetPinball）。Linux 上最简单的方式是安装 Flatpak 包 com.github.k4zmu2a.spacecadetpinball，自带原版游戏资源。

文章还介绍了如何使用画质更高的 Full Tilt! Pinball 数据文件（1024×768 分辨率，archive.org 上可获取）替换 Flatpak 自带的低分辨率资源，需要先运行一次让数据目录创建出来，再解压新数据并删除旧数据目录（可能需要 sudo，因游戏在找到第一个数据目录后不会继续搜索其他位置）。作者还观察到不同版本数据文件甚至会改变游戏规则——如重入通道灯光的切换行为不同，使 Full Tilt 版更容易升级凸起。

文末作者提出”源代码托管（source code escrow）“的设想：商业软件在销售期内保留全部版权，但一旦停止销售，应自动转为允许社区维护改进的 FOSS 许可，以平衡创作者权益、用户利益与软件保护。

HN 评论中最受瞩目的是一位自称是 Space Cadet Pinball 原作者的留言，表示对项目延续生命非常感动，并将文章转发给 Cinematronics 的联合创始人 Mike Sandige（首席工程师）和 Kevin Gliner（设计与产品经理）。多位评论者惊叹仅凭反编译还原出的版本与原作几乎一模一样。其他评论补充了相关历史：Space Cadet 实际上来自 Maxis 的更大游戏 Full Tilt! Pinball，而 Windows 95 差点捆绑的是 DOOM（GLUEM 项目），被微软以”能不能就来个弹球游戏之类的”为由拒绝。Shopify 团队分享了去年为黑五做的弹球可视化项目，并感慨编程实现弹球玩法相当有挑战。多位评论者推荐了 Visual Pinball 生态，里面有大量社区制作的真实弹球桌仿真。也有人对作者的”源代码 escrow”设想表示赞赏，类比 KDE Free Qt Foundation 的社会契约——若 Qt 公司停止开源版本，基金会有权以 BSD 类许可发布 Qt；并建议各国政府应像英国国家图书馆要求出版物存档那样，立法要求源代码归档以备版权过期或停售后的保存。

15. GitHub 正在沉没：一篇呼吁离开 Microsoft GitHub 的檄文

作者 David Bushell 撰文批评被微软收购后的 GitHub 正在快速恶化：可用性下降、状态页面与实际不符、Copilot 等 AI 功能堆砌、垃圾内容（slop）和机器人泛滥，甚至出现 GitHub “自我 DDoS” 的局面。文章配有一张显示收购后月度可用性从平稳绿色变为震荡红橙色的曲线图，并列举了多篇近期”告别 GitHub”的博客（Ghostty、Lonami、Armin Ronacher 等）作为佐证。

作者强调 Git 不等于 GitHub：Git 是分布式开源协议，中心化 forge 只是社交便利。文章推荐了若干替代方案：Codeberg（基于 Forgejo 的非营利社区方案，被视为最稳妥选项）、Tangled（基于 AT 协议的早期项目）、Gitea、GitLab（被调侃为”臃肿但能糊弄老板”）、以及不推荐的 Bitbucket，并补充了 Sourcehut、Radicle 等。对自托管者，作者推荐 Forgejo，并指出即便用邮件列表（如 Linux 内核）也能维护大型项目，所谓”扩展性问题”多是借口。

HN 评论的最高赞观点与作者形成对照：多人指出 GitHub 真正的压力来源是 AI 编码工具带来的提交量爆炸式增长。GitHub COO 数据显示 2025 年提交量达到 10 亿，目前每周已 2.75 亿次，Actions 用量两年内从每周 5 亿分钟增至 21 亿分钟。也有人质疑收购前 100% 可用性的图表更像是状态页更新不及时；还有用户反映访问普通仓库就触发二级速率限制。一些评论同情迁移诉求，但指出 SourceForge 式衰落让人惋惜；也有开发者描述了仓库被 AI 集成自动加入 “feature” 文件夹后愤而迁移到 Codeberg 的经历。文章末尾的”由人类撰写”声明也获得不少认同。

16. let-go：用 Go 实现的类 Clojure 语言，冷启动仅 7ms

开发者 nooga 发布了 let-go，一个用 Go 编写的”几乎是 Clojure”的 Lisp 方言，主打极快的冷启动（README 中标注 7ms，下方又写到 6ms，被评论者打趣）。项目目标是让 Clojure 风格的 Lisp 摆脱 JVM 启动开销，同时利用 Go 的 runtime、标准库和并发原语。

HN 讨论的焦点是”为什么又是一个 Clojure 方言”。评论者列举了同类生态：Janet（基于自有 VM，可用于生产）、Fennel（基于 Lua VM）、Joker（被认为被低估）、Glojure（基于 Go，已有 AOT 工具 Gloat 和浏览器 WASM REPL），以及 Carp、Dale 等编译到 C 的 Lisp。有评论指出这些项目集中出现，反映了一种趋势：Go 的运行时与标准库被认为是带 GC 语言中最优秀之一，但语法过于冗余、表达力不足，因此涌现一批”编译到 Go”的语言尝试，例如 Lisette。

社区希望看到的是更深入的对比：哪一个真正”以 Go 为宿主”，能像 JVM Clojure 与 Java 那样实现双向互操作（Go 调用 Lisp，Lisp 调用 Go，混合项目），以及与 Clojure 在语义上的具体差异。也有人对项目命名提出建议，如 “clogo”。一位 Plan 9 用户欣喜于该项目能在 plan9 上运行，期待 Go/Clojure 风格语言进入 9front 生态，用以替代当前 rc 与 awk 的工作流。整体讨论氛围正面，但也透露出”Lisp 方言已经太多”的疲倦感。

17. 任务瘫痪与 AI：一种新的依赖正在形成

博主 Daniel Gilbert 自述疑似 ADHD 倾向（兄弟姐妹童年已确诊，本人尚未诊断），常常在制定好策略后无法迈出第一步——他将这种状态称为 Task Paralysis，区别于 Analysis Paralysis：“分析瘫痪是大脑空转，任务瘫痪是大脑根本不转”。他频繁换岗（每 2-3 年一次），难以在某一技术领域深耕。

他坦言对 AI 态度复杂：反感 AI 对艺术家的伤害，自己已停止用 AI 做艺术创作；但在编码上，Claude Code 帮助他跨越了启动门槛——他有想法、有架构，只缺一个”乐于实现”的执行者。AI 让”想法”到”成品”的循环极短，多巴胺反馈强烈。他从 Pro 套餐升级到 Max，又额外购买 API 额度，自比”求着 dealer 给下一针的瘾君子”，承认自己正在与对 AI 的依赖作斗争。

HN 评论高度共鸣。一位有正式 ADHD 诊断的开发者表示，过去一年沉迷 agent 工作流后，新鲜感消退，反而怀念深入低层技术挑战的乐趣，对管理 agent 群、反复发现 agent 在验收测试上偷工减料感到厌烦，即便产出了高质量的库和工具，也因”是模型生成”而失去满足感。另一位八年大厂 SWE 表示 AI 杀死了他对编程的乐趣：从前是”自下而上”地从理解走向实现并享有所有权，如今变成”自上而下”先拿到实现、之后才尝试理解，连思考都被外包，自己沦为”瓶颈”，且代码价值归零，他人觉得”我也能 vibe code”。

多位评论者描述了同样的订阅升级路径（Pro → Max5 → Max20）和触及周限额时的”如释重负”，认为对那些天生难以自控、需要靠环境约束行为的人来说，把 AI 作为日常工作工具相当危险。也有人指出，AI 让一小时能做的事变成”消防水枪”，反而引发新的回避——因为永远感觉精力不足以处理那么多产出，加上同时活跃的项目数量激增，优先级判断本身就成了负担。

18. YC 的”丑闻档案馆”：一个非官方网站盘点 Y Combinator 投资败局

ycombinator.fyi 是一个匿名上线的非官方网站，自称 YC 的”档案记录”，以解剖报告（Autopsy Report）形式列出约 39 家 YC 投资公司的丑闻或失败案例。被点名的公司包括：Delve（声称用 AI 自动化 SOC 2 / ISO 审计，被吹哨者揭发自动生成虚假审计报告，被 YC 除名）、Central（以客户身份混入 YC 同门 Warp 半年后抄袭其产品获 YC 资助）、Naive（用一个 4.1 万星的 MIT 开源框架包装成”自主 AI 员工”融资 200 万美元，去除原始版权信息）、PearAI（fork Continue.dev 后批量替换名称并附上 ChatGPT 生成的虚假许可证）、Pickle（GPL 代码改 Apache 2.0、AR 眼镜演示疑似 CGI）、Optifye.ai（被称为”血汗工厂即服务”的工人监控摄像系统，YC 删除了演示视频）、Rezi（提前付租金给房东的房产平台，崩盘留下 4900 万美元的止赎诉讼）、Double Finance（1 美元/月的直接指数化机器人投顾，AUM 破千万后一年内关停，YC slug 还被回收用于创始人下一项目）等。

HN 评论以批评网站本身为主。最高票指出：YC 投资过 5000 多家公司，这里只列出 39 家，其中许多按网站自己的描述也只是普通的商业失败，并无丑闻成分；把它们与真正的欺诈混在一起反而稀释了可信度。多人质疑 Zenefits（被对手安插间谍）、Pebble（被苹果碾压的”黑天鹅”）、Cruise（GM 责任）等不该归为 YC 的丑闻。还有评论指出 Rippling 的条目逻辑混乱——开头提到 Parker Conrad，正文却完全在写竞争对手 Deel 派间谍渗透 Rippling 的事，按描述 Rippling 是受害者，根本不构成自身丑闻。多位评论者怀疑内容是 AI 生成（slop），加上交互上需要点击”剧透”才显示文字，整体观感像是”出于怨念”的项目，可能来自被 YC 拒绝的人，甚至涉嫌商标侵权。也有少数 YC 老校友表达对当下 YC 投资方向（执法监控类 Flock 等）的反感。

19. 西班牙跃升为欧洲最便宜电力市场之一：风光替代燃气的结构性变化

Jan Rosenow 撰文分析：2026 年前四个月，西班牙批发电价均价为 44 欧元/兆瓦时，远低于德国 96、英国 103、意大利 127，已逼近北欧水电核电组合的水平。十年前西班牙还是太阳能投资搁浅、电价较高的反面教材。

文章将原因归结为电源结构的根本变化：煤炭从 25 年前占比三分之一到如今基本归零；燃气曾在 2000 年代末占 30% 以上，目前回落到约 19%；核电稳定在 19%，水电与生物质合计 14%；剩余空间被风光填满。2025 年风电单独占 20%、太阳能占 22%。2022 年是关键拐点，风光合计首次超过所有化石燃料发电之和；2026 年一季度风光占 44%，化石燃料 17%。

价格机制层面，欧洲批发电价由每小时最贵的边际机组决定，过去十年大多由燃气决定。2022 年燃气在西班牙是 55% 小时数的边际机组，2024 年降至 27%，2026 年前四个月仅 9%。作者也明确说明几点限制：燃气仍占约五分之一发电量；批发电价不等于居民电价（西班牙居民电价 0.265 欧元/千瓦时仍高于欧盟均值，排第 16）；估算方法基于 Zakeri 等 (2023) 的方法，未涵盖水电的机会成本报价、热电联产的特殊监管定价，因而可能低估燃气对市场价格的实际影响。

HN 讨论中最高票观点提出反向解读：西班牙电价低不是单纯由清洁电源结构决定，而是因为伊比利亚半岛与欧洲核心电网互联容量有限，套利通道受限，形成价差；若与德国充分互联，价格会趋同。西班牙本身正推动更多互联以让本国可再生能源产业受益于更高价格。其他评论涉及光伏与电池价格暴跌使风光成为最便宜选项、欧洲 ETS 排放定价是高电价的政治原因、西班牙仍是俄罗斯 LNG 主要买家的道德争议，以及对此前西班牙大停电的解读：有评论引用 ENTSO-E 高管说法称问题在电网无法应对快速电压波动，并认为大量核电因负电价被关停削弱了系统稳定能力。也有人指出该作者只看日前市场，远期合约（如 CAL27）西班牙仍高于法国和北欧。

20. Show HN：rust-but-lisp，用 S 表达式语法书写的 Rust

ThatXliner 发布的 rust-but-lisp 项目把 Rust 的语法包装成 Lisp 风格的 S 表达式，本质上是 Rust 的另一种前端语法，而非真正独立的 Lisp 方言：它不引入新的语义，只是让人用括号写 Rust。项目目标是让喜欢 S 表达式的开发者也能享受 Rust 特有的所有权、生命周期等语义。

HN 评论给出了较为务实的反馈。一位用户指出当前代码无法直接编译（codegen.rs 中残留 span 相关代码、main.rs 中尝试 format 未实现 Display 的 Warning），修复后基本可用，但会把单字母类型自动当作泛型参数，导致 (struct X) (enum A (P X) Q) 被错误生成为 enum A<P, X> { Q }；多字母类型如 String 则正常。试图通过空泛型参数列表绕过时还会产出带有 List 调试注释的奇怪输出。

围绕设计动机的讨论分成两派：一派认为这种”宿主语言不变、只换皮”的做法精确复现 Rust 语义反而是优点，因为很多人喜欢 Rust 的语义；另一派则指出它”看起来像 Lisp 但不是 Lisp”，对常写 Lisp 的人显得别扭，例如示例中的 ((. dx powf 2.0) + (. dy powf 2.0)) sqrt) 不符合 Lisp 习惯。还有人质疑虽自称覆盖全部语法，却没有展示 Rust 中最棘手的生命周期标注与 turbofish。

实用性方面，评论者询问是否有指向 Lisp 源码位置的错误信息、能否使用 rust-analyzer 等 LSP，普遍预期答案为否。多人联想到类似项目：Loon（受 Rust 启发的 Lisp）、Carp、Dale（编译到 C 的 Lisp），以及 Greenspun 第十定律——任何足够复杂的 C/Fortran 程序都包含一个非正式、半实现的 Common Lisp，是否也该把 Go 和 Rust 加入这一定律之中。也有人调侃此项目像是直接暴露了 Rust 内部 AST，并提出”为什么要以 AST 形式输入程序”的疑问。