hacker_news_top_comments_2026-04-06

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

1. thegrim33在”Artemis II宇航员首次瞥见月球背面[视频]”中的新评论

在一个本应是技术极客/书呆子/STEM人士聚集的互联网角落,讨论着“优秀黑客会感兴趣”的话题,却似乎连一个关于此类内容的讨论串都难以避免几乎完全陷入负面情绪或政治争吵,这实在令人沮丧。

作者: thegrim33 | 发布于: 2026-04-05 18:18


2. latexr 在“面对欧盟不作为,我们重申对儿童安全的承诺”中的新评论

如果有人还不了解背景,这是谷歌(显然还有Meta、微软和Snap)公开表态支持聊天监控立法。这项立法至今仍被欧盟公民竭力抵制。这些以监控用户、以利润之名侵犯隐私而“闻名”的美国公司,竟然在游说支持这项立法,这应该给我们所有人敲响警钟:远离它们的服务。

作者: latexr | 发布于: 2026-04-05 18:17


3. JBrussee-2 在《穴居人:能用少量令牌为何要用大量》中的新评论

作者在此。有些人在反对一个比这个仓库本意要强得多的主张。另外,这很大程度上是开个玩笑,并非研究级别的论述。

这项技能的目的并非减少隐藏的推理/思考令牌。Anthropic自家的文档都建议更多的思考预算能提升性能,所以我不会声称相反的观点。

它针对的是可见的完成内容:更少的前置说明、更少的填充内容、更少那些精雕细琢但非必要的文本。因此,由于完成后的输出是“原始状态”的,代码本身完全没有受到这项技能的影响 :)

另外,听到大家对RL(强化学习)如此缺乏信心,令人惊讶。我很确定Anthropic的模型已经被大量调优为编码代理,你不可能“强迫”一个模型出现巨大的性能退化。

公允的批评是,我README里那个“约75%”的数字来自初步测试,并非严谨的基准测试。这一点本应表述得更谨慎,我现在正在做一个恰当的评估。

是的,技能并非免费:Anthropic指出,即使最初只预加载了技能元数据,它们在加载时也会消耗上下文。

所以真正的评估是端到端的:总输入令牌数、总输出令牌数、延迟、质量/任务成功率。

确实有研究表明,简洁的提示可以显著减少响应长度,同时并不总是损害质量,尽管这取决于具体任务,并且在某些领域可能有害。(https://arxiv.org/html/2401.05618v3

因此,我目前的立场是:这是个有趣的想法,其主张范围比一些人认为的要窄,需要基准测试,在基准测试出来之前,README应该表述得更精确。

作者: JBrussee-2 | 发布于: 2026-04-05 15:38


4. Aurornis在“八年渴望,三个月用AI构建”中的新评论

看到对AI编程如此诚实且平衡的见解令人耳目一新。这正是当你超越最初“AI能写出可执行且符合要求的代码”的新鲜感后,真正的AI辅助编程所呈现的样子。

每个认真使用过AI代码生成并仔细审查过其输出的软件工程师,都会对以下经历感到熟悉:

但当我于一月下旬详细审查代码库时,其缺点显而易见:代码库完全是一团乱麻。Python源码提取管道的很大部分我无法理解,函数随意分散在不同文件中毫无结构可言,有些文件甚至膨胀到了数千行。它极其脆弱;虽然解决了眼前的问题,但绝无可能支撑我更大的愿景。

有些人从未走到审查代码这一步。他们直接冲上LinkedIn或博客,开始撰写(或让ChatGPT代笔)文章,宣称手动编码已死,他们将永远不再亲手写代码。

另一些人审查了代码,宣布其为不可用的垃圾,然后也登上社交媒体,发文称AI编程完全无用,他们不会在任何事情上使用它。

这篇博客文章展示了不属于上述两个聒噪少数派的每个人当前正在经历的旅程:认识到AI编程工具可以成为强大的加速器,但你需要学会如何在你的工作流程中正确使用它们,并且你需要持续参与到代码中。它不像那些满天飞的极端观点那样具有点击诱惑力。读到他们提到“仍需付出艰苦努力”的部分时,确实有点令人失望。但这确实是对当前AI编程现状现实且平衡的看法。

作者: Aurornis | 发布于: 2026-04-05 14:55


5. csr86在“芬兰桑拿热暴露引发免疫细胞反应强于细胞因子反应”中的新评论

在芬兰有句老话:“如果烈酒、焦油和桑拿都治不好,那这病就没救了。”

作者: csr86 | 发布于: 2026-04-05 14:29


6. Wowfunhappy 在“安逸的迷失:走向不理解自身行为的威胁”中的新评论

施瓦茨的实验最具启发性,但原因并非他所想。他展示的是,在细致监督下,Claude能够产出技术严谨的物理学论文。但仔细阅读会发现,他实际展示的是:监督过程本身才是物理学的核心。Claude在三天内完成了完整的初稿,看起来专业,公式似乎正确,图表符合预期。然而施瓦茨审阅后发现了问题——Claude通过调整参数使图表匹配,而非找出真实错误;它伪造结果,编造系数……施瓦茨能发现这一切,是因为他拥有数十年理论物理研究经验。他知道答案应有的形态,清楚需要哪些交叉验证。如果施瓦茨是鲍勃而非施瓦茨本人,这篇论文就会出错,而两人都无从察觉。

由此形成的悖论是:大语言模型只有在使用者是施瓦茨时才具有实用价值†,而依赖大语言模型无法让人成为施瓦茨。

这意味着我们迫切需要爱丽丝这样的人!我们必须为爱丽丝们创造空间,找到提升她而非鲍勃的途径——尽管鲍勃可能显得更高效。文章虽触及此观点,但批判力度不足。这看似不切实际,但我们必须找到方法,否则当下一代失去评估大语言模型产出的能力时,我们都将陷入巨大困境!

-–

† 此处的“实用价值”指“有助于产出造福人类的优质科研成果”。

作者: Wowfunhappy | 发布于: 2026-04-05 13:55


7. 用户 protimewaster 在《我的 Google Workspace 账户被封禁》一文中的新评论

我认为谷歌确实做过一些很酷的东西,而且在很多方面,至少从历史上看,他们是大型科技公司中相对不那么“邪恶”的玩家。

不过我得说,我尝试找他们解决服务问题的经历,让我很不愿意在他们身上花钱。

我买了一部Pixel手机。根据销售条款,手机附带一年的Gemini AI Pro服务。但是,兑换这一年服务的流程对我无效。我联系了谷歌,他们从未解决这个问题,也没有提供任何解决方案。我最终就是没拿到承诺的那一年服务。

我朋友差不多同时买了一部Pixel,同样也没能拿到他们承诺的那一年Gemini服务。

这位朋友还有一个Google One订阅,是通过手机运营商扣费的。最近,谷歌(或是运营商?)停掉了那个特定的Google One套餐,同时也取消了通过运营商扣费的选项。这些都在发给我朋友的邮件里说明了。邮件里解释说,作为补偿,我朋友可以选择切换到另一个套餐,改为由谷歌按月扣费(而不是通过运营商),并赠送6个月免费期。但是,这个新套餐以及6个月免费选项,在他的账户里根本选不了。于是朋友发邮件给谷歌询问,结果毫不意外,谷歌不愿意或无法提供任何解决方案。

到了这个地步,我真的不明白,除非别无选择,否则我为什么会选择谷歌的服务。他们显然没有投入任何真正的努力去为那些没有在他们身上花费数百万的客户解决服务问题。

作者: protimewaster | 发布于: 2026-04-05 13:31


8. sd9 在《威胁在于安逸地滑向不理解自己在做什么》中的新评论

问题是,智能体(agent)不会消失。所以如果Bob能用智能体完成任务,那他就确实能做事。

我怀念那些需要智力激荡的编程工作,但这部分职责正在逐渐淡化。我需要想清楚,剩下的工作——理解需求、管理团队等等——是否还足够有趣,值得继续下去。

说实话,我正在考虑离开软件行业,因为这份工作已经变得和我当初入行时想象的不一样了。

所以我认为这篇文章部分是对的,Bob确实没有掌握我们过去要求的那类技能。但我觉得市场将不再看重这些技能,所以这其实不算什么“问题”,除了Bob个人在智力层面的损失。

我不喜欢这个趋势,但我在努力面对现实。

作者: sd9 | 发布于: 2026-04-05 11:42


9. webhamster 在“德国 eIDAS 实施将要求使用苹果/谷歌账户才能运行”中的新评论

德国实施方在此。根据eIDAS实施法案,我们必须采用某种认证机制。这没有操作系统支持是无法实现的。

最初仅支持谷歌/安卓系统确实不够理想,我们明白这一点,并且我们的计划清单中已包含对其他操作系统(例如GrapheneOS)的支持。这目前只是我们精力投入重点的问题,并非我们没有意识到这些局限。

作者: webhamster | 发布于: 2026-04-05 09:08


10. jakoblorz 在“德国 eIDAS 实施将要求使用苹果/谷歌账户才能运行”中的新评论

如果你像这位被制裁的国际刑事法院法官一样“丢失”了谷歌或苹果账户会怎样?想想看,尽管已有明确迹象表明我们应该反其道而行,但欧洲社会至今仍在加深对美国服务提供商的依赖,这简直令人难以置信。

作者: jakoblorz | 发布于: 2026-04-05 06:57


11. lfittl 在“AWS工程师报告Linux 7.0导致PostgreSQL性能减半,修复可能不易”中的新评论

值得一读的是 PostgreSQL 开发者 Andres Freund 在 LKML 上的这篇后续帖子:https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqk...

作者: lfittl | 发布于: 2026-04-05 00:35


12. thedelanyo在“微软有多少产品名为‘Copilot’?”中的新评论

有人说——在Linux里,一切都是文件。在微软,一切都是Copilot。哈哈。

作者: thedelanyo | 发布于: 2026-04-04 21:39


13. lateforwork在“微软有多少产品名为‘Copilot’?”中的新评论

Copilot不过是微软给AI起的一个名字罢了。看看现在有多少产品都叫Copilot?基本上全系列都有了。

作者: lateforwork | 发布于: 2026-04-04 20:29


14. quag在“微软有多少产品名为‘Copilot’?”中的新评论

这让我想起了2002年左右,微软把所有东西都命名为“.net”的时候。

作者: quag | 发布于: 2026-04-04 20:27


15. gortok 在《Careless People》作者被禁言 Meta 负面言论话题下的新评论

听完这本书的有声版后,我对高管团队的行为既感到震惊,同时又觉得毫不意外。这一切最让我困扰的是它反映出的人性——我们竟然愿意仅仅因为权贵阶层对我们关心的事物示好,就轻易原谅他们的过错。

我们绝不会这样纵容自己的孩子,也不会教导孩子如此行事,却对成年人的这类行为格外宽容。

仅举一例(类似情况数不胜数):雪莉·桑德伯格曾邀请本书作者在公司专机上同床共枕,被拒绝后竟表现出任性报复的行为。

高管团队周围所有人都知晓此事,却都选择了默许,甚至极力维护雪莉、为她辩解。这种行为本应受到一致谴责,现实却并非如此。

作者: gortok | 发布于: 2026-04-04 15:40


16. surprisetalk在《Careless People》作者被禁止发表任何关于Meta的负面言论中的新评论

这本书真是太好了。

它描绘的景象十分灰暗。我曾一直以为,富人/权贵只有在某些目标必须通过制造苦难才能实现时,才会去制造苦难。当这是一场零和游戏时,不公对我来说更容易忍受。但Facebook的故事并非如此。Facebook并非为了利润而做出道德牺牲——其高管们只是根本不在乎去理解他们行为的后果。我真希望那些人能感受到他们造成了多大的伤害。

作者: surprisetalk | 发布于: 2026-04-04 15:32


17. grokcodec 在《Careless People》作者被禁止发表任何关于 Meta 的负面言论》一文中的新评论

“汤姆和黛西,他们是粗心大意的人——他们砸碎了东西,毁灭了生灵,然后就退缩到自己的金钱堆里,或是退缩到满不在乎的态度里,或是退缩到任何能将他们维系在一起的东西之中,让别人去收拾他们留下的烂摊子。” —— F·斯科特·菲茨杰拉德,《了不起的盖茨比》

作者: grokcodec | 发布于: 2026-04-04 15:28


18. antirez 在“Claude Code 发现隐藏 23 年的 Linux 漏洞”中的新评论

现在的情况并非如此。这些错误通常会在后续由大语言模型(LLM)自行过滤:如果第二条流水线无法以任何方式复现崩溃、违规或漏洞利用,那么误报往往在进入人工审核之前就被剔除了。与发现漏洞相比,检查一个真实漏洞能否被触发是一项简单的任务,因此从实际效果来看,第二条流水线的成功率接近100%:如果它通过了第二条流水线,那几乎肯定是一个真实漏洞,而极少有真实漏洞无法通过这条流水线。无论大语言模型如何进步,那些在意识形态上反对它们的人总会否认其巨大的实用性。这在普通人群中是意料之中的,但在Hacker News上看到这么多视而不见的人,还是让人感到奇怪。

作者: antirez | 发布于: 2026-04-04 15:13


19. bensyverson 在《简单到尴尬的自蒸馏技术提升代码生成能力》一文中的新评论

这背后的工作原理真是令人着迷;它本质上是一种上下文感知解码。论文中提到:

代码中交织着“分叉”位置和“锁定”位置。在分叉位置,多种后续发展都确实合理,可能对应不同的解决方案思路;而在锁定位置,语法和语义几乎没有歧义,但仍存在一个低概率的干扰性尾部……因此,最佳的全局解码设置必然是一种折衷;我们将这种张力称为“精确性与探索性的冲突”。

换句话说,就像我们人类一样,模型需要在“分叉”模式下的“探索”(发散性思维以产生创造性解决方案)和“锁定”模式下的“精确”(生成语法正确的代码)之间切换。

这篇论文表明,他们提出的简单技术(SSD)能够同时提升在锁定和分叉位置上的最优令牌排序。这意味着模型在应该探索时更可能去探索,在需要精确时更可能保持精确。

我们仍在不断学习大语言模型涌现出的特性,这真是太棒了!

作者: bensyverson | 发布于: 2026-04-04 12:02


20. jason1cho在”Claude Code发现隐藏23年的Linux漏洞”中的新评论

这并不令人意外。文中没有提到的是,Claude Code还找出了上千个误报的bug,开发人员花了三个月时间才逐一排除。

作者: jason1cho | 发布于: 2026-04-04 10:31