要使用 Mastodon 网页应用程序，请启用 JavaScript。或者，尝试为您的平台使用 Mastodon 的原生应用程序。
每日HackerNews RSS
## LLM 与常识：洗车困境
最近在 Hacker News 上的讨论强调了大型语言模型 (LLM) 的一个有趣缺陷——回答一个看似简单的问题：走 50 米还是开车去洗车？许多模型，包括 OpenAI 的 GPT 5.2，最初建议*步行*，似乎假定汽车*已经在*洗车场。
然而，澄清提示词（“我的车在家……”）通常可以纠正答案。其他模型，如 Gemini 3、Claude Opus 和 Grok，通常一开始就能正确回答，认识到需要*开车*去洗车。
这场辩论表明，LLM 在“常识”推理方面存在困难，需要明确的上下文。一些人认为这源于缺乏“对现实世界的理解”，或者由于训练数据而倾向于谨慎、不明确的回答。另一些人则指出，模型依赖于模式识别而不是真正的思考，以及强化学习来自人类反馈 (RLHF) 可能会抑制强烈的观点。
最终，这次交流强调了仔细提示的重要性，并凸显了当前 LLM 的局限性，即使是最先进的 LLM，在面临需要基本情境感知能力的任务时也是如此。
## 使用AI代理构建SQLite：摘要 2026年2月，Kian Kyars成功地指示三个大型语言模型——Claude、Codex和Gemini——使用Rust构建一个类似SQLite的数据库引擎。该项目在大约三天和154次提交中完成了约19,000行代码，包括解析器、计划器、火山执行器、B+树、WAL、事务、索引和聚合等功能。重要的是，282个单元测试全部通过，验证了实现。 该过程模拟了分布式系统原理，强调通过Git、锁文件和严格测试进行协调。代理在一个循环中运行：声明任务、以SQLite作为预言机进行实现、更新共享文档并推送更改。协调开销（锁管理）占了超过一半的提交。 成功的关键在于预言机式验证、高测试频率和强大的模块边界，从而最大限度地减少了合并冲突。一个“合并器”代理（Gemini）旨在减少重复，但*在运行期间*未能有效利用。该实验强调了严格的任务边界、共享文档作为运行时组件以及测试作为利用并行AI代理时的重要反熵力量。该项目的仓库和脚本可公开获取以供复制。
罗伯特·沃尔克（Robert Wolke）的“美食101”专栏解释了铝箔的起源以及亮面和暗面的区别。最初被称为“锡箔”，因为19世纪时它是由锡制成的（灵感来自爱迪生的留声机），现在几乎完全由铝制成。
两种不同表面是制造过程的结果。铝在钢辊之间轧制；最后的工序使用两张面对面压制的薄片。外表面因与抛光辊接触而变得光滑，而内表面则相互挤压，形成哑光表面。
然而，沃尔克澄清说，**使用哪一面烹饪并不重要**——性能相同。有趣的是，铝是地球地壳中最丰富的金属，尽管人们普遍认为，锡箔帽并不能阻挡无线电信号！
## 黑客新闻讨论：亮面 vs. 哑面铝箔
一个黑客新闻的帖子引发了关于为什么铝箔一面是亮的，一面是哑面的讨论。最初的问题导致了一场出乎意料的详细辩论，延伸到该元素名称的历史——“aluminum”与“aluminium”，以及两者差异背后的语法原因。
用户指出，汉弗里·戴维最初将该元素命名为“aluminum”，但英国化学家后来采用了“aluminium”以符合拉丁命名惯例，但并非所有元素都始终如一地遵循这种惯例。讨论还涉及了铝箔在烹饪中的实用性，驳斥了亮面反射热更好的说法，并深入研究了辐射的物理学。
除了铝箔本身，对话也进入了幽默的领域，包括关于锡箔帽、公制系统，甚至三明治定义的笑话。一个关于铝箔作为心灵感应屏蔽效果的有趣研究链接也被分享了。
## Floe：一个可以回答关于自身问题的数据库 Floe 旨在成为一个“神奇”的数据库，轻松处理复杂的 SQL 查询。然而，认识到即使是最好的引擎也需要帮助，Floe 引入了一种独特的方法：使数据库本身可查询。 不同于依赖专门的 UX 工具或繁琐的日志，Floe 提供了一套全面的**系统视图（位于 `sys` 模式下）**。这些视图暴露了数据库内*所有内容*的可查询数据模型——表、函数、查询、会话，甚至内部统计信息。这允许用户使用 SQL 直接提出诸如“为什么我的查询速度慢？”或“哪些表增长最快？”之类的问题。 这种方法提供了强大的自动化和灵活性，让用户能够以熟悉的语言探索数据库，并回答 Floe 团队甚至未曾预料的问题。Floe 还支持通过 INFORMATION_SCHEMA 和 ADBC 进行传统的元数据访问，以及 PostgreSQL 线路协议，确保广泛的兼容性。 最终，Floe 的目标是成为一个透明且可诊断的数据库，赋予经验丰富的用户和新手以理解和优化其性能的工具。团队欢迎反馈，以便他们继续开发这个创新系统。
## FloeDB：数据库元数据的SQL
最近的Hacker News讨论集中在FloeDB上，这是一种新的数据库系统，强调“SQL无处不在”——具体来说，使用标准SQL查询数据库*元数据*。虽然像PostgreSQL这样的现有数据库已经通过系统目录（如`information_schema`）提供元数据访问，但FloeDB旨在将所有元数据（包括查询计划、统计信息和执行细节）视为一流的、可查询的数据。
核心思想是实现对数据库行为更深入的可观察性和分析。与提供聚合统计信息的传统系统不同，FloeDB会持久化详细的元数据，允许用户分析过去的查询，识别性能瓶颈，并了解数据使用模式。
提出的担忧包括详细元数据的潜在存储成本，以及收益是否能证明其复杂性。然而，开发者认为数据量是可以管理的，与Web服务器日志相当，并且提供了当前无法通过大量自定义工具获得的宝贵见解。FloeDB构建在Iceberg/Delta存储之上，并包含向量化执行和查询计划器等功能，使其定位为用于大规模分析的云原生数据库。
## 排版引擎基准测试：速度 vs. 控制
speedata Publisher (sp) 的开发者进行了一项基准测试，将其性能与 Typst、pdflatex、LuaLaTeX、WeasyPrint 和 Apache FOP 进行比较，任务是邮件合并——用数据填充信件模板以生成 PDF。
**测试结果：** 对于单页文档，sp 和 Typst 的速度相当（约 100 毫秒），明显快于其他引擎。 然而，对于 500 页文档，**Typst 显著优于所有其他引擎**，仅用时 157 毫秒——大约比 sp 快 28 倍。 这种速度得益于 Typst 更简单的断行算法。
**但速度并非一切。** 虽然 Typst 在快速处理方面表现出色，但 sp（和 pdflatex）使用 Knuth & Plass 算法实现更好的文本对齐，避免了 Typst 输出中存在的不均匀间距和断字问题。
**关键区别在于复杂布局。** 基准测试显示 sp 在 *自适应布局* 方面具有优势——自动调整内容以适应可用空间，这对于产品目录等任务至关重要。 Typst 在这方面遇到困难，需要手动计算并且缺乏内置的动态页面填充功能。 其他工具表现更差。
**结论：** 对于邮件合并等简单任务，**Typst 在速度方面是明显的赢家。** 然而，当布局需要智能内容调整和精确排版时，**sp 提供了其他引擎所不具备的功能**，即使这意味着牺牲一些处理速度。 该基准测试强调，“最佳”工具很大程度上取决于排版任务的复杂程度。
您可以在 [GitHub](链接未在文本中提供) 上找到完整的基准测试设置。
一篇最近的 Hacker News 帖子，作者名为“patrickg”，详细比较了六种排版系统的性能，结果显示 Typst 最快。然而，作者最终更喜欢 speedata Publisher 用于产品目录的创建，具体内容见链接文章 (speedata.de)。
随后引发讨论，质疑作者可能存在偏见，因为其与 speedata 的关联（作者澄清这在提交过程中并非有意为之）。另一位用户询问在性能测试中如何控制“设计意图”与算法优化——具体来说，系统是在默认设置下进行比较，还是经过调整以达到最佳性能。
Patrickg 回复说他*确实*使用了默认设置，承认每个系统都有可调整的参数会影响速度，并表示愿意根据系统作者提供的最佳设置重新测试。
跳过主内容 世界 商业 法律 市场 Breakingviews 更多 委内瑞拉石油的沉重现实 委内瑞拉的石油储量巨大，但并非所有原油都是一样的 作者：Kripa Jayaram、Mayank Munjal 和 Anurag Rao 发表于 2026 年 2 月 5 日 上午 6:00 EST 使用按键或点击继续 点击继续
启用 JavaScript 和 Cookie 以继续。
## 招聘信息有效期：Hacker News 讨论摘要
一个 Hacker News 讨论源于对招聘信息开放时间长短的疑问，揭示了一个出乎意料的多样化情况。一些公司会保留数年的招聘信息——有人提到一个持续 4 年以上的帖子，用于招聘 100 多人——而另一些公司则会快速关闭并重新发布信息，即使只是略微修改措辞。
讨论强调了人力资源文化的影响，一些公司使用“常青”招聘信息来招聘软件工程师等职位，而另一些公司则在僵化的职位描述中苦苦挣扎。分享的数据显示，行政/办公室职位的平均发布时间为 18 天，软件开发为 22 天，零售/酒店业为 33 天。
许多评论员指出，科技就业市场正在发生变化，注意到平均发布时间缩短，表明竞争加剧，并回归到“正常”的求职流程。另一些人认为，由于高技能人才稀缺，高级职位的招聘时间会更长，这可能由于人工智能对初级职位的影响而加剧。对话还涉及建立人脉和建立公开作品集，而不是仅仅依赖传统申请的重要性。
启用 JavaScript 和 Cookie 以继续。
在70年代和80年代热爱游戏的作者，在专注于电子游戏后，重新发现了桌面游戏的乐趣。最近的一次游戏之夜点燃了新的热情，促使他收集了超过30款游戏并参与了几个Kickstarter项目。 这不仅仅是怀旧；现代桌面游戏提供了一种独特而引人入胜的体验。高质量的组件——从厚实的纸板到雕塑的微缩模型——调动了我们的触觉，并创造了期待感。更重要的是，桌面游戏通过共同的规则和体验来培养真诚的社交联系，降低社交风险，同时提供情感回报。 作者强调了令人满意的“低风险成就循环”，失败是一个学习的机会，以及令人惊讶的游戏玩法多样性，可以刺激不同的认知技能。最终，重返桌面游戏提供了一种受欢迎的*存在感*——放慢速度，需要专注，并将娱乐转变为一种共享的人类体验。这是一种与触觉参与、社交互动以及共度时光的简单乐趣的重新连接。
## 棋盘游戏与社交联系
一篇 Hacker News 的讨论强调了棋盘游戏的吸引力，特别是对于那些寻求无屏幕社交和精神刺激的内向者。用户们表示，棋盘游戏在与他人互动和专注解决问题之间提供了一种平衡，这与持续的数字互动形成鲜明对比。
对话延伸到对价格实惠的游戏的推荐，例如《璀璨宝石》（Splendor）、《瘟疫危机》（Pandemic）、《车票之旅》（Ticket to Ride）、《卡卡颂》（Carcassonne）和《寿司走》（Sushi Go）。BoardGameGeek (BGG) 和 boardgameoracle.com 等资源被提及，用于研究和寻找优惠。
一个反复出现的主题是对游戏之夜被*新*游戏的规则解释所主导的沮丧，而不是简单地*玩*游戏并享受在一起的时光。一些人提倡选择具有深度的更简单的游戏，例如《年度游戏大奖》（Spiel des Jahres）获奖的游戏，或者专注于大家已经熟悉的游戏。最终，成功游戏之夜的关键在于了解团队的偏好，并优先考虑享受，而不是不断引入新的复杂性。 几位评论员也指出文章本身感觉是由人工智能生成的。
## 服务端优先的Web开发案例 本文认为，尽管行业趋势如此，严重依赖JavaScript（“JS-heavy”）的Web应用程序通常会带来较差的长期性能，并且需要大量的持续努力来维护。作者是一位Web性能专家，他结合在Automattic的经验，展示了这些方法——常见于单页应用程序（SPAs）——常常无法实现承诺的开发体验优势，并最终阻碍了用户体验。 JS-heavy应用容易因依赖项而膨胀，容易引入性能下降，并且由于框架特定的工具将问题隔离在标准浏览器开发者工具之外，因此难以调试。 维护性能需要持续的警惕，并且经常因代码变更和依赖项的演变而失败。 作者提倡回归更服务端优先的方法——优先考虑服务器端渲染并交付预构建的HTML——作为一种更可持续和高性能的解决方案。 虽然并非万能的解决方案，但服务器端方法提供了更大的控制力、可预测性和可扩展性，从而减轻了用户设备的负担。 最终，本文呼吁行业思维方式的转变，敦促开发人员优先考虑用户体验，并考虑JS-heavy框架的复杂性是否真的必要，或者更简单、以服务器为中心的架构是否更能服务于用户和开发人员。