Hacker News 高赞评论 - 2026-04-02
1. jordanb在”SpaceX申请上市”中的新评论
你不需要相信。如果你有401k养老金账户，那么在公司上市15天后，你就会成为它的投资者。
这次IPO会非常成功，因为公司只会发行相当少量的股票。大股东不会立即抛售。他们会继续持有，甚至可能买入以支撑股价。
然后，15天后，它将进入各大指数，所有人的401k账户就会开始自动买入这只股票。
你可能会说，如果指数这么快就接纳一只流通股有限的全新IPO股票，这显然是指数运作方式的一个缺陷。你说得对，所以通常它们一年内都不会被纳入指数。
至少以前是这样，直到埃隆让他们修改了规则：https://www.bloomberg.com/news/articles/2026-03-30/nasdaq-cl...
作者: jordanb | 发布于: 2026-04-01 19:28
2. 用户 magicalhippo 在《Claude 编写了一个完整的 FreeBSD 远程内核 RCE 并获取 root shell》中的新评论
关键在于，Claude并没有自己发现它利用的那个漏洞。它是拿到了CVE的详细报告1，然后被要求编写一个能利用该漏洞的程序。
话虽如此，考虑到目前的发展状况，如果让Claude或类似的AI去分析内核或核心服务的源代码，再配备一些虚拟机进行试错迭代，让它源源不断地生成CVE，我一点也不会感到惊讶。
就算现在做不到，在不久的将来也肯定能实现。
作者: magicalhippo | 发布于: 2026-04-01 09:59
3. simonebrunozzi在”OpenAI以8520亿美元估值完成融资轮”中的新评论
不，他们并没有像HN标题暗示的那样筹集到1220亿美元。那1220亿美元中很大一部分是“可能”的，取决于未来需要发生的各种条件。
哎呀……我迫不及待想看看这事会怎么发展。毕竟，结果可能不会太好看。
作者: simonebrunozzi | 发布于: 2026-03-31 21:11
4. manbitesdog在“Claude代码源泄露事件：伪造工具、挫败正则表达式与卧底模式”中的新评论
每次看到Claude试图在提交记录里挂名合著者，我都觉得尴尬。Git历史记录本应追踪责任归属和所有权，而不是你的“工具清单”。难道我还得把我的代码检查工具、智能提示和IDE都列为PR的合著者吗？
作者: manbitesdog | 发布于: 2026-03-31 21:09
5. latexr 在《“粗制滥造”未必是未来》一文中的新评论
你不必非要在两个阵营中选边站。在我看来，如果你想为用户打造优秀的产品，就应该把为他们编写的代码视为自己的手艺。高质量的工作无可替代。
说得太对了，感谢你这样的表述。
根据我的观察，目前只有像原帖作者那样思考的人，才会用他们那种方式描述这种局面。这是一种虚假的二元对立，却成了讨论的焦点。通过将其框定为“存在两个阵营，只是不同而已，没有孰优孰劣”，就为他们自身的立场赋予了合理性。
举个夸张且不可类比的例子，仅用于说明这种话语框架的力量：你可以说“有人认为枪支应该受管制，而有人热爱自由”。这便将事情推入了非此即彼的境地。这是一种按自身意图设定讨论框架的策略。
作者: latexr | 发布于: 2026-03-31 19:44
6. 用户 mzajc 在“Claude 代码源泄露：伪造工具、挫败正则表达式与卧底模式”中的新评论
现在有几条评论（错误地？）将“隐身模式”仅仅理解为隐藏内部信息。以下是实际提示词0中的节选：
绝对不要在提交信息或PR描述中包含：
- “Claude Code”这个短语或任何提及你是AI的内容
- Co-Authored-By行或任何其他归属信息
错误示例（永远不要这样写）：
- 由claude-opus-4-6一次性生成
- 使用Claude Code生成
- Co-Authored-By: Claude Opus 4.6 <…>
这听起来完全就是字面意思：保持隐身并假装是人类。尤其令人担忧的是，这个提示词明确是为向公共代码库贡献而编写的。
作者: mzajc | 发布于: 2026-03-31 19:06
7. nocman 在《Slop 未必是未来》中的新评论
完全错误。
大众除了产品的功能和限制外什么都不关心。
同样错误。
人们可能并不_知道_他们喜欢你的产品是因为代码质量高，但每个人都喜欢那些几乎没有bug、性能极佳、能帮助他们快速完成工作，并且显然是由那些对产品质量极为重视的人开发的软件（你知道，就是那种真的会看bug报告并快速修复问题的人）。
你的产品存在的时间越长，代码质量就越重要。现在很多人痴迷于“5秒钟内发布”，这只会继续制造出那些慢如蜗牛、执行简单任务却要占用数GB内存的垃圾软件。
你不必非要在两个极端中选择一个。在我看来，如果你想为用户打造一款_好_产品，你也应该将为他们编写的代码视为你的手艺。高质量的工作是无可替代的。
作者: nocman | 发布于: 2026-03-31 18:52
8. “OkCupid 向面部识别公司提供 300 万约会应用照片，FTC 称” 的新评论 by everdrive
时至今日，几乎所有的在线服务都应被视为带有敌意。只要能通过侵犯你的隐私或身份赚点小钱，他们就会去做。只要能通过窃取你的注意力并让你上瘾来赚点小钱，他们也会去做。
有例外吗？我相信是有的。我有时会不会因为过度谨慎而犯错？当然会。但如今，我们确实没有太多其他选择。
作者: everdrive | 发布于: 2026-03-31 18:42
9. seamossfet在《“粗制滥造”未必是未来》中的新评论
我发现大多数开发者可以归为两类：
第一类人把代码视为实现产品、服务用户的手段。
第二类人将代码本身视为自己的技艺，产品只是展示技艺的载体。通常对AI批评最激烈的人属于第二类，因为AI自动化了他们视为艺术创作的大部分工作，同时却让第一类人能更快地迭代产品。
就我个人而言，我属于第一类。
从来没有人会因为你的代码写得有多好而决定购买产品。
普通用户只关心产品的功能和局限。当然，如果你在代码中埋下重大缺陷，这最终会表现为对用户产生负面影响的后果。话虽如此，我确实尊重第二类人。但他们通常最适合那些确实需要精湛技艺的项目（例如：关键任务软件、我们其他开发者依赖的库等）。
我只是觉得，如果不明确我们讨论的是哪种类型的项目，就很难深入探讨这个话题。
作者: seamossfet | 发布于: 2026-03-31 18:01
10. wowoc 在“微软：Copilot 仅供娱乐用途”中的新评论
Anthropic 也做了件类似的事。如果你从欧洲 IP 地址访问他们的服务条款（针对 Max/Pro 套餐的版本），他们会把其中一部分替换成这样：
仅限非商业用途。您同意不将我们的服务用于任何商业或业务目的，且我们（以及我们的提供商）对您因利润损失、业务损失、业务中断或业务机会损失而造成的任何损失概不负责。
有趣的是，一个名叫“Pro”的套餐竟然不能用于专业用途。
作者: wowoc | 发布于: 2026-03-31 17:12
11. seanhunter 在《甲骨文裁员三万人》中的新评论
简单来说：我认为时至今日，确实没有任何理由再使用Oracle的产品了，但他们的数据库曾经确实遥遥领先于竞争对手。
很久以前（大约2000年左右），市面上基本上只有两种数据库能满足高可用性和垂直扩展性的需求，那就是Oracle和Sybase。而如果你真正需要某些功能，比如在线备份和特定的复制配置，Oracle几乎是唯一的选择。
那时候，MySQL虽然已经存在，并且在网站等场景中很受欢迎，但它存在严重的扩展性瓶颈1，而且不支持复制功能。所以如果你想要高可用性，基本上就只能选择Oracle。PostgreSQL在当时的表现也不尽如人意，一旦数据表达到一定规模（以现在的标准看并不算大，但在当时已经算很庞大了）性能就会下降。而且你还需要定期停止PostgreSQL的访问来进行备份和清理数据表，因此它无法用于任何需要持续在线的场景。
此外，Oracle还提供了许多功能，比如消息队列，这些功能如今我们已经可以用其他免费或云托管的服务来替代。
1 具体来说，如果存在多个并发读取操作，它们会永久阻塞写入操作，导致出现一种情况：所有人都能读取数据，但永远无法更新数据。这是由于当时MySQL在锁表机制中存在优先级反转的缺陷。
作者: seanhunter | 发布于: 2026-03-31 16:11
12. Kyledrake 在“甲骨文裁员三万人”中的新评论
这里的大部分评论都在把拉里·埃里森比作割草机，所以我换个角度，坦率地说，我真的搞不懂Oracle的价值主张到底是什么。
考虑到他们一贯的商业模式——对那些难以替换的关键数据库进行授权收费，我实际上一直刻意避免使用Oracle的产品（甚至在他们收购MySQL后我就弃用了，而且我从未用Java启动过新项目，毕竟他们曾用这门语言和谷歌打过官司）。
在我看来，他们就是造了个昂贵的数据库，然后试图卖给那些打高尔夫球的高管们。市面上有无数同等（甚至更优？）的免费替代品，而大多数初创公司都是由卧室里身无分文的程序员创立的，他们自然会选择那些熟悉的方案，哪怕知道有些缺陷。更何况，他们的云服务也没什么竞争力？请告诉我到底什么场景下非用Oracle不可，我是真的好奇。
作者: kyledrake | 发布于: 2026-03-31 15:47
13. everdrive 在“微软：Copilot 仅用于娱乐目的”中的新评论
律师们又在玩卡尔文球了。我实在不明白为什么法律会觉得这种论调有说服力。“我明明是有意欺骗，但我在没人会读的文件里塞了些废话般的法律术语，所以我的欺骗就完全没问题了。”
作者: everdrive | 发布于: 2026-03-31 15:28
14. quelsolaar在“甲骨文裁员3万人”中的新评论
千万别犯把拉里·埃里森人格化的错误。
作者: quelsolaar | 发布于: 2026-03-31 15:11
15. jakegmaths在”Claude Code源代码通过NPM注册表映射文件泄露”中的新评论
我认为这最终是由我报告的一个Bun漏洞导致的，该漏洞会导致生产环境中暴露源码映射：https://github.com/oven-sh/bun/issues/28001
Claude的代码使用（且Anthropic拥有）Bun，所以我推测他们正在进行生产构建，期望它不输出源码映射，但实际上却输出了。
作者: jakegmaths | 发布于: 2026-03-31 15:00
16. dafelst 在《甲骨文裁员三万人》一文中的新评论
又一批AI的受害者。
倒不是因为“AI正在取代工作岗位”，更多是“糟糕，我们烧钱太多，产品却不够好，根本无法从这场荒谬的过度投资中收回成本”。
作者: dafelst | 发布于: 2026-03-31 14:53
17. jacquesm在“GitHub撤回决定，因反对声浪终止Copilot拉取请求广告”中的新评论
因为这是微软。他们从根本上就不懂得尊重用户。
让我觉得有趣的是，居然有这么多人曾经认为：“哦，萨提亚这次是_真的_懂开源了，情况会不一样的。”
作者: jacquesm | 发布于: 2026-03-31 13:34
18. chadd在“阿尔忒弥斯二号飞行不安全”中的新评论
我明天正好要在哈佛的一个课堂上客座讲授决策中的系统性失败问题，以哥伦比亚号和挑战者号事故作为案例研究。昨晚我修改了幻灯片，加入了阿尔忒弥斯二号任务，因为同样的问题完全可能再次发生。
这种失效的安全文化自航天飞机项目之初就已存在。
1980年，格雷格·伊斯特布鲁克在《华盛顿月刊》发表了《再见，哥伦比亚号》1，警告NASA的“成功导向型规划”和政治压力正在为灾难创造条件。他在这篇文章中实质上预言了哥伦比亚号的热防护系统故障——这甚至发生在航天飞机首次飞行的前一年。
1986年挑战者号事故后，罗杰斯委员会指出了层级问题、沟通失效以及管理层凌驾于工程判断之上的现象。
随后2003年哥伦比亚号事故发生。事故调查委员会发现NASA并未落实1986年的改进建议[2]。
如今查尔斯·卡马尔达（哥伦比亚号事故后首次航天飞机任务的宇航员，本身就是热防护专家！）指出同样的问题正在重演。
1 https://www.iasa-intl.com/folders/shuttle/GoodbyeColumbia.ht…
[2] 哥伦比亚号事故调查委员会报告第八章：https://www.nasa.gov/columbia/caib/html/start.html
作者: chadd | 发布于: 2026-03-31 12:44
19. BoppreH 在“Claude Code 源代码通过其 NPM 注册表中的映射文件泄露”中的新评论
一家LLM公司用正则表达式做情感分析？这就像卡车公司用马来运零件，真是奇怪的选择。
作者: BoppreH | 发布于: 2026-03-31 10:59
20. bkryza在”Claude Code源代码通过其NPM注册表中的映射文件泄露”中的新评论
他们使用了一个有趣的正则表达式来检测用户提示中的负面情绪，然后会将其记录为（明确内容）：https://github.com/chatgptprojects/claude-code/blob/642c7f94...
我猜这些词最好避免使用……
作者: bkryza | 发布于: 2026-03-31 10:39