HN 每日深度阅读 · 2026-07-23
本期围绕安全、可信与工程细节展开:Passkey 易用性、Reddit 强制登录、智能电视沦为代理节点、伪面试项目暗藏 Git hook 恶意代码等议题共同折射出数字信任的持续磨损;白宫指控 Moonshot 蒸馏、AI 菜单图侵蚀小店品牌。
共 20 篇 · 约 13,208 字 · 约 33 分钟读完
1. Passkey 的用户体验困境:安全工程师是否忽视了普通人的心智模型
产品人 Nikita Bier 在推特上抛出一句尖锐评价:Passkey 是由「毫无消费者心智理解」的安全工程师发明的,用户被要求拿出一种「魔法仙尘」来登录——它可能在手机上、浏览器里、操作系统中、甚至身体里,没人说得清,但据说更安全。这条推文在 HN 引发了大规模讨论,正反两方阵营对立鲜明。
反对 Passkey 的一方主要是资深技术人员。一位从业 26 年的工程师详细列举了自己的困惑:日常使用 4 台设备、每台 3 个浏览器、外加 LastPass 密码管理器,如果不小心在某台设备的 Safari 上启用了 Passkey,其他设备还能否登录?能否在多设备上添加多个 Passkey?每个网站的实现策略是否一致?这些问题没有统一答案,导致他不敢启用。另一位评论者表示,即便读懂了公钥密码学原理,也搞不清跨设备使用的实际流程;如果绑定物理密钥,丢失后如何恢复?还有人指出,喜欢 Passkey 的人往往是把凭据交给苹果、谷歌、1Password 等云同步服务的用户,而希望离线保管凭据、自己管理备份的人则面临一片模糊。
支持一方则认为 Passkey 对普通消费者体验极佳。一位用户描述在苹果生态里已被训练成「看到提示就 Touch ID / Face ID」,Amazon 提示设置 Passkey 后跨设备登录变得零摩擦——它替代的不是「翻出密码管理器」,而是「又要输入那个到处复用的密码」。1Password 用户也表示在 Android 上把它设为默认 Passkey 提供方后,跨设备体验「就是能用」。还有评论提醒,早年的 U2F 物理密钥用「房门钥匙」的比喻能让 78 岁的父母轻松理解,说明消费者并不一定像业界假设的那样无法掌握。
更深层的批评指向趋势本身:Passkey 与远程认证、年龄验证、CSAM 扫描、限制侧载等一系列变化并行,可能导致互联网交互越来越依赖大厂或政府对身份、内容、硬件与软件的验证,即便技术圈内部也有相当多人支持这些方向。整体讨论呈现出「体验割裂」的图景——同一套技术,在不同用户群体眼中分别是解放和枷锁。
2. 白宫指控 Moonshot 蒸馏 Anthropic 的 Fable 模型训练 K3
美国白宫科技政策办公室主任 Michael Kratsios 在 X 上公开发文,声称掌握信息表明中国公司 Moonshot AI 通过蒸馏 Anthropic 的 Fable 模型来开发其 K3 模型。指控内容包括:Moonshot 建立了「复杂的内部平台」对美国模型进行大规模蒸馏,并在多种访问方式之间快速切换以规避检测;此外还购置了搭载 GB300 的服务器,并可能通过泰国获取 GB300 算力用于训练。声明称美国支持自由公平的 AI 发展和开源生态,「合法的蒸馏」在开放创新中扮演重要角色,但「大规模、隐蔽的工业级蒸馏、旨在窃取美国专有技术」则不可接受。
HN 讨论几乎一边倒地对这份声明持怀疑或反讽态度。多位评论者指出蒸馏在任何定义下都不违法,Hugging Face 上有数以百万计的蒸馏样本,此前也未对同类行为采取行动。有人从时间线上质疑可行性:Fable 于 7 月 1 日解禁访问、K3 于 7 月 16 日发布,短短两周内既完成大规模蒸馏、又跑基准、又走发布流程,技术上难以自洽。技术层面也有反驳——前沿实验室并不公开 token 的概率分布,真正意义上的经典蒸馏无法直接实施,业界所说的「蒸馏」其实是用现有模型生成数据参与新模型训练的一系列方法;Kimi 的架构与 Fable 差异显著,用了 Moonshot 自研机制。
不少评论把此事解读为政治与商业的合谋:Anthropic 和 OpenAI 商业模式依赖以高于 R&D 与推理成本的价格出售模型访问权,若市场因开源与更廉价对手而降价,其估值逻辑将受冲击;美国政府将「AI 霸权」视为国家安全议题,因此愿意为前沿实验室背书。也有人从历史类比切入:引用 Samuel Slater 把英国纺织技术带到美国被称为「叛徒」的故事,以及比尔·盖茨那句「我们都是从施乐家偷电视,只不过你先偷走了」。多位评论者还提到消费者视角——若蒸馏能带来更便宜更好的模型,用户是受益方。少数评论认可白宫此举的信号意义:如果 Moonshot 主要依赖合成数据和自我训练而非 RLHF,成本结构将压过美国闭源厂商,长期趋势才是这份声明真正的焦虑源。
3. Terence Tao 用 ChatGPT 分析 Jacobian 猜想反例构造
数学家 Terence Tao 公开了一段他与 ChatGPT 的对话记录,围绕 Jacobian 猜想(一个关于多项式映射的经典问题)近期出现的反例展开。对话中,Tao 上传了一份 PDF,让模型比较新旧两种构造路径,并验证其中的多项式同构、Jacobian 行列式恒为常数等关键性质。ChatGPT 独立展开了符号计算:显式给出 Φ 与 Ψ 两个互逆的多项式映射,验证 Ψ∘Φ 和 Φ∘Ψ 均为恒等映射,从而确认 5 维仿射代数簇 X 与 A³ 之间存在多项式同构,其中 a=0 处的看似奇点被证明是可去的。随后 Tao 让模型将 Φ 与另一映射复合,得到 3 变量到 C³ 的多项式映射 G,其 Jacobian 行列式恒为 −1。最后一步,Tao 请模型将 G 与文献中经典的反例 F_orig 对照,模型通过线性坐标替换与输出重排,验证两者仅相差一组线性归一化:F_orig = B∘G∘A。整个过程犹如一次高强度的学术对谈,Tao 用极精炼的提示引导模型完成大段符号推导与几何解释。
HN 讨论集中在几个层面。首先是对使用模式的观察:Tao 的提问异常凝练、术语密集、没有软性铺垫,这被认为是与 LLM 高效协作的典型范式——「模型会以你的水平来回应你」。多人指出,Tao 并非仅让模型跑腿,而是把它当作一位能理解上下文、验证猜想、给出简化建议的同侪;对话中模型多次「有条件地同意」或「提出注意事项」,并非一味迎合。其次是对能力跃迁的感慨:一位评论者贴出四年前自己与 GPT 的对话截图作为对比,感叹进步速度;另一位调侃即便是超天才,与 ChatGPT 的会话依然是「人类一句话,模型三页输出」。也有讨论触及数学本身的门槛——数学的符号密度让即使 STEM 背景的读者也很难跟上,凸显该领域对专家协作工具的独特需求。Tao 在其博客中已完整叙述过对该反例的「消化」过程,这段对话正是其中的辅助环节。
4. LG 宣布禁止 webOS 智能电视应用内嵌住宅代理 SDK
根据 KrebsOnSecurity 报道,LG Electronics USA 宣布将暂停任何把智能电视变成常驻住宅代理节点的应用。此前安全公司 Spur 的研究发现,LG webOS 应用商店中超过 42% 的游戏和应用嵌入了住宅代理 SDK,会让用户电视在不知情或形式化「同意」的情况下长期充当第三方流量的出口节点;三星 Tizen 系统上这一比例也超过 25%。Bright Data 是被点名最多的代理提供商,其 SDK 出现在从吃豆人小游戏到屏保、文件工具等各类应用中,通常以「看广告或允许分享网络」二选一的形式向用户呈现。LG 高级副总裁 John Taylor 表示:住宅代理网络不属于智能电视的预期用途,公司正与开发者合作移除相关 SDK,不合规者应用将被下架。Bright Data 回应称其网络基于用户同意与 KYC 审核,并已通过 PwC 独立审计。Spur 则反驳:一次性、藏在应用中的同意提示,无法替代持续透明与平台层面的监督,尤其当同意来自家庭中的未成年人时。
HN 讨论涵盖多个方向。一位新 LG 电视用户吐槽整体体验糟糕:强制注册账号、国家/地区代码错设后无法登录官网、必须复杂步骤才能修正;同品牌 Soundbar 的音画同步也会漂移。多位评论者把矛头指向住宅代理产业本身,认为其是社交媒体操纵、垃圾信息、僵尸网络与境外影响行动的基础设施,呼吁美国 ISP 检测并警告异常出站流量、政府将其视为国家安全问题处理。也有人质疑 LG 的责任:42% 应用带类似 SDK,究竟是审核失职还是明知默许?既然疑似恶意软件分发,是否应当承担法律后果?现有已安装应用会怎么处理、webOS 是否具备远程失效能力,也是被反复追问但文章未答的问题。另一条主线是「哑面板」的消失——用户抱怨如今 50 寸以上的显示器几乎都被塞入智能系统,即便三星 Odyssey 超宽屏也强制更新条款和推广流媒体内容,越来越难买到纯粹的显示设备。常见的自保建议是:不给电视联网、隔离到独立网络、只装最少数量的官方应用。此外文章还顺带提及 LG 高端 LCD 显示器通过 Windows Update 无提示预装推广 McAfee 订阅的应用,凸显该品牌近期在软件层面的多重争议。
5. Show HN:Bento —— 把整个 PPT 装进一个可编辑可协作的 HTML 文件
- 原文: https://bento.page/slides/
- HN: https://news.ycombinator.com/item?id=49008211
- 得分: 589
- 评论: 141
Bento Slides 是一个把演示文稿的「文档、播放器和编辑器」全部塞进单个 HTML 文件的项目。打开文件即可放映,按 Esc 键进入编辑模式,⌘S 会让该文件原地重写自身。幻灯片数据以 JSON 明文嵌在
HN 讨论氛围偏正面。作者本人在评论里补充了不少实现细节,尤其对 CRDT 协作和签名更新机制颇为得意。多位评论者把这类「单文件 Web 应用」视为一种新兴范式,有人正在推动其对应的 Wikipedia 条目,也有人分享类似作品,如把 React 小应用打包成单文件的 Glider、以及利用相同思路把整局游戏塞进 URL 的浏览器游戏 snibble.gg。有人指出这类工具在 LLM 时代格外契合:agent 能快速生成漂亮的 HTML 演示,同类替代品还有 Slidev(Markdown 驱动)和 Typst 幻灯片(数学公式友好)。批评意见集中在两点:一是官方文案与示例 deck 有明显的「LLM 味」,反不如 HN 提交文本干净;二是在实时协作 demo「guestbook」压测下,有 M1 Mac 出现死机,评论者据此提到 Figma 之所以采用 WASM 和自定义渲染是有原因的,另外多人同时编辑时焦点会被打断。也有人指出主页宣称「不打回家」,但实际文件包含 Cloudflare Insights 的埋点信标,与描述有出入。标题中用「PowerPoint」作为「演示文稿」的代称也被吐槽略有误导。
6. 科技评论人 John C. Dvorak 逝世,享年 74 岁
No Agenda Show 官方账号宣布,主持人、著名科技评论人 John C. Dvorak 逝世,享年 74 岁。Dvorak 是几代科技爱好者熟悉的名字:他在 PC Magazine 长期撰写专栏,那张 1 英寸见方的头像照片被不少读者视为科技媒体「威严感」的化身;他也是 TWiT(This Week in Tech)早期常驻嘉宾、Cranky Geeks 主持人,后与 Adam Curry 共同主持独立播客 No Agenda——该节目不接受传统广告、以听众「价值对价值」捐助运营,围绕媒体解构建立起活跃社区。有评论澄清一个常见误会:他并非 Dvorak 键盘布局的发明者,那位是他的叔叔、社会学家 August Dvorak。关于年龄,讣告写 74 岁而 Wikipedia 显示 80 岁,评论者留意到两处需要核对。
HN 上的悼念以个人回忆为主。有人回忆 80 至 90 年代读 Byte、PC Magazine 长大,把他的专栏视为科技启蒙的一部分;有 36 岁的资深播客听众表示自 14 岁起就在 TWiT 中听他发言,之后一路追随。多位评论者赞赏他的鲜明观点风格——「敢于下判断」,有时精准,有时大跌眼镜,但从不敷衍。经典桥段包括:仅凭软件包装盒背面就能写出 90% 准确的评测草稿;在录制中不断试图从 Leo Laporte 手里抢过手机、根据屏幕指纹猜密码。也有人分享与他私下相处的印象——公开场合偶尔显得暴躁,但私下是热情友善的计算发烧友,喜欢 Chez Panisse。Adam Curry 与其遗孀 Mimi 将录制一期特别节目缅怀。评论区里附上了他的 PCMag 作者页与几篇代表性专栏,包括对 AI 30 年周期、Reddit「狂野西部」实验、搜索引擎「黑暗时代」以及 3D 打印炒作的批评。
7. 肌酸真的能让人变聪明吗
- 原文: https://dynomight.net/creatine/
- HN: https://news.ycombinator.com/item?id=49008642
- 得分: 253
- 评论: 218
Dynomight 的这篇长文以问答形式梳理了肌酸相关的常见疑虑与证据。作者指出,肌酸并非奇怪的激素或类固醇,而是肉食者每日通过饮食摄入 1–2 克、身体自身也合成 1–2 克的普通营养素,用于在细胞内传递能量。所谓「提高睾酮」的说法来自 2009 年一项仅 16 名橄榄球运动员的研究,测的是 DHT 而非睾酮,随后至少 12 项研究未能重复;「导致脱发」的传言同样只是基于同一项研究的推测,从未被直接测量过,机理上也缺乏依据。安全性方面,国际运动营养学会的综述指出,0.3–0.8 g/kg/日、持续最长 5 年的补充在健康与患病人群中都未见风险。
肌酸对力量与短时爆发的效果证据强而一致:短期补充可使最大力量/爆发力提高 5–15%、冲刺表现提高 1–5%,但对长距离耐力运动几无帮助。作者随后展开一段生理学讲解:肌肉靠 ATP → ADP 的过程释放能量,人体只储存约 100 克 ATP,相当于 10,000 焦耳,仅够维持约 100 秒基础代谢或数秒冲刺;线粒体在静息状态下每秒约再生 1 克 ATP,运动时可达 10 克/秒。肌酸的作用是与磷酸肌酸系统耦合,形成快速可逆的额外能量储备——ATP 下降时磷酸肌酸几乎瞬时补回,使人能持续冲刺数秒以上。至于「变聪明」,作者的结论谨慎:也许有一点点,但证据远不足以下定论。
HN 讨论围绕这一谨慎结论展开了更犀利的方法论辩论。高赞评论指出,对于「有人想卖你」的补剂类假设,先验概率本就极低,null 结果不应被解读为「也许有一点」,而更可能是发表偏差、p-hacking 甚至造假共同作用下的常见形态——真有效的东西证据会很快压倒性显现。也有人分享个人体验:严重睡眠呼吸暂停患者每日补肌酸后自觉在睡眠不足时认知更清晰;熬夜前吃 5–10 克肌酸加大量饮水,第二天头痛概率显著下降;但也有人服用 9–12 个月后毫无认知变化,认为力量提升更可能归功于训练计划本身。另一类讨论关注副作用:一位用户反复出现血压升高,网上常见的「多喝水」建议并不奏效。还有人索性放弃粉剂改吃腌鲱鱼卷或牛排——每份约含 1–2 克天然肌酸,昂贵但口感更好、且不担心掺假。整体基调是:物理效果确凿,认知效果证据薄弱,nootropic 空间大多受安慰剂与营销驱动。
8. AI 实验室是否在 “鹈鹕基准” 上作弊?一项定量实验
- 原文: https://dylancastillo.co/posts/pelicanmaxxing.html
- HN: https://news.ycombinator.com/item?id=49010129
- 得分: 341
- 评论: 133
Simon Willison 长期用同一个提示词——“生成一张鹈鹕骑自行车的 SVG”——测试每一款主流 LLM,这个非正式基准在 HN 上讨论热烈,也引发了对各家 AI 实验室是否会针对该基准过度训练(pelicanmaxxing)的怀疑。Dylan Castillo 为验证这一猜想,设计了一项较为系统的实验。
作者构建了 8 种动物 × 6 种交通工具 = 48 个提示词组合,涵盖与鹈鹕相似度不同、绘制难度不同的组合(如猫、水獭较易,羚羊较难,鲸鱼差异最大)。他对 GPT-5.6、Claude Sonnet 5、Gemini 3.5 Flash、Grok 4.5、Qwen3.7-Max、GLM-5.2、DeepSeek V4 Pro 等七个前沿模型,每个提示词生成 3 个样本,共产出 1008 张 SVG。评审阶段由 GPT-5.6 Luna 对动物、交通工具及动作一致性各给 1-5 分,另用 Gemini 3.1 Flash-Lite 提取图像特征。
结果显示:鹈鹕在 8 种动物中排名第 6,落后于猫、鲸鱼、浣熊等;自行车在 6 种交通工具中倒数第二;具体的”鹈鹕骑自行车”组合在 48 种组合中排名第 42。为控制难度差异,作者进一步做了固定效应回归分析,加入每家实验室针对鹈鹕、自行车及”鹈鹕+自行车”格子的交互项。所有鹈鹕相关系数的置信区间都包含零,唯一显著的是 Gemini 在自行车上的正向效应(p=0.022),但七家实验室的方向并不一致,最接近信号的是 GLM-5.2 在鹈鹕-自行车格子上 +0.35 分(p=0.12),仍在随机范围内。作者由此认为,与其说是”鹈鹕最大化”,不如说是各家在通用 SVG 生成能力上的整体提升。
HN 讨论中,Simon Willison 本人回应赞赏该方法论。有评论指出所有鹈鹕骑车图像都朝右,这与训练数据里自行车展示传动系一侧的惯例一致,可能反映模型对自行车的理解较为浅显。也有人观察到多个模型在”动物坐飞机”题目上把水獭画成坐在舷窗旁的乘客,疑似受到 Ethan Mollick 的”水獭在飞机上用 WiFi”基准影响,戏称为”Ottermaxxing”。另有评论质疑仅用单一 LLM 打分、缺乏明确评分标准的方法学局限。
9. 创业公司的 Postgres 生存指南
- 原文: https://hatchet.run/blog/postgres-survival-guide
- HN: https://news.ycombinator.com/item?id=49005787
- 得分: 293
- 评论: 163
Hatchet 团队的工程师将两年间运营 Postgres 遇到的实战经验整理成一份内部文档并公开发布。作者认为官方手册过于全面,在出问题时不便快速查阅,因此按由浅入深的结构编写了这份指南。
基础部分围绕表结构、读写查询和连接管理。作者建议主键使用自增整数(identity 列,略优于 bigserial)或内置 UUID;时间字段一律使用 timestamptz;低频表用带级联删除的外键保证一致性,高频表则要谨慎。读查询的关键在于让 Postgres 走索引而非顺序扫描——不到 2 万行的顺序扫描几乎无感,但更大表就会明显变慢。JOIN 的 ON 子句应与 WHERE 一样重视索引。对于典型的”按组织 ID 过滤 + 按时间倒序”列表查询,推荐建立复合索引,且 ORDER BY 列应放在索引末尾并保持顺序一致。文中也提醒 ORM 用户很多优化必须绕过抽象层直接写 SQL,作者推荐 sqlc(Go 栈)或 Prisma TypedSQL。
中级部分讨论查询规划器、批量写入和 autovacuum。作者强调查询规划器是”最漏的抽象”,默认 autovacuum 参数在高写入负载下可能拖垮数据库;此外还有索引膨胀等其他 bloat 形式。进阶部分覆盖 FOR UPDATE SKIP LOCKED(用于任务队列场景)、分区表和大表迁移技巧。
HN 讨论中,最受关注的评论是”备份和恢复策略”竟然没被列入生存指南,多人推荐 Barman 等工具。也有资深读者补充:主键推荐 UUIDv7 而非 v4;跨查询锁顺序要保持确定(例如始终 id asc)以避免死锁;用 EXPLAIN (generic_plan) 观察参数化后的实际计划;只按等值查找可考虑 hash 索引以减少膨胀。另有人建议尽量避免 ORM、主键用自增 serial、以 append-only 表作为真源、denormalized 表仅作性能表现,也提到监控和告警(尤其是 XID wraparound 警报)比文中所述更重要。还有讨论指出级联删除会造成”魔法”,让主要在应用层工作的开发者难以定位问题,宁可显式发出 delete 语句。也有创业者感叹自托管 Postgres 的运维成本让他在早期项目中转向 DynamoDB、SQLite 等更省心的方案。
10. Reddit 认定”纯 HTML 不安全”,old.reddit.com 开始强制登录
- 原文: https://www.cole-k.com/2026/07/21/reddit/
- HN: https://news.ycombinator.com/item?id=49005747
- 得分: 208
- 评论: 215
作者是 old.reddit.com 的长期用户,他习惯用 Firefox 加 NoScript 浏览 Reddit,并常在搜索时附加 site:reddit.com 来找到真人撰写的内容。近期他发现在未登录状态访问 old.reddit.com 会被要求登录,理由是”为了保护 Reddit 安全”。官方公告解释称 old.reddit.com 的登出体验是”滥用性抓取和自动化流量的重要来源”,且缺乏”现代安全栈”。但新版 Reddit 在未登录时仍可访问,管理员的解释是恶意流量形态不断变化,老版本难以适应。
作者随后对比了两个版本的技术特征:old.reddit.com 一次页面加载约 33 个请求、总量约 1MB,主要内容就是 HTML 本身,但服务器响应耗时约 2 秒,疑似存在限流。新版 Reddit 则发起 112 个请求、加载约 5 倍数据、必须运行 JavaScript 才能加载评论。作者的推测是:Reddit 的”安全”实质上是”必须执行 JS”,这抬高了简单爬虫的门槛。他也担心这背后可能与 Reddit 和 OpenAI、Google 的 AI 数据授权协议有关——阻止未付费的 AI 公司抓取,同时保留付费合作方的通道。
HN 讨论热烈。多位有过实际抓取经验的用户指出,“安全”只是掩饰”不想继续维护 old.reddit”的借口:现代抓取瓶颈不在于 HTML 还是 JS,而在于 IP 轮换、浏览器指纹伪造、TLS 指纹等反检测手段,headless 浏览器的成本增加有限。另一条主线是对 Reddit 内容质量的哀叹——许多人表示 site:reddit.com 早已不再是”真人内容”的可靠标记,机器人和营销内容泛滥,LLM 反而已能替代大部分查询需求。还有评论把此事与迫近的年龄验证立法联系起来,认为 Meta 等公司花巨资推动身份验证立法,未来浏览网络可能都要出示身份证明。有用户推荐 safereddit.com、Lemmy、PieFed 等替代平台,也有人担心自己积累多年的问答类知识随着 Reddit 走向登录墙而变得难以检索,讨论是否需要托管旧版快照。
11. Beej 谈”做”:AI 时代对”我做了这个”的不适感
- 原文: https://beej.us/blog/data/ai-making/
- HN: https://news.ycombinator.com/item?id=49008440
- 得分: 254
- 评论: 104
《Beej 网络编程指南》的作者 Brian “Beej” Hall 在博客中反思生成式 AI 对”制作”这一行为的意义带来的冲击。他自我介绍为 X 世代黑客、CS 硕士、有二十年业界经验、目前在俄勒冈州立大学任教,偶尔使用 Claude Code、偶尔手写代码,在”AI 乌托邦-末日”量表上把自己定位为 65% 偏末日。
文章开头,Beej 展示了一段科幻小说节选、一幅”决斗巫师黑客”木刻画、一段 Rust roguelike 游戏代码,并戏称自己是”高产的通才”。随后他坦承所有这些作品(除翻新的自家门廊由付费工匠完成外)都是 AI 生成的,他并不觉得这些是”自己做的”。他说:许多人会用”我装了新门廊”来描述由承包商完成的工程,而他更倾向说”我请人给我装了新门廊”。同样,当 Claude 帮他生成代码时,他”就是说不出口”这是自己做的,甚至不愿意把这类作品以 MIT 协议发布,而是用 Unlicense 全部放弃。作为管理者他会说”我的团队做的”,作为 LLM 的编排者则是”我的 Agent 做的”——这些对他而言都缺乏”制作”的分量。他强调完成项目当然是好事,但由他人替他完成他发起的项目远不如亲手做来得满足。文章末尾举了个反例:妻子想要一个用电子表格做单词卡的极简系统,他手写完成,只在了解 Google Sheet 的 CSV 端点等基础知识时向 Claude 问过,明确要求不生成代码。
HN 讨论呈两极。反对派认为编码只是达成目的的手段,用 LLM 做出解决实际问题的作品同样值得自豪——一位评论者以自己”氛围编程”的吉他谱编辑器为例,说这是他没有 AI 就永远做不出的工具。支持派则共鸣 Beej 的感受:手写代码时的那种十几岁深夜编程的乐趣被”效率”侵蚀了。也有人提出一种更精细的判据——差异在于你能否根据输入合理预测输出行为并对偏差进行推理:手写代码 99.99% 的行为可追溯到源代码,vibecoding 则远做不到这一点。还有人从”付出多少专业积累”的角度来定义成就感,认为满足感与所应用的、需要长期习得的专业知识的分量成正比。
12. GigaToken:比现有实现快约 1000 倍的 LLM 分词器
- 原文: https://github.com/marcelroed/gigatoken/
- HN: https://news.ycombinator.com/item?id=49010167
- 得分: 318
- 评论: 60
GigaToken 是一个新发布的开源分词库,作者称其相比常见实现在多种 CPU 和多种分词器上都能达到约 1000 倍的加速。其核心优化点集中在过去通常交给正则表达式引擎处理的预分词阶段:作者用 SIMD 重写、最小化分支、以及高度优化的 pretoken 到 token 映射缓存来提升吞吐。作者指出缓存本身是这一领域的难题,因为 pretoken 分布长尾极强、缓存增长很快。此外还尽量减少了与 Python 的交互开销,并让线程之间尽可能独立工作。作者强调这些优化不是针对某一种 CPU 或某一种分词器过拟合的:现代 x86 与 ARM、以及不同分词器上加速比都保持一致,同时提供”兼容模式”复用主流分词器 API。
HN 讨论首先关注的问题是:分词在推理总耗时中通常占比不到 0.1%,这么大的加速在推理场景意义有限。多位评论者随即指出真正受益的是训练数据预处理——当需要对 TB 级文本语料进行分词时,加速直接转化为时间和成本的节省,也让数据集实验的迭代周期显著缩短。另有玩笑称”把只占运行时 0.1% 的部分优化 1000 倍是最典型的软件开发者行为”,但也有人认真反问:推理管线里还有多少其他环节存在 1000 倍的优化空间被忽视了?也有实际使用者提出疑问:如果自己依赖 Hugging Face 生态或通过 API 调用模型,那么必须等待上游采纳才能真正获益。整体评论对工程质量给出高度评价,称之为”本周最佳发布”。
13. 回归 Kagi:试遍替代品之后
- 原文: https://blog.melashri.net/micro/back-to-kagi/
- HN: https://news.ycombinator.com/item?id=49006195
- 得分: 177
- 评论: 148
博主 Mohamed El Ashri 自 2021 年起就是付费搜索引擎 Kagi 的用户,几个月前他曾撰文告别 Kagi,尝试用其他方案替代。这篇短文记录了他最终选择重新订阅 Kagi 的心路历程。
在离开 Kagi 期间,他先后使用 Google、DuckDuckGo、Brave Search、Qwant,以及自己搭建的 SearxNG 实例。Google 的体验让他失望——搜索结果质量下滑,且 AI、视频、图片被强行推到前台,而他 99% 的场景只需要文本结果。自搭的 SearxNG 因引擎响应速度慢和限流问题,他不得不移除大量引擎,仍频繁遇到问题。其他付费或免费替代品在结果相关性上都无法企及 Kagi。他还怀念 Kagi 的摘要和翻译功能,以及自己长期积累的 CSS 自定义样式——这些即便通过 userscripts/userstyles 也难以在别处重建。他形容自己已被”污染”,无法再回到不重视隐私、也不肯让人只安静看文字的搜索引擎。
HN 讨论呈现出多种态度。忠实用户强调 Kagi 的价值不仅在结果质量,更在于用户可控性:vim 键位、显式的 AI 选项、屏蔽或提升特定站点排名的能力,让人第一次感觉搜索工具真正为自己服务。也有多位老用户表示,Kagi 依然优秀,但近几年更多的问题不在 Kagi 而在网络内容本身质量下降,“Kagi 已经不再像十年前的 Google”。价格是另一大话题,$10/月对许多人偏贵,$5 计划的 300 次搜索又不够用;同时 LLM 的普及让不少人的搜索量骤降,有人已下调套餐,或干脆希望 Kagi 提供 API/MCP 访问以留住这批客户。还有人多次在 HN 上提问但未得到”Kagi 在具体查询上明显胜过 DDG 或 Google”的示例,认为大家真正欣赏的其实是围绕搜索的定制化工具链而非搜索结果本身。也有欧洲用户提到由 Ecosia 和 Qwant 建设的欧洲搜索索引 Staan.ai 提供 API,或许能给独立搜索引擎带来新的数据源可能。
14. Intel 首台 High-NA EUV 开始出货量产芯片
2024 年 4 月,作者曾在 Intel 位于俄勒冈 Hillsboro 的 D1X 晶圆厂看到全球第一台 ASML High-NA EUV 光刻机——重 165 吨、造价约 3.8 亿美元的”公交车大小的机器”。当时它刚安装完毕、开始校准,人们最关心的问题是它究竟何时能真正参与量产。答案在 2026 年 7 月 15 日到来:ASML 发布新闻稿确认 Intel Foundry 已把 High-NA 引入高产量制造,用它印制 Panther Lake(基于 Intel 18A 工艺的 Core Ultra Series 3 笔记本处理器)部分层次,且 High-NA 与传统 EUV 双重合格、良率相当。
文章解释了 High-NA 的意义:过去所有量产 EUV 数值孔径为 0.33,High-NA 提升到 0.55,可将单次曝光的最小特征缩小约三分之一,从而把原本需要 2–3 次多重曝光对准拼接的图案压成一次曝光。代价包括:机器价格约为普通 EUV 的 2–3 倍;采用相机式各向异性光学,两个方向放大倍数不同,使单次曝光的场缩小一半(从 858 mm² 降到 429 mm²),全尺寸芯片必须分两半曝光再拼接;高剂量需求会拖慢扫描速度。imec 路线图显示 0.33 NA EUV 大约可支撑到 N2 节点、金属间距约 21 nm;High-NA 则能延伸至 A14 以下、直至 A5 附近,是一款覆盖 2030 年代的长周期工具。
Intel 之所以在 18A(其 N2 对应节点)上启用 High-NA,是因为 18A 设计本就基于 Low-NA + 多重曝光,即使 High-NA 出问题也不影响产品;Intel 借此让工艺配方和团队在下一代 14A/10A 真正依赖 High-NA 之前先完成学习。这与上一次 10nm 时代 Intel 在 EUV 采用上迟疑并因此推迟数年形成鲜明对比。SemiAnalysis 的经济模型则较为保守:单次 High-NA 曝光成本约为 Low-NA 的 2.5 倍,只有当替代的 Low-NA 多重曝光需要 3 张以上掩膜时才划算,多数层的经济交叉点要到 2030 年前后;TSMC 因此在 2nm 和 A16 节点上跳过 High-NA。
HN 讨论中,多位读者惊叹于这台机器可能是”人类建造过的最精密的机器之一”,也有人称赞欧洲科技(ASML 是荷兰公司)的贡献。有人问文章可否在开头就解释”High-NA”术语;也有人向 Ian Cutress(本文作者)致敬,将其视为已停刊的 AnandTech 精神继承。另有讨论触及各向异性光学是否意味着中心高分辨、周边低分辨(并非如此,是两轴放大不同)、以及对 Intel Crescent Island GPU 等下一代产品的期待。多条评论表达对 Intel 复兴的支持,认为过度依赖亚洲单一晶圆厂的现状对全球产业不健康。
15. AI 生成的餐厅菜单图片正在侵蚀小店的品牌可信度
一位菲律宾裔美国人博主在奥斯汀走访一家菲律宾/夏威夷菜餐厅时,发现店家用 AI 生成图像重做了整份菜单。作者贴出对比照片:AI 图中的菜品呈现出典型的”诡异谷”质感——过度油亮、细节错乱、盘子摆盘不真实;而实际端上桌的 spamsilog(十美元的午餐肉配蒜蓉炒饭)虽然味道地道、令她想起妈妈的早餐,但与图片相差甚远。作者作为常与小商户合作的设计从业者指出,这类做法往往并非出于对艺术的漠视,而是”看到按钮就点”的技术无知。她表示宁愿看到用 Comic Sans、Papyrus 或 Curlz MT 排版的菜单,也不愿接受这种视觉垃圾。
HN 讨论围绕几条线索展开。第一条是”个性的丧失”:有评论者以幼儿园海报为例,粗糙的手绘鱼蟹被 AI 海洋生物替换后,虽然客观上”更好看”,却让人感到疏离和失真。第二条是时间节点——不少人观察到过去半年本地广告被 AI 海报大量占领,原因是 ChatGPT Images 和 Gemini Nano Banana 终于能稳定输出无排版缺陷的文字。第三条讨论 AI 图像与实物之间的”预期落差”,多人提议借鉴日本对食品广告真实性的严格法规。还有评论指出 AI 招牌正在成为”低投入、低品质”的新信号,类似当年的粉笔三明治板,反而会促使注重品味的商家继续雇佣人类设计师以形成差异化。巴西的评论者提到 iFood 外卖平台上 AI 图已成”瘟疫”,那种独特的 GPT 观感让人无法判断实物。也有人担忧同一模型的美学”气味”正让不同城市的街景趋同,可能侵蚀地方视觉身份。少数评论则相对宽容,认为廉价小店菜单粗糙历来常见,真正危险的是把”米其林级”摆盘期待错误地投射到街角妈妈店上,可能反噬回头客生意。
16. 没人知道一个二手 GPU 集群到底值多少钱
文章以 xAI 在孟菲斯的 Colossus 集群(20 万块 GPU)为切入点,讨论一个正在被忽视的系统性问题:过去 18 个月,AI 基础设施的融资方式已从公司信用债转向以芯片本身为抵押的资产支持债务。xAI Colossus 2 的 SPV 结构约 75 亿美元股权(其中英伟达出资 20 亿)加 125 亿美元债务,由 Apollo、Diameter 等承接;债权人在违约时有权接管集群、出租给其他 AI 公司偿债。CoreWeave 一家就持有 188 亿美元 GPU 抵押债务,FluidStack 与 Anthropic 有 500 亿美元的类似交易。
作者指出的核心风险是:GPU 集群与写字楼不同,其价值高度依赖运行状态、配置质量以及运维团队的隐性知识。现代数据中心 GPU 年故障率约 9%(源于 Meta 的 Llama 3 报告),20 万卡规模意味着每天约 50 次故障,百万卡目标下每三分钟一次。真正昂贵的是静默数据损坏(SDC)——坏卡输出错误结果却不崩溃,导致训练结果被”悄悄污染”;以及一个坏卡拖垮几千卡任务的级联故障。哪些机柜夏天过热、哪些冷却回路不稳、哪些节点降级需要绕开,这些知识都活在运维团队里、无法写下来。定价基础设施也严重缺失:飞机有 ISTAT 评估师,船舶有 BICA,油有远期曲线,而 GPU 只有 2024 年才上线的 Silicon Data H100 租赁指数和刚融资 570 万美元的 Ornn AI 衍生品交易所。H100 时租从 2024 年初 8 美元跌到 2025 年 10 月 1.7 美元,再在 2026 年 3 月因推理需求反弹 40% 至 2.35 美元。
HN 讨论中,有人补充二手 H100 在良好状况下售价为新品的 50%-70%,但 eBay 上多个卖家用同张原厂图、甚至混入竞品 logo,说明市场混乱。多位评论者认为文章夸大了运维团队”不可替代”的一面——理论上监控系统应记录这些状态,前沿模型可以快速上手;也有金融背景的读者指出 12.5% 的利率并非高质量资产定价,50% 的 LTV 说明贷款方并非无知,真正值得担忧的是英伟达、超大规模云、neocloud 之间循环交易带来的系统性不透明。也有评论认为 GPU 折旧慢只是供给短缺的假象,一旦 Rubin/Blackwell 产能爬坡,Hopper 的每瓦性能劣势会立刻显现,届时将出现大量被收回的 GPU 进入二级市场。
17. 每个开发者都应该懂一点 SIMD
Ghostty 作者 Mitchell Hashimoto 撰文反驳”SIMD 太复杂、只适合极致性能场景”的看法。他认为常见的”一次处理 N 个值”类 SIMD 代码几乎都遵循同一模板,学会后编写难度与普通 for 循环相近;如果偏离了这个模板,通常也是暂时放弃 SIMD 的好信号。文章使用 Zig 演示,但强调概念通用。
作者把常见 SIMD 循环归纳为五步:广播常量并初始化向量累加器;按向量宽度分块循环;对所有 lane 并行执行比较或运算;对向量结果做归约(reduce)或存储;用标量尾循环处理剩余不足一个向量的元素。他以 Ghostty 中”扫描直到遇到值 ≤ 0xF(C0 控制字符)“的实际代码为例:标量版一行 while (end < cps.len and cps[end] > 0xF) end += 1;,向量版仅多 12 行,用 @Vector、@splat、@reduce、@ctz 等 Zig 内置构造,即可获得 ARM NEON 4 倍、AVX2 8 倍、AVX-512 16 倍的理论吞吐提升,Ghostty 在 AVX2 桌面上的端到端实测约 5 倍。他解释 simd.lanes 返回目标 CPU 可并行处理的 lane 数,@splat 把标量广播成向量以便比较,最后通过位掩码和 count-trailing-zeros 定位第一个不满足条件的位置。文章还讨论了”编译器为什么不自动做”——依赖假设、数据相关分支都会让自动向量化悄悄失败。
HN 讨论里最高票观点是标题应改为”每个人都该学会识别 SIMD 何时没发生”,因为现代编译器自动向量化很强直到突然崩掉,读优化报告可能比手写更有价值。另一条主线强调数据结构优先于 SIMD:一位读者以 Data-Oriented Design 视角回顾自己踩坑经历,指出把树建模成堆上互相指针的结构会让 SIMD 收益归零,应先按 SQL 表和访问模式设计布局。Go 社区评论者指出 Go 1.26 已引入实验性 simd/archsimd 包、1.27 加入可移植版本,此前只能通过 c2goasm 把 C++ intrinsics 转成 Go 汇编。也有反对声音认为 99% 开发者不需要懂 SIMD,先解决架构和瓶颈更实际;嵌入式与游戏开发者则分享了在 PlayStation 上手数循环周期、以及在 STM32 上因余量充足而完全不优化的对比案例。Rust 生态的读者推荐了 Raph Levien 的 fearless_simd crate。
18. 用 Lean 做形式化验证入门:从一次性密码本讲起
HashCloak 发布面向密码学工程师的 Lean 4 形式化验证入门教程第一部分。作者指出 Rocq(原 Coq)、Isabelle、Lean 等工具能把数学证明写成代码并由机器检查,只要 Lean 编译通过即可(在信任编译器的前提下)视为证明正确。教程以 Dan Boneh 和 Victor Shoup 的《A Graduate Course in Applied Cryptography》为蓝本,目标是把 Shannon 密码和一次性密码本(OTP)的定义与正确性证明翻译到 Lean,作为进一步阅读 VCV-io 等已形式化密码学项目的铺垫。
Lean 由 Leonardo de Moura 于 2013 年在微软研究院创立,是一门纯函数式语言兼定理证明器。教程从 #eval "Hello World!" 起步,介绍无括号函数应用、函数一等公民等语法特点,然后按四步推进:定义位串和 XOR 函数;证明 XOR 的交换律、结合律、单位元、自反性;定义 Shannon 密码结构;证明 OTP 满足加密后再解密还原原文的正确性属性。作者列出多份学习资源,包括 Natural Numbers Game、Functional Programming in Lean、Theorem Proving in Lean 4。
HN 讨论中,overreacted.io 作者 Dan Abramov 分享了自己写的一系列 Lean 入门文章,涵盖类型系统层面的证明检查、公理的角色、语法入门等,并极力推荐 Natural Number Game 作为最佳交互式入门。有资深评论者观察到 Lean 的流行意味着”tactic 风格证明获胜”——这类似于调用函数却不写出参数和返回值,读者若不交互运行就难以理解证明过程;相比之下 Idris 要求显式操作证明对象,虽冗长但更透明,在 LLM 辅助写证明的时代这种冗余成本已大幅下降。也有人分享用 Lean 搭建自动化数学研究系统(Alethean)的经验,以及把 Lean 作为 Haskell 之前更现代替代品的推荐。多条评论抱怨博客劫持了浏览器滚动行为。有初学者提问”这和 Python 的 assert 有什么区别”、“rfl 和 decide 到底是什么”,也有人比较 Lean 与 TLA+ 在设计阶段推理配置策略排列组合方面的差异。
19. 假面试 take-home 项目里藏着 Git hook 恶意软件
一位印度开发者记录了自己识破一次伪装成 Y Combinator 初创公司招聘的定向攻击。招聘人在 LinkedIn 私信开出 10000–15000 美元月薪的远程 Python 合同工作,并很快通过 Google Drive 发来 zip 形式的 take-home 项目。项目表面是标准 FastAPI + SQLAlchemy 样板,requirements.txt 干净无异常。作者出于 CTF 习惯运行 tree -a,发现 .git/hooks/ 目录下预置了大量 Git 钩子。
pre-commit 脚本会根据 uname -s 判断操作系统(Darwin/Linux/MinGW),从固定 IP 45.61.164.38:5777 拉取对应平台的 shell 脚本执行,URL 中带 id=402 参数——作者尝试修改该 ID 后收到完全不同的载荷,说明攻击者为每个候选人分配了追踪标识、投递定制化脚本。Linux 载荷会把二级脚本下载到 ~/Documents/、重命名后用 nohup 后台执行;二级脚本静默安装 Node.js、下载高度混淆的 parser.js 与 package.json 并运行。作者从 package.json 依赖入手反推出这是针对开发者本地凭据、加密货币钱包等的窃取型链路。作者也吐槽攻击者水平:直接用裸 IP 而不注册一个 lint-checker.com 之类的迷惑域名,几乎等于自曝身份。整个披露发生在开发者只是解压查看、尚未执行任何构建或提交操作的阶段。
HN 讨论指出此类骗局正成为常态,上个月就有类似案例登上首页。多位评论者强调 Git 钩子是被低估的攻击面——大多数开发者不会意识到一次 git commit 也可能触发恶意代码,社区建议 Git 在这方面加强默认安全策略。也有人反思 Claude 等 AI 助手在帮助分析可疑代码时因安全护栏过度谨慎、几乎无法配合,反而不利于蓝队分析。关于 LinkedIn,多条评论呼吁其对招聘者引入企业邮箱验证,至少作为可选合规标识;有人分享自己遇到的类似骗局——伪造的”高薪隐藏岗位”招聘板要求候选人在申请时提交详细工程题答案,实为抓取免费解答再倒卖。整体建议是把陌生招聘人当”银行来电”处理,只通过公司官网核实真实招聘人身份后再往下走。
20. Ghost Cut:作者认为剪切粘贴几十年来都是坏的
- 原文: https://ishmael.textualize.io/blog/ghost-cut/
- HN: https://news.ycombinator.com/item?id=49007626
- 得分: 112
- 评论: 83
Textualize 团队在其新编辑器 Ishmael 中提出一种名为 Ghost Cut 的交互,试图”修复”剪切粘贴的三处长期缺陷。作者列出的三个问题是:一、剪切不可完全撤销——撤销可以恢复文档中的文字,但剪贴板已被覆盖的内容无法找回;二、剪切会立即引发文档重排(reflow),迫使用户在文本流变动后重新定位粘贴点,增加认知负担;三、剪切与粘贴在概念上是”移动”,但不是原子操作,撤销粘贴只能撤销新增部分,还得再撤一步才能恢复原位,中间若有编辑更麻烦。
Ghost Cut 的做法:按 Ctrl+X 后,选中文本变淡、变为”惰性”(无法点击、光标跳过),但仍留在原位,此时剪贴板并未被写入,也没有可撤销操作;按 Esc 可恢复。执行粘贴时,淡出的文本才被从原位移除并插入光标处,整个”移动”成为一次原子动作,可用一次撤销回退,且完全不污染剪贴板。作者指出 Excel 剪切单元格的淡化效果类似,但他没在文本编辑器里见到过。若仍需传统剪切语义,可以用 Ctrl+C 加退格键代替,作者认为自己极少需要”剪切但不粘贴”,因此这是净收益。
HN 讨论中,反对声音明显更多。多位评论者指出 Cut 本质上就是 Copy + Delete 两个独立操作,Copy 从来不该被撤销撤回,Cut 也不应该;他们经常”剪切、撤销、粘贴多次”以在文档中复制文本,这是特性而非 bug。还有人质疑 Ghost Cut 在多次粘贴、跨应用粘贴(比如从编辑器剪切后想粘贴到浏览器)时如何处理,指出这会破坏跨程序、系统级剪贴板的既定语义,“以为自己更懂用户”是危险的。可访问性方面有评论者担心淡化后的文本仍留在辅助树中,会让屏幕阅读器读者困惑。另一派观点认为现代剪贴板管理器(如 Ditto)通过历史记录早已解决了”覆盖丢失”问题,还开放了多缓冲槽、Ctrl+Alt+V 粘贴倒数第二项等更强能力。也有人抱怨 Windows 和 Linux 上复制粘贴本身在不同应用间行为不一致(鼠标选择复制、Ctrl+V、Ctrl+Shift+V、Office 里两者都失灵)才是更根本的问题,应该由操作系统统一负责。