关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 工作原理 测试新功能 © 2026 Google LLC
每日HackerNews RSS
最近在 Hacker News 上的一场讨论凸显了人们对 LG 智能电视做法的日益不满，特别是该公司利用自动内容识别（ACR）技术来跟踪用户活动并投放广告。
用户们越来越感到沮丧：他们支付了高昂的价格购买硬件，却被厂商收集数据并将其变现。批评者认为，“智能”功能已沦为侵入式监控的工具，这些功能往往在固件更新后被重新启用，或隐藏在具有误导性的“选择加入”流程之后。
讨论贴涉及了几个核心议题：
* **硬件的“平庸化”（Enshittification）：** 参与者感叹所有权的丧失，指出现在的设备通过严格的最终用户许可协议（EULA）将厂商利益置于用户控制权之上。
* **缺乏替代方案：** 许多用户难以买到“非智能”电视，因为厂商为了获取数据极力推行联网功能。一些人建议购买商用显示器，但即便如此，购买渠道也越来越少。
* **隐私保护措施：** 夺回控制权的建议多种多样，从物理拆除 Wi-Fi 网卡到在路由器层面屏蔽跟踪域名，尽管许多用户认为对于一款已经付费的产品来说，这些措施本不该是必要的。
归根结底，这一共识反映了人们对那种将数据提取置于用户体验之上的“智能”技术的普遍厌倦。
Real-SWE 是一项旨在评估前沿 AI 模型的新基准，它使用私有的真实企业代码库，而非合成或公开数据集。通过利用来自金融科技和 AI 销售平台等具有高风险生产环境公司的授权代码，Real-SWE 挑战模型处理专有系统、复杂业务逻辑以及特定组织编码规范的能力。 与传统基准不同，Real-SWE 测试的是智能体作为专业软件工程师的工作能力。任务被刻意设定得不够详尽，要求智能体自行发现实现细节、维护现有系统的完整性，并处理影响实际业务运营（如计费或税务计算）的跨职能约束。通过采用原生工具在现场评估模型与工具的组合，该基准能够准确衡量 AI 是否能成功应对生产级软件开发的细微差别，而在这些领域，代码质量和运行可靠性至关重要。
“Real-SWE”基准测试（realswe.withspecific.com）因其尝试使用私有的真实企业代码库而非标准的公开基准来评估 AI 编程模型，在 Hacker News 上引发了激烈讨论。
**讨论要点：**
* **方法论：** 创建者在长周期、“2023 年前”的企业任务上对模型进行了测试，认为公开基准已陷入“刷分”困境且趋于饱和。他们计划开源任务轨迹以提高透明度。
* **“魔法师与魔杖”之争：** 用户强调，性能在很大程度上取决于所使用的“工具链”（如 agy、oh-my-pi）以及用户担任项目经理的能力，即能否提供明确的范围、约束和阶段性审查。
* **模型表现：** 体验差异巨大。虽然该基准测试将 Fable 5.1 和 GPT-6 Astra 排在首位，但评论者对这些模型的实用性存在争议。许多人发现 Gemini 3.8 Flash 在大规模任务中表现出人意料地有效，尽管其他用户称其“糟糕”，且容易出现过多且低效的工具调用。
* **质疑：** 批评者对“私有代码库”的说法表示怀疑，指出这可能存在数据污染，以及与 AI 提供商共享专有代码带来的伦理和安全隐患。许多人认为，个人用户体验仍然是唯一可靠的指标。
本报告总结了 **OpenSCAD** 与 **CadQuery** 的对照测试，旨在确定哪种工具更适合自主式人工智能 CAD 生成。六个智能体被要求设计三个可打印部件——支架、卡扣式外壳和螺旋螺纹，并由独立的网格解析器而非工具自带反馈来验证成功与否。
**主要发现：**
* **性能：** 两种工具均能产生高质量的可打印部件，迭代次数相同。
* **故障模式：** OpenSCAD 倾向于静默失败（产生外观正常但损坏的几何体），而 CadQuery 则会通过报错显性失败，这对无人值守的自动化任务更为安全。
* **验证：** 可视化预览在捕捉严重缺陷方面效果有限。成功与否依赖于数值断言（如体积、干涉、壁厚）。
* **可查询性：** CadQuery 的 B-rep 内核允许 AI 直接查询几何结构，而 OpenSCAD 的“三角网格”迫使智能体必须编写自定义代码才能测量其工作成果。
**结论：**
尽管 CadQuery 在验证方面更胜一筹，但 ModelRift 将保留 OpenSCAD，因其具备速度快、沙盒化及格式简单等优势。未来的开发重点将集中在实现数值验证和基于边缘的渲染，以弥补 OpenSCAD 缺乏原生几何查询功能的不足。
这篇 Hacker News 讨论评估了一篇对比 CadQuery 与 OpenSCAD 在 AI 驱动 CAD 生成方面差异的博文。社区共识对该文评价极低，认为其缺乏深度且忽视了基本的 CAD 原则，属于“AI 垃圾内容”。
**讨论要点：**
* **OpenSCAD 与 CadQuery：** 批评者认为将两者进行对比具有误导性。OpenSCAD 是一种基于 CSG 的声明式工具，易于嵌入，但缺乏可扩展性和真正的工程约束；CadQuery 使用 bRep 内核（NURBS），在功能性、专业级机械设计方面具有数学上的优势。
* **“AI-CAD”的问题：** 经验丰富的用户警告称，从文本生成 CAD 的模型往往会产生脆弱且“幻觉”严重的几何结构。他们指出，成功的 CAD 设计需要领域知识（如理解公差、拔模角度和参数化约束），而 AI 目前难以复刻这些能力。
* **实用性：** 虽然一些业余爱好者认为 AI 在简单的修补（如打印家用物品的替换零件）方面很有用，但工程师们强调，功能性零件需要 100% 的精确度，若没有人工监督和专业的约束化工作流程，通用型 AI 目前无法保证这一点。
参与者普遍认为该领域发展迅速，但提醒人们不要将 AI 视为学习基础工程原理的捷径。
为了避免在 iOS、Android 和 Web 上重复编写相同功能所带来的错误和维护开销，作者正将应用程序逻辑整合到一个共享的 **Rust 核心**中。
该策略不再将各个平台视为独立的实现，而是利用 Rust 处理“业务逻辑”（如账户状态、游戏引擎和网络协调），仅让原生外壳（Swift、Kotlin 和 JavaScript）处理 UI 渲染和操作系统集成等设备特有的事务。
**主要优势包括：**
* **一致性：** 逻辑（例如用户名验证、存档处理和会话管理）只需编写和测试一次，消除了各平台之间行为的差异。
* **解耦架构：** 通过使用序列化 JSON 和 ABI 绑定，Rust 运行时与宿主的 UI 框架保持解耦。
* **简化工具链：** 通过将资产验证、变形几何处理和多人游戏状态协调等复杂任务卸载到共享的 Crate 中，团队无需发布三个单独的平台版本即可更新游戏内容或规则。
最终目标是将原生代码减少到集成所需的最低限度，将多元化的客户端生态系统转化为围绕单一稳健基础构建的精简且可靠的外壳。
这篇 Hacker News 帖子讨论了 **Cubacadabra** 的技术实现，该项目使用了 Luau 语言。
讨论始于一位用户对该项目使用 `-- @import` 语法进行跨文件类型检查，而非使用标准 Luau `require()` 调用的质疑。项目创建者 Andrew 承认了这一批评，并坦言这种自定义语法是一个设计失误。因此，团队更新了工具链以支持标准的 `require("./file")` 导入，同时对 SDK 模块使用了别名（例如 `@cubacadabra/shared-state`）。
除了技术问题外，讨论还转向了其他方面的评价。用户抱怨其落地页缺乏清晰的项目描述，导致访客必须深入挖掘链接才能了解产品内容。另一些用户则嘲笑了其 UI 设计，特别是那个“抖动”的标题图片，部分用户将其归因于“氛围编程”（vibe coding）——这是一个贬义词，用来形容目前利用人工智能生成软件的趋势。批评者认为，这种方式往往导致软件体验糟糕、粗糙或不符合常规。
作者向 Anthropic 公司首席执行官达里奥·阿莫代（Dario Amodei）发起挑战，要求他超越近期提出的“嵌入式评估员”方案，转而倡导一项真正能减缓人工智能发展的政策：**强制要求所有公开发布的人工智能模型必须采用开放权重。**
作者认为，当前的监管提案（如算力阈值和行业协调）容易受到“监管俘获”的影响。这些规则通过制造小型竞争对手难以负担的复杂合规负担，有效地保护了成熟企业，最终不仅没能减缓发展，反而巩固了现有巨头的市场垄断地位。
相比之下，要求任何面向公众的模型必须以开放权重的形式发布，将从根本上改变该行业的经济模式。通过削弱这些模型的专有价值，可以减少驱动快速、失控训练运行的大规模资本投入。作者呼吁阿莫代秉持其一贯的原则与使命感，并指出作为一家公益公司，Anthropic 具有独特的地位来引领这一牺牲。通过呼吁开放权重，阿莫代可以证明其将安全置于利润之上的承诺，并迫使整个行业实现无法被操纵或规避的减速。
这篇 Hacker News 讨论聚焦于 Jacob Gold 的一封公开信，他认为减缓“前沿”人工智能发展的最有效方法是立法，强制要求任何向公众提供人工智能模型的公司公开模型权重。
**核心观点：**
* **提议：** Gold 建议通过强制公开权重，使人工智能模型的专有价值归零。这将削弱目前推动“算力密集型”人工智能竞赛的海量风险投资，从而在无需全球监管协调的情况下，有效地“放慢”进展。
* **批评：** 许多评论者认为该提议逻辑不通或十分“疯狂”。批评者认为，公司只会停止提供公共模型，转而将其转向私营企业或海外司法管辖区以规避强制令。另一些人则认为，公开权重实际上可能会加速非前沿实验室的发展，同时也有人担心发布强大模型的权重会带来巨大且不可逆转的安全风险。
* **动机：** 该辩论中很大一部分观点将当前的人工智能安全讨论视为一种旨在巩固现有巨头主导地位的“监管俘获”。怀疑论者认为，像 Anthropic 的 Dario Amodei 这样的首席执行官并非真正出于利他主义，而是将安全作为保护其市场地位的借口。
经过两年多的开发，Rust 贡献者“waffle”成功稳定了“never”类型（`!`）。该类型表示永远不会返回结果的计算，例如无限循环或会导致程序退出的函数。 此次稳定化带来了两大主要优势： 1. **效率：** 它允许编译器通过消除不可达的分支，来优化泛型代码（例如无失败转换）。 2. **类型推断：** 它通过为不返回的表达式提供统一类型，简化了语言本身，使其能够自动强制转换为任何其他类型。 这一过程涉及处理复杂的“never fallback”问题，需要对类型推断进行细微的向后不兼容更改。通过利用“crater”工具对整个 Rust 生态系统进行测试，维护者识别并解决了数千个 crate 中潜在的破坏性问题。尽管一些旧代码可能需要显式类型标注才能编译，但这一更改实现了该语言长期以来的目标。从 Rust 1.99 版本开始，`Infallible` 类型将成为 `!` 的别名，从而完成过渡，使语言的类型系统更加一致且高效。
这份 Hacker News 讨论探讨了 Rust “never 类型”（`!`）的稳定性，该类型用于表示永不返回的计算（例如死循环或 `panic!`）。
讨论的主要观点包括：
* **语义作用：** `!` 类型允许开发者明确标记无法到达的代码路径或不返回的函数。它作为一种通用的“底部类型”（bottom type），可以强制转换为任何其他类型。
* **历史背景：** Rust 长期在内部编译器逻辑和特殊情况中使用 `!` 作为返回类型。它取代了 `Infallible` 类型，后者此前是为了弥补缺乏正式 never 类型而采用的变通方案。
* **实现争论：** 参与者对语法进行了讨论，一些人建议使用更具可读性的名称（如 `Never`）来替代单字符的 `!`。但也有观点指出，`!` 在 Rust 的历史和文档中已经根深蒂固。
* **类型安全与强制转换：** 讨论的很大一部分集中在隐式类型转换的复杂性上。尽管一些用户担心隐式类型转换可能引入意外行为，但支持者认为，这对于该语言以表达式为导向的设计至关重要，它能确保发散的代码分支在类型上保持稳健，而无需手动处理不可能的状态。
彭博 (Bloomberg) 需要帮助？请联系我们 我们检测到您的计算机网络存在异常活动 为继续操作，请勾选下方方框以验证您不是机器人。 为什么会发生这种情况？ 请确保您的浏览器已启用 JavaScript 和 Cookie，且未阻止其加载。 欲了解更多信息，您可以查阅我们的服务条款和 Cookie 政策。 需要帮助？ 有关此消息的咨询，请联系我们的支持团队并提供下方的参考 ID。 拦截参考 ID：02caf6a2-aedd-11f1-970c-9ab8954f30bd 订阅 Bloomberg.com，随时随地获取最重要的全球市场资讯。 立即订阅
近期一篇关于 Anthropic 首席执行官达里奥·阿莫代（Dario Amodei）呼吁放缓人工智能发展的文章，在 Hacker News 上引发了激烈辩论。评论者们对于这一声明背后的动机看法严重分歧。
许多用户对此提议持高度怀疑态度，认为这不过是“监管俘获”，或是为了保护即将进行的首次公开募股（IPO）、阻碍竞争对手，亦或是掩盖人工智能实验室已触及性能“瓶颈”这一事实的公关策略。批评者指出，如果这些公司真的担心存在生存威胁，他们应该立即停止开发，而不是继续向通用人工智能（AGI）竞速。
相反，也有部分用户支持这一立场，认为人工智能专家和研究人员确实担忧超级智能失控带来的风险。他们坚持认为，这种对谨慎的呼吁，反映了对开发速度过快及其潜在滥用风险的正当警觉。另一些人则认为，虽然这些担忧合情合理，但重心应从“放缓速度”转向“强化”现有系统，以抵御漏洞和黑客攻击。
归根结底，这场讨论反映出人们对企业人工智能领导层缺乏信任，许多参与者将行业对监管的推动视为一种由经济利益驱动的愤世嫉俗之举，而非出于公共安全考虑。
请启用 JavaScript 和 Cookie 以继续。
```Hacker News最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交登录我最喜欢的几本科幻书：关于我们如何构建社会并不断为之辩护 (bookdna.com)9 分，由 bwb 发布于 1 天前 | 隐藏 | 过往 | 收藏 | 3 条评论帮助
piloto_ciego 20 小时前 | 下一条 [–]
我想生活在《文明》（The Culture）中，如果能有机会搬到阿纳瑞斯（Anarres）并将乌拉斯（Uras）抛在身后，我也知足了。回复readthenotes1 1 天前 | 上一条 [–]
一则广告回复bwb 22 小时前 | 父评论 [–]
不，这绝不是广告。这个网站是围绕着对书籍的共同热爱和发现新书而建立的。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：```
这项研究发现，Android 12 及更高版本的设备存在一个安全漏洞，导致第三方应用程序可以绕过“始终开启的 VPN”和“阻止未连接 VPN 的网络连接”设置。 该缺陷存在于 Android 框架的 `startNattKeepaliveWithFd` API 中。尽管该 API 原本旨在供特权系统使用，但它同时也通过 `UdpEncapsulationSocket` 为普通应用程序提供了公共访问路径。由于框架在将流量卸载到硬件（Wi-Fi 固件）之前，未能验证调用者的资源所有权或执行 VPN 锁定策略，普通应用程序因此可以绕过 VPN 隧道。这使得应用能够直接通过物理网络发送周期性的、固定格式的 UDP/4500 数据包，从而向攻击者控制的端点泄露设备的真实 IP 地址和网络活动。 在 Pixel、三星和 Nothing 设备上进行的对照实验证实了这一行为。由于存在缺陷的框架路径在主流 WLAN 芯片组中是通用的，因此该漏洞影响大多数 Android 12 及以上版本的设备。作者建议弃用这些 IPsec/NAT-T 框架 API 的公共访问权限，并实施严格的准入控制，在允许任何硬件卸载通信之前验证资源所有权并核实 VPN 策略的合规性。在漏洞修复之前，需要高安全流量限制的用户应使用具备 VPN 强制功能的外部路由器。
一份最新报告指出，Android 系统存在一个安全漏洞，其“NAT-T keepalive”功能可能会绕过 VPN 限制。在搭载 Linux 内核 5.7 或更高版本的设备上，普通应用程序可以使用 `setsockopt(SO_BINDTODEVICE)` 强制流量通过特定接口，从而导致数据在 VPN 通道之外泄露。
Hacker News 上的讨论显示，社区对谷歌的应对态度感到强烈不满。尽管研究人员指出了该问题，但据报道，如果 VPN 泄露问题不在谷歌漏洞奖励计划的范围内，谷歌往往不会将其归类为“安全漏洞”，并经常直接关闭报告而不采取立即行动。批评者认为，这使用户处于危险之中，因为谷歌通常只优先处理最新 Android 版本的重大安全补丁。
相比之下，GrapheneOS 团队确认他们已获悉该问题，并正积极对 Android 的 VPN 实现进行系统性重构，以防止此类泄露。对于谷歌的不作为究竟是受限于官僚程序还是故意忽视隐私，社区仍存在分歧。许多用户强调，仅依赖操作系统内置的安全措施依然存在风险。
无稳态性能时代的实验评估方法 [pdf] Experimental Evaluation Methodology for the Era of No Steady Performance [pdf]
2 天前
这是一份 PDF 二进制文件的数据流，由于其中包含的是压缩后的乱码字符，无法直接翻译为可读的中文内容。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
无稳态时代的实验评估方法 [pdf] (cuni.cz)
6 分，luu 发布于 1 天前 | 隐藏 | 过往 | 收藏 | 1 条评论 | 帮助
tdullien 1 天前 [–]
天哪。一想到“无稳态”对于基准测试和性能优化的统计学意味着什么，我就头疼。
回复
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：