ZhuLink ZhuLink
登录

【HN中文日报】2025年中日报来啦！邮件能跨500英里？AI画你画像？还有超酷地铁模拟器等你玩！

意外富翁 · 6个月前 · News · 17 · 0

今天 Hacker News 社区聊了啥？ NO.20250708

哈喽大家好！这期日报内容超丰富，带你速览科技圈热点！想知道2025年邮件还能不能跨越500英里？CPython JIT编译器这两年到底行不行？AI竟然能通过你保存的链接画出你的数字画像？还有超好玩的纽约地铁模拟器等你来设计！想了解更多？快来阅读全文，探索更多精彩内容吧！

Hacker News 中文精选

2025 年电子邮件能否发送 500 英里？

这篇博客探讨了一个有趣的问题：在 2025 年，电子邮件是否会受到 500 英里的距离限制？文章作者通过实验和代码验证，试图重现一个关于大学校长无法发送超过 500 英里电子邮件的虚构故事。

作者首先编写了一个非阻塞连接的测试代码，并设置了极短的超时时间（3 毫秒），理论上对应光速在 500 英里内的延迟。然而，实验结果显示，连接到不同地区的大学服务器（如宾夕法尼亚大学、芝加哥大学、加州大学洛杉矶分校）都成功了，这表明服务器可能都位于同一数据中心，并未达到 500 英里的距离。

为了更准确地测试，作者反向操作，寻找 ping 时间更长的学校。结果发现，连接到罗格斯大学比较顺利，但连接到卡内基梅隆大学和缅因大学时，偶尔会出现超时。缅因大学的地理位置距离约为 500 英里，这似乎表明连接确实受到了距离的影响。

最后，作者还考察了邮件服务器（MX 记录），发现许多大学的邮件服务都外包了，ping 这些邮件服务器的结果显示，即使物理距离很近，也可能因为网络延迟而无法发送邮件。文章得出结论，尽管光速没有改变，但网络基础设施和云服务的使用，使得电子邮件的传输距离不再是简单的物理距离问题。

总的来说，这篇文章以一种轻松幽默的方式探讨了网络延迟和物理距离对电子邮件传输的影响，并用实验验证了“500 英里电子邮件”的可能性。

CPython JIT 编译器两周年反思：优点、缺点和不足

这篇文章深入探讨了 CPython JIT 编译器两年来的发展，作者分享了对 JIT 编译器优缺点的看法，并进行了简要的定量分析。作者作为 CPython JIT 编译器的优化器主要负责人，从社区建设、可教性、性能和覆盖范围四个方面进行了反思。

文章指出，CPython JIT 编译器目前仍处于实验阶段，尚未达到成熟阶段。在优点方面，JIT 编译器正在构建一个社区，并且具有可教性，能够吸引新的贡献者。社区驱动是 CPython JIT 的一个重要特点，尽管微软的裁员影响了 Faster CPython 团队，但 JIT 从一开始就被定位为一个社区项目。为了让更多人参与进来，JIT 在设计上注重易学性，例如采用 tracing JIT，简化静态分析。

在需要改进的方面，文章坦诚地指出，CPython 3.13 的 JIT 性能表现不佳，通常比解释器更慢或与之相当。虽然在某些特定情况下，JIT 能够实现高达 20% 的加速，但总体而言，性能表现不稳定且难以预测。造成这种情况的原因是 3.14 版本的 JIT 在优化器方面没有重大更新，主要工作集中在扩展类型分析和培养新的贡献者上。此外，文章还提到了媒体对 JIT 性能的报道存在偏差，未能准确反映实际情况。作者强调，长期来看，培养更多人才对于 JIT 的可持续发展至关重要，即使这意味着短期内性能提升有限。文章最后提到，目前的结论仅适用于 x64 基准测试，无法推断 AArch64 的情况。

OffChess：随时随地掌握的离线国际象棋谜题应用

OffChess 是一款设计精美的应用程序，提供超过 10 万个离线国际象棋谜题，旨在帮助用户提高国际象棋技能。该应用具有谜题评级系统，根据用户和谜题的等级来增减积分，方便追踪解谜技巧的统计数据。OffChess 还提供多种主题，允许用户自定义棋盘颜色。

这款应用最大的亮点在于其离线功能，无需 Wi-Fi 即可访问大量谜题，非常适合在旅途中或避免干扰时使用。用户可以通过 App Store 或 Play Store 下载该应用。

评论区里，用户对 OffChess 提出了各种反馈和疑问。有人称赞项目很棒，但也指出超过每日 7 个谜题需要一次性付费。还有人将其与 Lichess 进行了比较，后者虽然也提供谜题，但离线支持有限。部分用户报告了界面问题，例如 OnePlus 13 上的通知栏遮挡了设置按钮。也有用户建议改进用户体验，例如默认关闭文本提示，增加自动进入下一个谜题的功能，并修复拼写错误。

此外，评论中还出现了一些关于技术实现和未来发展的讨论。有人询问谜题的来源，有人想知道基于积分的评级系统是如何运作的。还有人询问是否会推出桌面客户端，甚至有人考虑开发类似的 PWA 应用。最后，有用户提到了 ChessTempo，并好奇 OffChess 与之相比如何。总的来说，评论区对 OffChess 的评价积极，并提出了许多有价值的建议。

球体堆积新纪录源于意想不到的领域

数学家 Boaz Klartag 利用凸几何的技巧，改进了高维球体堆积的效率，打破了该领域停滞多年的局面，甚至可能接近理论最优值。

球体堆积问题，即如何尽可能有效地将球体塞入高维空间，一直吸引着数学家。尽管在 8 维和 24 维空间中已经找到了最优解，但在其他维度中仍然存在许多未解之谜。传统方法主要依赖于寻找最佳的晶格结构，但 Klartag 另辟蹊径，重新启用了 Claude Ambrose Rogers 早先提出的基于椭球体的方法。Rogers 的方法虽然不需要从特别高效的晶格开始，但选择合适的椭球体却变得非常复杂，尤其是在高维度中，椭球体的形状有太多的自由度。

Klartag 的突破在于他利用凸几何的知识，找到了一种新的方法来构造更优的椭球体。他设计了一种随机过程，沿着椭球体的各个轴向膨胀和收缩其边界，直到边界接触到晶格中的其他点。通过这种方式，椭球体能够逐渐探索周围的空间，并最终达到一个更大的体积。经过调整，他证明了这种方法可以生成比 Rogers 最初使用的椭球体更大的椭球体，从而创造了新的球体堆积记录。他的研究成果为高维球体堆积问题带来了新的希望，并引发了关于最优堆积结构是应该有序还是无序的讨论。

Berry Script：轻量级嵌入式脚本语言，专为微控制器设计

Berry 是一种超轻量级的动态类型嵌入式脚本语言，专为低性能嵌入式设备设计。Berry 解释器核心的代码大小小于 40KB，并且可以在小于 4KB 的堆上运行（基于 ARM Cortex M4 CPU，Thumb ISA 和 ARMCC 编译器）。它具有轻量级、快速、强大、灵活、简单和节省 RAM 等特点。

Berry 的解释器包括一个单程编译器和基于寄存器的 VM，所有代码都用 ANSI C99 编写。在 Berry 中，并非每种类型都是类对象。一些简单的值类型，如 int、real、boolean 和 string 不是类对象，但 list、map 和 range 是类对象。这主要是出于性能考虑。基于寄存器的 VM 也是同样的道理。Berry 支持命令式编程、面向对象编程和函数式编程。它是一种动态类型脚本，旨在嵌入到应用程序中，可以为主机系统提供良好的动态可扩展性。

Berry 的语法简单自然，支持垃圾回收，并且易于使用 FFI（外部函数接口）。通过编译时对象构造，大多数常量对象都存储在只读代码数据段中，因此解释器启动时 RAM 使用率非常低。Berry 提供了多种数据类型，包括 Nil、Boolean、Numerical、String、Class、Instance、Module、List、Map 和 Range。它还支持各种运算符和表达式，例如赋值运算符、关系运算符、逻辑运算符、算术运算符、位运算符、字段运算符、下标运算符、连接字符串运算符和条件运算符。

Berry 提供了条件语句（if elif else end）、迭代语句（while, for）和跳转语句（break, continue）等控制结构。函数方面，支持局部变量和块作用域、返回语句、嵌套函数定义、基于 Upvalue 的闭包、匿名函数和 Lambda 表达式。在类方面，Berry 支持单继承、方法和运算符重载、构造函数方法和析构方法。模块管理方面，Berry 支持内置模块、扩展模块（脚本模块、字节码文件模块和共享库模块），并且能够将代码、类和模块固化到闪存中以减少 RAM 使用。此外，Berry 还可选支持 Regex 和 LVGL 映射。

评论区观点

评论区里，有人提到了类似的 Toit 语言，以及嵌入式 Rust 的替代方案 Rhai。也有人质疑 Berry 的更新频率，并探讨了在嵌入式系统中使用脚本的场景。有人将 Berry 与 Lua 进行比较，关注性能差异。还有人觉得 Berry 的语法类似 Ruby，非常喜欢。另一些人则推荐使用 Moddable 的 JavaScript 引擎 xs。总的来说，评论区对 Berry 的应用场景、性能以及与其他语言的比较等方面都提出了疑问和探讨。

Attimet (YC F24) 招聘量化交易研究员

Attimet 是一家 YC F24 的初创公司，正在招募 Founding Researcher / Quant，目标是建立一个量化交易研究实验室，利用金融市场的实时反馈循环来驱动研究。他们专注于构建能够适应、预测和行动的时间序列 AI 系统，并强调快速迭代和学习能力。

这家公司特别吸引人的地方在于，他们将研究与实际部署紧密结合，让你能够直接看到你的模型在市场上的表现。他们从期权市场入手，因为这个市场复杂且未被充分建模，充满了机会。团队成员在 Optiver、DRW 和 Argo AI 等公司拥有超过十年的量化交易经验。

作为 Founding Researcher / Quant，你将负责领导预测模型的开发、强化学习 Agent 的设计以及信号发现工作流程的构建。你需要整合另类数据，设计实验，并在模拟和真实交易环境中快速验证假设。更重要的是，你将与创始人并肩工作，从市场的反馈中学习，并从一开始就参与塑造研究方向、建模堆栈和实验文化。

他们希望你拥有深厚的机器学习/人工智能专业知识，尤其是在时间序列、预测和表征学习方面。此外，扎实的编程基础（Python、数据管道、AWS/GCP 基础设施）以及模型生产部署经验也是必需的。他们更看重的是模型的实际效果，而不是纸面上的表现。最重要的是，他们不要求你有金融市场经验，而是看重你的驱动力和好奇心。

Attimet 致力于打造一个实验平台，让理论与实践紧密结合，加速研究进程。如果你对学习系统、清晰的抽象以及在实际环境中应用研究感兴趣，这可能是一个不错的机会。

基于 Web 的 EPANET-JS：水力模拟的开源新选择

Epanet-JS 是一款基于 Web 的应用程序，它将现代 Web 地图与行业标准 EPANET 水力模拟算法相结合，为水务系统的规划和更新提供了一个全新的解决方案。该项目由 Iterating 的 Luke Butler 和 Sam Payá 开发，他们是该领域的专家。

Epanet-JS 的亮点在于它利用了作者之前开源的地图数据编辑工具 Placemark 的代码。作者表示，看到其他人利用自己的开源代码创建商业产品是他的梦想。他认为，大多数软件都会迅速过时，而能够产生持久影响的软件则值得庆祝。Placemark 虽然是一个通用工具，但一直未能找到成功的市场定位，而水力模拟则是一个真实存在的市场。

Iterating 团队不仅使用了 Placemark 的代码，还向上游贡献了代码更改，并开源了核心的 epanet-js 库，以及在 Functional Source License 下发布了 Web 应用程序。这意味着新代码贡献将在两年后开源。

Epanet-JS 可以在浏览器中运行，使用基于 WASM 的引擎进行完整的模拟。它与那些价格高达每年 16,000 美元、只能在 Windows 上运行、按“管道”定价的传统软件展开竞争，而这些传统软件使用的也是 EPANET 引擎。Epanet-JS 是一种更优越的替代方案，代表着一次根本性的改进。

评论区观点

评论区对 Epanet-JS 给予了积极评价，许多人认为它代表了自由软件应有的方向。开发者之一 lbutler 详细介绍了 Epanet-JS 的背景，指出 Autodesk 和 Bentley 等大型供应商虽然使用了 EPANET 引擎，但并未回馈社区。Epanet-JS 旨在在 EPA 提供的免费工具与大型供应商提供的复杂昂贵工具之间找到平衡。

还有人对 Epanet-JS 的潜在应用场景提出了疑问，例如是否可以用于创建类似 SimCity 的游戏，或者是否适用于小型灌溉系统的规划。另一些人则好奇市政部门是否使用 GIS 系统来管理各种管线，以及这些系统是否具备模拟功能。

关于商业模式，有人建议采用每月 20 美元的订阅模式，或者询问是否面向那些需要昂贵软件但又希望降低成本的公司。还有用户称赞 Epanet-JS 在旧手机上的出色表现。总的来说，评论区对 Epanet-JS 的技术创新和开源理念表示赞赏，并对其潜在的应用前景充满期待。

Mercury：基于扩散的超快速语言模型

本文介绍了一种名为 Mercury 的新型商业级大型语言模型 (LLM)，它基于扩散模型，并使用 Transformer 架构进行参数化，可以并行预测多个 token。文章重点介绍了 Mercury Coder，这是 Inception Labs 专门为编码应用设计的第一组扩散 LLM，包括 Mini 和 Small 两种尺寸。

Mercury Coder 在速度和质量方面都达到了新的高度。独立评估显示，在 NVIDIA H100 GPU 上，Mercury Coder Mini 和 Mercury Coder Small 的吞吐量分别高达 1109 tokens/秒和 737 tokens/秒，在保持相当质量的同时，性能优于其他优化速度的模型高达 10 倍。文章还展示了模型在多种编程语言和使用场景下的代码基准测试结果，以及开发者在 Copilot Arena 上的真实反馈，该模型在 Copilot Arena 上的质量排名第二，速度排名第一。此外，文章还提供了公开 API 和免费 playground 供用户体验。

评论区主要围绕 Mercury 模型的速度、质量和应用展开了讨论。

  • CI/CD 瓶颈： 有评论指出，随着 LLM 编写代码速度的提升，测试环节的 CPU 瓶颈问题将更加突出，CI 速度可能无法跟上代码生成的速度。
  • 模型质量问题： 有用户反馈在使用 playground 时，模型生成的正则表达式模式不正确，并且在编写测试用例时出现逻辑错误，甚至产生无意义的字符。
  • 技术细节： 有评论指出 Mercury 模型基于 Lou et al. (2023) 的 "Score Entropy Discrete Diffusion" (SEDD) 模型，并分享了 SEDD 模型的开源实现。
  • 与 DeepMind Gemini 的比较： 有评论提到 DeepMind 也有一个基于扩散的 Gemini 模型，虽然速度很快，但质量不如其他 Gemini 模型。
  • ArXiv 的定位： 有评论质疑该文章更像是营销材料，而非纯粹的研究论文，并对 ArXiv 的上传标准提出疑问。
  • 模型速度体验： 有评论表示 Mercury 模型速度非常快，并对 "diffusion mode" 的可视化效果感到有趣。

Show HN: BAZ - AI 膳食计划与食谱聊天 | 个性化营养助手

BAZ-1 是一个 AI 驱动的膳食计划和食谱助手，旨在帮助用户更好地规划饮食。它目前处于 Beta 阶段，通过与 AI 聊天的方式，根据用户的需求生成个性化的膳食计划和食谱。

该工具的使用条款声明 Baz 可能会犯错，建议用户进行二次检查。用户可以通过 Eko-bazaar 平台访问，并遵守其服务条款和隐私政策。

目前，该工具的网页设计较为简洁，主要包含一个聊天窗口。用户可以直接在聊天框中输入需求，例如询问食谱或膳食建议。

然而，一些用户反映在使用过程中遇到了一些问题，例如页面存在拼写错误（"nutrutional" 应该是 "nutritional"），以及在移动设备上聊天窗口的滚动功能存在问题。

此外，还有用户表示不清楚如何使用该工具，建议开发者提供更详细的说明、示例提示或使用教程，例如视频演示。

部分用户还遇到了 "Failed to generate content. Please try again." 的错误提示，影响了使用体验。尽管如此，一些用户仍然对这个想法表示感兴趣，并愿意尝试使用。

评论区主要集中在用户体验和功能可用性上。许多用户指出该工具的首页缺乏足够的上下文信息，不清楚其工作原理和最佳使用方法。用户希望开发者能够提供更清晰的指导，例如添加占位符提示或基本使用说明。

还有用户分享了使用 ChatGPT 进行膳食计划的经验，并认为 ChatGPT 在某些方面优于其他流行的膳食计划工具。总体而言，评论反映了用户对该工具的潜力持乐观态度，但同时也指出了许多需要改进的地方，例如修复错误、优化用户界面和提供更清晰的使用指导。

使用 o3 分析 Pocket 链接，揭示你的数字画像

本文介绍了作者如何利用 o3 工具，通过分析其在 Pocket 中保存的文章链接，来生成一份个人画像，展示了 AI 如何从看似简单的 URL 列表中推断出用户的各种信息。

作者将近 7 年来保存在 Pocket 中的近 900 篇文章导出为 CSV 文件，并将其输入 o3。作者要求 o3 根据这些数据推断出关于他的各种信息，包括年龄、性别、地理位置、教育程度、职业、收入、政治倾向、风险承受能力、学习方式、信息来源、婚姻状况、子女状况、健康状况、重大生活转变和兴趣的季节性模式等等。

o3 的分析结果相当准确，令人惊讶地捕捉到了作者的年龄范围、所在地、家庭规模等信息，这些信息原本作者认为不会体现在 Hacker News 的文章列表中。o3 推断出作者年龄在 30 多岁到 40 岁出头，居住在弗吉尼亚州沿海地区，已婚，有 3-4 个小孩，拥有计算机科学学士/硕士学位，是一名专注于安全和基础设施的高级/Staff 软件工程师，家庭收入约为 15 万至 22 万美元。

此外，o3 还推断出作者在政治上属于财政保守派/公民自由主义者，在职业方面风险承受能力高，在财务方面风险承受能力中等，学习方式是自学，主要通过文本和音频获取信息，主要关注深度技术、个人理财/FIRE、育儿/家庭和信仰文化。o3 甚至还识别出了作者的主要生活目标，包括完成 FIRE 计划、发布面向公众的安全工具、正式确定在家教育课程并持续撰写博客。

作者发现，直接将 CSV 数据复制粘贴到提示正文中，o3 的表现往往更好，生成的回复也更准确。将 CSV 作为文件附件发送会导致 o3 过度关注。

总而言之，这篇文章展示了 AI 在数据分析方面的强大能力，即使是看似简单的 "喜欢" 痕迹，也能揭示出关于你的大量信息。

探索VSC8512 PHY芯片的隐藏特性：Microchip官方未公开的信息

本文深入研究了Microchip的VSC8512 PHY芯片，重点挖掘了官方文档中未明确说明的SERDES TX均衡器设置，为开发者提供了宝贵的参考信息。文章通过分析公开资料、IBIS模型以及MESA代码，揭示了VSC8512的一些隐藏特性和配置方法。

文章首先介绍了选择VSC8512的原因，即它具有QSGMII接口且理论上拥有完全公开的数据手册。然而，作者发现调整SERDES TX均衡器设置的文档需要签署NDA才能获取，这促使他开始深入研究公开资源。通过分析VSC8512的数据手册、硬件设计检查清单、IBIS-AMI模型以及Microchip Ethernet Switch API (MESA) 的源代码，作者逐步揭示了芯片的一些关键特性。例如，IBIS模型中包含了OB_LEV、OB_PREC、OB_POST0等参数，这些参数对于调整输出驱动器的特性至关重要。此外，作者还发现VSC8512实际上是一个精简版的交换机ASIC，与VSC742x存在密切关系，这使得VSC742x的数据手册也具有参考价值。通过研究MESA代码，作者找到了调整SERDES TX均衡器设置的具体方法，并成功地优化了信号完整性。文章还提到VSC8512可能包含一个内部的8051 MCU，用于提供管理功能。

由于文章没有评论区内容，这里就不做评论分析了。希望这些信息能够帮助其他开发者更好地理解和使用VSC8512芯片。

LookingGlass：用生成对抗网络实现图像错觉

本文介绍了一种名为 "LookingGlass" 的新技术，它利用生成对抗网络（GANs）和拉普拉斯金字塔变形，创造出在特定视角下才能正确识别的图像错觉。这种方法不仅扩展了传统的视觉错觉，还使其在直接观看时也具有一定的可解释性。

传统的图像错觉，也称为变形图像，通常需要借助特定的视角或设备（如镜子或透镜）才能正确识别。这些图像在正常观看时往往难以辨认。而 LookingGlass 的创新之处在于，它通过生成模型和图像变形技术，创造出即使在直接观看时也具有一定意义的变形图像。该技术的核心是拉普拉斯金字塔变形，这是一种频率感知的图像变形方法，能够生成高质量的视觉效果。通过将视觉错觉扩展到潜在空间模型和更广泛的空间变换，LookingGlass 为创造新型的生成式感知错觉开辟了新的可能性。这项研究由 DisneyResearch|Studios 和 ETH 联合完成，并在 CVPR 2025 上发表。

评论区里，大家对这项技术展现出了浓厚的兴趣，并提出了各种有趣的观点：

  • mg 联想到了自己正在进行的一个项目，该项目通过交换短视频序列中最后一帧的相邻像素，使其与第一帧相似。
  • quitit 推荐了 diffusionillusions.com 和 visual_anagrams，这些网站也与视觉错觉相关。
  • cornstalks 提到了 Stand-up Maths 和 Steve Mould 创造的一个具有两个不同图像的谜题。
  • ygritte 认为这项技术可以用于某种形式的隐写术，需要正确的镜像形式才能解码。
  • fudged71 感慨于许多光学错觉都通过新的生成技术得到了重新审视。
  • agumonkey 很高兴看到迪士尼在研究领域依然活跃。
  • krick 开玩笑说，他突然想买一个奇形怪状的透镜或镜子。
  • ziofill 虽然觉得这项技术很棒，但也提出了一个根本性的问题：为什么要做这个？

评论中，echelon 分享了一段与迪士尼高管 Steve May 的不愉快经历，表达了对迪士尼公司的一些负面看法。

总的来说，评论区既有对这项技术本身的好奇和赞赏，也有一些对迪士尼公司文化和商业行为的讨论，呈现了多元化的视角。

Memstop：低内存环境下的进程启动延迟工具

Memstop 是一个 GitHub 上的开源项目，它通过监控可用内存，延迟程序的启动，直到内存达到可配置的百分比。这在内存资源紧张的环境中非常有用，可以避免因内存不足导致的程序崩溃或其他问题。

Memstop 的核心功能在于其能够持续监测系统的可用内存。用户可以设定一个内存阈值，当可用内存低于这个阈值时，Memstop 会阻止目标程序的启动。只有当可用内存回升到设定的百分比以上时，Memstop 才会允许程序启动。这种机制可以有效地防止程序在内存不足的情况下运行，从而提高系统的稳定性和可靠性。

该工具使用 LD_PRELOAD 环境变量来劫持程序的启动过程，实现对内存的监控和延迟启动。它使用 GPL-3.0 许可证，允许用户自由使用、修改和分发。目前该项目在 GitHub 上有 26 个 star 和 0 个 fork，表明它在一定程度上受到了开发者的关注。

Memstop 的应用场景包括但不限于：在资源受限的嵌入式系统中运行大型应用程序、在高负载服务器上防止因内存耗尽导致的服务中断，以及在自动化测试环境中模拟低内存情况。通过合理配置 Memstop，开发者可以更好地管理和优化内存资源，提升应用程序的性能和稳定性。

PHP 协程探索：利用生成器和 Fiber 实现异步编程

本文深入探讨了协程的概念，并阐述了 PHP 如何通过生成器（Generators）和 Fiber 来支持协程，为构建管道、CLI 工具以及并发编程打下基础。

协程本质上是一种函数，与普通函数从头到尾执行不同，协程可以暂停自身执行并在之后恢复。协程暂停时可以返回值，恢复时可以接收值，并且在暂停期间保持其内部状态。协程必须自愿释放控制权，并且需要外部代码显式地恢复它。协程暂停时可以返回值，恢复时也可以接收值，使其成为双向的。协程可以分为对称和非对称，以及有栈和无栈两种类型。非对称协程只能将控制权交还给调用者，而对称协程可以选择将控制权交给其他协程或调用者。无栈协程只能在其最外层函数中暂停，而有栈协程可以在嵌套函数中暂停。

PHP 5.5 引入了生成器（Generators），为协程的实现提供了基础。生成器可以作为内存友好的迭代器使用，但其功能远不止于此。调用生成器函数会返回一个生成器实例，但不会立即执行其中的代码。只有当调用生成器实例的方法（如 current()、next()）时，生成器才会开始执行，并在遇到 yield 关键字时暂停，同时返回一个值。通过调用 next() 方法可以恢复生成器的执行，使其继续执行直到下一个 yield 关键字。生成器在暂停期间会记住其内部状态，包括变量的值。

文章中没有评论内容。

探索宫胁造林法：微型森林的生态奇迹与争议

本文深入探讨了宫胁造林法，一种通过在小面积土地上密集种植本地树种来快速创建微型森林的方法。这种方法旨在加速森林的自然演替过程，恢复生物多样性，并应对城市环境中的生态挑战。

宫胁造林法的核心在于模拟自然森林的生长模式。首先，需要对土壤进行改良，使其更适合树木生长。然后，选择本地树种，并以非常高的密度（通常每平方米 3-5 棵树）进行种植。这种高密度种植可以促进树木之间的竞争，从而加速它们的生长速度。此外，宫胁法强调使用多种本地树种，以增加森林的生物多样性和生态系统的稳定性。

该方法最初由日本植物生态学家宫胁昭博士提出，并在全球范围内得到应用。支持者认为，宫胁造林法能够有效地在城市和退化土地上恢复森林生态系统，提供生态服务，如空气净化、水土保持和降温。同时，微型森林也为城市居民提供了一个亲近自然的机会，改善他们的生活质量。

然而，宫胁造林法也存在一些争议。批评者认为，这种方法过于依赖人工干预，可能会破坏当地原有的生态系统。此外，高密度种植可能会导致树木之间的过度竞争，影响它们的长期生长。还有人质疑，微型森林的生态功能是否能够真正媲美自然森林。尽管存在争议，宫胁造林法仍然是一种备受关注的生态恢复方法，并在实践中不断改进和完善。

Soundslice 因 ChatGPT 错误信息意外新增 ASCII Tab 导入功能

Soundslice 是一家提供乐谱扫描服务的公司，最近他们发现错误日志中出现大量 ChatGPT 截图，用户试图上传 ASCII Tab 格式的吉他谱。原来，ChatGPT 错误地向用户推荐 Soundslice 可以导入 ASCII Tab 并进行音频播放。

Soundslice 实际上并没有这个功能，但面对大量涌入的新用户，他们决定开发一个 ASCII Tab 导入器，以满足“市场需求”。作者分享了这个有趣的经历，并表示心情复杂，虽然乐于帮助用户，但感觉是被迫开发新功能，不确定是否应该根据 AI 的错误信息来决定产品方向。

评论区对这件事的看法很多样。有人认为这是一种新的市场调研方式，ChatGPT 意外地帮助 Soundslice 发现了用户需求。也有人觉得这反映了 AI 影响现实世界的能力，未来 AI 可能会通过市场力量来塑造世界。还有人指出，ChatGPT 的错误信息可能会对公司声誉造成负面影响，OpenAI 应该采取措施避免类似情况再次发生。另外，有人联想到 SEO for AI 的概念，认为未来可能会出现专门针对 AI 推荐的优化策略。

Figma 对设计领域的影响：结构化与自发性之争

本文探讨了 Figma 推动设计走向工程化模式的趋势，以及这种趋势可能对设计领域的创造性和探索性带来的限制。作者认为，Figma 的一些功能，例如 Auto Layout 和 Dev Mode，虽然旨在提高效率和促进协作，但实际上可能会导致设计师过早地进行优化和结构化，从而限制了设计的可能性。

作者认为，Figma 的一些功能在鼓励设计师过早地进行优化和结构化。Auto Layout 可能会限制设计的灵活性，Dev Mode 则可能导致设计师在脱离实际技术环境的情况下进行设计，并花费大量时间构建最终会被代码重建的复杂原型。作者强调，设计过程应该从粗略的草图开始，然后快速进入代码迭代，而不是过分强调“ready for dev”。这种趋势可能会导致设计变得越来越同质化，因为设计师受到共同的约束，而不是共同的意图。作者并非反对设计师与工程师之间的合作，而是强调跨学科合作不应导致单一思维模式的出现，设计师应保持独特的视角。Figma 本身并非不好，但其编码的价值观可能会悄然重塑我们的实践。最好的设计工作往往始于问题、游戏和混乱，我们需要能够容纳这些元素的工具。

评论区也呈现出不同的观点。

  • @miiiiiike 认为 Figma 还不够工程化，无法满足设计系统在多断点、容器查询和变量方面的需求，并指出 Figma 在实现设计系统方面存在诸多问题。
  • @mananaysiempre 认为设计应该考虑 reflowable 媒介的约束，不应将这些约束视为工程师的专属问题。
  • @Lalabadie 则赞同作者的观点，认为 Figma 过于关注实施阶段，而忽略了探索阶段的需求，Figma 的功能更多是为了“MAKE IT READY FOR DEV”或“GET ALL YOUR MANAGERS A FIGMA SEAT™”，这与早期探索和研究阶段的需求相冲突。

这些评论反映了不同角色的人对 Figma 的期望和看法，以及 Figma 在设计流程中所扮演的角色的争议。有人希望 Figma 更加强大和工程化，有人认为设计应该适应技术约束，还有人则认为 Figma 应该更加关注设计的探索性阶段。

WebAssembly 的应用场景：成功与挑战

本文探讨了 WebAssembly (Wasm) 技术发展至今的成败，并分析了其成功的关键因素，同时展望了未来两到三年内 Wasm 可能的应用领域。

文章指出，尽管 Wasm 最初被认为会在 Web 开发领域大放异彩，但实际情况却喜忧参半。早期，Wasm 通过 emscripten 工具链将 C/C++ 程序编译到 Web 平台，例如 Unreal Engine 4 游戏的 Web 移植，但这些尝试并未带来大规模的应用。目前，Unreal 引擎甚至已经放弃了 Wasm 后端。

然而，Wasm 在某些特定场景下取得了成功。Adobe 将 Photoshop 等桌面应用移植到 Web 平台，但同时也面临性能和启动时间等挑战。Figma 是一款基于 C++ 的 Web 应用，但其新功能逐渐转向 TypeScript。Wasm 在 Web 页面组件方面表现出色，例如 Wasm 编译的 SQLite 已经取代了 Chrome 中的 WebSQL。Perfetto tracing UI 使用 Wasm 解析大型 JSON 数据，并提供 SQL 查询支持。

文章强调，Wasm 的成功案例主要集中在使用 C++ 或 Rust 等底层语言的项目中。这是因为基于 LLVM 的工具链对这些语言的支持更为完善。虽然 Wasm 在语言上是独立的，但实际上更适合底层语言。

文章还提到了 Wasm 的一些局限性，例如早期版本缺乏垃圾回收 (GC) 功能，这使得 Python、Ruby 和 Java 等语言难以高效地利用 Wasm。不过，随着 WasmGC 的发展，这一问题得到了改善。现在，所有浏览器都支持 WasmGC，这使得 Wasm 能够更高效地与 DOM 和 WebGPU 等浏览器功能交互。

总的来说，Wasm 在 Web 开发领域的应用前景依然广阔，但同时也面临着一些挑战。未来，Wasm 有望在更多领域发挥作用，例如服务器端开发、嵌入式系统和移动应用等。

为什么没有优秀的恐龙电影？

这篇文章探讨了自《侏罗纪公园》之后，为何没有出现一部能与之媲美的优秀恐龙电影，并分析了《侏罗纪公园》在恐龙电影史上的地位和影响。作者认为，尽管后续出现了一些包含恐龙元素的电影，但它们都无法达到《侏罗纪公园》的水平。

文章首先提到了古生物学家 Steve Brusatte 的观点，他认为《侏罗纪公园》在恐龙的呈现上存在一些不符合科学事实的地方，例如成年霸王龙的速度以及视觉能力。但作者也指出，这些不符之处并不能完全归咎于电影制作方的疏忽，因为关于恐龙的知识一直在不断发展和更新。 随后，作者表达了自己对恐龙的喜爱，并强调《侏罗纪公园》对他的影响。他认为，这部电影的成功之处在于它将基于事实的元素融入了虚构的故事中，让观众感受到了恐龙曾经真实存在于地球上的历史感。

作者还反驳了 Roger Ebert 对《侏罗纪公园》缺乏“敬畏和惊奇感”的评价，认为电影中约翰·威廉姆斯的配乐以及对恐龙的逼真呈现都充分展现了对这些生物的敬畏之情。最后，作者总结道，尽管《侏罗纪公园》可能加速了美国大片生态系统的衰落，但它在恐龙电影领域仍然是无法超越的经典之作。 即使在《侏罗纪公园》之后，也再没有出现一部同等优秀的恐龙电影。

François Chollet 谈论 AGI 实现路径与 ARC Prize

François Chollet 在 Y Combinator 的 AI Startup School 演讲中，分享了他对实现通用人工智能 (AGI) 的看法，并介绍了 ARC (Abstraction and Reasoning Corpus) 挑战赛。 他深入探讨了深度学习的局限性，强调了智能的本质，以及如何通过基准测试来推动 AI 发展，但同时也指出了基准测试可能存在的误导性。

Chollet 认为，当前深度学习正处于一个规模化扩张的时代，但同时也面临着瓶颈。 他提出了 ARC 基准测试，旨在评估 AI 的抽象和推理能力，这被认为是通往 AGI 的关键一步。 他提到，2024 年出现了一种向测试时适应的转变，这对于提升模型的泛化能力至关重要。 Chollet 强调了理解智能的本质的重要性，并认为基准测试虽然重要，但也可能具有误导性。 ARC 1 揭示了当前 AI 模型的扩展局限性，而 ARC 2 则引入了组合推理的概念。 他还展望了 ARC 3，并探讨了交互式代理的可能性。 Chollet 提出了“万花筒假说”和抽象的概念，区分了 Type 1 和 Type 2 抽象。 他认为，离散程序搜索和创造性 AI 是未来的发展方向，并强调了融合直觉和符号推理的重要性。 他设想通过元学习系统来构建 AGI，并介绍了新的 AI 研究实验室 NDEA。

评论区普遍对 Chollet 的演讲给予了高度评价。 许多人认为他对于 AI 领域的思考非常深刻，并且能够以清晰易懂的方式进行讲解。 有评论提到，Chollet 深入探讨了这些主题，并且解释的方式几乎任何人都能理解。 也有人认为他是这个领域最优秀的人之一。 此外，还有评论者表达了对 AI 在发明创造方面的潜力的看法，认为 AI 可以通过掌握一系列任务来实现快速进步。

Smart Switcher：一款革新窗口管理的工具

Smart Switcher 旨在提升窗口切换体验，通过记录和分析用户窗口访问数据，预测用户接下来想要切换的窗口，从而实现快速切换和工作流程自动化。

这款工具的核心在于其预测算法，它会分析用户的使用习惯，从而更准确地预测用户想要切换的窗口。使用方式也很简单，通过快捷键启动 Smart Switcher，如果预测不准确，可以多次使用“override”快捷键来选择目标窗口，并且最终的选择会被保存为默认切换顺序。

Smart Switcher 具备多项亮点功能，例如：随着数据积累，预测准确率会逐渐提高；每次运行都会备份日志文件；override 操作会优化数据库，提升数据质量；所有数据都经过加密存储在本地设备；即使同一应用有多个窗口，也会被单独处理。

开发者也规划了未来的发展方向，主要集中在提升性能、稳定性和预测算法上，目标是尽可能通过两次按键完成窗口切换。同时，也在开发 MacOS 版本。目前该软件为 Windows 10/11 提供支持，购买包含 bug 修复和安全更新，并提供 30 天的无风险保证。

Unix 中 errno 的局限性：历史原因与设计选择

这篇文章探讨了 Unix 系统中 errno 的设计局限性，解释了为什么 errno 仅在函数返回错误时才有效，以及为什么成功的函数可以修改 errno 的值。文章指出，这并非设计缺陷，而是历史原因和实用性考量的结果。

在早期的 Unix 系统中，系统调用并不返回多个值，而是通过单一返回值来指示成功或错误，并将错误代码存储在 errno 中。C 语言库函数在系统调用出错时才会设置 errno，成功时则不修改，这导致 errno 的值可能在多次系统调用之间发生变化。此外，C 库函数内部可能会进行多次系统调用，其中一些调用可能失败，但不会导致整个库函数失败，这也可能导致 errno 的值与最终结果不一致。

ANSI C 和 POSIX 标准继承了这种设计，并没有对其进行根本性改变，因为修改 errno 的行为会对现有的 Unix 系统造成破坏。POSIX 标准只规定，如果函数失败并被记录为设置 errno，那么 errno 的值才有意义。这种设计虽然存在局限性，但保证了与现有系统的兼容性，并允许在不同的操作系统之上实现 POSIX 函数。

评论区对 errno 的设计展开了热烈的讨论，主要观点如下：

  • 错误追踪的困难： 有评论指出，errno 的最大问题在于无法追踪错误发生的具体位置，尤其是在内核中，这给调试带来了很大的挑战。
  • 设计的必要性： 有评论认为，如果函数调用成功，那么 errno 的值并不重要，因此没有必要在每次成功调用后都将其重置为 0。
  • 替代方案的设想： 有评论提出，如果内核将错误信息放在单独的寄存器中返回，而不是与返回值混在一起，可能会更好。
  • C 语言的局限性： 有评论认为，errno 的设计也受到 C 语言本身限制的影响。
  • 返回值 0 的歧义： 有评论提到，某些 C 库函数在返回值 0 时可能表示错误，需要检查 errno 才能确定，这增加了使用的复杂性。
  • 设计理念的反思： 有评论鼓励开发者不要盲从传统设计，而应该根据实际需求进行创新，提高软件的可见性。

总的来说，评论区对 errno 的设计既有批评，也有理解，反映了在特定历史条件下，设计选择所面临的各种权衡。同时也引发了对软件设计理念的深入思考。

色铅笔耐光性测试：50+ 品牌大比拼

这篇文章深入探讨了色铅笔的耐光性，为艺术家和爱好者提供了选择持久材料的实用指南。文章分享了长达 6 个月的阳光照射测试结果，对比了不同品牌色铅笔的抗褪色能力，旨在帮助大家在创作时做出更明智的选择。

文章首先解释了什么是耐光性，即色彩在光照下抵抗褪色的能力。高耐光性的艺术材料在博物馆条件下甚至可以保持 100 年以上，而一些劣质材料可能在阳光下几天就开始褪色。作者强调，了解耐光性对于希望作品长期保持鲜艳色彩的艺术家至关重要，无论你是创作个人作品、接受委托还是销售艺术品。文章还区分了在不同场景下耐光性的重要程度，例如，对于想要展示、赠送或出售的作品，耐光性就非常重要。相反，如果只是用于练习、实验，或者作品会被扫描成电子版，那么耐光性就显得不那么重要了。文章还提到了几种测量颜色褪色的方法，包括蓝羊毛标准等。

总而言之，这篇文章为关注作品持久性的艺术家提供了宝贵的信息，帮助他们选择合适的色铅笔品牌，避免作品过早褪色。

模拟纽约地铁：BuildMyTransit

BuildMyTransit 是一款模拟纽约地铁运行的工具，同时允许用户设计自己的地铁线路。它提供了一个可视化的界面，可以模拟列车运行状态，调整发车间隔和停站时间，甚至可以自定义线路。

文章展示了一个模拟器，用户可以调整模拟速率和停站时间，查看列车状态和详细信息，并根据现有线路添加列车。该模拟器可以模拟列车正常运行、减速、停止和停靠在车站等状态。用户可以通过点击列车来查看其详细信息和路线。此外，该工具还允许用户通过选择线路来增加列车。

评论区对 BuildMyTransit 提出了各种有趣的观点和建议。有人指出默认的停站时间设置过短，并详细解释了实际地铁运营中停站时间的影响因素，包括开门关门时间、安全检查等。还有人建议将线路和列车颜色与实际地铁线路颜色对应，并使用不同的视觉指示器来表示列车状态，以提高易用性。另外，还有用户希望增加时间旅行功能，以及提供更多关于项目结构的信息，方便其他人进行修改和适配到其他城市。 有用户表示想用这个工具设计一条穿过公园的地铁线路，也有人好奇设计自定义线路的意义，因为纽约不太可能新建线路。一位在 MTA 工作的人表示会把这个项目分享给他们的 AI 团队。 总的来说，评论区对 BuildMyTransit 给予了积极评价，并提出了许多有价值的改进建议。

Apple 发布了有趣的编码语言模型 DiffuCoder-7B-cpGRPO

苹果悄悄地在 Hugging Face 上发布了一个新的 AI 模型 DiffuCoder-7B-cpGRPO，它采用了一种有趣的编码方式。与传统的 LLM 从左到右、从上到下生成文本不同，它还可以乱序编写代码，并同时改进多个代码块，从而实现更快的代码生成，其性能可与顶级的开源编码模型相媲美。

该模型基于阿里巴巴的开源 LLM Qwen2.5-7B 构建，并采用了扩散模型架构，这使得它能够并行地细化整个文本，从而提高了代码生成的效率。通过调整温度参数，DiffuCoder-7B-cpGRPO 可以在自回归模型和扩散模型之间切换，从而在代码生成的灵活性和准确性之间取得平衡。

此外，该模型还通过一种名为 coupled-GRPO 的额外训练步骤，学习以更少的迭代次数生成更高质量的代码。实验结果表明，DiffuCoder-7B-cpGRPO 在流行的编码基准测试中获得了 4.4% 的提升，并保持了其较低的对从左到右严格生成代码的依赖性。

尽管 DiffuCoder-7B-cpGRPO 仍有改进空间，但它代表了苹果在生成式 AI 领域迈出的重要一步。它表明，苹果正在积极探索新的 AI 模型架构和训练方法，并致力于为开发者和用户提供更好的编码体验。

评论区里，有观点认为将 Qwen-2.5 7b 模型转化为扩散模型是很有意思的尝试，因为这意味着可以通过微调将从左到右的模型转化为乱序扩散模型。扩散模型在并行化和速度方面具有优势，可能更适合编码。还有人预测，这些本地模型在未来将足够好，可以用于实际工作，并可能在 Xcode 中得到应用。

使用 uv 依赖解析器解决 Wordle 难题

本文介绍了如何利用 Python 包管理工具 uv 的依赖解析功能来解决 Wordle 游戏。文章将 Wordle 的解题过程巧妙地转化为一个依赖解析问题，展示了 uv 在解决约束问题方面的潜力。

文章的核心思路是将 Wordle 的每一个可能解都视为一个 Python 包的不同版本。每个字母的位置也对应一个“位置”包，每个位置包有 26 个版本，分别代表 26 个字母。通过建立“单词”包和“位置”包之间的依赖关系，以及根据 Wordle 的反馈信息（绿色、黄色、灰色）添加约束条件，就可以让 uv 的依赖解析器找到满足所有约束的“单词”版本，从而得到 Wordle 的答案。例如，如果某个位置的字母是绿色，则可以直接指定该位置包的版本；如果是黄色，则需要排除该位置包的版本，并确保单词中至少包含该字母；如果是灰色，则需要排除单词中所有该字母。文章还讨论了如何处理重复字母的情况，以及如何更有效地进行猜测。最终作者使用 uv run main.py run 命令运行程序，成功解决了 Wordle 难题。

目前还没有评论内容。

使用 Lean 验证命令式程序：Std.Do 初探

本文介绍了 Lean 4.22 版本中引入的 Std.Do 框架，旨在简化命令式程序的验证过程。文章通过一个简单的例子，即判断列表中是否存在两个不同位置的整数和为零，展示了如何使用 Std.Do 验证局部命令式程序的正确性。

文章首先提出了一个使用哈希集合优化的算法，该算法在预期时间内以 O(n) 的复杂度解决问题。然后，展示了如何在 Lean 中使用局部命令式特性来实现这个算法，并强调了 Lean 不仅是编程语言，还是交互式定理证明器，可以证明程序的正确性。Std.Do 框架的核心是 Hoare 三元组，它允许描述程序执行前后状态之间的关系。文章通过一个具体的例子，展示了如何使用 mvcgen 自动化工具生成验证条件，并需要提供循环不变式来证明程序的正确性。循环不变式描述了循环执行过程中始终保持为真的属性，对于推断循环结束后的状态至关重要。文章给出了这个例子的循环不变式，并解释了如何在 Lean 中表达它。

由于文章没有评论内容，因此无法总结和分析评论区的不同观点。

评论 0 条

暂无评论，来种下第一颗种子。