2026年05月27日 · 星期三 第 122856 期

The Hacker Daily

丙午年(马)四月十一 · 小满

30 篇文章 · 3047 条评论 ·聚焦:AI 与 LLM 趋势 · 编程语言实践 · 复古与科技史
No.01 Cloudflare Flagship
Cloudflare 推出特性开关服务 Flagship
124 分 59 条评论 作者: tjek
Cloudflare 发布了特性开关(feature flag)服务 Flagship,允许开发者在不重新部署代码的情况下控制应用功能可见性。该服务通过原生 Workers 绑定直接评估开关,支持基于用户属性的定向规则(11 种比较运算符、AND/OR 逻辑分组)和基于一致性哈希的百分比灰度发布。Flagship 兼容 CNCF 开源标准 OpenFeature,开发者可通过 「@cloudflare/flagship」 SDK 在 Workers、Node.js 或浏览器中使用,并能一行配置切换其他开关供应商。开关变体支持布尔、字符串、数字和结构化 JSON 对象,可通过 Cloudflare 控制台进行管理并按应用分组。定位上对标 LaunchDarkly、Statsig、PostHog 等成熟产品,凭借 Cloudflare 边缘网络的「零网络跳数」抽象和成本优势切入市场。

评论精华

  • 官方 SDK 文档警告 API token 不限定单个 app,权限粒度过粗,Cloudflare 工程师回复 app 级 token 正在开发中
  • 有人质疑特性开关如此简单为何要外包给第三方,反方认为生产环境涉及多维分群、灰度策略和统计分析会迅速复杂化
  • 讨论与 LaunchDarkly、Statsig、PostHog 等竞品对比,看好 Cloudflare 边缘部署的零跳数延迟和成本优势
  • 对标 Vercel Flags,被视为 Cloudflare「一站式平台」战略的又一拼图
  • 用户普遍抱怨 Cloudflare 缺乏细粒度权限和企业级 Zero Trust 功能,生产环境仍需为此单建账号
No.02 Chemistry behind the Garden Grove chemical tank
加登格罗夫化学罐事件背后的化学原理
282 分 107 条评论 作者: nooks
文章解析了加州加登格罗夫一座装有甲基丙烯酸甲酯(MMA)的化学罐发生失控聚合反应、险些酿成 BLEVE(沸腾液体扩展蒸气爆炸)的事故原理。MMA 在储存时依赖抑制剂阻止自聚,一旦温度升高或抑制剂失效,单体就会发生放热聚合,热量进一步加速反应,形成失控的正反馈循环,罐体压力飙升随时可能爆炸。事故起因据评论提到是配件泄漏后用大扳手敲击修补,注入抑制剂的泵和阀门又堵塞失效。最终罐体出现裂缝泄压,反而避免了爆炸。文章顺带讨论了被动安全设计为何难以彻底解决问题:抑制剂加多了会让产品本身失去用途。争议焦点集中在 MMA 的真实毒性(评论指其 LD50 与维生素 C 相当,并非「剧毒」)、美国化工监管是否到位、以及地方政府应急处置是否得当。

评论精华

  • 有人贴出 iomosaic 对苯乙烯、丙烯酸丁酯类似失控聚合事故的事后分析报告作为对照阅读
  • MMA 毒性被夸大,LD50 接近维生素 C,且 100°C 下基本不会以蒸气形式释放
  • 罐内 MMA 很可能已完全聚合成一整块 PMMA 固体,未来或需吊车整体移出
  • 曾尝试注入抑制剂减缓反应,但泵和阀门堵塞失效;裂缝泄压才是阴差阳错的救命稻草
  • 对用步枪打孔泄压的设想,评论指出高压容器穿孔会直接引爆,并非可行方案
No.03 The just-say-no engineer was a ZIRP phenomenon
「凡事说不」的工程师只是零利率时代的产物
7 分 0 条评论 作者: jxmorris12
作者认为,那种以「说不」为己任、专门否决变更、阻止复杂度蔓延的资深工程师archetype,本质上是 2008 至 2022 年零利率政策(ZIRP)时代的特殊产物。彼时科技公司靠廉价资金疯狂扩招,需要这类「把关人」来制衡到处乱跑的工程师、维持系统秩序、并塑造高技术门槛的招聘形象。ZIRP 终结后,公司被迫聚焦盈利,AI 浪潮又恰好成为裁员的体面借口。如今管理层不再默许「说不」工程师否决方案,反而要求他们配合放行 AI 生成的 PR,甚至给出差评。作者指出,这一转变与 AI 关系不大,根源是经济环境变化:即便没有 LLM,文化也会同样转向。讽刺的是,若 ZIRP 仍在,AI 代码洪流反而会让这类工程师身价暴涨。文章建议这类工程师转向编译器、运行时等「纯粹工程」岗位,那里仍需要高质量门槛和慢节奏,而大多数产品团队已不再适合他们生存。
No.04 Where does next-token prediction leave us?
下一个 token 预测把我们带向何方
57 分 26 条评论 作者: 0x5FC3
作者批评 AI 圈中流行的「solved」「cooked」话语,认为这种对人类创造力被取代的庆祝带有阶级色彩——欢呼者多半有社会安全网作缓冲,而全球过半人口没有。文章指出 AI 行业的奠基叙事正在崩塌:从「拯救人类于气候、疾病、贫困」滑向赤裸的「削减劳动力」。Anthropic 的 Dario Amodei、OpenAI 的 Sam Altman 等高管公开宣称大学位无用、白领工作即将消失,剥夺了普通人最后的议价筹码——劳动本身。作者强调 AI 表面上「民主化」知识,实则把生产资料集中到少数掌握算力与闭源模型的巨头手中,「门槛」与「天花板」被同时抬高。所谓「with AI, not by AI」只是自我安慰,企业最终想要的是只付 token 成本。文章引用 Fields 奖得主 Tim Gowers 关于数学家「不朽」可能终结的感叹,并谴责训练语料的默认 opt-in、廉价标注工与数据中心抬高的电价,将 AI 热潮定性为资本主义的极端样本。

评论精华

  • 有评论引 Harari 观点:连军事服务都被 AI 取代时,民众将彻底失去筹码。
  • 有人反驳「playing God」叙事,认为作者本身也在制造夸张恐慌。
  • 讨论中层管理者用 agent 绕开程序员,类比业余装电源插座,能用但隐患大。
  • 「democratization」一词被批评是漂白话术,编程门槛在互联网时代本就极低。
  • 有人质疑作者关于「科技对底层冷漠」的论断,并就医疗进步是否惠及穷人展开争论。
No.05 A few interesting modern pixel fonts
A few interesting modern pixel fonts
290 分 64 条评论 作者: zdw
(摘要生成失败,请查看英文原文)
No.06 I Bypassed Adobe and Microsoft to Build a Git-Tracked Book Production Pipeline
绕开 Adobe 与微软:用 Git 管理的小说出版流水线
190 分 55 条评论 作者: dustin1114
作者是独立小说家兼软件工程师,写有「光之见证者」系列三部曲。过去他依赖 Word 写稿、InDesign 排版、Calibre 做 EPUB、Kindle Create 生成 KFX,每改一处都要在四套工具间来回同步,Linux 主力机还跑不了 InDesign 和 Kindle Create,只能切到 Mac。受 Standard Ebooks 项目启发,他在写第三本「Prince of Savoy」时改用 SE 的命令行工具链,把 DOCX 经 Calibre 转成干净 EPUB,再按 SE 风格指南手工打磨,享受像 lint 一样的严格校验。回头修订首部曲时,他干脆把源文件迁到 LibreOffice 的 ODT,用语义化段落和字符样式标注歌曲、书信、外语、祈祷文等,既利于无障碍阅读,也便于程序化转换。最终他得到一份 Git 版本控制的 XHTML 源,用 「se build」一键产出 EPUB,彻底摆脱 Adobe 与微软订阅。

评论精华

  • 多位读者推荐 Typst、Asciidoctor、Pandoc、LaTeX 等更纯粹的纯文本方案,认为更适合 Git 工作流。
  • 前商业印刷从业者指出 InDesign 其实支持脚本和外部主文档自动更新,作者的痛点其实可以自动化解决。
  • 有人吐槽 Standard Ebooks 流程过于繁琐,推荐给作者朋友前要三思。
  • 关于正文为何不用纯黑而用深灰,有人解释是 CMYK 色彩管理或长时间阅读减轻眼疲劳,也有人反驳称纸张已不是纯白,文字应保持纯黑。
  • 评论区调侃这本质上就是 CS 博士和学术圈用 LaTeX 排版几十年的老套路,只不过被独立作者重新发现了一遍。
No.07 The Forgotten Art of the LAN Party (2023)
被遗忘的局域网派对艺术
52 分 16 条评论 作者: susam
作者回忆 2001 年和朋友们把三台 19 寸 CRT 显示器、主机和 24 口交换机塞进一辆 1984 年福特小车,开到朋友家通宵联机三天的「局域网派对」(LAN Party)。文章定义 LAN Party 为一群人把设备接入同一局域网联机的社交聚会,核心优势是几乎零延迟,但更关键的是面对面的亲密社交体验:欢呼、咒骂、披萨、能量饮料和体味混杂在一起,往往持续 8 小时到 3 天。其衰落源于宽带普及消除了延迟优势、网吧分流人群、2010 年代常态化的「always-online DRM」让厂商砍掉 LAN 模式(「Spawn 安装」等共享方式被废)、Discord 和在线匹配进一步降低了 LAN 的感知价值。但作者认为 LAN 派对并未死,反而比以往更易举办:游戏本普及、显示器轻便、家家有 Wi-Fi。他把 LAN 派对列为每个玩家都该体验一次的「人生清单」项目。

评论精华

  • 挪威「The Gathering」每年仍吸引约 5000 人参加,LAN 派对并未消亡
  • 有人在大学组 LAN 时电流过载,跳了整栋学生楼的电闸
  • kentonshouse.com 等专门为 LAN 派对设计的房屋是必看参考
  • 文章混淆 Wi-Fi 与有线交换机,二者延迟差距仍然显著
  • 用 3 台原版 Xbox 加路由器就能办 12 人 Halo 局,给孩子的派对很受欢迎
No.08 From Rust to Ruby
从 Rust 到 Ruby:一次用本地 LLM 完成的反向迁移
54 分 23 条评论 作者: xlii
作者把自己一个约 1.5 万行 Rust 代码的 Web 子项目(Axum + Tera + Diesel)用本地 Qwen3 在 4090 上一次性转成了 Ruby on Rails,仅 3322 行,代码量减少 77%,每行 Ruby 抵 4.49 行 Rust。动机是 Rust 编译慢、依赖庞大、Mock 困难、E2E 测试要起 Playwright 加独立数据库,单元测试体验糟糕;而 Rails 自带电池、VCR 录制几行就能替代一大坨「MockProvider + Arc + RwLock + async_trait」样板。作者还让多个 LLM 给两种方案打分,Rails 综合得分比 Rust 高 1.47 倍,类型安全可用 Sorbet 或 Agent 补回。坦诚之处在于:转换花了 30 分钟,但他还没运行过新代码,只是「看着挺干净、挺地道」。文章核心是单人项目里开发幸福感与样板量的权衡,而非性能或安全的对决。

评论精华

  • 有人质疑:代码都没跑过就发博客,毫无说服力
  • 支持派认为这正说明业界该成熟讨论语言取舍而非装作没有
  • Rails 党称没有哪个框架像它这样把开发者幸福感放第一
  • 反对者吐槽 Rails 的 method_missing 和元编程让调试堆栈里出现源码不存在的方法
  • 有人推荐 Elixir/Phoenix,能拿到类似 DX 又没有 Ruby 的魔法陷阱
No.09 A portentous reunion
三十年同学聚会与一场关于 AI 的预兆性重逢
73 分 21 条评论 作者: cafkafk
作者 Bryan Cantrill 参加大学三十周年聚会,发现同龄人最普遍的焦虑都围绕大语言模型对知识工作和子女未来的冲击。借此他回忆了 1993 年与同学合作开发的双人对战俄罗斯方块「BattleTris」:用空模拟线缆联机、可买武器干扰对手,曾在布朗大学软件工程课的 Demo Day 上引爆全场,后被学弟 Adam Leventhal 接力组织锦标赛,并在 Sun 公司复活。文章穿插一段温情往事,他后来的妻子 Brigid 第一次赢下他时,他误以为游戏崩溃,Adam 的一句「她就是那个对的人」促成了求婚。叙述中 BattleTris 因 DTrace 与生活变迁逐渐沉寂,移植到现代系统成了「不敢动」的工程。文章把对 AI 时代的不安与对手工创造、人与人协作记忆的怀念并置,提出在「去人性化」担忧下,重温这种亲手做出的温度,本身就是一种回应。

评论精华

  • 作者本人补充:与焦虑家长谈去人性化的同时讨论这段人情味往事,体验很奇特
  • 应对剧变最关键的是与模糊性共处的能力,比掌握具体知识更重要
  • 有人反驳近 30 年文化反而比之前各十年更同质,缺乏可辨识的时代标签
  • 技术圈推荐 Tetrinet、超级任天堂的 Tetris Battle Gaiden 等同类对战作品
  • 有人指出 AI 高度中心化、无法拥有,与传统社会支柱不同,风险被低估
No.10 Stripe is friendly to “friendly fraud”
Stripe 对「友好欺诈」过于友好
178 分 118 条评论 作者: gingerlime
作者销售一款叫 Ciglue 的雪茄修补胶水,遇到顾客两次下单后均发起拒付。第一单 DHL 已签收,顾客谎称银行误判并承诺通过 PayPal 退款,作者按规矩提交了所有证据。结果顾客其实是故意作假,银行照例站在持卡人一边,作者损失货款、产品、运费和拒付手续费。第二单同样以拒付收场,顾客还发邮件嘲讽作者。作者将证据截图交给 Stripe,希望被纳入跨商户的反欺诈信号或上报银行,但 Stripe 明确表示不会用单个商户的拒付滥用证据来生成跨商户欺诈信号,只建议作者付费升级用 Radar 规则屏蔽该顾客再次下单。作者认为 Stripe 一边宣传机器学习反欺诈网络的强大,一边对实打实的「友好欺诈」证据视而不见,下一个商户照样会被同一个人坑,这种态度等于默许欺诈。

评论精华

  • 有人指出可禁用高风险地区或国家,能切掉八成此类欺诈
  • 多位卖家认为「友好欺诈」占拒付的九成以上,远超真欺诈
  • 建议拒付即全面封号:卡号、邮箱、设备指纹一起拉黑
  • 有人替 Stripe 辩护,称封禁决定权在发卡行,且跨商户黑名单可能触犯 FCRA
  • 也有人怀疑 Stripe 类似 PayPal 2.0:对平台内不当行为睁一只眼闭一只眼
No.11 IBM Confidential: System/360 File Organization [video]
IBM 机密档案:System/360 文件组织(视频)
7 分 0 条评论 作者: DaiPlusPlus
这是一段标注为「IBM Confidential」的历史培训影像,主题是 1960 年代 IBM System/360 大型机的文件组织方式。System/360 是计算机史上里程碑式的产品线,首次在不同型号间统一指令集架构,奠定了现代主机与兼容机的基础。视频很可能介绍当时主流的存储与文件结构,包括顺序文件、索引顺序文件「ISAM」、直接存取文件以及后来演化为 VSAM 的早期形态,并讲解记录格式、块大小、磁带与磁盘卷的组织方法。对今天的开发者而言,这类资料的价值在于回看「文件即数据库」的年代如何在没有关系模型、没有现代文件系统抽象的条件下,用 JCL、DCB 和访问方法把业务数据组织起来,理解 IBM 大型机生态延续至今的设计取舍与术语来源。由于帖子尚无评论,社区讨论焦点暂未形成。
No.12 Launch HN: Minicor (YC P26) – Windows desktop automations at scale
Launch HN: Minicor (YC P26) — 大规模 Windows 桌面自动化
84 分 51 条评论 作者: fchishtie
Minicor 是一家 YC P26 批次的初创公司,专注于为没有 API 的遗留桌面系统(EHR、ERP、DMS、PMS 等)构建可大规模运行的「自愈式」RPA。其核心思路是把自动化主体存为确定性代码(实际就是 Python 脚本),仅在出错或边缘情况时调用计算机使用 Agent 与 LLM 视觉来恢复,号称点击准确率可达 93-96%,远高于纯 computer-use 模型的 80-85%。一次 API 调用即可触发部署在 Windows 虚拟机、浏览器、本地或 Citrix 上的工作流,返回结构化 JSON。平台支持 SOC 2 Type II、HIPAA,可整套容器化部署在客户 VPC 内,PHI 不出网。目标客户是面向医疗、汽车、物流、金融等行业销售 AI 产品的公司,例如已支撑每天 25,000 名患者的生产负载。创始人强调「写一个 RPA 不难,难的是大规模维护」,认为传统 RPA 脚本太脆弱,而纯 Agent 又不够稳,混合方案才是最优解。

评论精华

  • 有人吐槽落地页通篇用「RPA」缩写却从不展开解释,对外行不友好。
  • 创始人澄清:底层自动化其实就是 Python 脚本,Agent 只用于异常恢复。
  • 隐私关键问题:截图只截界面局部区域用于 LLM 判断「是/否」,不含患者数据,日志写在客户自有桶。
  • 讨论指出遗留系统用户反而最愿意拥抱 AI,因为现有软件实在太难用,且付费意愿强。
  • 有用户反映一天前刚遇到欧洲团队做几乎一模一样的产品,赛道开始拥挤。
No.13 Tunecat: Simple Internet Radio
Tunecat:极简的网络电台
21 分 0 条评论 作者: croottree
Tunecat 是一个托管在 Codeberg 上的开源项目,定位为「简单的互联网电台」。从命名和描述推断,它应是一款轻量级的网络广播工具,允许用户收听或搭建流式音频电台,强调简洁和易用性,避开主流平台的臃肿与商业化。项目选择 Codeberg 而非 GitHub 托管,也透露出作者偏好独立、去中心化基础设施的取向,符合自由软件社区的审美。这类工具通常面向喜欢 curated 音乐流、播客或环境声响的用户,作为 Spotify、SomaFM 等服务的极简替代品。具体功能细节(如支持的协议、是否带 Web 界面、流媒体格式等)需查看仓库 README 才能确认。该帖目前在 HN 上尚未引发讨论,关注度较低。
No.14 Big tech's anti-labor playbook has come for Wikipedia
维基媒体基金会用大厂反工会剧本对付维基百科员工
379 分 214 条评论 作者: cdrnsf
文章指控维基媒体基金会(WMF)正在复制大型科技公司的反劳工策略:在英文维基百科编辑酝酿罢工、员工推动组建工会之际,WMF 解雇了 MediaWiki 的核心开发者之一 Brooke Vibber,并解散了以志愿者社区为产品负责人的「社区愿望清单」团队。作者强调,WMF 上财年收入 2.086 亿美元、储备金达 2.966 亿美元,约合 17.1 个月运营开支,根本不缺钱,却把矛头对准让维基百科得以运转的雇员和志愿者。文中将此视为「平台资本化」征兆:非营利组织聘请企业型 CEO,把募捐来的钱投向与编辑社区无关的项目,同时挤压一线工程师和编辑赖以维生的工具与流程。社区端,志愿编辑被迫维护「影子 IT」式的自有工具链,新人上手门槛飙升、贡献者持续流失。文章呼吁读者反思捐款流向,并把这场工会化行动放在更大的「平台衰退」(enshittification)背景下审视。

评论精华

  • 前重度编辑感叹维基已不再是当年那个值得每天投入数小时的开放社区。
  • 解雇 MediaWiki 元老 Brooke Vibber、砍掉社区愿望清单团队是导火索。
  • 英文维基编辑被迫自建工具链,基金会却把钱投向与 enwiki 无关的全球南方项目。
  • 17 个月运营储备对长期使命型基金会并不算多,工会化诉求与财务无直接矛盾。
  • 多人呼吁停捐 WMF,认为非营利更需要工会来制衡管理层「劫持捐款」。
No.15 Erin Brockovich made a map to track data centers around the country
艾琳·布罗科维奇做了一张全美数据中心追踪地图
167 分 165 条评论 作者: cratermoon
环保活动家艾琳·布罗科维奇(因奥斯卡获奖电影闻名)推出了一个工具,用于绘制全美数据中心分布地图,并提供表单让民众上报本地数据中心及其影响。她写道,建设 AI 基础设施的「竞赛」正在美国一座座城镇间展开,有些地方欢迎数据中心,有些地方则推迟、抗议甚至放弃项目。这张地图试图呈现这场竞赛的真实地理足迹,揭示增长、冲突与不确定性的模式。截至发布时,地图显示 33 个运营中数据中心、44 个在建和 27 个提议中项目,并已收到 2716 份社区报告。随着数据中心需求飞涨,相关环境与社区影响争议同步升温,调查报道数据中心已逐渐成为独立的新闻线口。

评论精华

  • 有人质疑重复造轮子,datacentermap.com 等已有更可靠的数据库
  • 多位评论者指出网站本身明显由 AI 生成,从文案到代码风格都很 Claude 味,颇具讽刺
  • 对水耗与生态危害的指控有人认为是 FUD,也有人举犹他州 O'Leary 项目反驳
  • 争论焦点:「AI 数据中心」与传统数据中心区别在于 GPU 带来的更高功耗与散热密度
  • 有人担心反 AI 情绪过激可能引向针对设施的暴力行为,也有人认为社区知情权天经地义
No.16 Rosalind: A genomics toolkit in Rust running whole-genome pipelines on a laptop
Rosalind:用 Rust 写的基因组工具包,在笔记本上跑全基因组流水线
138 分 37 条评论 作者: samuell
Rosalind 是一个用 Rust 编写的基因组学工具包,作者 logannyeMD 自称其为「确定性基因组引擎,内存占用紧凑」,目标是在普通笔记本上完成全基因组分析流水线。作者在评论中承认这是去年的原型项目,最近因 HN 关注度突增才被注意到,目前并未持续维护。社区反应褒贬不一:有人质疑测试用例形同虚设,仅检查「无错误」而不验证比对结果是否正确;也有人指出当前存在一股用 LLM 把生信工具改写为 Rust 等更快语言的潮流,Seqera Labs 甚至发布过相关「宣言」。支持者举出 Nextclade、质谱蛋白组学工具等已在生产中采用 Rust 的成功案例,认为方向值得肯定。批评者则要求作者明确支持的测序读长类型,并与 Samtools 等成熟工具做严格基准对比,否则不敢使用。还有评论调侃这类「我最爱语言重写生信工具包」的仓库多年来层出不穷,多属「学位论文软件」(dissertationware)。

评论精华

  • croemer 指出比对测试只查无报错,未验证正确性,形同笑话
  • 作者 logannyeMD 承认是去年原型,因 HN 突增 100 星才回来看
  • a_bonobo 提到当前 LLM 驱动的「Rust 重写生信工具」潮流
  • shpongled 举例已有质谱蛋白组学 Rust 工具被广泛采用且有遥测数据
  • mriet 要求与 Samtools 做大测试集对比,并明确支持的读长类型
No.17 Spain blocks prediction markets Polymarket, Kalshi over lack of gambling licence
西班牙以无博彩牌照为由封禁预测市场 Polymarket 与 Kalshi
821 分 376 条评论 作者: thm
西班牙监管机构以缺少博彩牌照为由,封禁了 Polymarket 和 Kalshi 两大预测市场平台。报道背景下,这两家平台被视为披着「预测市场」外衣的赌博服务,需要受博彩法监管而非证券或衍生品框架。评论区披露的关键事实:按交易量计算,Polymarket 约 80%、Kalshi 约 90% 的活跃度都集中在体育博彩,并非政治或战争等公共议题。争议焦点有三:一是平台是否在激励权力者操纵现实以赢取赌注,已有记者收到与导弹袭击押注相关的死亡威胁;二是与禁止给他人投保人寿或火灾险的逻辑类似,对他人事件下注存在道德风险;三是美国监管的双重标准,现任政府家族成员据称在相关公司任职获利。也有声音认为预测市场优于传统赌场,因为对手是其他玩家而非庄家,且不会因赢钱被封号。封禁手段方面,西班牙惯用的 DNS 屏蔽容易被 Google/Cloudflare DNS 绕过,链上合约更难彻底封堵。

评论精华

  • 数据揭穿叙事:Polymarket 八成、Kalshi 九成成交量其实都是体育博彩
  • 与禁止给他人买寿险同理,对他人生死下注会制造谋杀激励,已有记者收死亡威胁
  • 西班牙 DNS 封锁形同虚设,换 Google 或 Cloudflare DNS 即可绕过,链上更难封
  • 支持者反驳:预测市场对手是玩家不是庄家,赢家不会像 DraftKings 那样被封号
  • 讽刺美国不会跟进,因为现任总统家族正在该行业董事会上「捞外快」
No.18 Dropbox CEO Drew Houston to step down
Dropbox CEO 休斯顿卸任,产品负责人接棒
315 分 342 条评论 作者: aghuang
Dropbox 创始人 Drew Houston 宣布卸任 CEO,将先与从产品负责人晋升的 Ashraf Alkarmi 共同担任联合 CEO,随后转任执行董事长,最终由 Alkarmi 独掌大权。43 岁的 Houston 近 20 年前在 MIT 因频繁丢 U 盘而创办 Dropbox,是首位带 YC 公司走到 IPO 的创业者,个人净资产超 20 亿美元。但公司市值仅约 60 亿美元,较 2018 年上市首日高点腰斩,也低于 2014 年私募估值的 100 亿;近两年营收停滞,2025 年甚至小幅下滑。同为 YC 校友的 Airbnb 已近 800 亿市值,对比鲜明。Dropbox 长期受困于苹果、谷歌、微软、亚马逊等平台方将云存储作为系统级功能集成,如今又面临 AI 冲击。Houston 否认存在「SaaS 末日」,称从未遇到客户因 ChatGPT 取消订阅,并寄望 AI 搜索产品「Dash」打开新局面。他坦言下一步想自己创业做 AI,「不会去开帆船赛」。同期前谷歌 Chrome 产品副总裁 Mike Torres 将于 7 月加盟任 CPO。

评论精华

  • 平台厂商把同步做成系统功能,Dropbox 增长天花板早已注定
  • 免费 2GB 与 2TB/120 欧元之间缺中间档,劝退大量轻度付费用户
  • 重写桌面客户端为 Python 后同步变差,CPU 占用高被诟病
  • 产品自 2013 年后基本停滞,「是个功能不是产品」乔布斯一语成谶
  • Linux 客户端仍稳定可用,是少数没放弃 Linux 的大厂同步服务
No.19 What I've Learned (So Far) Building Online Mini Games with Elixir and Swift
用 Elixir 和 Swift 做在线小游戏的一些经验
15 分 9 条评论 作者: calflegal
作者分享了独立开发社交街机应用「Migo Games」的技术选型与心得。后端采用 Elixir/Phoenix 部署在 Fly.io,数据库用 Crunchy Bridge 托管的 Postgres;客户端用 Swift 加 SpriteKit,仅引入了一个 Phoenix socket 客户端依赖,二进制体积只有几 MB,作者拿 Mario 64 的 8MB 作类比,认为 AI 反而能帮助减少代码膨胀。他强调 Elixir 的「房间」抽象与 BEAM 进程模型天然对应,扩展性和容错性都很好,单个房间崩溃不会影响整个系统,类似 Cloudflare Durable Objects 的思路。建议同时支持 Mac 端,因为 Xcode 模拟器太慢,Mac 原生构建快得多。在原生与 Web 的对比上,他认为 iPhone 上原生在触感反馈、动画、全屏体验上完胜 Web。作者坦言整个项目几乎全靠 AI 写代码,自己主要把关设计;但 AI 解决不了分发难题,反而因 App Store 应用爆炸式增长让获客更难。

评论精华

  • 有人想了解为何选 Elixir 而非 TS,以及实时多人同步如何实现
  • 质疑 BEAM 对小游戏是否过度设计,Fly.io 稳定性也常被吐槽
  • 原生移动端反馈循环比 Web 慢,开发体验上 Web 仍占优
  • 作者承认服务器在新泽西,欧洲玩家延迟会很明显
  • 宣称支持 Web 但链接都跳转 App Store,安卓和网页用户被排除在外
No.20 The Steinwinter Supercargo
被遗忘的Steinwinter Supercargo:1983年的未来卡车梦
54 分 14 条评论 作者: itronitron
Steinwinter Supercargo是1983年法兰克福车展上亮相的奇特商用车,由德国斯图加特工程师Manfred Steinwinter设计。这款卡车采用极低底盘(仅比兰博基尼Huracan高半英寸),搭载奔驰OM422八缸柴油引擎,输出276马力和753磅英尺扭矩,配16速ZF变速箱。设计初衷是通过模块化平台提升运输效率:货柜可直接叠放在车顶,缩短整车长度从而在法规限制内装载更多货物。内饰相当豪华,配Recaro真皮座椅和居中驾驶位,颇有跑车风范。然而项目最终失败,原因包括驾驶视野极差、操控难以调校、可靠性不足。奔驰拒绝支持后资金断裂。该车1988年曾在美剧「The Highwayman」中露面,2002年最后出现在「Power Rangers Time Force」拍摄现场。文章借此反思卡车设计创新的困境,并质疑特斯拉电动半挂是否会重蹈覆辙。

评论精华

  • 有人指出波音在西雅图也用类似车辆驳运超长货物的尾部
  • 讨论是否启发了「异形」中的APC装甲车,但后者实际改自Hunslet ATT77
  • 设计动机是法规只限整车长度而非挂车,缩小牵引车可多装货物
  • 底盘过低导致通过性极差,被质疑实用性,有人拿雪铁龙BX类比
  • 有读者回忆当年在德国少儿年鉴「Das Neue Universum」上读到此车,印象深刻
No.21 Sonny Rollins, jazz saxophonist, has died
爵士萨克斯传奇 Sonny Rollins 离世,享年 95 岁
70 分 12 条评论 作者: boarsofcanada
被誉为「萨克斯巨人」的爵士传奇 Sonny Rollins 于周一在纽约 Woodstock 家中辞世,享年 95 岁。他在哈莱姆长大,7 岁起接触萨克斯,高中时已与 Jackie McLean 等人切磋技艺,毕业后即加入 Fats Navarro、Bud Powell 的乐队。1950 年代是其创作巅峰期,他与 Miles Davis、Thelonious Monk、Max Roach 等大师合作,并写下成为爵士标准曲的「Oleo」。1957 年的「Saxophone Colossus」奠定其领班地位,「Way Out West」则开创无钢琴三重奏格式,反过来影响了 Ornette Coleman。1959 至 1962 年他隐居在 Williamsburg 大桥上独自练琴,复出专辑直接取名「The Bridge」。1981 年他为滚石乐队「Waiting on a Friend」献上经典萨克斯独奏。9·11 事件中他从世贸中心附近寓所撤离仅带走萨克斯,数日后在波士顿演出留下专辑「Without a Song」。他于 2014 年退休,被同行 Wayne Shorter 形容「已渗入我身体的每一个毛孔」。

评论精华

  • 有人 1997 年蒙特雷爵士节看过他,票来自连续 30 年同行的老乐迷团
  • Rollins 在超市听到「Waiting on a Friend」,心想终于有首滚石歌好听,才发觉萨克斯是自己吹的
  • 1998 年堪萨斯城现场,他在「St. Thomas」上即兴了 36 段,灵感源源不绝
  • 巧合的是,Pink Floyd 的萨克斯手 Dick Parry 也在几天前刚去世
No.22 Use boring languages with LLMs
用「无聊」的语言搭配 LLM 编程
196 分 146 条评论 作者: evakhoury
作者认为「一致性会复利」:大语言模型会放大生态分裂的代价、强化约定统一的优势。Python 的包管理器、JavaScript 的框架矩阵在训练语料里方差极大,导致 agent 输出风格漂移、随机装包、复刻 2019 年的怪异写法。相对地,Rails 因为「只有一个 Rails」,推理输出更稳定。作者重点推荐 Go:goroutine 替代了「函数颜色」问题;net/http 与加密库等标准库覆盖大部分后端需求;gofmt、go vet、gopls、golangci-lint 提供单一正确风格和实时语义反馈;带 GC 的原生性能避开了 Rust 借用检查与 C/C++ 内存陷阱对 agent 的折磨;idiomatic Go 的「踩雷点」集合是有界的。结论不是「Go 最好」,而是低方差语料 + 单一工具链最适合 agent 编写 CLI、后端、agent 编排器这类非 GUI 软件。

评论精华

  • 有人反驳:Go 的并发模型反而让 LLM 频繁滥用 mutex 和锁,竞态处理并不省心。
  • 支持者认为 Rails、Elm、Java 21+Spring Boot 等强约定栈同样表现优异,印证「约定优于配置」。
  • 反方观点:Haskell 等强类型语言通过 sum type 和穷尽匹配,反而给 LLM 更强的纠错信号。
  • 有评论指出 Python 包管理器只需起步时定一次,并非 LLM 出错的真正瓶颈,非局部副作用才是。
  • 有人呼吁用 benchmark 而非空谈,提到 AutoCodeBench 显示 LLM 在 Elixir 上表现意外突出。
No.23 Liverpool and Manchester Railway
利物浦与曼彻斯特铁路:世界上第一条城际铁路
19 分 7 条评论 作者: daverol
本文回顾了 1830 年 9 月 15 日开通的利物浦与曼彻斯特铁路(L&MR),它是世界上第一条城际铁路,也创下多项「第一」:首条完全依靠蒸汽机车牵引、禁止马拉车辆的铁路;首条全线复线;首条拥有真正信号系统、完整时刻表并承运邮件的铁路。铁路由乔治·斯蒂芬森设计建造,全长 31 英里,主要服务于工业革命中利物浦港与曼彻斯特棉纺工厂之间的原料与成品运输,以替代「弯曲粗糙」的收费公路和被指垄断暴利的运河系统。项目推动者为利物浦谷物商 Joseph Sandars 与曼彻斯特纺纱厂主 John Kennedy,受测量师 William James 启发。1825 年首份议会法案因斯蒂芬森测量数据被对方律师 Edward Hall Alderson 诘问时漏洞百出而被否决,改由 Rennie 兄弟与 Vignoles 重新规划路线、绕开反对者土地后,1826 年法案获准。工程难点包括穿越 Chat Moss 沼泽与 Wapping 隧道。铁路商业上极为成功,深刻影响了 1830 年代英国铁路的发展,1845 年被并入 Grand Junction Railway,后并入伦敦与西北铁路。

评论精华

  • 设计者斯蒂芬森被誉为「铁路之父」,还发明了 Geordie 矿用安全灯。
  • 感叹工业革命几乎是英国独力推动,法、西、美早期贡献微乎其微。
  • L&MR 标志着铁路走出「测试版」,从单纯货运升级为成熟客货运体系。
  • 曾经两座城市之间有 4 条铁路线,如今难以想象,若没有汽车铁路本应更繁荣。
  • 外观让人联想到游乐场里供小孩乘坐的迷你小火车。
No.24 What color is your function? (2015)
你的函数是什么颜色?(2015)
106 分 131 条评论 作者: tosh
作者用一个虚构语言的寓言来批评异步编程模型。在这个语言里,每个函数都有「红色」或「蓝色」两种颜色:调用方式不同、蓝色函数不能调用红色函数、红色函数调用起来更繁琐,而且某些核心库函数偏偏是红色的。这就强迫程序员在整个调用链里时刻关心颜色,函数复用变得极其痛苦,高阶函数更是难以做到「颜色多态」。揭晓谜底时,红色函数其实就是异步函数,蓝色是同步函数,JavaScript 的 Node.js 回调风格正是这一困境的典型。文章核心观点是:把同步和异步在语法层面割裂会污染整个代码库,任何想抽取复用的代码都要被迫选边站,而且这种感染会顺着调用栈一路向上蔓延。作者借此暗讽 callback 风格异步设计的本质缺陷,并指出 Go 这类用运行时隐藏并发细节的语言反而避开了这个问题。

评论精华

  • 有人认为 async/await 已基本解决该问题,文章在 2015 年写时只是猜测
  • 反方观点:Go 等隐式异步语言其实仍有颜色,只是把问题藏起来,边界情况更难调试
  • 支持者称函数着色是好事,显式标注让调用者明白函数的语义和性能特征
  • 代数效应(OCaml 5、Ante)被认为是更彻底的解法,但也有人担心每个库自带颜色反而更糟
  • 实践派建议:Python 后端干脆全部同步,或像 Julia 用 @spawn/fetch 按需异步
No.25 Sage Care (YC S24) Is Hiring Software Engineers
Sage Care(YC S24)招聘软件工程师
1 分 0 条评论 作者: ian-gillis
Sage Care 正在为家庭护理机构打造 AI 原生的 CRM 和虚拟助手,目标是把客户电话和上门访视自动转化为结构化的护理计划、跟进任务和系统记录。创始团队指出,家庭护理机构靠人际关系运转,却被大量文书工作拖住:接待协调员要花数小时手动转写通话、制定护理方案、追踪后续事项,这些开销让机构无法专注于服务对象。Sage 直接对接机构已有的 WellSky、AxisCare 等工具,支持 iOS 和桌面端,号称每位客户的接待环节可节省 100 分钟以上。公司处于早期阶段,资金充足,签约机构速度较快,现正招募早期工程师,向 CTO 直接汇报,参与塑造技术基础并推动平台发展,对公司走向有较大影响力。岗位还列出了一些「加分项」技能,但正文未展开具体技术栈细节。
No.26 The real cost of owning a home
买房的真实成本
323 分 686 条评论 作者: ggcr
作者以自己 2011 年在巴尔的摩买的 1983 年老房为例,逐项拆解房屋持有的隐性成本,反驳「租房就是把钱扔掉」的说法。买入时光贷款手续费就花了约房价 3% 的 12777 美元;首期月供 2329 美元里近 80% 是利息,本金占比不到 21%,与同地段一居室公寓租金相当。此后作者持续支出房产税(每月 515 美元)、保险(111 美元)、PMI、维修与改造(换屋顶 9390、换窗 10530、换外墙板 21046、换聚丁烯水管 5050 等)以及不断上涨的电费(两年涨 42%)。卖房时再付掉约 10% 房价的佣金与税费,他在西雅图 Auburn 那套房算上买卖成本反而亏于租房。结论是:租 vs 买并非显而易见,建议按 1%-3% 房价/年预留维修金,自己动手能省一半,决策应基于稳定性与生活方式而非「租房浪费钱」的口号。

评论精华

  • 租房同样有隐性成本,最大是不稳定:房东随时可涨租或终止合同。
  • 加拿大理财人 Ben Felix 的观点:长期看租买在财务上往往打平,应按生活方式决策。
  • 把首付和月供差额拿去投资,长期收益与买房接近,买房好处多是心理层面。
  • 1% 维修预留远不够,多数业主不存这笔钱,房子因此慢慢贬值。
  • 房贷强制储蓄是隐藏价值,理论上投资收益更高,但多数人没那个自律。
No.27 C64 Basic: Game Map Overhead “Camera View”
C64 BASIC 实现游戏地图的俯视「摄像机」视角
80 分 11 条评论 作者: ibobev
作者回应 Facebook 群友 Jay 的提问,演示如何在 Commodore 64 上用 BASIC 实现类似《Ultima》的俯视摄像机视角:玩家始终居中,地图在其周围滚动。核心思路是把「世界地图」与「视口」分离,每帧从大地图中切出以玩家为中心的 11×11 切片贴到屏幕。文章给出五个递进版本:第一版是未优化的朴素实现,慢得像幻灯片;第二版用预计算行偏移查找表 R(Y)=Y*40 替掉每帧 121 次浮点乘法,提速 3 到 5 倍;第三版把二维地图改成一维数组,加上 MR(Y)=Y*MW 行查表,循环里只剩加法;第四版加初始化进度提示避免看起来像死机;第五版把外层 FOR 循环手工展开为 11 行调用,并预烘焙 VR(J) 视口行基址,进一步消除 NEXT 开销。作者坦承即便优化到这一步,BASIC 仍偏慢,真正实战应改用 6502 汇编或 DATA 语句加载。

评论精华

  • amiga386 指出真正方案是用 D018 寄存器和硬件平滑滚动
  • bonzini 认为 FOR...TO...STEP 会更快,这种例程用 6502 汇编写极简单
  • bluescrn 回忆 BASIC 是入门好工具,但严肃游戏开发必须上汇编
  • dspillett 反驳称 BBC BASIC 加少量汇编也能做出真游戏
  • timbit42 举例《Sword of Fargoal》和《Pirates!》几乎全用未编译 BASIC 写成
No.28 Outsourcing plus local AI will soon become more economical vs. frontier labs
外包工程师加本地 AI 即将比前沿大模型更划算
263 分 285 条评论 作者: GodelNumbering
作者指出前沿实验室的推理价格不降反升:GPT-5.5 比 8 个月前的 GPT-5 涨价 3 倍多,Gemini 3.5 Flash 较前代涨价 3 倍,Anthropic Opus-4.7 换新分词器后 token 消耗增加 32%-47%。按「混合 token 消耗比」(每 100 万输入对应 5 万输出)计算,Anthropic 与 OpenAI 每百万 agentic token 约 2.8 美元,而 DeepSeek 仅 0.094 美元,价差约 30 倍。文章认为前沿模型虽更强,但在编码场景下,「够用」的开源模型加一名低成本国家的工程师组合,正逼近甚至超过纯前沿模型的性价比。配合 token 消耗持续上涨与 GPU 短缺,前沿实验室涨价存在天花板,否则企业现金消耗将不可持续。作者也承认假设较粗(未来价格、token 趋势、市场反身性),但强调本地模型进步迅速、推理硬件持续上线,长期方向利好「人 + 本地 AI」组合。

评论精华

  • 多位读者反驳:本地模型实测在 agentic 编码上仍明显落后 Claude Code 和 Codex,质量不在一个档次
  • 有人指出订阅价比 API 便宜 10-40 倍,90 美元 Claude 订阅约等于上千美元 API 额度,讨论裸 API 价没意义
  • 怀疑 DeepSeek 是在以低于成本补贴 token,这种低价并不可持续,不能作为开源经济性的证据
  • 外包类比争议大:对比 ChatGPT 像对接印度外包,需详尽设计文档才出活;且 1100 美元/月的工程师工资设定被批太低
  • 前沿模型本身才是开源追赶的训练数据来源,没有前沿就没有「够用」的开源,30 倍价差有其合理性
No.29 The Ballad of TIGIT
TIGIT 抗癌药的失败叙事曲
98 分 19 条评论 作者: crescit_eundo
文章讲述了肿瘤免疫疗法领域曾被寄予厚望的「TIGIT」靶点药物的集体溃败。继 Keytruda(K 药)凭借免疫检查点抑制机制创造制药神话后,业界把 TIGIT 视为「下一个 K 药」:理论上阻断它能同时松开两个免疫刹车并踩下一个油门,抗癌效果应当更猛。罗氏率先推出 tiragolumab,2020 年 ASCO 二期数据显示客户响应率 31% 对 16%,FDA 给予突破性疗法认定。罗氏随即押上重注,并行启动十二项二三期试验,覆盖约 5000 名患者,项目代号「SKYSCRAPER」,总投入达数十亿美元。默沙东、BMS、百济神州、Arcus、iTeos 等巨头也纷纷下注,授权交易动辄数亿美元。但从 2022 年 SKYSCRAPER-02 在小细胞肺癌上 PFS 失利开始,旗舰试验 SKYSCRAPER-01 也未达 PFS 终点;罗氏寄望的 OS 数据 2024 年 11 月最终读出依然失败。整个 TIGIT 药物类别因此被打上「带辐射」的标签,多年内无人敢碰。

评论精华

  • 有评论指出 TIGIT 失败的同时,另一癌症「白鲸」靶点 KRAS 的药物正在取得突破。
  • 有读者称赞文章可读性极佳,能让非药学背景的人理解药物研发的复杂逻辑。
  • 有人犀利点评 Aβ 药物之所以失败,是因为「淀粉样斑块致病假说」本身就建立在学术造假之上。
  • 讨论延伸到风投式跟风心态:错过下一个大机会比押错赌注代价更大,导致资本扎堆。
  • 有评论补充澄清:从一期到批准的成功率其实约 33%,并非常说的 90% 失败,需区分临床前阶段。
No.30 Opaque Types in Python
Python 中的不透明类型设计模式
116 分 53 条评论 作者: lumpa
作者 Glyph 介绍了一种在 Python 库设计中使用「不透明类型」(opaque types) 的模式,用于封装复杂且会持续演进的配置对象。以快递库的 ShippingOptions 为例:直接暴露 dataclass 会让构造函数成为公开 API,导致后期演进困难。解决方案是结合三个工具:用 typing.NewType 创建公开类型名(仅供类型注解),底层包装一个全私有属性的 _RealShipOpts 类(不暴露构造器),再提供 shipFast、shipNormal、shipSlow 等公开构造函数返回该 NewType。这样客户端无法直接访问内部字段,库作者保留了未来扩展属性、替换实现的全部自由度,运行时开销也接近于零。文章核心是借鉴 C 语言中 FILE、pthread_t 这类不透明句柄的思路,在 Python 类型系统里实现「公开名字、私有结构」的最小兼容面。

评论精华

  • 有人吐槽这是 Java 式繁琐,Python 信奉「我们都是成年人」,应直接用 ShippingOptions
  • masklinn 反驳:构造函数本身就是公开 API 的一部分,下划线约定挡不住滥用
  • 建议改用 Literal「fast」「slow」或 Enum 作为参数,把解码逻辑放到库内部更简洁
  • 有人指出私有类难写单元测试,需要 import 私有实体,建议调整暴露方式
  • 对作者用 camelCase 命名 Python 函数表示无法认真对待,引发风格争论