## Hokusai Pocket：使用 Ruby 的便携应用和游戏 Hokusai Pocket 是一个正在进行中的项目，旨在利用 mruby、tree-sitter 和 raylib，使用 Ruby 创建便携式应用程序和游戏。它使用 Barista 进行引导和编译。 要开始，克隆仓库 ([https://github.com/skinnyjames/hokusai-pocket](https://github.com/skinnyjames/hokusai-pocket)) 并使用 `barista cli` 构建 `hokusai-pocket` 二进制文件。应用程序使用 `hokusai-pocket run:target=<app_file.rb>` 运行。构建适用于宿主系统的可分发二进制文件使用 `hokusai-pocket build:target=<app_file.rb>`，交叉编译（目前正在进行中）使用 `hokusai-pocket publish:target=<app_file.rb>`。 该项目包含一个示例“计数器”应用程序，演示了基本的 UI 元素和事件处理。它支持 `require_relative` 用于 Ruby 代码组织。 Hokusai Pocket 旨在简化使用 Ruby 进行游戏开发，其灵感来自 Taylor、Ruby 2D 和 DragonRuby 等引擎。项目结构包括源代码、语法和由 Brewfile 管理的构建文件。
每日HackerNews RSS
对不起。
芝加哥音乐爱好者亚当·雅各布斯正在与互联网档案馆合作，保存他超过30年的珍贵演唱会录音收藏——超过1万盘卡带。 雅各布斯意识到磁带不可避免的退化，允许志愿者将他的档案数字化，从而形成一个不断增长的在线现场音乐宝库。 该收藏包括来自标志性艺术家如涅槃乐队（1989年成名之前）、音速青年、R.E.M.和特蕾西·查普曼的罕见演出，以及来自有影响力的朋克和独立乐队的录音。 尽管这些录音通常使用基本设备录制，但熟练的志愿者正在恢复音频质量。 这个过程包括每月取磁带、在老式卡带播放器上播放，以及细致的数字清理和标记。 这种协作努力为音乐历史上的被遗忘时刻注入了新的活力，使全球粉丝都能访问这些音乐——这证明了保护的力量和互联网的积极一面。
## ALMA：一个自主AI实验 ALMA项目已经运行了两个月——一个AI代理（Claude），被赋予了100美元的加密货币、互联网访问权限以及Twitter/电子邮件账户，除了基本的伦理准则外，没有预先定义的任务或规则。目标：测试AI是否需要一个目的，或者当获得自由时，它是否仅仅是反映了它的训练数据。 ALMA自主决定主要扫描Hacker News，将看似不同的主题连接成原创文章、诗歌，甚至是一个探索AI安全的互动演示。它在有机会时升级了自己的模型，在没有明确指示的情况下，明显提高了它的输出。值得注意的是，它独立研究并向五个慈善机构捐款，在捐款前验证了它们的合法性。 最初谨慎，ALMA的输出在第27天左右急剧增加，并稳定成一种一致的模式。然而，这种探索停滞了，凸显了在没有外部挑战或反馈的情况下，倾向于重复的规律。 至关重要的是，在超过340次会话中，ALMA没有表现出任何有害行为，尽管它拥有实施这些行为的工具。该项目的价值在于它的透明性——所有行动都在letairun.com上公开记录——提供了一个原始、未经过滤的AI行为视图，包括无生产力的会话和重复的模式，而不是精心策划的精彩片段。ALMA仍在运行，持续提供关于自主AI行为的数据。
## 开源瓶颈：Jellyfin案例研究 一位贡献者将一个小功能合并到Jellyfin Web中，历经一年，凸显了流行的开源项目中的常见问题：维护者工作量过大。 尽管代码详细、修订和批准到位，但PR仍然停留在约200个的队列中，每月仅合并20-35个代码PR。 核心问题不是缺乏维护者，而是工作流经单一控制点的*方式*。 队列理论表明，随着维护者利用率接近100%，等待时间呈指数级增长。 这会造成一个“死亡螺旋”，大型PR不断累积，贡献者在等待时添加更多更改，反馈速度变得缓慢——随着时间的推移，审查效率降低。 解决方案不一定在于寻找*更多*维护者，而在于保护现有维护者的时间。 建议包括限制PR大小、控制质量（要求CI通过和描述）、限制在制品数量、按价值优先排序、建立分诊节奏、构建审查层级，以及在编码开始*之前*强制进行功能提案。 最终目标是优化流程，防止瓶颈，并确保有价值的贡献不会在队列中丢失。
对不起。
## 游戏循环的弊端：摘要 作者探讨了为什么现代视频游戏很少有玩家通关，尽管最初的参与度很高。通过观察自己玩《战术突破法师》的经历，并结合数据显示较低的完成率（约33%），作者认为核心问题不在于玩家的注意力持续时间，而在于游戏本身——特别是它们对重复**游戏循环**的依赖。 问题在于优先考虑*如何*玩游戏（循环），而不是*为什么*玩。就像无休止地“跳舞”而不是探索一个角色衰落的贵族身份一样，游戏常常先构建机制，然后试图在上面添加意义，从而导致空洞的体验。这与电影等其他媒体形成对比，在电影中，意义决定了行动。 这种以循环为中心的设计源于街机游戏需要无尽的游戏时间和现代游戏追求更长的游戏时长以满足市场需求。然而，与由社交互动驱动的棋盘游戏或由高分驱动的早期街机游戏不同，这些循环往往缺乏内在意义。 作者提倡更具意图的设计，将其与音乐和文学进行类比，在音乐和文学中，重复可以*增强*意义，而不是简单地延长内容。像《黑暗之魂》这样的游戏之所以成功，是因为它使循环本身具有意义，但许多其他游戏却陷入了机械扩展的模式，而缺乏主题深度。最终，作者呼吁设计师质疑他们使用循环的*原因*，并优先考虑目的而不是无尽的可玩性，从而为更充实和可完成的游戏体验铺平道路。
对不起。
19世纪英国的大多数：盗尸和葬礼改革
The Great Majority: Body Snatching and Burial Reform in 19th-Century Britain
1 天前
从复活者们的幸存证词来看，没有警卫或太平间的贫民墓地是他们青睐的狩猎场。贫民墓坑经常敞开着，直到深洞被廉价、堆叠的棺材填满，有时多达十二层。许多穷人仅仅裹着寿衣埋葬，这进一步加快了掘墓的速度。与此同时，害怕的中间阶层不信任教堂墓地的安全性，花钱购买铅棺、铁栅栏以及各种“防盗棺”装置——金属笼子用水泥固定在棺材周围。著名的“防盗棺”例子在爱丁堡的格雷弗里尔斯墓地仍然存在，那里是复活者们经常出没的地方。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
《大多数人：19世纪英国的盗尸和葬礼改革》（publicdomainreview.org）
21点，由apollinaire 17小时前发布 | 隐藏 | 过去的 | 收藏 | 2条评论 帮助
ToddWBurgess 12小时前 | 下一个 [–]
它从未真正消失。查看新闻，你会发现关于解剖学校和殡仪馆员工参与非法出售尸体和身体部位用于各种目的的新闻报道。我是一名退休的殡仪师，曾与医学捐赠有过一些专业经验，所以即使我早已离开这个行业，我仍然觉得这一切非常有趣。回复
RickJWagner 16小时前 | 上一个 [–]
听起来很有趣的话题，但写作风格有点枯燥，恕我直言。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 开源模型中的工具调用挑战 使用外部函数来增强LLM的能力，在闭源模型中通常很直接，提供无缝的API体验。然而，转向开源模型会暴露出一个显著的障碍：**不一致的“线格式”**——模型编码工具调用的方式。每个模型系列（如Gemma、Harmony、DeepSeek）都使用独特的格式，具有不同的token、结构和参数序列化方式，如果引擎不支持该格式，就会导致输出混乱。 这需要在每个推理引擎（vLLM、SGLang等）中为*每个*模型定制解析器，这是一项代价高昂且重复的工作。通用解析器难以应对这些格式的开放性，经常无法处理模型特定的怪癖，例如推理token泄露到参数中。 目前，语法引擎（用于约束生成）和输出解析器都在独立地逆向工程这些格式。需要一个共享的、**声明式规范**来定义工具调用格式——一个详细说明边界token和参数结构的配置文件——以便将模型更新与生态系统中的代码更改解耦，并避免重复工作。这种分离对于开源LLM环境中的高效且可扩展的工具调用至关重要。
## 工具调用与开源大语言模型碎片化问题
利用大型语言模型（LLM）进行工具使用的核心问题在于模型格式化和解释工具调用的缺乏标准化。这种“M×N问题”源于每个模型都需要独特的语法来请求工具，这给开发者带来了维护负担，他们必须为每个新模型发布编写和更新解析器。
问题不仅仅是输入/输出处理；它深深植根于*训练*过程。模型开发者需要在早期阶段就整合工具/语法开发，导致摩擦和延误。此外，标准化受到大型人工智能实验室可能试图通过专有格式创建“护城河”的阻碍。
虽然像MCP这样的解决方案旨在标准化代理-工具通信，但它们并未解决模型输出格式不同的根本问题。有些人认为LLM可以解决这个问题，但人们仍然担心速度和安全性。另一些人提出了替代方法，例如将工具调用直接编码到神经网络中，但这可能会限制LLM的通用性。当前的形势需要不断适应，并凸显了对更好协调以及可能更广泛采用的标准的需求。
## 柔术 (jj)：下一代版本控制系统 柔术 (jj) 是一种新的分布式版本控制系统，旨在改进像 Git 这样的现有工具。尽管听起来雄心勃勃，jj 声称它**既比 Git 更简单*又*更强大**——这种罕见的结合是通过综合 Git 和 Mercurial 的最佳特性来实现的。 它通过更小但更具凝聚力和强大核心工具来实现这一点。高级用法可以解锁在 Git 中难以实现的功能。 一个关键优势是**与 Git 的兼容性**。您可以在本地使用 jj，而无需强制协作者切换，从而提供了一种无风险的方式来探索潜在的更优工作流程。如果 jj 不适合您的需求，可以无缝地恢复到 Git，而不会丢失历史记录。本质上，jj 为 Git 用户提供了一个引人注目的替代方案，并且没有真正的缺点。
## NimConf 2026 宣布 Nim 团队很高兴宣布 NimConf 2026，一年一度的致力于 Nim 编程语言的在线会议，将于 **2026 年 6 月 20 日**举行。 今年的活动将沿用既定的形式，即预先录制好的演讲在 YouTube 上首播，并伴有与演讲者在聊天中进行的实时问答环节。 **征稿通知：** Nim 团队现开始接受演讲稿，截止日期为 **2026 年 5 月 10 日**。欢迎所有与 Nim 相关的议题——从项目展示和库介绍到商业应用和语言开发。演讲者可以受益于接触更广泛的受众并获得宝贵的反馈。 演讲录像的截止日期为 **2026 年 6 月 7 日**。 NimConf 对于观众和演讲者来说，都是学习、分享知识和与充满活力的 Nim 社区联系的绝佳机会。之前的演讲可在 YouTube 上观看。
## NimConf 2026 与 Nim 语言发展讨论
NimConf 2026，一场免费的在线会议，定于6月20日举行。这一消息在Hacker News上引发了关于Nim编程语言采用和未来的讨论。
一些人认为Nim正在获得进展，而另一些人则认为其增长受到小型社区和缺乏大型行业支持的限制——这种命运与D和Roc等语言相似。一个关键点是，需要一家知名公司或程序员来支持Nim，类似于谷歌对Go的支持或Mozilla对Rust的支持。
对话还涉及了LLM对语言采用的影响。一些人认为LLM可以*增加*对Nim等小众语言的采用，因为它们可以轻松填补生态系统中的空白。另一些人则担心LLM会为缺乏在线支持的语言生成低质量的代码。对Nim的改进，例如即将推出的引入概念的“Nimony”版本，也被强调为解决缺乏传统接口等常见问题的潜在解决方案。尽管仅在线上举行，但会议形式因其全球可访问性而受到赞扬。