2025 12 18 HackerNews

2025-12-18 Hacker News Top Stories #

Astral 发布用 Rust 编写的极快 Python 类型检查器与语言服务器 ty Beta，主打增量计算、低延迟编辑反馈与开源集成。

文章批评现代图形 API（如 DX12/Vulkan/Metal）过于复杂且不适配当代 GPU，主张回归基于现代硬件特性的更简单设计。

文章指责 Mozilla 高层暗示可能削弱广告拦截功能，会损害 Firefox 的隐私立场与用户信任。

作者预测大语言模型将大幅降低形式化验证成本并推动其普及，但规格制定与行业文化仍是主要障碍。

GitHub 推迟对自托管 Actions 运行器收费、下调托管运行器价格并引入小额云平台费，同时承诺改进自托管扩展与扩缩工具。

Google 发布面向速度与效率的 Gemini 3 Flash，声称在推理速度、成本与多模态能力上显著优于前代。

Waterfox 回应称不会在可预见未来集成不可审计的大模型，强调浏览器应保持可控性、透明与用户自主。

OpenAI 推出 GPT Image 1.5（gpt-image-1.5），大幅提升图像生成与编辑的局部修改、风格迁移和文本渲染能力并在 ChatGPT 中上线。

Coursera 与 Udemy 达成全股票合并协议，合并后保留 Coursera 品牌并预计实现收入与成本协同，交易需监管与股东批准。

Astral 团队发布 ty 的 Beta 版本 (Announcing the Beta release of ty) #

https://astral.sh/blog/ty

Astral 团队今日宣布推出其新工具 ty 的 Beta 版本。ty 是一个用 Rust 编写的极快 Python 类型检查器和语言服务器，旨在替代 mypy、Pyright 和 Pylance 等现有工具。

ty 的设计核心是“增量计算”，专为语言服务器优化，能够在编辑文件或修改函数时仅重新计算必要部分，实现极低延迟的实时反馈。在 PyTorch 项目中，ty 仅需 4.7ms 即可重新计算诊断结果，相比 Pyright 的 386ms 快 80 倍，比 Pyrefly 快 500 倍。

在性能方面，ty 无需缓存时比 mypy 和 Pyright 快 10 至 60 倍，尤其在编辑器中表现更为突出。其底层架构借鉴了 Ruff 和 uv 的设计理念，强调极致性能、正确性与用户体验的平衡。

ty 提供业界领先的诊断系统，灵感来自 Rust 编译器，能跨文件提供上下文信息，清晰指出错误原因并建议修复方式。例如，当赋值类型不匹配时，会同时显示赋值位置和对应声明位置的问题。

支持主流编辑器，可通过 VS Code 扩展使用，兼容 LSP 协议，提供 Go to Definition、自动补全、自动导入、语义高亮、内联提示等现代语言服务器功能。

当前目标是通过 Beta 版本收集早期用户反馈，后续将重点提升稳定性、完善 Python 类型规范支持，并增强对 Pydantic、Django 等流行库的原生支持。

长远来看，ty 将成为 Astral 工具链的核心，推动更多高级功能，如死代码消除、未使用依赖检测、语义版本兼容性检查、CVE 可达性分析、类型感知 linting 等。

项目开源，采用 MIT 许可证，欢迎社区贡献。团队特别感谢核心开发成员及来自 Salsa、Elixir、Python 类型社区等多方的技术支持与协作。

Astral 致力于让 Python 成为地球上最高效的编程生态系统，ty 将持续每周迭代，不断优化，与用户共同打造更好的开发体验。

HN 热度 815 points | 评论 150 comments | 作者：gavide | 1 day ago #

https://news.ycombinator.com/item?id=46294289

Pyright 在类型检查方面表现优秀，但其性能较慢，影响了开发体验。
类型检查器的性能、错误信息质量、编辑器集成和用户体验等非规范性因素对实际使用影响更大。
类型检查规范主要关注显式类型注解的语义，不涵盖推断、诊断、配置和新功能实现等关键方面。
Pyright 会将未标注的集合推断为 Unknown 类型，其语义等同于 Any，但能提供更严格的诊断。
一些用户因 Pyright 依赖 Node.js 和 npm 而对其持保留态度，更倾向于使用原生 Python 实现的工具。
ty 作为新发布的类型检查器，已在 Emacs 中初步测试表现良好，未来可能成为长期使用的选择。
类型检查器的性能虽重要，但实际使用中很少成为主要瓶颈。
与 Pyright 相比，ty 在速度和 LSP 集成方面有明显优化潜力，有望提升开发体验。
类型检查器的特性对比表无法全面反映实际使用中的差异，如诊断行为、默认配置和扩展能力。
基于 Pyright 的 Basedpyright 提供了增强功能，但与 AI 生成代码结合时可能带来复杂性。
AI 生成的 Python 代码与某些类型检查器（如 Basedpyright）结合时可能引发难以处理的问题，需配合钩子和额外配置。

无图形 API (No Graphics API) #

https://www.sebastianaaltonen.com/blog/no-graphics-api

本文探讨了现代图形 API 的复杂性及其历史根源，指出当前图形 API（如 DirectX 12、Vulkan、Metal）的设计已不再适应现代 GPU 的发展。作者认为，这些“现代 API”诞生于 10 年前，当时 GPU 架构高度异构，需要通过持久化的管线状态对象（PSO）来减少运行时开销。然而，如今的 GPU 已普遍具备完整的缓存层次结构、统一内存访问、64 位 GPU 指针支持以及无绑定（bindless）纹理采样，使得许多早期设计的必要性已不复存在。

文章指出，当前 API 的复杂性导致了严重的 PSO 组合爆炸问题——游戏需缓存数以万计的 PSO 变体，本地缓存动辄超过 100GB，严重影响加载性能和游戏流畅度。相比之下，早期的 Mantle 和主机端 API（如 PS4/Xbox One）因专为单一现代架构（AMD GCN）设计，无需复杂映射与预处理，API 更简洁高效。

作者回顾了图形 API 的发展历程，从 1998 年的 3dfx Voodoo 2 到 NVIDIA GeForce 256，指出早期硬件高度专用化，API 设计受限于硬件差异，导致长期的向后兼容性负担。如今硬件已趋统一，现代 GPU 支持 CPU 直接写入 GPU 内存、统一地址空间和可编程通用计算，完全有能力支持更轻量、更直接的图形编程模型。

结论是：我们应重新思考图形 API 的设计，摆脱对持久化状态对象的依赖，回归更简单、更高效的编程方式。未来的图形 API 应基于现代硬件能力，大幅简化 API 表层，减少驱动层负担，提升开发效率与运行性能。

HN 热度 800 points | 评论 154 comments | 作者：ryandrake | 1 day ago #

https://news.ycombinator.com/item?id=46293062

当前的 DirectX 12 和 Vulkan API 存在诸多问题，如 DX12 缺乏对缓冲区指针的支持，Vulkan 1.0 版本后缺乏统一更新，且驱动支持不一，导致开发者难以使用。
Vulkan 的复杂性使得开发者难以掌握同步机制，导致过度使用屏障和刷新，反而造成性能下降，而旧的 API 通过智能驱动可更好地优化性能。
新的图形 API（如 Vulkan 和 DX12）在实际应用中反而可能比旧 API 更慢，主要因为需要预编译大量管线状态，且运行时仍可能出现编译延迟。
旧 API 通过高级着色器和扩展技术已能实现单次绘制调用渲染大量复杂对象，使性能瓶颈大幅降低，这在当时已接近极限。
尽管 Vulkan 统一了桌面与移动平台的 API，但两者在硬件架构和驱动质量上差异巨大，导致实际开发中仍需大量适配，反而增加了复杂性。
在移动设备上，尤其是 Android 平台，GPU 驱动更新滞后，导致 Vulkan 的新特性无法普及，部分设备上 OpenGL ES 反而表现更优。
桌面与移动 GPU 的差异过大，应设计为两个独立的 API 风格，而非强行统一，OpenGL ES 与 OpenGL 的分离模式更具合理性。
一些非游戏类应用（如图像编辑、视频处理、计算任务）受益于统一 API，因此 Vulkan 的统一设计仍有其价值。
任天堂 Switch 等设备虽使用桌面级 GPU，但其硬件已落后，且与主流移动 GPU 差异明显，说明“移动”与“桌面”界限模糊，统一 API 的实际意义有限。

Mozilla 是不是在自取灭亡？ (Is Mozilla trying hard to kill itself?) #

https://infosec.press/brunomiguel/is-mozilla-trying-hard-to-kill-itself

作者对 Mozilla 新任 CEO 在《The Verge》采访中提及可能禁用 Firefox 广告拦截功能一事表达了强烈担忧。该 CEO 虽表示不打算实施此措施，因其“违背使命”，但承认此举可为公司带来额外 1.5 亿美元收入。作者认为，这番言论暗示该选项仍被认真考虑，令人不安。

作者回顾自己长期使用 Firefox 的经历，强调 Firefox 的核心吸引力在于对开放网络标准的坚持、强大的扩展系统以及对用户隐私的保护。广告拦截功能不仅是用户体验的重要组成部分，更在当前网络环境下成为一种必要的安全防护，尤其针对恶意广告（malvertising）。

作者担心，若 Mozilla 放弃这一关键优势，将严重削弱其与基于 Chromium 的浏览器（如 Chrome）的差异化竞争力，进而伤害其核心用户群体——那些重视隐私、技术素养高的极客与爱好者。这部分用户不仅是 Firefox 的忠实支持者，也是普通用户获取技术建议的重要来源。

作者指出，虽然理解 Mozilla 需要盈利，但 CEO 公开谈论一个“不愿做但可做”的策略，极易引发负面舆论，损害品牌形象。他质疑这种表态的必要性，认为这可能暴露公司内部在使命与商业利益之间的矛盾。

整体来看，作者对 Mozilla 未来方向感到失望与忧虑，认为此举可能加速其衰落，呼吁 Mozilla 回归初心，坚守开放网络的使命。

HN 热度 795 points | 评论 715 comments | 作者：pabs3 | 14 hours ago #

https://news.ycombinator.com/item?id=46299934

有人认为 Mozilla 高管声称不会通过阻止广告拦截器来获取 1.5 亿美元收入，是因为这不符合其使命，但这种说法被质疑为自相矛盾，暗示其实际可能仍会采取此类措施。
有用户表示使用 Firefox 的主要原因就是能够运行 uBO（uBlock Origin）等广告拦截扩展，若 Mozilla 限制此类功能，将立即转向其他浏览器。
有人指出，没有广告拦截器的浏览体验存在严重安全隐患，曾因未禁用广告拦截器而遭遇恶意软件感染，因此坚决反对 Mozilla 削弱广告拦截功能。
有用户对比了 Ungoogled Chromium 与 Firefox，认为尽管 Ungoogled Chromium 更注重隐私，但其资源占用过高，导致系统不稳定，最终仍选择回归 Firefox。
有人强调广告拦截不仅提升浏览体验，还能有效保护隐私，防止用户数据被大量追踪和泄露。
有人指出，即使使用 Tor 和 VPN，也无法完全避免服务器端数据收集和指纹识别，广告拦截只是缓解部分问题。
有人认为广告拦截的真正价值在于改善网页可用性，而非隐私保护，对广告的容忍度极低。
有人提到 uBlock Origin 配合 Tampermonkey 是屏蔽弹窗和网页干扰的必要组合，而某些浏览器（如 Brave）的内置广告拦截功能远不如 uBO 强大。
有人认为 JavaScript 的过度使用是网页性能和安全问题的根源，主张限制其使用范围，只允许必要功能运行。
有人建议开发类似 NoScript 但更智能的扩展，能基于公开数据库自动识别并允许必要脚本，同时阻止其他有害代码。
有人认为广告拦截并非绝对必要，取决于用户使用的浏览器类型和网络工具，例如在文本浏览器或自定义 HTTP 客户端中无需广告拦截。
有人指出，Firefox 本身与 Google 合作，将搜索数据发送给广告平台，其设计本质仍服务于广告生态，因此用户需要依赖广告拦截来获得更健康的浏览环境。

AI 将推动形式化验证走向主流 (AI will make formal verification go mainstream) #

https://martin.kleppmann.com/2025/12/08/ai-formal-verification.html

本文作者 Martin Kleppmann 预测，人工智能（AI）将推动形式化验证技术从边缘走向软件工程主流。

形式化验证是一种通过数学证明确保代码符合规格的方法，已有工具如 Isabelle、Lean、F*和 Agda 等支持。尽管已有成功案例，如验证过的操作系统内核和编译器，但其应用受限于高昂的人力成本和专业门槛——例如，seL4 微内核的验证耗时 20 人年，需 20 万行证明代码，远超实现代码量。

当前，形式化验证因成本过高而难以普及，尤其在工业界。然而，随着大语言模型（LLM）在编写代码和证明脚本方面能力提升，这一局面正在改变。AI 可辅助甚至自动化生成证明，而验证器会自动拒绝无效证明，确保结果可信。

作者认为，AI 生成代码的不确定性，恰恰需要形式化验证来保障可靠性。当 AI 能自动证明其生成代码的正确性，开发者将更愿意采用 AI 代码而非人工编写但可能含错的代码。

此外，AI 还可协助编写形式化规格说明，尽管存在自然语言与形式语言转换的潜在风险，但整体可控。未来，开发者可能只需声明期望的系统行为，AI 即可自动生成代码与证明，无需人工审查。

总结三点：形式化验证成本将大幅降低；AI 代码需要形式化验证以替代人工审查；形式化验证的精确性可弥补 AI 的不确定性。三者结合，使形式化验证有望在不久的将来成为主流。届时，真正的挑战将不再是技术，而是行业文化的转变。

HN 热度 788 points | 评论 401 comments | 作者：evankhoury | 1 day ago #

https://news.ycombinator.com/item?id=46294574

AI 推动形式化验证主流化，但行业仍难以达成对软件需求的明确共识，这本质上是文化和激励机制问题。
形式化验证的瓶颈在于从自然语言需求到精确规格的转换，而非代码实现本身，这一过程需要专业且善于沟通的技术人员。
一个形式化验证的程序仍可能有缺陷，因为规格本身可能未能准确反映实际需求，这并非程序错误而是理解偏差。
软件质量控制应分为“验证需求”和“验证适用性”两个层面，形式化验证只能解决前者，后者仍需依赖实际使用反馈。
将需求转化为可维护规格的过程始终依赖人类专家，即使工具链再先进，也无法完全自动化。
大多数软件开发的本质是通过试错来探索需求，而非预先定义完整规格，因此形式化验证难以普适。
形式化验证更适合数学性强、边界清晰的底层系统（如解析器、压缩算法），对复杂交互系统帮助有限。
与形式化验证相比，AI 驱动的视觉回归测试可能对日常开发产生更大实际影响。
试图用形式化方法验证规格本身可能导致“过度工程化”或陷入无尽循环，反而增加复杂性。

GitHub Actions 定价调整：推迟自托管运行器收费，优化产品体验与用户信任 (Pricing Changes for GitHub Actions) #

https://resources.github.com/actions/2026-pricing-changes-for-github-actions/

GitHub 宣布推迟原定于 2026 年 3 月 1 日实施的自托管 GitHub Actions 运行器收费政策，以有更多时间重新评估该策略并听取开发者、客户和合作伙伴的反馈。此举旨在改善 GitHub Actions 的产品体验，重建用户信任。

尽管自托管运行器将推迟收费，但 GitHub 仍将继续推进 GitHub 托管运行器价格下调计划，自 2026 年 1 月 1 日起，托管运行器价格将降低最高达 39%，具体降幅取决于所使用的机器类型。该降价由整体运行器价格下调约 40% 与新增的每分钟 0.002 美元的 GitHub Actions 云平台服务费共同构成，但该服务费已包含在新的托管运行器定价中。

新增的云平台服务费将适用于所有 GitHub 托管和自托管运行器工作流，但不影响公共仓库的使用，且 GitHub 企业服务器客户不受影响。该费用将于 2026 年 3 月 1 日起正式实施。

GitHub 表示，此次调整是为了更准确地反映服务使用成本，并支持平台持续创新。目前已有 96% 的客户不会受到价格变化影响，其中 85% 的受影响客户将实际支出减少，仅 15% 的客户面临小幅上涨，平均增幅约 13 美元。

为提升自托管运行器体验，GitHub 将加大投入，推动更广泛的平台支持，包括 Windows、容器、虚拟机、云实例和裸金属服务器的自动扩展能力。2026 年将推出“GitHub Scale Set Client”——一个轻量级 Go SDK，帮助企业在不依赖 Kubernetes 或 ARC 的情况下构建自定义自动扩展解决方案，支持任务队列管理、安全配置与智能扩展逻辑。

GitHub 强调，平台将持续优化 Actions 的可靠性、性能与可扩展性，以支持企业级 CI/CD 需求，并为未来智能工作负载提供安全、开放的平台基础。同时，GitHub 已开放公开讨论，收集用户反馈，用于指导后续产品路线图。

HN 热度 775 points | 评论 802 comments | 作者：kevin-david | 1 day ago #

https://news.ycombinator.com/item?id=46291156

开发者应从依赖专有软件的教训中吸取经验，推动团队和管理层转向社区维护的自由开源替代方案，即使功能稍逊，也更可靠且不会对用户采取敌对策略。
企业更看重托管服务、集中化平台和发票支持，而非软件是否开源，因此自建系统在商业环境中难以推广。
尽管自托管 GitLab 或其他开源工具在初期投入巨大，但长期来看可能更可控，且能避免专有平台的不可预测变化。
自托管 CI/CD 系统虽然初期构建复杂，但通过完全代码化、无状态和可重复部署，可以实现可持续维护，甚至提升测试能力。
一些开发者认为，自建系统如 Gitea、Forgejo 等在性能和体验上优于 GitHub，尤其在本地部署时响应更快、更轻量。
与 GitHub 相比，自托管平台如 Codeberg、Forgejo 提供了更好的隐私控制和数据备份能力，且无锁定风险。
自托管系统需要持续投入维护、安全更新和性能优化，对团队的技术能力和纪律要求较高，难以在大规模团队中普及。
专有平台如 GitHub 提供了开箱即用的完整生态，包括 CI/CD、部署、协作工具等，而开源替代品在用户体验和功能集成上仍有差距。
一些开发者指出，GitHub 的价格调整和功能强制推送（如 Copilot）反映出其对用户利益的忽视，企业应警惕此类风险。
有观点认为，与其为专有平台付费，不如将资源投入开源社区，共同改进自由软件，实现更长期的可持续发展。

Gemini 3 Flash：为速度而生的前沿智能 (Gemini 3 Flash: Frontier intelligence built for speed) #

https://blog.google/products/gemini/gemini-3-flash/

Google 今日发布 Gemini 3 Flash，这是 Gemini 3 系列中最新推出的高性能、低成本 AI 模型，专为速度与效率而设计，旨在让每个人都能更快地学习、构建和规划各种任务。

Gemini 3 Flash 在保持 Gemini 3 Pro 级别推理能力的同时，实现了 Flash 级别的响应速度和运行效率，显著降低使用成本。它特别适用于编程、复杂分析以及需要快速反馈的交互式应用。

该模型现已作为默认选项，上线于 Gemini 应用和 Google 搜索的 AI 模式中。开发者可通过 Google AI Studio、Gemini CLI、Google Antigravity、Android Studio、Vertex AI 和 Gemini Enterprise 等平台访问。

在性能方面，Gemini 3 Flash 在多项前沿基准测试中表现卓越，例如在 GPQA Diamond（90.4%）和 Humanity’s Last Exam（无工具情况下 33.7%）等博士级推理任务中达到领先水平，甚至超越了此前的 Gemini 2.5 Pro 模型。在 MMMU Pro 多模态知识测试中取得 81.2% 的高分，与 Gemini 3 Pro 相当。

该模型具备智能思考调节能力，可根据任务复杂度动态调整推理深度，在典型使用场景下平均减少 30% 的 token 消耗，同时提升任务完成质量。在高思考层级任务中，其处理速度比 Gemini 2.5 Pro 快 3 倍，真正实现了性能、速度与成本之间的最优平衡。

Gemini 3 Flash 的推出标志着 Google 在“高效智能”道路上迈出关键一步，让前沿 AI 技术更广泛、更经济地服务于全球用户与开发者。

HN 热度 687 points | 评论 328 comments | 作者：meetpateltech | 7 hours ago #

https://news.ycombinator.com/item?id=46301851

Gemini 3 Flash 虽名为“闪速”，但性能远超预期，响应速度极快，知识广博，相比 Claude Opus 4.5 和 GPT 5.2 高性能版本在推理时间和成本上具有数量级优势。
用户通过内部基准测试发现，Gemini 3 Flash 在响应速度不变的情况下，性能显著优于 Gemini 2.5 Flash 和 2.5 Pro，性价比极高，令人惊叹。
有用户对生成式 AI 保持怀疑态度，但在一个高度专业且冷门的测试问题上，Gemini 3 Flash 是首个给出合理答案的模型，表明其在特定领域已取得实质性进步。
该用户强调，这类冷门难题并非生成式 AI 的核心优势，真正价值在于处理非结构化数据、自动化重复任务，如转录、OCR、生成模板代码等。
生成式 AI 在处理复杂、微妙或冷门知识时仍存在局限，但其在实用场景中的表现正在持续改善。
有开发者批评 OpenAI 忽视快速推理模型的发展，其策略过度依赖 GPT-5 系列，导致开发者在低延迟场景下缺乏合适选择，而 Gemini 3 Flash 在实际应用中表现优于 GPT-5 的低思考模式。
硬件架构差异影响推理延迟，TPU 相比 GPU 在低延迟方面具有天然优势，而 Cerebras 和 Grok 的超快模式则依赖特殊优化或规避安全机制。
有观点指出，模型训练数据可能包含用户提交的问题，因此公开测试题存在被模型“学习”从而失效的风险，因此不宜公开具体测试问题。
生成式 AI 本质上是“万能锤”，虽不能完美替代所有工具，但在特定场景下仍能发挥巨大价值，关键在于合理定位其使用边界。

无 AI 之处——对 Mozilla 新篇章的回应 (No AI* Here – A Response to Mozilla’s Next Chapter) #

https://www.waterfox.com/blog/no-ai-here-response-to-mozilla/

Mozilla 新任 CEO 宣布将 AI 置于公司未来的核心位置，试图打造“全球最值得信赖的软件公司”。作者对此表示理解，但认为这一战略存在根本性错误。

作者指出，“AI”一词如今被滥用，掩盖了技术本质的差异。像 Bergamot 这类有限用途、可审计的机器学习模型具有实际价值，而大型语言模型（LLM）则是不可见的“黑箱”，无法验证其行为，也无法确保用户数据安全。

在浏览器这一场景下，作者强调浏览器应是用户的“代理”，代表用户与网络交互。若引入 LLM 作为中介，就变成了“用户代理的代理”，AI 将自行决定内容呈现、标签页管理、浏览历史修改等，用户却无法理解或审查其逻辑，违背了透明与控制原则。

尽管 Mozilla 声称 AI 功能可关闭，但作者质疑：如何监控一个你无法理解的系统？即便能关闭，持续追踪其潜在影响也带来巨大认知负担。

作者认为，Mozilla 的困境在于，为应对市场压力，正试图吸引普通用户，却可能失去其技术社区根基。而 Waterfox 的定位恰恰相反：专注于成为一款纯粹、高效、可控的浏览器，不引入当前形式的 LLM。

Waterfox 明确承诺：不会集成 LLM，至少在可预见的未来不会。其核心价值在于性能、标准兼容性和用户自主权。

此外，作者指出，许多 Firefox 分支项目缺乏正式治理结构、隐私政策或法律实体，导致责任缺失。而 Waterfox 拥有法律实体和正式政策，这使其获得第三方信任，甚至接入 Widevine 等受保护流媒体服务，证明了治理机制的实际价值。

最后，作者承认 AI 可能不可阻挡，但强调网络的去中心化本质仍值得守护。真正的浏览器不应成为 AI 的附庸，而应始终以用户为中心。

HN 热度 519 points | 评论 291 comments | 作者：MrAlex94 | 1 day ago #

https://news.ycombinator.com/item?id=46295268

大型语言模型被视为黑箱，难以审计、理解其数据处理方式，也无法验证其行为，这与神经机器翻译的可理解性形成对比，但两者在架构上具有相似性。
神经机器翻译虽也存在不可完全验证的行为，但因其有明确的替代方案且副作用有限，因此被接受；而将大模型应用于广泛场景则显得不必要且风险更高。
机器翻译领域早期的规则系统虽可完全理解，但自 2008 年后统计模型在准确性和上下文处理上远超规则系统，推动了技术转向。
尽管规则系统仍具研究价值，但统计和神经网络方法因持续进步和更大投入，已成为主流，体现了“苦涩的教训”——数据驱动方法最终胜出。
未来可能的最优解是结合规则逻辑与大模型能力的混合系统，以兼顾可解释性与性能。
对于模型内部机制，即便大模型由明确指令构成，其输出仍难以预测，这与复杂规则系统存在类似不确定性，因此“可理解性”并非绝对。
规则系统虽由人编写且作者理解其逻辑，但面对语言的复杂性和歧义性，仍难以覆盖所有情况，如“time flies like an arrow”这类句子存在多重合理解释。
即使能生成所有可能的语法解析，也难以高效筛选出语义合理的解释，尤其在嵌套结构中，计算复杂度呈指数增长。

GPT Image 1.5 (GPT Image 1.5) #

https://openai.com/index/new-chatgpt-images-is-here/

OpenAI 今日发布了全新版本的 ChatGPT Images 功能，基于其最新旗舰图像生成模型，显著提升图像生成与编辑能力。新模型支持更精准的图像编辑，能够忠实执行用户指令，仅修改指定内容，同时保留光照、构图和人物外观等关键细节，适用于照片修复、服装试穿、风格转换等场景。

新功能支持多种创意变换，如将现实照片转化为电影海报、时尚广告或插画风格，且能自动适配时代背景与艺术风格。模型在指令遵循方面表现更佳，可准确生成复杂布局，如 6x6 网格内容，确保元素位置与描述一致。

在文本渲染方面，新模型支持更密集、更小字号的文字，能精准还原 Markdown 格式内容，如报纸文章、代码片段和数据图表，保持原始排版与信息完整性。

该功能已全面上线 ChatGPT，面向所有用户开放。API 版本命名为 GPT Image 1.5，支持开发者集成。新图像创作空间也已推出，用户可通过预设风格快速激发灵感，实现从零开始的创意探索。目前，企业与商业用户版本将稍后开放。

HN 热度 507 points | 评论 245 comments | 作者：charlierguo | 1 day ago #

https://news.ycombinator.com/item?id=46291941

OpenAI 的 gpt-image-1.5 在图像编辑任务中表现显著优于前代模型，尤其在局部修改和保持整体风格一致性方面进步明显，且在“移除棕色糖果”任务中展现出更符合物理逻辑的推理能力。
有评论指出，某些模型虽未完全移除指定对象，但通过改变颜色或重新排列来“通过”测试，这种做法可能不符合真实语义，应提高测试标准以要求真正意义上的“移除”。
当前基准测试存在模型发布后被新模型针对性优化的问题，导致测试结果可能失真，建议定期更新测试集以保持挑战性。
为防止模型通过“训练数据作弊”，可引入如 Anubis 等反爬机制，同时通过动态生成新测试用例来提升测试的不可预测性。
建议采用程序化生成 3D 场景（如 Blender 预可视化）作为新测试框架，通过自动构建复杂场景并要求模型进行风格迁移或角色替换，实现更真实、可复用的评估体系。
尽管模型优化基准测试是合理行为，但若通过动态加载特定 LoRA 等手段针对性应对测试，属于“作弊”行为，会严重削弱基准测试的价值。
训练模型以通过特定测试可能难以实现，因为这类测试涉及复杂物理逻辑和语义理解，难以通过简单数据注入解决。

即将推出：更简单的定价与更优的 GitHub Actions 体验 (Coming soon: Simpler pricing and a better experience for GitHub Actions) #

https://github.blog/changelog/2025-12-16-coming-soon-simpler-pricing-and-a-better-experience-for-github-actions/

GitHub 宣布推迟原定于 2026 年 3 月 1 日实施的自托管 GitHub Actions 运行器收费政策，以有更多时间听取开发者、客户和合作伙伴的反馈，并重新评估该策略。公司表示，虽然运行 Actions 控制平面存在实际成本，且正加大对自托管运行器在复杂企业场景下可扩展性的投入，但此次定价调整未能充分纳入用户意见，因此决定暂缓执行。

与此同时，GitHub 仍将在 2026 年 1 月 1 日如期下调 GitHub 托管运行器价格，降幅最高达 39%，具体价格根据机器类型而定，免费使用配额保持不变。

自托管运行器在公共仓库中的使用将继续免费。对于 GitHub Enterprise Server 用户，该政策调整不会产生影响，其自托管运行器的使用仍无需付费。

GitHub 强调，将加大对自托管体验的投资，未来 12 个月内将扩展支持更多平台（包括 Windows）、引入新的自动扩展机制，并提升整体稳定性与灵活性。

针对用户关心的问题，官方说明：收费并非针对用户自有的硬件，而是为了更公平地分摊平台基础设施与服务维护成本，同时支持持续创新。绝大多数用户（96%）的账单不会发生变化，其中 85% 的受影响用户将实际支出减少，仅 15% 的用户面临小幅上涨，中位数增加约 13 美元。

对于个人开发者，仅 0.09% 使用私有仓库的免费或 Pro 用户可能面临账单上涨，中位数增加不足 2 美元/月，且该影响发生在已用完免费配额之后。另有 2.8% 的用户将受益于成本下降。

GitHub 提供了新的定价计算器和 Python 脚本，帮助用户基于历史使用数据估算未来成本，并建议查看详细使用报告以辅助评估。此外，也提供了从自托管运行器迁移到 GitHub 托管运行器的指南。

公司已开启公开讨论，欢迎用户直接反馈，以共同塑造 GitHub Actions 的未来发展方向。

HN 热度 453 points | 评论 2 comments | 作者：nklow | 1 day ago #

https://news.ycombinator.com/item?id=46291414

GitHub Actions 即将推出更简单的定价方案，预计将改善用户体验。
评论指出该更新与之前在 HN 上讨论的类似话题相关，建议查看原帖以获取更多信息。

Coursera 与 Udemy 宣布达成最终合并协议 (Coursera to combine with Udemy) #

https://investor.coursera.com/news/news-details/2025/Coursera-to-Combine-with-Udemy-to-Empower-the-Global-Workforce-with-Skills-for-the-AI-Era/default.aspx

Coursera 与 Udemy 宣布达成最终合并协议，将以全股票交易方式合并，创建一个面向全球劳动力的领先技术平台，助力应对人工智能时代下的技能转型需求。

此次合并基于 2025 年 12 月 16 日的收盘价，合并后公司的预估股权价值约为 25 亿美元。Udemy 股东将获得 0.8 股 Coursera 普通股，较过去 30 个交易日平均股价溢价 26%。合并后，Coursera 现有股东将持有新公司约 59% 的股份，Udemy 股东将持有约 41% 的股份。

合并后的公司将整合 Coursera 的大学与行业品牌资源，以及 Udemy 动态的 AI 驱动技能发展市场，打造更全面、个性化、可扩展的学习生态系统。平台将强化 AI 原生创新，提升技能发现、学习与认证的全流程效率，加速产品迭代与全球市场拓展。

财务方面，预计合并后公司年收入将超过 15 亿美元，24 个月内可实现约 1.15 亿美元的年度运营成本协同效应。合并后公司将执行大规模股票回购计划，进一步增强股东回报。

新公司将继续以 Coursera 为品牌名称，股票代码为 COUR，在纽约证券交易所上市，总部设在加利福尼亚州山景城。Coursera 的公共利益公司（PBC）身份保持不变。

Greg Hart 将继续担任合并后公司的首席执行官，Andrew Ng 将继续担任董事会主席。董事会共 9 名成员，其中 6 名来自 Coursera，3 名来自 Udemy。

该交易已获双方董事会一致批准，预计于 2026 年下半年完成，需获得监管批准及股东投票通过。主要股东如 Insight Venture Partners 和 New Enterprise Associates 已签署支持协议。

HN 热度 384 points | 评论 214 comments | 作者：throwaway019254 | 11 hours ago #

https://news.ycombinator.com/item?id=46301346

Udemy 平台的课程排名和推广机制可能不完全自动化，存在对特定讲师的偏袒，导致优质课程因未被推荐而销量骤降。
现代社会普遍轻视较旧的知识，即使内容依然有效，也容易被忽视，反映出对“新”事物的盲目追求。
技术行业的快速迭代使得人们更倾向于寻找最新信息，但部分基础技术知识如 Linux、网络、CPU 原理等仍具有长期价值。
一些核心系统知识（如文件系统、I/O 机制）在当前开发者中已逐渐被遗忘，导致解决问题时缺乏根本性理解。
项目若长时间无更新，会被认为已“死亡”，即使其代码仍完全可用，这反映了对“活跃度”的过度依赖。
通过定期重置在线身份（如创建新账号）可能有助于绕过平台算法对旧内容的压制，但受税务信息等实名限制，可行性较低。
依赖 AI 生成内容或工具建议，而缺乏对系统底层原理的理解，导致开发者难以真正解决问题。
一些看似“过时”的知识（如 RAID、readahead、write-back 等）在实际系统调优中仍至关重要，但当前开发者普遍不了解。

Hacker News 精彩评论及翻译 #

Tell HN: HN was down #

https://news.ycombinator.com/item?id=46303196

Yes, sorry! We’re investigating, but my current theory is we got overloaded because I relaxed some of our anti-crawler protections a few days ago.

(The reason I did that is that the anti-crawler protections also unfortunately hit some legit users, and we don’t want to block legit users. However, it seems that I turned the knobs down too far.)

In this case, though, we had a secondary failure: PagerDuty woke me up at 5:24am, I checked HN and it seemed fine, so I told PagerDuty the problem was resolved. But the problem wasn’t resolved - at that point I was just sleeping through it.

I’ll add more as we find out more, but it probably won’t be till later this afternoon PST.

dang

是的，抱歉！我们正在调查，但我目前的推测是，几天前我们放宽了一些反爬虫保护措施，导致系统过载。

（我那么做的原因是，反爬虫保护措施不幸也影响了一些真实用户，而我们不想阻挡真实用户。不过，看来我把限制调得太低了。）

不过，这次我们遇到了另一个故障：PagerDuty 在凌晨 5:24 唤醒了我，我检查了 Hacker News (HN)，看起来一切正常，所以就告知 PagerDuty 问题已解决。但实际上问题并没有解决——那时我只是睡过去了。

随着我们了解更多情况，我会继续更新，但可能要等到太平洋标准时间今天下午晚些时候了。

Pricing Changes for GitHub Actions #

https://news.ycombinator.com/item?id=46295141

It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn’t pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior but were community-developed, community-maintained and libre.

The writing is in the wall. First it was UX annoyances. Then it was GitHub Actions woes. Now it is paying money for running their software on your own hardware. It’s only going to go downhill. Is it a good time now to learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives? They may be inferior. They may lack features. But they’re not going to pull user hostile tricks like this on you and me. And hey, if they are lacking features, maybe we should convince our management to let us contribute time to the community to add those features? It’s a much better investment than sinking money into a software that will only grow more and more user hostile, isn’t it?

throwaway150

正是我们这些开发者，说服管理层购买了GitHub Enterprise作为我们的代码托管平台。我们没有顾及软件自由的价值。一款闭源、专有的软件拥有良好的功能，我们看到了这一点，并说服管理层购买了它。从未想过，当这项优秀的软件落入不良所有者之手时，未来会带来什么代价。我们也忽略了那些虽然功能较差，但由社区开发和维护且是自由软件的替代方案。

不祥之兆已经显现。起初是用户体验上的烦心事，然后是GitHub Actions带来的种种困扰，现在竟然要我们为在自己的硬件上运行他们的软件而付费。情况只会每况愈下。现在是不是到了我们从错误中吸取教训，并说服我们的团队和管理层采用由社区维护的自由软件替代方案的时候了？它们可能功能较差，可能缺乏一些特性。但它们不会像现在这样，对用户玩这种敌对把戏。再说了，如果它们真的缺乏某些功能，也许我们应该说服管理层，允许我们投入时间来为社区贡献，以增加这些功能呢？这比把钱投入到一个只会变得越来越对用户不友好的软件中，要好得多，不是吗？

Is Mozilla trying hard to kill itself? #

https://news.ycombinator.com/item?id=46300288

He says he could begin to block ad blockers in Firefox and estimates that’d bring in another $150 million, but he doesn’t want to do that. It feels off-mission.

It may be just me, but I read this as “I don’t want to but I’ll kill AdBlockers in Firefox for buckerinos ”.

Yes, that does seem like a pretty uncharitable interpretation of that quote. I read it as “we won’t do it, even though it would bring in $150M USD”.

lxgr

他说他可以在Firefox浏览器上开始屏蔽广告拦截器，并估计这能带来另外1.5亿美元的收入，但他不想这么做。这感觉有点偏离公司的核心使命。

可能这只是我个人的看法，但我解读为：“我并不想这么做，但为了钱，我照样会在Firefox上干掉广告拦截器。”

是的，这确实是对那番话相当不友善的解读。我的解读是：“我们不会这么做，即便这能带来1.5亿美元的收入。”

Is Mozilla trying hard to kill itself? #

https://news.ycombinator.com/item?id=46300189

It’s kinda frustrating that Mozilla’s CEO thinks that axing ad-blockers would be financially beneficial for them. Quite the opposite is true (I believe) since a ton of users would leave Firefox for alternatives.

herobird

有点让人沮丧的是，Mozilla的CEO认为移除广告拦截器会对他们有财务上的好处。但我认为事实恰恰相反，因为大量的用户会因此离开Firefox，转而使用其他浏览器。

AWS CEO says replacing junior devs with AI is ‘one… #

https://news.ycombinator.com/item?id=46304549

“without losing face”? What culture are you referring to? The Western companies I have worked at do not discourage such questions – in fact, it’s often the sign of someone very senior when they ask a seemingly ‘dumb’ question that others have taken for granted.

rsanek

“不失面子”？你指的是什么文化？我工作过的西方公司并不会阻止这类提问——事实上，当有人提出其他人想当然的、看似“愚蠢”的问题时，这往往表明他们非常资深。

Pricing Changes for GitHub Actions #

https://news.ycombinator.com/item?id=46292376

I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn’t even explain the reasoning well. It basically summed up to “because we can” and “where are you going to go?”. He was shocked to find out that I didn’t like it.

We currently self-host on kubernets/aws. The thing that really got to me isn’t the new charge per se. It’s the fact that GHA has a ton of problems. I can hold my nose and deal with them when it’s free. But now that you’re squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don’t even include things that I care about. Specifically:

Jenkins had better kubernetes integration years ago. It’s crazy that GHA can’t beat that.
“Reintroducing multi-label functionality” - yeah, so they first broke it. They did supply “reasons”, which looked like they never talked to a customer. [1]
Still no SDK of any kind.
“Actions Data Stream” - or you can just fix your logging.

There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don’t use GHA again. Even if I end up paying another vendor, at least I’ll be treated as a customer.

[1] - https://github.com/orgs/community/discussions/160682#discussioncomment-8063837

golovast

几周前，我们的客户代表联系了我，告知我这一消息。我认为这简直是一场灾难，真的让我非常生气。这位代表甚至无法很好地解释原因，他的说辞基本上就是“因为我们可以这么做”以及“你还能去哪里呢？”。他对于我不喜欢这个决定感到很震惊。

我们目前在 Kubernetes/AWS 上进行自托管。真正让我恼火的不是新收费政策本身，而是 GHA 存在的大量问题。当它免费时，我可以捏着鼻子忍受这些缺陷。但现在你们要来压榨我了，你们至少也应该先打造一个类似 GHA 2.0 的产品，然后对它收费。取而代之的，只有一些模糊不清的路线图承诺，其中甚至没有包含我关心的问题。具体来说：

Jenkins 在几年前就有了更好的 Kubernetes 集成。GHA 居然做不到，真是疯了。
“重新引入多标签功能”——是啊，因为他们先把功能给弄没了。他们确实提供了一些“理由”，但看起来他们从未与客户沟通过。
至今仍然没有任何类型的 SDK。
“Actions 数据流”——或者说，你们干脆把你们的日志系统修好就行了。

还有几十条其他的抱怨，很容易就能找到。这种做法只会让我下定决心再也不使用 GHA。即使最终我不得不向另一个供应商付费，至少我还能被当作客户来对待。

Gemini 3 Flash: Frontier intelligence built for sp… #

https://news.ycombinator.com/item?id=46301897

Don’t let the “flash” name fool you, this is an amazing model.

I have been playing with it for the past few weeks, it’s genuinely my new favorite; it’s so fast and it has such a vast world knowledge that it’s more performant than Claude Opus 4.5 or GPT 5.2 extra high, for a fraction (basically order of magnitude less!!) of the inference time and price

samyok

别被“flash”这个名字给骗了，这真是一个绝妙的模型。

在过去的几周里我一直在玩它，它真的成了我的新宠；它速度飞快，又拥有海量的世界知识，性能甚至比 Claude Opus 4.5 或 GPT 5.2 extra high 更强，而其推理时间和价格却只有后者的零头（基本上少了一个数量级！！）。

GPT Image 1.5 #

https://news.ycombinator.com/item?id=46294934

Okay results are in for GenAI Showdown with the new gpt-image 1.5 model for the editing portions of the site!

https://genai-showdown.specr.net/image-editing

Conclusions

OpenAI has always had some of the strongest prompt understanding alongside the weakest image fidelity. This update goes some way towards addressing this weakness.
It’s leagues better at making localized edits without altering the entire image’s aesthetic than gpt-image-1, doubling the previous score from 4/12 to 8/12 and the only model that legitimately passed the Giraffe prompt.
It’s one of the most steerable models with a 90% compliance rate

Updates to GenAI Showdown

Added outtakes sections to each model’s detailed report in the Text-to-Image category, showcasing notable failures and unexpected behaviors.
New models have been added including REVE and Flux.2 Dev (a new locally hostable model).
Finally got around to implementing a weighted scoring mechanism which considers pass/fail, quality, and compliance for a more holistic model evaluation (click pass/fail icon to toggle between scoring methods).

If you just want to compare gpt-image-1, gpt-image-1.5, and NB Pro at the same time:

https://genai-showdown.specr.net/image-editing?models=o4,nbp,g15

vunderba

GenAI Showdown 网站编辑测试部分的结果已经出炉，这次测试了新的 gpt-image 1.5 模型！

https://genai-showdown.specr.net/image-editing

结论

OpenAI 一直拥有最强的指令理解能力，但其图像保真度却是最弱的。这次的更新在一定程度上弥补了这一弱点。
与 gpt-image-1 相比，它在进行局部编辑而不改变整个图像美学风格方面要好得多，评分从之前的 4/12 翻倍至 8/12，并且是唯一一个真正通过了“长颈鹿”提示的模型。
它是最具可操控性的模型之一，合规率达到 90%。

GenAI Showdown 更新

在“文本生成图像”类别中，为每个模型的详细报告增加了“花絮”板块，展示其显著的失败案例和意想不到的行为。
新增了包括 REVE 和 Flux.2 Dev（一个新推出的可本地化部署模型）在内的模型。
终于实现了一个加权评分机制，该机制综合考虑了通过/失败、质量和合规性，以进行更全面的模型评估（点击通过/失败图标可以在不同评分方法之间切换）。

如果您想同时比较 gpt-image-1、gpt-image-1.5 和 NB Pro：

https://genai-showdown.specr.net/image-editing?models=o4,nbp,g15

Tell HN: HN was down #

https://news.ycombinator.com/item?id=46302283

I got stuck in an infinite loop.

Try opening HN -> it’s down, better check HN to see everyone talking about a major website being down -> Try opening HN -> loop

Elfener

我陷入了死循环。试着打开HN -> 网站挂了，那就去HN上看看大家是不是在讨论某个大网站也挂了 -> 试着打开HN -> 循环。

Is Mozilla trying hard to kill itself? #

https://news.ycombinator.com/item?id=46300847

Like many others, the ability to run uBO is the main reason I use Firefox. Otherwise I’d use Chrome or Safari.

JoeJonathan

和大多数人一样，我使用Firefox的主要原因是它能运行uBO，否则我就会用Chrome或Safari了。

Announcing the Beta release of ty #

https://news.ycombinator.com/item?id=46295665

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

klysm

我真的希望Astral能够盈利，不至于进行极具破坏性的rugpull，因为他们正在构建出色的工具并解决实际问题。

Pricing Changes for GitHub Actions #

https://news.ycombinator.com/item?id=46291358

We are introducing a $0.002 per-minute Actions cloud platform charge for all Actions workflows across GitHub-hosted and self-hosted runners.

Charging for self-hosted runners is an interesting choice. That’s the same cost as their smallest hosted runners [1]

[1] - https://docs.github.com/en/billing/reference/actions-runner-pricing#standard-github-hosted-runners

Arcuru

我们将对所有Actions工作流程（涵盖GitHub托管和自托管的运行器）推出每分钟0.002美元的Actions云平台费用。对自托管运行器收费是一个有趣的选择。这和他们最小的托管运行器成本相同[1] https://docs.github.com/en/billing/reference/actions-runner-pricing#standard-github-hosted-runners

AWS CEO says replacing junior devs with AI is ‘one… #

https://news.ycombinator.com/item?id=46304163

The thing people miss in these “replace juniors with AI” takes is that juniors were never mainly about cheap hands on keyboards. They’re the only people in the org who are still allowed to ask “dumb” questions without losing face, and those questions are often the only signal you get that your abstractions are nonsense.

What AI does is remove a bunch of the humiliating, boring parts of being junior: hunting for the right API by cargo-culting Stack Overflow, grinding through boilerplate, getting stuck for hours on a missing import. If a half-decent model can collapse that search space for them, you get to spend more of their ramp time on “here’s how our system actually fits together” instead of “here’s how for-loops work in our house style”.

If you take that setup and then decide “cool, now we don’t need juniors at all”, you’re basically saying you want a company with no memory and no farm system – just an ever-shrinking ring of seniors arguing about strategy while no one actually grows into them.

Always love to include a good AI x work thread in my https://hackernewsai.com/ newsletter.

alexgotoi

在那些“用AI取代初级员工”的论调中，人们往往忽略了一点：初级员工的价值，从来就不在于他们是廉价的“键盘劳动力”。他们是组织里唯一还能在不丢面子的情况下提出“傻”问题的人，而这些“傻”问题往往是让你意识到那些抽象概念有多么荒谬的唯一信号。

AI的作用恰恰是消除了初级员工工作中那些令人尴尬又无聊的部分：比如盲目照搬Stack Overflow上的代码来寻找合适的API，埋头处理枯燥的样板代码，或者因为漏掉一个import语句而被困住好几个小时。如果一个还不错的AI模型能帮他们缩小搜索范围，你就可以把他们更多的时间花在“我们这个系统是如何协同工作的”上，而不是“在我们的代码风格里for循环该怎么写”这种事上。

如果基于这个前提，你却决定“太棒了，我们现在完全不需要初级员工了”，那你基本上就是说，你想要一个既没有传承、也没有人才梯队的企业——只剩下一群资深的员工，他们的圈子越来越小，为战略问题争吵不休，同时也没有人能成长起来接替他们。

我总喜欢在 https://hackernewsai.com/ 的简讯中收录一些关于“AI与工作”的优秀讨论帖。

No Graphics API #

https://news.ycombinator.com/item?id=46293716

The article is missing this motivation paragraph, taken from the blog index:

Graphics APIs and shader languages have significantly increased in complexity over the past decade. It’s time to start discussing how to strip down the abstractions to simplify development, improve performance, and prepare for future GPU workloads.

opminion

过去十年中，图形API和着色器语言的复杂度显著增加。是时候开始讨论如何剥离这些抽象层，以简化开发、提升性能，并为未来的GPU工作负载做准备。

Pricing Changes for GitHub Actions #

https://news.ycombinator.com/item?id=46291992

That’s not a move of a company that thinks it can still grow. That’s a Netflix “we have 90% of the market, let’s squeeze them” move. This is the beginning. We have all seen this pattern over the last 5+ years. You know their next few moves.

andsens

这不是一个认为自己还能继续增长的公司的举动。这完全是奈飞（Netflix）那种“我们占据了90%的市场，就让我们去压榨他们”的做法。这只是个开始。在过去五年多来，我们都见识过这种模式。你知道他们接下来的几步棋。

No AI* Here – A Response to Mozilla’s Next Chapter #

https://news.ycombinator.com/item?id=46296574

Large language models are something else entirely*. They are black boxes. You cannot audit them. You cannot truly understand what they do with your data. You cannot verify their behaviour. And Mozilla wants to put them at the heart of the browser and that doesn’t sit well.

Am I being overly critical here or is this kind of a silly position to have right after talking about how neural machine translation is okay? Many of Firefox’s LLM features like summarization afaik are powered by local models (hell even Chrome has local model options). It’s weird to say neural translation is not a black box but LLMs are somehow black boxes that we cannot hope to understand what they do with the data, especially when viewed a bit fuzzily LLMs are scaled up versions of an architecture that was originally used for neural translation. Neural translation also has unverifiable behavior in the same sense.

I could interpret some of the data talk as talking about non local models but this very much seems like a more general criticism of LLMs as a whole when talking about Firefox features. Moreover, some of the critiques like verifiability of outputs and unlimited scope still don’t make sense in this context. Browser LLM features except for explicitly AI browsers like Comet have so far had some scoping to their behavior, either in very narrow scopes like translation or summarization. The broadest scope I can think of is the side panels that show up which allow you to ask about a web page with context. Even then, I do not see what is inherently problematic about such scoping since the output behavior is confined to the side panel.

inkysigma

大型语言模型完全是另一回事*. 它们是黑箱。你无法对它们进行审计，无法真正理解它们如何处理你的数据，也无法验证它们的行为。而Mozilla想把它们置于浏览器的核心，这一点让人很不舒服。

是我过于吹毛求疵了，还是说在刚刚讨论过神经机器翻译没问题之后，这种立场本身就有点可笑？据我所知，Firefox的许多LLM功能，比如摘要功能，都是由本地模型驱动的（说真的，就连Chrome也有本地模型的选项）。说神经机器翻译不是黑箱，但LLM却成了我们无法理解其数据处理的黑箱，这很奇怪，特别是如果稍微模糊一点看，LLM不过是用于神经机器翻译的架构的放大版本。从这个意义上说，神经机器翻译同样具有不可验证的行为。

我或许可以把一些关于数据的讨论理解为在谈论非本地模型，但当讨论Firefox功能时，这看起来更像是对LLM整体的一种更广泛的批评。此外，像输出可验证性和无限范围这类批评，在这个语境下仍然讲不通。除了像Comet这样的明确以AI为核心的浏览器之外，浏览器的LLM功能迄今为止都对其行为有所限制，要么是像翻译或摘要这样非常狭窄的范围。我能想到的最广泛的范围，是那些弹出的侧边栏，它们允许你结合网页内容提出问题。即使如此，我也看不出这种范围限制有什么内在问题，因为其输出行为仅限于侧边栏内。

AI will make formal verification go mainstream #

https://news.ycombinator.com/item?id=46298001

I don’t think formal verification really addresses most day-to-day programming problems:

A user interface is confusing, or the English around it is unclear
An API you rely on changes, is deprecated, etc.
Users use something in unexpected ways
Updates forced by vendors or open source projects cause things to break
The customer isn’t clear what they want
Complex behavior between interconnected systems, out of the purview of the formal language (OS + database + network + developer + VM + browser + user + web server) For some mathematically pure task, sure, it’s great. Or a low-level library like a regular expression parser or a compression codec. But I don’t think that represents a lot of what most of us are tasked with, and those low-level “mathematically pure” libraries are generally pretty well handled by now.

QuadrupleA

我不认为形式验证能真正解决大多数日常编程问题：

用户界面令人困惑，或者其上的英文表述不清晰
你所依赖的 API 发生变化、被弃用等
用户以意想不到的方式使用产品
由供应商或开源项目强制推送的更新导致系统崩溃
客户不清楚自己想要什么
互连系统间的复杂行为，超出了形式语言的范畴（操作系统 + 数据库 + 网络 + 开发者 + 虚拟机 + 浏览器 + 用户 + Web 服务器）

对于某些数学上纯粹的任务，当然，它非常棒。或者像正则表达式解析器或压缩编解码器这样的底层库。但我不认为这代表了大多数我们所负责的任务，而那些底层的“数学上纯粹”的库，现在通常也已经得到了很好的处理。

Thin desires are eating life #

https://news.ycombinator.com/item?id=46294586

I can’t help but feel that this article was written in a format that is the textual equivalent of thin desires…

Every sentence is separated into its own paragraph, like each one is supposed to be revelatory (or maybe tweet-worthy). It’s pretty common design knowledge that if you try to emphasize everything, you end up emphasizing nothing. The result is that reading the article feels choppy, and weirdly unsatisfying, since the larger arc of each point is constantly being interrupted.

Why choose such an antithetical form, to what is otherwise an important and deep message?

The only answer that comes to mind is that the author’s livelihood, or at least their internal gauge of success, is tied to manipulating readers’ thin desires.

ianstormtaylor

我总觉得，这篇文章的写作格式简直就是“肤浅欲望”的文字体现。每一句话都自成一段，仿佛每一句都石破天惊（或者说，特别适合发推特）。这是很常见的设计常识：如果你试图强调所有东西，结果就是什么都没强调出来。结果是，读这篇文章感觉很跳跃，而且有种奇特的、不满足感，因为每个观点的整体脉络总是在被打断。对于一个本应重要而深刻的信息，为什么作者要选择与之背道而驰的格式呢？我唯一能想到的答案是，作者的生计，至少是他们内心成功的标尺，都取决于对读者肤浅欲望的操纵。

Tell HN: HN was down #

https://news.ycombinator.com/item?id=46301962

TIL I have a “open Hacker News” hand reflex

manbitesdog

今天才知道我有个“打开 Hacker News”的手反射。