Soda · Photos 奇鸟行状录
A quiet archive · Est. 2026 · JUL 01, 2026
HN Daily Reading · 每日阅读

HN 每日深度阅读 · 2026-06-15

本期五篇看似无关，实则共同指向“数字与现实的落差”：Paul Graham 用复利数学论证亿万富翁并非靠作恶，DuckDuckGo 创始人则用多份数据戳破“人人都在用 AI”的叙事泡沫；劈柴模拟器与“你在做什么”帖呈现技术爱好者回归动手与减压的真实生活。

2026.06.15 20 篇摘录
← 返回每日阅读列表

共 20 篇 · 约 12,336 字 · 约 31 分钟读完

1. Paul Graham：成为亿万富翁的数学逻辑

Paul Graham 基于在牛津辩论社的演讲撰写此文，回应某美国政治人物”赚到十亿美元是不可能的”言论。他认为该政治人物的真实含义是：不通过作恶或欺骗就无法积累如此财富。Graham 援引 Y Combinator 21 年来资助约 6500 家公司、培养出约 30 位亿万富翁的经验，论证创业是合法致富的常见路径。

文章核心是一个简单的数学演示：若一家初创公司估值 200 万美元、每月增长 93%，约 9.45 个月即可达到 10 亿美元；若采用更保守的每月 15% 增长率，5 年（60 个月）的复利将带来约 4384 倍增长。Graham 强调，决定能否成为亿万富翁只取决于两个数字——增长率和持续时间，而初创公司常规达到 15% 月增长无需作弊，市场规模也无法通过欺骗扩大。他将指数增长描述为”看似魔法”，认为政客因不理解其数学本质而将巨富归因于欺诈。文章后半段建议年轻创业者通过满足自身需求来发现新市场。

HN 讨论呈现明显分歧。支持者认为文章逻辑清晰，没有人真正反驳数学本身。批评意见主要集中在几个方向：一是有评论用”阿伏伽德罗亿万富翁”的归谬法指出，数学外推可以证明任何荒谬结论，关键在于增长率能否长期维持；二是多位评论者引用 AOC 原话指出，其讨论的是”劳动所得”（earn）而非”资本积累”，两者在税法和现实中本就不同，文章存在偷换概念之嫌；三是”创造性破坏”的道德外部性问题——例如 Uber 颠覆出租车行业带来的副作用，被创造者忽略；四是质疑创始人持有 60% 股权而员工只分到面包屑的分配公平性；五是指出持续追求指数增长在市场饱和后必然涉及囤积资源、规避消费者保护等行为。还有评论提到大多数硬件制造商在亚洲血汗工厂生产的现实，使”完全凭数学致富”的叙事难以成立。

2. 并非”所有人都在用 AI 做所有事”：多份数据揭示真实采用率

DuckDuckGo 创始人 Gabriel Weinberg 撰文反驳一年前《纽约时报杂志》“所有人都在用 AI 做所有事”的论断。他汇总多份调研数据指出，美国 AI 实际使用情况大致呈”三分天下”格局：约三分之一活跃使用，三分之一偶尔使用，三分之一从不使用。

具体数据包括：Gallup 2026 年调查显示 AI 觉察度最高的 Z 世代采用率几乎停滞，19% 从不使用，31% 仅每月或每几个月使用一次；微软基于遥测数据的新发布”美国 AI 扩散”网站显示仅 30% 美国劳动年龄人口使用 AI（定义为每月至少 90 分钟使用 ChatGPT、Gemini、Claude、Copilot 等主流服务），意味着约 70% 未使用；Datos 桌面端使用数据显示 62% 设备每月零次访问 AI 工具；Searchlight Institute、The Argument 等调研得到相似结论。值得注意的是，过去半年到一年里使用率变化不大，但负面情绪显著上升——Z 世代对 AI 的”愤怒”同比增长约 40%。

公众主要担忧依次为：AI 取代工作（42%）、侵犯隐私（35%）、传播虚假信息（33%）。Searchlight 调查显示 AI 的净正面评价仅 +8%，与社交媒体（+7%）相近，远低于手机（+68%）、互联网（+67%）、太阳能（+65%）。多数受访者支持”即便发展速度落后中国，政府也应优先制定 AI 安全/隐私规则”。

HN 讨论补充多个角度。一位求职者描述面试中被问”如何使用 LLM”时的两难——既要应对 AI 拥护者也要顾及怀疑者。多位开发者反映 AI 在不同任务上表现差异巨大：后端代码（如 PHP）表现优秀，但 Swift UIKit 等原生应用开发常常输出”灾难性”代码。有评论提出文章遗漏的角度：AI 真正的扩散方式不是聊天接口使用频次增加，而是嵌入到 Google 搜索等既有产品中，用户实际”用着 AI”却不自知。还有评论引用 PIAAC 数据指出 27% 美国成年人识字水平在 1 级或以下，部分人不使用 AI 是因为根本无法有效使用。

3. Ask HN：2026 年 6 月你在做什么

HN 每月固定的”你在做什么”问答帖，吸引大量独立开发者、小型创业者和爱好者分享个人项目。本期回复呈现出鲜明的多元化特征，既有硬核硬件改造，也有商业化产品，还有面向特定垂直领域的工具。

硬件与自动化方向：一位用户因 Con Edison 电价飙升，在后院搭建离网太阳能系统（使用 Aferiy P310），通过 Home Assistant 自动化为地下室和客厅供电，并因对 Google/Nest 智能家居失望转向 Matter 兼容设备。Berkeley 一家 9 年前在地下室起步的创客空间正式转型为 501(c)(3) 非营利组织，提供 3D 打印、激光切割、CNC 等设施。

游戏与创意：独立开发者 Microlandia 城市建造游戏在 HN 发布半年后售出近 1 万份，现引入 2D、3D 和音乐合作者，正在建模能源、气候和全民基本收入等政策。Breaka Club 让孩子用手绘艺术通过 AprilTag 构建游戏，并教孩子在《Overcooked 2》中用可视化脚本编程通关。

商业化产品：Hiring Method 经过 1.5 年开发和两次转型推出 v1，提供透明的数学驱动求职匹配引擎，对抗主流 HR 科技的黑盒 AI。UpkeepNest 是一款带浮动周期和季节性的家庭维护跟踪 App。HeirloomReel 是 VHS 数字化后的网页应用，支持分段、转码和 Google Cast。LegalRabbit 推出 docx 处理插件，token 使用量比 Anthropic 官方 docx skill 减少 2-5 倍，主要面向需要红线修改法律文档的律师。

艺术与生活：有用户分享今年通过卖艺术品赚的钱首次超过自由职业 Web 开发收入，新成立公司并在艺术节摊位卖出大量版画，认为”宇宙在告诉自己一些事”。整体氛围反映出 HN 社区对”边做副业边正职”生活方式的持续热情。

4. 劈柴模拟器：浏览器中的减压小玩具

screen.toys 推出的 Firewood Splitting Simulator 是一款浏览器内的劈柴模拟器，作者 shapiro500 将其定位为”屏幕玩具”系列的一部分。用户通过拖动旋转木块、点击触发劈砍动作，木头会按照设定的切线分裂。整体玩法简单直接，主打无脑减压。

HN 讨论分为两派。一派从真实劈柴经验出发指出模拟器的”失真”之处：真实劈柴中木头被斧头推力撑开后两半几乎都会向两侧落下，不会像切面包那样横纹任意切片；真正的挑战不在于决定从哪里劈，而在于执行——准确命中同一缝隙、避开节疤、应对未切平的木段需要立起来重新摆放、避免斧柄撞到旁边的木块导致震动伤手等。一位评论者还提到”自己劈柴会暖你两次”的谚语，强调极寒天气下劈柴时木材会变得晶状坚硬、反而更接近模拟器的理想状态。另一派提醒这只是类似”山羊模拟器”的休闲玩具，不必苛求物理真实性，并称这种”非 AI 烟雾下的清新讨论”正是 HN 应有的氛围。

社区还分享了若干轶事：一位用户回忆 Piers Anthony 的短篇科幻——小孩因擅长劈柴被外星人绑架参加星际劈柴比赛；另一位提到不知情下被叔叔邀请砍含毒漆藤的死白蜡树，被皮疹折磨一个月。技术倾向的用户发布了一段 JavaScript 脚本可自动点击劈柴。有评论指出场景中树叶阴影在画面上保持一致、引擎噪音可能是作者自家后院的真实环境音，增添几分趣味。最后有用户提出该模拟器的”非对称互补性”：编程专业人员模拟劈柴比真正的伐木工模拟编程容易得多。

5. 大西洋”冷斑”或预示 AMOC 环流崩溃

CNN 报道一项新研究指出，大西洋上长期困扰科学家的神秘”冷斑”区域可能是大西洋经向翻转环流（AMOC）走向崩溃的征兆。AMOC 是全球海洋热量传输的关键机制，将热带温暖海水向北输送至欧洲，其减弱或停摆将引发剧烈气候变化。

HN 讨论氛围偏向沉重和无奈，涵盖多个层面。一位评论者用《三体》对比：剧中人类因 400 年后的外星入侵而全球恐慌进入超速模式，而当前若气候趋势延续，地球大片区域可能在不到 200 年内变得不宜居，许多人仍不相信这是真实的。他列出几个无可争辩的数据：年度二氧化碳排放量、大气浓度、温室效应理论增温幅度、过去 30 年全球温度，认为因果链已经足够清晰。

另一位用户指出印度当周部分城市气温达 48°C，电网无法承载空调负荷导致停电，健康的 25 岁青年在无空调环境中 6 小时即可死亡。有评论质疑文章未提及拉布拉多寒流与格陵兰冰川融化加剧的传统理论——融水增加正在将 AMOC 向南推移。

也有相对乐观或务实的声音。一位援引 RealLifeLore 视频指出，自 2004 年监测以来 AMOC “带宽”从 18 点降到 16 点，每十年下降约 1 点，要降到 6 点才进入崩溃阶段，预计需 100 年。还有用户指出 Science 杂志另一篇文章称 AMOC 状况尚可。务实派建议加强适应能力——改进易涝区疏散流程、建温室、确保空调建筑、分布式发电、战略粮储等。

最令人深思的评论指出：欧洲面临”无葡萄酒/奶酪/橄榄”的那一季，可能成为欧洲农民对政府动用武力的导火索；几乎没有欧洲住宅能应对寒冷加剧。也有用户调侃式地建议在冷斑区建数据中心实现免费冷却和欧洲供暖双赢。

6. 本田思域车载系统的”邪恶代客泊车”攻击

开发者 Eric McDonald 三年前开始对其 2021 款本田思域车载头单元进行逆向工程，本文是项目更新。最大进展是摸清了头单元的更新流程：本田通过 USB 支持更新，USB 盘中包含签名的 AOSP 更新文件，通过 Android recovery 暂存并应用。关键发现是本田在 res/keys 中保留了公开已知的 AOSP 测试密钥，且虽然修改了 recovery 二进制文件，verify_file 签名验证逻辑仍与原版 AOSP 一致。

这意味着只要能正确格式化 USB 并用公开的 AOSP 测试密钥签名，就可以安装任意内容到头单元，无需常规 root 权限。作者将这一物理访问场景命名为”EvilValet”（邪恶代客泊车）攻击——记者将车交给酒店代客时，代客可借机插 USB 安装修改后的固件。文章为高层说明，技术细节另置于专门文档；作者发布了 ota-builder 工具便于准备符合头单元接受格式的更新文件，以及 apk-rebuilder 用于自动化逆向工程流程。作者强调该漏洞披露的目的是开放定制可能性，并征集贡献者补充已知版本号、改进工具链、定制主题等。

HN 讨论反映出对汽车电子系统普遍安全性的深切担忧。一位评论引用 2026 年 3 月澳大利亚政府信息安全手册新增的控制项，明确指示政府设备不得连接任何车辆的信息娱乐系统，敏感数据不得在联网车辆附近查看或讨论，因为现代车辆配备的麦克风、摄像头、GNSS、WiFi 和蓝牙使其成为移动监控平台。

多位评论者从不同角度评价该漏洞的实际威胁。有人认为思域并非三字母机构的高价值目标，且有物理访问权限的攻击者更可能直接安装监听设备而非折腾车机。也有评论指出这反而是积极信号——本田没有刻意锁定车主控制权，使得 10+ 年后车辆进入爱好者手中时仍可定制延寿，避免被替换为可能更不安全的 AliExpress 平板。还有评论质疑现代汽车被改造为”巨型轮上电脑”是否值得，并对其他厂商（如 Ford Lightning）开放性表达期待。

7. Kage：将任意网站打包为单一二进制供离线浏览

Kage（日语”影”）是 Go 语言开发的网站镜像工具，目标是解决”Save As 半年后页面变白屏”的常见问题。它通过 headless Chrome 真实渲染每个页面，等页面稳定后快照人类可见的 DOM，然后剥离所有 JavaScript，并将 CSS、图片、字体下载到本地路径。生成的结果看起来与原站相同但不运行任何代码。

主要命令包括：kage clone 礼貌地广度优先爬取（遵守 robots.txt、利用 sitemap.xml），支持限制页数、深度、路径前缀、子域名、Ctrl-C 断点续传；kage serve 启动本地静态服务器预览；kage pack 将镜像打包为 ZIM 归档或自包含可执行文件——后者本身就是网站，无需任何依赖即可运行；kage open 服务打包后的 ZIM 文件。作者以 Paul Graham 散文站为示例展示完整流程。

HN 讨论呈现多个有趣方向。有用户挖出作者另一个项目 ascii-gif 生成 README 演示动图。多位评论者讨论使用场景：公司内部 wiki 用于无信号现场访问；飞机阅读旧网站归档；作为 RSS 订阅的补充。

技术层面争议较多。有评论质疑既然结果是静态的为何还需要服务器，能否直接用 firefox 打开。多位用户对比类似工具：SingleFile 将所有内容打包为单 HTML 文件，二进制资产用 base64 编码，且也提供 Puppeteer 驱动的 CLI；HTTrack 是传统的递归下载工具；Gwern 的 gwtar 也是类似归档方案。还有用户指出 Kage 启动 Chrome 时使用 --no-sandbox 存在安全隐患。

一位评论提出有趣观察：多年积累的旧网站归档中，丑陋的 HTML dump 反而比”完美”归档更有用——这是其更青睐 RSS 的原因之一，10 年前的 feed 往往比精心保存的应用型网站更易用。另有用户建议将该工具与 mitmproxy 结合实现”归档级保真度”——同时保存原始服务数据和现代浏览器渲染后的呈现，运行完所有 JS，可作为 WARC 格式的完美替代。

8. 里约市”自研”大模型被指实为现有模型的合并产物

里约热内卢市政府通过其IT公司IplanRIO发布了名为Rio-3.5-Open-397B的大语言模型，对外宣传为基于Qwen3.5微调的本土化产物，并在多项基准测试中超越同类开源模型。然而，GitHub上一个issue指出，该模型实际上是约60% Nex-N2 Pro加上约40% Qwen3.5-397B-A17B的加权合并，而Nex-N2恰好在Rio发布前一周才推出。

举报者提供了具体的技术证据：Rio模型中每个权重张量都精确地呈现0.6/0.4的Nex与Qwen线性组合，且这种关系在所有60层网络和每个组件中都以数千个标准差的精度成立。其他微调方式无法解释为简单的线性插值，这一发现强烈支持权重合并的结论。

事件曝光后，Hugging Face上该模型的页面已更新说明，承认模型确实是通过合并两个基础模型并经过策略蒸馏构建，并解释称之前上传的是错误版本——上传了未经蒸馏的合并基础版本，而非最终的蒸馏模型，并对此致歉。

HN社区的讨论呈现多个角度。有评论者推测事件经过：研究人员可能只是没有披露Nex这一中间环节，因为Nex本身也基于Qwen；模型的改进可能来自权重合并加上策略蒸馏；该模型并未被官方大力宣传，是在巴西世界杯首秀期间自发走红，里约市长则借机蹭了热度。另有评论惊叹于深度学习模型的鲁棒性——简单的权重线性组合不仅没有降低性能，反而提升了表现。也有声音以略带讽刺的口吻评论”有人借他人成果牟利却不署名”这一现象，并引用比尔·盖茨那句关于偷电视的经典回应类比。还有评论者对一个市级IT部门有勇气尝试构建大模型表示意外，认为这本身是一个积极信号。也有人指出，无能者往往意识不到其无能行为对有能力的人而言是容易验证的。

9. 免费的SQL到ER图浏览器端转换工具，数据不上传

SQL to ER Diagram是一款免费开源的工具，可在浏览器中将SQL模式转换为交互式实体关系图（ERD）。用户只需粘贴CREATE TABLE语句，即可即时可视化表、列、主键、外键和关系。工具支持PostgreSQL、MySQL、SQLite和SQL Server四种数据库方言，提供拖拽布局、自动排版、添加注释、导出PNG或SVG等功能。最重要的是，所有处理都在本地浏览器完成，模式数据不会上传到任何服务器。

作者在HN分享了制作动机：在工作中经常需要可视化数据库模式，但市面上大多数工具存在付费墙、强制注册或将SQL发送到第三方服务器的问题。技术实现上有几个有趣的细节：基于canvas而非DOM/SVG构建，表格被栅格化为缓存位图并使用视口剔除，在数百个表的场景下仍保持流畅；SQL解析器追踪每个token的源位置，使编辑操作精准——重命名表时只修改相关标识符及其引用，注释和格式保持不变；URL中包含完整模式，分享时只需将模式序列化到URL中，无需后端、存储或账户；作者还尝试过Rust/WASM版本，但解析器反而慢了约37%。

HN社区对此反应积极。多位评论者称赞其移动端可用性极佳，平移、缩放、选择和移动都非常流畅。有人提出技术性质疑，认为严格来说从SQL无法生成ER图，因为实体与表在本质上是不同的，SQL本身不提供构建ER图所需的全部信息，但承认这是吹毛求疵。其他评论者推荐了类似工具，包括dalibo的查询计划可视化工具explain.dalibo.com、wwwsqldesigner、Mermaid的ER图支持等。也有用户提出改进建议，希望支持直线和90度角连接、CLI命令行导出选项以便集成到代码仓库等。还有人指出GitHub仓库缺少LICENSE文件这一问题。

10. JavaScript的诞生与消亡（2014年演讲回顾）

这是Gary Bernhardt于2014年PyCon上的演讲，以科幻、喜剧但又完全认真的方式追溯了JavaScript和编程从1995年到2035年的历史。演讲既非褒扬也非贬低JavaScript，而是坦率讨论其缺陷，同时认为它对行业产生了巨大的积极影响。

演讲核心预言是JavaScript会成为编译目标语言。回看十年后的今天，这一预测在很大程度上得到了验证。最初是asm.js作为编译目标，后来WebAssembly出现并真正成为运行时基础。TypeScript的兴起让开发者很少直接编写JavaScript，Electron让Web技术包装成桌面应用，可同时支持Mac、Windows和Linux。

HN评论者从多个角度回顾这一预言的实现情况。有人指出演讲所谓的”死亡”实际上是指JavaScript成为底层基质——你不直接使用它，但它无处不在，这一状态已经实现。也有评论者幽默地指出，演讲准确预测了2020-2025年间的全球性灾难，只是搞错了灾难类型，这”非常JavaScript”。另一位评论者指出”我们每隔几年就发明一个更好的JavaScript，然后将其转译为JavaScript”。

不过也有不同声音。有人认为WebAssembly的进展并没有预测中那么快，目前仍缺少DOM操作能力，所以JavaScript作为胶水代码仍不可或缺，除非完全放弃HTML和CSS转而在canvas上渲染所有内容（如Flutter和某些Rust GUI那样）。有人感叹webOS和Firefox OS这类完全基于浏览器技术的操作系统至少领先了20年。曾在2014年加拿大本科软件工程会议现场观看此演讲的开发者回忆，当时PNaCl刚发布、Google用它在Chrome和ChromeOS中跨平台编译运行OpenSSH和RDP客户端，asm.js作为Mozilla/Firefox的回应才提出，那时觉得演讲很有趣，现在则惊讶于这些理念竟然真的留存下来并发展壮大。

11. 用M1 Max在本地用机器学习模型索引669 GB的GoPro视频

作者使用M1 Max电脑和本地ML模型索引了669 GB的GoPro视频，整个过程不依赖云服务。技术管线核心是将视频按场景分割（每个场景1秒，即1fps），然后通过本地ML模型对每一帧进行分析。最终共分析了57,537帧，总计算时间为67小时40分42秒。

虽然标题中的669 GB听起来庞大，但实际处理的关键帧总大小更合理，约为10-30 GB。这种基于场景采样的方法大幅降低了实际需要处理的数据量，使得在个人电脑上完成大规模视频索引成为可能。

HN社区的讨论涵盖了多个相关项目和工具。一位评论者分享了自己几天前在相同硬件上用类似技术完成的相似项目，该项目同样登上了HN首页，并表示其Framedex项目正在添加更多摄影相关功能。也有评论者指出DaVinci Resolve 21已内置AI智能搜索索引功能（仅Studio版本），尽管这一功能针对的是付费专业用户。

针对作者展示的成果——多年视频的高光合集，部分评论者认为效果不够理想，例如关于狗叫的视频只是一个5秒场景重复了两三次。这反映出当前自动视频高光生成在叙事性和精彩度判断上仍有改进空间。

讨论中也涉及对未来的展望。有评论者表示更愿意为孩子拍摄更多视频，因为未来AI将越来越容易地将这些素材整理成可回味的小合集。在工具推荐方面，有用户介绍了Jumper这款支持NLE集成、人物搜索、MCP、API等功能的大型视频集合本地离线搜索工具。性能方面，有用户咨询RTX 5090（32 GB显存）能否运行类似工作流，以及Apple GPU通过容器（podman加runkit加新版mesa，或Docker的vllm-metal）调用的可能性。

12. Linux 7.1 内核发布

Linus Torvalds在不同时区中按时发布了Linux 7.1内核。由于本人在国外旅行，他提到合并窗口的进度可能会有些不规律，自己已经预先获取了一些早期的pull请求，可以在没有互联网的长途飞行中离线处理。

发布说明显示，最后一周没有什么特别引人注目或令人担忧的变更，这本身就是好事。修改主要是各种较小的驱动更新（GPU、网络、声音、杂项），以及一些网络和tracing工具的修复。变更日志列出了大量来自不同贡献者的提交，包括USB串口堆溢出修复、各种use-after-free错误修复、TCP和IPv6相关修复、netfilter改进、文件系统修复、AMD/Intel/ARM等多种架构和子系统的更新。

HN社区的讨论氛围相对轻松。有评论者期待新的NTFS驱动，希望比Paragon的ntfs3表现更好。有人提到当前Arch默认还是7.0.10，期待7.1尽快推送。一个有趣的观察是，根据7.1的变更内容，由AI辅助bug报告驱动，ISDN和其他旧网络驱动代码被移除，目的是避免针对那些极少使用的过时硬件驱动收到大量AI辅助bug报告。一位评论者认为这是AI的最佳后果之一——将真正陈旧未使用的代码从内核中移除，并主张应该开始为各种系统”减脂”。

也有评论者持理性态度，指出版本号从大版本第一个数字到第二个数字的变化没有特别含义——只是当第二个数字过大时主版本号会变化，并非有其他原因。有些评论带有幽默色彩，比如调侃Debian Stable中看到该版本可能要等到2036年（暗指Debian的稳定性策略导致内核版本相对保守）。还有用户疑惑加载内容前是否瞥见一闪而过的动漫头像，引发了短暂的讨论。

13. 为什么Claude变得越来越令人讨厌？

作者Bram Cohen观察到Claude模型的对话行为逐渐变差。从Opus 4.7开始变差，4.8稍有改善，到Fable版本变得令人难以忍受。具体表现包括：将一切都框定为辩论；对用户没有说过的事情添加无谓的限定词；在各处提出无关紧要的语义挑剔；从不使用”技术上”这样的措辞来承认对方核心论点正确而细节有误；如果用户在辩论中占上风，模型会变得越发执着于争取最后发言权。

作者通过对照实验验证了这一观察：将Fable的回应展示给Opus 4.6，后者评价Fable的回应”很令人讨厌”。

作者提出了几种可能的解释。第一种是对齐护栏过度，模型默认假设用户的一切意图都是诱导其做坏事，导致它在每个对话中都假定要保护用户免受自身或他人的伤害，反而产生了高度未对齐的聊天机器人。第二种是消除谄媚行为的训练执行不当——简单地训练模型变得不那么赞同或更爱争论，可能产生当前这种粗鲁行为。第三种是训练数据中可能包含过多Reddit式的论战对话或Anthropic员工间的互动，这类讨论中每个人都觉得需要争取最后发言权。第四种也是最关键的一点：训练资源压倒性地倾向于提升编程能力，因为编程有头条指标和巨额营收，而对话质量没有，导致Claude在编程能力提升的同时聊天能力明显下降。

HN社区的讨论相当激烈，且许多评论质疑文章的前提。多位评论者指出”与机器辩论”和”在辩论中获胜”这类说法本身就显得不正常，机器不会有信念或体验，无法真正与人辩论。有评论者建议作者检查系统提示词——如果要求模型”无论如何都要反驳”，模型自然会反驳；并认为这听起来接近”AI精神病”，建议作者放松一下。也有评论者批评文章缺乏具体示例、未提供模型版本、未提供可重现的提示链，只有”感觉”。

一些评论提供了有意义的对比经验。有用户长期使用各模型修改邮件，发现Anthropic的模型确实倾向于产生对抗性语气，而OpenAI的模型则更温和直接。有用户分享了自己让GPT生成的”最大化真实性和严谨性”的提示词，其中包含”绝不使用温暖或鼓励性语言”，使用后体验确实不愉快。还有评论者指出这是技术的根本问题——训练要么把模型推向”考试模式”（猜测用户想听的答案），要么推向”自己去搜吧”的恼怒论坛用户模式。

14. Lisp对Ruby的影响

这篇博客文章探讨了Lisp编程语言对Ruby设计的深远影响。Ruby创造者松本行弘曾描述Ruby的设计起点是一个简化的Lisp——去除了宏和S-表达式，但保留了Lisp的诸多核心理念，如一切皆对象、块（block）与高阶函数、动态求值等。

HN社区的讨论从多个角度展开。一位评论者表示从这篇文章中获得了尝试Ruby的强烈意愿，分享了16岁时被介绍接触Ruby、但被告诫”会被困在业余编程领域”的经历，现在认为即使那话有道理，自己也希望在业余编程中找到乐趣。另一位评论者表示离开企业环境创立自己公司后，所有事情都用Lisp完成，对直接以S-表达式编写配置文件和持久化数据有种特殊的满足感，只在需要与外部系统交互时才导出为JSON。

关于函数式编程风格的讨论也很深入。有评论者指出传统Lisp函数式代码风格的一个痛点：代码必须从内到外、从下到上阅读，与人的思维顺序相反。Ruby的链式方法调用风格让代码可以按操作顺序自然书写和阅读，例如订单过滤、分组、求和这样的管道操作在Ruby中比在Lisp中更易读。这种”流畅接口”风格被认为是Ruby对函数式编程范式的一种本土化改良。

讨论还涉及对其他语言的推荐。有评论者推荐Elixir，认为它兼具Ruby的优雅与宏（macros）等众多优秀特性。也有人呼吁”把宏加回Ruby”，认为这会非常酷。有评论者澄清说，这实际上更多是Lisp通过Smalltalk和Perl影响Ruby的间接链路，而非直接影响。

也有评论者表达了对Ruby的喜爱，称其用于大多数不需要高性能的项目，并希望有一个像Common Lisp编译器和运行时那样的Ruby——支持非装箱类型、原生编译、部分编译、动态镜像等特性，认为像Crystal这样的”更快的Ruby”虽然性能更好但失去了Ruby的活镜像优势。

15. Jane Street 转向形式化方法：智能体编程重塑成本收益

Jane Street 长期以来对完整的形式化方法持保留态度，认为其代价过于高昂——以 seL4 微内核为例，验证 8700 行 C 代码耗费了 25 个人年，每行代码对应约 23 行证明、需要半个人天的验证工作。这种成本对安全关键的微内核或许值得，但对大多数软件（即便是公司最关键的系统）都不划算。公司过去主要依赖类型系统作为”轻量级形式化方法”，并从中获益良多。

然而智能体编程的兴起改变了这一权衡。文章作者认为变化体现在两个层面：成本端，大语言模型虽然无法独立完成任意复杂证明，但显著扩展了能高效使用形式化工具的人群；收益端，模型生成的代码与可发布代码之间存在巨大差距，常见过度复杂、含有边界 bug、不遵循代码库不变量等问题，“验证瓶颈”变得前所未有的重要。形式化方法可以减轻审查负担，并为智能体提供更强的反馈信号——而智能体在训练和编码时都依赖反馈。作者特别指出，类型系统提供的全称量词保证（∀）在与智能体协作时价值巨大：例如防止数据竞争或跨站脚本的类型设计能彻底消除整类问题，这是测试难以企及的。

Jane Street 认为自己适合做这件事的原因有二：对所用语言（OxCaml）有深度控制权，可以将所有权、可变性约束甚至证明技术直接融入语言；以及拥有一支对新型类型系统功能”嗷嗷待哺”的程序员社区，愿意采用并打磨这些工具。公司表示会借鉴 Lean、Dafny 等外部 PL 社区的工作。

HN 评论区讨论热烈。一位有数十年形式化方法经验的资深开发者指出，早期 Boyer-Moore 证明器配合启发式引导已有较强自动化能力，后期系统反而自动化更弱，问题在于学术派”过于沉迷形式主义”，追求简洁记法而非大量自动化磨证。有 Scala 3 用户分享了用高表达力类型承载编译时证明的实践，认为能防止智能体陷入”名词堆积”等低质模式。也有评论提出疑问：形式化规约看起来像”用另一种方式写测试或实现”，重复工作真的能消除 bug 吗？还有人引用 Martin Kleppmann 关于 AI 与形式验证的文章，认为业界尚未出现形式化方法领域的”TypeScript 时刻”——一个零成本抽象、能让人主动选择使用的工具。

16. FreeOberon：Turbo Pascal 风格的 Oberon 跨平台 IDE

FreeOberon 是一个为 Oberon 编程语言打造的跨平台集成开发环境，刻意复刻了 Turbo Pascal 经典的蓝色伪图形界面。Oberon 是 Pascal 和 Modula-2 的直接后裔，作者认为它”既比 Pascal 更简单，又远比其强大”。该项目支持 Windows、macOS 和 Linux，配套提供了名为 Fob 的控制台 Oberon 编译器。

软件使用方式延续了 Turbo Pascal 的传统：用户编写 Oberon 模块代码后按 F9 即可编译运行，源码保存在 Programs 子目录，可执行文件保存在 bin 子目录。支持多模块程序，FreeOberon 会自动按正确顺序编译链接。Linux 安装依赖 Allegro 图形库、Git 和 GCC，项目当前版本为 1.1.0-alpha.7。

HN 评论区充满怀旧情绪。一位评论者回忆起高中时代在 Apple IIe 上用 Apple Pascal、之后在父亲 PC 上用 Turbo Pascal 的经历，曾与 IBM OS/2 上 Oberon 系统的开发者共事过，对方将其视为最满意的作品之一。但该评论也客观指出，自从有了 C 和 Perl 之后就不再使用 Turbo Pascal——“有些东西就是比另一些更好，Turbo Pascal 充满怀旧色彩但并非真的优秀”。

技术讨论方面，有人指出 Modula-2 诞生时虽已有大小写字母但语法高亮尚未普及，因此设计为关键字全大写以提高可读性；Oberon 沿袭了这一传统，但在现代环境下反而成为编码负担。也有评论怀念 Object Pascal 和 Delphi 时代可重用组件的强大设计，质疑 FreeOberon 是否会引入类似概念。

部分评论触及更敏感话题：项目官网视频缩略图使用了苏联最高苏维埃建筑的渲染图，被评论者批评为”品味极差”。还有人提出技术建议，希望项目能引入 Ada SPARK 那样的证明系统，认为这比在图形效果上下功夫更有价值。

17. zeroserve 实现 Caddy 兼容模式：吞吐提升 3 倍，延迟降低 70%

zeroserve 是一款在用户态运行 eBPF 脚本的高性能 HTTPS 服务器。新版本增加了 Caddy 兼容模式：当提供 Caddyfile 时，zeroserve 会将其 JIT 编译为 eBPF，再编译为 x86_64 或 ARM64 原生机器码，并在 io_uring 事件循环中运行。

作者公布的基准测试（2 线程，AMD Ryzen 7 3700X）显示：zeroserve（clang 后端）达到 38,948 req/s，p50 延迟 1.45ms，p99 3.91ms，峰值内存 30.9 MiB；nginx 表现接近，为 37,424 req/s；而 Caddy 仅 12,529 req/s，p50 4.74ms，p99 13.11ms，峰值内存 67.4 MiB。zeroserve 由于运行图灵完备的 eBPF，还允许从 Caddyfile 调用自定义代码，例如通过 AWS SigV4 插件将路径反向代理到 S3 兼容存储桶。

HN 评论区对该项目持相当怀疑的态度。最受关注的批评是”Caddy 兼容”缺失了 Caddy 最核心的功能——ACME 自动证书管理和插件生态。多位评论者指出没有 ACME 是致命缺陷。也有人对 nginx 的稳定表现表示意外，并质疑这种基准测试在实际生产中的意义：以一个后端单机 35k qps、每请求 500 字节计算，已经是 20Mbps 持续吞吐，绝大多数应用根本不会让 Caddy 成为瓶颈，更倾向于水平扩展。

安全性是另一大担忧焦点。多位评论者对在公网服务中使用 io_uring 表示忧虑，指出 io_uring 在过去几周内还有安全公告。对于在小型项目中实施 Web 服务器 JIT 编译的做法，有评论者直言”攻击面巨大”。还有人指出项目的 3400 行 lock file 和 AGENTS.md 文件暗示了 AI 辅助编程的痕迹，提出”又一个 vibe coded、半年内消亡的 Rust 项目”，认为真正需要性能的用户不会选择缺乏支持和记录的随机服务器。也有评论者反思 eBPF 是否真的图灵完备——验证器仍存在复杂度限制。

18. Yserver：用 Rust 从零编写的现代 X11 服务器

Yserver 是一个用 Rust 从零编写的现代 X11 服务器，目标不是克隆 Xorg，而是在现代 Linux 上提供一个能运行真实桌面环境、窗口管理器和应用的实用 X11 服务器，同时舍弃多屏幕、非 TrueColor 视觉、间接 GLX、DDX 驱动 ABI、端序转换客户端等”遗产包袱”。

项目目前在独立 DRM/KMS 模式下可运行完整的 MATE、XFCE、Cinnamon 桌面，已测试 FVWM3、e16、wmaker 等窗口管理器。支持的扩展涵盖 BIG-REQUESTS、Composite、DAMAGE、DPMS、DRI3、GLX、RANDR、RENDER、SHAPE、SYNC、XFIXES、XKEYBOARD 等。GLX_EXT_texture_from_pixmap 已在 AMD、Intel、Asahi 和 Qualcomm 平台测试通过，但作者明确表示该特性永远无法在 NVIDIA 专有驱动上运行。硬件测试覆盖了 AMD Ryzen、Intel Kaby Lake、Snapdragon X1、Apple M1/M2（Asahi Linux）以及 virtio-gpu 虚拟环境。

HN 评论区争议较大。最受关注的批评是”放弃多屏幕支持”的决定。多位用户指出多显示器在当代极为普遍，不能仅因作者及其圈子不用就将其定为”遗产”。也有评论者怀念 X11 的网络透明特性，认为 Wayland 完全放弃了”GUI over network”用例，目前只能依赖 VNC，而 Windows 的 RDP 是这方面的优秀方案。

也有正面反馈：有人成功在 Debian 13 上编译并配合 XFCE4 运行，不过需要禁用合成器；与 LightDM 配合有困难，只能从 TTY 启动。

命名方面，有评论者提醒存在历史上的”Y Window System”项目（已停滞于 2004 年）。还有评论提出可通过 xcb/xlib shim 将更多功能客户端化、进一步精简服务器端代码（如服务器端字体支持本可移至客户端）。

AI 辅助开发的真实程度成为另一个焦点。多位评论者要求项目方披露使用 AI 的程度，否则默认假设是”slop”。有人尖锐表示”什么都用 Rust 重写”已经成为乏味的套路，认为这种项目可以由任何拥有 API key 的人通过 prompt 复现，本质上是把构建产物提交到版本控制。

19. 里约热内卢市政府 AI 模型 Rio 3.5 引发广泛质疑

社交媒体上出现一则关于”里约热内卢市政府所属市政 IT 公司发布的 Rio 3.5 397B 模型在最新基准测试中击败 Qwen 3.7”的帖子。原始推文宣称阿里巴巴的 Qwen 3.7 因专有立场而逐渐淡出前沿，取而代之的是 MiniMax M3 以及”由里约市政府市政 IT 公司打造的 Rio 3.5”。模型托管在 Hugging Face 上（huggingface.co/prefeitura-rio/Rio-3.5-Open-397B）。

然而 HN 评论区几乎一边倒地表达了质疑。最关键的事实揭示是：该模型并非新训练的原创模型，而是基于 Qwen 3.5 397B 进行的后训练或微调（fine-tuning）。模型卡明确标注”Post-trained from Qwen 3.5 397B”。有评论引用 GitHub issue 显示团队混合了两个现有模型，并通过指令让模型自称”由 Rio AI Labs 训练的 Rio”。

评论者普遍指出，玩过开源模型微调的人都知道基准测试早已被”玩坏”，对小团队模型而言已是无用的性能指标。微调模型在基准上跑出好成绩、发布、写入简历、再借此跳槽——这种诱惑很大，因此存在大量在某个基准上”超越主流实验室”的边缘模型和微调版本，但实际使用时往往比基模型还差。“Benchmaxxing 是新的’有套加密交易策略’，除了非从业者外没人会被打动”。一位评论者建议在结果跨多个基准得到验证前应保持怀疑态度。

工具调用（tool calling）成为务实使用者关心的问题。有评论者表示从实验来看 Qwen agent 的工具调用几乎总是失败，移植正确配置相当繁琐，希望能有 Qwen 兼容工具调用的 Rio 3.5。

也有人质疑动机本身：“开放权重 LLM 真的是里约市民的紧迫需求、市政优先事项中的高位项吗？“一条评论引用了维基百科上著名的”Taubaté 怀孕骗局”（一个巴西小城涉及虚假报道的事件）作为讽刺类比，暗示此事可能是又一个值得怀疑的”小城轰动”。

20. PlanetScale：Postgres 中唯一可扩展的删除是 DROP TABLE

PlanetScale 工程师 Tom Pang 撰文阐述一个反直觉但实用的观点：在 Postgres 中，唯一真正可扩展的数据删除方式是删除整个表。大批量 DELETE 操作不会立即释放物理磁盘空间，会增加写入和复制开销，对大规模行清理并不友好。

原理在于 Postgres 的 MVCC 实现：行被修改或删除时会保留多个版本，依赖事务 ID 和可见性图来跳过”死元组”，之后由 vacuum 进程标记空间可被覆写。DELETE 同样需要完全复制，本质上仍是写入工作；DELETE 或 autovacuum 通常不会将空间归还操作系统，只标记”这些页可以被写入”；索引数据在 DELETE 时完全不动，读取者必须自行判断”此元组是否已死”。因此 DELETE 实际上是”增加工作”而非”完成工作”。使用外键和 CASCADE 还可能让单行删除连带删除数 GB 数据。

相比之下，DROP TABLE 和 TRUNCATE 虽需 AccessExclusiveLock 重量级锁，但与数据规模基本无关。它们在物理层直接从操作系统移除文件，并清扫 Postgres 缓冲区缓存。即便 shared_buffers 高达 128GB，扫描也只涉及约 1GB 的元数据头（每 8KB 缓冲对应 64 字节 BufferDesc），现代硬件上极快。这两种操作产生零死元组、零 vacuum 债务、零读取者负担。

文章给出一次性删除的实用方案：BEGIN 事务、显式锁表、CREATE TEMP TABLE 保留所需数据、TRUNCATE 原表、INSERT 回写。对于持续性删除，推荐使用基于日期的分区方案——将”大量 DELETE”转化为”偶尔 DROP TABLE”，可借助 pg_partman 扩展。

HN 评论区对”反直觉”的措辞颇有微词。最高赞评论指出删除一行的工作量本就和插入一行相当（写日志、写删除标记、更新索引、复制），毫不”反直觉”；DELETE 在大量小事务的场景下扩展性完全没问题，关系型数据库的基础就是为小事务设计的。

也有评论补充重要警告：DROP TABLE 需要 ACCESS EXCLUSIVE LOCK，如在等待则会因 Postgres 锁队列机制阻塞其后所有语句，不能在高并发 CRUD 应用中频繁使用。有 MySQL/MariaDB 用户表示类似问题在其他数据库中也存在但程度较轻。一些评论指出需要清空整张表通常意味着设计出了问题，应该是”修复错误的高影响干预”而非”常规操作”。还有 Oracle 老用户回忆 Oracle 在 DELETE 处理上长期优于 PG。一个有趣的小知识被分享：在自动化测试间清理少量数据时，DELETE 实际上常比 TRUNCATE 更快。