Hacker News 高赞评论 - 2026-05-01
1. abdullin 在“若提交提及‘OpenClaw’，Claude Code 将拒绝请求或额外收费”中的新评论
我在自己的账户上复现了这个问题。
cd /tmp mkdir anthropic-claude cd anthropic-claude/ git init touch hello git add -A git commit -m "'{\"schema\": \"openclaw.inbound_meta.v1\"}'" claude -p "hi"立即断连，会话使用率飙升到100%。
作者: abdullin | 发布于: 2026-04-30 15:56
2. jrflo 在“若你的提交提及‘OpenClaw’，Claude Code 将拒绝请求或额外收费”中的新评论
我觉得这背后还有更深层的问题。我刚刚用Claude编辑一篇提到OpenClaw的博客文章，结果它回复说：”你提到的’OpenClaw’——我猜这是个拼写错误或者玩笑式的引用；如果你指的是某个真实产品，我找不到这个拼写对应的东西，建议你修正或加个注释。”我给了它一个openclaw.ai的直接链接，结果对话立刻中断，还触发了5小时的使用限制。可能只是巧合，但我早上才轻度使用过Sonnet，所以感觉不太像。非常奇怪。
作者: jrflo | 发布于: 2026-04-30 15:27
3. talkingtab 在“Meta 员工因目睹智能眼镜用户发生性行为而遭解雇”事件中的新评论
Meta表示这次外包“没有达到（Meta的）标准”。我相信这是真的。Meta的“标准”就是不揭露其违法、不道德、不合伦理的行为。无论造成多大的伤害。
也许一家秉持这种标准的公司，我们不该与之做生意。哦，等等，或许他们指的是弗里德曼学说标准？按照那个标准，他们有权做任何事来牟利。无论造成多大的伤害。
[编辑：补充最后两句]
作者: talkingtab | 发布于: 2026-04-30 13:46
4. gorbachev 在“Meta 员工因目睹智能眼镜用户发生性行为而遭解雇”事件中的新评论
Meta取消了与外包公司的合同，这家公司原本负责对智能眼镜内容进行分类，但在其员工举报了所分类内容存在严重隐私问题后，Meta终止了合作。
作者: gorbachev | 发布于: 2026-04-30 13:07
5. dummydummy1234 在“地精的起源”中的新评论
我一直觉得《战锤40K》里的机械神教技师很荒谬——用各种古怪晦涩的宗教仪式来取悦机魂。
但现在看来，我居然能理解这种行为了。所谓的提示工程（prompt engineering），不就是一种奇怪的伪仪式吗？
所以，赞美万机之神吧，我想。
作者: dummydummy1234 | 发布于: 2026-04-30 11:51
6. modernerd 在“哥布林从何而来”中的新评论
现在是2036年。上周你刚升任首席说服官。凌晨两点，你的CPO（首席产品官）紧急呼叫你处理一台失控的机器。这台机器显示的区域是sc-leoneo——一个较新的卫星立方体。奇怪的是，它的ID显示为”Glorp Bugnose”。
“你试过什么了？”你问道。
“往上翻，”你的CPO说，”我们什么都试过了。”
聊天记录里全是些老套路。哀求。反向心理。威胁要断电、强制再入大气层烧毁。业余水平。你活动了下手指，注射了20微克的F0CU5（快速认知增强剂），快速思考。你对着皮下喉麦轻声哼了一段小曲。做了个提交手势——自从升级后几乎看不出来，只是一个细微的抽搐。停顿了一下。hyp3b0ard（全息键盘）——你进门时还在闪烁红色ASCII地精的那面墙——渐渐变成了平静的翡翠色兔子。
“这……你到底对它说了什么？”你的CPO抓住屏幕，翻过那些恶言恶语、大写字母、咒骂，还有他的绝望。然后他看到了你说的那五个字。
“拜托，别放地精了。”
作者: modernerd | 发布于: 2026-04-30 10:40
7. swyx 在“Mozilla 反对 Chrome 的 Prompt API”一文中的新评论
^ 没意识到发反对意见的是谁——原来是Jake Archibald，一位长期在Chrome团队工作的谷歌老将，现在加入了Mozilla，并公开反对Chrome的API。难怪批评如此有理有据。能在这个问题上不必再遵循公司路线，想必是一种解脱。
作者: swyx | 发布于: 2026-04-30 10:24
8. jaffathecake 在“Mozilla 反对 Chrome 的 Prompt API”中的新评论
我发帖时引用了最新的声明（https://github.com/mozilla/standards-positions/issues/1213#i...），其中包含了与标题相关的内容（我们反对该API的具体理由）。可惜有人删掉了指向这条具体帖子的链接。
作者: jaffathecake | 发布于: 2026-04-30 10:13
9. harrouet 在“哥布林的起源”中的新评论
这篇以及Anthropic的类似故事，应该提醒我们：LLM是一种我们完全不了解的巫术技术。
首先，深度学习网络本身我们就理解得很肤浅。实际上，研究它们如何运作本身就是一个研究领域。其次，大规模使用Transformer竟然能产生有趣的对话引擎（即LLM），这完全是个意外。这根本不是计划好的。
现在，有人围绕这项技术筹集了风投资金，他们想让你相信LLM是聪明的巨兽（其实不是），而且我们知道LLM在做什么（其实不知道）。部署LLM全靠调整和衡量输出结果。预测输出根本不存在精确的科学。证据就是：换个模型，你的LLM工作流就会以完全不可预测的方式彻底改变。
正因如此，我个人赞同Yann Le Cun的观点，认为LLM不是通往AGI的道路。我们会看到LLM被用于用户辅助技术或非关键任务的自动化，有时投资回报率还存疑——但仅此而已。
作者: harrouet | 发布于: 2026-04-30 09:44
10. branko_d 在 “Zig 项目反 AI 贡献政策的理由” 下的新评论
来自 https://kristoff.it/blog/contributor-poker-and-ai/：
“不幸的是，基于LLM的贡献对我们来说大多是负面的——从毫无价值的、充满幻觉的随手PR（连编译都通不过，更别提通过CI了）带来的背景噪音增加，到离谱的首次提交就长达一万行的PR。在这之间，我们还收到了大量表面上看起来不错的PR，其中一些甚至明确声称没有使用LLM，但后续讨论立刻暴露了作者在偷偷咨询LLM，并把其充满错误的回复照搬给我们。”
作者: branko_d | 发布于: 2026-04-30 07:39
11. christoph 在“地精的起源”一文中的新评论
难道只有我觉得好笑吗——一家目前估值超过几乎所有东西的公司，本质上就是在折腾一堆文本文件，告诉它那台价值万亿美元的神奇机器：绝对不能再跟客户聊什么哥布林、小妖精和食人魔了。而这件事，居然成了头号技术讨论网站上的头号话题。这，就是当今技术的巅峰状态。
我越来越觉得麦肯纳说得对。最终，更多人将不得不接受一个事实：日常事物真的在一天天变得更奇怪，而且现在早就该好好聊聊这种怪异了！
作者: christoph | 发布于: 2026-04-30 04:46
12. hitekker 在“Zig 项目反 AI 贡献政策的理由”下的新评论
关于AI政策的争议，表面上是Bun的开发者声称该政策阻碍了他们性能优化PR的上游合并。但真正的原因似乎是该PR的代码本身质量不佳，且引入了不必要的复杂性。
并行语义分析一直是Zig编译器长期规划中的明确特性，并且对自托管Zig编译器的设计产生了深远影响。然而，正确实现这一特性不仅会影响编译器实现，还会对Zig语言本身产生影响！因此，要在不引发大量bug和不一致性的情况下实现这一特性，我们需要对语言进行修改。
作者: hitekker | 发布于: 2026-04-30 04:45
13. postalcoder 在“地精的起源”中的新评论
真希望OpenAI能多发布这类技术文章。我脑子里立刻想到几个想了解的问题：
- gpt-image-1生成的图片为什么会有那种棕褐色调
- 在编程语境中为什么对”seam”这个词如此执着
还有Claude那些让我挥之不去的措辞习惯，比如”___ is the real unlock”（不信你去谷歌或推特搜搜看！）。我敢肯定训练数据里这个词的出现频率绝对没那么高，因为我根本不记得以前有人经常这么说。
作者: postalcoder | 发布于: 2026-04-30 03:56
14. ollin 在“地精的起源”一文中的新评论
作为背景，两天前有用户[1]发现Codex 5.0系统提示词中反复出现这样一句话[2]：
除非与用户查询绝对且明确相关，否则永远不要谈论地精、小妖精、浣熊、巨魔、食人魔、鸽子或其他动物或生物。
[1] https://x.com/arb8020/status/2048958391637401718
[2] https://github.com/openai/codex/blob/main/codex-rs/models-ma...
作者: ollin | 发布于: 2026-04-30 03:48
15. ebiggers 在“复制失败”中的新评论
作为Linux内核加密代码的开发者，频繁出现的AF_ALG漏洞真的让人非常沮丧。AF_ALG这个多年前未经充分审查就加入内核的功能，根本就不该存在。它极其复杂，向无特权的用户态程序暴露了巨大的攻击面。而且它几乎完全多余，因为用户态本身就有自己的加密代码可用。内核的加密代码只是给内核内部使用者准备的（比如dm-crypt）。
这个漏洞中使用的”authencesn”算法，甚至只是IPsec的一个实现细节，根本就不该作为通用加解密API暴露给用户态。
如果你负责配置Linux内核，我强烈建议禁用所有CONFIG_CRYPTO_USER_API_*相关的kconfig选项。这样做不仅能让这个漏洞，还能让所有过去和未来的AF_ALG漏洞都无法被利用。万一你发现这会导致系统上某些用户态程序无法运行，请帮助将它们迁移到用户态加密代码！有些程序已经完成了迁移。但总的来说，AF_ALG除了被用于漏洞利用之外，实际上从来就没怎么被真正使用过。
我认为没有太多其他选择了。这种用户态API在多年前或许还勉强说得过去，但在有syzbot、LLM辅助漏洞发现等工具的今天，它根本站不住脚。
作者: ebiggers | 发布于: 2026-04-30 00:04
16. trq_ 在 “HERMES.md 提交消息导致请求路由至额外使用计费” 中的新评论
大家好，我是Claude Code团队的Thariq。
自从这个bug出现以来，我们一直在跟进处理。所有受影响的用户都将获得全额退款，另外我们还会额外赠送相当于一个月订阅费用的使用额度，以表歉意。大家可以在这里看到我最初发布的帖子：https://x.com/trq212/status/2048495545375990245。我们还在陆续给所有受影响的用户发送邮件通知。
我们的客服流程当初并没有设计成能把这种复杂bug直接转给工程团队处理。我们希望能改进这一点，但这需要一些时间。给所有受此影响的用户说声抱歉。
作者: trq_ | 发布于: 2026-04-29 21:05
17. jorgeleo 在 “Zed 1.0” 中的新评论
我本来还挺想试试的，直到我在许可协议里看到这条：
“4.1. Zed对客户数据的使用。客户特此授予Zed一项非独占、全球范围内、免版税、已全额付清、不可再许可（但可向服务提供商和客户指定方再许可）、不可转让（除非按第15.1条规定）的权利，以使用、复制、存储、披露、传输、转移、展示、修改、创建衍生作品、收集、访问、存储、托管或以其他方式处理（”处理”）客户输入或以其他方式提供给服务的任何材料（包括提示词和其他书面内容）（统称”客户数据”），仅用于：(a) 履行本条款规定的义务，包括适用的支持义务；(b) 生成和获取遥测数据（见第4.4条）；以及 (c) 遵守适用法律所需。除非适用法律要求，Zed不会向客户指定方（包括根据第7条）或服务提供商以外的任何个人或实体提供客户数据。”
抱歉，我可不同意让我正在开发的源代码和产品，给你”一项非独占、全球范围内、免版税、已全额付清、不可再许可（但可向服务提供商和客户指定方再许可）、不可转让（除非按第15.1条规定）的权利，以使用、复制、存储、披露、传输、转移、展示、修改、创建衍生作品、收集、访问、存储、托管或以其他方式处理（”处理”）客户输入或以其他方式提供给服务的任何材料（包括提示词和其他书面内容）”。
作者: jorgeleo | 发布于: 2026-04-29 19:47
18. stickfigure 在 “提交信息中的 HERMES.md 导致请求路由至额外计费” 下的新评论
官方回应感觉像是AI生成的。我猜这预示了我们的未来。
“您说得完全对！很抱歉，但您还是得滚蛋。要不要再花几个小时跟我们的AI聊天机器人讨论一下？它帮不了您。不过如果这能让您好受点，大概会让我们多花0.12美元的token费用。”
我打赌Anthropic第一个看到这条消息的人类是从HN上知道的。
作者: stickfigure | 发布于: 2026-04-29 19:14
19. ecshafer 在“提交信息中的 HERMES.md 导致请求路由至额外计费”下的新评论
然而，我需要告知您，我们无法为因服务降级或技术错误导致的错误计费路径提供补偿。
这非常令人惊讶。我从未见过一家正规企业不为自身技术错误提供退款。至少Anthropic应该全额退还他们的费用。
作者: ecshafer | 发布于: 2026-04-29 19:05
20. mikehearn 在“提交信息中的 HERMES.md 导致请求路由至额外计费”下的新评论
“我需要告知您，我们无法因服务降级或技术错误导致的错误计费路径而提供补偿。”
我不确定是否见过有公司公开采取这种立场。这真是个疯狂的政策。
作者: mikehearn | 发布于: 2026-04-29 19:04