hacker_news_top_comments_2026-04-30

Hacker News 高赞评论 - 2026-04-30

1. stickfigure 在“提交信息中的 HERMES.md 导致请求路由至额外使用计费”下的新评论

官方回应感觉像是AI生成的。我怀疑这就是我们未来的写照。

“你说得完全对！我很抱歉，但你还是得滚蛋。要不要花几个小时跟我们的AI聊天机器人讨论一下？它帮不了你。不过如果这能让你好受点，大概会让我们多花0.12美元的token费用。”

我打赌Anthropic第一个看到这条消息的人类，是从HN上知道的。

作者: stickfigure | 发布于: 2026-04-29 19:14

2. ecshafer 在“提交信息中的 HERMES.md 导致请求路由至额外计费”下的新评论

然而，我必须告知您，对于因服务降级或技术错误导致的错误计费路径，我们无法提供补偿。

这非常令人惊讶。我从未见过一家正规企业不为自身技术错误提供退款。至少Anthropic应该全额退还他们的费用。

作者: ecshafer | 发布于: 2026-04-29 19:05

3. mikehearn 在“提交信息中的 HERMES.md 导致请求路由至额外使用计费”下的新评论

“我需要告知您，对于因服务降级或技术错误导致的计费路由错误，我们无法提供补偿。”

我不确定是否见过有公司公开采取这种立场。这真是个疯狂的政策。

作者: mikehearn | 发布于: 2026-04-29 19:04

4. simjnd 在 “Mistral Medium 3.5” 中的新评论

我不知道评论里的人在说什么。这个模型并没有”击败”其他模型，但考虑到它的体积，它确实能与之竞争。

GLM 5.1 是个很优秀的模型，但即使量化到 Q4，你也需要大约 400GB 的显存。Kimi K2.5 也很不错，量化到 Q4 时差不多需要 600GB。

这个模型呢？你可以在 70GB 显存下以 Q4 运行它。这已经接近消费级水平了（你可以花大约 3500 美元买到一台 128GB 内存的 Mac Studio）。

对于那些被 Claude 圈粉的人，我不知道你们是不是只跑 Opus，但我在用 Pro 计划时，Sonnet 就已经非常强大了。而这个模型在本地运行时击败了最新的 Sonnet，而且不会因为你仓库里有 HERMES.md 就额外收费，也不会一时兴起就封你的号。

Mistral 在前沿领域从来都不是最顶尖的，但也许我们并不需要它做到那一步。拥有帕累托最优的模型，能以 20% 的成本/体积获得前沿模型 80% 的能力，这对我来说听起来很不错。

作者: simjnd | 发布于: 2026-04-29 16:30

5. Bender 在“在线年龄验证是必须坚持到底的立场”下的新评论

我唯一愿意参与的方式是：服务器运营者为可能包含成人内容或用户生成/贡献内容的URL设置RTA标头[1]，客户端可以选择检测该标头，并在设备所有者启用家长控制时触发。这应该足以保护大多数年幼的孩子。青少年总能绕过任何人的实现，就像他们已经在做的那样。RTA标头并不完美，没有任何东西是完美的，也永远不会完美，但这种方式完全不涉及追踪或数据泄露。政府可以轻松雇佣承包商扫描网站是否缺少该标头，并对不参与的网站处以巨额罚款，直到它们倒闭。

我——作为一个小型服务器运营者和互联网用户——绝对不会参与任何其他方式，句号，到此为止。围绕RTA标头制定简单、合乎逻辑且合理的法律，我就会参与。许多网站已经自愿添加了这个标头。实现起来非常简单。这里[1]有很多问题和冗长的讨论。我怀疑我那些小型私人和半私人网站不会被注意到，但总有一天可能会面临这种情况，到那时，我和朋友们就会退回到半私密的Tinc开源VPN网格中。

[1] - https://news.ycombinator.com/item?id=46152074

作者: Bender | 发布于: 2026-04-29 16:22

6. obeavs 在 “Zed 1.0” 中的新评论

这一串置顶评论真是糟糕透顶。这帮人用新颖的技术打造了一款出色的产品，而且它只会越来越好。Zed团队干得漂亮。

作者: obeavs | 发布于: 2026-04-29 15:38

7. giancarlostoro 在 “Zed 1.0” 中的新评论

祝贺Zed团队打造了我用过的最好的现代编辑器。我订阅了月度计划，只为给你们提供所需的资金支持，尽管我的贡献只是杯水车薪。我一直想要一个功能丰富的Sublime Text替代品，能在任何地方运行，并且基本满足我的所有需求。我使用JetBrains IDE多年（从2017年开始每年订阅），但自从用了Zed，我已经很久没有打开那些IDE了，除了偶尔用Rider处理一些C#的细微差别。

作者: giancarlostoro | 发布于: 2026-04-29 15:26

8. kalleboo 在“他让 AI 数了 27000 次碳水，结果每次答案都不一样”下的新评论

“但作者只是拍了食物的照片，就期望得到真实的回应？”

现在App Store上有些非常流行的应用正在非技术人群中走红，它们做的正是这件事，而用户对AI的工作原理毫无概念。我妻子曾谈到其中一个，我不得不让她认清现实——AI根本不知道食物用了什么原料。而她本人还是一名持证营养师。

像这样的研究，为那些感到困惑的人提供了一个可以指认的对象，也成了媒体展开讨论的跳板。

作者: kalleboo | 发布于: 2026-04-29 13:32

9. endymion-light 在“他让 AI 计算碳水化合物 27000 次，结果每次答案都不一样”下的新评论

关于大语言模型和碳水化合物计算的教育严重缺失。整篇文章更适合发在占星网站而非黑客新闻。

当我打开文章时，以为作者至少会尝试做个计算服务，比如把餐食分量输入实际模型，利用现有的（稍微）更准确的工具进行整合。见鬼——大多数食品按规定都必须标注卡路里信息，其他食物你也能查询开源数据！

但作者只是拍了食物照片就期望得到真实反馈？这真的能算作AI研究吗？

这就像Instagram上那些跟ChatGPT对话、让它计时跑步时长的短视频。只不过那些被当作搞笑段子，而不是被包装成研究。

我希望看到这项研究能运用任何形式的实际知识基础，看看AI在尝试通过图片分析获取真实数据时会犯什么错误——至少这样的方法论能得出有趣的结果。

作者: endymion-light | 发布于: 2026-04-29 12:59

10. danparsonson 在“ChatGPT 如何投放广告”中的新评论

不，我觉得”我把广告视为最后的手段”这种说法，其实是在拐弯抹角地说”广告迟早会来”。

我倾向于认为像他这样的人，是用语言来达成特定目标，而不是真正说出心里话的人。这些话是谎言、是真相、还是介于两者之间，其实并不重要；对他们来说，重要的是结果。

试图解读其中的含义很可能是在浪费时间，因为根本就没有含义。”但山姆·奥特曼说过…”对我来说，和”ChatGPT告诉我…”差不多有价值。

作者: danparsonson | 发布于: 2026-04-29 06:44

11. collinfunk 在“Rust 不会捕获的 Bug”中的新评论

你好，我是GNU Coreutils的维护者之一。感谢这篇文章，它涵盖了一些有趣的话题。在我使用Rust的少量经验中，我觉得用std::fs编写TOCTOU竞争条件实在太容易了。我希望标准库最终能提供一个类似openat的API。

我只想提一下，我不同意文章中”规则：在比较路径之前先解析路径”这一节。通常来说，更好的做法是调用fstat并比较st_dev和st_ino。不过文章中也提到了这一点。一个似乎较少被考虑到的副作用是性能影响。这里有一个实际例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
$ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
$ while cd $(yes a/ | head -n 1024 | tr -d '\n'); do :; done 2>/dev/null
$ echo a > file
$ time cp file copy

real 0m0.010s
user 0m0.002s
sys 0m0.003s
$ time uu_cp file copy

real 0m12.857s
user 0m0.064s
sys 0m12.702s

我知道在现实中人们不太可能做这样的事情。然而，GNU软件通常会非常努力地避免任意限制[1]。

另外，文章的主要观点仍然成立，但文章说”Rust重写在类似的活动窗口期内出现了零个[内存安全漏洞]”。然而，这并不正确[2]。:)

[1] https://www.gnu.org/prep/standards/standards.html#Semantics
[2] https://github.com/advisories/GHSA-w9vv-q986-vj7x

作者: collinfunk | 发布于: 2026-04-29 04:48

12. wahern 在“Rust 无法捕获的 Bug”中的新评论

值得注意的是，所有这些bug都出现在一个生产环境的Rust代码库中，而且是由那些自认为懂行的人编写的。

他们确实知道怎么写Rust，但显然对Unix API、语义和陷阱缺乏足够的经验。从长期从事GNU coreutils（或BSD、Solaris基础组件）开发的资深人员角度来看，这些错误大多极其业余——那些问题在几十年前就已经被发现并基本解决了，尽管旧代码库中仍有少量修复在持续进行（如今基本只是零星修补）。

作者: wahern | 发布于: 2026-04-29 04:37

13. programjames 在“ChatGPT如何投放广告”中的新评论

不到两年前，Sam Altman还说过：

我基本上把广告看作是我们商业模式的最后手段。如果这是让全世界每个人都能获得优质服务的唯一途径，我会这么做，但如果我们能找到其他方式，我宁愿不这样做。

那么，这是不是意味着OpenAI在宣布他们缺钱了？

作者: programjames | 发布于: 2026-04-29 01:43

14. alastairp 在“GitHub 之前”一文中的新评论

GitHub 给了我们什么

在我看来，GitHub 带来的一个明显改变是：它围绕个人而非项目构建了一套体系。对我来说，能快速创建一个以自己名字命名的仓库，感觉非常自由，而不用像以前那样，得经历一套（在我看来）相当严肃的流程——想好项目名，在 SourceForge 上注册，就为了得到一个 CVS 或 SVN 仓库（还要附带网站、邮件列表、问题追踪等等）。GitHub 让“哦，这只是个小玩意儿”这种心理负担变得轻松多了。

它给项目带来了问题追踪器、拉取请求、发布页面、维基、组织页面、API 访问、Webhooks，后来还有 CI。

虽然这些功能不是一次性推出的。我至今还记得，在组织功能出现之前，我们为了模拟组织，特意创建了一个新用户账户。我清楚地记得和朋友们讨论过，是否要为项目搭建一个 bug 追踪软件，当时我们的想法是：“GitHub 可能几个月内就会推出一个。” 最后，我们只是在仓库里提交了一个文本文件来记录。几个月后，问题追踪功能就发布了。

作者: alastairp | 发布于: 2026-04-28 22:41

15. margalabargala 在 “Ghostty 离开 GitHub” 下的新评论

“只有那些真正在乎的人留下来改进GitHub，它才会变得更好”

这话没错，但具有误导性。可惜了。

对于在微软GitHub工作的开发者来说，这是事实。但对用户而言，这并不成立。

你继续像以前那样使用GitHub，并不能通过任何途径让它变得更好。

作者: margalabargala | 发布于: 2026-04-28 22:01

16. idan 在“Ghostty 离开 GitHub”下的新评论

嗨！我是GitHub的长期粉丝和重度用户。

有情绪很正常。我也有类似的感受。我是GitHub用户22723，这实际上和你差不多（考虑到现在GitHub上有大约1.8亿个账户）。

我对你帖子的理解略有不同：

“只有那些在乎的人留下来让它变得更好，GitHub才会变得更好”

一走了之很容易。六年前我离开Heroku时就是这种感觉。我辞掉那份工作后，再也没有打开过Heroku的控制面板，尽管之前我愉快地使用了近十年。我觉得它已经无可救药了，虽然花了一段时间，但Salesforce最终确实成功地将它彻底搞垮了。

但GitHub给我的感觉不同。正因为它很珍贵，我才无法一走了之。这里不止我一个人有这种想法。

过去几年里，GitHub同时经历了一场根本性的范式转变（智能编码）和几次爆发式增长。这很混乱。我并不总是对结果或我们被迫做出的产品选择感到自豪。但这和Heroku/Salesforce的惨败完全不同。奥卡姆剃刀原则在这里适用：这不是”更多的AI编码”，也不是”邪恶的微软”。这是规模问题，是我们所有人脚下地基的根本性转变。

我希望我们能做出一些让你愿意回来的改变。我希望我们能再次点燃你心中的那份热情！对一个作为开发者生活中如此核心的东西产生强烈的情感并不愚蠢。别管那些闲言碎语。

作者: idan | 发布于: 2026-04-28 20:21

17. JuniperMesos 在 “Ghostty 离开 GitHub” 下的新评论

我能理解桥本对GitHub的真挚感情，以及开源软件开发世界为他打开的大门——他生命中相当长一段时间都投身其中。

另一方面，我不禁觉得，如果他多一些理查德·斯托曼那种“非自由软件天生可疑且不道德”的态度，这些心碎或许本可以避免。GitHub从来都是别人托管的非自由软件，按照所有者的规则运行，为所有者的利益服务，而不是最终用户。2008年如此，今天依然如此。

我也在GitHub上度过了生命中相当长一段时间，通常是因为工作需要。但我从未对它产生情感依赖。事实上，我早就对GitHub感到不满：它是别人的专有软件，尽管建立在自由软件Git之上，却想方设法在结构上把用户锁定在自己的平台上。

我从未能够爱上那种需要邮箱注册、接受服务条款、并且在伊朗无法使用的软件——因为运营它的公司遵守美国的制裁法律。

所以，我毫无保留地高兴看到Ghostty正在从GitHub迁移到其他地方。

作者: JuniperMesos | 发布于: 2026-04-28 20:01

18. DrammBA 在“Ghostty 离开 GitHub”下的新评论

我能感受到那种挫败感，表达出来没什么大不了的。

文章里的这段话让我很有共鸣：

我想好好干活，但它不让我好好干活。我想发布软件，但它不让我发布软件。

这种感受是共通的，而且GitHub并不是唯一让我有这种感觉的服务。现在网上的东西都变得越来越脆弱、越来越低质。频繁的宕机、bug、UI上的小毛病、不完整的功能——这到底是怎么回事？

作者: DrammBA | 发布于: 2026-04-28 20:01

19. mitchellh 在“Ghostty 离开 GitHub”下的新评论

我知道这听起来很夸张，但这是真的：写这篇博客文章时我确实哭了（眼泪滴到了键盘上，说出来挺难为情的）。

说到底，没人应该为了一款SaaS产品而哭泣。但GitHub对我的意义远不止于此（文章里都写到了）。我和它之间有一种不太健康的关系。它给了我太多，我对此充满感激。但它已经不是从前的样子了。我也不知道。

我们断断续续讨论了好几个月，几周前才开始认真讨论，几天前做出了最终决定。当真正”落笔”按下”发布”按钮时，一切都变得如此真实。

我知道肯定会有人因此取笑我。这确实是一件很傻的事。但我真心热爱GitHub，希望他们能找到自己的方向。

作者: mitchellh | 发布于: 2026-04-28 19:58

20. tedivm 在 “Ghostty 离开 GitHub” 下的新评论

看着GitHub作为一个组织逐渐崩塌，确实令人瞩目。关于原因有很多讨论：从独立运营到成为微软的一部分，资源被转移到Copilot而非核心服务，组织架构本身，对vibe coding（氛围编程）的依赖，等等。

无论原因是什么，不可否认的是GitHub正面临一些严重问题。非官方状态页面[1]展示了一个触目惊心的状况。

我非常希望能听到一些内部人士的看法（哪怕只是为了学习如何防止这种情况在我工作的地方发生），但我想任何关注过的人都清楚，GitHub这艘船正在下沉，人们没有弃船的唯一原因是惯性。考虑到如今软件行业其他方面变化如此之快，我不认为惯性足以支撑一家公司。

  1. https://mrshu.github.io/github-statuses/

作者: tedivm | 发布于: 2026-04-28 19:55