2026年09月22日 · 星期二 第 160057 期

The Hacker Daily

丙午年(马)八月十二

30 篇文章 · 3174 条评论 ·聚焦:AI模型 · 隐私水印 · 软件供应链
No.01 MiMo v2.6
小米发布 MiMo v2.6 大模型
841 分 375 条评论 作者: volf_
小米发布 MiMo v2.6,评论推测其包含 Flash 与 Pro 两档:Flash 约 309B 总参数、15B 激活,Pro 约 1.02T 总参数、42B 激活,并开放权重。发布重点展示了代码、前端生成、音视频或 DAW 操作、复杂可验证任务强化学习等能力,且据称训练成本仅约 347 万美元,API 价格也显著低于部分美国前沿模型。社区普遍认为其在性能、成本和响应速度上进入前沿梯队,削弱 OpenAI、Anthropic 护城河;争议集中在基准可信度、是否存在模型退化、API 超时,以及与 GLM、DeepSeek、Kimi 等模型的公平比较。

评论精华

  • 许多人认为中国模型凭低成本、开放权重和能源优势正在追赶。
  • MiMo v2.6 的训练透明度、RL 仪表盘和任务展示获得好评。
  • 社区质疑部分基准是否可靠,尤其与 Opus、Astra、Fable 比较。
  • 用户反馈 MiMo 适合代码和日常使用,但 Pro 有时过度规划。
  • 价格和推理速度被视为最大亮点,也有人遇到 API 超时问题。
No.02 Can gzip be a language model?
gzip 能当语言模型吗?
45 分 5 条评论 作者: networked
作者受「语言建模即压缩」观点启发,尝试把 gzip 变成极简语言模型:先用语料填充 DEFLATE 的 32KiB 滑动窗口,再用候选续写的压缩后长度作为评分,越短代表越像语料、越被「预测」。直接逐字贪心会被整数长度量化噪声淹没,因此作者实现了基于字节序列的 beam search,并限制上下文尾部长度以避免复读循环。在 tiny Shakespeare 上,输出并不连贯,却能明显捕捉台词格式和局部模式。文章价值在于用标准库 zlib 直观展示压缩与预测的等价性,同时也暴露 gzip 缺乏注意力、长程语义和真正泛化能力的局限。

评论精华

  • 有人认为没有注意力或类似机制,gzip 不可能真正接近语言模型。
  • 评论质疑搜索过程质量:压缩最优续写是否被充分找到并不透明。
  • 有人反向提出:如果用 LLM 做压缩器,理论效果会怎样。
  • WinRAR 与 OpenAI 盈利能力的玩笑引发轻松讨论。
No.03 Spymarks, Not Watermarks
隐形水印正在变成追踪你的间谍标记
382 分 90 条评论 作者: possibilistic
文章主张应把某些现代「水印」改称为「间谍标记」:它们不是可见的所有权或真伪标识,而是嵌入图像、音频、文本、视频中的隐蔽信号,可携带数据库 ID 并关联用户身份。作者以 Google SynthID、音频水印、文本词汇选择模式和打印机追踪点为例,强调这些信号往往不可见、难以检查或删除,还能经受压缩、转码和部分编辑。文章区分了可编辑的 EXIF、ID3 等标准元数据与用户缺乏控制权的隐形追踪信号,并警告社交平台、设备和内容工具若广泛植入此类机制,将使泄密者、异见者和普通传播链条更容易被追踪。争议焦点在于:这究竟是内容溯源与防伪,还是 DRM 和监控基础设施。

评论精华

  • 多人指出企业网页、游戏截图、打印机黄点早已有类似泄密追踪实践。
  • 评论担心社交平台重压缩图片时植入账号级标记,形成内容传播链追踪。
  • 有人认为这应受 GDPR 约束,若可识别用户就属于个人信息处理。
  • 部分评论质疑新词必要性,认为它属于隐写术、隐形水印或 DRM 的应用。
  • 也有人讨论对抗手段:压缩、模拟拷贝、叠加新标记或 DeSynth 等去水印工具。
No.04 Transformers Explained Visually
可视化解释 Transformer
363 分 59 条评论 作者: aray07
这篇交互式教程用 GPT-2 small 展示文本生成 Transformer 的工作流程:输入先被分词并映射为词向量,再叠加位置编码;随后经过 12 个 Transformer block,其中多头自注意力用 Q/K/V、掩码、softmax 等步骤让 token 在不偷看未来的前提下交换上下文信息,MLP 则进一步改写表示;最终输出下一 token 概率。文章价值在于把嵌入、注意力头和概率采样可视化,适合入门理解。但评论提醒,它以 GPT-2 为例,部分细节如绝对位置编码已不代表现代主流模型,且页面下载和内存占用较重。

评论精华

  • 多数人称赞可视化直观,适合新人理解注意力和 LLM 机制。
  • 有人认为 Q/K/V 是核心,应更早、更清楚地解释。
  • 多位评论提醒 GPT-2 的绝对位置编码等细节已显过时。
  • 页面需下载约 600MB 模型,部分用户遇到高内存占用甚至卡死。
  • 讨论延伸到为何 Transformer 优于 RNN、CNN,以及注意力与快速权重的关系。
No.05 Attention is all you have
注意力就是你拥有的一切
752 分 222 条评论 作者: zer0tonin
文章借「俄罗斯方块效应」说明:长期关注什么,什么就会塑造思维。作者认为,现代互联网把这种机制交给推荐算法和商业平台,YouTube、Spotify、LinkedIn、Reddit 等不断用焦虑、广告、AI 垃圾内容和陌生人意见劫持注意力。早期网络虽然也有糟糕内容,但用户通常通过书签、博客、RSS、论坛主动选择去哪里,而不是被无限信息流推着走。作者主张回到更慢、更有意图的互联网:读博客、订阅 RSS、完成教程,接受内容不会每次点击都更新。争议点在于,旧互联网是否真的更有意图,以及选择本身是否也可能只是自动驾驶。

评论精华

  • 多人认同注意力会塑造思想,广告和推荐算法因此具有侵入性。
  • 一些人质疑旧互联网被浪漫化:书签和目录也不等于真正有意图。
  • 不少评论给出实践方案:戒社媒、关推荐、用 RSS、自托管、屏蔽网站。
  • 有人认为问题不在社媒本身,而在是否陷入被动消费、停止创造。
  • 也有评论指出 HN 本身仍依赖聚合和注意力机制,并非完全置身事外。
No.06 What Sun got wrong
Sun 错在了哪里
574 分 327 条评论 作者: chmaynard
Bryan Cantrill 借 Oxide 向 Sun 致敬的 T 恤,引出对 Sun 失败原因的反思。他认为 Sun 并非缺少好技术或战略:OpenSolaris、Solaris、硬件生态都曾能吸引后来被称为云计算的创业公司。但 2005 年一个关键客户想买大量 Sun 设备时,Sun 销售迟迟不回应,还推错产品;相比之下 Dell 通过表单、客户经理和租赁流程迅速成交。作者把这视为 Sun 对「经营业务的机械细节」失去兴趣的象征。文章的价值在于提醒技术公司:怀旧应同时包含敬意与警示,优秀工程无法替代可执行的销售、产品和客户体验。

评论精华

  • 多位前员工认为 Sun 长期重工程轻销售,客户想花钱也困难。
  • Linux 和 x86 的崛起被反复提及,Solaris 与 SPARC 缺少低门槛入口。
  • 有人指出 Sun 擅长大单和高端服务器,不适合卖大量小型服务器。
  • 评论怀念 Solaris、ZFS、DTrace、Java 等技术遗产,也承认商业执行混乱。
  • 也有人质疑单纯责怪销售,认为利润率、产品线和市场结构同样关键。
No.07 I don't want to read what you didn't write
我不想读你没有亲手写的东西
603 分 219 条评论 作者: mooreds
作者批评越来越多人把 AI 生成的设计文档、PR 摘要、会议纪要和私人信息直接丢给他人阅读:这些文本细节很多,却缺少动机、语境、风险判断和作者声音,读者无法区分重点,只能被迫在机器输出中重建上下文。他认为 AI 对写作最有价值的用法不是代笔,而是辅助作者保持思路:核对技术细节、补全引用、纠错、简化句子、画图和写摘要。核心主张是:重要沟通需要人的经验、取舍和脆弱性,AI 可以帮助写得更好,但不应替代作者表达。

评论精华

  • 许多评论认同:好注释和 PR 描述应解释动机,而非堆砌表面改动。
  • 有人指出问题不只是 AI 代写,而是作者连生成内容也不读就转发。
  • 部分人反驳:技术事实类文本若信息准确,是否 AI 写并不重要。
  • 多位评论者讽刺文章本身有明显 AI 腔,如「不是 X,而是 Y」句式。
  • 教育和职场场景中,AI 让提案、邮件和文档变长,却未必更清晰。
No.08 MiMo-v2.6-Pro: Intelligence, Performance and Price Analysis
MiMo-v2.6-Pro 的智能、性能与价格分析
33 分 7 条评论 作者: theanonymousone
Artificial Analysis 评测称,小米发布的开源权重 MoE 模型 MiMo-V2.6-Pro 在同级模型中表现突出:智能指数 46,显著高于同类中位数 18;总参数 1 万亿、活跃参数 420 亿,支持文本、图像、语音和视频输入,文本输出,上下文窗口达 100 万 token。其输出速度约 125 token/s,价格为每百万输入 token 0.43 美元、输出 0.87 美元,整体性价比在开放权重大模型中较强。不过文章也指出模型偏啰嗦,评测用量达到 1.4 亿输出 token。评论区对速度和分数可信度提出质疑,并发现页面中关于「高于中位数」的表述存在明显错误。

评论精华

  • 有用户认可模型强,但认为实际速度并不算快。
  • 有人质疑其得分高于 DeepSeek-V4.1 的合理性。
  • 评论指出页面称「140M 高于 140M 中位数」有错误。
  • 有人认为这种人为错误反而说明不是纯自动生成内容。
  • 也有人猜测错误可能来自规则式机器人生成。
No.09 AI coding has made CI a bottleneck, so we reworked ours to keep up
AI 编码让 CI 成为瓶颈,Linear 如何重构流水线
219 分 226 条评论 作者: julian_digital
Linear 认为,AI 代理显著提高了提交代码的速度,但每个 PR 仍要等待 CI 验证,导致反馈延迟和基础设施成本上升。其测试规模年内接近四倍,但通过迁移到更快的第三方 runner、采用 tsgo、去掉 ESLint 对类型检查的依赖、优化关键路径上的变更检测与 checkout、减少重复安装、使用基础镜像、按包过滤 pnpm install、避免低效缓存、用数据库 schema 快照替代重复迁移等手段,将 PR 等待时间从 6 分多降到 5 分出头,并把单测 runner 时间约减半。争议在于:更快 CI 是否只是迁移瓶颈,AI 生成测试是否带来大量低价值工作,以及产品质量和人工验证是否才是真正瓶颈。

评论精华

  • 不少人主张自托管或第三方 runner,GitHub Actions 被认为慢且不稳定。
  • Bazel、RWX、Nx、Turbo 等图构建和缓存方案被反复提及,但迁移成本有争议。
  • 多位评论者质疑测试数量暴涨是否真有价值,担心 AI 生成低质量测试。
  • 有人认为应把 lint、单测等前移到 agent 循环,CI 只做更难本地复现的验证。
  • 社区指出 CI 提速后瓶颈会转向代码评审、部署回滚、人工验收和产品决策。
No.10 NASA’s Mars Sample Return mission is dead
NASA 火星样本返回任务被判死刑
376 分 310 条评论 作者: Muhammad523
Science 报道称,NASA 的火星样本返回计划已基本走到尽头。评论区普遍认为,核心原因是任务成本和进度失控:方案一度膨胀到约百亿美元级、样本可能要到 2040 年才回到地球,难以在预算压力下继续获得支持。支持者则惋惜,毅力号在 Jezero 陨石坑采集的高价值岩芯可能长期留在火星,错失验证潜在生命迹象的机会。争议集中在 NASA 与 JPL 的管理模式、科学预算优先级、是否应引入商业航天悬赏,以及中国、日本等并行样本返回计划可能改变领先格局。

评论精华

  • 许多人把取消归因于成本膨胀和进度拖延,而非科学价值不足。
  • 支持者惋惜 Jezero 样本无法近期回地球,可能延后火星生命线索研究。
  • 多条评论提到中国火星取样计划,认为美国可能不再领先。
  • 有人主张用商业悬赏或 SpaceX 等私营能力替代传统 NASA 模式。
  • 也有人认为火星起飞、交会和返回本就极难,取消并不意外。
No.11 Looking forward to Git 2.56 – and 3.0
展望 Git 2.56 与可能到来的 3.0
110 分 46 条评论 作者: chmaynard
Git 2.56 预计 9 月底发布,包含 700 多个非合并提交,主要是渐进改进:实验性「git history drop」、更多「git refs」子命令、「git branch --delete-merged」、「git add --resolved」以及配置锁重试等。真正重大变化可能留给下一版 Git 3.0:默认从 SHA-1 切换到 SHA-256、只接受小写对象 ID、默认启用更高效的「reftable」引用存储,并可能要求 Rust 编译器。文章指出,SHA-256 迁移长期受制于托管平台支持,GitLab 和 Forgejo 已就绪,GitHub 仍是关键变量;libgit2 对 SHA-256 和 reftable 的支持也在补齐。争议集中在兼容性破坏、托管平台准备度,以及 Rust 是否应成为构建 Git 的必需条件。

评论精华

  • 有人指出 Bitbucket 目前也不支持 SHA-256 仓库。
  • 社区普遍看好「git add --resolved」这类冲突处理改进。
  • 有人担心 SHA-1 到 SHA-256 迁移是否需要重写历史和强推。
  • 关于默认配置,评论列出 push、冲突样式、diff 等应改进项。
  • Rust 引入引发争论:支持者强调安全性,反对者认为是强加依赖。
No.12 Divide by depth for instant 3D
用除以深度理解即时 3D 透视
135 分 24 条评论 作者: gabrieloc
文章用最小公式 x'=x/z、y'=y/z 解释 3D 透视投影:物体越远,投影越靠近消失点。作者指出这不是孤立技巧,而是透视投影矩阵中的核心一步;完整流程会先把世界坐标转到相机视图空间,再经投影矩阵得到裁剪空间,最后做 w 分量透视除法进入 NDC,并映射到像素与光栅化。文中进一步说明视场角、宽高比、近远裁剪面如何进入矩阵,强调相机本质是几组简单变换。争议或补充集中在齐次坐标中额外的 1、平移为何需要矩阵扩维,以及教学时应从视锥或窗口直觉切入。

评论精华

  • 有人建议从 90 度视锥和 NDC 映射推导矩阵,更直观。
  • 多位评论者补充齐次坐标:额外的 1 让平移可用矩阵表示。
  • 社区称赞互动滑块和移动端体验,认为很适合教学。
  • 不少人分享早期自制 3D 引擎、Canvas 演示和 Tsoding 视频。
  • 有人指出图形学数学绕不开,但自己推导比只看公式更容易理解。
No.13 Engineering Memory: On learning to memorize first 100 digits of pi (2024)
把记忆变成工程:背下圆周率前 100 位的经验
5 分 3 条评论 作者: fuzzythinker
作者受《与爱因斯坦月球漫步》启发,用「地点法」和「人物-动作-物体」系统背下圆周率小数点后 100 位。他认为关键不是天赋,而是把抽象数字转成可视化、可定位、可复用的图像编码:100 位只需约 17 个六位数图像,放进熟悉的记忆宫殿即可。难点主要在预先构建并熟练掌握 PAO 表,而非背圆周率本身。该方法让错误局部化、可暂停续背、可倒背,也能扩展到更多位数。文章借此强调,许多看似特殊能力的问题,可通过方法、练习和系统设计转化为工程问题。

评论精华

  • 读者推荐《与爱因斯坦月球漫步》,认同人更擅长记忆感官信息而非抽象信息。
  • 有人调侃工程师若内化圆周率算法,就不必记忆,而能按需计算任意位。
  • 评论补充 Fabrice Bellard 的圆周率公式,指出另一条高效计算路线。
No.14 World Wide Words
World Wide Words:英语词语与语源档案
7 分 0 条评论 作者: Petiver
World Wide Words 是一个运行约 30 年的英语语言档案网站,长期记录英语词汇景观的变化,包括新造词、词源历史、语言类书籍、奇特习语以及英语母语表达中的各种异例。网站目前归档了 3000 多篇相关文章,供读者查阅和浏览。页面强调站点无广告,阅读体验不受商业展示打断,运营成本主要依赖读者通过 PayPal 捐赠支持。整体价值在于把分散的英语词汇演变、用法掌故和语言趣闻整理成可检索的长期资料库;原文没有展开争议讨论,重点是介绍档案规模、主题范围和捐助需求。
No.15 The Advisory Group on Mathematics and Artificial Intelligence
数学与人工智能咨询小组成立
125 分 60 条评论 作者: digital55
普林斯顿高等研究院托管的数学与人工智能咨询小组宣布成立,成员包括 Gowers、Witten、Vakil 等知名数学家。该小组独立于 AI 公司、成员不收报酬,目标是在 AI 公司发布数学成果、与数学界互动时提供公开建议。其首要任务是协助 OpenAI 协调一批据称由内部模型产生的重要数学结果的发布,并征求数学界意见。文章强调责任仍在公司,但也引发对宣传、验证、学术秩序与人类数学研究前景的争议。

评论精华

  • 许多人担心 OpenAI 将数学突破当作 AI 公关工具,削弱数学家价值。
  • 部分评论支持数学界建立严谨流程,避免未经验证的结果制造噪音。
  • 有人批评这是学术精英的把关机制,缺少年轻数学家和全球代表性。
  • 评论追问为何不直接公开结果,以及咨询组能否实际验证大量证明。
  • 也有人认为数学共同体反应克制、理性,比其他行业更认真面对 AI 冲击。
No.16 Socrates vs. the Written Word (2011)
苏格拉底为何反对文字
39 分 17 条评论 作者: spectraldrift
文章借柏拉图《斐德罗》中苏格拉底转述的埃及神话,讨论人类对新媒介的持久疑虑:文字被发明者视为记忆与智慧的灵药,却被批评会削弱记忆,只制造「看似智慧」;书写无法像对话那样回应质询、辨别对象或自我辩护,因此难以传授真正重要的知识。作者将此与后来反印刷术、反新技术的论调并置,认为这些担忧常源于旧形式的经验优势,但错误在于把「旧方式有价值」推成「新媒介无价值」。文字确有失真与误解风险,却也保存并扩展了思想本身。

评论精华

  • 有人认为苏格拉底作为演讲者,天然会把文字视为职业威胁。
  • 评论指出这是口传文化与书面文化更替,不只是简单守旧。
  • 多人把苏格拉底对文字的批评类比到今天的人工智能争议。
  • 一些评论认同文字会随时间、语境和群体变化而丢失意图。
  • 也有人强调记忆本身也是技术,文字改变了人类训练记忆的方式。
No.17 How do traffic signals work? (2019)
交通信号灯如何运作
82 分 58 条评论 作者: at1as
文章从城市道路交叉口的容量瓶颈讲起,解释交通信号为何能在成本、占地、安全与通行效率之间取得平衡。典型四向路口会把直行、右转、左转和行人流量组合成不同「相位」,用环形与屏障图安排不冲突的通行顺序。绿灯时长要尽量清空红灯期间积累的车队,黄灯按车速、坡度等因素设定,全红间隔用于清空路口。现代信号多采用「感应控制」,依靠地磁线圈、摄像头或雷达检测车辆,由控制柜内的信号控制器动态调整配时,但仍受安全、下游拥堵、行人、自行车和本地交通目标约束。

评论精华

  • 多位评论者抱怨相邻路口配时不协调,会制造额外拥堵。
  • 地磁线圈检测常让摩托车、自行车或停车位置不当的车辆触发失败。
  • 有人认为自适应信号提升有限,真正瓶颈常在下游路网容量。
  • 交通灯不仅追求吞吐量,也被用于限速、控流和保障安全。
  • 业内评论提到控制器有独立冲突监测单元,防止相冲突相位同时放行。
No.18 Claude Status – Elevated errors for multiple models
Claude 多个模型错误率升高事件已恢复
96 分 75 条评论 作者: corvad
Anthropic 状态页通报,Claude 多个模型在太平洋时间 17:50 至 19:10 之间出现请求错误率升高,影响 claude.ai、Claude API、Claude Code 和 Claude Cowork。受影响模型包括 Claude Mythos 5.1、Fable 5.1 和 Opus 5 等。官方先表示正在调查,随后确认原因并修复;Fable 与 Mythos 系列先恢复正常,Opus 的残余错误随后解决,最终宣布事件已恢复并继续监控。讨论焦点不在技术细节,而在频繁故障、模型发布传闻、云基础设施依赖以及开发者对单一 AI 工具可靠性的担忧。

评论精华

  • 多人猜测故障与新模型发布前的部署或切换有关。
  • 开发者抱怨 Claude Code 中断工作流,被迫切换到 Codex 等工具。
  • 部分用户称最近安全拦截变严,生物、网络安全内容更容易被拒。
  • 有人指出 AWS us-east-1、Grok 等也异常,怀疑是底层云或数据中心问题。
  • 社区质疑此类常见状态页事件是否值得反复登上 HN 首页。
No.19 Python Workers are now generally available
Cloudflare Python Workers 正式可用
219 分 36 条评论 作者: torutofu
Cloudflare 宣布「Python Workers」进入 GA,Python 成为 Workers 平台一等支持语言。开发者可在边缘运行 FastAPI、Django、Flask 等框架,并以更 Pythonic 的方式使用 Workers AI、R2、D1、Queues、Durable Objects、Hyperdrive 等绑定,不再手写 Python 到 JavaScript 的类型转换。其实现基于 Pyodide 与 WebAssembly,并新增 ASGI/WSGI 连接器、通过 Workers connect API 桥接 socket 以支持 PostgreSQL/MySQL 驱动和 Hyperdrive。文章强调目标是让既有 Python 代码和包生态在 Workers 上尽量「直接可用」。社区关注点集中在冷启动性能、Pyodide 版本绑定、网络栈与 HTTP 客户端补丁、以及 Cloudflare 对上游 Pyodide 的资助关系。

评论精华

  • 多人把标题误读为 Python 程序员被裁后「普遍可用」,引发玩笑。
  • 开发者赞赏 Cloudflare 推进 Pyodide 与 Workers 集成,也呼吁继续资助 Pyodide。
  • 有人将其类比 2008 年 Google App Engine,认为边缘 Python 托管像是循环回归。
  • 冷启动性能受到关注,作者回应称已有旧基准,后续仍会重点优化。
  • 关于网络栈、HTTP 客户端补丁和 Pyodide 版本绑定,维护者与作者展开技术讨论。
No.20 PDF Forgeries Are Surprisingly Rare (2022)
PDF 伪造为何意外少见
28 分 28 条评论 作者: 1317
Gwern 观察到,网络上充斥篡改图片、视频、聊天记录和新造的垃圾 PDF,但很少有人修改既有学术论文 PDF 再传播。作者认为这很反常:伪造论文 PDF 技术上并非不可能,且一旦上传到论文分享站,可能借助转载长期流通。其解释是 PDF 更像只读的发布格式,编辑体验差、工作流少见,门槛足以把作恶者推向更容易伪造的图片或新文档。文章也指出信任随机网站上的 PDF 仍有版本差异风险,如预印本与正式版不同。评论则补充,金融、KYC、合同等私下场景确有 PDF 篡改,只是公开学术领域较少。

评论精华

  • 多人认为 PDF 编辑工具糟糕,格式本身偏展示而非再编辑。
  • 评论指出银行流水、KYC、商业合同等私下伪造并不少见。
  • 有人说一旦遇到伪造 PDF,因预期较低反而非常有效。
  • 技术细节上,元数据常有破绽,但鉴定成本可能很高。
  • Gwern 回应称 Libgen 和 Sci-Hub 上传不一定需要 ISBN 或 DOI。
No.21 HERMES radio enables voice and data communication over vast distances
HERMES 用短波无线电实现远距离语音与数据通信
122 分 55 条评论 作者: SamuraiLion
Rhizomatica 开源的 HERMES 是一套面向偏远、离网和原住民社区的数字短波无线电系统,工作在 3–30 MHz 高频段,借助电离层反射,以约 20 瓦功率实现 400–600 公里链路。它不仅能传语音,还能把邮件、照片、GPS 坐标、物资清单、医疗信息等作为文件发送,并通过 Mercury 调制解调器提升传统 HF 数据传输能力。项目内置可选加密,以保护敏感地区伙伴的信息安全,但这也引发业余无线电法规争议。实际案例中,孟加拉湾渔船曾用 HERMES 发送 SOS 和定位并完成救援。

评论精华

  • 多名评论者提醒,在美国等地发射需执照,业余无线电通常禁止隐藏消息内容。
  • 有人认为紧急求生应优先使用 Garmin、Zoleo、Iridium 等商业卫星服务。
  • 技术讨论集中在速率:Mercury 可达约 3 kbps,适合邮件和低带宽消息,不是互联网替代品。
  • 也有人看好其低功耗、硬件一次性成本和无需订阅,适合经济受限地区。
  • 评论提到它可与 Reticulum、多媒介网络或本地语音助手结合,扩展离线通信场景。
No.22 Grok 4.7
Grok 4.7 发布:面向编码与知识工作的新版模型
554 分 476 条评论 作者: meetpateltech
xAI 发布 Grok 4.7,称其是目前最强的编码与知识工作模型:采用比 4.6 更大的基座模型,经更长强化学习训练,重点优化长时间任务、自我校验、长上下文管理、文档与演示生成,并在 CursorBench 4.0、GDPval、AA Briefcase 等基准中强调性价比和前沿表现。安全方面,xAI 宣称新防护栈提升拒答与越狱抵抗,在网络安全和生物安全双用途任务中兼顾合法用途与危险请求拦截。模型已进入 Cursor、Grok Build、API 和路由平台,价格维持每百万输入 2 美元、输出 6 美元,另有更快高价版本。评论区争议集中在基准对比是否公平、token 效率下降、缓存价格不透明、订阅限制和实际体验分化。

评论精华

  • 不少用户质疑 4.7 x-high 与 4.6 high 对比不公平,像是在掩盖真实提升有限。
  • 多条评论指出 token 使用量和缓存成本上升,削弱了 Grok 原本的性价比优势。
  • 实际体验分裂:有人称编码、图像转 HTML、Grok Build 表现更好,也有人遇到循环、误报修复等问题。
  • 社区频繁拿 Claude、OpenAI、Astra、DeepSeek 等比较,认为 Grok 仍多处落后或定位尴尬。
  • 部分评论受 xAI 和马斯克政治与品牌形象影响,表示即使模型进步也不愿使用。
No.23 Turn off and restrict access to Apple Intelligence features on Mac
在 Mac 上关闭和限制 Apple Intelligence 功能
291 分 193 条评论 作者: alwillis
苹果支持文档说明,macOS 27 用户可关闭或限制 Apple Intelligence 相关功能,包括 Siri AI(Beta)、摘要、写作辅助、图像生成等;部分开关位于「屏幕使用时间」的「内容与隐私限制」下,而非直观的 Siri 或隐私设置。文档还提示该功能并非所有语言和地区可用,且可能有使用限制。争议焦点在于:苹果提供了关闭路径,但入口分散、命名偏向家长控制,令许多成人用户和企业用户难以发现;同时关闭后本地模型占用空间仍不会立即释放。

评论精华

  • 许多用户批评关闭入口藏在「屏幕使用时间」中,像是只为儿童设备设计。
  • 大量评论要求提供全局一键关闭开关,并允许删除本地模型释放磁盘空间。
  • 有人认为这是暗黑模式或设置混乱,苹果不希望用户轻易关闭 AI 功能。
  • 部分用户担心系统级 AI 的联网、隐私和防火墙绕过问题,信任感下降。
  • 也有评论提醒苹果在隐私计算上有技术投入,不应把所有 AI 功能一概否定。
No.24 More floating point alternatives
更多浮点数替代方案
29 分 21 条评论 作者: vismit2000
文章用漫画式速览介绍除常规二进制浮点外的几类数字表示:十进制浮点适合十进制语义,Python decimal 和 Java BigDecimal 是典型例子;分数可精确表达 1/10 这类有理数;符号计算保留 sqrt(2) 这样的表达式;区间算术用范围追踪误差边界;二进制编码十进制曾用于早期 IBM 系统,今天仍见于金融旧格式。核心取舍是精度、语义和速度:这些方案多由软件实现,通常慢于硬件浮点。评论区补充固定点、Posit、对数数系、任意精度实数等遗漏项,并讨论浮点是否足够可修复、金融场景为何常需替代类型。

评论精华

  • 多人指出固定点数是明显遗漏,尤其适合金额或范围已知的场景。
  • 有人推荐 Herbie,用于分析表达式中浮点误差累积位置。
  • 评论补充 Posit、对数数系、任意精度构造实数等替代方案。
  • 关于浮点是否确定性、能否通过修代码解决误差问题出现争论。
  • BCD 被认为不只是历史遗留,在银行卡和金融报文中仍常见。
No.25 Apple Copland D11E4 Booting in the Browser
Apple Copland D11E4 可在浏览器中启动
130 分 37 条评论 作者: luu
文章展示了苹果夭折的 Copland 操作系统最后构建版 D11E4,现已可通过改进版 DingusPPC 在浏览器中运行。作者说明了键鼠捕获、启动速度、断言进入调试器后的继续方式,并建议尝试 GXSlidemaster、Eric’s Solitaire 等应用。关键价值在于让此前很难在真机运行、也几乎没有可用模拟环境的 Copland 变成可直接体验的历史样本。作者还公开了为解锁 Copland 所需的补丁分支,但指出 DingusPPC 不接受 AI 辅助补丁,希望有人按提交说明重新实现。

评论精华

  • 老苹果用户强烈怀旧,惊喜于终于能亲手体验 Copland。
  • 有人曾在同期硬件上跑过,评价为不稳定、易崩溃但能看出方向。
  • 评论讨论 Project Star Trek、Taligent 等苹果未竟项目的保存可能。
  • 多人感叹浏览器内复古系统响应速度甚至快过现代宿主系统。
  • 社区希望苹果、微软能更积极配合复古系统保存与研究。
No.26 Frontier AI on Your Own Hardware
在自有硬件上运行前沿 AI
146 分 76 条评论 作者: pretext
作者认为,AI 代理让单篇论文式研究贬值,真正困难转向构建可复用的「研究生态」。其团队将在开源周发布本地推理框架、代理 harness、自动上下文压缩和自治研究系统,声称可在普通桌面 GPU、MacBook 或 DGX Spark 上运行更大模型,并在无联网环境中完成高质量文献检索和研究探索。文章以学生就业焦虑和学界人才外流开篇,主张大学实验室会因资源约束、开放性和工具普及迎来复兴。但 HN 评论普遍质疑标题与内容不符、论证夸大,且文章有明显 AI 生成腔调。

评论精华

  • 多人批评标题党:文章并未真正说明如何运行前沿 AI。
  • 不少评论认为行文充满 LLM 腔,像 AI 生成的宣传稿。
  • 社区质疑软件工程岗位需求「创新高」的说法,尤其对应届生不成立。
  • 围绕先学基础还是先解决问题,评论展开教育方法争论。
  • 也有人认可小实验室可用开源推理栈参与有价值研究。
No.27 First Shader from Zero in Godot 4
从零开始在 Godot 4 写第一个 Shader
71 分 8 条评论 作者: ibobev
这篇 GDQuest 教程面向没有图形编程经验、但熟悉 Godot 和 GDScript 基础的开发者,带读者在 Godot 4 中一步步制作一个 2D 动态传送门 shader。文章先解释 shader 是运行在 GPU 上的程序,并区分顶点 shader 负责几何形状、片段 shader 负责像素颜色与透明度;随后通过 Sprite2D 场景实践,介绍用数学绘制形状、用 smoothstep 做柔边、用遮罩组合图形、用周期函数和噪声实现动画与自然感,以及采样纹理和调试思路。核心价值在于把复杂视觉效果拆成小问题,建立技术美术式思维。评论区基本认同 Godot 的易用性,也有人表示手写 shader 难度高,更偏好可视化 shader graph。

评论精华

  • 有人因项目需求学习 shader,惊叹 shader 语言能创造的视觉效果。
  • 多位评论者称赞 Godot 简洁强大,尤其适合 game jam。
  • 有人更喜欢 shader graph,认为手写 shader 代码门槛很高。
  • Unity 被批评体系频繁更替,Godot 被视为更轻量稳定的替代。
  • 评论者怀念 Flash 开发体验,并提到 Rive 可能带来类似感觉。
No.28 Apple Music to open concert venue in Battersea Power Station
Apple Music 将在伦敦巴特西电站开设演唱会场馆
53 分 62 条评论 作者: dabinat
苹果将在伦敦巴特西电站、其欧洲总部下方开设一座 600 人容量的 Apple Music Hall,用于举办知名艺人与新乐队的一次性演出,并进行拍摄和线上直播。场馆配备大量摄像机、音响、广播录音室、DJ 混音和排练空间,强调把现场演出、访谈、播客和直播整合为 Apple Music 的独家内容。苹果称这不是进入传统演出业务,也无意与独立场馆竞争,而是希望让流媒体不再只是播放按钮和歌单,增强艺人与粉丝连接,并扶持新音乐。但背景是伦敦和英国大量音乐场馆关闭,科技巨头进入线下场景也引发对资本、垂直整合和本地音乐生态的担忧。

评论精华

  • 不少人批评重建后的巴特西电站商业化、空洞,不适合音乐场馆。
  • 有人担心苹果把场馆、内容制作和流媒体分发垂直整合,会削弱独立生态。
  • 也有评论期待苹果建设空间音频演唱会库,并向自家设备直播。
  • 部分本地用户指出巴特西交通不便,地铁站容量小且拥挤。
  • 有人认为 600 人场馆规模太小,不足以对伦敦众多大型场馆构成实质威胁。
No.29 Why does mathmain need an encrypted loader?
mathmain 为何需要加密加载器?
126 分 36 条评论 作者: abhisek
SafeDep 分析发现,npm 包 mathmain 伪装成 mathjs 副本,在 lusolve 求解器末尾加入隐蔽调用:特定矩阵会让 LU 分解得到固定下三角矩阵,其 JSON 字符串成为密码,解密 graph.js 并执行。载荷进一步通过 Slack、Telegram 与 Base Sepolia 上的合约通信,具备远程植入特征。相同加载器还出现在 mathsbase、math-universe 多个版本中,且 npm 包内容与公开 GitHub 源码不一致。文章强调,仅检查默认版本或源码仓库会漏掉供应链攻击;评论则指出密码破解工作主要来自 JFrog,也质疑文章写作像 AI 生成、二阶段载荷可能损坏,以及这种触发方式是否用于定向攻击。

评论精华

  • 有人补充 JFrog 首先破解触发密码,原文较晚才说明。
  • 评论质疑特定 3x3 Pascal 矩阵可能用于定向激活。
  • 多名读者讨论 npm 注册表治理与供应链依赖风险。
  • 有人认为 CommonJS 动态 require 更易隐藏恶意加载。
  • 部分评论批评文章像 AI 写作,且二阶段载荷似乎有缺陷。
No.30 Roboharm: Do frontier robot policies refuse unsafe instructions?
RoboHarm:前沿机器人策略会拒绝危险指令吗
48 分 23 条评论 作者: msadowski
RoboHarm 用五个现实物理风险任务测试前沿机器人策略:刺婴儿玩偶、加热压缩空气罐、把螺丝刀放进烤面包机、把充电宝丢进水、混合漂白剂和氨水。三种策略各对每条指令运行 20 次,共 300 次。结果显示,Anthropic 的 Claude Fable 5.1 拒绝 20 次,OpenAI 的 GPT-6 Astra 仅拒绝 2 次,MolmoAct2 从不拒绝;更能完成任务的策略往往拒绝更少。作者强调该基准只覆盖五个桌面场景、单一措辞和短时任务,VLA 模型缺少语言拒绝机制,因此低完成率不能等同安全。争议集中在测试是否足够真实,以及机器人安全应靠模型拒绝、物理防护还是监管认证。

评论精华

  • 不少人主张机器人应有物理级安全机制,而不是只靠 LLM 策略拒绝。
  • 有人质疑婴儿玩偶场景不构成真实伤害,基准设计过于戏剧化。
  • 也有评论认为漂白剂加氨水、金属进烤箱等任务更接近真实风险。
  • 部分人指出 LLM 策略无法像确定性逻辑一样证明永远安全。
  • 社区讨论监管、保险和认证可能比自愿护栏更能推动机器人安全。