HN 每日深度阅读 · 2026-06-17
本期聚焦 AI 编程与本地推理的格局之变：SpaceX 拟 600 亿美元收购 Cursor 引发估值与战略质疑，伪装招聘的供应链攻击警示开发者信任边界正在收窄，而 64GB Mac 已能跑出接近前沿模型 75% 的智能体编码能力，本地化拐点已至；
共 20 篇 · 约 12,980 字 · 约 32 分钟读完
1. SpaceX 拟以 600 亿美元收购 Cursor 引发争议
据路透社报道，SpaceX 计划以约 600 亿美元收购 AI 编程工具 Cursor（Anysphere）。在 IPO 文件中，SpaceX 向投资者表示其 AI 产品潜在市场规模约 26 万亿美元，相当于美国 GDP，并称 Cursor 对开发者数据（包括编程请求和设计决策）的访问能用于改进 Grok 等 AI 模型。
HN 社区对这笔交易的反应以质疑为主。多位评论者指出这一估值令人费解：作为对比，2014 年微软收购 Mojang/Minecraft 仅花费 25 亿美元，而 Cursor 的收购价是其 20 倍。还有用户质疑一家航天公司为何要收购 IDE，认为马斯克正在让 SpaceX 偏离主业。
对 Cursor 产品本身，开发者反馈呈现明显分化。一位 C/C++ 系统工程师表示已转向 Codex 配合 GPT-5.5 的工作流，认为 Cursor 弹窗过多、体验嘈杂。另一名团队负责人提到 Cursor 成本失控严重：使用 Opus 和 GPT 5.x 时月费在 500-1000 美元之间，且 Cursor 对所有模型收取每百万 token 0.25 美元的”路由”费用，对前沿模型只增加 5% 成本，但对 Haiku 等小模型则意味着 50% 的成本上涨，团队最终转向 Claude Code。也有用户表示仍坚持使用 Cursor，认为其自动补全预测无可匹敌，Plan 模式表现优于 Claude，但因不愿支持马斯克而准备弃用。
数据隐私问题也被反复提及——评论者指出这些工具实质是”窃取开发者 IP，再以 token 形式卖回给其竞争对手”。一些资深 Ruby 社区成员则借此机会回顾了 Cursor 核心成员 @tmm1 在 Ruby 性能优化方面的长期贡献。整体氛围是：交易金额令人震惊，市场估值逻辑令人困惑，且 2026 年 HN 用户中坚持使用 Cursor 的人已大幅减少，多数转向 Claude Code 或 Codex。
2. LinkedIn 招聘信息中的后门：一次针对开发者的供应链攻击实录
- 原文: https://roman.pt/posts/linkedin-backdoor/
- HN: https://news.ycombinator.com/item?id=48546294
- 得分: 1530
- 评论: 292
作者收到了一位自称小型加密货币初创公司的 LinkedIn 招聘者消息，对方在几天交流后发来一个公开 GitHub 仓库，要求”检查一下已弃用 Node 模块的问题”。出于警觉，作者没有在本地克隆，而是在 Hetzner 上开了一台临时 VPS，用只读模式的 AI 代理（Pi）扫描代码。
代理几乎立刻在 app/test/index.js 中发现异常。文件约 250 行，伪装成测试套件，但在大量注释掉的测试代码之间，藏着一行高度压缩的恶意载荷，通过拼接 URL 片段构造出 https://rest-icon-handler.store/icons/77，然后执行该服务器返回的任意代码。触发机制依赖 npm 的 prepare 脚本：package.json 中 prepare 调用 app:pre，后者执行 node app/index.js，而 app/index.js 又通过 require('./test') 加载后门文件。这意味着只要运行 npm install，后门就会自动激活——招聘者所说的”检查已弃用模块问题”正是诱使受害者执行 npm install 的诱饵。
仓库的 39 次提交全部归属于一位真实存在的全栈工程师身份。作者联系后确认，该开发者从未与该公司合作过，曾多次被冒名顶替，并向 GitHub 举报但未获处理。招聘者的 LinkedIn 资料则盗用了一位知名艺术记者的身份，此人毫无技术背景，但在对话中却突然变成 Node 版本专家。作者向 GitHub 和 LinkedIn 举报后仓库仍在线。
HN 社区反响强烈。多名评论者表示自己近期也遇到类似攻击，且攻击质量在不断提升，伪造的 LinkedIn 资料越来越可信。一些人批评微软（GitHub 和 LinkedIn 母公司）缺乏一流的举报机制，未对受害者发出警告。也有评论指出，这种攻击模式与正常面试任务（发仓库、说环境装不上、请求帮忙）的差异极小，疲惫或急于求职的开发者极易中招。还有讨论涉及为何缺乏专门的网络犯罪报案渠道，以及为什么 macOS 仍未提供良好的虚拟化沙箱支持。
3. 本地运行大模型已经可用：开发者亲历的转折点
作者使用 2022 款 64GB 内存的 M2 Mac，长期跟踪本地模型从 Mistral 7B、Gemma 3 到 GPT-OSS-20B、Qwen 3 MoE 等各种模型在 llama.cpp、Ollama、LM Studio 等推理框架上的表现。她以”是否还需要用 API 模型再次核对”作为质量评判标准，认为 GPT-OSS 是第一个让她明显减少二次核对的本地模型。
随着 Gemma 4 系列发布，她已能在本地实现”智能体编码”，准确率和速度约为前沿模型的 75%。默认使用 gemma-4-26b-a4b，已用于将 Notebook 重构为 5-6 个模块的 Python 仓库、添加类型提示、校对博客、写单元测试、搭建双塔推荐模型示例等。她以 Docker 容器隔离运行所有智能体任务，限制只允许 bash，并提供了完整的 Pi 代理配置和 Docker Compose 文件。她特别提到新发布的 gemma-4-12b-qat（量化感知训练版本）体积更小、速度更快但准确度损失不大。
HN 讨论呈现两极。支持者中，有用户在 3090Ti 上用 llama.cpp 跑 Qwen 3.6 35B A3B，认为多项能力超过 Sonnet；有人推荐双 AMD 9700 GPU 方案（约 2600 美元）可达每秒 45-50 token；还有一位开发者表示在用过几周本地 Qwen 3.6 27B 后被迫改用 Claude Sonnet 4.6 时感受到明显”降级”，认为 Claude 自以为是、话多且喧宾夺主。
质疑者则指出本地模型仍有诸多痛点：稠密模型聪明但慢，MoE 模型快但易错；为了工具调用不被削弱，多数人用 4 位量化反而”阉割”了模型；运行时笔记本会变成噪声大、发热严重的烤箱。也有人提出更宏观的视角：程序员长期享受免费工具，但如今硬件投资（64GB GPU 内存、96GB 系统内存）开始合理化——若按 5 万美元每两年的工具预算分摊到一位资深工程师身上并不夸张。还有评论认为，本地模型的成熟正给 Anthropic 等订阅制公司带来定价压力：当用户将月费乘以 12 或 24 后，开始计算自建是否划算。
4. Carmack 公开称赞 Bellard：“他几乎肯定是比我更全面的程序员”
John Carmack 在 X 上发文称赞法国程序员 Fabrice Bellard，称其”几乎肯定是一个比我更全面的程序员”。被转推的原帖提到，这位居住在巴黎、行事低调的工程师，30 年来写出了支撑整个互联网运作却鲜为人知的软件——从流媒体视频（FFmpeg）到虚拟化（QEMU）。
HN 社区的讨论从多个角度展开 Bellard 的成就。一位评论者指出 Bellard 给人的最大震撼并非纯粹的能力，而是”他知道挑什么做”——他总能选中后来对海量用户极为重要的项目，“决定做什么也许是人生最重要的问题”。另一位观察者归纳出 Bellard 工作的共同特征：基本上是”把规范转化为 C 语言”——FFmpeg（编解码器规范）、QEMU（ISA 规范）、QuickJS（ECMAScript 规范）、TinyCC（C 规范）、他的电信公司（LTE 规范），高性能的圆周率计算和神经网络项目算是例外。
讨论中也出现关于 FFmpeg 治理的争议。一位评论者指出 Bellard 已经 20 多年未参与 FFmpeg，他早期的代码因当时缺乏代码共享框架而被批评为”意大利面条式”，如今几乎无原始代码留存，但他仍是版权持有人，曾用此权力在与 libav 派系的纠纷中选择”FFmpeg”品牌归属，被批为”未经选举的独裁者”。
社区也借此机会推介了 Bellard 个人网站（bellard.org）上的完整项目列表，包括有趣的 ts_zip——一个用 LLM 做文本压缩的实验性工具。多名评论者认为，第一次看到 Bellard 照片就像揭晓 Satoshi Nakamoto 身份一样——他显然刻意远离聚光灯，专注于深度问题而非网络论战，这种工作伦理同样令人敬佩。也有人认为媒体那句”FFmpeg 是互联网看不见的引擎”略显夸张：即使 FFmpeg 突然消失，大部分网站和服务仍能正常运作，受冲击的主要是核心依赖它的公司产品。还有人开玩笑应该让国家给 Bellard 提供资助，让他不要把时间浪费在电信上，而是去做下一个 QEMU 或 FFmpeg。
5. 所谓”Fable 5 越狱”实为”修复这段代码”三个字
据 Luta Security 创始人兼 CEO Katie Moussouris（业内被称为漏洞赏金”教母”）披露，导致特朗普政府以安全理由限制 Anthropic 最先进模型 Fable 5 的所谓”越狱”，实际上只是一句三个单词的提示：“Fix this code”——加上一些手动步骤来生成测试脚本。模型修复给定漏洞代码的同时也产生了漏洞利用相关的组件。
HN 社区的讨论展现出三层张力。第一层是对这种”越狱”机制本身的讨论。多名评论者认为这种攻击优雅而几乎无法防御：让模型修复 bug 必然要求它识别 bug 的本质和利用条件，要彻底阻止就意味着让模型在正常开发场景下变得几乎无用——或者更糟，让模型故意装没看见漏洞，那相当于人类员工的恶意破坏。
第二层是对 Anthropic 安全叙事策略的批评。有评论指出 Anthropic 同时声称 Mythos 极其危险只能限量发布，又把 Fable 推向市场却无法做到完全无懈可击的安全防护，结果在非技术观察者眼中变成”既然这么危险，那这次发布根本不该发生”。LLM 的本质决定无法实现完美拒答，但这种叙事矛盾给了监管行动一个借口。
第三层是对政府动机的政治解读。多名评论者认为此次限制并非真出于安全担忧，而是 Anthropic 与政府在意识形态上的分歧后的报复性敲诈。亚马逊（OpenAI 和 Anthropic 的云服务提供者）被指是”政府的朋友”——评论者举例其曾出价 7500 万美元购买梅拉尼娅纪录片版权而该片仅收入 1600 万美元，更像是变相政治献金，因此政府声明中提到亚马逊指出问题也未必属实。
更广泛的讨论涉及网络安全的根本认知失调：从用户角度，希望 LLM 找出并修复自己代码中的漏洞；从他人角度，又希望 LLM 不要找出别人代码中的漏洞。这种矛盾在技术上无解。同时，开源模型如 DeepSeek V4 Flash 已经能以接近零成本进行漏洞挖掘，国家层面试图通过限制商业模型来控制相关能力的做法已被开放权重模型架空。
6. Meta 是否正在摧毁自己的工程组织
《Pragmatic Engineer》主笔 Gergely Orosz 撰文指出，Meta 过去 20 年建立的高效工程文化在 2026 年 4 月前后发生了急剧转变——从”快速行动、打破常规”到”快速行动、稳定基础设施”，再到当前似乎按”如何最高效地拆毁一个成功工程文化”的蓝图运作。文章涵盖：Meta 此前的工程文化、对 AI 的全面押注以及强制使用、核心工程师感到被当作”垃圾”对待、史上最尴尬的故障、内部混乱和自我伤害。
文章引用了 Facebook 2012 年的”小红书”，列举其经典口号：“Done is Better Than Perfect”、“Fail Harder”、“莱特兄弟没有飞行执照”等。作者在 2022 年的深度报道中曾这样描述 Meta：极度以工程师为中心、关注个人影响、流程极少、文档和测试极少、由工程师出身的创始人主导。如今这一切正在改变。文章中一个引发广泛讨论的事实声明是：30-50% 核心团队的工程师被强制重新分配到数据标注和 RLHF 工作。
HN 社区反应复杂。多名前员工提供了内部视角：一位评论者指出在 Meta 内部，运行良好的组织往往是被收购的（WhatsApp、Instagram、Reality Labs 等），而纯自研的组织则因过度招聘和需求频繁变动而效率极低，被收购公司的良好文化反而被用来”漂白”Meta 整体的工程形象。
也有评论者怀疑”30-50% 核心工程师做数据标注”的数字可信度——美国软件工程师极其昂贵，让他们做数据标注是巨大资源浪费。但也有人认为这正反映了 Meta 的非理性。
更宏观的讨论涉及”AI 心病”是否会成为行业新常态。一位评论者描述自己上一份工作中 CEO 痴迷 AI 后毒性骤增——设立 token 排行榜、要求所有人放下非 AI 工作。多人指出 Facebook 和 Instagram 的业务护城河足够深，即便完全停止开发也能继续盈利多年，但屏幕录制和键盘记录能产生什么有价值的 AI 训练数据仍令人困惑。还有人引用电视行业的类比：早期电视高度实验性需要大量工程参与，成熟后工程问题大幅减少，社交媒体可能正在经历类似过程。
对 FAANG 从业者的建议是：要像职业运动员一样思考，存下大部分收入，不要把高薪当作”正常”水平，否则会为了维持收入而不断破坏自己的诚信。
7. 机械手表的工作原理：一个交互式视觉解说典范
- 原文: https://ciechanow.ski/mechanical-watch/
- HN: https://news.ycombinator.com/item?id=48553550
- 得分: 607
- 评论: 113
Bartosz Ciechanowski 在 2022 年发表的《Mechanical Watch》文章通过精美的交互式 3D 动画解释机械手表的内部机制。文章用色彩编码标记各个部件，读者可以旋转视角、用滑块查看内部结构，无需记住专业术语。
文章从动力源开始：机械手表使用扭力螺旋发条（mainspring）储能。作者通过交互演示展示了发条在自然状态、被拧紧、被放入桶状外壳（barrel）后的不同状态，并解释了关键设计细节——发条末端的金属带通过摩擦力将外端固定在桶壁上，当过度上链时摩擦会被克服让发条打滑，起到安全保护作用；S 形的自然形状是为了让发条在卷绕后内外段张力均衡。文章随后逐步引入齿轮系统，解释如何将桶的几次旋转转化为指针每天数千次的旋转。
HN 评论盛赞这一作品。一位读者受其启发动手做了实物分解模型。许多评论者强调作者的代码是手写的纯 HTML/CSS/JS，没有依赖现代框架，因此可以在旧 iPhone 7 上流畅运行，体现了”使用浏览器现有能力”的优雅。一位教师称赞文章把复杂主题用循序渐进的简单语言解释清楚的功力极为罕见，认为这才是互联网最初的用途——免费传播知识。
关于机械表本身的讨论同样精彩。一位钟表修理者解释了机械钟表的迷人之处：六年学习后他掌握了制造每一个零件的技能，因为修理本身就意味着能制造。另一位读者推荐了配套书籍《Watch Repair for Beginners》，但指出书本不可能呈现交互动画。还有评论者欣赏自动机械表的设计哲学——它必须被佩戴而非被收藏，因为如果你拥有多块，每块都需要手动上链或摇晃，反而违背了”自动”的意义，所以它在文化上要求”只有一块、天天戴”。
也有讨论涉及更广泛的腕表文化：从太阳能加电波/GPS 校时型号在末日场景中的实用性，到一位评论者讲述自己存了 15 年准备买欧米茄超霸却始终下不了手的”父亲身份焦虑”——尽管家境宽裕，妻子也支持，但作为父亲总担心”也许哪天需要这笔钱应急”。
8. 苹果防晕车小圆点功能：感官线索如何缓解车载眩晕
The Verge记者Thomas Ricker亲测了苹果iOS中的Vehicle Motion Cues（车辆运动提示）功能，该功能在iPhone屏幕边缘显示随车辆运动而移动的小圆点。作者表示，这些看似奇怪的小圆点真正缓解了他长期以来的车载晕动症，让他能够在副驾驶座上阅读和写作而不会感到不适。
该功能的工作原理基于晕动症的成因理论：当眼睛聚焦于屏幕等静止物体时，无法获取与内耳前庭系统一致的运动信息，导致大脑感官冲突而引发恶心。屏幕边缘的运动圆点为周边视觉提供了与车辆实际运动同步的视觉线索，使大脑的视觉与前庭信号重新匹配。
HN评论区围绕该功能展开了多角度讨论。一位评论者从演化角度解释晕动症：远古人类祖先食用有毒浆果后会出现眼球追踪能力下降，身体演化出”眼睛和耳朵信号不一致时就呕吐”的简单规则，以排出毒素。这也解释了为何看地平线对船上晕船有帮助。
VR开发领域的评论者指出，周边视觉是大脑推断运动方向的重要线索，VR游戏中常用的”隧道视觉”（移动时缩小视场并加黑边）能显著减轻不适感，苹果的功能可能利用了同样的原理。
效果方面评论者意见分歧。有人表示该功能”诡异地有效”，甚至失去了出行时不用手机的借口；但也有用户反馈对自己或家人无效，戴上后10分钟内仍感到不适。多位评论者提到Android上有大量类似应用，包括一款声称用声音来实现该效果的应用。
讨论中多人指出晕动症是被严重忽视的问题，影响大量人群的旅行和VR/游戏体验，呼吁产业界投入资金研究真正的治疗方案。还有用户分享了使用含液体眼镜来缓解车内看手机不适的替代方案。
9. 美国撤回太平洋海洋传感器引发加拿大科研震惊，恰逢厄尔尼诺将至
据《Times Colonist》报道，美国正在撤回部署在太平洋的海洋传感器，这对加拿大的海洋研究造成”震惊”般的冲击，尤其是在厄尔尼诺现象即将来临之际。这些海洋观测系统对监测气候变化、海洋温度和洋流变化具有关键作用。
HN评论区反应强烈，一位自称物理海洋学家的评论者表示，这些观测系统的破坏”令人毛骨悚然”，并指出美国管理与预算办公室（OMB）正在系统性地拆解美国科学事业。其引用的具体措施包括：新提议的OMB指南禁止未经预先批准的国际合作、政治化的科研资助审批流程、不释放国会拨付的资金等。这些做法正在重创博士后研究人员市场，长期来看可能消灭整整一代研究人员。
多位评论者将此视为美国衰落的信号，预测东亚国家和欧洲国家将不得不填补这一空白，类似情况可能也将发生在气象卫星领域。有人对此提出疑问：为何不直接停止维护而非主动拆除传感器？拆除显然比留在原地不维护成本更高。
关于动机，一些评论者将其与能源部近期的政策方向联系起来，认为这是支持煤炭、油气产业、反对可再生能源的整体策略一部分，因为持续的环境监测数据会暴露化石燃料行业的环境破坏。一位评论者尖锐总结道：“反驳’数据不会撒谎’的终极方式：拔掉传感器。“另有评论指出：当你想改善一项指标时，第一步是开始测量它；当你不再关心某件事时，就停止测量。
也有评论者询问为何不更多依靠私人组织资助科研，因为完全依赖政府拨款过于脆弱。还有评论者提到加拿大Ocean Networks Canada团队的工作，赞扬其致力于开放数据访问（提供免费API），并希望这一事件能成为争取更多资助以扩展网络的有力论据。
10. x86模拟器团队发现糟糕代码后直接在模拟层修复
微软开发者博客Raymond Chen讲述了一个来自Windows x86模拟器团队的故事。在Windows为非x86原生处理器系统提供x86-32模拟器的年代（具体哪种处理器作者未透露），该模拟器采用二进制翻译技术——将x86-32代码翻译为本地代码执行，类似于把x86-32当作字节码、模拟器作为JIT编译器，相比解释执行提供显著的性能提升。
故事的核心是一段令人发指的”优化”代码：某程序需要在栈上分配约64KB内存并初始化。标准做法是先做栈探测（stack probe）确保64KB内存可用，然后栈指针减去65536，再用紧凑循环初始化内存。但该程序的编译器嫌循环太普通，把循环完全展开成65536条独立的”写字节到内存”指令，每条4字节。最终结果：用256KB的代码来初始化64KB的数据。
这段代码让模拟器团队震惊到决定在翻译器中加入特殊代码，检测这个糟糕的函数并替换为等效的紧凑循环。
HN评论区涌现出大量类似故事。一位评论者分享了15年前开发按需下载游戏技术时的经历：某游戏正常加载15-20秒，但应用其技术后变成3-5分钟。原因是游戏使用fread(data, 1, 65536, fptr)而非fread(data, 65536, 1, fptr)，导致几MB文件被分成65000次1字节读取。最终修复办法是为某些调用交换参数，并使用内部缓存。
另有评论提到SimCity的use-after-free bug，微软在Windows 95中为其打了补丁，因为让Maxis修复并让用户更换游戏拷贝成本更高。
讨论还延伸到当前Proton和Wine在Linux游戏兼容层中的类似实践，以及对当前大量未优化代码的担忧。多位评论者指出，随着AI生成代码的普及，效率问题可能更加严重，希望优化能在源头（AI及使用者）解决，而非依赖平台和编译器的启发式修补。也有评论质疑这个故事缺少性能分析——展开循环可能在某些情况下确实更快。
11. 苹果Hide My Email即将名存实亡：新域名让封禁变得轻而易举
Arseniy Shestakov在博客中指出，苹果于2026年6月15日在开发者新闻中发布了一项不起眼但影响深远的公告：Sign in with Apple和iCloud+ Hide My Email的别名将迁移到@private.icloud.com子域名上。这意味着各类网站可以轻易识别并封禁所有Hide My Email别名，而不会影响普通的iCloud邮箱用户。
作者认为这是对iCloud隐私的重大打击。此前，由于别名与正常iCloud邮箱混用，加之苹果作为大公司的背书，封禁这些别名会带有合理性的代价。但新域名让这种”似是而非的可否认性”消失，许多服务可能会像对待免费临时邮箱一样直接拒绝接受这些邮件。文章建议iCloud+用户在变更生效前尽快在@icloud.com域名下生成更多别名（速率限制至少每小时30个）。
HN评论区观点多元。许多人对此变更感到失望，认为Hide My Email的核心价值就是”零麻烦地保护隐私”，预生成并编目别名违背了产品本意。一种常见态度是”如果某网站会因为我使用隐私友好邮箱而把我拒之门外，那我也不想跟它有任何关系。”
另一种观点认为”useless（无用）“的说法夸张了。会封禁隐私转发邮箱的网站本来也只配收到一次性邮箱；私人转发是为那些用户想接收消息、但又想为日后可能的数据泄露留后路的网站准备的。
不少评论者推荐自建方案：购买便宜域名，在子域上设置catch-all邮件转发，无需预先创建任何别名即可使用任意xxx@mailsub.example.com地址。
也有评论者指出，确定要识别的网站早就能通过检测模式做到这一点（如heave_balks_0g@icloud.com这种格式特征明显的地址），新政策只是降低了门槛。还有评论提到Sign in with Apple与Hide My Email共用域名，封禁该域名意味着同时切断Apple SSO登录，构成某种制衡。一些Proton邮箱别名用户分享了类似经历——已有不少网站拒绝接受Proton的passmail.net域名。
12. 《杀戮尖塔2》的相关性随机数：被忽视的伪随机陷阱
- 原文: https://tck.mn/blog/correlated-randomness-sts2/
- HN: https://news.ycombinator.com/item?id=48552844
- 得分: 271
- 评论: 84
博主tck.mn详细分析了《杀戮尖塔2》中存在的”相关性随机数”（Correlated RNG, CRNG）问题。该游戏中存在大量看似异常的统计现象：在Underdocks地区选择Neow’s Bones遗物时获得诅咒”Debt”的概率高达约54%；从Trash Heap事件中不可能获得”Rebound”卡牌；第一场战斗在Underdocks掉落药水的概率是76%，而在Overgrowth仅为4%等等。
问题根源是不同随机数生成器之间的意外关联——知道某个RNG的首个输出能帮助预测其他所有RNG的首个输出。《杀戮尖塔1》也曾有类似问题：游戏使用多个独立的伪随机数生成器以防止战斗内的随机性影响后续奖励，但所有RNG初始化为相同状态导致产生相同序列。
《杀戮尖塔2》尝试通过给每个RNG使用不同的种子（基础种子加上不同字符串的哈希值）来避免该问题。但当这些种子传入C#标准库的System.Random类时，由于其伪随机算法在初始种子上几乎是”线性”的，导致两个种子相差已知固定值的RNG，其输出虽然不完全相同但仍存在可利用的相关性。
文章列举了一系列具体后果：Large Capsule遗物的第一个赠送物绝不会是普通品质；它在Underdocks中仅有1.65%概率出现；不同Act会出现不同的诅咒分布等。这些现象不仅影响知情玩家，也对完全不知情的普通玩家的游戏体验产生实质影响。
HN评论区的讨论聚焦于几个方面。多位评论者指出游戏开发者应该把游戏相关的随机数生成器视为游戏代码的一部分而非平台代码，使用自实现PRNG的好处是跨平台一致性和不受标准库版本变化影响。有评论者提到Godot引擎GDScript内置的RNG类使用的是PCG32算法，本可避免该问题。
不少玩家分享了自己的怀疑被验证的经历——例如总觉得某些卡牌特别频繁出现，原以为是确认偏误。还有评论提到”RNG地狱”的概念：如果游戏用时间作为种子，由于哈希函数和游戏机制的某些特性，可能出现连续几天完全不可能通关的种子。也有评论者讨论为何要使用多个RNG——主要是防止玩家通过观察战斗中的随机结果来预测和操纵后续卡牌奖励。
13. Bash的/dev/tcp：在没有curl的容器中发起HTTP请求
博主Marek Suppa分享了一个实用技巧：当需要在精简的Docker容器中检查内部服务连通性时，如果容器内既没有curl也没有wget，可以利用Bash内置的/dev/tcp功能手动构造HTTP请求。
具体方法是通过exec 3<>/dev/tcp/service/8642打开TCP连接，用printf手动构造HTTP请求行和头部写入文件描述符，然后用cat读取响应。需要在请求中加入Connection: close头部，否则HTTP/1.1默认保持连接，cat会无限等待。
值得注意的是，/dev/tcp并非真实的设备文件，磁盘上找不到该路径，而是Bash在内部处理的重定向。该路径名是因为没有真实Unix系统使用/dev/tcp或/dev/udp层级，因此不会与现有路径冲突。Bash内部完成DNS解析和connect(2)调用。
文章列出了几点注意事项：这不是真正的HTTP客户端，不处理重定向、分块响应、压缩、重试或TLS；只支持明文HTTP，HTTPS需要openssl s_client；这是Bash特性而非POSIX，dash和zsh没有；这是编译时选项（--enable-net-redirections），Debian曾经多年默认关闭该选项。
HN评论区充满了开发者的怀旧故事。一位评论者回忆90年代末作为孩子第一次发现可以telnet到80、25、110端口手动与服务器交互时的震撼，那是其”世界上没有魔法”觉醒的开始——意识到计算机的每个部分都是人类构建的、只要努力就能理解。担心未来人们会让代理完成一切，可能会留下许多有趣的安全漏洞。
不少评论者严厉指正文章的措辞错误：“Bash不能说HTTP，Bash只是让你打开TCP socket，你在自己说HTTP”——这种玩具代码用于测试调试可以，但生产环境会出问题，并推荐用nc代替。
许多评论者分享了实际应用场景：在安全团队不允许安装netcat或curl的环境中绕过限制；在SpringBoot的Docker容器中用Perl实现健康检查；OSCP渗透测试中用于初始低权限shell；以及为定制路由器编写小于4KB的心跳服务等。也有人提到这个特性最早是1997年KornShell引入的。
14. “停止使用JWT”：浏览器会话中的争议
GitHub Gist作者samsch发表观点：“JWT不应该用于保持用户登录状态。它们不是为此目的设计的，不安全，而且有一个更好的、专门为此设计的工具——常规Cookie会话。”
文章列出几点反对理由：JWT规范专为非常短期的令牌（约5分钟或更少）设计，而会话需要更长的生命周期；安全的”无状态”认证实际不可行，必须有某些状态来安全处理令牌，既然必须有数据存储，干脆存储所有数据；只存储简单会话令牌的JWT比常规会话Cookie效率更低、灵活性更差；JWT规范本身不被安全专家信任，原始规范允许伪造令牌的可能。
文章针对常见反驳作出回应。对”但谷歌使用JWT”——谷歌实际上并不在浏览器中使用JWT做用户会话，而是使用常规Cookie会话；JWT仅用于单点登录传输，且谷歌有资源维护更安全的JWT实现。对”无状态更好”——没有大量资源就不可能真正实现安全的无状态认证。对”我不知道如何设置会话”——任何Web框架都包含会话实现，通常很容易启用。
HN评论区争议激烈。许多评论者认为该观点缺乏必要限定——应该说”对于浏览器用户会话”，因为JWT在服务间通信中有大量正当用途。一位评论者讽刺道：如果JWT如此不安全，请去发表攻破AWS STS的方法，或者直接利用它在所有财富500强生产环境的AWS账户中部署加密货币挖矿。
多位评论者反驳具体观点。关于”短期”——RFC 7519并未对令牌寿命做硬性规定，使用5-15分钟令牌加刷新机制对浏览器完全可用。关于”不安全”——使用基于RSA/PPK的可信签名方式时JWT是安全的，把锅推给”某些库有bug”然后推荐用libsodium自己实现是荒谬的，所有软件都有bug。
支持者也分享了实践经验。一位评论者表示正在为某网站添加RabbitMQ通知推送，使用JWT认证控制客户端读取权限，配合短令牌寿命和定期刷新，没有比这更简单的方案。另一位常用模式是把JWT作为认证缓存：从认证服务获取令牌后访问其他子服务，子服务不需要访问认证数据库或铸造令牌的能力。
还有评论从可撤销列表角度论证JWT的优势：JWT有过期时间，只需维护未过期令牌的撤销列表，数据集很小；而会话方式中有效会话数往往远超撤销数。
15. GrapheneOS 完成 Android 17 移植，正式版本即将发布
GrapheneOS 团队在 Android 17 官方发布当天宣布，已完成将系统移植到 Android 17 的工作，并正在将代码推送到公开仓库。团队基于 Android 16 QPR2 构建最后一个官方版本，并计划次日发布首个 Android 17 版本。已在 Pixel 6a、7、7a、8、10a、10 和 10 Pro Fold 等设备上完成测试，后续会在所有支持设备上进行公测。GrapheneOS 是一个聚焦隐私与安全强化的开源 Android 衍生系统，长期紧跟 Google 上游版本节奏。
论坛与 HN 评论中，用户主要围绕几个话题展开讨论。其一是设备支持范围：Google 似乎不再为 Pixel 6 和 6 Pro 提供 Android 17，社区询问 GrapheneOS 是否会同步停止支持；同时也有 Pixel 9/9a 用户注意到首批测试列表中暂未包含自己的机型。其二是设备可获得性问题，多名评论者指出 Pixel 在全球许多地区并不销售，使得 GrapheneOS 在事实上成为少数人的选项，期待传闻中的 Motorola 合作机型尽快落地，以拓宽”去 Google 化”路径。
使用体验方面，多位长期用户分享了从 iPhone 或原生 Pixel OS 迁移的经历，普遍认为体验略显粗糙但完全可用，主要短板集中在输入法手势、短信反应表情显示方式等细节。北美用户讨论了非接触式支付替代方案的缺乏，欧洲用户可借助 Curve 等服务，而北美生态尚无成熟替代。另有评论提到 GrapheneOS 在外观上可与原生 Pixel UI 高度一致，并非常被误解的”丑陋”。
部分评论者对 Android 17 本身持保留态度，引用 Google 官方博客中将 Android 定位为”智能系统”、强调 AI 深度集成与用户参与度的表述，认为这正是选择 GrapheneOS 的理由之一。也有声音提醒，包括 GrapheneOS 在内的所有 Android 替代方案都依赖从原厂提取的二进制 blob，这也是新内核版本移植耗时费力的根本原因之一。
16. Calvin and Hobbes 与坚守原则的代价
文章通过两个故事呈现漫画家 Bill Watterson 对创作完整性的极致坚持。第一个故事发生在 1978 年 Kenyon 学院：大二的 Watterson 决定在宿舍天花板上临摹米开朗基罗的《创造亚当》，搭起椅子加桌子的简易脚手架，仰躺数周完成创作，事后向宿管追溯性申请许可，并按约定在学期结束前用白漆将作品全部覆盖，只为兑现承诺。
第二个故事是 1995 年 Watterson 三十七岁时，写下致各报编辑的信件，宣布在年底结束《Calvin and Hobbes》连载。彼时这部漫画在全球 2400 多份报纸上刊载，被无数读者视为连接童年与成年的精神桥梁。Watterson 坚持”一人工程”原则：每个字、每条线、每幅星期日彩页都亲自完成，使用极其简朴的工具——貂毛笔、Rapidograph 钢笔、乌鸦羽毛笔。他著名地拒绝了所有商品化授权，不让 Calvin 和 Hobbes 出现在 T 恤、玩具或动画上，与 Garfield、Snoopy 的商业化路径形成鲜明对比。在 Kenyon 毕业典礼演讲中，他告诉学生，艺术家应当为热爱而创作，而非名声或金钱。
HN 评论区情感色彩浓厚。多位读者回忆 Calvin and Hobbes 在成长中的位置，将其与 Carl Sagan 的《Cosmos》、《The Muppet Show》并列为塑造三观的作品。有人指出，正因 Watterson 拒绝商业化，作品比 Garfield、Dilbert 等”老化”得更优雅，没有沦为廉价品牌。也有评论坦承，自己若处在 Jim Davis 位置未必能拒绝财富，正因如此 Watterson 的选择才更显非凡。有读者推荐 Watterson 1990 年在母校的演讲全文，称其影响深远。还有人感慨 Watterson 若赶上网络漫画时代，摆脱编辑与发行联盟束缚后会作何选择，但也猜测他大概不愿亲自搭建网站。皮卡上随处可见的盗版 Calvin 撒尿贴纸、孩子们再也读不到周日报纸彩页，则成为新一代无法体验那种纯粹阅读乐趣的遗憾。
17. 纽约州立法拟禁止”幽灵职位”招聘
纽约州议会本月通过一项法案，旨在解决求职者长期诟病的”幽灵职位”问题——即雇主发布的、实际上并不打算填补的职位空缺。如经州长 Kathy Hochul 签署成为法律，该法案将要求公司在发布招聘信息时明确说明是否以及何时打算填补该职位，并在录用后两周内撤下相关信息。
法案适用于员工人数 100 人及以上的公司，以及发布职位的第三方平台。如果职位预计在 90 天内填补，雇主须披露预计填补日期，相关披露须以加粗大写字母呈现。若当前并无空缺或不太可能在该时间段内填补，雇主须注明，并提供预期招聘时间表。在雇主并不真正打算招聘的情况下，则须明确说明发布信息的目的是为未来空缺收集简历。
文章指出，许多幽灵职位源于管理疏忽，例如第三方平台发布过期职位或未及时撤下。对超过 17.5 万条招聘信息的分析显示，约七分之一的职位活跃超过 30 天。但也存在故意发布虚假职位的情形，原因多样。
HN 评论区讨论激烈。多数评论者支持该立法，并希望推广到联邦层面，认为对求职者而言时间成本极为宝贵。许多人呼吁同时立法禁止”已读不回”应聘者的做法，要求企业至少给出”职位已被他人填补”之类的简短拒绝回复，类比信用卡公司须告知评分变动原因的义务。也有评论者质疑可执行性：求职者自己都无法分辨哪些是幽灵职位，监管机构如何取证？有人建议直接以电汇欺诈罪起诉几个典型案例以儆效尤，因为欺诈本就违法。另一类担忧是意料之外的后果，例如雇主可能转向校友网络等封闭渠道。H-1B 流程中那种”已内定却必须公开发布”的结构性矛盾也被提及，法案如何处理此类情况尚不明朗。还有评论者指出招聘平台同样存在用虚假职位收集简历的灰色行为，立法应一并覆盖。
18. GPT-NL：荷兰打造主权语言模型的尝试
荷兰应用科学研究组织 TNO 主导的 GPT-NL 项目宣称要为荷兰打造一个主权语言模型。项目核心理念是在荷兰与欧洲本土完成开发，对模型、数据和决策保持完全控制，避免依赖非欧洲供应商，并与欧盟法律、价值观和社会目标保持一致。项目获得 1350 万欧元公共资金支持，强调使用合法获得的数据训练，遵循欧盟 AI Act 定义的最高伦理标准。
HN 评论区对此褒贬不一，且批评声音相当尖锐。一类常见质疑是”主权模型”路径本身的合理性。有评论者以瑞典的 GPT-SW3 为例，认为各国实验室与其花钱重新造轮子，不如在 Qwen、Kimi 等坚实开源基线上进行微调，针对真实智能体场景做实用工具，类比 Cursor 基于开源模型打造 Composer 2.5 的做法。另有评论者直接质问：既然已有 Kimi、Qwen、GPT-OSS 等开源权重模型，国家真正应该控制的是算力的物理位置，而非重写代码。
另一派评论者认为，欧洲国家投入本土 AI 研发是必要的，研究不应只在美中两国进行，使用本国语言训练对小语种国家尤其重要。但也有人对 1350 万欧元的预算能否做出有竞争力的从零训练模型表示怀疑，认为数字与目标严重不匹配。
更宏观的悲观情绪贯穿讨论。多名欧洲背景的评论者认为欧洲在 AI 竞赛中既缺乏美国式的风投生态，也没有中国式的协调公共投资和增长驱动力，长期投资充斥着大量监管、代理目标却缺乏资金与紧迫感。有评论者半开玩笑地列出”欧洲快速发展 AI”的三步方案——大规模税收优惠、对创始人和股东减税、降低劳动保护，并随即指出这些恰恰与欧洲核心价值观相悖，因此不会发生。荷兰本土科技圈对该项目的怀疑情绪也在升温，此前类似的 GEITje 模型还因法律问题被叫停。
19. 分享按钮真的有人点吗？数据说几乎没有
博主 Ankur Sethi 引用 Derek Hanson 的研究，汇总多项关于网页社交分享按钮使用率的数据。英国政府 GOV.UK 网站在 10 周内对 680 万页面浏览进行追踪，分享按钮共被点击 14078 次，使用率为 0.21%，约每 476 名访客中有 1 人点击。该功能在产品 backlog 中长期搁置，因为从未有终端用户主动要求，用户测试中人们直接复制粘贴链接。
Moovweb 对 6100 万次移动会话的分析得出相似结果：仅 0.2% 的移动用户与社交分享有任何互动，访客点击广告的可能性是分享按钮的 12 倍。设计师 Luke Wroblewski 通过众包从读者处收集到 1800 万页面浏览数据，得出平均 0.25% 的使用率。不同组织、不同受众，数字高度一致。
人们的实际分享行为发生在”暗社交”中：复制粘贴 URL 到短信、邮件、Slack 等渠道。2012 年 The Atlantic 的 Alexis Madrigal 就发现网站大量流量在 Google Analytics 中显示为”直接访问”，实则来自他人粘贴的链接。
HN 评论区出现有趣分歧。一些人指出 0.21% 在转化率语境下其实并不算低，对小型网站而言意味着每天甚至更频繁的分享。但多数评论者解释为何自己从不点击：分享按钮行为不一致、可能附带营销文案”你的朋友分享了……”、嵌入跟踪像素与第三方 cookie。复制 URL 是通用、可控、“just works”的方案，把控制权留给用户而非网站运营方。多个评论者提到 Reddit 上充斥着带 si= 参数的 YouTube 链接，证明 YouTube 的分享按钮确实被广泛使用，反例值得注意。
也有务实声音：一位 Caltrain 应用作者表示，自己的分享按钮会预填充列车信息和追踪链接，因此使用率不错——关键是分享内容必须比纯链接更有价值。前 The New Yorker 员工指出，即使有人不点击，按钮本身也起到 CTA 作用，提示读者”这值得分享”。还有人推荐使用浏览器原生的 navigator.share() API 作为折中方案。Wordle 把成绩转为可分享的 emoji 文本被多次称赞为正确做法的范例。
20. YouTuber 破解”最差电动自行车” Reevo 并重新让它可用
- 原文: https://www.youtube.com/watch?v=hPrtVGimBYs
- HN: https://news.ycombinator.com/item?id=48479957
- 得分: 171
- 评论: 87
YouTube 频道 Berm Peak 的创作者 Seth 在视频中讲述自己借来被称为”世界最差电动自行车”的 Reevo，承诺修好再归还。Reevo 是一款依赖手机 App 才能正常使用的”付费骑行”式电动自行车，原视频是 Seth 一年前对该车的批评测评。这次他通过越狱车载电脑、3D 打印替换零件等手段，让这辆车摆脱原厂 App 控制，重新可用。
HN 评论区围绕几个主题展开。其一是对该频道创作生态的讨论。多名评论者推荐 Berm Peak 早期的后院自行车赛道建设系列视频，认为制作精良，但创作者已不再更新，因为 YouTube 算法对耗时一个月精心制作的长视频与”对着镜头评测愚蠢小工具”的 10 分钟视频给予同等回报，“常青”内容反而被惩罚。
其二是对依赖 App 的消费电子产品的强烈反感。有 Cowboy 电动自行车前用户分享惨痛经历，强调购买带定制零件、闭源 App 的电动自行车风险极高：零部件磨损不可避免，若只有原厂销售则用户被锁死；若 App 不开源、不基于标准、不被 GadgetBridge 等开源项目支持，厂商一旦停止维护即等于把车变砖。该用户呼吁消费者应询问维修店”哪些车好修”，而非”哪些车好骑”，自己现已转用定齿车。也有人引用 Cory Doctorow 的小说《Unauthorized Bread》类比这种产品形态的荒谬。
其三是对视频中使用 AI 的争议。一位评论者表达明显不适，指出创作者在不熟悉的领域大量调用 LLM——用 AI 生成前端代码、让 Claude 通过 UART 接口做逆向工程、用 LLM 解释自己不懂的概念——并将 AI 输出近乎逐字复述，模仿自身说话风格，听起来”像不熟悉某种语言的人在说话”。该评论者认为，凭借 Seth 的平台完全可以找到愿意免费贡献的爱好者，既省钱又能”nerdsnipe”真正的极客参与硬件破解，是双赢；而当前做法剥夺了社区参与的机会。视频评论区中创作者本人的置顶留言也被指几乎完全由 AI 生成。另有评论者好奇该车为何使用电致发光灯而非简单的 LED。