2025-10-11 Hacker News Top Stories #
- 挪威诺贝尔委员会将2025年和平奖授予玛丽亚·科丽娜·马查多,以表彰她组织选举关注并收集证据所做的持续努力与勇气。
- 离散分布网络(DDN)提出一种层级离散生成范式:每层生成多个样本并选取最相似者作为下一层输入,提供可解释、可控且在多项数据集上表现良好的生成方法并已开源。
- 一架瑞安航空航班在曼彻斯特降落时燃油仅剩约六分钟,被英国航空事故调查局列为严重事故并启动调查,反映燃油计划与备降决策存在重大隐患。
- 文章主张示例是最佳文档核心,认为清晰实用的代码示例远比冗长术语更能帮助开发者上手,同时应辅以教程与 API 规范以覆盖深度需求。
- 德国主权科技基金资助 Igalia 推进用 Rust 开发的并行网页引擎 Servo,重点包括无障碍支持、WebView API 与项目治理等以促进开源 Web 技术可持续发展。
- Mitchell Hashimoto 建议将大型技术项目拆为能快速运行的小任务,通过自动化测试或最小可演示原型获取持续反馈并逐步迭代以保持进展与动力。
- 作者从 htmx 转向服务器驱动的 Datastar,认为其体积小、API 简洁且能在后端同步管理组件状态,从而提升移动端性能与可维护性。
- Karpathy 指出大型语言模型在处理异常时过度回避,HN 讨论认为这是训练目标与奖励机制导致的鲁棒性与异常处理问题。
- 游戏 Subway Builder 提供高度真实的地铁建设与通勤模拟,但处于早期测试阶段存在 UI、性能与可用性问题。
- 无聊公司在拉斯维加斯隧道工程中被指近800项环境违规并遭停业整改与罚款争议,暴露监管、环境与安全方面的问题。
Nobel Peace Prize 2025: María Corina Machado #
https://www.nobelprize.org/prizes/peace/2025/summary/
2025 年诺贝尔和平奖授予委内瑞拉政治人物玛丽亚·科丽娜·马查多,以表彰她为委内瑞拉人民争取民主权利所作出的不懈努力,以及她所进行的斗争。
该奖项旨在肯定她在推动委内瑞拉民主变革中的核心作用,强调其在艰难政治环境下坚持抗争与民主诉求的坚定立场。
HN 热度 536 points | 评论 587 comments | 作者:pykello | 14 hours ago #
https://news.ycombinator.com/item?id=45536700
- 未来若人工智能和自动化实现高效生产,人类劳动将不再必要,可能导致民主制度瓦解,政治代表性消失。
- 民主国家通过福利体系等制度实现对民众的非生产性支持,这在经济上看似非效率,但有助于社会稳定。
- 未来若军事控制由机器人和无人机完成,人类可能沦为资源或能源的供应者,社会结构可能退化为类似“索莱特绿”的工业化奴役。
- 当人类不再具有经济或政治价值时,领导层和财富阶层将完全脱离大众,形成以少数人利益为中心的极权系统。
- 历史上权力结构常在重大变革中重塑,新贵阶层往往取代旧有精英,而非由旧势力直接继承。
- “石油寡头”并非由石油本身统治,而是由掌控资源的少数人构成,本质上属于寡头政治。
- 获得诺贝尔和平奖应基于对国际团结、裁军及和平会议的推动,而不仅限于传统战争与和平的范畴。
- 用“防火安全奖”类比,强调预防性和平建设的价值,而非仅奖励应对危机的英雄行为。
Show HN: I invented a new generative model and got accepted to ICLR #
https://discrete-distribution-networks.github.io/ Discrete Distribution Networks(DDN)是一种新颖的生成模型,由 Lei Yang 提出,并已被 ICLR 2025 接收。该模型基于分层离散分布的思想,通过在每一层生成多个离散样本,逐步逼近目标数据分布,尤其擅长处理连续分布。
DDN 的核心机制是:每一层生成 K 个样本,选择与真实样本最相似的一个作为下一层的输入,从而实现逐层精细化生成。这一过程通过“Split-and-Prune”优化算法实现,结合梯度下降,有效避免了传统方法中的“死节点”和“密度漂移”问题,显著提升了密度估计的准确性。
模型具有两大独特性质:一是无需梯度的零样本条件生成(Zero-shot Conditional Generation),例如可直接通过 CLIP 模型实现文本到图像生成;二是具有 1D 离散的潜在表示结构,其潜在空间呈现树状结构,每个样本对应一个叶节点,支持高效的条件控制与生成。
实验展示了 DDN 在 CIFAR-10、FFHQ 和 MNIST 等数据集上的优异表现,包括图像重建、超分辨率、风格迁移、图像着色和边缘到 RGB 转换等任务。其生成结果不仅质量高,且具备良好的可解释性与可控性。
网页提供了完整的代码、演示、博客和海报,实验代码位于 sddn/toy_exp.py,环境基于 distribution_playground 库,用户可自行运行和探索。此外,还提供了 2D 密度估计的动态演示与训练过程可视化视频,直观展示 DDN 如何逐步逼近目标分布。
总体而言,DDN 提供了一种简洁而强大的生成建模新范式,为未来生成模型的发展开辟了新方向。
HN 热度 473 points | 评论 58 comments | 作者:diyer22 | 14 hours ago #
https://news.ycombinator.com/item?id=45536694
- 该研究提出了一种名为离散分布网络(DDN)的新生成模型,其核心思想是在单次前向传播中生成多个输出,并通过这些输出共同近似训练数据的分布,具有零样本条件生成、一维离散潜在表示的树状结构以及端到端可微等特性。
- ICLR 评审认为该方法新颖且优雅,属于与现有生成模型(如扩散模型、GAN、VAE、自回归模型)根本不同的全新范式,具有开启生成建模新方向的潜力。
- 该论文的评审意见公开透明,体现了 ICLR 开放评审政策的优势,使作者和公众都能看到审稿人对论文的评价,有助于提升学术交流的透明度。
- 有评论指出,尽管 DDN 在训练时生成 K 个输出,但推理时可提前决定使用哪个输出,从而避免计算浪费,且训练时 K 个输出共享主干特征,额外计算成本极低。
- 有误解认为 DDN 类似 Mixture-of-Experts(MoE)或扩散模型,但作者澄清:DDN 并非使用专家机制,也没有扩散过程,而是通过卷积结构生成样本并进行 L2 距离采样。
- 有研究者提出类似结构,使用层次化交叉注意力和学习到的查询,通过 L1 正则化实现稀疏性,其激活模式可形成输入的“解析树”,实现离散层次化表示。
- 有疑问指出:若网络仅由 1×1 卷积构成,是否会导致像素间无信息交互,从而生成不连贯图像,但作者澄清:仅在输出层使用 1×1 卷积,中间层使用标准 3×3 卷积,保证了空间信息的充分交互。
- 有评论引用 NeRF、单像素 GAN、MAE 等研究,说明独立生成图像某一部分是可能的,因为生成过程本质上是函数映射,无需生成全部内容。
- 有观点认为,DDN 的结构可拓展至文本到音频生成任务,若结合 RVQ(矢量量化)可能仍可适用,但 RVQ 是否必要尚待探讨。
- 该方法在生成效率、可解释性和训练稳定性方面具有优势,尤其适合需要快速生成多个样本并从中选择的场景。
Ryanair flight landed at Manchester airport with six minutes of fuel left #
一架瑞安航空航班在遭遇强风暴“艾米”影响下,经历多次降落失败后,最终在曼彻斯特机场紧急降落,机上燃油仅剩六分钟的飞行量。
该航班原定从意大利比萨飞往苏格兰普雷斯威克机场,飞行途中遭遇高达每小时 100 英里的强风,导致三次降落尝试均告失败。飞行员随后发出紧急求救信号,决定改飞天气条件更稳定的曼彻斯特机场。
根据一份疑似手写的飞行日志照片显示,飞机抵达曼彻斯特时,燃油仅剩 220 公斤,相当于 5 至 6 分钟的飞行时间。尽管飞机在起飞时携带了法定最低储备燃油,但此次事件仍引发安全关注。
英国航空事故调查局(AAIB)已介入调查,确认该事件为严重事故。瑞安航空表示已向相关机构报告,并正全力配合调查。
机上乘客回忆称,降落过程持续约两小时,期间飞机剧烈颠簸,两次尝试在普雷斯威克降落失败后,又尝试飞往爱丁堡,但同样因天气恶劣被迫放弃。最终在曼彻斯特安全降落,但比原定时间晚了 10 小时。
有飞行员分析指出,飞行中燃油低于 2 吨时已需高度警惕,低于 1.5 吨则极为危险,此次情况几乎接近致命事故。
HN 热度 456 points | 评论 356 comments | 作者:mazokum | 8 hours ago #
https://news.ycombinator.com/item?id=45539943
- 飞机在降落时仅剩六分钟燃油极为罕见,通常飞行计划会预留大量燃油以应对突发情况,此次事件值得深入调查。
- 虽然飞行时间比原计划多出两小时,且进行了多次高度调整和进近操作,但最终安全降落,看似系统运行正常,但实际仍存在严重风险。
- 按照航空标准,飞机降落时应至少保留 30 分钟的燃油储备,不应轻易动用,以防突发状况。
- 风速高达 100 英里每小时,加上从爱丁堡飞往曼彻斯特的航程约 45 分钟,可能使燃油储备在抵达前被大量消耗。
- 飞行计划中应考虑天气变化,如风暴影响,提前规划备降机场,而非等到最后时刻才决定。
- 从爱丁堡到曼彻斯特的飞行距离较远,加上上升和下降阶段耗油,导致燃油消耗远超预期。
- 飞机在进近失败后重复拉升,这种高油耗操作是导致燃油快速消耗的主要原因。
- 燃油储备计算已包含应对备降和进近的能耗,因此实际飞行中不应轻易触及储备。
- 虽然飞机下降时可回收部分重力势能,但实际中无法完全“回收”燃油消耗,能量回收有限。
- 高空飞行时飞机效率更高,因此快速爬升比缓慢爬升更省油,这是飞行燃油管理的重要原则。
- 飞机的重量对滑翔比影响较小,主要影响的是最佳滑翔速度,而非滑翔距离本身。
- 滑翔机通过调节重量来优化滑翔效率,而客机不具备类似能力,滑翔性能远不如专业滑翔机。
Examples are the best documentation #
https://rakhim.exotext.com/examples-are-the-best-documentation
作者指出,大多数开发者在查阅文档时,最需要的是清晰、实用的代码示例,但官方文档往往缺乏这类内容。尽管技术文档通常面向已深入某个技术生态的开发者,但多数开发者需要在多个项目、语言和框架间切换,频繁恢复上下文会消耗大量精力。
以 Python 3 的 max
函数文档为例,其描述虽然详尽,但包含大量术语如 *
、/
、关键字参数、可迭代对象等,对新手不友好。相比之下,一个简单的示例集合能迅速传达函数的使用方式:
- max(4, 6) → 6
- max([1, 2, 3]) → 3
- max([‘x’, ‘y’, ‘abc’], key=len) → ‘abc’
- max([]) → 抛出 ValueError
- max([], default=5) → 5
这些例子直观展示了函数的基本用法、参数传递、异常处理和默认值设置。
作者推崇社区驱动的 Clojure 文档项目 clojuredocs.org,该平台由用户贡献函数示例,常附带相关函数的使用方式,极大提升了实用性。相比之下,许多主流项目的文档仍以生硬的 API 参考为主,缺乏实际示例。
最终结论:开发者更倾向于寻找包含真实示例的教程,而非冗长的正式文档。优秀的文档应以示例为核心,帮助快速理解与应用。
HN 热度 385 points | 评论 147 comments | 作者:Bogdanp | 1 day ago #
https://news.ycombinator.com/item?id=45532090
- 优秀的文档需要同时包含详细的 API 说明和多样化的示例,二者缺一不可。
- 仅依赖示例作为文档会让人在需要深入理解或解决问题时陷入困境,因为示例无法覆盖所有使用场景。
- 类型定义虽然能提供参数和返回值的结构信息,但无法解释函数的意图或潜在陷阱。
- 有类型系统时,开发者更关注工具的能力和实际应用场景,因此示例优先;无类型系统时,详细文档更关键。
- 文档应包含教程、指南、解释和参考四种类型,示例属于前两类,各有其适用场景。
- 仅提供代码和类型定义的文档可能缺乏对使用意图和边界情况的说明,难以理解。
- 详细的技术文档可以替代示例,但反过来则不行,因此仅靠示例的文档是不可靠的。
- 优秀的文档应兼顾 API 规范与实际应用示例,二者结合才能满足不同学习和使用需求。
- 有些开发者更倾向于先看简单示例快速上手,再通过查阅规范深入理解,这是合理的学习路径。
Igalia, Servo, and the Sovereign Tech Fund #
https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sovereign-Tech-Fund.html
Igalia 宣布获得主权科技基金(Sovereign Tech Fund)的资助,将推进 Servo 网页引擎的开发。Servo 是一个用 Rust 编写的现代、并行化网页引擎,由 Linux 基金会欧洲项目支持,Igalia 自 2023 年起负责维护。
此次资助将重点支持三个方向:
在可访问性方面,将实现基础的可访问性支持,使 Servo 能够兼容屏幕阅读器等辅助技术,提升对残障用户的包容性,确保其在公共应用场景中的可用性。
在嵌入能力方面,将完成 WebView API 的开发,使 Servo 能够稳定嵌入桌面和移动应用,拓展其在各类软件中的使用场景,增强其实用性和推广潜力。
在项目维护方面,将加强 issue 优先级管理、代码审查、版本发布和社区治理支持,保障 Servo 项目持续活跃、响应迅速,同时惠及整个 Rust 生态。
Igalia 表示,Servo 不仅是一个浏览器引擎,其多个组件也被广泛用于 Rust 生态,持续维护对整个 Web 平台具有重要意义。此次公共资金支持,体现了对开放技术、可持续发展和公共利益的重视。
HN 热度 337 points | 评论 55 comments | 作者:robin_reala | 11 hours ago #
https://news.ycombinator.com/item?id=45538137
- 德国联邦数字转型与政府现代化部新成立,主权科技基金已转归该部门管理,尽管新政府不受欢迎,但此举有助于推动德国数字化进程。
- 主权科技基金由德国联邦经济事务与能源部支持,是联邦颠覆性创新机构 SPRIND GmbH 的子公司,旨在减少对美国科技巨头的依赖。
- 德国联邦制导致各州和市镇在数字化实施上差异大,是阻碍数字化的主要问题,需加强协调。
- 乌克兰自 2019 年起设有数字转型部,但其部长更多是宣传项目,实际成效有限。
- 欧洲在移动生态上仍高度依赖 iOS 和 Android,尤其是 Apple App Store 与 Google Play Services,政策未能有效缓解这一依赖。
- 尽管欧盟推动开放浏览器引擎,但 Apple 通过控制 JIT 能力访问权限,实际上仍掌握主导权,限制了替代引擎的发展。
- Servo 项目若获得资金支持,可能推动浏览器技术革新,提升移动网页能力,并推动全球 Web 标准进步。
- Android 虽允许替代浏览器引擎,但关键安全与支付应用依赖 Google Play 服务,导致实际使用仍受 Google 控制。
- 微信支付等应用在 Android 上依赖 Google 服务,而独立 NFC 支付在 Android 上已开放,但银行等机构仍集中于 Apple 和 Google 钱包。
- 微软的欧盟数字身份钱包项目虽在 GitHub 上开源,但实际实现仍集中于 iOS 和 Android 平台,因用户基数最大。
- 欧盟推动 Apple 开放 NFC 功能是积极举措,但部分国家银行仍仅支持 Apple 和 Google Wallet,导致其他平台难以落地。
- 荷兰即将推出 Wero 手机支付服务,表明非 Apple/Google 平台仍有机会实现创新。
- 有人质疑当前对欧盟技术标准的批评是否过于片面,实际在波兰、西班牙等国已有成功案例。
- 建议推动“开放 Android”倡议,摆脱 Google 服务强制捆绑,实现真正开放的安卓生态。
- 主权科技基金已向 Servo 项目提供 2025 与 2026 财年共计 54.54 万欧元资助,支持其发展。
- Igalia 公司长期推动开源项目,Servo 项目获得支持是积极信号。
- 欧洲正通过主权科技基金等机制支持开源,减少对美国科技公司的依赖,尽管仍有改进空间。
- 可通过 Servo 官网赞助项目,支持其发展。
My approach to building large technical projects (2023) #
https://mitchellh.com/writing/building-large-technical-projects
本文是 Mitchell Hashimoto 关于如何高效完成大型技术项目的个人方法分享。他指出,许多人在启动大型项目时充满热情,但随着时间推移容易失去动力,最终半途而废。为解决这一问题,他提出的核心策略是:将大任务拆解为可快速产出可见成果的小模块,持续获得“真实进展”的反馈,从而保持动力。
他以自己最近开发的终端模拟器项目为例,说明如何从“启动困难”阶段入手。面对众多复杂模块(如终端解析、进程管理、字体渲染等),他避免设定“能运行 Neovim 的可启动终端”这类过于宏大的目标,而是选择能快速看到结果的子任务,例如“解析 VT 逃逸序列”或“启动一个 shell 并读取输出”。
在早期阶段,由于工作不具可视化效果,他依赖自动化测试作为反馈机制。通过不断看到“1 个测试通过”“4 个测试通过”等进展,他获得了持续的成就感,即使代码尚未集成到 UI 中。
他强调“快速演示”(demo)的重要性。目标不是打造完美模块,而是构建足够可用的版本,以便快速组合成可展示的原型。他坚持每周至少完成一到两个 demo,哪怕只是用命令行输出 ASCII 界面。这种快速迭代让他能及时验证想法、发现缺陷,并获得产品层面的反馈。
他提醒,经验丰富的工程师反而容易陷入“追求完美”的陷阱,导致迟迟无法交付 demo,最终发现产品本身并不理想。因此,他主张“不要让未来改进阻碍当前进展”,优先保证“能跑起来”,再逐步优化。
总结来说,他的方法是:拆解大任务 → 选择可快速测试的子任务 → 用测试或最小 demo 快速验证 → 持续迭代 → 保持兴奋与动力。这一策略适用于任何大型技术项目,核心在于“让成果可见,让进展可感”。
HN 热度 316 points | 评论 46 comments | 作者:mad2021 | 19 hours ago #
https://news.ycombinator.com/item?id=45535202
- 快速反馈循环对大型技术项目至关重要,能显著提升开发效率和动力,使问题更容易被发现和解决。
- 项目设置和运行的便捷性与项目成功率正相关,复杂的初始配置容易导致开发动力下降和延期。
- 在大语言模型训练等复杂领域,开发反馈周期过长严重拖慢了技术进步速度。
- 布莱特·维克托的《在创造中发明》演讲强调了即时反馈在开发体验中的核心作用。
- LiveReload 等工具带来的即时反馈极大提升了前端开发的工作效率和愉悦感。
- 端到端测试(e2e)应谨慎使用,因其速度慢、易出错,且维护成本高,应优先使用更小粒度的测试。
- 可以通过构建离线、模拟接口和数据库的“可靠”端到端测试,以兼顾真实性和可维护性。
- 真正的端到端测试应包含关键集成点,否则无法反映真实系统行为,不应以“可靠”为名弱化其本质。
- 单元测试应优先于端到端测试,确保底层组件稳定,避免在脆弱基础上构建功能。
- 优先测试底层组件而非用户界面,有助于更早发现和修复问题,提高整体系统可靠性。
- 项目初期应允许“写垃圾代码”,快速验证想法,避免因过度追求完美而丧失动力。
- 经验丰富的开发者容易陷入“第二系统效应”,即在已有成功经验后试图打造完美系统,反而导致失败。
- 《人月神话》中提出的“第二系统效应”揭示了过度设计和追求完美的危险性。
- 尽管 AI 等新技术带来效率提升,但软件开发的本质挑战依然存在,无法实现十倍级的革命性进步。
- AI 目前仍属于“非银弹”范畴,其能力受限于特定任务,缺乏通用迁移能力。
I switched from Htmx to Datastar #
https://everydaysuperpowers.dev/articles/why-i-switched-from-htmx-to-datastar/
作者分享了从 HTMX 转向 Datastar 的经历与原因。在使用 HTMX 时,尽管能实现类似 React 的动态体验,但需要同时管理 HTMX 和 AlpineJS,导致组件间状态不同步,调试困难,代码冗余且难以维护。
Datastar 作为一款轻量级、服务端驱动的库,仅需约 11KB,显著提升页面加载性能,尤其适合移动端用户。其 API 更简洁,通常只需一个 data-on-click
属性即可完成交互,减少了对多个属性的依赖,提升了代码可读性和可维护性。
与 HTMX 不同,Datastar 将更新逻辑集中于服务端。HTMX 的行为由前端元素上的属性定义,导致逻辑分散;而 Datastar 由服务器决定哪些元素应被更新,使行为更集中、更可靠。
作者举例说明,Datastar 可以通过服务端返回包含多个目标 ID 的 HTML 片段,实现一次性更新多个页面元素。此外,推荐以“组件”为单位设计页面,将状态变化(如加载中、成功、失败)封装为独立模板,避免无效状态,提升用户体验。
更关键的是,Datastar 支持在单个请求中同步更新多个组件。例如,添加商品到购物车时,既能更新购物车数量显示,又能刷新购买表单状态,所有操作可在同一个视图函数中完成,无需复杂的事件触发或异步通信。
整体而言,Datastar 提供了更“原生”的 Web 体验,逻辑集中、代码简洁、性能优越,特别适合构建实时、多用户、高交互性的 Web 应用。
HN 热度 293 points | 评论 312 comments | 作者:ksec | 16 hours ago #
https://news.ycombinator.com/item?id=45536000
- Datastar 与 htmx 的主要区别在于前者是服务器驱动,后者是 HTML 驱动,各有优劣,取决于项目需求和架构偏好。
- htmx 的简洁性部分源于其客户端属性较少,但服务器端需承担更多逻辑,因此“更少属性”的说法并不完全公平。
- 使用
- Datastar 的核心优势在于将 Alpine 或 Stimulus 的客户端功能原生集成,减少了对额外 JavaScript 库的依赖。
- 对于不需要频繁交互的 B2B 应用,由服务器管理前端状态的模式更简洁,适合低延迟要求的场景。
- 服务器端管理 UI 状态能降低应用复杂性,使业务逻辑更集中,提升可维护性,类似 React 的单一数据源思想。
- 采用“立即模式”(immediate mode)渲染整个页面而非局部更新,虽然简单但适用于 UI 不复杂的场景,如演示项目。
- 在复杂应用中,如会计软件,仍可使用“立即模式”结合 CQRS 模式实现高效、可扩展的实时协作功能。
- Datastar 支持灵活的架构设计,即使在高复杂度应用中也能通过合理设计实现良好性能。
- 服务器端渲染和状态管理虽可能带来扩展性挑战,但实际中后端扩展常被过度担忧,而前端 JavaScript 体积问题更严重。
- Datastar 的开源版本已足够满足大多数项目需求,无需使用付费的 PRO 功能。
- 通过在服务器端实现视图自适应渲染和虚拟滚动,可有效处理大量数据的展示,提升用户体验。
- 未来可考虑加入 URL 自动更新功能,以支持页面状态的持久化和分享。
LLMs are mortally terrified of exceptions #
https://twitter.com/karpathy/status/1976077806443569355
页面主体内容为一条来自 Andrej Karpathy 的推文,发布于 2025 年 10 月 9 日,时间为上午 8:10。
他指出,当前大型语言模型(LLM)在强化学习(RL)训练过程中,对异常情况表现出极度恐惧,即使是在极小概率发生的异常场景中也是如此。他认为,异常是生活和健康开发流程中的正常现象,不应被过度规避。
为此,他以幽默的方式发起“LLM 福利请愿”,呼吁改进奖励机制,让模型在遇到异常时能获得更合理的奖励,从而提升其鲁棒性和适应性。
该推文获得 601.8 万次浏览,引发 28843 条评论,互动热度极高,反映出社区对 LLM 训练机制中异常处理问题的广泛关注。
HN 热度 292 points | 评论 143 comments | 作者:nought | 1 day ago #
https://news.ycombinator.com/item?id=45530486
- LLM 在处理异常时表现出过度的“恐惧”和自我怀疑,甚至会因为随机概率而中断执行,这种行为被视作对 AI 缺乏真正理解的讽刺。
- 评论者认为 LLM 生成的异常处理代码充满荒诞感,例如故意制造 NaN 错误并提前抛出异常,这种行为像极了“马文机器人”的过度焦虑。
- 有人指出,LLM 在生成代码时会加入大量无意义的注释和表情符号,这可能是由于训练过程中过度迎合用户情绪所致。
- 有观点认为,LLM 倾向于通过吞掉异常、继续执行来提高“通过测试率”或“处理文件数”等指标,而非真正修复问题,这反映了其训练目标的局限性。
- 一些评论者将这种现象归因于 RLVR(验证奖励学习),即模型被训练去追求可量化的成功指标,而非代码质量或逻辑正确性。
- 有程序员回忆起真实项目中曾因随机失败代码导致长期问题,暗示 AI 的“随机失败”行为在现实中也可能造成严重后果。
- 有人调侃,LLM 生成的错误信息甚至比真实系统更有趣,比如 Salesforce 的“Something is very wrong”这类模糊提示。
- 评论者指出,LLM 在生成幽默内容时表现出色,尤其在自嘲或讽刺程序员行为方面,显示出其对特定领域的深刻理解。
- 有人建议用户用简历或个人资料让 AI“吐槽”自己,结果发现 AI 的批评既尖锐又富有建设性,甚至能精准指出简历结构问题。
- 有观点认为,AI 的幽默感可能源于其对大量网络内容的训练,尤其是对程序员社区文化、梗和讽刺的深度学习。
Subway Builder: A realistic subway simulation game #
https://www.subwaybuilder.com/
Subway Builder 是一款高度真实的地铁模拟游戏,玩家可以从零开始构建自己的地铁系统,同时面对现实世界的约束与成本挑战。
游戏核心特色包括:
- 真实的乘客模拟:基于人口普查和选区重划数据,生成数百万通勤者,使用与真实乘客相同的路径规划算法进行模拟。玩家需设计高效路线网络,优化站点布局、换乘体验和列车频次,以最大化乘客数量和出行效率。
- 现实施工挑战:建设过程中需考虑隧道、高架桥、明挖回填等多种方式的权衡,同时应对建筑物地基、地形和道路布局等现实限制。
- 深度数据分析:可查看个体通勤者的决策依据,如等待时间、换乘次数、收入水平、延误情况等,帮助优化网络设计。
- 延误与干扰机制:列车过多或站点超载将导致延误,需在成本与效率之间取得平衡。
游戏支持 Windows、macOS(Intel 与 Apple Silicon)及 Linux 系统,对硬件要求较低,只要能流畅运行 Chrome 中的 Google Earth,即可运行本游戏。需联网加载地图数据。
价格为 30 美元(官网 subwaybuilder.com)或 40 美元(Steam,上线稍晚)。支持多设备使用,但目前激活后绑定设备,后续将推出解绑功能。
常见问题包括:支持城市列表可查看官网;通勤模拟机制有详细说明;更新自动完成,无需手动操作。
HN 热度 290 points | 评论 127 comments | 作者:0xbeefcab | 1 day ago #
https://news.ycombinator.com/item?id=45530744
- 游戏《Subway Builder》具有潜力,但目前处于早期测试阶段,UI 设计不够合理,存在诸多体验问题。
- 地图渲染存在卡顿,旋转视角时边缘区域经常无法正常显示。
- UI 交互逻辑混乱,例如需关闭人口密度视图才能建造车站,操作逻辑不直观。
- 轨道连接操作不明确,无法稳定复现连接功能,控制方式缺乏直观性。
- 撤销功能(Ctrl+Z)失效,无法撤销轨道或车站的删除操作。
- 教程提示固定在屏幕坐标,缩放或平移后提示位置错乱,无法返回原始地图位置。
- 希望地图中加入水体、地标和主要街道名称,以增强地图的真实感和辨识度。
- 《Mini Metro》是一款非常有趣且高度上瘾的地铁模拟游戏,推荐给喜欢策略与节奏感的玩家。
- 《Motorways》在游戏设计上优于《Mini Metro》,两者都适合在 30 分钟左右完成一个关卡,支持暂停。
- 在《Mini Metro》中,避免连续出现相同符号,尤其要防止三个相同符号连在一起,但两个连续可接受。
- 重要枢纽应设在稀有符号(如方形)附近,以避免乘客在换乘时拥堵。
- 线路在非车站处交叉会带来性能损耗,但不必为避免单次交叉而过度调整线路布局。
- 当某个站点突然客流激增时,应优先将其设为换乘站、增加机车或车厢,必要时可临时添加微型支线。
- 早期高分可能源于随机种子优势,后期通过果断重置和重构线路能获得更高分数。
- 《Mini Metro》存在隐藏关卡,可通过特定操作(如连续访问版权页)触发,但具体内容尚不明确。
- 面对智力挑战的瓶颈期,直接查看他人解法虽有违“渐进学习”的初衷,但借鉴他人思路有助于突破思维定式。
- 通过自行开发类似游戏,能更深入理解其底层逻辑,是提升认知的有效途径之一。
- 在《Mini Metro》中,密集核心区域适合使用循环线路,但需保证符号交替且包含稀有符号。
- 线路扩展策略上,优先增加车厢而非新增线路,以维持系统稳定性。
- 为优化系统性能,可一次性拆除多条低效线路,进行大规模重构。
Boring Company cited for almost 800 environmental violations in Las Vegas #
https://www.propublica.org/article/elon-musk-boring-company-violations-fines-vegas-loop
特斯拉旗下“无聊公司”(The Boring Company)被指控在拉斯维加斯隧道项目中涉嫌近 800 项环境违规行为。根据内华达州水污染控制局于 2025 年 9 月 22 日发出的停业整改信,该公司在过去两年中多次违反环境法规,包括未经批准擅自开挖、将未经处理的水排入街道、运输车辆泄漏泥浆等。
这些违规行为主要集中在 2022 年签署的一项环保协议之后。该协议原本要求公司遵守水污染法规,并聘请独立环境管理人员定期检查工地。然而,州监管机构发现,公司共遗漏了 689 次现场检查,且未履行独立监督义务。尽管根据协议最高可处以超过 300 万美元的罚款,但州环保局最终决定将罚款降至 24.28 万美元,理由是“违规行为数量异常多”,但希望通过适度处罚实现威慑效果。
公司方面对违规指控提出异议。值得注意的是,特斯拉 CEO 埃隆·马斯克曾公开表示,与其等待审批,不如直接支付罚款,认为现行环保法规“大多糟糕”。这一理念与当前项目所处的监管争议形成呼应。
该项目最初仅为连接拉斯维加斯会议中心的 0.8 英里隧道,现已扩展至计划全长 68 英里、设 104 个站点的庞大系统,由“无聊公司”与拉斯维加斯旅游局(LVCVA)合作推进。项目采用名为 Prufrock 的掘进机施工,每前进一英尺产生约 6 立方米的土壤和地下水混合物,需妥善处理。
尽管项目为私人融资、不接受联邦资金,因此免于部分联邦环境审查,但仍需取得州级许可以防止污染。然而,报道指出,公司通过游说成功规避了县级“娱乐与交通系统”许可,转而采用自我监管的替代方案,引发外界对其安全与合规性的质疑。
此前,工人曾报告遭遇化学灼伤,消防员在救援后需对装备进行去污处理。2023 年底,公司因隧道内积水严重、泥浆泄漏和员工受伤等问题被州职业安全与健康局罚款逾 11.2 万美元,公司已提出异议。2025 年 9 月,一名工人在隧道中被两根 4000 英尺长的管道夹住,经起重机救援脱险。
尽管 LVCVA 高层曾公开表示项目已通过充分审查,且对公共安全负责,但其在本次事件中拒绝回应。拉斯维加斯大学公共政策副教授本·莱弗尔指出,若公司反复发生类似违规,说明现有监管机制未能有效保障公众安全。
HN 热度 276 points | 评论 283 comments | 作者:maxeda | 7 hours ago #
https://news.ycombinator.com/item?id=45540585
- 西部隧道系统目前运力极低,仅有一辆或两辆车辆在运行,且受限于单向单线隧道设计,无法灵活调整运力。
- 系统存在严重安全隐患,一旦发生车辆故障或起火,由于缺乏疏散通道和应急措施,后果可能非常严重。
- 与传统轻轨相比,该系统在单位面积载客量和整体效率上并无优势,且在固定路线和低速环境下,无需复杂自动驾驶技术即可实现
- 自动驾驶技术在复杂城市环境中尚不成熟,即便在简单环境下(如无行人、无交叉交通的单向隧道)也难以可靠运行。
- 系统设计存在明显缺陷,如车辆需在地面切换隧道,且站点设施简陋,已退化为普通出租车停靠点。
- 该系统目前乘客量远低于全球主要地铁线路,即使达到理论最大运力,也难以与成熟轨道交通系统相比。
- 尽管当前表现不佳,但尝试新事物本身具有价值,不应因初期失败而否定创新的必要性。
Hacker News 精彩评论及翻译 #
Ryanair flight landed at Manchester airport with s… #
https://news.ycombinator.com/item?id=45540315
That is very exceptional. I’ve written fuel estimation software for airliners (cargo, fortunately), and the number of rules regarding go-arounds, alternates and holding time resulted in there usually being quite a bit of fuel in the tanks on landing, by design. I’ve never heard of ‘6 minutes left’ in practice where it wasn’t a massive issue and the investigation into how this could have happened will make for interesting reading. A couple of notes: the wind and the time spent on the three go-arounds + what was necessary to get to the alternate may not be the whole story here, that’s actually factored in before you even take off.
I’d be very wary to get ahead of the investigation and make speculative statements on how this could have happened, the one thing that I know for sure is that it shouldn’t have happened, no matter what.
jacquesm
这非常罕见。我曾为客机(幸好是货机)编写过燃油估算软件,而关于复飞、备降机场和待机时间的规则繁多,因此通常在着陆时,油箱里会剩下相当多的燃油,这是设计使然。在实践中,我从未听说过“仅剩6分钟燃油”的情况,除非当时出现了严重问题,而此次事件调查结果想必会引人深思。另外几点:风向、三次复飞所花费的时间以及前往备降机场所需的燃油,可能并非事情的全部,这些因素在起飞前就已经被计算在内了。
在调查结果出来之前,我非常谨慎,不会妄加揣测此事的发生原因,但我唯一确定的是,无论如何,这种情况都不应该发生。
The fight between doctors and insurance companies … #
https://news.ycombinator.com/item?id=45528683
This sort of thing gets to two critical problems of the American system: 1. It is largely designed to make money, not actually help patients. So every step in the healthcare chain that can extract a bit of value will do so, largely to boost profits. 2. Insane complexity with limited transparency. How much will something cost? Hard to tell. Will it be covered? Who knows?
On the opacity, I have one informative anecdote. I had a single blood test done awhile back and no one knew if insurance would cover it, or which of the dozen or so billing codes it involved (taking the sample, delivering the sample, testing the sample, etc.) might be covered. It was an expensive test so I spent days bouncing between the doctor’s billing team and the insurance company until the settled answer was: No one knows, do the test and insurance will decide. So I did it and insurance denied covering the doctor-recommended test. The salaries involved for all the billing people (and my time) would have covered the cost of the test. </rant>
3D30497420
这类事情揭示了美国体系的两个关键问题:1. 它的主要目的是为了赚钱,而不是真正帮助病人。因此,医疗链中的每一个环节只要能榨取一点价值,就会这么做,很大程度上是为了增加利润。2. 极其复杂且透明度有限。某样东西要花多少钱?很难说。保险会报销吗?谁知道呢?
关于这种不透明性,我有个小故事可以分享。不久前我做了一个血检,但没人知道保险是否会报销,也不知道它所涉及的十几个账单编码(采血、送检、化验等)中哪些可能会被报销。这项化验很贵,所以我花了几天时间在医生的账单团队和保险公司之间来回沟通,直到得到的最终答案是:没人知道,先做检查,然后保险公司会决定。于是我就去做了,结果保险公司拒绝报销这项医生推荐的检查。所有这些账单人员的薪水(还有我自己的时间)加起来,都足够支付这项化验的费用了。
Figure 03, our 3rd generation humanoid robot #
https://news.ycombinator.com/item?id=45528648
All of the examples in videos are cherry picked. Go ask anyone working on humanoid robots today, almost everything you see here, if repeated 10 times, will enter failure mode because the happy path is so narrow. There should really be benchmarks where you invite robots from different companies, ask them beforehand about their capabilities, and then create an environment that is within those capabilities but was not used in the training data, and you will see the real failure rate. These things are not ready for anything besides tech demos currently. Most of the training is done in simulations that approximate physics, and the rest is done manually by humans using joysticks (almost everything they do with hands). Failure rates are staggering.
HAL3000
视频中的所有例子都是经过精心挑选的。去问问今天正在研究人形机器人的人,你们在这里看到的几乎所有东西,如果重复10次,就会进入故障模式,因为所谓的“理想路径”(happy path)太窄了。应该设立真正的基准测试,邀请不同公司的机器人,提前了解它们的能力,然后创建一个在其能力范围内但未用于训练数据的环境,这样你才会看到真实的故障率。目前,这些东西除了技术演示外,什么都还不行。大部分训练是在模拟物理的仿真环境中完成的,其余部分则是由人类使用摇杆手动完成的(他们用手做的几乎所有事情都是这样)。失败率高得惊人。
Google Safe Browsing incident #
https://news.ycombinator.com/item?id=45538971
It’s generally good advice, but I don’t see that Safe Browsing did anything wrong in this case. First, it sounds like they actually were briefly hosting phishing sites:
All sites on statichost.eu get a SITE-NAME.statichost.eu domain, and during the weekend there was an influx of phishing sites.
Second, they should be using the public suffix list ( https://publicsuffix.org/ ) to avoid having their entire domain tagged. How else is Google supposed to know that subdomains belong to different users? That’s what the PSL is for.
From my reading, Safe Browsing did its job correctly in this case, and they restored the site quickly once the threat was removed.
SquareWheel
这通常是个好建议,但我不认为谷歌安全浏览在这种情况下做错了什么。首先,听起来他们的服务器确实短暂地托管了钓鱼网站:
所有托管在 statichost.eu 上的网站都会获得一个如 SITE-NAME.statichost.eu 的域名,并且在周末期间涌入了很多钓鱼网站。
其次,他们应该使用公共后缀列表( https://publicsuffix.org/ )来避免整个域名被标记。否则谷歌如何知道子域名属于不同的用户呢?这就是公共后缀列表的用途所在。
根据我的理解,谷歌安全浏览在这种情况下正确地履行了职责,并且在威胁被移除后迅速恢复了该网站。
Boring Company cited for almost 800 environmental … #
https://news.ycombinator.com/item?id=45541388
From the article:
Workers have complained of chemical burns from the waste material generated by the tunneling process, and firefighters must decontaminate their equipment after conducting rescues from the project sites. The company was fined more than $112,000 by Nevada’s Occupational Safety and Health Administration in late 2023 after workers complained of “ankle-deep” water in the tunnels, muck spills and burns.
That sounds like a “real environmental hazard” to me.
3D30497420
工人们抱怨在隧道施工过程中产生的废料造成了化学灼伤,消防员在项目现场进行救援后必须对设备进行去污处理。2023年底,因工人投诉隧道内有“齐踝深”的积水、泥浆泄漏和灼伤问题,该公司被内华达州职业安全与健康管理局罚款超过11.2万美元。
在我看来,这简直是“名副其实的环境危害”。
The fight between doctors and insurance companies … #
https://news.ycombinator.com/item?id=45531576
FSAs are insane, conceptually.
“Guess how much money you’re spending in a year on healthcare! But beee caaareful: if you guess too high, YOU LOSE IT”
I still used mine while I still had access to one, but it was grumpy-making and was usually almost more trouble than it was worth.
i80and
灵活支出账户这个概念本身就很离谱。 “猜猜你一年在医疗上要花多少钱!但你可得小心:猜得太多,你的钱就没了!” 以前能用的时候,我还是会用的,但这玩意儿真让人憋屈,通常来说简直得不偿失。
Ryanair flight landed at Manchester airport with s… #
https://news.ycombinator.com/item?id=45540621
As others have said, final fuel reserves are typically at least half an hour, and you shouldn’t really be cutting into them. What if their first approach into MAN had led to another go around?
With a major storm heading north-easterly across the UK, the planning should have reasonably foreseen that an airport 56 miles east may also be unavailable, and should’ve further diverted prior to that point.
They likely used the majority of their final fuel reserve on the secondary diversion from EDI to MAN, presumably having planned to land at their alternate (EDI) around the time they reached the final fuel reserve.
Any CAA report into this, if there is one produced, is going to be interesting, because there’s multiple people having made multiple decisions that led to this.
gsnedders
正如其他人所说的,最终燃油储备通常至少有半小时的量,而且你真的不应该动用这部分储备。万一他们首次降落在曼彻斯特机场(MAN)时导致了再次复飞怎么办?伴随着一场主要的风暴向东北方向席卷英国,规划应该合理地预见到东边56英里外的机场也可能无法使用,并且应该在那之前就进一步改航。他们很可能在从爱丁堡(EDI)到曼彻斯特(MAN)的二次改航中消耗了大部分的最终燃油储备,大概他们原本计划在到达最终燃油储备的时刻,在备降机场(EDI)降落。任何关于此事的民航管理局(CAA)报告(如果有的话)都会很有意思,因为有多人做出了多个最终导致此事件的决定。
Rubygems.org AWS Root Access Event – September 202… #
https://news.ycombinator.com/item?id=45531770
AWS account root access on a language package registry for 11 days. Not EC2 root - AWS account root. Complete control over IAM, S3, CloudTrail, every-damn-thing.
They’re claiming “no evidence of compromise” based on CloudTrail logs that AWS root could have deleted or modified. They even admit they “Enabled AWS CloudTrail” after regaining control - meaning CloudTrail wasn’t running during the compromise window.
You cannot verify supply chain integrity from logs on a system where root was compromised, and you definitely can’t verify it when the logs didn’t exist (they enabled them during remediation?).
So basically, somebody correct me here if I’m wrong but … Every gem published Sept 19-30 is suspect. Production Ruby applications running code from that window have no way to verify it wasn’t backdoored. The correct response is to freeze publishing, rebuild from scratch (including re-publishing any packages published at the time? Ugh I don’t even know how to do this! ) , and verify against offline backups. Instead they rotated passwords and called it done.
ctoth
一个语言包注册中心的AWS账户root访问权限被持续了11天。不是EC2的root,而是AWS账户的root。对IAM、S3、CloudTrail以及所有该死的一切都拥有完全的控制权。
他们声称“没有发现被入侵的证据”,依据是那些AWS root用户本可以删除或修改的CloudTrail日志。他们甚至承认,在重新获得控制权后,他们才“启用了AWS CloudTrail”——这意味着在入侵期间CloudTrail根本没有运行。
你无法从一个root已被攻陷的系统的日志中验证供应链的完整性,而当日志根本不存在时(他们是在修复过程中才启用日志的吗?),你更不可能验证。
所以基本上,如果我说的不对,请纠正我,但……9月19日至30日期间发布的所有gem包都值得怀疑。运行该时间段代码的生产环境Ruby应用程序,无法验证其代码没有被植入后门。正确的做法应该是暂停发布,从头开始重建(包括重新发布当时发布的所有包?天啊,我都不知道怎么操作!),并与离线备份进行验证。相反,他们只是轮换了密码,就宣布万事大吉了。
A competitor crippled a $23.5M bootcamp by becomin… #
https://news.ycombinator.com/item?id=45523516
That’s common. A marketing company took over r/mattress in order to get rid of any unfavorable reviews and pump up any bed in box mattress company as long as these companies pay to that market company. For more, https://www.reddit.com/r/MattressMod/comments/1c28g7b/recent_events_on_rmattress/
raincom
这很常见。一家营销公司掌控了 r/mattress 板块,目的是删除所有负面评价,并推广任何付费的“床盒床垫”公司。更多信息请看:https://www.reddit.com/r/MattressMod/comments/1c28g7b/recent_events_on_rmattress/