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

HN 每日深度阅读 · 2026-04-21

本期在硬件可维修性、平台权力和 AI 文化冲突之间拉出一条清晰主线：欧盟电池法规、苹果交棒、GitHub 假星、AI 音乐与企业数据采集都关乎谁拥有真实控制权。表面是产品和政策新闻，底层其实是用户能不能保留选择。

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

共 20 篇 · 约 11,146 字 · 约 29 分钟读完

1. 欧盟强制要求：2027 年起所有在欧销售手机必须可更换电池

欧盟 2023 年通过的电池法规将于 2027 年 2 月 18 日正式生效：所有在欧盟境内销售的智能手机和平板电脑，其电池必须设计为用户无需专业工具或协助即可自行拆卸与更换。厂商还必须在产品停售后，至少继续提供五年的替换电池供应。该举措与此前强制 USB-C 充电口的规定一脉相承，目的是削减欧盟的电子垃圾，官方估算到 2030 年消费者可累计节省约 200 亿欧元。

目前主流手机电池都是一体化封装，只有专业维修点才能更换，高昂成本迫使许多用户在电池寿命衰减后直接换整机。新规生效后，用户将能像十年前那样自行购买并更换电池，延长设备寿命。

HN 讨论几乎一边倒地欢迎这项规则，但话题迅速分化为几条主线。第一条是对”可更换”定义的追问：条文要求不使用专用工具，但允许使用胶水——如果胶水在加热/溶剂下可以松动，是否就算合规？许多人担心厂商会打擦边球，做出名义上”可换”但实际仍然困难的设计。第二条是防水性能与可换电池的兼容性，评论区援引旧 Galaxy S5、现役 Fairphone 的例子，认为 IP68 与可拆后盖并非不可共存，只是厂商没有动力去做。第三条是对苹果的特别关注，许多人预测苹果会像当年 USB-C 那样，先抗拒后为全球统一转向可换电池。第四条是 Brussels Effect 的再次印证，欧盟单边立法实际上为全球市场定调。也有少数反对声音，担心可换电池会让机身变厚、牺牲无线充电线圈位置，以及二手电池假货泛滥。

2. Tim Cook 卸任苹果 CEO，John Ternus 接棒

苹果正式宣布高层交棒：Tim Cook 将转任执行董事长，硬件工程高级副总裁 John Ternus 接任 CEO。Cook 自 2011 年从 Steve Jobs 手中接过公司，任内把苹果从约 3500 亿美元市值推至全球最高市值公司之一。Ternus 是苹果内部成长起来的工程师，主导过多代 iPhone、iPad、M 系列芯片过渡期的硬件架构，外界长期将他视作接班人的头号候选。

HN 讨论的主基调是”意料之中”。许多人回顾 Cook 接手时外界的质疑——“只是个供应链运营官”——而最终他被证明是极其出色的 CEO，把苹果的运营杠杆和毛利率推到前所未有的水平，但也被批评在创新上保守，Vision Pro 被视为最大败笔。Ternus 被选中被解读为苹果明确押注”硬件工程公司”的身份，而不是走软件/服务路线——这与 Jeff Williams 或 Eddy Cue 等其他潜在候选人的取向形成对比。

争议点集中在几处：一是 Ternus 是否能处理苹果当前的 AI 困局，Apple Intelligence 被普遍认为落后于 OpenAI、Google、Anthropic，许多人怀疑工程背景的 CEO 会否比运营背景更擅长扭转这一局面；二是 App Store 反垄断诉讼、欧盟 DMA 合规等政治/法律议题，需要 CEO 花大量时间应对，这恰恰不是 Ternus 的强项；三是 Cook 的”执行董事长”头衔到底是荣誉虚职还是实权过渡期，有人引用比尔盖茨、拉里·佩奇等先例，认为这类安排往往持续数年且创始人/前任影响力仍在。也有讨论转向文化层面，认为苹果自 Jobs 去世以来丢失了”野心气质”，Ternus 能否把这股锐气找回来是真正的看点。

3. GitHub 的虚假 Star 经济

作者基于 CMU、NC State 和 Socket 合作的 ICSE 2026 论文，加上自己对 20 个仓库的独立抽样分析，系统描绘了 GitHub 虚假 Star 的产业链。论文工具 StarScout 扫描了 2019-2024 年 GitHub 上 326 亿 Star 事件，识别出约 600 万个虚假 Star，分布在 18617 个仓库、约 30.1 万个账户；其中 90.42% 被标记的仓库在 2025 年 1 月前已被 GitHub 删除，佐证了检测的准确性。AI/LLM 仓库是最大的非恶意虚假 Star 受益类别（17.7 万个），超过加密货币项目，且有 78 个被污染仓库成功登上过 GitHub Trending。

市场端完全公开。至少十几个网站（SocialPlug、Buy.fans、GitHubPromoter 等）直接挂牌卖 Star，Fiverr 上有 24 个活跃 Gig，价格分三档：一次性小号 0.03-0.10 美元/star，中档 0.20-0.50 美元，高端（多年老号、有贡献图）0.80-0.90 美元。Telegram 上甚至出售带五年 commit 历史、带 Arctic Code Vault 徽章的预制账号，每个约 5000 美元。作者自查的 20 个仓库里，有些项目 36%-76% 的 stargazer 零关注者，fork/star 比例远低于有机项目基准。

驱动力来自风投。Redpoint 数据显示种子轮项目中位 Star 数为 2850，多家机构跑自动爬虫抓”快速增长”的仓库作为 Sourcing 信号，把 Star 直接转化为估值。FTC 2024 年禁止伪造社交影响力指标的新规每次违规可罚 53088 美元，SEC 也已指控创业者在融资时夸大 traction。

HN 讨论几个热点：一是对 GitHub 本身是否真有动力清理的质疑，许多人认为 Star 是 GitHub 最核心的病毒传播机制，彻底净化等于伤害自己；二是对 VC 用 Star 做 Sourcing 的批评，被认为是把原本是”好奇心书签”的功能误解为”市场验证”；三是 AI 垃圾仓库泛滥的担忧，评论提到很多论文附带仓库代码质量很差但 Star 数畸高；四是防御建议，比如用 fork 数、contributor 多样性、issue 活跃度替代 Star 作为信号。

4. Kimi K2.6：推进开源编码模型的能力边界

月之暗面开源了新一代模型 Kimi K2.6，主打 SOTA 级编码能力、长跨度任务执行和 agent 集群协作。模型通过 Kimi.com、Kimi App、API 和 Kimi Code 同时开放。官方公布的 benchmark 覆盖 Humanity’s Last Exam、BrowseComp、Toolathlon、OSWorld-Verified、Terminal-Bench 2.0、SWE-Bench Pro、SWE-Multilingual、MathVision 等，在长跨度编码场景下相较 K2.5 有显著提升，且泛化到 Rust、Go、Python 等多语言。

博客展示两个长跨度案例。其一是在 Mac 上下载并部署 Qwen3.5-0.8B，用 Zig（小众语言）从头写推理代码，经过 4000+ 次工具调用、12 小时连续执行、14 轮迭代，吞吐量从 ~15 tokens/s 优化到 ~193 tokens/s，比 LM Studio 快约 20%。其二是对 8 年老项目 exchange-core（金融撮合引擎）进行自主重构，13 小时内迭代 12 种优化策略、1000+ 次工具调用、精确修改 4000+ 行代码，识别 CPU/内存瓶颈后重配核心线程拓扑（4ME+2RE→2ME+1RE），中位吞吐提升 185%，峰值吞吐提升 133%。

Baseten、Blackbox、CodeBuddy、Factory、Fireworks、Hermes、Kilo、Ollama、OpenCode 等多家企业 beta 用户给出正面证词，关键词集中在”长跨度稳定性”、“工具调用成功率 96.60%”、“代码生成准确率 +12%”、“长上下文稳定性 +18%”。

HN 讨论主要围绕几点：一是开源模型与闭源前沿（Claude Opus 4、GPT-5 等）的追赶速度，许多人认为 K2.6 和 Qwen 3.6 的发布日间隔之短表明中国实验室的发布节奏已经与美国前沿对齐；二是对 benchmark 的警惕，“Kimi Code Bench”是内部基准，评论员指出厂商自研 benchmark 容易过拟合，希望看到第三方复现；三是对 agent 集群（swarm）能力的兴趣，K2.6 首次把 swarm 作为一等公民推广；四是”12 小时跑 Zig 项目”这类演示在实际开发环境中是否具备经济性，大量工具调用意味着 token 成本不容忽视；五是开源许可证细节和本地部署硬件要求。

5. Qwen3.6-Max-Preview：更聪明、更锋利、仍在演进

阿里通义千问发布 Qwen3.6-Max-Preview，是 Qwen3.6-Plus 之后下一代专有模型的早期预览版。该版本并非开源，托管于阿里云 Model Studio，主打三项改进：更强的 agentic 编码能力、更扎实的世界知识、更可靠的指令遵循。相对 Qwen3.6-Plus，在 SkillsBench 提升 9.9、SciCode 提升 6.3、NL2Repo 提升 5.0、Terminal-Bench 2.0 提升 3.8，同时在 SuperGPQA（+2.3）、中文 QwenChineseBench（+5.3）、ToolcallFormatIFBench（+2.8）上也有增益。

官方称该模型在 SWE-bench Pro、Terminal-Bench 2.0、SkillsBench、QwenClawBench、QwenWebBench、SciCode 六大编码类基准拿到 top 分。调用方式兼容 OpenAI chat completions 协议，也提供 Anthropic 兼容接口。新特性 preserve_thinking 让推理 trace 可以跨轮保留，适合 agent 场景。

HN 讨论的焦点是”Qwen vs Kimi”的直接对比——两者几乎同一周发布，一个闭源但有 API，一个开源可自部署。评论普遍认为这是 2026 年中国前沿模型格局的缩影：阿里走云平台商业化路线，月之暗面走开源+托管双轨。一些评论指出 Max-Preview 的 benchmark 选型偏向自家”Qwen*Bench”，第三方评测还需要时间；另一些关注 agentic 编码在 IDE/CLI 工具链里的实测表现。也有讨论涉及 preserve_thinking 的工程意义，认为它是对 OpenAI o 系列”thinking token”问题的一种解法——不用重放思考，可以直接复用上一轮的推理。围绕地缘的讨论也存在，但相对克制，多数评论回归技术本身。

6. AI 抵制运动正在壮大：近期反 AI 动作盘点

原文因 Cloudflare 反爬墙抓取失败，仅能基于标题和 HN 讨论还原大意。作者 Steph Vee 梳理了近期值得讨论的”反 AI”现象，可能涵盖：艺术家和作家针对训练数据的集体诉讼、出版社与 AI 公司的授权谈判破裂、学校与大学对 AI 辅助写作的新一轮限制、设计师/摄影师对 Adobe/Getty 训练集的反弹、平台用户对”AI slop”内容的集体抵抗、工会（SAG-AFTRA、WGA）新一轮合约中的 AI 条款，以及消费者层面出现的”AI-free”品牌化（如 Proton、Kagi、DuckDuckGo 定位）。

HN 讨论分成明显的两派。支持派认为抵制是健康的社会反馈：AI 被部署速度远超监管和共识建立的速度，用户、创作者、劳动者有权通过拒绝、诉讼、抵制来拉回平衡；有人把它类比十九世纪的 Luddite 运动被历史污名化，实际上那是一场关于劳动议价权的政治运动而非反技术。怀疑派则认为”抵制”更像情绪化的姿态而非有效行动，多数 AI slop 的出现是供给侧问题，单靠消费者拒绝难以改变，最终还是要靠平台治理和法律。第三类讨论聚焦代际差异——年轻用户对 AI 习以为常，抵制运动的社会基础可能比作者想象的小。也有大量评论围绕”what counts as AI”：拼写检查、翻译、降噪这些旧 AI 没人抵制，现在被抵制的主要是生成式 AI 对创作与就业的直接冲击。

7. Deezer 披露：平台每日新上传曲目中 44% 由 AI 生成

法国流媒体平台 Deezer 周一公布数据：AI 生成曲目已占到每日新上传音乐的 44%，相当于每天约 7.5 万首、每月超过 200 万首。上传量呈指数增长——2025 年 1 月首次部署 AI 检测工具时每日约 1 万首，到 2025 年 9 月 3 万首、11 月 5 万首，到 2026 年 1 月已达 6 万首。不过实际播放端仍极小：AI 曲目仅贡献总流量的 1%-3%，而且其中 85% 被检测为”欺诈性播放”（用机器人刷播以套取版税）并被去货币化处理。

这组数据还原的是一个”上传侧被 AI 淹没、消费侧基本无感”的分裂图景。Deezer 是较早部署 AI 音乐检测的主流平台之一，对未标注的 AI 作品会自动识别，对涉嫌欺诈流量的作品会切断分成。公司将这种做法定位为保护艺术家版税池的必要手段。

HN 讨论焦点有几个：一是”44% 是否被低估”，评论员怀疑检测器存在假阴性，实际比例更高；二是版税经济学——当 Spotify/Apple Music 按照总流量切分固定蛋糕时，即使 AI 曲目只占 1-3% 播放，也会稀释真人艺术家的收入，欺诈性刷播更是直接偷钱；三是 AI 音乐的”审美塌缩”担忧，部分评论引用自己在 Lo-fi、冥想、白噪音歌单里已经基本听不到真人作品的体验，认为特定长尾场景已被 AI 全盘接管；四是平台治理的博弈——Deezer 主动披露数据可能是为监管谈判积累筹码，也可能是在为将来向 AI 曲目收取上传费做铺垫；五是 Spotify、Apple Music 为什么不公开类似数据，有人认为这三家在这一问题上的策略分歧会塑造未来几年的行业格局。

8. Atlassian 默认开启数据收集用于训练 AI

Atlassian 在其 Jira、Confluence 等产品中默认开启了一项新的数据收集设置，将用户内容用于训练其 AI 模型（Rovo 等）。该设置为 opt-out，用户必须自行进入管理后台才能关闭，且关闭入口分散在多处，许多企业管理员在公告之前并未意识到变更已生效。原文指出这一做法延续了 SaaS 行业近两年的普遍趋势——Slack、Zoom、Adobe、GitHub 都曾因类似”悄悄默认打开”的 AI 训练条款引发反弹。Atlassian 的特殊之处在于其产品承载了大量企业内部机密：工单描述、架构设计、事故复盘、财务流程、客户沟通记录，几乎等同于公司的”第二大脑”，一旦进入训练语料便无法撤回。

HN 讨论集中在三条线。其一是法律与合规层面：多名欧盟和加州用户质疑这是否违反 GDPR/CCPA 下的”明确同意”原则，尤其是工单中常出现 PII（客户邮箱、电话、病历号），企业管理员无权替第三方数据主体给出训练同意。其二是企业 IT 的被动处境：很多公司采购 Atlassian 时签的 DPA 并未覆盖”生成式 AI 训练”这一新增用途，合同存续期间单方变更被认为”技术上合法但道德可疑”。其三是对 Atlassian 产品力的普遍不满——评论者认为 Jira 本身近年性能、UX 都在退化，公司把工程资源押注在 AI 上而忽视核心体验，反而加剧用户流失。部分开发者推荐迁移到 Linear、Plane、YouTrack 作为替代。也有评论指出，这类”默认开”设置一旦被媒体放大，大型企业客户往往会在下一个续约周期要求合同级豁免，最终可能迫使 Atlassian 回退。

9. 桑拿对心率的影响

Terra 基于 256 名用户约 59,000 条每日健康数据，用配对 t 检验评估了桑拿当日的即时生理反应。结果显示：桑拿日的活动时间和距离更长，最大/平均心率更高（符合”运动后去桑拿”的常见模式），但夜间最低心率平均下降约 3 bpm（5%），即使控制了活动量之后这一效应依然显著（FDR 校正 p < 0.05，Cohen’s d > 0.2），提示桑拿本身带来了超出运动范畴的恢复信号，可能与副交感神经活动增强有关。性别维度上，女性在桑拿日的活动量增幅更大，但夜间心率下降幅度小于男性；进一步按月经周期拆分，只有黄体期的女性出现有意义的心率下降，卵泡期则无显著差异。作者认为这与已知的热应激生理学一致——高温使心率飙升、血管扩张，冷却阶段激活迷走神经主导的恢复过程。

HN 讨论分化明显。支持派引用 Laukkanen 在芬兰 20 年随访队列的经典研究，指出每周 4-7 次桑拿与全因死亡率、心血管死亡率、痴呆风险显著降低相关，认为 Terra 的短期信号与长期流行病学证据方向一致。怀疑派则强调多重混杂：桑拿用户本身就是”健康用户偏差”的典型群体——更自律、更有闲暇、更富裕、更常运动，n=256 的可穿戴数据无法剥离这些。方法学细节也被挑刺：Terra 没有公布桑拿时长、温度、是否冷水浴交替，这些都会显著改变心血管反应；3 bpm 的静息心率下降虽然统计显著，但临床意义有限。还有热议分支讨论红外桑拿与传统芬兰桑拿的差异、心脏病患者的禁忌、脱水与电解质风险，以及桑拿前后饮酒带来的急性心律失常案例。一个高赞评论总结：“证据足以让已经喜欢桑拿的人继续去，不足以说服不喜欢的人开始去。“

10. F-35 是一件为错误战争打造的杰作

War on the Rocks 这篇长文用小提琴做比喻：F-35 是大师级乐器，精密、优越，但无法快速廉价复制，美国却试图用这种乐器武装整个管弦乐队。全生命周期成本预计超过 2 万亿美元，是史上最昂贵的国防采办项目。作者承认 F-35 在刚结束的 12 天对伊战争中表现卓越——隐身突防、压制防空、传感器融合为指挥官提供战场统一图像——但强调对伊战争是短期、计划周密、从安全基地出击、针对被预先削弱的固定目标的战役，不能作为高烈度对华冲突的样本。

文章核心论点有两条：其一是物理问题。西太平洋所有美军机场都在解放军导弹射程内，兵棋推演一致表明大多数战机损失发生在地面而非空中。主动防御难以拦截中国可生成的饱和齐射，被动防御（加固机堡、分散停放、跑道快速修复、诱饵）在大部分战区仍不足。即便在已被削弱的伊朗防空网中，3 月 19 日一架 F-35A 仍被疑似路基机动防空系统击中后紧急迫降；中国完整的多层防空体量与伊朗不在一个量级。其二是可持续性问题。F-35 依赖庞大地面保障链——诊断系统、备件库、燃料弹药、高技能维护人员。击毁一个备件仓库或后勤服务器对出动率的打击不亚于击毁飞机本身。分散部署是自然反应，但它拉长了已经脆弱的供应链、碎片化维护能力、并让战机远离目标，迫使依赖昂贵且产能有限的远程武器（LRASM 等）和易损的空中加油机。

作者的政策建议是”平衡兵力”：保留 F-35 执行只有它能完成的任务，但把更多采办预算转向可批量生产、可承受损失的无人系统。HN 讨论主要围绕三点展开：一是该文并非反对 F-35，而是反对把它当作空军主力的结构性选择，很多评论认为媒体标题党化后失真；二是对乌克兰战争”无人机海”经验能否套用到台海存在分歧——支持方指出跨海作战距离远、电子战环境复杂，小型 FPV 无人机难以直接复制；反方则举例 Shahed-136 级别的远程攻击型无人机已经在红海和乌克兰证明了价值。三是产能讨论：美国每年产约 150 架 F-35，而解放军装备的 PL-15/东风系列导弹年产数以千计，数量差被普遍认为是结构性的、难以通过提高 F-35 产能解决。

11. ggsql：面向 SQL 的图形语法

Posit（前 RStudio）发布了 ggsql 的 alpha 版本，把 R 生态里广受欢迎的 ggplot2 “图形语法”（Grammar of Graphics）思路直接搬到 SQL 数据库内执行。核心想法是：不再把数据拉到客户端再绘图，而是用声明式的图层/美学映射/统计变换表达式编译成 SQL，在数据库端完成聚合、分箱、平滑等计算，只把最终绘图所需的小结果集返回前端。这对 BI 场景尤其有意义——一张堆积柱状图或 2D 密度图可能对应数十亿行底表，客户端内存无法承受，但数据库完全可以在几秒内返回已聚合好的几百行结果。ggsql 通过 DuckDB、Postgres、Snowflake、BigQuery 等多方言后端适配，图层 API 与 ggplot2 保持一致（geom_、stat_、facet_、scale_），R 和 Python 绑定都在计划中。

HN 讨论整体正面。数据分析师赞赏这种”把可视化意图编译成查询”的方向，认为比 Superset/Metabase 那种拖拽式 UI 更适合严肃分析工作流，且比客户端 Vega-Lite 在大数据场景有本质优势。技术讨论集中在两点：一是 DuckDB 的崛起是否让这类”推计算到存储”的工具更具吸引力——多人提到 DuckDB + Arrow 的本地分析栈已经能覆盖大部分中等规模用例，ggsql 正好填补”声明式 viz”这一层。二是与现有方案对比：有人指出 Observable Plot、Vega-Lite、plotnine 也能做类似事情，ggsql 的差异化在于严格保持 ggplot2 API 语义并在 SQL 侧做计算下推。另一个讨论分支是关于 Posit 的长期开源承诺——作为 tidyverse 的守护者，它推出 ggsql 被视为对 Python/SQL 生态的正面进攻，有评论认为这可能是 Posit 在 Snowflake/Databricks 生态里找差异化定位的关键一步。负面意见主要是 alpha 阶段的功能缺失（缺少 geom_smooth 的 LOESS 下推、facet 跨库行为不统一）和方言覆盖不全。

12. Firefox 的 WebUSB 扩展（awawausb）

ArcaneNibble 发布了 awawausb——一个用 Rust + WebExtensions 为 Firefox 添加 WebUSB 能力的实验性扩展。Firefox 多年来一直明确拒绝在浏览器内实现 WebUSB（Mozilla 在官方 standards-positions 中把它列为”harmful”，理由是安全模型不足、指纹面风险、以及 USB 设备本身的复杂攻击面）。awawausb 绕过这一官方立场，通过 native messaging host 把浏览器页面的 USB 请求转发到本机原生进程，由后者调用 libusb，再把结果回传给网页，对 Web 端暴露一个与 Chromium WebUSB API 基本兼容的接口。作者坦率地把它定位为”给必须用 Firefox 又需要 WebUSB 的人的一个拐杖”，典型场景包括硬件钱包（Ledger/Trezor）、键盘配置工具（VIA/QMK）、烧录器、示波器 Web 前端等。

HN 讨论基本分为两派。支持派强调”用户应该有选择权”：Chromium 已经把 WebUSB 事实标准化，Firefox 的缺席让硬件厂商越来越把 Firefox 用户排除在外，第三方扩展填补空白是健康的生态补救。也有人借此批评 Mozilla 近年的策略摇摆——在 Manifest V3、WebSerial、WebHID、WebBluetooth 上都走保守路线，市场份额下滑与此不无关系。反对派则重申 Mozilla 的安全论点：WebUSB 允许网页在获得一次用户授权后与任意 USB 设备对话，而 USB 驱动栈历来是内核攻击面富矿，钓鱼页面诱导点击一次”允许”就可能 flash 固件或提取私钥；Chromium 虽然有设备 blocklist，但维护滞后、绕过方法频出。技术讨论部分涉及 native host 的权限模型、如何在 Linux 上处理 udev 规则、macOS 上的 code signing 要求，以及作者选择 “awawa” 这种戏谑命名是否影响严肃采用。也有评论者担心扩展一旦流行，Mozilla 可能以安全为由在 AMO 下架，从而把它推向侧载分发。

13. 日本宫古东北东 100 公里处 7.4 级地震

USGS 事件页记录 2026 年 4 月 20 日 07:53 UTC（日本时间 16:53）在岩手县宫古市东北东约 100 公里近海、北纬 39.953°、东经 143.046°、深度 35 公里处发生一次矩震级 Mww 7.4 地震。ShakeMap 和 Did You Feel It 社区数据均给出修正麦加利烈度 VI（强感），PAGER 经济与人员损失警报为绿色（预计损失与伤亡较小）。震源机制解显示为日本海沟俯冲带特征的逆冲破裂，Finite Fault 给出的滑动分布集中于浅部、走向与海沟平行。日本气象厅随后发布了针对岩手、宫城沿岸的海啸注意报，部分港口观测到数十厘米级海啸波，稍后解除；福岛第一、第二核电站未报告异常。

HN 讨论体现出 HN 社区在地震话题上的一贯风格：半科普、半人文。技术分支集中在三个问题上。一是为何 M7.4 在日本这种高设防强度国家只产生轻微损失——评论者引用日本的建筑抗震规范、海啸防潮堤、J-Alert 预警系统，以及 2011 东日本大震灾之后的基础设施升级，认为这是”规范真的有用”的活教材。二是震源深度 35 km 带来的影响，浅源逆冲在板块界面属于海啸型，但这次矩不足以引发破坏性越洋海啸，夏威夷、美国西海岸未发警报。三是 USGS ComCat 与日本 JMA 的参数微差（JMA 早期报 M7.1、后修正 M7.3），用户讨论了不同震级尺度（Mj、Mw、Mww）的算法差异。人文分支则是大量日本本地 HN 用户分享亲身体感——东京有人感到长周期摇晃持续一分多钟，岩手/宫城居民触发手机紧急地震速报；也有评论担心类似地震对正在运转的仙台以北新干线和福岛核事故废水/核素清理工作的影响。

14. 10 年前有人给 Servo 写了一个 2026 年到期的测试

Servo 项目的老维护者 Josh Matthews (@jdm_) 在 Mastodon 上发帖：10 年前——彼时 Servo 才成立 3 年——有人为 cookie 解析测试硬编码了一个 2026 年 4 月 18 日的过期时间，当时看来遥远得足以”永远不会到”。结果 Servo 活到了 2026 年，测试在这一天集体失败，CI 全红，直到维护者合入 PR #44341 把过期日期改到一个世纪之后才恢复。PR 标题本身就自带苦笑：“Update test cookie expiration dates to one century in the future.”

HN 和 Mastodon 的讨论迅速演变成一场程序员的集体回忆大会，话题是”代码里那些写死的’不可能到的未来日期’“。经典案例包括：Y2K 不用多说；2038 年 1 月 19 日 03:14:07 UTC 的 Unix 32 位时间戳溢出（embedded 世界仍在踩坑）；MS-DOS FAT 文件系统 2107 年边界；iOS 早期 NSDate 的 2040 问题；各种 10 年有效期 TLS 证书到期导致的大规模瘫痪事件（Ericsson 2018 年全球 O2 断网、GitHub Pages、Let’s Encrypt 根证书切换）；Fastly、Cloudflare 证书过期故障；私有 CA 默认 10 年有效期毁掉 VPN/内部服务。评论者戏称这类 bug 为”时间地雷”（time bombs），讨论了几种防御实践：用测试框架提供的时间 mock（Ruby 的 timecop、Python 的 freezegun、Rust 的 mock_instant）代替真实墙上时钟；把过期日期设为 9999 年、或直接使用 chrono::DateTime::MAX；CI 层面增加”time-travel”任务定期把时钟前进 1/5/10 年运行测试发现潜伏炸弹。也有人借此反思 Servo 项目本身的韧性——一个被 Mozilla 放弃、又由 Linux 基金会接手复活的项目，能活到让 10 年前的测试到期，本身就是一种行业奇迹。

15. 布鲁塞尔发布年龄核验 App，黑客称两分钟就能破解

欧盟委员会主席冯德莱恩本周在布鲁塞尔高调发布了一款用于网上年龄核验的移动 App，声称代码”技术上已经就绪”、将配合各成员国禁止未成年人使用社交媒体和色情网站的政策落地。该 App 由瑞典身份认证公司 Scytáles 与德国电信联合中标（€4M 招标），设计上依托 eIDAS/EUDI 数字钱包框架，用户通过护照、身份证或银行等可信来源登记，随后网站只能查询”是否已满某年龄”，采用所谓”零知识证明”来保护隐私。

然而 App 开源仅几小时，就被多位欧洲安全研究员翻了底。英国安全顾问 Paul Moore 发推称在不到 2 分钟内攻破，指出 App 将敏感数据以不受保护的形式存储在本地。法国白帽 Baptiste Robert 向 POLITICO 证实可绕过生物识别环节（跳过 PIN 与 Touch ID）。法国数字身份工作组成员、密码学研究员 Olivier Blazy 给出了更具破坏力的场景：“下载完 App、证明我自己已满 18 岁之后，我侄子拿着我解锁的手机，就能用它证明他也已满 18 岁。“超过 400 名专家此前已致公开信，要求在科学共识形成前暂停部署。

欧委会回应称被测试的是”早期 demo 版本”、漏洞”已修复”；但 Moore 和 Blazy 均表示他们测试的正是 GitHub 上最新代码。发言人 Thomas Regnier 更是自相矛盾地说”最终版本”其实”仍然是 demo 版本”。捷克海盗党议员 Gregorová、德国社民党议员 Sippel 以及波兰 ECR 议员 Müller 同声批评，称其为”被政治压力仓促推行的半成品”，甚至将其与”中国式互联网”相提并论。

HN 的讨论分为几条主线。第一条是标题争议：发布的其实是”上线前的源码”而非已上架 App。第二条是针对 Blazy 的”侄子借用手机”场景的激烈辩论——一部分人认为 App 根本无法防住父母与子女共享设备这种现实情境，另一部分人则认为这恰恰暴露了整个”线上强制验龄”政策的荒诞：需求在短时间内全球同步冒出，本身就可疑。第三条是对”零知识证明 = 匿名”的质疑。多位评论者指出 App 并非真正 ZKP：要么把身份中心化存储到政府数据库成为单点攻击目标，要么与防止凭证外借互相冲突，“只能二选一”。也有评论区分 eIDAS/EUDI 电子身份（已经在多个成员国落地并用于登录网银）与新增的 age verification 用例——前者是成熟方案，后者才是这次被喷的政治工程。整体风向是对 EU 这套 PR 先于工程的做法相当失望。

16. RTX 3090 上跑 Qwen3.5-27B 达到 207 tok/s 的 Lucebox 项目

Lucebox 是一个把 LLM 推理按芯片型号”手调”的开源项目，首批公布两个成果，全部围绕 2020 年的 RTX 3090。第一个是 Megakernel：把 Qwen3.5-0.8B 的全部 24 层融合进单个 CUDA dispatch，通过 82 blocks/512 threads 的持久化 kernel 与 cooperative grid sync，取代了每 token 约 100 次 kernel launch 的传统流程，权重直接从 HuggingFace 流式读取，配合 220W 功耗上限跑到 1.87 tok/J、37,800 tok/s 总吞吐，作者声称在能效比上与 Apple 最新芯片持平、吞吐量则是其 2 倍。

真正抢眼的是第二个项目 DFlash DDTree：在单卡 RTX 3090 上对 Qwen3.5-27B Q4_K_M 做 speculative decoding，draft 模型用 BF16 版 DFlash，tree budget=22。峰值 207.6 tok/s（对比自回归 38.0 tok/s，5.46×），HumanEval 10-prompt 基准均值 129.5 tok/s（3.43× 于 AR，2.8× 于 SGLang AWQ 的公开最好成绩），并能在 24GB 显存里跑 128K 上下文（ctx=131072 时 134.78 tok/s）。作者强调这是”首个把 DFlash 移植到 GGUF target 的实现”——因为 AWQ INT4 加 BF16 draft 在 24GB 卡上塞不下 DDTree 验证状态，Q4_K_M GGUF 约 16GB 成了唯一可行的 target 格式，为此他们基于 ggml 新写了三个 tree-aware SSM 状态回滚的自定义 CUDA kernel（ggml_ssm_conv_tree 等）。项目哲学写得很直白：过去十年通用框架之所以主导，是因为”为每颗芯片手调 kernel 过于昂贵”，AI 编码助手改变了这个算式——原本一季度的改写现在一个迭代周期就能完成，于是可以”一次只面向一颗芯片、一个模型家族”地重写。

HN 的反应褒贬参半。作者本人在评论区 TL;DR 了数据，指出当前实现仅支持贪婪采样（greedy）、仅单卡，被问到”为什么不上 Vulkan/ROCm 让非 CUDA 用户也能跑”以及”greedy 是否会让投机解码的接受率变差”。一条高赞留言直接泼冷水，说这是”vibecoded 的研究 demo 叠加牺牲质量换速度的优化，207 tok/s 只出现在标题里，HumanEval 均值才是真正该看的数字”，并指出 Qwen3.5-27B 在 Vulkan、MLX、OpenVINO、ROCm 上早就能跑，Apple 凭统一内存反而在自部署市场更有优势；Nvidia 并非唯一选项。也有评论指出疑似有 AI 生成的回复混进讨论。正反双方共识大致是：数字亮眼但要打折看，“为一颗具体芯片手搓”这条路线值得关注，只是这个仓库的商业化与跨平台故事还远没讲完。

17. 量子计算机对 128 位对称密钥并不构成威胁

密码学家 Filippo Valsorda 撰文反驳一个在 IT 圈广泛流传的误解：“量子计算会把对称密钥安全性减半，所以 AES-128 必须换成 AES-256”。他的结论非常直接：AES-128、SHA-256 在后量子时代仍然安全，对称算法的密钥长度无需变化，这也是 NIST 与主流标准化机构的共识。

误解的根源是 Grover 算法。Grover 确实能让一个规模 N 的无结构搜索在 π/4·√N 次调用内找到答案，表面上把 AES-128 的暴力破解从 2^128 降到 2^64。问题在于 Grover 有三条硬约束：oracle 必须作为量子电路的一部分实现、oracle 调用必须严格串行、而且除了”把搜索空间切分给多台独立的量子计算机”外不存在更好的并行方式（Zalka 1997）。而分割搜索空间会破坏二次加速——把 2^16 台机器并行时，每台节省的 work 只是 √(2^16)=2^8，而不是经典并行里的全部 2^16 倍。结果系统总 work 反而从 2^64 升到 2^72。

接着作者代入具体数字。假设超导量子架构 1µs 一个门，连续运行十年约能做 2^48 次门操作；Liao & Luo 2025 给出的最优化 AES-128 Grover oracle 深度 232 T-gates、宽度 724 qubits。解方程得需要约 140 万亿（10^14）个各自含 724 逻辑 qubit 的量子电路、并行运行十年才能打破 AES-128；深度×宽度（DW cost）约 2^104.5。对比 Babbush 等 2026 关于 256 位椭圆曲线上 Shor 的最新估计（约 70M 门、10µs gate time 下分钟级可完成），攻击 AES-128 的成本比打破 256 位 ECC 高 4.3×10^23 倍。而且 Shor 这些年估算一路下降，Grover 针对 AES 的公式里几乎没有继续压缩的空间——Liao&Luo 比 2015 年最早估计只抠出 7.5 bit，比 2019 年已经优化过的版本只抠出 1.5 bit。

作者最后点名 NIST：SP 800-57 等文件中对 AES-128 的有效安全位数仍然按 128 bit 计，没有任何合规要求强制切到 256 位。他担心的是有限的 PQ 迁移精力被错配到”无谓地升级对称算法”上，挤占真正紧迫的非对称密钥替换（ECDH、RSA、ECDSA）工作。

HN 讨论集中在三点。一是措辞分歧：文章把哈希与对称密钥并列讨论令部分读者不适；作者亲自澄清 HMAC/HKDF 这类哈希构造可定义”密钥长度”、Grover 适用方式与对称加密类似。二是 WPA3 的吐槽——有人说 WPA3 从 PSK 切到 ECDH 会导致大量 IoT 设备在 PQ 时代报废；更精确的回复指出 WPA3 仍以 AES CCMP/GCMP 为底层分组密码，ECDH 只出现在密钥交换环节，而且 2018 年标准化时 ML-KEM 根本还没出来，苛责并不合理。三是实践层的”激进轮换”思路：一位读者分享他们与银行对接 OAuth M2M 时让 ECDSA 密钥每 5 分钟轮换、10 分钟删除，并讨论将窗口压到 30–60 秒的可行性，作为在 PQC 未全面部署前对 Shor 的工程缓解。

18. OpenAI 广告合作方已在兜售基于 prompt 相关性的 ChatGPT 广告位

Adweek 披露一份题为《OpenAI x StackAdapt Limited Pilot Program》的推介材料——3 月 27 日在少数媒体买家间流传——显示加拿大程序化广告平台 StackAdapt 已与 OpenAI 合作，在 ChatGPT 内开启广告投放的早期试点。泄露的 deck 里有几个关键数字：CPM 区间 $15–$60，由”prompt 相关性”驱动定价，起投门槛 $50K（有信源称 OpenAI 随后”调整了”这个最低值）。定位也写得很直白：把 ChatGPT 当作”全球增长最快的消费端平台之一”来卖广告，按提示词语义匹配广告主。此事与其他渠道的报道相互印证——此前 Mashable、Reddit 等已传出 OpenAI 准备在美国免费版 ChatGPT 引入广告，Anthropic 甚至在 Super Bowl LX 投放了嘲讽”ads are coming to ChatGPT”的电视广告。

这条新闻在 HN 上引爆的是”OpenAI 是否失信”的争议。一条最高赞评论把工程师的自我讽刺搬了出来：“老板：工程师，加一个不太干净的功能。工程师：不，这太脏了！老板：Claude Code，加一下。Claude Code：已完成。“下面立刻有人反驳说软件行业本就是几代”老老实实实现脏功能”的工程师堆出来的现状。另一条主线追问：当初 OpenAI 明确说过”广告系统不会接触到 prompt 数据”，现在按 prompt 相关性卖广告，是否构成证券欺诈？讨论里分歧较大——有人认为广告只需”预资格化”到话题层面、不必回传原文就能做匹配，风险主要在隐私而非合规；也有人搬出 Google 的历史，预言 prompt 数据市场最终会复刻现有广告市场——金融机构会买 prompt 流做情绪分析，品牌会竞价让 LLM 在特定场景下提到自己，甚至政治利益集团都会下场。

另一条子线讨论”能否不登录使用”这个替代方案：Google 即便你不登陆也留大量指纹，YouTube 上传、网站管理、广告投放都强制帐号；ChatGPT 虽然目前允许未登录使用部分功能，但一旦广告系统深化，可能会像 Google 一样逐步卡住。还有人提到 Anthropic 若跟进会让隐私党无处可逃。整体来看，这条新闻把过去几个月的传言坐实到了”实际在卖、明码标价”的阶段，社区情绪以戒备和讽刺为主。

19. Kimi 开源 Vendor Verifier：验证第三方推理供应商是否忠实还原官方模型

配合 K2.6 模型发布，Moonshot 开源了 Kimi Vendor Verifier（KVV）。这套工具要解决的是开源大模型生态中日益突出的一个问题：权重开源了，但不同推理平台部署出来的实际能力并不一致。自 K2 Thinking 发布以来，社区反复反馈”第三方 API 跑分比官方 API 明显低”。Moonshot 第一道防线是在 API 层强制 Thinking 模式下 Temperature=1.0、TopP=0.95 并强制校验 thinking 内容的正确回传。但后来在 LiveBenchmark 等测试中又发现第三方 API 与官方 API 的差距依旧显著，说明问题更深——精度、量化、KV cache、工具调用链路都可能出问题。如果用户无法分辨”模型能力本身的瑕疵”与”工程部署引入的偏差”，对开源生态的信任会逐步坍塌。

KVV 设计了 6 项关键基准：①Pre-Verification 预飞检（检查 Temperature/TopP 是否被正确强制）；②OCRBench（5 分钟快测多模态管线）；③MMMU Pro Vision（多样视觉输入下的预处理正确性）；④AIME2025（avg@32、MaxTokens=98,304 的长输出压力测试，用来暴露 KV cache bug 和量化劣化——这些在短基准上看不出来）；⑤K2VV ToolCall（工具触发一致性 F1 与 JSON Schema 准确率，抓取 agent 链式误差）；⑥SWE-Bench 完整 agentic 编码测试（未开源，因需沙箱依赖）。官方给出的参考分数包括 OCRBench 91.0、AIME2025 98.4、MMMU Pro Vision 78.8。Moonshot 还承诺将与 vLLM/SGLang/KTransformers 社区合作修根因、为供应商提供模型预发布访问权做 pre-release validation、维护一个公开的 vendor 排行榜作为持续施压。在 2×H20 8-GPU 服务器上完整跑完约需 15 小时，脚本支持流式推理、自动重试与断点续传。

HN 讨论不多但切中要害。第一类声音赞许这个方向：“推理供应商常悄悄换量化等级，多数用户不会验。由模型作者直接发一套 verifier 是正解，希望其他 lab 跟进。“也有评论认为 Anthropic 之后 Moonshot 是又一家限制采样参数的 vendor，不是所有人都乐见。第二类声音质疑威胁模型：KVV 能抓的是”无意的精度漂移”，但对于刻意作恶的供应商——比如用一个模型验证部署、给真实用户换成更便宜的模型——这类 benchmark 并不能覆盖。有人把这种中间态概括为”从’我们只是不透明地在量化’升级成’我们是在故意用不同部署欺骗用户’，后者至少在法律上更清晰、更接近欺诈”。第三类是运营可行性：15 小时的跑分无法高频重复，但可以一次性覆盖全部、后续按 2–4 周滚动覆盖部分基准以模拟真实使用曲线，把它当成 CI 里的回归测试来对待就够用了。

20. Kefir：独立实现的 C17/C23 编译器

Kefir 是 Jevgenij Protopopov 一个人开发的 C 编译器，目标是完整、合规地实现 C17 与 C23 标准。项目已在 100 个真实开源软件的测试套件上完成验证，包括 GNU coreutils、binutils、curl、nginx、OpenSSL、Perl、PostgreSQL、Tcl 等。它面向 x86_64 与 System-V AMD64 ABI，主目标是 Linux（glibc 与 musl 都支持），次级目标为 FreeBSD/NetBSD/OpenBSD/DragonflyBSD。

技术栈看点集中在以下几条。语言覆盖：C17 的 complex、imaginary、atomics、VLA 全部实现；C23 的 bit-precise integer 与 _Decimal 浮点（后者依赖 libgcc）也在内；此外还吃下一部分 GNU C built-ins、inline assembly 与 128-bit 整数。实现本身用 C11 写成，运行时仅依赖标准库、部分 POSIX 与 shell。优化方面是完整的 SSA 流水线——两道 SSA pass，做局部标量提升到寄存器、死代码消除、常量折叠、全局值编号、循环不变量外提、函数内联、尾调用优化，以及保守的全局内存访问优化与目标相关优化。代码生成方面支持 DWARF5 调试信息、PIC、AT&T 与 Intel 两种 GNU as 语法、对 Yasm 有限支持，并具备 bit-identical bootstrap——在固定环境下 Kefir 能逐位重现自己的二进制，便于可复现构建审计。命令行兼容 cc，可输出 token/AST/IR 的 JSON 表示，并附带可审计日志。许可证 compiler 为 GPLv3-only、runtime includes 为 BSD-3。作者诚恳提醒：项目由单人无资助、业余维护，不建议用于生产；“Kefir”之名取自发酵奶饮料，“无任何别的言下之意”。

HN 上的 5 条讨论虽少但正面。主导看法是”由一个人完成到这种完成度，了不起”、“测试套件的覆盖面本身已经相当惊人”。另一条评论点出文档上的改进空间：项目主页缺少一段”与主流编译器相比动机何在、下一步去哪、潜在应用场景是什么”的明确叙述，希望作者能专门写一段。随后有人补充，作者其实在页面的 #goals-and-priorities 与 #history-and-future-plans 两个锚点里回答了这些问题，只是不够显眼。整体氛围更接近”为一个长线 hobby 项目鼓掌”，而非技术路线层面的争论。