纽约大学数学家特里斯坦·巴克马斯特（Tristan Buckmaster）与Anthropic公司的莱文特·阿尔珀格（Levent Alpöge）近期宣布在纳维-斯托克斯存在性与光滑性问题上取得了进展——这是一个价值100万美元的千禧年大奖难题。他们的研究在人工智能的辅助下完成，但随后OpenAI发布了同一问题的完整证明，引发了巨大争议。 巴克马斯特指控OpenAI在获悉其团队方法论的传闻后窃取了研究成果。他坚称自己的方法非常独特，若非预先获知其进展，人工智能极不可能在几天内复现。此外，巴克马斯特暗示OpenAI可能通过他大量使用其Codex模型的数据获取了他的研究内容。他还声称，一名OpenAI代表曾向他施压，要求其删除阿尔珀格的署名，并在他拒绝后威胁其职业生涯。 OpenAI否认获取了特定的用户数据，坚称其结果是通过下一代模型和巨额算力投入独立实现的。他们坚持认为其证明过程与这两位学者的发现有所不同。这一事件加剧了关于学术诚信、人工智能研究伦理，以及独立研究者与利用庞大计算资源的科技巨头之间巨大权力差距的讨论。
每日HackerNews RSS
抱歉。
水星 2.5 Mercury 2.5
43 天前
我们很高兴发布 **Mercury 2.5**，这是我们迄今为止性能最强的扩散模型（Diffusion LLM）。基于生产环境反馈和真实故障案例构建，它在保持行业领先的速度和效率的同时，实现了比 Mercury 2 高出 40% 的智能提升。
**主要特性：**
* **性能：** 每秒 1,107 个 Token，支持 260K Token 上下文窗口。
* **经济性：** 起价为每百万输入 Token 0.04 美元（发布期间享有 80% 折扣）。
* **能力：** 具备可调推理、并行工具调用以及结构化 JSON 输出功能。
Mercury 2.5 专为搜索代理、语音交互和编程助手等对延迟敏感的应用场景设计，已显著降低了企业用户的成本并缩短了响应时间。
随此次发布，我们还预告了 **Mercury Voice**（针对 170 毫秒以内的低延迟进行了优化）和 **Mercury Router**（一种将查询路由至最适合任务模型的智能系统）。
Mercury 2.5 现已通过 Inception API、Baseten 和 OpenRouter 提供服务。我们正在开发下一代更大规模的模型，并将继续致力于推动基于扩散技术的语言模型发展。请访问我们的文档以开始使用或获取部署福利。
Hacker News 社区正在讨论 Inception Labs 发布的 Mercury 2.5 模型。该模型的独特之处在于其采用了基于扩散（diffusion-based）的架构，而非标准的下一个词预测（next-token prediction）架构。
讨论的主要要点包括：
* **性能与速度：** 用户称赞该模型速度极快，这使其在实时语音代理等低延迟应用场景中极具吸引力。虽然它并非“前沿”模型，但被认为是一款功能强大且具有成本效益的通用聊天机器人。
* **架构：** 与典型的 LLM 不同，Mercury 可以一次性生成并去噪整页文本，开发者认为这一特性在技术上非常有趣。
* **局限性：** 批评者指出，与顶级模型相比，该模型在处理复杂的代理编码任务和工具调用方面仍显吃力。一些用户还对其未能开源权重表示失望。
* **应用场景：** 许多人认为，在延迟为关键制约因素的多模型系统中，它是高速子任务或“仲裁者”的有力候选者。
总的来说，尽管人们对它能否与领先模型竞争持怀疑态度，但社区认可它在推理成本和延迟为首要考量的商业环境中具有独特的价值。
Deltafin 是一个实验性的开源 Rust 项目，旨在在消费级硬件上运行完整、未经剪枝的 2.8 万亿参数 Kimi K3 模型。与其他通过压缩或剪枝专家权重来换取速度的实现不同，Deltafin 保留了原始模型的完整性，确保 Kimi K3 成为生成每一个 token 的唯一权威。 该项目专注于原始质量和极致优化，利用专家预取和高效存储处理（通过 ARGODRIVE）等技术，在本地固态硬盘上管理庞大的模型。用户既可以运行完整的 1.7TB 模型，也可以按需流式加载以节省空间。虽然该项目包含可选的较小草稿模型（如 Qwen）来加速文本补全，但这些猜测始终会经过完整 K3 模型的验证，以确保输出质量完全一致。 Deltafin 提供了命令行界面和一个兼容 OpenAI 的本地集成服务器。作为一项旨在突破家庭托管 AI 边界的研究工作，它证明了通过严谨的工程设计，无需牺牲模型性能也能实现前沿规模的计算能力。该软件在 MIT 许可证下发布，并对原始 Kimi K3 权重及相关技术提供了完整署名。
Argonautlabs 最近的一个项目展示了如何在 M5 Max MacBook Pro 上本地运行 Kimi K3（一个 2.78 万亿参数的模型）。由于该模型 1.45 TB 的权重远超机器 128 GB 的内存，系统通过四个雷电 5 (Thunderbolt 5) 固态硬盘流式传输专家权重。
其性能约为每秒 1 个 token，且在“预填充”（处理初始提示词）阶段有明显的延迟。尽管 Hacker News 上的评论者质疑这种低速运行的实用性，但作者认为该项目适用于无人值守的定时批处理任务（例如月底数据核对），在这些场景下，数据隐私和模型能力优于实时交互。
该项目凸显了在消费级硬件上运行“前沿规模”模型所面临的技术障碍，特别是在 I/O 瓶颈和内存带宽方面。作者强调，该项目的价值在于探索并拓展本地私有计算的极限，而非追求实时聊天性能。有关优化 SSD 读取路径和调度机制的详细研究结果，已记录在项目存储库中。
抱歉。
2010年哈佛大学的一项研究揭示了一个简单的真理：思绪游离的人更不快乐。无论从事何种任务，全心投入（即使是在处理平凡的工作）所带来的满足感，远胜于精神上的漫游。
对于高潜力的职场人士来说，这形成了一种独特的“折磨”。能够构想出无限的职业路径本是职业资产，却往往演变成思维陷阱。他们不断将现状与理想化、虚构的职业轨迹进行对比——比如“如果我是创始人会怎样”或“如果我在独角兽企业会怎样”——这使得他们在情感上与实际工作产生了疏离。
这种持续的职业思绪游离状态，阻碍了深度的投入、有意义人际关系的建立以及真正的满足感。由于这些人将当前的工作仅视为众多选项之一，他们从未完全投入当下。结果便陷入了不安的循环：他们生活在想象的未来中，而真实的职业生涯却成了背景噪音。
真正的满足感不在于寻找“最优”路径，而在于保持专注的自律。若想获得成就感，高潜力人才必须停止将职业生涯视为一场持续的计算，转而致力于在当下深耕，创造有意义的成果。关键不在于可能性，而在于活在当下。
这篇 Hacker News 帖子探讨了“选择项的暴政”——即认为自己必须时刻保持选择开放，以找到“最佳”人生路径所带来的心理负担。评论者引用奥利弗·伯克曼（Oliver Burkeman）的《四千周》一书，就这究竟是一种真实的挣扎，还是现代特权阶层的症状展开了辩论。
观点呈现出两极分化。一些用户认为，真正的满足感需要“全情投入”——选定一条路，接受其不完美，并放弃对假设性替代方案的渴望。他们强调，正念与专注是消除这种心理噪音的解药。
另一些人则持反对意见，斥其为“AI 废话”或精英阶层的自我放纵。批评者认为，人们应该在当前的工作中寻找尊严，而不是沉迷于职业优化。相反，也有人坚持认为，对于高成就者而言，职业成就感是自我认同的重要组成部分，而非仅仅是奢侈。最终，这场讨论凸显了两种观点之间的分歧：一方将不快乐视为未能珍惜现状的失败，而另一方则将其视为野心和人类潜能必然产生的副产品。
“函数颜色”之争往往错误地将任何必需参数（如 Go 语言的 `context.Context`）等同于颜色。作者认为，真正的“颜色”取决于变更如何在调用栈中传播。
在标准编程中，变更具有**封装性**：对底层函数的修改仅影响其直接调用者，开发者可以轻易阻止该变更向栈顶蔓延。相比之下，函数“颜色”会产生一种**链表式依赖**，即底层的变更不仅是简单传递，还会不可避免地对调用栈上的每一个函数提出强制性要求。
真正的颜色变更会绕过结构化编程的优势，而结构化编程存在的意义正是为了将高层函数与底层实现细节隔离开来。虽然某些语言特性（如 Haskell 的 `STM` 单子）通过跨层强制约束表现出部分“颜色”特征，但大多数语言特性并非颜色，因为它们允许开发者对变更进行封装。归根结底，只有当语言设计阻碍开发者停止变更传播，并迫使整个调用链必须符合新约束时，“颜色”才会产生。
这篇 Hacker News 的讨论聚焦于“函数染色”（function coloring）的争论，该讨论由一篇题为《函数参数不是函数颜色》（*Function Arguments Are Not Function Colors*）的文章引发。
参与者围绕 `async/await`、`Context` 或单子（monads）等语言特性是否构成“函数染色”展开了深入的技术辩论。许多用户认为这种区分带有主观性，并指出尽管某些特性会强制改变调用栈上下游的代码，但这往往是为了安全或模块化而做出的刻意权衡。
主要主题包括：
* **实践与理论：** 持怀疑态度的人认为，“函数染色”并非正式的编程语言理论，而是一个用来形容在代码库中传播需求（如依赖注入或异步状态）所带来的“痛苦”的口语化术语。
* **依赖管理：** 一些评论者认为，如果系统要求此类向上传递的更改，则表明设计存在缺陷；而另一些人则认为，类型系统只是在通过强制显式依赖来履行其职责。
* **JavaScript 的“稻草人”论点：** 该帖中还有一段为 JavaScript 辩护的附带讨论，暗示批评者往往聚焦于该语言的历史缺陷，却忽视了其演进、生态系统及其主导地位。
总体而言，社区对于“函数染色”是否为评估语言设计的有用框架，仍存在分歧。
请提供您需要翻译的内容。
Meta 推出了 **Muse**，这是一个个人 AI 智能体，旨在通过访问用户的电子邮件、浏览器和账户来处理购物、行程规划和日程管理等任务。
Hacker News 社区的反应呈现出严重的两极分化，主要集中在以下两个方面：
* **隐私与信任：** 技术圈用户达成了一种压倒性的共识，即对 Meta 抱有极深的不信任感。许多人认为，鉴于 Meta 在数据剥削、侵入式追踪以及平台质量恶化（enshittification）方面的历史，它是最不值得托付私人通信和财务数据的公司。批评者将 Muse 视为一种“特洛伊木马”，旨在以提供便利为幌子，获取更私密的用户信息。
* **目标受众与“极客”的对比：** 参与讨论者承认，普通大众可能会忽略这些隐私问题，而优先考虑易用性。虽然 Hacker News 上的资深用户倾向于使用自托管或手动流程，但大家普遍认为，普通消费者往往会默认使用那些预装或大力推广的工具。
尽管一些早期测试者对该智能体的速度和精美的界面表示赞赏，但许多怀疑论者认为这是一种“为了解决问题而创造出的问题”，它优先考虑的是商业利益（广告和购物）而非真正的用户价值，这也反映了科技行业在设计工具时，往往更倾向于利用而非赋能用户的普遍困境。
本文解释了 GCC 如何实现嵌套函数，特别是那些访问父作用域变量的函数。 GCC 没有使用（旧语言中常见的）栈帧指针，而是在早期的中间端阶段对嵌套函数进行降级处理。它将所有被访问的父变量打包到一个“帧”结构中，并将指向该结构的指针作为隐藏参数传递给嵌套函数。这种方法使该特性与编译器特定的栈管理解耦，并允许标准优化器像处理其他数据结构一样处理该帧。 作者指出，虽然 C++ Lambda 表达式和 GCC 嵌套函数在语法上有表面的差异，且 C++ 使用了独特的匿名“伏地魔”（Voldemort）类型，但它们的核心实现却极为相似。两者都将嵌套代码转换为持有捕获变量的对象或结构。一个关键的技术区别在于，GCC 可能会将所有嵌套函数聚合到一个共享帧中，而 C++ 通常为每个 Lambda 创建单独的对象。最终，作者总结道，GCC 嵌套函数在语义上是 C++ Lambda 的一个子集，现代编译器完全可以使用相同的基础设施轻松支持两者。
这篇 Hacker News 讨论批评了一篇主张在 C 标准中引入 GCC 风格嵌套函数的文章。评论者指出，作者忽视了重大的技术挑战，尤其是将嵌套函数作为指针传递时所需的“蹦床（trampolines）”机制——这种机制通常需要可执行栈或特定的 ABI 支持，从而带来了安全性和可移植性风险。
相比之下，参与者指出 C++ 的 Lambda 表达式通过将闭包视为对象而非原生指针，更有效地处理了这些问题。D 语言开发者 Walter Bright 强调了 D 语言如何通过“委托（delegates）”避免这些问题；委托将函数指针与指向外围作用域的静态链接配对，创建了一种类似于 C++ 成员函数、且与 ABI 兼容的结构。
总体而言，人们普遍认为，虽然嵌套函数提供了语法上的便利，但它们引入了复杂的语义和优化障碍。现代编译器设计倾向于采用基于闭包的模型，因为它们避免了 GCC 实现中固有的栈操作陷阱；这些陷阱会迫使变量溢出到内存而非保留在寄存器中，从而对性能产生负面影响。
原定于今天下午降落在伦敦希思罗机场的至少 22 个航班已被改降至英国及欧洲各地的机场。 此次改降影响了广泛的国际航班，包括来自东京、洛杉矶、新加坡和迪拜的长途航班。虽然许多飞机被改道至斯坦斯特德、曼彻斯特、盖特威克、伯明翰、卢顿和格拉斯哥等英国区域枢纽，但其他航班被迫降落在更远的巴黎、法兰克福、布鲁塞尔和阿姆斯特丹等城市。这些中断严重影响了希思罗机场整个晚上的运营。
英国空中交通管制（ATC）出现重大故障，导致全国范围内航班大面积取消，出行受到严重干扰。相关部门正在努力修复系统故障。
Hacker News 的用户正在讨论此次事件，指出中央集权式航空基础设施的脆弱性，以及航空公司缺乏可靠的实时沟通。讨论重点包括：
* **系统可靠性：** 许多评论者担心，英国空中交通服务提供商（NATS）的单一软件故障竟能导致全国领空停摆，这引发了对加强冗余和 A/B 系统测试的呼吁。
* **乘客权益：** 用户们分享了关于乘客权益的指南，指出虽然航空公司在 ATC 故障期间通常无需承担金钱赔偿责任（因为这被视为“特殊情况”），但旅客仍有权要求报销餐费、住宿费，在某些情况下还可以获得全额机票退款。
* **对沟通的不满：** 一个反复出现的主题是航空公司向滞留乘客提供的信息质量低下，许多人批评航空公司将规避法律责任置于提供清晰、及时的更新之上。
此次事件重新引发了关于关键基础设施私有化、航空旅行的必要性，以及现代化航空遗留软件所面临的持续挑战等长期争论。
请启用 JavaScript 和 Cookie 以继续。
Hacker News 社区对 OpenAI 发布 ChatGPT Images 2.5 的看法存在严重分歧。
**技术性能：** 开发者报告称速度有显著提升，延迟从超过 100 秒降低至约 35–40 秒。早期测试表明，新模型在参考图像的遵循度以及处理复杂任务（如风格化）方面表现更好，但一些用户指出，模型在手部结构和微小文字等细节处理上仍存在遗留问题。
**社会影响：** 该帖引发了关于生成式 AI “反乌托邦”本质的激烈辩论。批评者认为，这项服务助长了懒惰，在营销和菜单设计中推行“AI 垃圾内容”，并带来虚假信息和数据隐私方面的风险。许多人对日常生活中 AI 生成内容的常态化表达了不满。
**辩护观点：** 相反，支持者认为该工具是一种无害、有趣且能赋能个人的方式，可用于迭代个人项目，例如家居装修效果图、故事可视化，或仅仅是出于娱乐目的进行尝试。支持者反驳了“垃圾内容”的叙事，认为这是一种个人表达的工具，并指出将资源消耗问题与高尔夫或商业旅行等其他非必要社会活动相比时，针对 AI 的担忧往往被夸大或具有双重标准。