Skip to the content.

从 20 条内容中筛选出 13 条重要资讯。


  1. Claude 破解 NIST ECDSA 曲线种子来源:lrand48 加时间戳 ⭐️ 9.0/10
  2. Jake Archibald 对比 JPEG XL 与 AVIF 的网页应用场景 ⭐️ 8.0/10
  3. Mercor:美国 90%的工作时长缺乏 AI 基准测试覆盖 ⭐️ 8.0/10
  4. Home Assistant Supervisor 被曝未经同意向 HIBP 发送密码哈希前缀 ⭐️ 8.0/10
  5. Big Fish:利用 OpenBSD 潜伏 37 年的内核漏洞 ⭐️ 8.0/10
  6. 特斯拉 Roadster 搭载 SpaceX 火箭推进器套件 ⭐️ 7.0/10
  7. llama.cpp 原生运行于已越狱 PS5,可加载任意 GGUF 模型 ⭐️ 7.0/10
  8. Waymo 将自动驾驶网约车服务扩展至多伦多 ⭐️ 7.0/10
  9. 文章从联想记忆的第一性原理推导出 Transformer 注意力机制 ⭐️ 7.0/10
  10. Apple MLX 在四台 Mac Studio 集群上以 36+ tok/s 运行近万亿参数 Muse Spark Open ⭐️ 7.0/10
  11. Anthropic 的 Claude Code 团队披露其自动化代码评审流水线 ⭐️ 7.0/10
  12. Anthropic 在 IPO 前告知投资者:第三季度营收达 168 亿美元 ⭐️ 7.0/10
  13. Simon Willison 的 Chirp Pong:用音频鸣叫联网的手机游戏 ⭐️ 6.0/10

Claude 破解 NIST ECDSA 曲线种子来源:lrand48 加时间戳 ⭐️ 9.0/10

Anthropic 前沿红队(Frontier Red Team)报告称,Claude 在不到半小时内发现:NIST 的 P-192、P-224、P-256、P-384 和 P-521 五条椭圆曲线的种子,并非某个易记短语的 SHA-1 哈希值,而只是 C 标准库伪随机数生成器 lrand48 以某个 Unix 时间戳作为种子后的输出。这一发现据称兑现了由 Go 语言密码学维护者 Filippo Valsorda 为破解这一长期悬案所设立的赏金。 这些种子本应是用来证明 NIST 曲线“清白”的“袖中无物”(nothing up my sleeve)数字,其来源不明在过去二十五年里不断助长“NSA 在标准中埋了后门”的猜疑;如今证明它们只是来自一个用时间戳播种的普通伪随机数生成器,至少消除了这一条疑云。这同时也是一次引人注目的 AI 辅助密码学研究示范——一个悬置数十年的公开难题是由模型而非人类密码学家解决的。 这一结果并非完全收网:属于二元域曲线的第五个种子 B-163 仍无法解释,有评论者推测它可能只是在生成到发布之间的某个环节被误打了一位数字。更根本的问题在于,正如讨论中所指出的,确认生成方法并不能证明这些曲线没有被刻意挑选——因为那些曾生成后来又被丢弃的候选种子,用这种重建方式是看不到的。

hackernews · ahlCVA · 10月16日 18:55 · 社区讨论

背景: ECDSA 是数字签名算法(DSA)的椭圆曲线变体,被广泛用于从 TLS 会话到加密货币的各种签名场景。NIST 在 2000 年的 FIPS 186-2 中标准化 P-192 至 P-521 这几条曲线时,为每条曲线公布了一个“种子”(seed)参数:理论上该种子经哈希(最初是 SHA-1)演算即可得到曲线的 b 系数,从而任何人都能验证这些常数并非被人为挑选以制造弱点。由于没人能复现文档所描述的推导过程,“NSA 秘密挑选了这些曲线”的猜测日渐盛行;而 lrand48 则是 Unix C 库中一个古老的 48 位线性同余生成器,用 Unix 时间戳给它播种虽是常见做法,却也极易被猜测。

社区讨论: Hacker News 的讨论既有一吐为快也有幽默调侃:一条高赞评论戏称“折腾了 13 年的阴谋论,被一句 srand48(time(NULL)) 打回原形”,另一条则说这对“整整一代 NIST 密码学阴谋论者来说是毁灭性消息”。最有分量的反驳意见(来自 fidotron)指出,这只能确认种子的产生方式,并不能证明曲线未被刻意挑选,因为完全可以把生成器跑遍大量时间戳再丢弃候选值;而 teddyh 则提出了一个合理解释——那个无法破解的 B-163 种子很可能只是抄录时打错了一位。

标签: #cryptography, #ECDSA, #NIST, #AI-assisted research, #random number generation


Jake Archibald 对比 JPEG XL 与 AVIF 的网页应用场景 ⭐️ 8.0/10

Jake Archibald 在其博客上发布了一篇针对网页应用场景的 JPEG XL 与 AVIF 详细对比文章,从压缩效率、编码速度和视觉质量三个维度评估这两种新一代图像格式。该文章登上 Hacker News 首页并引发约 142 条评论,从业者纷纷分享基准测试数据、编码器调优技巧以及对感知质量的批评。 对于任何在网页上发布图片的人来说,选择 JPEG XL 还是 AVIF 直接影响页面体积、服务端编码成本和用户感知的画质,因此一份严谨的实测对比对前端与性能工程师极具参考价值。讨论还凸显出:这两种格式的实际表现很大程度上取决于尚不成熟的编码器,而非格式本身的理论上限。 Archibald 的测试显示,libjxl 最高努力级别对照片仅比默认设置小 2–7%,对截图和插画约小 25%,但耗时 9–46 秒,约为默认设置的 50–180 倍,主因是 Butteraugli 感知误差指标的迭代式优化循环。评论者还指出,更好的 JPEG XL 编码器(如 jixel)能在几秒内达到同等结果,并将无损体积缩小 30–39%。

hackernews · farlight · 10月16日 16:12 · 社区讨论

背景: JPEG XL 和 AVIF 是网页上最有望取代 JPEG 与 WebP 的两大候选格式。AVIF 是开放媒体联盟推出的开放、免版税格式,把 AV1 压缩图像封装进 HEIF 容器,浏览器支持度已经很高;JPEG XL 则是较新的格式,主打对现有 JPEG 的高效重压缩以及超高分辨率图像,但其浏览器与编码器支持仍不够成熟。讨论中提到的 Butteraugli 是 Google 提出的感知图像差异指标,用于调优 JPEG XL 的量化参数。

参考链接

社区讨论: 整体情绪偏向支持 JPEG XL,但对两种格式当前的工具体系都有批评:多位评论者认为 libjxl 的高努力慢速模式并不具代表性,因为 jixel 等更快的编码器能达到同等效果;也有人力挺 AVIF 已可用于生产环境,并分享了使用 yuva444p 与 alphaextract 的 ffmpeg 命令链,可在保留 PNG 透明通道的同时把体积缩小十倍以上。最激烈的分歧集中在感知伪影上:一位评论者称被广泛引用的 F1 赛车样图恰好证明 AVIF 会把细腻高光替换成看似合理的伪造细节,而其他人则反驳说 AVIF 在只被匆匆一瞥的大型主视觉图上依然出色。

标签: #JPEG XL, #AVIF, #image compression, #web performance, #Hacker News


Mercor:美国 90%的工作时长缺乏 AI 基准测试覆盖 ⭐️ 8.0/10

Mercor 在其 Labor Index 研究中发布了一份“基准地图”(benchmark map),发现美国约 90%的工作时长都花在现有 AI 基准测试几乎没有覆盖、甚至完全未覆盖的任务上。该分析将基准测试中的提示词(prompt)与真实职业任务进行对照,结论是:很难判断 AI 模型在美国人实际从事的工作上究竟表现如何。 这一发现挑战了“基准分数高就等于真实工作能力强”的假设,并直接影响企业、政策制定者和模型开发者对 AI 自动化就绪度的判断。如果基准测试系统性地漏掉了大部分有薪酬的劳动,那么基于它们做出的部署决策和劳动力市场预测就可能产生误导。 研究指出,即便在控制了 AI 暴露度之后,薪资总额更高的职业所对应的 O*NET 任务在基准提示词中仍被显著过度代表;批评者则指出,“覆盖良好”往往只意味着某个任务有少量提示词——例如一项社会工作类任务仅凭 13 条提示词就被算作覆盖良好。此外,Mercor 自身也在构建评估体系,例如面向商业任务的 APEX-Agents 基准。

hackernews · speckx · 10月16日 17:08 · 社区讨论

背景: AI 基准测试是用于比较模型在特定任务上表现的标准化测试,例如问答、编程或指令遵循类评测集。O*NET 是美国劳工部的职业数据库,把各种职业拆解为具体任务,因此很自然地成为检验基准提示词是否对应真实工作的参照。Mercor 是一家组织人类专家劳动、为前沿 AI 实验室提供训练数据、评估环境和基准测试的公司。

参考链接

社区讨论: 评论者普遍认为这项分析很有价值,但对其框架存在争论:有人用“门卫谬误”(Doorman Fallacy)说明自动化会替代某些任务、却忽略其隐藏职能;也有人引用“鲍莫尔成本病”(Baumol’s Cost Disease),指出编码效率提高 20 倍后,时间只是被会议、Jira 和 QA 填满。最尖锐的方法论批评是:文中把“覆盖良好”当成了“有没有覆盖”的同义词,因为仅靠 13 条提示词根本无法代表一名社会工作者完整的职责。

标签: #AI benchmarks, #AI evaluation, #future of work, #labor economics, #LLM


Home Assistant Supervisor 被曝未经同意向 HIBP 发送密码哈希前缀 ⭐️ 8.0/10

一名用户在 home-assistant/home-assistant.io 仓库提交了 issue #49314,指出 Home Assistant Supervisor 会在没有明确征得用户同意的情况下,悄悄向 Have I Been Pwned 的 Pwned Passwords API 发送密码相关数据。该 issue 获得约 166 分和 118 条评论,维护者 Frenck 参与回应,最初态度较为敷衍,随后道歉并说明可以通过 “ha security options –pwned=false” 关闭该检查。 这场争议凸显了开源与智能家居软件领域的一个普遍矛盾:一边是默认即安全的功能设计,一边是任何向外部共享数据的行为都应尊重用户同意。由于 Home Assistant 通常运行在家庭网络中并管理大量联网设备的凭据,它即便只处理部分密码数据的方式也会直接影响用户信任,并可能影响其他自托管项目如何设计「选择加入」策略。 其机制是 k-匿名泄露检查:只发送密码 SHA-1 哈希的前 5 个字符,再由本地系统将结果与返回的列表进行比对,完整密码始终不会离开设备。Frenck 指出该行为已在 Supervisor 中存在多年,只是最近一次版本修复了提示警告才让用户注意到;该功能针对被标记为密码的应用选项,目前可通过 “ha security options –pwned=false” 命令关闭。

hackernews · trvrprkr · 10月16日 20:33 · 社区讨论

背景: Home Assistant 是一款广受欢迎的开源家庭自动化平台,其 Supervisor 组件负责管理底层操作系统、加载项以及 Home Assistant OS 安装中的配置。Have I Been Pwned 是广泛使用的数据泄露通知服务,其 Pwned Passwords API 允许客户端通过 k-匿名技术检查某个密码是否出现在已知数据泄露中,该技术使服务器无法获知真实密码。许多密码管理器和浏览器都采用同样的范围查询方式,因此即便提示是未经请求的,其技术设计本身通常被认为是安全的。

参考链接

社区讨论: 评论者大体认同:即便数学上安全,未经用户同意的数据共享仍然是同意权问题——有人主张任何产品都不应在未获同意的情况下把用户数据(无论是否哈希)发给第三方,也有人批评那种「因为方法可证明匿名化,所以用户的不适感无效」的敷衍说法。另一些人则为该做法辩护,指出 Home Assistant 采用的是许多密码管理器都在用的 HIBP 安全扫描流程;还有用户提及过去与该维护者的摩擦,称这是他们离开该项目的原因。

标签: #privacy, #security, #home-assistant, #open-source, #data-sharing


Big Fish:利用 OpenBSD 潜伏 37 年的内核漏洞 ⭐️ 8.0/10

一位安全研究员发布了一份详细的分析报告和漏洞利用代码,针对 OpenBSD 中一个潜伏了约 37 年、始终未被发现的内核漏洞,尽管该项目以严格的代码审计著称。这份发布在 calif.io/research/big-fish 上的研究,完整展示了漏洞是如何被发现并转化为可用 exploit 的。 这是关于人工代码审查与静态工具局限性的一个典型案例,说明即便是审计最严密的代码库,也可能隐藏可利用的缺陷长达数十年。由于 OpenBSD 的组件(如 OpenSSH、LibreSSL 和 PF 防火墙)被 macOS、Android、LLVM 和 Windows 广泛复用,这类漏洞的影响可能远远超出 OpenBSD 本身。 社区讨论指出,NetBSD 似乎在 1999 年 8 月重写相关代码时无意中修复了同一个漏洞,这意味着该缺陷只残留在 OpenBSD 这一分支上。讨论中提出的一个关键问题是:fuzzing 或静态分析是否真能发现这类漏洞,还是必须依靠人去思考漏洞利用原语(exploit primitive)才能找到它。

hackernews · rs_rs_rs_rs_rs · 10月16日 14:44 · 社区讨论

背景: OpenBSD 是由 Theo de Raadt 于 1995 年从 NetBSD 1.0 分支出来的、以安全为核心的自由类 Unix 操作系统,以持续主动的代码审计、力求在被利用之前消除缺陷而闻名。内核漏洞指的是操作系统核心(负责内存、进程与硬件访问)中的缺陷,这类问题通常尤其危险,因为内核被攻陷往往意味着整台机器被完全控制。这条新闻的前提是读者了解:OpenBSD 的代码既受到严密审查,又被广泛复用到其他系统中。

参考链接

社区讨论: 评论者称赞了文章中模仿“OpenBSD Release”风格的配图,并打趣说期待配套主题曲;还有人指出 NetBSD 在 1999 年的重写中已无意间修复了同一漏洞。整体观点认为,这说明某些内核漏洞仅靠代码审查极难发现,并围绕 fuzzing 或静态分析是否能真正找出这类漏洞、还是必须依赖人类对漏洞利用原语的洞察展开了争论。

标签: #security, #openbsd, #kernel, #vulnerability-research, #exploit-development


特斯拉 Roadster 搭载 SpaceX 火箭推进器套件 ⭐️ 7.0/10

特斯拉发布了更新版 Roadster,其可选的 SpaceX 套件增加了冷气和燃烧式火箭推进器,能够实现悬停并增强加速;该系统分为两种模式:一种是不燃烧的冷气版本,仅提供额外向前的推力;另一种是演示视频中出现的燃烧式火箭版本,且仅限受邀用户购买。此次发布在 Hacker News 上获得 1130 分和超过 2000 条评论。 它把一款主流电动车推向航空航天推进的领域,模糊了消费级汽车与航天器演示之间的界限,并重新点燃了关于特斯拉这种依赖订金、长期跳票的产品线究竟是工程还是营销的争论。社区反应表明,如今汽车与科技圈受众评估特斯拉发布时,主要看的是可信度与可行性,而非纸面参数。 冷气推进器仅通过让储存的高压(通常为惰性)气体经喷管膨胀来产生推力,因此在各类火箭中推力和效率最低;据报道,A71 系统直接对车身施力,使反作用力绕过轮胎与地面的抓地力限制。评论者指出了根本性限制:高压气瓶、阀门和管路要么占据大部分车内空间,要么只能提供几秒钟的推力,而且燃烧式推进器版本仅限受邀用户。

hackernews · shekhar101 · 10月16日 01:32 · 社区讨论

背景: 冷气推进器是最简单的一种火箭发动机:一个气瓶、一个调节阀、一个喷管和极少的管路,不涉及燃烧,因此成本低、可靠性高,被广泛用于航天器姿态控制和小卫星(CubeSat)推进。把这类硬件装到汽车上很不寻常,因为推力通常受轮胎抓地力限制,而直接作用于车身的火箭推力可以突破这一限制——直到压缩气体耗尽为止。特斯拉多年来一直在预热 Roadster 的「SpaceX 套件」,该车最早于数年前承诺推出,却一再延期。

参考链接

社区讨论: 社区情绪两极分化:一方面有人对工程实现感到惊叹,惊讶它真的能飞,并称赞把风扇和火箭发动机塞进一辆高性能汽车;另一方面则有强烈质疑,认为这只是「迷因股营销噱头」,永远不会量产交付。反复出现的担忧集中在压缩气体储存的物理极限(只能跳跃一次、推力仅数秒)、气瓶和管路占据的巨大空间成本,以及特斯拉以订金形式收取用户多年的「免息贷款」,去买一辆可能永远不会问世的汽车。

标签: #Tesla, #electric-vehicles, #automotive-engineering, #product-announcement, #hype-skepticism


llama.cpp 原生运行于已越狱 PS5,可加载任意 GGUF 模型 ⭐️ 7.0/10

一个名为 PS5LM(cobanov/PS5LM)的 GitHub 项目让已越狱的 PlayStation 5 能够原生运行 llama.cpp,从而直接在主机硬件上加载和执行任意 GGUF 格式的模型,而无需以 PC 作为宿主机。该项目在 Hacker News 上引发关注,因为它把索尼高度封闭的游戏主机变成了一台通用的本地大模型推理机器。 这说明被二次利用的消费级硬件——包括封闭的游戏主机——可以充当廉价且可长期在线的本地大模型推理节点;在人们越来越倾向于本地运行模型而非调用云端 API 的背景下,这一思路颇具吸引力。讨论还指出,这类设备能以远低于商业 API token 的成本承担长时间运行、要求不高的任务。 社区成员提到,它能够以 2-bit 量化运行类似 Qwen 27B 的模型,这种质量足以支撑持续输出、水平一般的 token 流;功耗成本估计约为每天 70 美分,相当于每天约 200 万个输出 token。更关键的一点是:对于监控错误率、查看监控录像这类任务,稳定的廉价可用性比原始基准测试分数更重要。

hackernews · Anon84 · 10月16日 18:32 · 社区讨论

背景: llama.cpp 是一个开源推理库,与 GGML 张量库共同开发,如今已成为 Ollama、LM Studio 等大多数本地推理工具事实上的标准核心。GGUF 是与之配套的模型文件格式,用于封装量化(压缩)后的模型权重,使其能在算力有限的硬件上高效运行。PlayStation 5 是一个封闭平台,通常会阻止运行未签名软件,因此必须越狱才能执行此类代码。

参考链接

社区讨论: 评论者总体持热情态度:有人认为,把封闭设备改造成通用电脑的想法让他们都考虑入手一台 PS5;也有人指出,即使是质量平平的 2-bit 输出,也足以应对监控服务器错误率、查看安防录像等长时间运行的任务。另一些人则提出了实用与法律方面的担忧,认为此类项目不应托管在 GitHub 而应使用自有域名,因为索尼随时可能下架该页面;他们还指出,BC250 显卡(PS5 所用 AMD APU 的缩水版)或许也能运行同样的软件,而且目前在 eBay 上花 150 至 200 美元仍能买到。

标签: #llama.cpp, #PS5, #local-llm, #jailbreak, #GGUF


Waymo 将自动驾驶网约车服务扩展至多伦多 ⭐️ 7.0/10

Waymo 在其官方博客上宣布将业务扩展至多伦多,把自动驾驶网约车服务带入一个寒冷多雪的加拿大市场。公告在第一句话中就提到了创造本地就业,显示公司正围绕经济效益来包装这一举措。 这对商业化自动驾驶而言是一个重要里程碑,因为多伦多的积雪、结冰和融雪盐是自动驾驶感知与规划系统最难应对的条件之一。Waymo 在当地的表现,将在很大程度上决定 Robotaxi 能否从目前气候温和的美国城市扩展到更广泛的市场。 Waymo 已在旧金山、凤凰城、洛杉矶和奥斯汀等城市提供商业服务,并在东京进行测试,但多伦多将是其颇具代表性的寒冷气候首站。低温、积雪和盐雾会削弱摄像头与激光雷达的性能,并遮盖车道标线,因此此次落地很可能涉及大量重新建图与车辆适配工作。

hackernews · ChrisArchitect · 10月16日 14:44 · 社区讨论

背景: Waymo 是 Alphabet 旗下的自动驾驶子公司,运营着名为 Waymo One 的商业 Robotaxi 服务,车内不配备人类安全员。进入一座新城市通常需要制作精细的高精地图、获得当地自动驾驶法规的批准,并与省或州级主管部门协调——在多伦多即安大略省政府。积雪结冰的道路被普遍认为是自动驾驶系统剩下最难攻克的环境。

社区讨论: Hacker News 的评论者分享了差异极大的亲身经历:有人称赞旧金山的乘坐体验,并兴奋地描述在东京街头偶遇 Waymo 的惊喜;但也有奥斯汀的用户表示,一段原本 9 分钟的车程被莫名延长到 45 分钟,最后客服把他们放在一家餐馆了事。还有人指出,出于对失业的担忧,马萨诸塞州等寒冷市场阻挠了 Waymo 所需的立法调整,暗示多伦多公告强调就业创造,是对这类政治阻力的有意回应。

标签: #autonomous-vehicles, #waymo, #self-driving, #robotics, #tech-expansion


文章从联想记忆的第一性原理推导出 Transformer 注意力机制 ⭐️ 7.0/10

Alex Wang 在 alexwang.ai 上发表了一篇教学式博客文章,从联想记忆的第一性原理出发推导 Transformer 的注意力机制,将 Transformer 视为一种现代的单步 Hopfield 式记忆检索系统。 文章将经典联想记忆概念与现代深度学习联系起来,提供了一条直观的桥梁,有助于来自其他领域(如通信和电气工程)的工程师理解 Transformer 的内部工作原理。这类解释对于理解乃至设计更高效的基于注意力的架构具有重要价值。 一个关键观察是,Transformer 只需一步就能检索到合适的存储记忆,而原始 Hopfield 网络需要多次迭代更新才能收敛到能量极小值。文章还涉及现代 Hopfield 网络(也就是密集联想记忆),它打破了经典网络中输入特征数量与存储记忆数量之间的线性缩放关系。

hackernews · speckx · 10月16日 19:01 · 社区讨论

背景: Hopfield 网络是一种循环神经网络,可作为内容可寻址存储器,通过最小化能量函数从部分或含噪输入中回忆出存储的模式。联想记忆(包括自联想和异联想)是指仅凭数据的一小部分样本就能检索出完整数据的能力。Transformer 的注意力机制根据查询与键的相似度对值进行加权组合,而近年来的理论工作已经表明这一操作与现代 Hopfield 网络的更新规则之间存在密切联系。

参考链接

社区讨论: Hacker News 上的评论者赞赏这篇文章,有人指出干扰信号比、信道容量等通信和电气工程概念可应用于理解 AI。另一位评论者请求澄清在 LLM 语境下“值”究竟对应什么,还有一位评论者强调 Transformer 只需一步就能找到合适的记忆,而原始 Hopfield 网络需要多步。

标签: #transformers, #associative-memory, #Hopfield-networks, #deep-learning, #attention-mechanisms


Apple MLX 在四台 Mac Studio 集群上以 36+ tok/s 运行近万亿参数 Muse Spark Open ⭐️ 7.0/10

Apple 机器学习研究团队发布了一项演示:最新版本的 MLX 可以在由四台 Mac Studio 组成的集群上运行 Meta 的近万亿参数开放权重前沿模型 Muse Spark Open,生成速度超过每秒 36 个 token。文章还展示了该方案如何从单台配备最高 512GB 统一内存的 Mac Studio 扩展到多机分布式推理。 这表明几台桌面级 Apple 设备就能在本地承载前沿规模的开放权重模型,无需云端 GPU 或按 token 计费的 API,对隐私敏感和离线场景尤其重要。随着开放权重模型规模不断增大,这也把 Apple 芯片与 MLX 摆上了可信的替代推理平台位置。 这一吞吐量数据是在 8,192 token 上下文下测得的,多位评论者指出这一长度对现代智能体或长文档场景来说远远不够。此外,基准测试中 Muse Spark Open 采用 4-bit 量化,而对标的 Qwen 使用原生 BF16,这种不对等比较受到批评;分布式推理路径依赖机器之间的 RDMA 网络。

hackernews · antipaul · 10月16日 13:43 · 社区讨论

背景: MLX 是 Apple 开源的数组计算框架,专为 Apple 芯片打造,并针对其统一内存架构优化,使 CPU 与 GPU 能共享数据而无需在独立内存池之间复制。分布式推理是指把模型的计算任务拆分到多台互联设备上,而不是只靠一台机器,从而让超出单机内存容量的模型也能被运行。Muse Spark Open 是 Meta 迄今能力最强的美国开放权重模型,专门针对智能体编码工作流训练。

参考链接

社区讨论: Hacker News 的评论者参与度高但态度偏怀疑而非追捧:最主要的批评是用 4-bit 量化的 Meta 模型对比原生 BF16 的 Qwen 并不公平,而且 8,192 token 的上下文让这一演示的实用价值受限。也有人分享了单机独立测试结果(256GB 的 M5 Ultra 运行 DeepSeek 4.1 Flash 0910 约 45 tok/s),还有评论调侃说 Meta 花数十亿美元训练开放模型,最终是让用户掏 2 万美元买 Apple 设备来跑它们。

标签: #local-llm-inference, #apple-mlx, #distributed-inference, #model-quantization, #mac-hardware


Anthropic 的 Claude Code 团队披露其自动化代码评审流水线 ⭐️ 7.0/10

Anthropic 的 Claude Code 团队发布博客,说明其如何在极大规模下进行代码评审——据称每天约 3 万个 pull request——做法是让大部分流程自动化,只把人的注意力投向风险较高的改动。按其描述的规则,文档、文案、仅内部使用的功能,以及隐藏在开关后面的增量改动等低风险类别,只要自动评审和安全检查通过,就完全不需要人工评审;同时评审器本身会持续接受一套评估集打分,而该评估集会随着每一次事故而扩充。 这是一份少见的公开案例:一家人工智能实验室把自家模型用在自己的工程流程上,它会影响其他团队如何看待“评审”这道质量关卡。如果机器生成的代码量持续攀升,那么“有没有人读过这段代码”是否仍是安全性的有效代理指标,就会从哲学问题变成一个实际的工程决策。 值得注意的技术点在于,评审器本身被当作一个被测系统:每一次事故都会补充进评估集,而评审器的每一次改动都要在全部累积的评估集上打分。外部人士提出的质疑则在于规模——每天约 3 万个 pull request,任何人类团队都不可能真正读完其中哪怕一小部分改动,因此验证能力高度依赖自动检查本身是否正确。

hackernews · pretext · 10月16日 19:04 · 社区讨论

背景: Claude Code 是 Anthropic 推出的智能体式编程工具,运行在终端中,能够理解代码库、编辑文件并替开发者执行命令。它由 Claude 系列大语言模型驱动,Anthropic 按能力高低将其分为 Haiku、Sonnet、Opus 等层级。智能体式编程工具每天产生的改动量远超人类团队手写的规模,因此试用这类工具的团队也在尝试用自动化评审流水线取代逐行人工评审。

参考链接

社区讨论: Hacker News 上的讨论普遍持怀疑态度:有评论认为没有人能跟得上每天 3 万个 pull request,Anthropic 实际上是在用 AI 监督 AI;还有不少人质疑代码反复重写的比例以及每行代码可能高得离谱的成本。也有人怀疑这篇博客流畅的文风并非人工撰写,反驳了“放慢速度能降低错误率,主要是因为你做的所有事情都变少了”这一说法,并称让大模型写文档而无人阅读简直是“纯粹的疯狂”。

标签: #AI code review, #Claude Code, #Anthropic, #software engineering, #LLM tooling


Anthropic 在 IPO 前告知投资者:第三季度营收达 168 亿美元 ⭐️ 7.0/10

Anthropic 在周三的投资者日上向投资者披露,其第三季度(7 月至 9 月)营收环比增长近 50%至 168 亿美元,而第二季度为 115 亿美元、第一季度约为 48 亿美元。公司还透露,竞争对手利用其模型输出进行训练的”蒸馏”行为曾占其收入的 5%至 7%,并称已在第三季度”大幅”削减了这类用量。 这些数字让外界难得一窥一家头部前沿 AI 实验室在筹备 IPO 之际的收入规模与增速,进一步印证了企业对生成式 AI 的支出已形成每季度数十亿美元级别的市场。蒸馏问题的披露也凸显了前沿实验室与竞争对手之间的紧张关系——后者购买 API 纯粹是为了训练竞品模型,而 Anthropic 如今正积极限制这类做法。 第三季度 Anthropic 每在算力上花费 1 美元,就能产生 1.70 美元收入;剔除股权激励后的调整后营业利润率为 11%。此外,公司似乎已不再像过去那样向投资者强调”年化运行收入”(annualized run-rate revenue)这一口径。Simon Willison 的粗略推算显示,若蒸馏约占第二季度收入的 5%,那么未具名的竞争对手实验室仅在该季度为蒸馏 Anthropic 模型就花费了超过 5 亿美元。

rss · Simon Willison · 10月15日 13:04

背景: Anthropic 是 Claude 系列大语言模型背后的 AI 公司,也是前沿 AI 系统的主要开发者之一。模型蒸馏(又称知识蒸馏)是一种把大型高性能模型的知识迁移到更小或更廉价模型中的技术,通常做法是用大模型的输出来训练小模型。调用这些输出需要付费,因此当竞争对手从前沿模型蒸馏时,实际上会为模型所有者带来真实的(尽管并非本意的)收入——这也是 Anthropic 在走向上市之际把这一做法同时视为商业与知识产权问题的原因。

参考链接

标签: #AI industry, #Anthropic, #IPO, #business, #revenue


Simon Willison 的 Chirp Pong:用音频鸣叫联网的手机游戏 ⭐️ 6.0/10

Simon Willison 发布了「Chirp Pong」,这是一款双人竞技的类 Pong 游戏,以静态 HTML 形式运行在两部彼此靠近的手机上,游戏状态完全通过音频鸣叫(chirp)传输,并由浏览器麦克风 API 接收解码。他是在 Claude Code 中使用 Claude Opus(文中写作「Claude Opus 5.5 Extra」)构建的,提示词只有一句话:做一个通过音频传输状态的双人游戏,并在画面和玩法上加入比普通 Pong 更有趣、更交织的设计。 它展示了一种非常规的联网方式:不需要服务器、不需要 WebSocket 连接,也不需要蓝牙配对,只要扬声器和麦克风即可通信,这说明在创作型约束下配合 AI 辅助编码,一句话提示就能产出可运行的原型。它也体现出 Claude Code 这类编码智能体正在把小型探索性想法快速变成可公开试玩的成品。 由于整个游戏是静态 HTML 和 JavaScript,两台手机之间唯一的通道就是可听见的声音,因此设备必须靠得很近,而且浏览器会要求麦克风权限,并在用户产生交互后才能开始播放音频。这类基于声音的链路距离短、易受环境噪声干扰,有效带宽和可靠性远低于 Wi-Fi 或蓝牙;对节奏飞快的游戏状态同步而言够用,但不适合通用数据传输。

rss · Simon Willison · 10月15日 19:47

背景: 用声音传输数据是一种成熟的做法:发送方把信息编码成一系列可听见的音调或频率变化,通过扬声器播放,而有麦克风的接收方再把这些音调解码回数据,开源项目「chirp」就采用这一原理。在浏览器中,这依靠 Web Audio API 实现,其中 getUserMedia() 会把麦克风输入采集为音频缓冲区,JavaScript 可以对其做时域或频域分析。Claude Code 是 Anthropic 推出的智能体式编码工具,能在整个项目中编写和运行代码;Simon Willison 则是知名开发者和博主,经常发布这类小型 AI 辅助实验。

参考链接

标签: #game-design, #web-audio, #generative-ai, #experimental-projects, #networking