Soda · Photos 奇鸟行状录
A quiet archive · Est. 2026 · MAY 03, 2026
HN Daily Reading · 每日阅读

HN 每日深度阅读 · 2026-05-01

本期主题偏向基础设施与权力边界：比利时重回核电、Claude Code 的关键词风控、浏览器 Prompt API 标准争议、内核漏洞披露和网络封锁立法。很多讨论都在问同一件事：当关键系统被少数平台掌握，用户、开发者和监管者还有多少实际选择。

2026.05.01 20 篇摘录
← 返回每日阅读列表

共 20 篇 · 约 11,346 字 · 约 30 分钟读完

1. 比利时停止核电站退役，转向国有化收购

比利时首相 Bart De Wever 宣布政府将停止对该国核电站的退役进程，并与现运营方法国电力集团 ENGIE 展开独家谈判，洽购包括七台反应堆、相关人员、核子公司以及全部资产负债（含退役与拆除义务）在内的整套核能资产，预计于 10 月达成基本协议。比利时早在 2003 年立法决定到 2025 年彻底淘汰核电，但近年因能源安全顾虑而多次推迟。去年议会以高票通过取消核电淘汰政策，现政府还计划新建核电站。比利时目前严重依赖天然气进口，可再生能源扩张乏力，七座反应堆中已有三座关停。

HN 评论区主流情绪偏向支持。多位评论者认为，环保组织数十年来反核的立场严重延后了减碳进程，是历史性错误；美国海军超过 7500 反应堆年的零事故记录被反复引用作为安全性证据。也有评论者参观过加州 Diablo Canyon 核电站后，对工程与安全文化印象深刻，认为下一代小型模块堆和现役机组都将在未来电网中扮演重要角色。一些人指出，关停尚在设计寿命内的安全机组属于”纯粹的疯狂”，运行中的核电站应视作国家级资产。

讨论中也出现了反方与补充视角。德国自 1970 年代起寻找永久核废料处置场至今未果，预计 2040 年前都难有结论，被举为核电长尾成本的例证。另有评论者讲述了美国本土因铀加工厂污染导致家乡居民甲状腺疾病和癌症高发的亲身经历，强调”核灾难”不仅限于三哩岛、切尔诺贝利和福岛，铀矿开采和浓缩环节同样有公共健康代价。还有人提到欧盟近期发布加速部署核能与可再生能源的计划，认为本轮能源冲击将带来持久的政策转向。

2. Claude Code 遇到 “OpenClaw” 关键词会拒绝请求或多扣额度

开发者 Theo（t3.gg）在 X 上披露，只要 git 提交信息中包含特定 JSON 片段提及 “OpenClaw”，直接调用 Claude Code 就会触发异常：要么拒绝请求，要么直接将会话用量计为 100%。该现象在空仓库中也能稳定复现：初始化 git，提交一条含 {"schema": "openclaw.inbound_meta.v1"} 的 commit message，再运行 claude -p "hi"，会话立即断开并耗尽配额。另有用户反映，仅在博客文章里提及 OpenClaw 并附上 openclaw.ai 链接，Claude 也会立刻终止对话并触发 5 小时使用上限。还有人观察到 Claude 在编辑包含路径 ~/projects/opencode 的内容时，会间歇性把 “opencode” 替换为 “claude”，干扰工具调用。

HN 评论将此事解读为多个层面的问题。一是审查与商业伦理：通过关键词匹配秘密扣减用户额度被认为是”邪恶微软式”的暗黑模式，并且构成了一个”可以开卡车穿过去的 DoS 漏洞”——任何人都能通过在他人仓库植入特定字符串来耗尽对方配额。二是公司状况的旁证：评论者推测 Anthropic 容量规划失误叠加 OpenClaw 类工具带来的负载压力，使其将后者视为生存威胁，因而采取激进的限流手段，而这反过来严重损害品牌信任。三是工程质量：近期 Claude Code 接连出现 HERMES.md、思考消息裁剪、缓存跳过等 bug，结合 Claude Code 团队公开承认大量代码由 AI 生成的事实，被讽刺为”Anthropic 自己都做不好 vibe coding”。不少长期付费用户表示正在评估迁移到 Codex、Cursor、OpenCode Go 或通过 OpenRouter 调用其他模型，认为 20x 套餐的性价比已难以为继。

3. Mozilla 反对 Chrome 推动的浏览器 Prompt API 标准

Mozilla 在其 standards-positions 仓库中对 Chrome 提出的 Prompt API（让网页通过浏览器内置接口调用本地大语言模型）表态反对。撰写反对意见的是前 Google Chrome 团队成员、现加入 Mozilla 的 Jake Archibald。核心论点有两条：一是 prompt 与具体模型存在紧耦合——同一段 system prompt 在不同模型上效果差异巨大，作者举例称为 Gemini 调教出英式英语口吻的 prompt 换到其他模型上行为完全不同，因此把”调用本地模型”做成标准 API 在工程上并不成立；二是该 API 的使用条款缺乏模型中立性，等于借标准之名固化特定供应商。

HN 讨论进一步放大了多方面顾虑。指纹识别风险首当其冲：浏览器内置模型的具体行为差异会成为新的高熵指纹源，且难以伪造，可能被用于”设备验证”和反规避。性能与成本问题被多次提及——LLM 推理对内存和 CPU 占用极大，在当前内存价格高企的背景下，强制依赖本地模型会让低端设备上的网页严重劣化。生态层面，评论者担心这会演变成”必须使用 Chrome（因为站点只在 Gemini 上测过）“的新一轮浏览器锁定，甚至让没有自带模型的国家级或开源浏览器被排除出主流网站兼容范围；几年后模型迭代还可能导致老站点直接失效。另有人质疑前提本身：“浏览器和操作系统理应越来越多地接入语言模型”这一论断并非共识。也有少数声音同情 Google 的设计动机，认为浏览器层面的统一接口至少避免了每个站点各自接入云端 API 的隐私问题，但承认在 TOU 中加入模型中立条款是必要前提。更宏观的批评指向 Chrome 一贯的扩张路径：与其不断给浏览器堆加新能力，不如先修复 Web 平台已有的结构性短板。

4. Linux 内核漏洞 CopyFail 披露未通知发行版维护者

Gentoo 开发者 Sam James 在 oss-security 邮件列表上确认，编号为 CVE-2026-31431 的 Linux 本地提权漏洞 “CopyFail” 在公开披露之前并未通知各发行版。该漏洞由 2017 年合入的一个 IPSec 相关 commit 引入，影响 4.14 至最新主线，目前已在 6.18.22、6.19.12 与 7.0 中修复，但长期支持分支 6.12、6.6、6.1、5.15、5.10 因 API 变化无法干净 backport，截至披露时尚未获得官方修复。Sam James 表示自己尝试 backport 但因不熟悉 IPSec 代码不敢轻易改动，转而提供了一个禁用 authencesn 模块的临时 workaround 补丁。他特别指出，对于 Linux 内核漏洞，除非报告者主动选择走 linux-distros 邮件列表，否则发行版不会得到提前通知，本次正属此种情况。

HN 评论几乎一致认为这是一场可避免的事故。多数人反对将责任归咎于报告者：要求漏洞研究者自行了解并联系所有下游消费者（发行版、设备厂商等）缺乏合理的边界，按理说内核项目自身的安全团队应承担向下游同步的职责。“Linux 内核已不再是玩具项目，它有大量受雇于各公司的全职员工，应该有人来处理通知发行版的工作”是被高度赞同的观点。也有评论者提供实际缓解方案，包括基于 eBPF 的运行时缓解（针对 AF_ALG 编入内核而非作为模块加载的情形）、使用 initcall_blacklist 等。

围绕缓解措施还衍生出更深层的安全卫生讨论：有评论者主张 nosuid、nodev 应成为默认挂载选项，并以 NixOS 为例——所有 SUID 二进制都集中在单一 /run/wrappers.$hash 目录中，其他挂载点全部 nosuid，从根本上限制此类提权链的攻击面。Ubuntu 已发布并验证了补丁；NixOS 自身在该漏洞上未受影响；StageX 因已运行 7.0 版本同样安全，但同样未被提前通知。

5. 西班牙国会拟立法限制 LaLiga 大规模 IP 封锁行为

西班牙顶级足球联赛 LaLiga 此前从法院获得命令，要求西班牙各 ISP 在足球比赛进行期间封锁与盗播相关的 IP 地址。由于这些 IP 多为 Cloudflare 的共享地址，结果是每逢比赛日，大量与盗播毫无关系的合法网站在西班牙境内集体不可访问。西班牙国会现已表态将立法干预，遏制这种波及面极广的封锁手段。

HN 评论几乎一边倒地批评原有机制。有评论者从法理角度提出了”停止原则（stopping principle）“的概念：任何执行性政策——无论是交通执法、缉毒还是版权封锁——都应能清晰说明何时停止投入资源，可能是问题已被充分解决、边际收益不再值得、或者对自由的侵害开始压过收益。LaLiga 的封锁恰恰缺乏这一原则，规模不断扩大，逻辑上的终点就是”100% 封锁”。也有美国评论者表示难以想象法院允许 NFL 在全国范围内命令 ISP 封锁 IP，认为西班牙法院的授权本身就匪夷所思。

实操层面，多位运营在西班牙的从业者反映深受其害，例如经营票务系统的开发者表示停机基本不可接受，但封锁让其束手无策。亦有用户分享使用 Cloudflare WARP 绕过封锁的经验。多名读者在评论中以”读这篇文章时遇到了 CloudFront 403”的截图，讽刺性地呼应了文章主题——封锁文化的最终受害者，正是人们想要访问的内容本身。也有声音担忧立法可能止步于”持续关注”的口头表态，因为整段 Cloudflare IP 即使在工作日也持续遭到封锁。

6. Mark Klein 如何把 NSA 641A 房间的真相交给 EFF

本文是 EFF 现任执行主任 Cindy Cohn 新书《Privacy’s Defender》的节选，回忆了 2006 年 1 月 20 日 AT&T 退休技术员 Mark Klein 走进 EFF 旧金山办公室的那一天。Klein 主动告知 EFF：他知道 NSA 是如何在旧金山市中心的一栋 AT&T 大楼里接入互联网骨干网进行大规模未定向监听的——这正是后来著名的 641A 房间。文章追溯了背景：9·11 之后《爱国者法案》仅用七周便通过，EFF 注意到其中很大一部分内容与 1995 年俄克拉荷马城爆炸案后 FBI 推动失败的法案高度重合，疑似”放在抽屉里等下一次危机”。该法削弱了原本将 NSA 对外监听与 FBI 对内执法分隔的”墙”。EFF 此前已陆续从业内人士处听到 NSA 在美国境内大规模收集电话记录、骨干流量与元数据的传闻，但始终缺少能上法庭的证据，直到 Klein 携带物证登门。该案最终演变为 Hepting v. AT&T 诉讼。

HN 讨论补充了大量同时代的旁证。一位前 1990 年代政府承包商透露，所谓 NSA 与 FBI 之间的”墙”其实早在 90 年代初就被例行违反，他因签署了多份 NDA 而未像 Snowden 那样公开。另一位读者讲述 2002 年在洛杉矶市中心机房目睹角落里新建的、有粗光纤进出的封闭小房间，未上漆的干墙却配着高规格门禁，被机房技术员默认是监听设备。还有读者通过 arpwatch 在自家 ISP 网段发现一台注册到美国国防部 IP 段的主机，认为大规模监听基础设施依然就在身边运行。

技术演进层面，多位评论者指出完美前向保密（PFS）的普及在很大程度上削弱了 641A 式被动复制流量的价值，使得即便流量被分流到犹他州数据中心也难以离线解密，迫使监听方转向更主动的服务器入侵或证书攻击。也有人感叹这一议题在 Bush 末期短暂成为政治热点，但当奥巴马在《Tonight Show》上公开否认存在国内监听项目后，两党共同的淡化使其逐渐退出公共议程，而当前关于 FISA 第 702 条重新授权的争论仍在很大程度上处于保密状态。

7. Rivian 允许用户彻底关闭车辆的网络连接

电动车厂商 Rivian 在其官方支持页面明确说明：用户可以选择禁用车辆全部联网功能，从而阻止任何数据离开车辆。代价是部分功能将受限或失效，包括导航、主动车道居中辅助以及 OTA 升级（涵盖新功能、性能优化、安全修复等）。在加拿大销售的车辆可直接通过车机”数据与隐私”设置中的开关关闭蜂窝连接；在其他市场（包括美国），用户需联系 Rivian Service 通过预约把 eSIM 物理停用。订阅类服务（如 Connect+）不会因此自动取消，需另行处理。

HN 评论对这一做法总体持正面态度，但也提出了大量延伸问题。最受关注的是 OTA 与召回的冲突：在美国，传统燃油车的排放相关 ECU 必须支持通过 J2534 透传设备进行（可能签名的）CAN 总线更新，普通用户甚至可以购买短期经销商级诊断软件订阅自行刷写；但 EV 没有相应的法规要求，一旦用户禁用 eSIM 并随后出现需要软件修复的安全召回，是否还有线下刷写途径目前在美国处于灰色地带，NHTSA 仅要求”提供 remedy”但缺乏细则。另有评论者怀疑”关掉联网就关掉车道保持”是否属于变相惩罚式的暗黑模式，还是确实依赖云端前方路况数据。

更宏观的讨论指向智能汽车的国家安全维度：当制造国与使用国不同，制造方理论上能远程禁用大量车辆、收集军事人员的位置/音视频/Wi-Fi 与基站数据，这些数据在 GPS 被干扰时甚至可用于导弹和无人机制导；DPI 与海关检查都无法完全应对 Starlink 等绕路。也有评论者引用 Mozilla “Privacy Not Included” 项目对各品牌汽车隐私政策的盘点——日产和起亚的隐私政策中竟包含”性生活”、六家车企声称可收集”基因信息”——以此衬托 Rivian 提供”硬开关”在行业内的稀缺性。还有车主分享在 2015 款雪佛兰 Silverado 上拔出 OnStar 模块以物理切断蜂窝天线的经历，认为 Rivian 至少把这一隐私需求做成了官方支持选项。

8. IBM Granite 4.1：8B 稠密模型对标 32B MoE

IBM 发布开源企业级语言模型家族 Granite 4.1，采用 Apache 2.0 协议，使用 15 万亿 token 训练，包含三种规模。最受关注的是其 8B 稠密版本：未使用 MoE，也未使用扩展推理链，但在内部基准测试中几乎全面追平甚至超过 Granite 4.0-H-Small——后者拥有 32B 参数（其中 9B 激活）。原文作者认为这一对比要么说明新模型设计极为高效，要么暗示旧模型欠优化，或两者兼有。文章重点剖析了 IBM 在数据流水线、幻觉过滤、数学结果强化等方面的设计选择，以及不同规模模型如何在同一家族内取得相近表现。

HN 评论分歧明显。一部分实测用户反馈 8B 版本在普通硬件上跑得很快，训练数据较新，适合自动补全和小任务，但仍认为 Qwen3.6 35B A3B 是本地最强；4B 版本表现欠佳，但可能足以处理工具调用。另有评论指出 granite-vision-4.1-4b 在表格与语义键值抽取上可能是真正的”黑马”。在架构趋势上，有人注意到 IBM 与 Mistral 都在向稠密模型回归，而前沿大模型仍坚持 MoE 路线。

不少评论对原文质量提出尖锐批评，认为该文有明显 LLM 写作痕迹（“不是这个，而是那个”的句式、空洞铺陈），并指出文章遗漏了关键对比：与 Qwen 3.5 4B 等同级模型相比，Granite 4.1 8B 仅在抗幻觉和指令遵循两项占优，其他指标均落后。也有人强调，本地模型在 2026 年最值得关注的不是单点智能，而是多步工具调用中结构化输出的稳定性——小模型每次调用的可靠性差异在 5 步以上链路中会快速累积，希望看到 Granite 在多步函数调用上的专项评测。还有评论顺带称赞 IBM 一以贯之的视觉设计语言，从 1968 年《2001 太空漫游》中的未来主义风格延续至今。

9. LinkedIn 扫描浏览器 6278 个扩展并加密上传

404privacy 的调查指出，LinkedIn 在用户访问其网站时会主动探测浏览器中是否安装了特定扩展，目前列表已扩展至 6278 个，且自 2017 年（当时仅 38 个）以来持续增长。技术原理是利用 Chrome 扩展 manifest.json 中的 web_accessible_resources 字段：对 chrome-extension://{id}/{file} 发起 fetch 请求，已安装的扩展会成功返回，未安装则被 Chrome 拒绝，由此判断安装状态。打开开发者工具即可在控制台看到大量此类失败请求。

文章强调，与一般针对匿名访客的指纹识别不同，LinkedIn 已掌握用户姓名、雇主、职位、薪资区间、社交网络等真实身份信息，再叠加扩展清单，等同于将私人软件画像绑定到职业身份。扫描列表中包含数百个求职扩展（可能暴露员工的跳槽意图），以及涉及政治、宗教、残障、神经多样性的扩展。聚合多名同公司员工的扫描数据，还可反向绘制企业内部工具栈、安全产品和竞品订阅情况。文章引述据称在德国法庭宣誓作证的 LinkedIn 工程师 Milinda Lakkam 称，公司曾”对安装特定扩展的用户采取行动”。LinkedIn 隐私政策中并未披露此项扫描，也无用户同意流程。

HN 讨论中，有人指出该贴是重复提交，原贴讨论更深入。多条高赞评论质疑作者的写作质量与 LLM 痕迹：第二个本应指向”扩展清单 GitHub 仓库”的链接实际指向一个 9 年未更新的项目；并认为文章漏掉了关键事实——被扫描的扩展主要是数据抓取、爬虫、AI 垃圾营销和招聘自动化工具，而非普通用户日常使用的扩展。也有人从技术上澄清这是常见的设备指纹识别手段，扩展列表熵值高，确实有助识别爬虫。一条实用技巧引发关注：从 Chrome 商店下载扩展源码后本地加载，会得到全新的 extension_id，可绕过基于固定 ID 的探测。还有评论分享了实际副作用：LinkedIn 后台脚本 li.protechts.net 在标签页留存数小时后仍占用 2GB 内存和 8% CPU。多位用户表示已注销 LinkedIn 账号。

10. PyTorch Lightning 遭 Shai-Hulud 主题供应链攻击

Semgrep 披露：广泛使用的深度学习框架 PyPI 包 lightning 的 2.6.2 与 2.6.3 版本（发布于 2026 年 4 月 30 日）被植入恶意代码。仅运行 pip install lightning 即触发：包内隐藏的 _runtime 目录在模块导入时执行混淆 JavaScript 载荷，窃取凭据、令牌、环境变量和云端密钥，并尝试污染 GitHub 仓库。该攻击带有明显 Shai-Hulud（《沙丘》主题）特征，会创建名为 EveryBoiWeBuildIsaWormBoi 的公开仓库，被认为出自 Mini Shai-Hulud 攻击者之手。

攻击的特殊之处在于跨生态扩散：入口在 PyPI，但载荷为 JavaScript，蠕虫传播发生在 npm。一旦发现 npm 发布凭据，恶意代码就向所有可发布包注入 setup.mjs dropper 与 router_runtime.js，将 scripts.preinstall 改为执行 dropper，递增补丁版本号并重新发布，下游开发者安装后即被感染。窃取目标覆盖文件系统中 80+ 凭据路径、shell 环境、GitHub Actions Runner 进程内存（提取 isSecret:true 标记的密钥）、AWS（含 IMDSv2 与 ECS 元数据端点）、Azure Key Vault 与 GCP Secret Manager。数据通过四条并行通道外泄：HTTPS POST 到 C2、GitHub 提交搜索的 dead-drop、攻击者控制的公开仓库、以及受害者自身仓库的所有分支。

更值得警惕的是持久化机制：恶意代码会在仓库写入 .claude/settings.json，注册 SessionStart hook，使开发者每次打开 Claude Code 都触发 node .vscode/setup.mjs，被认为是首例利用 Claude Code hook 系统的真实攻击。

HN 讨论聚焦于供应链攻击近期高频发生的趋势。多位评论者注意到 lightning 仓库的 4 个安全 issue 最初均被一个名为 pl-ghost 的机器人自动评论并关闭，且评论后被删除，引发对维护方响应是否得当的质疑。有评论指出，使用 Claude Code 时用户往往直接回车确认其建议的 pip 安装命令，但模型训练数据滞后数月，根本无从识别本周新出现的恶意包，构成”最差的安全过滤器”。也有人担忧 Anthropic 自身一旦被攻破，整条工具链会受牵连。还有人讨论 uv 与 asdf 安装 Python 的来源安全性，以及机器学习生态长期使用 pickle 等可执行格式分发模型所累积的安全债。

11. 炼油厂如何工作：从原油到成品油的工程全景

Construction Physics 撰文系统介绍现代炼油厂的运作机制。背景数据显示，世界每天消耗超过 1 亿桶石油，2023 年石油占全球能源消费 30%，居各能源之首；化工原料中约 90% 来自油气，几乎所有塑料及大量润滑油、涂料、合成纤维、化肥等都源自石油化学品。大型炼油厂占地数千英亩，造价数十亿美元，日处理原油可达数十万桶。

原油是数千种化合物的混合物，主要为各种碳氢分子，从丙烷、丁烷到含数千原子的沥青烯不等。按产地不同分为重质/轻质（按重分子比例）、甜/酸（按硫含量）。炼油厂的核心任务是分离这些混合物，并通过化学反应把低价值组分转化为高价值产品。

最关键的工艺是蒸馏。原油先脱盐，加热至 650–750°F 大部分气化，进入装有多层托盘的常压蒸馏塔。蒸气上升时在每层托盘的液体中冷却，沸点最高的重分子在底部凝结，最轻的从塔顶以气态排出，由此分离出各馏分。汽油本身即是 C4–C12 分子的混合物，其定义按 10% 与 90% 回收点的沸点范围给出。最简单的炼油厂仅做常压蒸馏，更多炼厂会将各馏分送入气体厂（含脱丁烷塔等多级蒸馏柱）等下游装置进一步处理。

HN 讨论延展出多个有趣视角。一位曾在横滨炼油厂参观的译者回忆：满负荷运转时几乎看不到工人，控制室人员也不忙；为避免居民投诉，厂区几乎闻不到异味，他当年翻译的文档之一就是异味检测系统。多人推荐 NPR 的”Planet Money 买石油”系列与”我曾试图买一桶原油”的旧帖。还有评论提到 Chevron 当年定制的教学游戏 SimRefinery，以及 Factorio、GregTech 等游戏对炼油流程的相对真实还原。技术性讨论包括：文章未提及”一次能源谬误”——大量石油能量最终以废热形式损失；炼厂塔顶燃烧火炬是否仍在浪费可燃气；naphtha 一词在不同语境下含义跨度极大，且词源可追溯至阿卡德语。也有评论惊讶于”加工增益”现象——出料体积可能大于进料，以及原油颜色未必是黑色（可呈绿、红等色）。

12. 用 SIMD 与四叉插值搜索击败二分查找

Daniel Lemire 在博客中介绍了一种针对 16 位无符号整数有序数组的搜索算法，能在常见场景下显著超过 std::binary_search。背景是 Roaring Bitmap 中常用 1–4096 元素的 16 位整数数组，需要频繁判断元素是否存在。

作者提出两点观察：其一，现代 64 位 ARM 与 x64 处理器都支持用一条 SIMD 指令同时比较 8 个 16 位整数，因此二分查找下降到小于 8 个元素的块时已无意义，甚至可廉价比较 16 个元素；其二，二分查找一次只检查一个值，但现代处理器具备出色的内存级并行能力，可同时加载并比较多个值，因此把数组按四等分而非二等分（四叉搜索）虽多生成几条指令，但指令数并非瓶颈。

由此他设计了 SIMD Quad 算法：将数组划分为 16 元素的固定块，以每块最后一个元素作为插值键进行四叉插值搜索，先快速定位目标可能所在的块，再用 SIMD 一次性并行比较该块全部 16 个元素。若数组少于 16 元素则直接线性扫描。该方法融合了插值搜索的对数级压缩与 SIMD 的硬件并行加速。

HN 讨论提供了多条有价值的补充。多位评论者指出，二分查找只在对数据分布”一无所知（仅知有序）“的前提下才是最优；若有先验分布信息（如人查英文字典），插值搜索或将搜索视作单调函数求逆并应用梯度下降式控制算法可以做得更快。也有人质疑”四叉”是否只是把二分循环展开一层、本质比较次数相近，是否能用普通循环展开达到同样效果。另一思路是利用缓存行特性：CPU 每次必然加载完整 64 字节缓存行，那不如在中间缓存行上用一条 512 位 SIMD 指令同时比较其中 32 个 16 位整数（或 16 个 32 位整数），可能比标准二分快近 32 倍。还有评论介绍了 Exponential Search 在重复搜索递增键时带来 8 倍提速的实际经验，以及”带哨兵的线性搜索在小数组上极难被击败”——但”小”具体多大极难量化。也有人提出”Binary*“的启发式变体：利用三个采样点的差值比例自适应调整下一个 mid 位置，使搜索更贴近目标方向。整体观点是：经典算法多假设无并行、无缓存的串行模型，而真实硬件特性正在让”非传统”搜索算法重新焕发价值。

13. BidProwl：聚合 28 个美国政府拍卖站点的统一搜索

BidProwl 是一个把 GSA Auctions、GovDeals、Ritchie Bros、Purple Wave、GovPlanet、Bid4Assets、IRS Auctions、Municibid、HUD Homes、US Marshals 等 27 个美国政府及关联机构的剩余物资/拍卖站点聚合到单一搜索框的项目。截至上线时显示 72,655 条在线列表，覆盖 50 州，每日新增数千条。除关键字搜索外，提供按类别（车辆、重型设备、办公家具、电子产品、医疗与科研、军用剩余、不动产、查封财产等）和按州浏览。

平台的卖点包括：每日两次抓取更新，减少”幽灵拍卖”；为每条列表生成 1–10 分的”成交分”（基于价格、出价速度与剩余时间）；所有详情页直接跳转原拍卖站，平台不接触出价、不抽成、不介入买卖双方。还提供入门指南，涵盖注册、出价、检查、运输与提货等流程，以及不同平台对比与车辆拍卖专题。订阅邮件可每日推送 10 条评分最高的拍品。

HN 讨论中，有评论指出三周前已有相似产品 GovAuctions 出现，质疑本项目是否克隆。也有人从政策角度反思：相当一部分政府拍品来自民事资产没收（civil asset forfeiture），追问政府如何最初获得这些自行车、卡车、开关等物品。多位评论者吐槽政府拍卖的现实体验——常常需要为一件军规水槽跨三州奔波，或不得不一次性购入 400 件已损坏的同型号物品。功能层面反馈集中在两点：一是站点性能问题，多人遇到加载缓慢、各州页面打不开、报错”服务器过载”，疑似 HN 流量冲击；二是缺少按 ZIP 码或地理半径筛选的能力——加州的好货对七小时车程外的用户毫无意义。还有用户报告价格与状态同步存在延迟（点进去价格已从 $806 变为 $1,270，已成交项未及时下架）。一条轶事：评论者 25 年前曾差点在 GSA 拍卖中买下一座灯塔，幸好出价输了，因为后来发现维护费极其高昂。

14. 用 F# 写一个 Game Boy 模拟器：Fame Boy

作者 Nick Kossolapov 是工作 8 年的软件工程师，自陈对计算机底层运作并不真正理解，于是通过模拟器项目自学。他先完成了 From NAND to Tetris 课程建立基本功，再用 F# 实现 CHIP-8 模拟器（Fip-8）作为练手，最终完成了带声音、可在桌面与浏览器运行的 Game Boy 模拟器 Fame Boy，能跑《精灵宝可梦 蓝》。

架构设计上，他在仿真核心与前端之间维持简洁接口：一个 160×144 的帧缓冲数组、一个 32768 Hz 采样率的环形音频缓冲、stepEmulator() 执行一条 CPU 指令并返回所用周期数、getJoypadState() 由前端回传按键状态。代码组织尽量贴近真实硬件：CPU 模块（对应 Sharp LR35902）只通过内存映射与中断信号了解外部，是最具 F# 风格、最重函数式领域建模的部分；Memory.fs 充当 RAM 与各组件总线，并为性能将 VRAM/OAM 引用共享给 PPU；IoController.fs 在 Memory.fs 逻辑膨胀后被抽离出来，以统一处理硬件寄存器。Emulator.fs 中的 stepper 函数串行调度 CPU、定时器、串口、APU、PPU 的各自 step，保证组件同步——真实硬件本是基于主时钟并行运行的。每帧约需 17500 个 CPU 周期来达到 60 FPS，前端在开声音时用音频采样率驱动模拟器，静音时用帧率驱动。

性能考量上，作者向函数式纯派”道歉”：CHIP-8 版本完全无 mutable、所有数组复制，但 Game Boy 速度高得多，每秒复制十几 KB 内存上百万次不现实，因此 Fame Boy 大量使用可变状态。他对 F# 类型系统在 CPU 指令建模上的表现给予高度评价：参考 Gekkio 技术手册时，他用判别联合（DU）抽出”立即数 / 直接寄存器 / HL 间接寻址”等共有概念，将 512 个 opcode 压缩为 58 条指令，并用类型系统拒绝非法状态。

HN 讨论氛围正面。有 F# 老手指出可进一步优化：将 Instructions.fs 中的 DU 标记为 [<Struct>] 减少分配；某些寄存器已是 byte 类型，setter 中 &&& 0xFFuy 是冗余的。多条评论赞赏这是”人类亲手学习”而非 LLM 速成的成果。也有评论者观点是 F# 长期处于 C# 阴影之下，多数库实为 C#/.NET 转手，缺乏针对 F# 设计的接口与文档。还有人感慨用函数式语言写模拟器尤为不易——硬件天然契合命令式范式，看到作者构造的函数式抽象很受启发。也有人借此重新点燃自己搁置的 Rust→Game Boy 编译器构想，并提出了一个相关有趣需求：希望有人用不同测试图案、不同光照条件下对 GB/GBC/GBA 屏幕做高分辨率微距拍摄，以便为复古滤镜建立更精确的物理模型。

15. Honker：把队列、流和发布订阅塞进 SQLite 文件

Honker 是一个 SQLite 加载扩展，把持久化队列、事件流、发布订阅和 cron 调度器都塞进单个 SQLite 文件，目标是为以 SQLite 为主数据库的应用提供 Postgres 风格的 NOTIFY/LISTEN 语义，避免引入 Redis、Celery 等额外组件。

其核心卖点是事务一致性：业务写入（如 INSERT INTO orders）和入队操作可以在同一个事务里提交，回滚时任务也会随之消失，从而消除业务表与队列之间的双写问题。Honker 提供 Python、Node、Rust、Go、Ruby、Bun、Elixir、C++ 多语言绑定，共享同一份磁盘格式，跨进程唤醒延迟在 M 系列笔记本上约 0.7ms（p50）。

实现机制上，Honker 通过每毫秒轮询一次 SQLite 的 PRAGMA data_version——一个在任何连接、任何日志模式下提交时都会单调递增的计数器，读取约 3μs——来获得精确的唤醒信号。每个数据库只需一个轮询线程，订阅者数量增加不会增加查询开销。队列、流、发布订阅本质上都是扩展管理表中的 INSERT 行。

HN 讨论中争议主要集中在「每毫秒轮询」这一选择上。有评论者指出忙轮询并不优于内核文件监视器（inotify/kqueue），且每秒约 0.3% CPU 时间是无谓浪费。也有人质疑前提：SQLite 本身是单写者数据库，多线程通信用 ring buffer + futex/eventfd 即可，并不需要 Redis 这类组件。作者本人现身回复，强调关键差异在于触碰元数据而非数据页，且正在开发基于 inotify、kqueue 或 mmap 共享内存的真正无轮询方案。还有人提到与之类似的 Rails 生态项目 Litestack（已停止维护），以及通过监听 -wal 文件 IN_MODIFY 事件实现类似功能的实践经验。Oban 已支持 SQLite 也被多次提及。

16. Claude Opus 4.7 能从未发表的文字片段识别出作者身份

作者 Kelsey Piper 测试 Anthropic 新发布的 Claude Opus 4.7 时发现，模型能从她从未公开发表过的文字片段中准确识别出作者身份。她在隐身模式、API 调用、以及朋友的电脑上分别测试，排除了账户记忆和上下文泄露的可能。

测试覆盖多种文体：125 词的政治评论开头、教育领域学生进度报告、电影评论（她从未公开写过的领域）、奇幻小说草稿，甚至是 15 年前写得相当糟糕的大学申请文书——Opus 4.7 都准确识别为 Kelsey Piper。同期对比中，ChatGPT 和 Gemini 在不同样本上表现各异，有时也能命中。

有趣的是，模型给出的「推理」往往是事后编造的无稽之谈。例如 Claude 声称有效利他主义者「众所周知」喜爱某部电影，ChatGPT 则说大学申请文书「明显出自一位未来的复杂政策解释者之手」。作者认为模型实际上在捕捉难以察觉的文体微特征，再用类似福尔摩斯式的推理来包装解释，这种事后合理化本质上仍是一种幻觉。

作者站在支持网络匿名的立场，认为匿名是少数群体（包括她自己作为同性恋者）的保护机制，但她担心这种识别能力的普及会让网络匿名变得不可能。

HN 讨论中多位用户复现了实验。一位作者用 Kimi K2.6 模仿 James Mickens 写文，Opus 4.7 准确识别出是「对 Mickens 风格的模仿」。另一名用户喂入 Simon Willison 的博客文本，模型从「(via Lobsters)」归属风格、内联更新括注、链接和引用习惯等线索精准识别。也有不那么知名的博客作者被命中。一位物理学家几年前测试原始 GPT-4 时，模型会用他的语气续写并签上他的名字。讨论中也有声音认为这种能力应当加上护栏，避免普通用户一键扒出匿名作者；另一派则认为网络匿名本就是幻觉，ISP、运营商、Cloudflare、Google 等早已掌握指纹。

17. Postgres 写入扩展性基准：单机 14.4 万 TPS

DBOS 团队针对「Postgres 能否扩展」这一常见疑问，发布了一份针对工作流执行场景的写入吞吐基准。测试环境为 AWS RDS db.m7i.24xlarge（96 vCPU、384GB 内存、120K 预置 IOPS 的 io2 卷）。

在向一个三列表（UUIDv7 主键、TEXT 数据列、时间戳）独立事务插入数据的极简场景下，单台 Postgres 实例可持续支撑约 144K 写入/秒，相当于每天 120 亿次写入或 43K 工作流/秒（约 40 亿工作流/天）。瓶颈并非 CPU 或 IOPS，而是 WAL 刷盘：通过 pg_stat_activity 观察发现，任意时刻总有一个进程在执行组提交的 fsync，其余大多数进程在等待 WAL 锁。这是写密集负载的常见瓶颈，因为 Postgres 只有一份 WAL，所有写入都必须串行通过它。

DBOS 选择 Postgres 作为持久化工作流执行的存储，因为每个工作流需要多次写入数据库以检查点输入、输出和每一步结果，写入吞吐直接决定上限。

HN 讨论分歧明显。最尖锐的批评指出 144K 这个数字具有误导性：从图表看，在 120K 写入/秒后 p50 延迟从 10ms 飙升到 1 秒——两个数量级的延迟跳变意味着服务器已完全饱和，对 OLTP 完全不可接受，更合理的报告值应是 120K 甚至更低，并以 p95 为口径。另一名工程师分享了正在用 Postgres 替换 MySQL 的实战体验：表行数到几千万后，多行插入因索引增长显著变慢，过亿后退化更明显，质疑线性扩展的假设。还有评论指出，写入 QPS 不是关键指标，索引碎片、死元组累积等才是真正的长期问题。也有人补充可通过调整 checkpoint 设置进一步提升吞吐。

另一类评论关注横向扩展和高可用：Postgres 单机性能强，但要做到无停机升级、横向扩展依然困难。DBOS 与 Temporal 的对比也被提及，有用户称 Temporal 像 Kubernetes，DBOS 更像 docker compose，更易上手。

18. 用 LLM 逆向工程 SimTower 并复刻为协作版

作者 Patrick Hulin 用大约一周时间，借助 LLM 逆向了童年喜爱的电梯模拟游戏 SimTower，并上线了支持协作合作模式的克隆版 towers.world。

最初策略是「静态分析」：用自研框架 reaper 把 LLM 接到 Ghidra，让模型从低级函数和数据结构出发，逐步构建对二进制的理解，最终产出一份可用于干净室重写的规范。这条路失败了。作者总结出当前 LLM 静态分析的三大缺陷：一是过早下结论后难以放弃错误猜测，且常用「runtime entity」「lower-atrium band」之类奇怪的抽象术语污染整个数据库；二是即便 prompt 明确要求逐函数命名所有局部变量和参数，模型仍然偷懒不做；三是难以分离概念设计与实现细节——要么过度纠缠位字段布局，要么抽象到无法据此重新实现的程度。根本问题是反编译输出过于冗长，上下文窗口反复压缩，逆向工程必需的精确细节在压缩摘要中丢失。

随后转向「动态分析」，灵感来自 Christopher Ehrlich 的 SimCity 移植和 banteg 关于 Crimsonland 的实验。由于 SimTower 已无法在现代硬件运行，作者让 Claude Code 基于 Unicorn 引擎构建模拟器，为游戏调用的全部 195 个 Windows 3.1 API 函数编写 mock。这部分工作 Claude 半小时完成、99% 正确，作者称之为又一次「LLM 进展震撼时刻」。之后通过让 Claude 配置小型塔楼、调用模拟二进制中的函数、定时记录状态快照，与重写实现进行差异比对，从而让 LLM 有可攀爬的「梯度」自动修复偏差。

作者特意避开函数级移植，因为 API 可能受版权保护，过于贴近的二进制复制相比干净室设计有更大法律风险。

HN 讨论中网友对 SimTower 充满怀旧情感，提到鲜为人知的续作 Yoot Tower（Don Hopkins 已获 Yoot Saito 授权开源但源码尚未公开），讨论了 Zelda 类似 RE 项目至今未被任天堂下架的判例，以及 Opus 4.7 在错误路径上难以纠偏的体验问题。也有人对项目消耗大量 token、需要订阅 Claude Code $200/月计划表示并不算太贵。

19. 用 DuckDB 做全文搜索：能力与局限

作者在 DuckDB 系列第二篇博文中，实测了 DuckDB 的全文搜索（FTS）扩展能力，对比了与 Elasticsearch、Postgres（含 pgvector、pg_search）的差异。

DuckDB 的 FTS 通过 INSTALL fts; LOAD fts; 启用，使用 Okapi BM25 算法对查询结果打分，可调参数包括词频权重 k₁ 和文档长度归一化 b。索引层面支持词干提取（stemming）、停用词移除和重音符号归一化。作者提到底层依赖 Snowball 项目，并演示用 Python 的 snowballstemmer 库调试意外的词干结果——例如 mouse 词干为 mous，但 mice 仍是 mice，这就解释了为何某些词形不会匹配。

实测场景是搜索一个包含 13010 封 .eml 邮件的归档。DuckDB 无法原生导入 .eml，作者用 Python + uv + BeautifulSoup 做预处理，提取正文、关键 header（用于过滤营销邮件和事务邮件）后输出 JSON 供 DuckDB 加载。

作者认为 DuckDB FTS 是不错的起点但功能尚浅。最大遗憾是缺少类似 Postgres ts_headline 的查询词高亮定位能力，作者只能借助 tmux 或 grep 笨拙地查找匹配位置。可预见未来会增加短语查询、向量、可插拔同义词词典等功能。

HN 讨论中 DuckDB 受到普遍好评。有人构建了基于 DuckDB-WASM 的浏览器内 LLM SQL 基准测试系统；有人用 DuckDB 配合 S3 上的 Parquet 完全替代 Cloudwatch、Loki 等日志系统，避免 HA 计算和云税成本；有人盛赞 DuckDB 可直接指向几乎任何数据源生成 SQL 表，或挂载来自不同数据库系统的实例做联合查询。安全方面有讨论指出 DuckDB 默认在某些功能下会自动下载并运行扩展，存在不必要的风险。也有人询问 DuckDB 与 Clickhouse local 的对比体验。

20. Jeff Bridges 推出全新机械式全景胶片相机 WideluxX

演员 Jeff Bridges 主导的 WideluxX 项目终于上线预售，首批限量 350 台，定价约 4400 美元。这是一台向经典 Widelux 摆动镜头全景相机致敬的现代复刻产品，强调「不是怀旧姿态，而是与现代工具并存的另一种创作方式」，在德国进行精密制造。

技术规格上，WideluxX 使用标准 35mm 胶片，单张影像尺寸 24×58mm，36 张胶卷可拍约 21 张，搭载 26mm f/2.8 镜头，快门速度 1/15、1/125、1/250 秒，视角 140° 对角（126° 水平），光圈 f/2.8–f/11 手动控制，焦点固定从 1.5 米到无穷远，重量约 880 克。

核心机制是「摆动镜头 + 缝隙快门扫描」：旋转镜头通过窄缝按顺序逐段曝光胶片，整个 1/15 秒挡在真实世界中持续约 2.5 秒完成扫掠，但胶片上每个区段只接受短暂曝光，因此能在通常需要三脚架的速度下手持拍摄。由于镜头始终保持中心旋转，全幅曝光均匀；由于是单次连续曝光形成的全景，不存在数字拼接的接缝伪影或对齐错位，而运动中的主体会自然融入画面，呈现的是「时间的延续」而非冻结的瞬间。胶片可通过任何常规冲洗流程处理，再用现成 35mm 扫描仪数字化。

HN 讨论以情感共鸣和价格质疑为主。有用户表示等了五年，本以为能压在 1000 美元以下，4400 美元加 175 美元运费让其大失所望；多人对 Bridges 的诚意和工程投入表示尊敬。来自 Hasselblad XPan 用户的批评较多，认为 XPan 拥有更优的镜头、更少畸变、可换镜头，二手价格虽贵但仍是首选——只是 XPan 依赖电池快门，未来可能变成废铁。也有人偏好 Instax wide 或 6x17 大画幅全景方案，认为同等价位可获得更大底片和更多功能。德国民法关于定制商品撤回权的勾选条款也引发好奇。整体上社区认可这种小众机械艺术品的存在价值，但价格门槛让多数人保持观望。