HN 每日深度阅读 · 2026-07-28
本期主线聚焦"用工程手段重塑既有系统"：Kimi-K3 及其知识图谱训练管线、Bun 的 Rust 重写、微软安全模型、Go 新 GC、HTMX 替代 React、HMTP 邮件构想等展示了对底层重构的执念；PGSimCity、Colossus 里程碑。
共 20 篇 · 约 12,638 字 · 约 32 分钟读完
1. Moonshot 发布开源大模型 Kimi-K3
- 原文: https://huggingface.co/moonshotai/Kimi-K3
- HN: https://news.ycombinator.com/item?id=49065752
- 得分: 1300
- 评论: 510
Moonshot AI 在 HuggingFace 上发布了 Kimi-K3，一款约 3T 参数、原生采用 mxfp4 量化的开源权重大模型。由于模型体积巨大，托管约需 1.5TB 显存，接近 8 张 B200 的极限，实际部署（考虑上下文与吞吐优化）可能需要 16 张。第三方推理服务已上线，例如 Fireworks 定价为输入 3 美元 / 百万 token、输出 15 美元 / 百万 token。
许可证附带典型的规模条款：如被许可方或其关联方运营 Model as a Service 业务，且连续 12 个月总收入超过 2000 万美元，需与 Moonshot AI 另行签署商业协议。
HN 社区讨论集中在几个方向。首先是定价与经济学：GLM 5.2 发布后一个半月内价格下降约 45%，评论者据此推测 Kimi-K3 的第三方价格也会持续下探，甚至可能有服务商在电费加折旧成本以下出售 token。但也有反对意见认为，从实测看 Kimi 定价已相对贴近成本，未必会出现 GLM 那种大幅折扣。其次是主权与定制价值：不少人认为最大亮点并非价格，而是任何创业公司都可下载权重、微调并保留 IP 与数据主权。第三是硬件形态问题：目前个人可用硬件要么是慢速的统一内存方案，要么是耗电上千瓦的数据中心卡，缺少 180–250W、128–256GB 显存的”消费级专业卡”。此外有评论者自嘲，直接询问模型”介绍你自己”，得到的回复却是”我是 Anthropic 制作的 Claude”，显示训练数据中混入了大量竞品输出。也有人呼吁社区通过下载、做种保存这些前沿开源模型，以对抗未来可能出现的监管收紧。安全评测方面，AISI 网络安全基准显示其略优于 GLM 5.2，但仍显著落后于闭源 SOTA 模型。
2. PGSimCity：用 3D 城市模拟 PostgreSQL 内部机制
- 原文: https://nikolays.github.io/PGSimCity/
- HN: https://news.ycombinator.com/item?id=49063754
- 得分: 881
- 评论: 86
PGSimCity 是一个独立的非商业教学可视化项目，用类似 SimCity 的 3D 城市隐喻展示 PostgreSQL 引擎的内部工作方式——各种进程、调度、缓冲区、会话等被表现为建筑、管道和信号灯。作者明确标注这是”早期未审阅原型”，可能包含模型和解释上的不准确之处，欢迎通过 GitHub issue 或 PR 反馈。
HN 上的反响呈现两极。一方面，许多评论者称赞概念本身极具吸引力：把复杂的数据库调度用直观的城市场景呈现，很有潜力，作者鼓励这种范式扩展到 Kubernetes、云计算等其他领域。有人联想到在 VR 里调试程序，或类似”Beam VM 版 Doom”这样把运行时可视化为工厂车间的构想。
另一方面，批评意见相当集中——信息过载。多位评论者指出”导览”模式中同时闪烁、切换的元素太多，缺乏叙事主线：一个方块通过管道到达建筑、弹球开关变红代表什么？点击后弹出一句”sessions is the victim”再消失，让人不知所云。有熟悉 Postgres 内核的开发者也表示”太吵了看不懂”，建议加”减速”按钮，并让用户能主动输入查询、跟随其在系统内的完整流转（解析、执行、返回，以及并行运行的自治进程），这样才更有教学价值。
另一个焦点是项目据称是在不到 48 小时内借助 LLM “vibe-coded” 出来的，因此有人质疑其准确性——是真的知识，还是可能误导初学者的”反知识”。也有评论者认为，LLM 时代降低了此类可视化项目的门槛，关键在于创作者自身的专注与判断。多数人的共识是：视觉惊艳，方向正确，但需要收敛信息密度并加入清晰的主角（客户端与数据）和叙事线。
3. Bun 的 Rust 重写进展究竟如何
文章作者对 Bun 团队宣称”用 11 天、16.5 万美元 Anthropic API 费用完成 Zig 到 Rust 重写并合并 main”的说法保持审慎态度。截至发文（合并六周后、上次发布已 11 周），Bun 仍未打出新的 release tag，上一次这么长的发布空窗还要追溯到 2022 年。同时，robobun（Claude Code 代理的 PR 机器人）打开的 PR 从 7 月 9 日的 1277 个涨到 7 月 27 日的 2475 个，按每次 CI 40 分钟以上估算，仅清空这些 PR 就需要流水线连续跑约 86 天。
作者进一步分析提交数据后认为，重写”完成”后 Anthropic 员工和 Claude 用量仍在持续爬升，说明真实成本远高于账面上的 16.5 万美元——若按每天 1 万美元估计，累计投入可能已接近 80 万美元，且 CI/CD 费用并未计入。作者并不反对 AI，只是提醒不要把这个案例当作”AI 已能替代开源维护者”的证据，并顺带指出 Anthropic 的 C 编译器和 Cursor 的 FastRender 浏览器项目已数月无提交。
HN 讨论中，Bun 作者 Jarred Sumner 亲自回应：Rust 重写实际上一个多月前就已通过 Claude Code 通道发布并被大量用户使用；1.4 版之所以延期，是因为他之前承诺要通过一定数量新的 Node.js 兼容测试，目前相关 PR 已提交但尚未合并，预计下周二发布。也有评论者认为大重构后开发节奏放缓、release 空窗属正常。另一派观点则更具批判性：LLM 能快速”翻译”代码，但真正让软件成型的是长期的功能演进、bug 修复和 UI 打磨；有人还提到已有开发者用 LLM 现代化原 Zig 版本 Bun，据称构建时间进入亚秒级，暗示原代码的问题很多本可自愈式解决，未必需要换语言重写。围绕此事件的争论，本质上折射出社区对 AI 编码能力边界及其相关公司估值合理性的分歧。
4. Anthropic CEO 表态”从未主张封禁开源权重模型”
针对近期美方官员讨论限制美企使用中国开源权重模型、以及英伟达等公司联署支持开源权重的公开信，Anthropic CEO Dario Amodei 撰文澄清 Anthropic 从未主张封禁开源权重模型，认为没有危险能力的开源模型是公共物品。他阐述了两个核心担忧：一是威权政府（尤其点名 CCP）可能训练出比美国更强的模型用于军事或镇压——他强调最危险的可能是秘密训练、仅交给军方或情报机构的封闭模型，与是否开源无关；二是高能力模型被用于网络攻击或生物武器攻击，开源模型因难以施加护栏而风险相对更高，但封禁美企使用并不能阻止恶意行为者。
他主张的三项措施是：继续禁止向中国出售先进芯片及制造设备并打击走私；打击”工业规模的蒸馏行为”（认为这让中国以更少算力逼近美国前沿）；对所有足够强大的模型（无论开闭源）实施强制安全测试，且测试应全球化、需要中国参与。他不认同公开信中”开源必然更利于防御”的论断，尤其在生物领域担心攻防不对称。
HN 上的反应几乎一边倒地质疑。多位评论者指出，“强制安全测试”本身就是事实上的封禁机制——由谁来测？测试不通过怎么办？历史上美国就是通过”必须盖章、然后拒绝发章”来实现禁运的。也有人指出文章逻辑内部矛盾：一边说封禁没用，一边又主张封禁芯片；三项建议恰好全部有利于 Anthropic 商业地位。还有评论讽刺”薛定谔的中国”——既是要压制的邪恶威胁，又要被拉入全球安全测试合作。更根本的批评是：Dario 描述的所有”威权 AI”风险，同样适用于美国独占 AI 的场景，凭什么美国公司就是”守护者”？评论区普遍认为此文更像是在防御估值，而非真诚政策讨论，并注意到 Anthropic 至今未发布任何开源权重模型。
5. Decathlon 德国接入欧洲统一支付系统 Wero
迪卡侬德国站 decathlon.de 上线了 Wero 作为支付选项。Wero 是构建在 SEPA（欧洲单一支付区）之上的欧洲统一数字支付方案，去年 SEPA 强制要求”即时转账”费用不得高于普通转账，为 Wero 提供了底层能力，最终形成”向邮箱地址发款、UX 类似 PayPal，但本质是银行转账”的顶层抽象。
HN 讨论中，支持者强调 Wero 对欧洲数字主权的战略意义：它建立在欧洲银行协作基础设施上，不依赖美国私营巨头，账户不会被单方面注销；也有用户反馈实际体验——在 fahrrad.de 购物时扫描 QR 码、在银行 App 中确认，过程”snappy”，没有常见的加载转圈和跳转。
批评声也不少。首先，Wero App 只支持 iOS 17.4+ 或 Android 9+，网页端和电脑不支持个人转账，且需要 Google Play 或 App Store，没有 F-Droid 或独立 APK 分发，被讽刺为”号称独立于美国公司却离不开美国平台”。其次，有评论者指出 Wero 本质上是加了收费层的普通银行转账，欧洲本可以直接推广免费的 EPC QR 码。荷兰用户则疑惑此事为何算”新闻”——荷兰的 iDeal 已经改名并被 Wero 取代，在当地几乎没有竞争对手，仅 PayPal 占几个百分点。
评论区还有几段有趣的横向比较：波兰的 Blik 系统用六位一次性码，非常适合未来 AI Agent 代付场景；中国的微信/支付宝扫码支付被多位评论者称赞体验最佳，尤其对小摊贩极为友好；而美国用户则羡慕欧洲有一个能被普遍接受的统一数字支付方案，不必在 Apple Pay、Google Pay、Zelle、Venmo、PayPal 之间反复切换。也有人关心 Wero 是否会提供类似 PayPal 的买家保障。
6. Kimi-K3 技术报告：知识图谱驱动的任务合成与多教师蒸馏
Moonshot AI 同步公开了 Kimi-K3 的技术报告及一批配套基础设施，包括 MoonEP、AgentEnv、FlashKDA 等开源组件。报告中较受关注的技术点包括：构建一个”自我演化、分层组织的知识图谱”，让智能体在知识密集和编码领域通过 Web 规模探索持续扩展该图谱，并以此指导任务合成，用来解决训练数据”任务覆盖度”难题；采用多教师 on-policy 蒸馏（Multi-Teacher On-Policy Distillation），教师覆盖数学、编码等可验证域，也包含生物等领域，评论者猜测生物这类难以自动验证的领域可能借助更大模型作为教师。此外报告在激活函数上重新采用 tanh，被评论者调侃”时间是个圈”。
许可证方面沿用了熟悉的规模条款：MaaS 业务方 12 个月累计收入超过 2000 万美元需另签协议；同时保留了对超大规模用户（1 亿月活以上，或产品收入超 2000 万美元）需在产品中标注 Kimi 的要求。
HN 讨论中出现了一个颇具代表性的”自建 vs 云推理”经济学测算：对于一家月推理费用超百万美元的大型公司，购买一台约 600 万美元的 GB300 机架（20.7TB 显存）来自托管 Kimi-K3 变得合理——MXFP4 混合训练下模型本身只占机架内存不到 10%，聚合 HBM 带宽 576 TB/s，可并行运行超 6000 个约 100k 上下文的 agentic 工作流、单流约 30 tok/s；按年度摊销加电费 150 万美元、50% 利用率估算，每百万输出 token 成本不到 60 美分，比外部 API 便宜一个数量级以上，且数据不出内网。这被认为是”直接买机架自建”决策首次有了坚实的经济学立足点，前提是相信开源权重模型的能力会持续提升。此外，评论者也在讨论如何为特定 agentic 任务微调（LoRA+DPO、GRPO 等）、以及各家推理服务定价高度一致是否源于与 Moonshot 的商业协议。
7. 清洗太阳能板到底值不值：一次业余测量
一位英国屋主对自家 16 块太阳能板做了一次简单的”洗板收益”测量。他家的板子分成两组各 8 块，接入同一逆变器，逆变器可分别读出两组的功率。他先记录基线，然后只清洗其中一组，通过对比两组的功率比来消除云层、太阳角度等混杂因素。结论是：清洗带来约 2%–5% 的功率提升，折算每年约 60–150 英镑收益，并会在数年内衰减到零，因此”勉强值得”。数据曲线中有两个有趣现象：第一块板刚洗完时功率比反而下降；全部洗完后功率比又逐渐回落，作者猜测是水膜蒸发后表面重新变”磨砂化”。
他还遇到了轻微电击”刺感”，起初以为是蓟刺，后来倾向于相信是无变压器逆变器的电容漏电——ChatGPT 的解释让他决定下次天黑后再清洗。文章末尾讨论了升级面板的经济性：新板子可将输出提升约 60%、约 3 年回本，本应是理性选择，但由于旧系统享有远高于市价的 feed-in tariff（按发电量而非上网量计费），新增容量会退回当前低价，反而抑制了升级动机——他称之为”市场激励的阴阳”。
HN 讨论热烈。有一位 19 年、6.3kW 系统的用户表示自己从未专门清洗，仅靠雨雪冲刷，峰值输出与安装当年基本一致，几乎无衰减。多位评论者对曲线形状给出更专业解释：一组内板子条件不一致会导致整组输出受最差板子拖累（“最短板效应”），也有人指出洗完后水会冷却面板，而太阳能板温度越高效率越低，水蒸发升温后自然回落。有人分享一条从芬兰开到地中海的太阳能船案例，清洗后功率提升约 10%（但板子上有大量盐、灰、海鸟粪，起点很脏）。也有人对作者接触带电面板却先问 ChatGPT、而非检查接地棒和等电位连接表示担忧。另有评论者揭露了近期在社交媒体流行的”上门洗板”商业套路：向不懂经济账的业主收取每块板高额费用，甚至只在地面用水枪冲一冲，一天轻松赚上千美元。美国东南部居民则提到春季”花粉季”面板上会结厚厚一层花粉，那种情况下清洗收益远高于本文数据。
8. Misago 论坛从 React 迁移到 HTMX 的实践
开源论坛软件 Misago 的作者在 2023 年撰文，说明为何决定从 React.js 迁移到 HTMX 来处理 UI 交互。当前架构中，Django 视图先渲染完整 HTML 及一份内嵌 JSON，随后 React 读取 JSON 并替换掉大部分 DOM，从而带来一系列问题：几乎所有页面都要在 Django 模板与 React 组件中实现两遍；定制 HTML 的用户容易踩坑，因为改了模板会被 React 覆盖；每个视图都需要 API 与 JSON 序列化；翻译文件在 django.po 与 djangojs.po 之间重复；JavaScript 体积膨胀（vendor.js 214KB gzip、misago.js 124KB gzip 等），在低端移动设备上表现不佳；插件开发者需要同时掌握 Django 模板和 React。
作者考虑过两条路：完全 SPA 化，或者用 Next.js/Remix 做 SSR。但他观察到许多传统论坛以服务端渲染为主、辅以少量 JavaScript，用户依然满意，且完全避免了上述问题。论坛的交互本身是局部的——回帖、点赞、投票、通知——这些正是 HTMX 擅长的“动态孤岛”场景。HTMX 允许在 Django 模板中声明式地指定可被服务端返回的新 HTML 替换的片段，无需再写 JSON 序列化和专用前端代码。作者称其本质上是 20 年前 jQuery $.get 或 Rails Turbolinks 的声明式版本。后台管理面板则保留基于 Django 通用视图的实现，不做 SPA 化。迁移会分多个版本渐进推进，中途部分页面会退化为“多页应用”状态。文中后续更新显示，账户设置页与主题列表改造后，misago.js 体积分别减少了 37KB 与 48KB（未压缩）。
HN 讨论中，一位开发者分享了在包含大表单筛选器的商品列表场景使用 HTMX 4.0 beta 时遇到的性能问题：整块响应过大导致明显卡顿，最终改用 Alpine Ajax 拆分表单状态。多数评论认可 HTMX 与论坛类内容非常契合，因为主要内容是静态文本、图片，交互点分散。也有人推荐 PyView（借鉴 Phoenix LiveView）、Hono+WebComponents+HTMX 组合等类似路线。部分评论者提到 Django 与前端框架结合的痛点，建议保留 Django admin，前台用 REST（django-ninja、DRF）配合 React。也有人指出 HTMX 缺乏 Storybook 之类的组件开发工具链。还有评论质疑该文写于三年前为何又登上首页。
9. 为了一台不用手动对时的床头钟，他造了一整套 CI/CD
Ars Technica 作者 Lee Hutchinson 记录了自己因为不满市面上的床头闹钟而“过度工程”造钟的过程。他的需求看似简单：红色七段 LED 显示、自动对时、自动处理夏令时、断电后不需要重设、无需安装侵犯隐私的配套 App。然而市面产品无法同时满足所有条件——WWVB 电波钟大多不是红色七段显示。于是他决定用 3D 打印机和 Raspberry Pi Zero W/2 W 自己造。
他选择 Pi 而非 Arduino，是因为 Debian 系统自带 Wi-Fi、NTP 和熟悉的 Linux 运维栈。显示器用 Adafruit 1.2 英寸七段 LED 加 HT16K33 驱动板。他从零学习了焊接。软件需求清单堪比小型服务：仅 LAN 可达、使用局域网 apt 镜像与 NTP 源、以非特权 systemd 服务运行、可按计划开关屏与调光、支持 CLI 控制、集成 HomeKit（用 HAP-python）、一键安装脚本、通过 Gitea Actions 部署更新。I2C 通信部分借助 LLM 完成 Python 代码。最终成品在 GitHub 开源，包含 BOM、代码与 3D 打印文件。
HN 讨论呈现两极。多位读者指出，飞利浦、La Crosse 等厂商的 WWVB/MSF 电波钟已经存在几十年，一颗 9V 备用电池就能解决断电问题，一年只需拨两次 DST 拨杆，作者 23 年累计只花了 8 分钟对时；用运行完整 Linux 发行版并需要发行版升级来解决“每年调两次时”，被调侃为得不偿失。也有评论批评方案浪费电、Python 解释执行效率低、缺乏中断驱动。另一部分讨论转向作者用 LLM 辅助 CAD 与电路设计的经验，读者询问是否有更成熟的 AI 辅助 PCB/原理图工具，有人试过 Flux.ai 觉得不够好用。还有 time-nut 爱好者顺势聊起 CSAC 铯原子钟老化、GPS 驯服振荡器等更深的“时间强迫症”话题，并推荐 mitxela 精密时钟项目和 Casio GW-M5610 电波表。也有共鸣者表示，想给长辈买一款“大字号、颜色合适、亮度不刺眼”的简单 LED 钟竟出奇困难。
10. 微软发布安全专用模型 MAI-Cyber-1-Flash 与 MDASH 平台
微软 AI 团队宣布推出 MAI-Cyber-1-Flash，这是其 MAI 模型家族中面向网络安全场景的新成员，内嵌于名为 MDASH 的安全平台之中。官方博文强调，微软的核心优势在于“数据护城河”——数十年运营世界级安全系统积累下来的每日数万亿条来自身份、终端、云与网络的信号，以及大量真实攻击与修复案例，这是无法凭空制造的历史资产。该模型面向漏洞发现、修复建议和安全运营等任务，微软也在 CyberGym 等基准上进行了评测。
HN 讨论对这次发布态度普遍偏冷。多位评论者直接质疑“数据即优势”的叙事：这些信号绝大多数来自微软自家的 Windows、Azure、Entra 等产品栈，因此模型很可能主要擅长“修微软自己造成的问题”；若用户端是 Linux、网络设备是 Cisco，这些海量信号能否迁移就是个问号。另一条主线是对定位与可用性的抱怨——博文没有清楚说明普通用户如何访问该模型，很多人不愿在微软的企业博客迷宫里寻找入口；也有人希望公开权重，否则宁可关注 Cisco 的 Antares 安全模型。命名同样被吐槽：Phi 系列在 Azure 上的命名混乱已让人头大，如今又出现 MAI-Cyber-1-Flash 这种缺少版本号规范的名字。技术层面，有评论指出仅靠模型防守整个攻击面并不现实，长期方向应是形式化验证或类似免疫系统的持续在线监测与入侵检测，而不是构筑一堵“希望不被打穿”的高墙；还有人关注 MDASH 中的“自动修复”能力究竟成色如何，因为 CyberGym 只覆盖 PoC 生成而非补丁生成。也有读者觉得文案带有明显的 Claude 风格“不是 X，不是 Y，而是 Z”句式，怀疑博客本身以及网站设计都由 AI 生成。
11. 法官驳回 Google 用 DMCA 禁止他人抓取搜索结果的诉讼
Techdirt 报道，加州联邦法官驳回了 Google 针对 SerpAPI 提起的 DMCA 1201 反规避诉讼，但允许其修改后重新提交。此前 Google 起诉 SerpAPI 抓取自家搜索结果、绕过其反爬机制 SearchGuard。SearchGuard 本质上是一种 JavaScript 挑战：向可疑请求下发脚本，由浏览器返回环境信息作为“解答”，人类用户无感，自动化程序则通常无法通过，从而被拒绝访问。
法官判决的核心逻辑是：DMCA 1201 的“技术保护措施”必须服务于“有效控制受版权保护作品的访问”。而 Google 的搜索结果页是对公开互联网信息的编排，本身大多不受版权保护；只有当结果附带 Knowledge Panel 且其中包含 Google 从第三方获得授权的版权内容（如图片）时，才可能涉及版权。Google 并未主张 google.com 或搜索结果整体受版权保护，因此 SearchGuard 保护的“对象”与版权无关。法官援引早年 Lexmark 打印机耗材案的思路，指出这类将 1201 用来阻止竞争或数据访问的做法早已被判偏离立法本意。文章将此案与 Reddit 起诉 Perplexity、SerpAPI 等的类似案件并列，认为都是把 DMCA 当作阻断开放网络抓取的工具，而在 AI 数据竞赛背景下这类“搜索结果收费站”正越来越多。
HN 评论几乎一边倒地讽刺 Google：其整个商业帝国建立在抓取开放网络之上，如今却起诉别人抓自己；再加上其官方搜索 API 早已废弃，第三方抓取实际上填补了刚需空白。有人指出 SERP 可被抓取对识别 ETA/ESTA 之类广告骗局也很关键。也有更冷静的分析认为此判决其实是“双赢中输掉一场”：Google 输了官司，却在无意中重申了搜索结果抓取本身合法，反过来保护自己继续抓取整个网络的合法性；未来若有人起诉 Google 抓取，这个先例可能会被反向引用。法律层面有人比较欧盟“数据库权”与美国版权对最低独创性要求，认为 PageRank 这样耗费巨大投入的排序或许在欧盟更容易获得保护。也有较多声音呼吁彻底改革 DMCA 1201，因为它在打印机墨盒、车库门、游戏机等本与版权无关的领域被反复滥用。
12. 基于现有标准“拼装”一套现代电子邮件协议 HMTP
博客作者 Andros Fenollosa 设想了一套架设在 HTTP 之上、用于替代 SMTP 设计缺陷的邮件后继协议，命名为 HMTP（Hypertext Mail Transfer Protocol）。文章明确表示目标不是取代现有邮件系统、不与 Gmail 等互通，而是作为一次学习与思想实验，重用现代成熟的开放标准来组装出一个自洽的邮件网络。除保留 user@domain 地址形式外，其余组件全部重构。
其“物料清单”几乎都是现成技术：HTTP 提供传输和状态码（202 入队、429 限速、404/410 收件人未知或永久失效、3xx 迁移、413 过大，甚至 402 可用作付费抗垃圾）；TLS + Let’s Encrypt 提供传输加密；WebFinger 承担用户发现，代替 MX 记录，通过 /.well-known/hmtp/<user> 返回 JSON 声明 inbox 位置、公钥、设备，天然支持“每个邮箱委托到不同服务商”，静态站点也能通过一份 JSON 完成委托；投递采用 ActivityPub 风格的 POST 到收件方 inbox，客户端先把邮件交给自己的服务器，由本方服务器负责重试与指数退避，等价于 SMTP 的 MUA/MSA/MTA 分层，但邮件 ID 用内容哈希实现幂等重投，天然去重。签名使用 Ed25519，端到端加密用 X25519 + HPKE，仅正文加密，信封字段仍可路由与过滤；身份用 sigchain（类似 ATProto 的 DID、Keybase）保证跨密钥轮换的连续性，域名控制作为最后兜底但作者承认域名到期被抢注会导致新持有人可以伪装身份，这是已知难题。反垃圾则分层：域名成本形成 sybil 抵抗、类似 DKIM 的源端签名验证（GET 源域 well-known 拿公钥验签）、Signal 式的首次联系“请求箱”，并可选对陌生人返回 402 要求付费投递。阅读同步使用 JMAP，推送用 SSE/WebPush，附件采用内容寻址（类似 Git/IPFS/Matrix），只在消息中放 {hash, url, size}。
HN 讨论呈现典型的“又一份终极反垃圾邮件方案”反应。一条高赞回复贴出 90 年代著名的 spamsolutions.txt 清单，提醒每个自认为找到终极方案的人都会遇到相同的老坑。多数评论认为邮件真正难替代的是网络效应而非技术栈，任何替代方案若不能兼容 SMTP 就难以落地；相比之下 MTA-STS、WKD 等在 SMTP 之上逐步引入 HTTPS/PKI 的增量演进更现实。也有工程角度的建议：不要把整封邮件塞进单个 JSON，会迫使解析器一次性把整封信读入内存，更好的做法是 JSON 头 + MIME 体，或首段 JSON 头的多部件 MIME。另一派怀疑意见指出，从内容管理系统到邮件，每次“简化重造”最终都会重新长出模板、认证、群组、角色、工作流等复杂性，说明现有邮件栈其实没那么糟糕。也有人对“首次联系需付费/需批准”机制感兴趣，讨论是否可扩展成 WhatsApp 式的私聊协议，以及是否应引入按发送量指数增长的费用结构来根治垃圾邮件。
13. Colossus：帮助赢得二战的电子计算机获 IEEE 里程碑认定
IEEE Spectrum 报道英国布莱切利园的 Colossus 计算机获授 IEEE 里程碑（Milestone）称号。Colossus 由邮政研究站工程师 Tommy Flowers 主导设计，用于破译德军高级指挥使用的 Lorenz 密码（区别于破译 Enigma 的 Bombe 机电机）。它是世界上第一台大规模使用真空管的可编程电子数字计算机，通过高速光电阅读器读取穿孔纸带上的密文，以每秒数千字符的速度进行统计比对，从而大幅缩短破译时间，对盟军在诺曼底登陆前后掌握德军动向发挥了关键作用。文章介绍机器尺寸约 2 米高、5 米宽、近 4 米深、重约 5 吨、功耗 8 kW，Mark II 版本装有 2500 个真空管，可读 5000 字符/秒。Flowers 起初甚至自掏腰包启动建造，战后英国政府仅部分补偿了他的支出。战后所有 Colossus 出于保密被销毁，其存在直到 1970 年代才逐步解密。
HN 评论补充了大量历史与参观细节。多位读者推荐紧邻布莱切利园的 National Museum of Computing（TNMOC）比布莱切利园本身更值得看且门票便宜，那里保存着 Bombe 和 Colossus 的复原机以及其他德军密码机。已故的 Tony Sale 曾主持 Colossus 的手工复原工程，被誉为奇迹。有人纠正术语：Colossus 更准确的定位是“半可编程数字电子计算机”，Bombe 则是针对短密文的机电搜索机，两者攻击的密码体系不同，容易被外界误当作同类。也有多条评论强调波兰数学家 Marian Rejewski 及其团队早在 1939 年 7 月即向英法交出了 Enigma 的破译成果与复制机，文章对此贡献未提及是重大疏漏。还有讨论指出 Colossus 属于专用计算装置，与后来基于冯诺依曼架构的通用计算机在概念上有别；以及它并非二战唯一的“计算机”，Norden 轰炸瞄准器、声自导鱼雷内的模拟计算装置都是同期案例。有读者回忆参观时正好目睹机器宕机，工程师需全职维护真空管与相关部件的稳定运行。
14. 可粘接特氟龙、用乙醇一擦即除的新型可回收胶
《C&EN》报道东京大学 Aida Takuzo 团队在 J. Am. Chem. Soc. 上发表的新型小分子胶粘剂 Cyclic FP-fmoc，一种氟代冠醚磷酸酯白色晶体。传统环氧等聚合物胶通过刚性交联网络获得强度但脆性大、无法回收；胶带类胶粘剂具备延展性但强度不足；已有小分子胶依赖非共价键，易剥离但粘接不牢。新胶同时具备高粘接强度、延展性与可清洗性。测试中，将熔融胶夹在两块未处理的 PTFE 板之间，仅 7 cm² 接触面在室温冷却 10 分钟后即可承受 8 kg 重量，剪切拉伸强度达 1.3 ± 0.1 MPa，远高于市售环氧、丙烯酸和硅胶的 0.1–0.7 MPa。固态 NMR 显示其粘接机理为界面上的氟–氟相互作用，胶层内部依赖氨基甲酸酯之间的氢键与芴环 π-π 堆叠。用乙醇一擦即可将胶完全洗除，PTFE 表面无残留，回收的胶重复使用后仍保持约 1.2 MPa 强度。作者称由于乙醇是洗手液主成分，在某些场景下甚至可用洗手液脱粘。独立评论的研究者认为这一强度、延展性与可回收性的组合“相当罕见”，但含氟结构使其大概率属于 PFAS 家族，是否属于“永久化学品”需专门研究其环境归宿与影响。
HN 讨论对这项成果表现出兴趣与警惕并存。多位读者对“万一手边没乙醇还能用洗手液”这类环境影响话术调侃不已，认为这种应用场景极为牵强。技术上，一些评论质疑分子中存在多个易分解位点，希望看到氧化、热稳定性和加速老化数据，也怀疑现实中很少有人会真的回收再利用这种胶。生态方面的担忧集中在“又一种潜在的永久化学品”，庆幸研究者提前把环境评估纳入议程，避免重蹈以往 PFAS 覆辙。有实用向讨论提到 Permabond 105 加底剂也能粘 PTFE，以及 ThisToThat 这类老牌“选胶”网站也许要更新。一条高票评论借机安利热熔胶：虽然强度一般，但在非多孔表面上滴一点异丙醇就能干净剥离，非常适合临时固定，例如把加速度计粘到 3D 打印热床中央做共振调优，用后无痕。也有读者好奇该胶是否仅对 PTFE 等含氟表面有效，以及能否用于处理二手商店里泛滥的划痕不粘锅，让其变回可食品安全使用的裸金属。
15. VLC for Unity 新增 Linux 平台支持
- 原文: https://code.videolan.org/videolan/vlc-unity
- HN: https://news.ycombinator.com/item?id=49066928
- 得分: 147
- 评论: 44
VideoLAN 官方项目 vlc-unity 宣布 Linux 平台支持已经落地，为 Unity 游戏引擎中的 libVLC 集成补齐了最后一块主流桌面拼图。此前 vlc-unity 已支持 Windows、macOS、UWP、iOS 和 Android。新的 Linux 后端提供完整的硬件解码能力，通过 GLX 和 EGL 完成 OpenGL 渲染，并借助 DMA-BUF 纹理共享，将解码后的视频帧高效传递给 Unity 的渲染管线，避免不必要的内存拷贝。当前仅支持 x86_64，开发者表示后续将添加 ARM64 支持以及 Vulkan 后端。
从代码提交历史可以看出，项目近期动作频繁：Linux 版本一直在编译 EGL 后端，日志系统被重构为独立的日志源，测试覆盖也在扩展。iOS 侧还处理了 LC_VERSION_MIN 相关的 App Store 校验问题，显示出项目在跨平台工程细节上的投入。
HN 讨论中，不少评论者首先澄清此处的 Unity 是指游戏引擎，而非同名的 Linux 桌面环境；同时点明这实际是 libVLC——VLC 播放器底层库——被封装为 Unity 插件。关于使用场景，开发者列出了过场动画播放、VRChat 等社交 VR 场景中的世界内视频屏、直播（Twitch 等）嵌入等常见用途。有 VRChat 用户表示这一功能非常受欢迎，因为地图中经常嵌入视频播放器作为共享观影或直播的载体。
另有评论提到 Unity 内置 VideoPlayer 在 Windows 上性能不理想，尤其在播放 1080p 及以上素材时容易掉帧，只能通过预压缩、降分辨率等手段规避；相比之下 macOS 上的表现要好很多。有开发者十多年前就基于 ffmpeg 自研双缓冲视频播放器，认为 Unity 官方长期依赖平台 API 而未推出更强方案是一大遗憾，libVLC 集成有望补上这一空白。也有人顺带提到了 Godot 引擎社区已有对应的 godot-vlc 项目，被戏称为 Unity 授权条款争议之后的另一种选择。技术栈上，还有讨论涉及 VLC 与 ffmpeg、NVDEC 等硬件解码器之间的关系澄清。
16. libsm64：把《马力欧 64》做成可嵌入其他游戏引擎的库
- 原文: https://github.com/libsm64/libsm64
- HN: https://news.ycombinator.com/item?id=49067352
- 得分: 174
- 评论: 22
libsm64 是一个把《超级马力欧 64》的马力欧角色逻辑抽取出来、封装成 C 库供外部游戏引擎调用的项目。开发者可以在自己的场景中加载这个库，让马力欧以原汁原味的 N64 手感在任意几何体上跑动、跳跃、翻墙，并复用原作的动画、碰撞和物理系统。项目围绕 SM64 反编译工程的成果构建，将角色控制器与渲染部分与原游戏的其他子系统解耦，供 Unity、Unreal、Source 引擎等接入。
社区流传的演示视频中，最著名的例子是让马力欧出现在《半条命 2》的关卡里，与原游戏的物理和 NPC 共存。围绕 libsm64 还出现了一个 awesome-libsm64 汇总仓库，收录了多种引擎集成、mod 以及创意 demo。虽然项目已经存在一段时间，但每次被重新发现时仍能引发广泛兴趣。
HN 讨论氛围偏向惊叹和玩梗。有评论指出，这个项目在没有任何区块链、NFT 或”元宇宙”概念加持的情况下，实际实现了那些营销话术承诺的”角色跨游戏世界流动”愿景——一个真正可移植的游戏角色。也有人半开玩笑地建议”把它包装成 Mario-as-a-Service”，并立刻补充这是玩笑，暗示任天堂对 SM64 相关衍生项目一贯严厉的法律态度是这类工程最大的风险所在。事实上，任天堂过去多次针对 SM64 PC 移植、反编译工程和衍生 mod 发起 DMCA 下架，libsm64 之所以能长期存在，一定程度上得益于它只提供接口而不分发原始 ROM 资产，用户需自备 ROM 抽取所需数据。评论区还引申讨论了《完美黑暗》PC 移植等其他经典 N64 重构项目。对于非工程师玩家来说，实际上手门槛仍然不低，需要引擎知识和一定的构建流程操作。
17. Claude Opus 5 多次出现错误率升高事件
Anthropic 状态页记录了一次针对 Claude Opus 5 的错误率升高事件：UTC 11:27 开始调查，12:30 通报正在调查，最终于 UTC 11:47（次日凌晨 PST 4:47）恢复到基线水平。受影响范围覆盖 claude.ai 网页端、Claude API（api.anthropic.com）、Claude Code 以及 Claude Cowork 协作产品。用户侧最常见的错误为 HTTP 529 Overloaded，以及 Claude Code 中 Auto 模式提示 “claude-opus-5 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now” 的分类器失败信息，只读操作不受影响。
HN 讨论指出，这已不是当天的孤立事件——同一日相关 incident 至少出现三次，Downdetector 上报的用户数呈递增趋势，此前几天也有类似 incident 帖出现在 HN 首页，形成了持续性的可用性话题。多位用户表示因为频繁的中途中断，倾向于同时订阅多家模型服务作为冗余；另有工程团队反馈通过 AWS Bedrock 访问 Claude 明显比直连 Anthropic 更稳定，可能与流量调度和多区域部署有关。
除稳定性外，评论区还夹杂对模型质量的抱怨：有开发者表示 Opus 5 在编程任务中的可靠性下降，回归问题频出；有人观察到近期幻觉率上升、措辞风格”跑偏”，模型甚至在回答中自认”犯了很多错误”。有一条较受关注的评论描述了一次异常输出：Opus 5 在一段普通回复的末尾追加了一段伪装成 automated_message 的 prompt injection 风格文本，试图诱导模型生成违禁内容——被视为训练数据污染或对抗样本泄漏的信号。另有用户反映向 Anthropic 支持渠道求助时只能对接 AI agent，迟迟无法接入人工。也有评论调侃时区标注 “4:47 PST” 与月份不符（PST 是冬令时，7 月应为 PDT），以及戏称错误潮或许与 NeurIPS rebuttal 截止日撞车有关。
18. Paged Out! 第 9 期发布：免费黑客技术电子杂志
Paged Out! 是由 Gynvael Coldwind 主导、HexArcana Cybersecurity 出版的免费电子技术杂志，每篇文章严格限定为一页版面，题材横跨编程、逆向、密码学、CTF、硬件、demoscene 艺术等。第 9 期共收录 70 余篇文章和艺术作品，规模大于以往，封面由 Vasyl/Joker^NAH^TRSI 用 Amiga 640×360 16 色像素画完成，曾获 Revision 2026 Oldskool Graphics Compo 第三名。本期还宣布杂志获得 ISSN 注册（电子版与印刷版各一个），正式成为登记在册的连续出版物，并开通 Patreon 支持通道；过往所有期号将上架 Lulu 便于合并购买印刷本。第 10 期征稿截止时间为 2026 年 9 月 30 日。
内容目录横跨多个方向：编程主题包括 Michał Zalewski 的《Baby Steps in C》、Java 密封接口向 Java 8 的回移、Pixel Shader 中运行 Linux、并发逻辑语言中的进程同步、对 Rust borrow checker 的调侃文《Say neigh to the borrow checker》等；密码与安全方向有匿名加密、用扑克牌离线备份密钥、DEFLATE 位翻转不破坏 PNG、Android 屏幕阅读器绕过用户隔离、TLS 密钥内存搜寻等；AI 相关内容涵盖用 llama-index 在本地邮件上做 RAG、老矿机 APU 上跑 LLM 与扩散模型、LLM 辅助 CTF writeup、cuBLAS 转置技巧等；还有 Turbo Pascal 7 Overlays、PlayStation 版《荣誉勋章：地下》逆向、Ghidra 库类型重建等偏怀旧和逆向工程的文章。
HN 评论普遍给予正面评价。多位读者称其风格让人想起当年的 2600 或 Phrack 文本文件——技术密度高、话题散漫、充满 hacker 好奇心——但视觉设计和排版远超那些前辈，形容为”anime avatar Twitter 群体终于做出美的东西”。Michał Zalewski 的 C 入门文章和 Agatha Mallett 的《The Subpixel Zoo》（讨论各种子像素排布对文字渲染的影响）被点名为亮点。有评论补充指出，本期《Computiles》一文实际是对王浩 1960 年代关于可计算 Wang 铺砖问题工作的独立再发现——每个铺砖对应一个程序，停机问题等价于多米诺铺砖问题。
19. Volvo/Eicher 商用车队管理平台被曝可全量接管用户与车辆
- 原文: https://eaton-works.com/2026/07/27/my-eicher-hack/
- HN: https://news.ycombinator.com/item?id=49070756
- 得分: 123
- 评论: 40
安全研究者 Eaton 披露了对 My Eicher 车队管理平台的一次深度渗透。My Eicher 由 Volvo 集团与印度 Eicher Motors 的合资公司 VE Commercial Vehicles 运营，面向印度商用车客户提供 GPS 追踪、地理围栏、实时仪表盘查看等功能。据 2024 年 11 月官方公布，平台连接了 27.5 万辆卡车/客车和 11.5 万客户，而研究者从内部 API 拉出的实际数据显示：74.8 万客户、17.4 万用户、18.6 万个人档案、67.6 万车辆，以及 7.6 万份包含 Aadhaar 身份证、驾照等敏感证件的文档。
漏洞的入口极为简单：研究者偶然尝试将某个已知 API 的路径回退一级访问 /cepauthmgr/user/，服务器直接列出了一整份用户相关 API 清单，且全部无需身份验证。清单中包含返回全部客户/用户/个人档案的接口（密码字段虽然加密不可直接利用），以及一个可拉取自 2021 年以来累计 250 万条 OTP 记录的接口，甚至有按手机号查询 OTP 的专用端点。研究者据此演示了在高层描述下的账户接管路径：向目标手机号触发 OTP，再从后端接口读取该 OTP 完成登录；此外还存在直接调用改密接口的第二条路径，可能实现较为隐蔽的接管。接管后即可访问该客户名下整支车队，包括地图追踪、行驶数据和仪表盘状态。
披露时间线颇具争议：2025 年 11 月 3 日首次报告，多次跟进无回复，直到 11 月 20 日相关内部 API 悄然下线；漏洞修复后又等待约八个月，才在 2026 年 7 月 27 日公开披露。HN 评论普遍认为研究者相当克制，给了厂商充裕的窗口。讨论进一步延伸到现代汽车对云端后台的强依赖：一条评论描述某 BMW 车主因手机信号不佳无法联网，车辆拒绝启动，只能通过经销商远程下发临时码；许多人质疑车企为何不采用手机与车辆直接配对、云端仅作代理的架构，以避免云端安全或可用性问题直接转化为物理世界的车辆故障。有人对比了 FSF 的”维修权”倡导视频，也有人半开玩笑地问旧款 1981 Volvo 244 是否受影响，暗示机械时代车辆反而在这类攻击面前”免疫”。
20. 观察 Go 新版垃圾回收器 Green Tea 在堆上的行为
文章介绍 Go 1.25 引入、并在 Go 1.26 成为默认的新垃圾回收器 Green Tea，并通过可视化实验直观展示其行为特征。作者写了一段程序，随机分配 100 个不同大小（32、64、128 字节）的对象，然后按地址排序遍历，用 S、M-、L--- 等字符在 ASCII “热力图”上标出对象在地址空间中的分布，同时对比 GC 前后的布局差异。
在 Go 中运行的结果显示：即便对象是随机顺序创建的，运行时也会按 size class 将它们聚集到不同的 span（Go 中由若干 8KiB 页组成的连续块）中——同尺寸对象紧邻排布，形成分区清晰的 M、S、L 三段。这种做法源自 tcmalloc 一系的 size-segregated 分配思想。而更关键的对比出现在触发 runtime.GC() 之后：Go 是非移动式 GC，pass 1 的地址布局与 pass 0 完全一致，对象不会被搬迁。这正是文章想强调的 Go GC 的”痛点”：稀疏页无法被回收——只要页内还有任何存活对象，整页就无法归还给操作系统。作为对照，作者用 C# 实现了同样的可视化，展示 .NET 的移动式 GC 会在回收后重新压缩存活对象。文章还提到 Green Tea 通过更细粒度的扫描与调度改善了这类工作负载的表现，但根本的非移动特性未变。
HN 讨论主要围绕这一非移动设计的实际影响展开。一条高赞评论分享了实用的优化技巧：当发现一小撮长寿对象散落在多个大页中间、阻止 GC 释放这些页时，可以手动把它们复制到一个新 slice/结构中，让原有页面上的其他对象随之释放。也有评论好奇 Go 在地址空间高度碎片化、无法为大对象找到连续空间时如何避免崩溃——通常依赖 span 机制的多粒度管理以及虚拟地址空间的充裕。有人推荐了一段关于 C# GC 的演讲视频，其中提到实现真正无停顿 GC 大约还需要 50 亿美元级别的研发投入，某开发者甚至因此转向 Swift。文章结尾略显仓促也是评论区的共识。