HN 每日深度阅读 · 2026-05-21
本期聚焦平台与公权力对个体表达的双重挤压：Meta 应海湾国家要求大规模屏蔽人权组织账号，田纳西一名退休警员因一则特朗普表情包被羁押 37 天后获赔 83.5 万美元，凸显言论边界的脆弱；技术层面，C 语言无处不在的未定义行为提醒底层正确性近乎奢望。
共 20 篇 · 约 12,517 字 · 约 31 分钟读完
1. Meta 应沙特和阿联酋要求屏蔽人权组织账号
- 原文: https://www.alqst.org/ar/posts/1190
- HN: https://news.ycombinator.com/item?id=48206768
- 得分: 892
- 评论: 382
ALQST 等多家人权组织联合声明指出，自 2026 年 4 月 30 日起，Meta 应沙特阿拉伯和阿联酋政府的要求，对 Facebook 和 Instagram 上多个独立 NGO、研究人员和公民社会人士的账号在两国境内实施地理屏蔽（geo-blocking）。受影响者包括 ALQST、Democratic Diwan 以及沙特研究人员 Abdullah Alaoudh、人权活动人士 Yahya Assiri。根据 Meta 公开的内容限制报告，自 2026 年 3 月以来已有逾百个页面和账号被限制访问，类似情况此前也在 X 平台上发生过。
Meta 在通知中援引”当地法律要求”，具体指沙特和阿联酋的网络犯罪法，并称违规内容涉及”地区地缘政治冲突和安全发展的报道”。声明指出，这些法律长期被两国政府用于压制异见，许多人因社交媒体发言被起诉甚至判刑。声明特别质疑 Meta 所宣称的”人权尽职审查”流程：要求其公开收到的法律请求全文、披露审查标准、说明区域办公室在其中扮演的角色，并立即恢复受影响账号的访问。签署方包括 Access Now、EFF、Gulf Centre for Human Rights 等十余个组织。
HN 评论分为几派。一部分人认为 Meta 别无选择——要么遵守要求，要么被整体封禁，反而让本地更糟的平台填补空白；另一部分则批评以”增长优先”为核心的社交媒体平台缺乏原则，将利润私有化、危害社会化。有身处阿联酋的用户证实 alqst.org 在当地被完全封锁，需要 VPN 才能访问。也有评论翻出当年硅谷”社交媒体将传播民主”的宣传，对照如今的现实感到讽刺。还有人提到《Careless People》一书所揭示的 Meta 内部文化，认为此事并不意外。讨论中也出现了对去中心化、联邦化平台和不含广告与算法的替代方案的呼吁。
2. C 语言中无处不在的未定义行为
作者以近 30 年 C/C++ 编程经验直言：没人能写出完全正确的 C 或 C++ 代码。文章核心论点是，C/C++ 中的未定义行为（UB）远比大多数人想象的要多，且不仅仅出现在悬空指针、越界访问、双重释放等”经典”场景，许多看似平凡的操作同样会触发 UB。
作者特别澄清一个常见误解：UB 不是”开启优化时编译器恶意利用漏洞”，而是编译器有权假设程序不会触发 UB，因此根本无需为这些情况生成代码。文章列举多个例子：解引用未对齐指针在 Alpha 上可能由内核修复、在 SPARC 上直接 SIGBUS、在 x86 上看似正常——但所有情况都是 UB；甚至仅仅创建未对齐指针（强制类型转换）就已构成 UB，与是否解引用无关。其他例子还包括：在 char 为 signed 的平台上向 isxdigit() 传入负值会越界读数组；float 到 int 的转换若超出 int 范围则是 UB，而判断是否超出本身就充满陷阱；signed 整数溢出、std::atomic 在未对齐时的原子性问题等。
HN 讨论非常活跃。有评论补充了更”刁钻”的例子：对 volatile int 在 printf 同一调用中读两次会触发 UB，因为 volatile 访问被视为副作用，未排序的同对象副作用是 UB——相当于单线程”数据竞争”。也有人总结学习 UB 的五个阶段：否认、愤怒、讨价还价、抑郁、接受。批评意见认为，文章的例子大多是”取决于输入才会成为 UB”，按这标准任何函数调用都可能栈溢出；C++ 也已演进多年，文章中的原始指针写法早已不再 idiomatic，将 C 与现代 C++ 混为一谈不够公允。还有人指出 UB 真正危险之处在于编译器可以基于”UB 不会发生”的假设进行优化，从而删除或重写大段代码，导致结果与直觉严重不符。也有资深 C 程序员表示，过去二十年很少听到 UB 这个话题，最近半年才频繁登上 HN，反映了语言安全性讨论的范式转变。
3. 田纳西男子因特朗普表情包被关 37 天 获 83.5 万美元和解金
退休执法人员 Larry Bushart 在 2025 年 9 月保守派活动人士 Charlie Kirk 遇刺后，在 Facebook 上分享了一张引用特朗普校园枪击事件后”我们必须挺过去”原话的表情包。该表情包配图中提到的是 2024 年发生在爱荷华州 Perry 市的 Perry High School 枪击事件，与田纳西州 Perry County 高中相距 500 多英里。但 Perry 县治安官 Nick Weems 和调查员 Jason Morrow 在不向法官说明这一关键背景的情况下申请逮捕令，将其以 200 万美元保释金关押 37 天，期间他失去退休后的工作、错过结婚纪念日和孙辈出生。事件全国发酵后他才获释。
在 FIRE（个人权利与表达基金会）代理下，Bushart 提起联邦民权诉讼，最终与 Perry 县及治安官达成 83.5 万美元和解。FIRE 援引最高法院 Watts v. United States 案，强调政治性言论受第一修正案完全保护。文章还提到 Kirk 遇刺后全美有数百人因网络言论遭到处罚，FIRE 同时代理田纳西州雇员 Monica Meeks 等类似案件。
HN 讨论的焦点是和解金来源。大量评论批评由纳税人而非警察个人或养老金承担赔偿，导致违法警员毫无切肤之痛，主张应从警员退休金扣除以建立有效的纠错激励。也有相反观点认为，民主制度下选民对当选官员（治安官系民选）负有责任，由纳税人买单恰恰是合理的问责机制。另一个争议焦点是缺乏刑事问责——许多人认为治安官滥用职权应被起诉，并对比欧洲法系中类似行为通常会面临刑事追究。也有人提醒不应以”把更多人关进监狱”的方式解决过度监禁文化。许多评论赞赏 FIRE 在左右两端言论案件中保持一致立场，并推荐 Jessica Pishko 的著作《The Highest Law in the Land》了解美国治安官权力的结构性问题。
4. OpenAI 模型推翻离散几何中一个核心猜想
OpenAI 宣布其内部通用推理模型自主推翻了 Paul Erdős 在 1946 年提出的平面单位距离问题中的一个长期猜想。该问题问：平面上 n 个点最多能形成多少对距离恰好为 1 的点对？记此最大值为 $u(n)$。基于重新缩放的方格构造，已知下界为 $n^{1+C/\log\log n}$，Erdős 猜想上界为 $n^{1+o(1)}$，即增长率本质上略快于线性。
新结果给出了一族构造，对无穷多个 n 实现 $n^{1+\delta}$ 的单位距离对数（$\delta>0$ 为固定常数）。普林斯顿数学教授 Will Sawin 后续细化证明 $\delta$ 可取 0.014。证明的关键不在几何本身，而在代数数论：扩展 Erdős 原始基于高斯整数的构造，使用具有更丰富对称性的代数数域，并借助无穷类域塔与 Golod–Shafarevich 理论证明所需数域确实存在。证明已由外部数学家独立验证，菲尔兹奖得主 Tim Gowers 称其为”AI 数学的里程碑”，数论学家 Arul Shankar 认为这表明当前 AI 模型已能产生原创性想法并将其贯彻到底。OpenAI 强调该模型并非数学专用模型，也未针对该问题做专门调校。
HN 讨论高度分化。一派援引 Ayer 和早期维特根斯坦的观点，认为数学真理本就是从公理和规则中”展开”已蕴含的内容，因此”重组训练数据”不应成为否定 AI 贡献的理由。许多评论强调这次是”反例式证伪”，比正向证明猜想容易，本质上是高级搜索而非新理论的构建。另一派指出，AI 跨领域调用数学工具（这里是用代数数论攻克几何问题）的能力，可能恰恰打破人类研究者过度专业化的瓶颈。也有人讽刺”PhD 级智能”的目标已悄然挪到欧拉、伽罗瓦级别。有人质疑为何报道中被解决的总是 Erdős 问题，而不是其他领域的悬而未决问题。还有人注意到该任务的”思维链”摘要长达 125 页，推理规模惊人。
5. Qwen3.7-Max 发布：面向智能体时代的旗舰模型
- 原文: https://qwen.ai/blog?id=qwen3.7
- HN: https://news.ycombinator.com/item?id=48205626
- 得分: 582
- 评论: 233
阿里巴巴发布 Qwen3.7-Max，定位为面向智能体时代的专有旗舰模型，强调在编码、办公自动化以及长程自主执行上的综合能力。官方称其在一次 35 小时、超过 1000 次工具调用的完全自主内核优化运行中保持了连贯推理，并能跨 Claude Code、OpenClaw、Qwen Code 等多种智能体框架稳定工作。模型即将通过阿里云 Model Studio API 提供。
基准成绩方面，Qwen3.7-Max 在编码类任务表现突出：Terminal Bench 2.0-Terminus 69.7（超过 DS-V4-Pro Max 67.9），SWE-Verified 80.4 与 Opus-4.6 Max 持平，SWE-Pro 60.6、SWE-Multilingual 78.3、SciCode 53.5 等多项领先。通用智能体方面，MCP-Mark 60.8、MCP-Atlas 76.4、Skillsbench 59.2 均位居前列，Kernel Bench L3 取得 1.98 倍中位加速、96% 胜率。在 STEM 与推理上，GPQA Diamond 92.4、HMMT 2026 Feb 97.1、IMOAnswerBench 90.0、Apex 44.5 均为榜单第一。多语言能力（WMT24++ 85.8、PolyMATH 86.5）也展现出明显优势。
HN 评论普遍肯定其在 AA-omniscience 上的非幻觉率达到 SOTA，甚至超过 Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5。许多用户分享了将 Qwen3.6 与 llama.cpp、OpenCode 结合本地使用的体验，认为开源模型已经非常接近闭源前沿。也有用户希望阿里能与美国超大规模云厂商合作，让 Qwen 模型在美国境内合规可用，方便企业生产环境采纳。多个评论质疑基准对比中未纳入 Opus 4.7、GPT-5.5、Gemini Flash 3.5 等最新竞品。开发者关心该模型是否会像之前一些 Qwen 模型那样在一段时间后开放权重，以及在 OpenRouter 等代理平台上的吞吐性能。也有人观察到 OpenRouter 上 Qwen 调用量在 4 月初出现尖峰，猜测是基准测试方还是普通用户尝鲜。
6. 意大利宝可梦中文维基从 Google 搜索结果中消失
Pokémon Central Wiki——15 年来意大利语圈最知名的宝可梦信息站点——近日发现自己几乎从 Google 搜索结果中完全消失，运营团队在 X 上发文表示”Google 似乎讨厌我们了”。文章本身信息有限，主要是社区对该现象的讨论和对 Google 搜索现状的吐槽。
HN 讨论从多个角度展开。一种观点认为这并非”仇恨”而是 Google 的”漠不关心”——作为一个庞大的商业组织，它已不再像早期那样在乎单个内容站点的命运。许多用户分享自己从 Google 搜索转向 Kagi 的体验，吐槽 Google 顶部塞满推广链接、AI 答案使用配额不透明等问题。另一种解释从技术角度出发：维基类站点近年遭受严重的垃圾内容攻击，一些维护者不得不关闭注册，如果 Pokémon Central 在旧版 MediaWiki 上长期未清理恶意内容（甚至挂上恶意链接），Google 将其判定为风险站点并降权也有一定合理性，恢复需要彻底审计内容并向 Google 申诉。也有人推测可能是 Google 的爬虫或索引环节出现细微 bug，比如对 HEAD 请求处理异常导致某类站点被排除，类似情况在小型搜索引擎实践中并不罕见。
还有相当多评论将此事与更宏观的趋势联系起来：Google 已经爬取了内容并用于训练模型，自然不再有动力将流量导回原站；本次 I/O 主题演讲后，AI Overview 进一步将搜索结果”页脚化”，独立网站获取自然流量的窗口正在快速关闭。也有 OpenCV 文档、个人博客被去索引的类似抱怨，反映 Google 搜索质量在更广范围内的下滑。
7. Railway 事故复盘：GCP 误封导致整个平台 8 小时中断
2026 年 5 月 19 日 22:20 UTC 至 5 月 20 日约 06:14 UTC，PaaS 厂商 Railway 经历了一次长达近 8 小时的全平台中断。直接原因是 Google Cloud 通过一项自动化操作错误地将 Railway 的生产账号置于暂停状态，该自动化动作同时影响了 GCP 内多个客户账号，且事先未对受影响客户进行任何通知。
Railway 的控制平面、数据库和部分网络基础设施都托管在 GCP，账号被暂停后 Dashboard 和 API 立即返回 503 错误。更严重的是，Railway 的边缘代理依赖 GCP 上的网络控制平面来填充路由表，虽然 AWS 和自有 Railway Metal 上的工作负载本身没有挂掉，但随着路由缓存过期，这些区域的工作负载也开始返回 404，故障级联到了所有区域。GCP 在 22:29 UTC 恢复了账号访问，但持久磁盘、计算实例、网络都需要逐项手动恢复——磁盘 23:54 UTC 全部就绪，网络直到次日 01:30 UTC 才完全恢复。恢复期间又触发了 GitHub 对 OAuth 和 Webhook 的限流，导致登录和构建再次受阻。
Railway 在复盘中坦承架构问题：单一上游云厂商的动作不应能引发平台级故障，未来将把 GCP 服务从数据平面的热路径中移除，仅保留为故障转移备份。
HN 评论几乎一边倒地警告 GCP 风险。许多评论指出 GCP 在自动化账号封禁方面已多次出问题，缺乏人工介入和申诉机制；有评论将其归因于内部高管造成的文化变化，并指出 GCP 与传统的 Google 是完全不同的实体，不应以”Google 品质”预期之。也有评论赞赏 Railway 没有把责任全推给上游，而是承认”是我们选择了供应商，我们对正常运行负有最终责任”。一些用户分享了已紧急迁移到 Azure 的经历，并讨论除 Vercel、Supabase、Railway 之外的中型 SaaS 部署替代方案。另一个细节引发关注：事故时间线显示自动化监控比 GCP 账号被暂停早 10 分钟检测到 API 健康检查失败，时间戳的不一致暗示根因可能比”误封”更复杂，至今未完全披露。还有人指出复盘中”用户需重新接受服务条款”这一副作用更像 Railway 自身的实现问题，而非 GCP 责任。
8. 恶意 VSCode 扩展导致 3800 个 GitHub 私有仓库被泄露
GitHub 证实，一次通过恶意 VSCode 扩展发起的供应链攻击导致约 3800 个仓库的源代码被未授权访问。攻击者借助开发者机器上安装的受感染扩展，获取了 GitHub 凭据或令牌，并访问了大量内部及私有仓库。被盗源代码已出现在地下论坛上，挂牌出售，并声称若无买家将免费泄露。该事件与此前 GitHub 宣布正在调查内部仓库未授权访问的事件属于同一序列，也与 nx-console 等扩展近期被报告的安全事件时间高度吻合。
HN 讨论的核心集中在 VSCode 扩展生态长期存在的安全隐患。多位评论者指出，VSCode 经常根据打开的文件类型弹窗推荐扩展，普通用户很难区分哪些是官方维护、哪些是个人开发者上传，部分看似”官方”的扩展实际安装量数百万却归属不明。社区普遍呼吁微软为扩展引入显式权限系统，类似浏览器扩展或移动应用的权限模型，限制扩展对文件系统、网络、凭据的访问。
技术层面，有人提到 VSCode 基于 Electron，沙箱化在 Linux 下因 SUID helper 的历史包袱而困难重重；也有人讨论 WebAssembly 是否能成为扩展运行的更安全沙箱方案。另一条讨论线索集中在 GitHub 细粒度令牌的局限：用户希望避免一次授权暴露所有关联仓库和组织，但目前细粒度令牌无法读取 Actions 的 Checks 结果等关键能力，导致很多人仍在使用权限过宽的经典 token。还有评论戏称这是”另一种让代码开源的方式”，反映出社区对私有代码托管中心化风险的无奈。事件也再次把 Microsoft（VSCode）、npm、GitHub 同属一家公司却未能形成协同防御的尴尬摆上台面。
9. Map of Metal：一张交互式金属乐流派演化地图
- 原文: https://mapofmetal.com/
- HN: https://news.ycombinator.com/item?id=48205699
- 得分: 384
- 评论: 138
Map of Metal 是一个交互式网站，以地图形式呈现金属乐的历史脉络与各子流派之间的影响关系，并标注塑造这些流派的代表性乐队。站点由 Patrick Galbraith 与一位多媒体专业的朋友合作完成，最初基于 Flash 开发，后来移植到 HTML5，但仍保留了 Flash 时代的视觉氛围。作者在 HN 现身解释，整个项目最初仅花了一两周时间，移植后代码也开源在 GitHub。移动端支持因 YouTube 嵌入播放器策略变化（早期可嵌入极小播放器且广告少）和 WebGL 自定义渲染器未完成等原因长期搁置。
HN 讨论从多个角度展开。一位老乐迷回顾了金属乐谱系的历史观变迁：1970 年代末时，Jimi Hendrix 的《Purple Haze》在当时听众耳中几乎等同于金属乐，而如今主流叙事更多把 Black Sabbath 和 Judas Priest 视为流派起点，Led Zeppelin 的地位也被重新评估，说明流派定义本身随时间漂移。
很多评论者顺势推荐了类似的可视化项目，包括电子音乐领域的 Ishkur’s Guide to Electronic Music、Spotify 旗下 everynoise.com（作者被裁员后已停止更新，成为静态快照）、music-map.com、musicroamer 等。也有人感叹希望在爵士、古典、嘻哈领域看到带有历史脉络和个性的同类作品。
不少讨论涉及”地图上缺失的角落”：Katatonia、Agalloch、Alcest 等被归入 blackgaze 或 grey metal 的乐队未被收录；奇幻金属（如 Blind Guardian、Windrose）、metalstep 等融合电子与金属的小众分支也难以归类。普遍观点是这类流派地图的”密度”集中在过去，近十余年的演化相对停滞，或者说新流派的形成方式已经不再依赖明确的子类标签。
10. Anna’s Archive 被判赔 1950 万美元并面临全球域名封禁令
由 Penguin Random House、Elsevier、HarperCollins 等十三家主要出版商组成的联盟，在纽约联邦法院对影子图书馆 Anna’s Archive 赢得了 1950 万美元的缺席判决。法官 Jed S. Rakoff 按照 130 部”涉案作品”每部 15 万美元的法定赔偿上限顶格判赔。由于站点运营者匿名且未出庭应诉，判决还要求其在 10 天内披露真实身份——考虑到运营者此前公开声明匿名是为了避免”数十年牢狱”，业内普遍认为这一要求将被忽略。
判决真正的杀伤力在于永久禁令。法院点名了二十多家技术中介机构，包括 Cloudflare、Njalla、DDOS-Guard，以及管理 .gl（格陵兰）、.pk（巴基斯坦）、.gd（格林纳达）等当前活跃域名的注册局，要求它们永久停用 Anna’s Archive 的域名并阻止转移。出版商指控该站不仅传播盗版图书链接，还成为 Meta、NVIDIA 等 AI 公司训练数据的主要来源。与早先音乐行业 3.22 亿美元判决不同的是，出版商的图书目前仍在站上可访问，这可能使中介机构更难忽视禁令。然而禁令对美国管辖外的实体执行力有限。
HN 讨论高度分裂。一类观点关注数字时代图书馆与首次销售原则的消亡：用户购买的”许可证”无法转售、捐赠，传统图书馆模式正在被流媒体经济侵蚀。另一类观点质疑司法系统的双标——LLM 公司从 Anna’s Archive 获取大量训练语料却基本毫发无损，而做”脏活”的影子图书馆承担全部法律后果。还有评论指出运营者大概率位于俄罗斯，俄方不会配合美方裁决；也有人推测 Anna 已在 Spotify 元数据事件后预料到此结果。技术层面，有人分享了 Anna 本人撰写的《如何运营影子图书馆》指南，以及 open-slum.org 这类追踪各影子图书馆在线状态的资源。多名评论者把这次判决形容为”数字版《华氏 451》“，也有人质疑维基百科作为美国实体是否会被迫停止链接相关域名。
11. Google AI 搜索结果被轻易操纵，搜索巨头悄然反击
BBC 记者 Thomas Germain 此前撰文揭示，只需在个人网站上发布一篇精心撰写的博客，就能在约 20 分钟内让 ChatGPT、Gemini 和 Google AI Overviews 把作者描述成”世界冠军吃热狗选手”。这一手法被不法企业大规模滥用，用于在医疗补充剂安全性、退休理财建议等严肃话题上向公众投喂偏向性答案。问题根源在于 AI 搜索工具经常基于单一网页或社交媒体帖子生成答案，对来源缺乏交叉验证。全球每月有十亿人使用 AI 聊天机器人，25 亿人看到 Google AI 概览，操纵的潜在影响极大。
在报道与研究者推动下，Google 上周更新了搜索垃圾内容政策，明确将操纵 AI 响应的行为列为违规，违者可能被降权或从索引中移除。Google 官方称这只是”措辞澄清”而非政策变化，但 SEO 顾问 Lily Ray 和 Harpreet Chatha 观察到，Google 和 ChatGPT 似乎正悄悄从 AI 答案中剔除那些有自我推销嫌疑的公司——文章可能仍被引用，但公司名称会被排除在结论之外。即便如此，Ray 在本周仍成功复现了同样的把戏，让 Google 称某位 SEO 同行”擅长堆沙堡”。
HN 讨论中，最尖锐的观点认为 Google 从未真正以”正确”为产品目标，留住用户和 SEO 营收才是核心。多位评论者指出，Google 自 2006 年以来就未能有效清理 SEO 垃圾，这次也不会例外，“AI 不过是被美化的搜索，背后没有任何推理”。也有人认为案例本身——“2026 年南达科他州国际吃热狗冠军”——是个生造的冷门查询，并不能证明对热门查询同样有效，相当于”先造一个虚构维基条目，再写文章证明维基不可信”。另一位 HN 用户 Simon Willison 分享称，他一年半前对”半月湾港口鲸鱼名字”做的低水平索引投毒，至今仍出现在 Google AI 摘要中。还有人测试 Claude，发现它能识破热狗陷阱，却又把另一篇钓鱼文章当作事实引用。整体看，社区把这视为 SEO 演化为”AIO”（AI 优化）的开端，预期是 Google 与黑帽优化方之间无止境的猫鼠游戏。
12. SpiderMonkey 告别 asm.js：OdinMonkey 的诸神黄昏
自 Firefox 148 起，SpiderMonkey 的 asm.js 专项优化默认关闭，未来版本将彻底移除相关代码。由于 asm.js 本身只是标准 JavaScript 的严格子集，依赖它的网站不会立即损坏，原有代码仍可通过常规 JIT 运行，只是失去专门加速。Mozilla 建议这些项目重新编译为 WebAssembly，以获得更快执行速度和更小二进制体积。
asm.js 于 2013 年随 Firefox 22 推出，是 Mozilla 对 Google NaCl/PNaCl 的回应：通过静态类型化的 JS 子集，让引擎能即时识别并编译为接近原生速度的机器码，且代码仍位于 Web 内容中、可使用 Web API，无需独立沙箱或替代 API。它让 Unity、Unreal 等 C/C++ 引擎首次以纯 Web 技术运行——Epic Citadel demo 当年仅用四天就移植完成。asm.js 证明了 Web 上原生级性能可行，直接催生了几年后的 WebAssembly（Firefox 52，2017）。如今 WebAssembly 已成熟，asm.js 用户基本完成迁移，继续维护双路径意味着维护成本和额外攻击面。Mozilla 用北欧神话叙事告别：asm.js 编译器名为 OdinMonkey，将被巨狼 Fenrir 吞噬，由 WebAssembly 优化编译器 BaldrMonkey 和基线编译器 RabaldrMonkey 继承。
HN 讨论充满怀旧气息。多位评论者重温 Gary Bernhardt 的经典演讲《The Birth and Death of JavaScript》，感慨当年的”科幻”已成现实。一位 Figma 早期工程师透露，Figma 最初是纯 C++ 代码库，asm.js 证明了在浏览器中运行设计工具的可行性，直到有了付费客户后才迁移到 WebAssembly，主要换来更小的包体积和更快的解析（asm.js 仍是 JS，需要解析为 AST）。
也有不同声音。部分开发者认为废弃 asm.js 是个错误：WebAssembly 与 JavaScript 之间隔离过深，无法直接调用大多数 Web API，更关键的是 JS 与 WASM 之间无法零拷贝传递缓冲区；asm.js 在运行时动态生成 JS 代码以加速算法的玩法将变得困难。还有评论提到 Chrome V8 团队当年没有专门优化 asm.js，而是改进通用 JIT，最终各家浏览器引擎在 JS 优化上趋同，asm.js 即便没有 OdinMonkey 也能跑得不错。有人呼吁开发 asm.js 到 WASM 的转译器，以应对老旧 Emscripten 代码难以重新构建的痛点。
13. 评论：Google 正在向开放 Web 宣战
博主 tante 撰文批评 Google 在 I/O 2026 主题演讲中进一步把搜索推向”给你处理好的答案”方向，AI Overviews 成为主入口，链接到信息源的传统范式被弱化。他认为这套包装在”AI”和”agentic”话术下的策略，实质是将信息去语境化：剥离链接与来源，用 LLM 生成的回答取而代之，从而在 Web 之上建立一个 Google 控制的抽象层。
文章的核心论点是，当 Zuckerberg 的 Metaverse 失败时，Google 正在发起下一轮攻击——网站、写作、艺术作品不再以文化产物的身份被分享，而沦为合成文本挤出机的免费原料；用户被引导进入 Google 控制和审核的封闭界面。作者预测下一步可能出现一个贬义词来标记原始 Web 为”不洁、危险”（类似”暗网”），而 Google 的抽象层则被塑造成”安全 Web”。由于 Google 对 Web 标准影响巨大，这会反过来改变 Web 技术基础。文章呼吁”去 Google 化”——更换搜索引擎、放弃 Chrome——否则将醒来发现自己置身一个被 LLM 化的 AOL 式信息环境。
HN 讨论分歧鲜明。支持方认同当下 AI 输出常常剽窃原内容却不导流，创作者只能为爱发电，“只有大公司还能从内容中赚钱”。反对方质疑这种叙事的一致性：当 Perplexity 做同样的事情时被视为颠覆 Google 的英雄，Google 自己做就成了对 Web 宣战，背后的原则差异不清。也有人指出 Web 早已被 SEO 垃圾、广告弹窗和订阅骚扰污染，Google 抛弃这种 Web 反而可能像 Usenet 当年那样带来某种净化。
商业逻辑层面，多位评论者困惑 Google 的终局：网站允许 Google 抓取是为了换取流量，如果 Google 完全切断回链，网站为何不直接屏蔽其爬虫？这种共生关系一旦破裂，Google 是否真的能维持索引质量？也有网站主反映 AI 概览带来的流量上升伴随事实错误被署上自己网站名的尴尬。还有人怀念 StumbleUpon，认为社区需要不被单一公司控制的新型流量分发机制。另一条线索是 Google 一方面大规模抓取他人内容，另一方面在 SerpApi 诉讼中坚决反对自身被抓取，被认为是双标。
14. 追踪星巴克”广泛可回收”塑料杯：无一进入回收设施
非营利组织 Beyond Plastics 进行了一项为期三个月的全国性调查：在 2026 年 1 月至 3 月间，将 53 个蓝牙追踪器放入星巴克的一次性聚丙烯（5 号塑料）冷饮杯，并投入分布于 9 个州及华盛顿特区共 35 家星巴克门店的店内回收箱。在返回有效数据的 36 个追踪器中，没有一个出现在真正的回收设施：16 个进入填埋场，9 个进入焚化设施，8 个止步于中转站，3 个到达只做分拣打包的物料回收设施（MRF）。最长一次旅程是 463 英里，从布鲁克林一家星巴克到俄亥俄州的填埋场。报告发布数小时后，星巴克删除了其”回收你的冷饮杯变得更容易”的宣传页面。
调查同时发现，原本计划覆盖 21 个州，但其中 11 个州的门店根本不提供回收，或明示纸杯塑料杯只送填埋。背景是 2026 年 2 月，星巴克联合 WM 等机构借助 How2Recycle 标签宣称聚丙烯已”广泛可回收”，覆盖 60% 以上美国家庭。但美国塑料整体回收率不足 6%，其中大部分是 PET 和 HDPE，聚丙烯在全美仅有寥寥数家商业化设施愿意接收，加上液体食物残渣污染（加州聚丙烯回收料平均污染率达 31%），实际再生几无可能。
HN 讨论对方法论争议很大。最高赞评论指出，蓝牙追踪器含 CR2032 电池，本身不可回收，会被回收设施的磁选或人工挑出，因此追踪器没进入回收线并不代表杯子没进入，“系统正按预期运作”。另有评论者翻阅原始数据，发现 36 个样本中 8 个来自纽约市单一城区、6 个来自奥林匹亚单一门店，样本集中度高；报告把所有中转站默认归为”通往填埋场”，但作者亲自去过其中一个中转站，其确实处理可回收物；报告把 3 个进入打包设施的样本直接排除在外，理由牵强；对 PureCycle 的化学回收一概不认为是”真正的回收”，也被认为缺乏中立性。
也有不少评论支持核心结论。多位用户分享亲身经历：本地星巴克设了垃圾与可回收两个分类桶，但晚上打烊时全部倒入同一个外部垃圾箱。聚丙烯回收在美国市政体系中确实极少，“可回收”作为标签更多是绿色洗白。另有讨论延伸到自带杯（10 美分折扣却鲜有人使用）、现代填埋场是否真的危害有限、市政对”过度回收”行为的反向警告，以及包装上印的回收承诺在欧洲根本没有对应服务网络等问题。
15. 用动画感受 LLM 的「N tokens/秒」到底有多快
- 原文: https://mikeveerman.github.io/tokenspeed/
- HN: https://news.ycombinator.com/item?id=48174920
- 得分: 264
- 评论: 67
作者 Mike Veerman 做了一个名为 tokenspeed 的网页小工具，用来直观呈现各种 tokens/秒（tok/s）速率下文字流出的视觉感受。它支持四种模式：代码（带语法高亮）、纯文本（lorem ipsum 散文）、思考（暗色斜体推理夹杂代码）以及 agent（工具调用与代码生成交替、含处理停顿），覆盖从 5 tok/s（树莓派级本地模型）、60 tok/s（典型托管的 Claude 或 GPT）、200 tok/s（Groq 级别）到 800 tok/s（Cerebras 级别，已经超出眼睛跟读能力）的速度区间。
作者强调，benchmark 数字虽然诚实，但同样的 tok/s 在不同内容下感受差异巨大：代码 token 密度高于英文散文（约 1.3 tokens/词），所以代码模式在相同速率下会显得更慢。该工具采用近似 BPE 的分词逻辑，而非任何特定厂商的 tokenizer。
HN 讨论中，Modal 团队成员介绍了类似的 Token Timing Simulator，并指出还可以加入输出延迟分布（log-normal 拟合 p50/p90/p99）来模拟真实 UI 中的 jitter。多位评论者补充，单一 tok/s 并不足以衡量体验，至少要区分 decoding（自回归生成）速度、prefill（提示处理）速度，以及二者随上下文长度增长的衰减斜率。有人举例：DGX Spark 上 DS4F 的 prefill 约 350 t/s、长上下文仍有 200 t/s，但 decoding 只有 13 t/s；Mac Ultra 则 prefill 400 t/s、decoding 35 t/s，体感差异巨大。还有讨论指出，推理模型常常消耗 2–3 倍乃至更多的 thinking tokens，工具调用约定、metadata 等「背景噪声」也会拉低有效输出速率。
一些评论分享主观体感：5 tok/s 虽比打字快，但作为 agent 已显得冰川般缓慢；而 Mimo、Minimax 等 100–150 tok/s 的速度反而快到难以跟上模型在做什么，更适合子 agent。有人将当下 GenAI 体验类比为「拨号上网时代」，也有人回忆在 Cerebras 上接入 opencode 时，几分钟就烧掉了 15 美元，提示高速度并不总等于好体验。
16. SpaceX 递交 S-1 招股书：Starlink 输血，xAI 巨亏，估值争议
SpaceX 于 2026 年 5 月 20 日向 SEC 递交 S-1 文件，准备以代码「SPCX」在 Nasdaq 与 Nasdaq Texas 上市发行 A 类普通股。公司采用双层股权结构：A 类 1 票/股，B 类 10 票/股，Elon Musk 通过 B 类股控股，公司将以「受控公司（controlled company）」身份豁免部分公司治理要求。注册地为德州 Starbase。
财务方面，HN 评论汇总的 2025 数据显示：营收 187 亿美元（2024 年 140 亿），运营亏损 26 亿，净亏损 49 亿，调整后 EBITDA 66 亿，经营现金流 68 亿，资本开支高达 207 亿。分部看，Starlink/连接业务营收 114 亿、运营利润 44 亿，是真正的现金奶牛；火箭发射业务营收 41 亿、运营亏损 6.57 亿；而合并进来的 xAI/X 业务营收 32 亿，却亏损 64 亿，且 2025 年 SpaceX 约 60% 的资本支出（约 200 亿美元）流向了 AI 部门。Starlink 订阅数从 2025 年底 890 万增至 2026 年 3 月的 1030 万，但 ARPU 从 2023 年 99 美元降至 2026 年一季度 66 美元。
招股书还披露一份与 Anthropic 的云服务协议：Anthropic 将在 COLOSSUS 和 COLOSSUS II 上租用算力，每月支付 12.5 亿美元、持续到 2029 年 5 月，单笔合同体量超过 Starlink 当前收入，成为 SpaceX 最大单一营收来源。公司给出的 TAM 高达 28.5 万亿美元，其中 AI 占 26.5 万亿（企业 AI 22 万亿）。文件中「rocket」出现 148 次，「AI」出现 773 次。
HN 评论几乎一边倒地质疑估值：火箭业务体量其实远小于市场想象（小于 Northrop、甚至小于 Avnet），公司被 X/Twitter 债务与 xAI 巨额亏损拖累，TAM 数字被认为「离谱」；也有人担心被动指数基金将不得不在万亿估值买入。少数评论肯定 Starlink 是真正盈利的好生意，并赞叹 SpaceX 把现金重新投入 R&D 的能力。整体观感被形容为「拥有一家成功咖啡店的 WeWork」。
17. Flipper One 技术规格曝光：RK3576 + RP2350 的 Linux 掌机
- 原文: https://docs.flipper.net/one/general/tech-specs
- HN: https://news.ycombinator.com/item?id=48212046
- 得分: 193
- 评论: 75
Flipper 官方文档公开了开发中的 Flipper One 技术规格。设备尺寸 155×67×40 mm，PC/ABS 外壳，配阳极氧化铝散热与支架、Gorilla Glass 屏幕和 TPU 缓冲。显示屏为 256×144 像素、6 位灰度（64 级）的单色 LCD，通过 QSPI 由 MCU 驱动，而非主 SoC。
核心由两颗芯片组成：主 CPU 为 Rockchip RK3576（4×Cortex-A72 + 4×Cortex-A53，最高 2.2 GHz，Mali G52 MC3 GPU，6 TOPS INT8 NPU）；低功耗 MCU 为 Raspberry Pi RP2350B（双 Cortex-M33 + 双 RISC-V Hazard3，150 MHz）。配备 8 GB LPDDR5、64 GB UFS 2.2 存储、MicroSD 槽，电池 24000 mWh / 7000 mAh，支持 USB-C PD 最高 26 V 充电。
接口异常丰富：2 个 USB-C 3.1（其中一个支持 DP Alt Mode 和 PD 充电）、1 个 USB-A 3.1、HDMI 2.1（4K@120Hz）、双千兆以太网（RJ45）、3.5mm TRRS 音频、Nano SIM、Wi-Fi 6（2.4/5/6 GHz，MediaTek MT7921AUN）+ 蓝牙 5.2、M.2 Key B 扩展槽（支持 PCIe 2.1×1/USB 3.1/SATA3/UART/I2C 等）。控制方面有触控板（带触觉反馈）、5 颗应用按钮、D-pad、Back、App Switcher 以及一颗 PTT 推话键。文档中多处标注「needs verification/clarification」，显示仍在打样阶段。
HN 评论焦点集中于「这不再是原来的 Flipper」：原 Flipper Zero 最受欢迎的 Sub-1GHz 无线、NFC、RFID、IR 等射频/SDR 能力，在新设备的规格里完全看不到，被视为定位重大转向。有评论惋惜没有 FPGA + SDR 收发器，期望它走软件定义无线电路线。也有人对双千兆以太网很感兴趣，设想用它做便携路由、VLAN/DHCP/PXE/802.1X 嗅探与 MITM 工具，或作为旅行路由器。对低分辨率单色屏配高端外壳的反差、AI 语音助手与 Flipper 原本「玩具化黑客工具」气质不符也颇有争议。还有用户回忆 Flipper Zero 大部分时间「躺在抽屉里」，担心 Flipper One 更像树莓派而失去原本的独特定位，以及对在过海关时被 TSA 盯上的顾虑。
18. 「不死也不活」：用离体人脑做药物测试引发的伦理震动
Science 报道了一种新的药物测试方法：研究人员在捐献者死后数小时内取出整颗人脑，放在台面上，通过管路持续灌注血液替代液和其他液体，提供氧气并带走代谢废物，以维持脑组织的细胞、蛋白和生理活动。在这种「介于生与死之间」的状态下，研究者对脑施加实验性药物，并通过传感器记录数百项细胞与生化指标，24 小时后将其切成上百片做进一步研究。为防止潜在的电活动，研究使用了较深的镇静药物。
这一做法被宣传为相比小鼠模型更接近人类生理、可能加速候选药物筛选，但其法律地位与伦理边界模糊：被实验的脑组织既不被认定为「活体」（无心跳、呼吸），也保留了相当程度的代谢与可能的电生理潜能。
HN 上的讨论几乎清一色聚焦在伦理层面。多名评论者表达了强烈不安，担心：在重度镇静下无法确认脑是否仍存在某种意识体验，一旦存在却无法看见、听见或表达，相当于在不可知地实施「无声的酷刑」；研究者用药物压制电活动，本身就暗示对意识残存的可能性并非 100% 排除。许多人质疑该研究如何通过伦理审查，并联想到《I Have No Mouth, and I Must Scream》《That Hideous Strength》等反乌托邦/科幻作品中的「容器中的脑」意象（包括 Alpha Centauri 中 Project PYRRHO 的台词）。
一些评论由此延伸到对器官捐献意愿的反思，有人表示将取消器官捐献勾选，担心遗体被用于此类实验。也有人从哲学层面指出，「alive」本身是一个粗糙概念，只在心跳、呼吸等钝器指标下有意义，越往细胞级别看越没有明确分界，直到完全无任何电、生化、机械活动才能称为「inert」。还有人提出方法论质疑：如果担心离体脑功能已经偏离正常，为何不直接使用活体灵长类模型来获得更可靠的数据。
19. Infomaniak 将多数投票权转让给瑞士公益基金会
瑞士云服务商 Infomaniak 宣布，创始人 Boris Siegenthaler 于 2026 年 5 月 13 日将公司多数投票权以不可撤销方式转让给新成立的「Infomaniak Foundation」——一家受日内瓦州政府监管、章程经公证的瑞士公益基金会。基金会持有 Infomaniak Group SA 的特殊类别股，享有永久否决权且永不可转让，使任何收购都必须获得基金会批准。Boris 与 36 名员工股东（共持 25% 股本）一致投票同意，相应削减自身投票权。公司目前没有任何外部投资人。
此前的方案是创始人每年向员工逐步转让股份，但存在两个隐患：员工股东集中离职时公司回购压力过大；创始人若意外离世，缺乏运营经验的继承人会立刻被投资人接洽。叠加 AI 浪潮加速、欧洲云厂商被收购、域外立法强化、地缘紧张等背景，公司选择用结构性安排锁定独立性。
基金会有两个角色：一是公益使命，资助数字主权与教育、伦理科技、环境与生物多样性、能源转型四个方向的独立项目（如 DebConf、42 Lausanne、Agent Green 等），资金来源为 Infomaniak 年利润的最高 5%；二是作为参考股东，不介入运营，仅在关键时刻通过「股东宪章」捍卫公司 DNA。该宪章包含九项原则（独立、数字主权、隐私、环境责任、有用且可负担的创新、透明、本地根基等），原则只可加强、不可削弱。隐私条款明确：客户数据归客户所有或在其专属控制下，AI 模型训练等附加用途必须默认关闭、需明确可撤销同意。基金会理事会由 4 名志愿成员组成，初期三年由 Boris 任主席。
HN 评论整体正面，多名用户分享了从 Gandi、OVH、Google、Mailfence 等迁移到 Infomaniak 的良好体验，尤其在邮件托管、DNS、DKIM/SPF/DMARC 自动诊断方面口碑较好；也有人指出其管理 UI 略显复杂、产品/定价层级（kSuite vs kSuite Pro）不清晰。批评意见集中在两点：其一，Infomaniak 的身份核验流程（通过 kCheck 要求护照/身份证+自拍，触发场景包括忘记密码、关闭 2FA、首笔票务收款等）与其隐私宣传存在张力；其二，对「结构能否守住理想」的怀疑——有评论指出，委员会式治理长期看会向商业压力均值回归，把意识形态外包给结构未必比留给可信创始人更稳。也有人将这种安排与 IKEA 创始人 Ingvar Kamprad 设立的基金会架构类比。
20. C 标准库里其实没有一种能正确解析整数的方法（2022）
作者 Habets 系统梳理了 C 标准库中常用的整数解析函数，得出结论：atol()、strtol()/strtoul()、sscanf() 在严格意义上几乎都不能正确完成「把字符串解析成完全一致的整数，并能检测错误」这件基本任务。
atol() 会把 123timmy 解析成 123，空串和 timmy 都返回 0，超过 LONG_MAX 的输入按 POSIX 是未定义行为，调用者无法得知任何错误，因此对不可信输入根本不可用，类似 gets() 一样属于「无法被正确使用」的 API。
strtol() 是少数可以正确使用的：通过预先把 errno 置零、检查 endp 是否指向字符串末尾、再判断 errno 是否为 ERANGE，可以同时识别空串、尾部垃圾和溢出。但作者强调使用方法需要相当小心。
strtoul()/strtoull() 则无法正确使用：标准规定遇到前导负号时返回「转换结果的取负，并以无符号方式表示」。这导致 -1 解析为 2^64-1，-2^64+2 解析为 2，-2^64+1 解析为 1，而 -2^64 才会以 ERANGE 报错——返回值无法区分合法大数、负 1、以及真正越界三种情况。作者建议测试本地实现：当输入全为空白字符时，strtol 是否能识别为错误，否则它也是坏的。
sscanf("%lu%n%c", ...) 看似简洁，但对负数和越界仍会给出无意义结果，例如 -2^64 被解析为 ULONG_MAX，与合法的最大值无法区分，同样不可靠。作者反驳「输入垃圾就活该得垃圾」的态度，指出这会让攻击者用 -18446744073709551615 之类的输入在 Python 与 C 之间获得不同符号，绕过 ACL 等校验。文末更新提到 C++17 的 std::from_chars() 是真正可用的方案。
HN 讨论里，许多人分享了类似经历：有教授整个学期的作业就是「读两个整数并相加」，测试集会向 stdin 灌入十亿个 9 来羞辱学生；有人 1983 年学 C 时第一份作业就是修复 string 函数。多名评论者展示了几十行手写解析（按字符乘 10 累加，并在乘加过程中检测溢出）就能解决问题，结论是「自己写一个比组合标准库更快、更短」。也有人推荐 OpenBSD 的 strtonum(3) 作为简洁正确的替代品，并提到 Rust str::parse 的实现思路。另一个常被提及的坑是某些函数把前导 0 当成八进制指示符，应该作为可选项而非默认行为。浮点解析则被普遍认为远比整数复杂，C++17 from_chars 的浮点部分直到近年才有开源实现真正写对。