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

HN 每日深度阅读 · 2026-06-22

本期聚焦技术与人的张力：从Anthropic身份验证、iOS指纹窥探到巴西预警系统遭入侵，信任与隐私边界持续收紧；AI正同时冲击招聘信号、童书出版与开源商业模式，部分讨论延伸到代码抽象、nil检查等工程审美；新闻疲劳、维护者倦怠与父亲节温情则提醒。

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

共 20 篇 · 约 13,185 字 · 约 33 分钟读完

1. Claude 推出身份验证：信任与隐私的双重争议

Anthropic 在其支持页面宣布，将为 Claude 的部分使用场景引入身份验证流程，用户在访问某些功能或作为常规平台完整性检查时可能被要求提交政府签发的实体身份证件照片，并通过第三方供应商 Persona 完成验证。Anthropic 声称仅将验证数据用于确认身份，不会用于训练模型，但同时承认 Persona 可以使用相关数据来”改进其防欺诈能力”。验证失败的用户可能会被永久锁定，账户也可能因安全原因被封禁，用户需通过申诉表单请求复审。

HN 评论区反应强烈，多数评论持批评态度。有用户指出该页面其实从今年早些时候就已存在，并非全新政策，但近期围绕美国政府对 AI 公司施压的新闻让这一举措显得格外敏感。一些非美国用户表示，叠加美国对前沿模型的出口限制（如 Fable 限制），他们正在加速转向 Mistral 等替代品，认为继续付费给 Anthropic 是”贬值投资”。多名评论者提到 OpenAI 也有类似机制，且失败后不允许重试，导致用户被永久排除在顶级模型之外。

供应商 Persona 本身也是争议焦点：有评论指出 Discord 曾因用户反弹而放弃使用 Persona。还有人将”AI 中性”与早年的”网络中性”类比，认为这是危险的先例——服务商不仅要求政府身份证，还可能基于使用方式静默封禁用户。多位评论者宣布已取消订阅并申请退款，理由是不愿将身份证件交给一家与现政府关系密切的公司，担心”合法法律程序”条款被用于秘密构建外国用户档案。也有务实派指出，地缘对手能轻易获取大量伪造美国身份证，此类验证只会伤害普通用户而无法阻止真正的恶意行为者。

2. Loupe：让用户直观看到 iOS 应用能”窥探”什么

Loupe 是 Mysk 研究团队发布的一款开源 iOS/iPadOS 应用，旨在向用户展示原生应用在无需任何特殊权限的情况下，能够通过公开 iOS API 读取哪些设备指纹数据。应用将信号分为三类：被动信号（任何应用无需提示即可读取，如区域设置、时区、屏幕、电池信息）、需权限信号（触发系统权限弹窗，如通讯录、照片、位置）和高级信号（通过 canOpenURL 进行 URL scheme 探测、利用 Keychain 在重装后保持身份等侧信道用法）。所有读取的数据都仅在本地展示，不上传不同步。Loupe 的代码几乎完全由 AI 编程工具生成。

HN 讨论集中在对 iOS 隐私现状的震惊与反思上。多名评论者对”iPhone 上次设置或抹除时间”这类高精度指纹信号表示愤怒，认为系统应当对这类信息进行模糊化处理。一位评论者纠正了关于”已安装应用枚举”的说法：iOS 应用并不能列出全部已安装应用，只能通过 LSApplicationQueriesSchemes 在审核时声明具体要查询的应用，Apple 正是因为指纹和隐私风险才加上这一限制。即便如此，开发者仍可针对 Tinder、Bumble、Hinge 等特定应用进行探测，“伴侣是否出轨即服务”被举为可货币化的滥用场景。

更深层的讨论指向了 Apple 应用模型的根本缺陷：为什么应用默认就能联网？多人认为联网权限应当是 opt-in，因为阻止数据外泄能从源头消除大部分危害。也有评论指出 VPN 启用状态可以通过枚举网络接口名间接推断，这本不该被允许。卷剪贴板 changeCount、卷创建日期等也被点名过于精细。有人对比 Android 表示 iOS 现状仍更好，但同时希望 Android 上也能出现类似工具。还有评论者重申最根本的解决之道是”不要采集多余数据”，但在数据即金钱的当下，这一倡议被视为唐吉诃德式的理想。

3. 大脑的演化无法承受当今规模的坏消息洪流

这篇来自 The Conversation 的发展心理学评论文章指出，新闻疲劳并非懒惰或公民意识衰退，而是人类大脑面对从未被设计去应对的环境的可预测反应。根据路透研究所 2025 年数字新闻报告，69% 的加拿大人和 40% 的全球受访者至少偶尔会回避新闻，后者为有记录以来最高值。

作者从演化心理学角度解释了”负面偏好”（negativity bias）的起源：人类的认知架构在漫长岁月里被塑造为优先关注威胁，因为忽视真实威胁的代价是死亡，而过度反应只是浪费几分钟警觉。但人脑并未改变，改变的是它被要求扫描的世界规模。一项发表于《Nature Human Behaviour》的研究分析了超过 10.5 万条真实新闻标题、近 600 万次浏览，发现每增加一个负面词汇就会提升点击率，正面词汇则相反。研究者还提出了”问题性新闻消费”（PNC）的临床框架，2022 年的研究发现 17% 的美国成年人存在严重 PNC，其中 61% 报告身体不适。对少数族裔群体而言，由于反复目睹针对自身群体的伤害，认知负荷更重。

文章建议的应对方案不是回避，而是管理消费方式：限定新闻时段、选择深度长文而非碎片化推送、区分信息与行动（研究表明意识与行动力之间的鸿沟是心理困扰的最强预测因子之一）、警惕”愤怒诱饵”内容。

HN 评论区观点多元。有评论者认为问题在于人们对世界运作有不切实际的期待。Neil Postman 的”躲猫猫世界”被引用，指出现代人对那些”无能为力”的事件依然焦虑。多位评论者分享了自己的策略：只读本地新闻、把新闻调成黑白以削弱情绪冲击、按地理距离和”爆炸半径”对新闻进行排序。一条本地标语”关掉新闻，爱你的邻居”获得不少共鸣。也有反对声音认为，看到世界的混乱反而让人更珍惜家中的平静，是一种”接地气”的体验。

4. Sandi Metz 经典论断：宁可重复，也不要错误的抽象

这是 Sandi Metz 于 2016 年发表的著名文章，源于她在 RailsConf 2014 演讲中的一句话：“重复远比错误的抽象便宜”。文章描述了一个普遍模式：程序员 A 发现重复代码，提取出抽象；时间流逝，新需求出现，程序员 B 因为荣誉感保留现有抽象，添加参数和条件分支以适应新场景；更多新需求接连到来，更多参数和条件被加入，代码变得难以理解；最终接手的程序员陷入泥沼。

Metz 指出，沉没成本谬误让人们倾向于继续维护错误抽象。她给出的解决方案是”前进的最快方式是后退”：将抽象内联回每个调用方，根据每个调用方的参数确定其实际执行的代码子集，删除不需要的部分。这样既移除了抽象也移除了条件分支，让每个调用方只保留自己需要的代码。一旦完全移除旧抽象，就可以从零开始重新识别重复并提取新抽象。她总结道：“当抽象错误时，最快的前进方式是后退。这不是撤退，而是朝更好的方向前进。”

HN 讨论非常热烈。一派观点支持”单一真相源”原则，认为如果重复代码分歧会导致 bug，仍然必须重构，但同意如果不违反单一真相源，抽象只是便利性问题；如果函数需要多个标志位定制行为，往往是抽象错误或违反单一职责原则。一位 RTS 游戏开发者分享了具体案例：他在处理多种精灵图加载时纠结于共同抽象，最终拆成 UnitLoader、CorpseLoader、EffectLoader 三个独立类继续推进。

多位资深开发者表达共鸣：欠工程化代码库比过度工程化的容易维护得多；DRY 原则若被盲目遵循会产生最糟糕的代码。一位 40 年经验的开发者反思，年轻时高估了自己的理解和抽象能力，需要见过更多模式实例才能做出好选择，这意味着要习惯于让重复存在一段时间。也有评论者表示从 OOP 转向函数式编程后，重复问题就少见了。

5. Beyond All Reason：致敬 Total Annihilation 的免费开源 RTS

Beyond All Reason（BAR）是一款基于 Recoil RTS 引擎、致敬经典 RTS《Total Annihilation》的免费开源即时战略游戏，目前处于 Alpha 阶段。游戏包含两大对立阵营 Armada 和 CORTEX，以及实验性的 Legion 阵营，覆盖机器人、载具、飞行器、舰船、气垫船等多种单位类型，并提供工厂、防御工事、建筑物等丰富建造选项。游戏还支持外星 Raptor、Scavenger 等 PvE 模式。项目正朝着 Steam 发布迈进。

HN 讨论既充满怀旧情怀也不乏批评。多位老玩家盛赞 BAR 是”史上最佳 RTS”，技术上令人印象深刻，性能和用户体验超越当下许多 3A 工作室作品，仍在积极开发且完全免费。一位前 StarCraft 2 职业选手解说的 40v40 对战视频被推荐为范例。Total Annihilation 的怀旧氛围被反复提及——一位用户的表亲曾在 Cavedog 工作，让他童年得以接触这款游戏，留下大量美好回忆。

然而对玩家社区的批评同样集中。多名评论者称 BAR 的玩家社区相当恶毒：如果不遵循当月的固定 meta 构建顺序，玩家会被队友投票踢出并被夺走单位；前线一旦崩溃，按”礼节”应当投降而非让后方经济玩家尝试翻盘；按资历选地图位置导致老玩家拿低压力位置，新玩家被迫接手困难位置，形成恶性循环。一位玩家因此停止游玩，另一位指出 16 人对战中只要遇到少数极端不友善的玩家就会败坏整场体验。

新玩家建议方面，多人推荐先看 YouTube 视频、单人或对 AI 练习，再寻找新手大厅，避免直接进入老玩家主导的对战。也有人指出 BAR 近期出现争议：部分核心管理员声称所有权并与发行商合作，将这款免费开源游戏在 Steam 上以付费形式销售（提供免费 demo），引发社区分裂。寻求更稳定社区的玩家可考虑 Zero-K（另一款相关开源游戏）或 FAF。还有玩家怀念原作那种”缓慢推进的永恒战争”的忧郁氛围，认为 BAR 偏 PvP 点击竞速，希望能有更具单人或 PvE 体验的 Spring 引擎模组。

6. 开发者不懂 CORS：从 Zoom 漏洞看普遍误解

Chris Foster 于 2019 年撰写的这篇文章以 Zoom 当时被曝光的零日漏洞为切入点，论证大量 Web 开发者并未真正理解 CORS（跨源资源共享）。安全研究员 Jonathan Leitschuh 发现 Zoom 在用户本机 localhost:19421 上运行了一个 Web 服务器，Zoom 网站通过加载尺寸不同的图片来传递状态码，以此绕过 CORS。原始报告错误地声称”浏览器对 localhost 服务器忽略 CORS 策略”，但作者指出 Chrome 实际上对 localhost 同样尊重 CORS 头——开发者用 Create React App 时跨端口请求就是依赖这一点工作的。

作者推断 Zoom 是因为不理解 CORS 才设计了这个图片黑科技来绕过它，结果让所有网站——而不只是 zoom.us——都能触发原生客户端的操作并读取响应。安全的实现方式应当是：localhost 服务器实现 REST API，并设置 Access-Control-Allow-Origin 头指向 https://zoom.us，同时在 zoom.us 上设置 CSP 头阻止在 iframe 中渲染。文章也批评了 Zoom 自动打开摄像头麦克风的产品决策违背了”软件应可预测”的 UX 原则，对比 Google Meet 在应用内显示确认弹窗的做法。

HN 评论区颇具讽刺意味地”亲自证明了作者的观点”——一条高赞评论指出文章本身就误解了 CORS。CORS 并不限制任何东西，它是放宽了默认限制：任何网站的 JavaScript 仍然可以向 localhost:19421 发送请求，Access-Control-Allow-Origin 只是允许 zoom.us 的 JavaScript 读取响应。请求本身依然会发生，后端必须确保它们不会引起副作用。

多位评论者承认 CORS 难以理解：标准和头部不断变化，开发者通常只是”折腾到能用就发布”。要理解 CORS，必须先理解同源策略（SOP）。MDN 上的 CORS 文章和同源策略文档被推荐为最佳入门资料。一位评论者尝试将 SOP 作为面试题，但发现绝大多数候选人都不熟悉。还有人提到 CORS 调试痛苦：浏览器收到的错误信息被有意削弱，CORS 失败场景难以与其他失败模式区分。一位后端开发者坦言因日常不接触前端，CORS 是他需要定期”复习”的话题。

7. 15 分钟在家莱姆病蜱虫检测试剂盒亮相

《波士顿环球报》报道了一款名为 LymeAlert 的家用快速检测试剂盒，旨在让被蜱虫叮咬的人能够在家中 15 分钟内检测从身上取下的蜱虫是否携带莱姆病病原体，避免去急诊室的成本和等待。该产品通过研磨蜱虫样本并使用反应试纸条来检测莱姆病相关细菌。

HN 评论区话题广泛。一位用户分享了令人心酸的经历：直到二十多岁才知道蜱虫的危害，此前多年在鹿出没的灌木丛中翻滚，整个三十多岁都在与无法解释的焦虑、疲劳、睡眠不佳和认知衰退作斗争，做遍各种血液检测、睡眠研究、补充维生素都无果，怀疑可能患上了慢性蜱传疾病但找不到答案。

另一类讨论聚焦于 α-gal 综合征（红肉过敏综合征），一位用户刚在伊利诺伊州北部从背上拔下一只 Lone Star 蜱虫，担心这个夏天可能因吃汉堡而过敏致命，惊讶这种蜱虫已扩散至北方。多位评论者指出该检测的实际效用存疑：找到的蜱虫阴性不代表没找到的也阴性；蜱虫阳性也不代表已感染宿主，因为蜱虫通常需附着到充血状态才会传播疾病，而展示的蜱虫均未充血。

有评论者表示常备多西环素，被鹿蜱叮咬后服用，并附上美国国立医学图书馆的预防性用药指南链接。辉瑞最近也宣布计划向监管机构提交其三期临床试验后的新型莱姆病疫苗。德国市场已有类似产品，三只装售价约 30 欧元，可检测多种伯氏疏螺旋体。一位评论者建议出现关节疼痛等异常症状时既要查莱姆病，也要排查更常见（约 5% 人群）的 α-类胰蛋白酶血症。还有人对”去急诊室处理蜱虫叮咬”的说法提出质疑，认为这并非常规做法。一条戏谑评论喜欢”研磨蜱虫”这个操作，称之为”罪有应得”。一条颇具想象力的推测认为，莱姆病可能与哺乳动物共同进化，使其”对蜱虫上瘾”——每次再感染引发的发烧会暂时重置不适感，从而促使宿主持续暴露于蜱虫以获得”健康”感受。

8. 巴西手机大规模收到未授权预警短信，疑因黑客入侵

2026年6月20日，巴西全国手机用户收到了一条未经授权的”极端警报”类型推送，内容仅包含”misantropia”（厌世）一词。巴西相关机构在声明中表示，这很可能是一次黑客攻击事件。

根据HN社区分享的信息，攻击者疑似通过窃取VPN凭证进入了预警系统。被盗凭证来自一台运行已停止支持的Windows 7系统的个人电脑，该电脑没有安装杀毒软件，曾搜索过Windows 10和Office 2019的破解激活工具，恶意软件似乎通过一个恶意游戏安装包植入。更具讽刺意味的是，攻击者使用CapCut录制了演示视频，过程中暴露了自己的身份证件和头像。如果这些信息属实，该事件暴露出令人惊讶的系统安全薄弱程度——攻击者本可造成更严重的危害，但仅仅是向全国发送了一条文字消息。

HN讨论中，多位用户提到类似的历史案例：2018年夏威夷的虚假导弹警报、加拿大Pickering核电站的错误警报，以及2017年达拉斯紧急警报系统被攻击事件。有评论指出，许多新设备的预警通知系统会让用户养成忽略所有警报的习惯——例如Amber警报常常涉及数百英里外的事件，红旗天气警告频繁触发等，反而削弱了系统的实际效用。

关于”hacker”一词的使用，有评论引用经典定义指出，媒体常将”hacker”和”cracker”混为一谈，真正的hacker是创造者，而入侵系统的破坏者应被称为cracker。

另有讨论涉及类似的滥用风险：波兰的电话系统允许伪造来电显示号码，已被诈骗团伙广泛利用；美国新增的”总统警报”功能也引发了对未来潜在滥用的担忧。一位评论者认为，赋予政府向全国大规模发送消息的能力，是Google和Apple给各国政府的最糟糕的”礼物”之一。

9. AI让招聘流程两端同时失灵：简历与面试都失去信号价值

《哈佛商业评论》文章指出，生成式AI正在系统性地破坏企业早期招聘流程的两端。作者团队历时一年开展运营研究，访谈了来自87家公司的120位招聘领导者，分析了6380场首轮筛选录像，发现简历和实时视频面试这两个传统筛选环节都已被AI辅助工具有效”破解”。

在筛选漏斗顶端，AI生成的简历和求职信使得文档失去信号价值——候选人能在几分钟内生成针对岗位高度优化、关键词丰富的内容。研究还发现AI筛选工具本身存在”自我偏好偏差”：来自马里兰大学等机构的2025年研究表明，AI筛选系统会优先选择与其自身输出风格相似的简历，匹配度高的候选人入围概率高出23%-60%。

在漏斗底端，Final Round AI、Parakeet、Cluely等实时面试辅助工具可在视频面试中提供答案覆盖层，向候选人喂送脚本化回答。Cluely在2025年获得530万美元种子融资，其创始人此前因开发该工具的早期版本被哥伦比亚大学停学。文章引用Gartner预测：到2028年，四分之一的候选人资料将部分或完全造假。Google和McKinsey已开始重新引入面对面面试。

SHRM报告显示，非高管职位的平均招聘成本为5475美元，高管职位接近36000美元；Gallup估计替换一名员工的成本为年薪的1.5至2倍。一位招聘官表示已停止在招聘网站发布职位，仅做主动外联，但这也无形中削弱了招聘多样性。

HN讨论中，有评论分享了亲身经历：某科罗拉多公司的”AI面试”实际上是耗时一小时的CAPTCHA。多位评论者质疑为何科技公司不愿恢复线下面试。另有评论指出招聘流程本就长期存在问题，AI只是让双方的不对称同时显露。还有招聘C++初级开发者的雇主反映，许多简历自称”中级”水平的候选人甚至不懂指针和引用，通过30-60分钟的当面交流就能轻易识别。

10. 化石燃料占海运货物40%吨位，却消耗一半航运能源

CleanTechnica刊文指出，海运燃料讨论通常从错误的对象出发——人们直接对照当前的船用燃料需求，讨论氨、甲醇、氢、LNG、生物燃料或合成燃料能否替代，却跳过了更核心的问题：在能源转型改变船舶运载货物后，还会剩下多少海运燃料需求。

文章核心论点是：化石燃料货物不仅在质量上巨大，对航运能源更具不成比例的重要性。化石燃料约占海运吨位的40%，但在作者模型中相当于约一半的海运货运能源，因为煤、石油和天然气主要是长途散货贸易。运送一吨废金属短距离和跨洋运输一吨石油或LNG对运输能源问题来说并不相同——吨公里才是更恰当的衡量模型。

在严肃的能源转型中，煤炭、石油和天然气需求都会下降，意味着运送化石能源的散货船和油轮减少。海运业不必为所有这些运输工作寻找一对一的替代燃料，因为相当大份额的工作本身就会消失。原铁矿石也是相邻的暴露品类，随着中国建筑节奏放缓、电弧炉份额上升、还原铁可在富含可再生能源的矿区附近完成，原铁矿石航运不太可能延续过去的增长模式。

文章主张采用”分母优先”思路：先估算化石货物减少、可电气化短途航线增长、运营效率提升后剩余的燃料燃烧工作量，再讨论残余液体燃料。短途海运、内河航运、渡轮、港务船舶等更适合电池、岸电和混合动力运营。Nature Energy 2026年的研究表明短途海运电气化的可行空间出乎意料的大。氨和氢被认为是较弱的核心方案，因为它们要求行业围绕在成本、安全、能量密度、生命周期核算上存在重大问题的分子建立昂贵的新燃料链。

HN评论指出该数据虽然较高但仍属小份额：海运占总石油使用量很小一部分，公路运输约为海运的20倍，航空约为2倍。一桶石油约40%的能量在到达油箱前损失，主要在精炼和分发环节，跨洋运输原油占比反而较小。有评论赞赏作者类比阿姆达尔定律的论证方式。也有评论批评文章风格疑似LLM生成，存在过于简洁的句式和”努力显得聪明”的痕迹。

11. AI的”十万个为什么”：从亚马逊童书封面看LLM输出的同质化

作者lcamtuf通过一个鲜明实例反驳”无法区分人类与AI生成文本”的观点。他在亚马逊搜索”100000 whys”，结果出现约150本童书封面拼贴图——这些书甚至有些是儿童文学类的畅销书。

作者认为，这些书名和封面单独看并没有什么”非人类”特征，但整体观察立刻能识别出AI的批量产物。原因在于AI工具的”准确定式”特性：如果100个”作者”用相似提示（如”为儿童生成一本参考书”）调用同一AI工具，模型在约80%的情况下会产生功能上几乎相同的输出。

封面相似性远不止于书名——拼贴图顶行所有封面都在左上角有一只咆哮的恐龙；图中还反复出现红白卡通火箭、金毛犬、狮子等图案。连作者署名都呈现集群特征：Ethan Bright、Nolan Bright、Pamela Bright、Daniel Bright、Thomas Bright、Andrew W. Bright、Mayan Bright、Mary Bright、Levi Bright——一个异常”才华横溢的大家庭”。

作者的核心洞察是：LLM写作的辨识度并非源于其个别表达与人类不同，而在于它们面对几乎任何普通提示都会诉诸同一套复杂的表达习惯。这是模糊信号，但在非正式场合可以信赖直觉判断。当生成内容的成本远低于消费内容的成本时，传统在线互动模式便会崩溃，这种识别本能变得越来越重要。

HN讨论中，多位评论者扩展了这一观察。有人比喻：让1000个人写1000本书是1000种不同的人生经历，而让LLM写1000本书只是在和3-5个模型对话，它们训练数据相似、响应模式趋同。另一位评论提到生成单篇博文时AI令人印象深刻，但连续生成50篇就会显现相同模式；其Notebooklm生成的播客讨论已可预测主持人会在何处”反驳”。还有评论指出”模式坍塌”（mode collapse）现象，这可能源于指令微调。有评论者发现在编程领域同质化反而是优点。另一个有趣的辨识技巧被提出：AI图像生成器无法正确绘制铁轨——轨距、轨枕间距、道岔几乎全错。

12. HN父亲节专帖：开发者社区分享与父亲相关的故事与感悟

这是Hacker News上一个简单的”Tell HN: Happy Fathers Day”父亲节祝福帖，吸引了227分和30条评论，社区成员分享了关于成为父亲或回忆自己父亲的个人故事。

多位评论者描述了父亲对其性格和职业的影响。有人回忆父亲一生致力于修理家中各种物品，是出于对事物运作方式的真实好奇——这种无畏面对挑战、相信能够成功的态度深深影响了自己；评论者发文当周正受此激励修理自己的咖啡机。另一位用户分享了父亲出现在第一期Dragon User杂志封面上的链接，称在各种微型计算机环绕中成长是充满乐趣的经历。

有评论分享了Brunt（工作靴和工装公司）创始人的父亲节邮件，认为这是少有的兼具企业气质和人情味的营销内容：创始人的两个儿子第一次都能穿上品牌靴子，小儿子虽然实际尺码偏大但仍骄傲地穿着到处奔跑。

一位80天宝宝的新手父亲表示，这是他人生中最不可思议的日子，让他想要在前所未有的方式上变得更有抱负和活力。另一位评论者描述了女儿成长中的诸多温馨场景：女儿打翻妈妈的包、赶BART去工作、加州大学伯克利分校办公室、夏季游泳课，以及多年后女儿带他重走当年路线，他感慨自己年轻时如何完成那段陡峭徒步。

一条实用的健康建议得到关注：年轻父亲应购买带足弓支撑的鞋垫，因为足底筋膜炎悄悄困扰着许多带娃父亲，抱孩子奔跑会加重足部负担，约50美元的鞋垫可有效预防。

也有评论提醒：父亲节在各国并非同一天庆祝，并非所有国家都过这个节日。

13. 在Proxmox VE中以简单方式运行MicroVMs：pve-microvm项目

作者运行混合Proxmox集群多年，节点配置差异巨大——从2GB内存的Atom x5-Z8350到128GB内存的i7-12700。在编写agentbox及代理沙箱热潮中，作者厌倦了LXC容器与完整VM之间的折衷，开发了pve-microvm——一个将QEMU的microvm机器类型作为Proxmox VE一等管理客户机的Debian软件包。

项目背景在于Proxmox原生提供的两个选项各有局限：LXC容器启动迅速、共享主机内核、效率出色，但隔离性不足——一个容器中的内核漏洞会危及全部，无法运行不同OS，嵌套Docker复杂；完整VM通过KVM/VT-x提供硬件隔离，但要经过SeaBIOS或OVMF、GRUB、检测模拟传统设备，通常需5-10秒到达登录提示。

QEMU的microvm机器类型（最初为Firecracker风格工作负载开发）去除了所有这些环节：无BIOS、无GRUB、无传统设备，直接内核启动进入最小virtio环境。结果是亚300ms启动到完全联网客户机，运行在自己的KVM硬件隔离边界内。

pve-microvm是一个单独的.deb包，安装时修补Proxmox的qemu-server Perl模块。设置machine: microvm后，标准config_to_command函数委托给作者的MicroVM.pm，构建几乎完全不同的QEMU命令行——无芯片组模拟、无PCI桥接、无VGA。客户机获得单个串行控制台、virtio块设备和virtio网络接口。包含12MB的预构建Linux 6.12.22内核（含virtio、vsock、virtiofs、9p、Docker所需模块）、1MB的initrd、pve-microvm-template工具、pve-oci-import工具、Web UI扩展和确保补丁先于pvedaemon应用的systemd服务。

性能方面，SmolBSD（使用virtio-mmio传输的NetBSD客户机）启动需31ms。带Docker和QEMU代理的完整Debian在8秒内就绪，多数时间花在首次apt包安装上。后续启动稳定在300ms。项目目前支持21种客户机操作系统，从Debian到NetBSD甚至Plan9——作者确认Plan9在microVM中确实可运行。

HN讨论中，Proxmox官方开发者回应称他们在2020年评估过microVMs，当时认为维护成本不值得，但随着原生动态负载均衡和亲和性规则的引入值得重新评估。多位评论者讨论了相关工具：基于libkrun的smolvm、microvm.nix、crun等。GPU直通仍是大家关心的痛点——virtio-gpu和Venus提供Vulkan支持但CUDA仍缺失。有评论赞赏作者的工作但担心修补pve-daemon的方式可能在Proxmox更新时出问题。

14. Windows UI演变史：点击未关联文件时会发生什么

博主回顾了从Windows 386/2.11到Windows 10各版本中，文件管理器点击未知扩展名文件时弹出对话框的演变。

Windows 386/2.11（1989年）直接给出拒绝消息——“ABC.OMG不可执行”。该版本已有文件类型关联概念，但没有配置UI，只能在WIN.INI中设置。Windows 3.1（1992年）改进了情况，仍然拒绝但告知用户存在文件类型关联概念及配置位置，提供基础但实用的对话窗口。Windows NT 3.1（1993年）和Windows for Workgroups 3.11基本相同。

Windows 95（1995年）是重大进步——弹出对话框可直接选择所需程序，无需导航到其他位置。Windows 98、Windows ME和Windows 2000保持了这一行为。

Windows XP（2001年）开始引导用户使用某种Web服务，体现了”互联网无处不在”的时代背景。读者补充信息指出，该服务仅在Internet Explorer中打开网站，将文件扩展名作为查询字符串发送，自2006年起已停止服务。该服务实用性不高，可能只列出微软认证合作伙伴的程序，连流行的.3GP格式都无法识别。Windows Vista（2006年Beta版本5600）外观略有差异但功能相同。

XP/Vista与Windows 10之间存在跨度，作者未涉及Windows 7和8。Windows 10（2015年）进入”扁平化一切”时代，用户难以分辨哪些元素可交互，连窗口装饰都消失了。“在Store中搜索应用”实际上是按钮，“其他应用”通过颜色（类似Web链接）表明可点击，列出已安装应用——现在称为”App”。第三个选项”在此PC上查找其他应用”需要滚动窗口才能发现。

HN讨论展开多个有趣话题。有评论指出现代Windows上若卸载新版记事本以使用旧版，无法通过常规方式将.txt关联到notepad.exe，需要注册表小技巧。一位评论者认为Windows 9x是Windows的巅峰——一切清晰、信息密度高、响应迅速；相比之下UWP应用笨重、Electron更糟。有用户对Windows XP时代在线文件关联服务的实际效用感到好奇——是否真的有用，或如同后来Windows搜索那样只是引出充满垃圾”什么扩展名是XXX”网站的Bing搜索。有评论戏称微软多年来加入这些”在线查找”选项却从未真正找到过任何有用内容，似乎只是用来嘲弄用户。最后微软终于推出了CLI版本的文件关联管理工具，对于脚本化设置新系统正合适。

15. 用 Python 写一个 Lisp 解释器（Norvig 经典教程）

该页面是 Peter Norvig 撰写的经典教程，目标是用 Python 3 实现 Scheme 方言的解释器（命名为 Lispy，源文件 lis.py），同时阐述编程语言解释器的通用实现方法。作者引用 Alan Kay 的说法，将 Lisp 解释器称为”软件领域的麦克斯韦方程组”，并借 Steve Yegge 的话强调”不理解编译器就不理解计算机”。

教程对比了 Scheme 与 Java 的语法差异：Java 有大量关键字、中缀运算符、多种括号、运算符优先级等，而 Scheme 只需 5 个关键字和 8 种语法形式。Scheme 程序完全由表达式构成，没有语句/表达式之分；数字和符号是原子表达式，其余都是列表表达式，由首元素决定其语义（特殊形式或函数调用）。

文章采用渐进式教学，先构建简化的”Lispy Calculator”，仅支持变量引用、常量字面量、条件 if、定义 define 和过程调用五种形式，能完成计算器级别的运算加上条件判断和变量定义。随后再扩展到接近完整的 Scheme。解释器分为两部分：parse 负责将字符序列解析为抽象语法树（在 Lispy 中即嵌套的 Python 列表），eval 则根据语义规则执行计算。文中给出示例：程序 “(begin (define r 10) (* pi (* r r)))” 经 parse 后变为嵌套列表结构，再交由 eval 求值。

HN 讨论中，多位评论者将该教程与《Crafting Interpreters》并列推荐为入门首选资源，并提及 Norvig 的进阶版 lispy2。有评论者分享了类似的微型实现项目 Ribbit，可在 8KB（JavaScript）或 6.5KB（x86）规模内支持完整 R4RS REPL 含尾调用。有人指出语言学也用类似 Lisp 的括号或方括号标注句子结构，树和括号结构同构。还有人反向提供了用 Common Lisp 实现的 Python 解释器项目。多位评论者表示实现 Lisp 或 Forth 是极有启发性的练习，能让人重新理解括号的意义。也有评论者悲观地指出，未来这类教学资源会被 AI 大量复制利用。

16. Go 中过度的 nil 指针检查反而是代码异味

作者讨论 Go 代码中日益常见的 nil 指针检查，指出虽然在合适位置进行 nil 检查能预防 panic，但在错误位置进行检查往往说明代码已经无法清晰追踪指针的来源和生命周期，这在生成代码（包括 AI 生成）中尤为常见。

文章以 RateLimiter 持有 Redis 客户端为例：在 Allow 方法中检查 r.redis 是否为 nil 看似安全，实则掩盖了真正的问题——为什么 RateLimiter 会用 nil 依赖来构造。错误发生在构造时，此时检查并不能处理错误，反而把”操作失败构造”当作可接受状态。在构造函数中检查 nil 并返回 error 虽有改进，但仍允许了无效状态进入系统；正确做法是在初始化点（如 NewRedisClient 调用失败时）就立即处理错误，避免 nil 传递。若系统需要容忍依赖暂时不可用，应将该状态显式建模，用外层类型封装重试和降级逻辑，对外暴露始终安全调用的方法。这类似数据库的 NOT NULL 约束：一次性建立保证，使后续代码无需重复检查。

作者批评”静默失败比 panic 更安全”的直觉，指出显式错误是”响亮、即时、可归因”的，而吞掉错误则是”静默、延迟、模糊”的，会拉大原因与症状的距离，并迫使团队投入精力构建监控基础设施去重建本应保留的信号。文章还区分了外层（请求入口处）与内层（深层调用栈）的检查策略：请求作用域数据应在传输边界处校验，而非在深层方法中重复检查。

HN 讨论意见分歧明显。一派支持局部推理和防御式编程，尤其在 LLM 时代不愿依赖对全部调用路径的把握；另一派强调契约式编程，认为参数检查只应在公共边界进行。多位评论者指出 Go 真正的问题是类型系统缺少非空指针表达能力，Rust 的 &T 与 Option<&T> 区分被认为是已解决的方案。有评论者建议团队约定不使用指针、所有结构体按值传递，且永远不要对接口做 nil 检查（因接口可能对 nil 值有效）。也有评论者引入简单的 Optional 泛型类型解决问题。还有人将其类比 Java 中受检异常 vs 非受检异常的历史辩论，认为这本质上是契约编程与防御编程的老话题。

17. Lodash 作者讲述开源维护者的倦怠真实经历

OpenJS 基金会发布了与 Lodash 创建者 John-David Dalton 的对话。Lodash 是 JavaScript 生态中使用最广的工具库之一，每日 npm 下载量超过 1 亿次。该项目最初由 Dalton 个人维护，他从 2012 年开始项目，凭借 npm 普及和框架兴起迅速成为基础设施。

文章关注的不是常规的”工单太多、请求太多”式倦怠，而是更复杂的个人层面经历。Dalton 多年来以每日少量工作的节奏稳定维护项目，但母亲去世后优先级发生重大变化，项目从日常节奏中脱离。2019 年又经历了和平离婚，即便是积极的人生转变也需要时间重建稳定。这期间他从大部分开源工作中退出。Dalton 也提到许多维护者熟悉的隐忧——担心停止贡献就会失去相关性，但他发现已建立的社区关系和信任依然存在。

Dalton 估计重返开源花了大约五年时间，经历多次失败开始才感到可持续。恢复更多关乎平衡而非产出：心理治疗、运动、健康边界以及编程之外的爱好都起到作用，其中一个有意改变是不再把编码作为业余爱好。他得出的结论是长期可持续性比持续产出更重要。

在 OpenJS 生态支持下，Lodash 进入新阶段：引入技术指导委员会和专门的安全分流小组，恢复持续集成，部署现代安全工具，将责任从单一个人转向社区共享。

HN 评论指出开源的独特困境——业余项目可能演变为关键基础设施，“就像你喜欢钩针编织，结果你停下来全城人就没衣服穿”。多位评论者建议维护者应该坚持”我的软件我的愿景”原则，敢于关闭不符合愿景的请求、降低工作量、按自己节奏修复问题。有人推广 Supported Source 等许可方案，主张商业公司持续索要功能却不付费时，开源就成了被剥削的源头。也有人感慨在大多数开源项目之外，纯粹的开源模式可能不再可持续，并以 Rust GUI 框架普遍依赖单人维护的 winit crate 为例。还有人回忆 Lodash 早期 Dalton 在与 underscore.js 分叉竞争时态度颇为尖锐，感叹生活让人变化。

18. 为个人网站添加 JSON-LD 结构化数据的实用指南

作者 Ethan Hawksley 介绍了如何为个人网站添加 JSON-LD（JSON Linked Data）结构化数据。JSON-LD 能帮助网络爬虫理解站点的语义结构，获得更丰富的链接预览，甚至可能提升搜索排名。作者花了约 100 小时构建自己的站点，在每个页面添加了 JSON-LD。

技术上，JSON-LD 以 <script type="application/ld+json"> 标签嵌入 HTML head 部分，浏览器不会执行该脚本但爬虫会解析。文档以 @context 声明遵循的 schema（通常是 schema.org），用 @graph 组织节点图。每个节点包含 @type（类型，如 WebSite、SoftwareApplication）、@id（唯一标识符，建议用 URL 加哈希形式）和描述属性。爬虫可跨页面合并同 ID 节点的属性，但单页爬虫（如 LLM）不会合并，因此跨页复用需平衡。

文章详细介绍几种关键节点类型：WebSite 描述站点元数据帮助爬虫展示，根页面应完整，其他页面可用简化版；WebPage 描述当前页面本身，与 BlogPosting 等内容类型有区别，包含 isPartOf 关联到 WebSite 和 breadcrumb 面包屑导航；Person 节点描述作者身份，Google 将其作为内容质量指标，LLM 爬虫也越来越多地用它决定引用对象，每个页面都应包含。Person 节点字段可包括 jobTitle、knowsAbout、nationality、affiliation、alumniOf、sameAs（链接到 GitHub、LinkedIn、维基百科等）等丰富属性。

HN 讨论中，最热门的质疑指出这种优化是”在打上一场战争”——Google 现在更多直接生成 LLM 总结展示在原站链接之上，伴随错误，且会降权原始内容。有评论者推荐结合 Google 官方文档使用，承认 JSON-LD 信息只对小部分站点有用（如 Rotten Tomatoes 的影评评分），但其优势是简单且确实被搜索引擎使用。也有评论者质疑这些属性是否真的提升搜索可见度，还是只让搜索引擎留住更多用户不离开搜索结果页。一个明显的痛点是 HTML 已有语义化标签，却还要在 script 标签中用 JSON 重新表达一遍同样的语义信息——虽然 RDFa 正是为复用 HTML 中已有的值而设计，但常见解析器仍要求重复表达。多位评论者怀念语义网最初的承诺，认为本可形成强大的链接数据生态，而非如今平台锁定的局面。

19. AI 时代可销售软件的最小可行单位

作者刚离开 Stainless 全职做副业项目 River（Go 与 Postgres 的任务队列），有人质疑在 LLM 时代做软件生意是否疯狂——任何产品都可能被 LLM 内部构建包替代。作者以分析回应该疑问。

文章开篇以 LinkedIn 上某用户的逸事切入：该用户用 Claude 让团队构建内部任务追踪器，替代月费 400 美元的 Atlassian Jira。但 LLM 让构建变便宜不等于免费：好的 LLM 系统仍需反复反馈迭代，需要人工监督，维护也是持续成本。作者用粗略计算反驳：年薪 20 万美元的工程师每小时成本约 96 美元，要抵消 Jira 的月费 400 美元，每月只能花最多 4 小时在自建系统上——这显然不现实。即便宽松假设每月只需 2 小时维护，初始 2 周构建后仍需 37 个月才能回本。

但对高价 SaaS 情况不同。Salesforce 满载约 500 美元/座位/月，若需 50 座位则月费 2.5 万美元，足以支持 1.5 名工程师全职构建替代品。作者据此提出”可行性区间”概念：在某个区间内的软件既有足够新颖性使 LLM 重建非平凡，定价又不至于高到强烈推动重建。区间内存在”可销售软件的最小可行单位”——低于此则重建成本与购买相当。

作者认为 River 处于该区间内：开源版本提供大多数任务相关功能，Pro 版本保留高级功能（工作流、顺序任务、并发限制任务）和按发票计费能力供收费。

HN 讨论丰富。多位评论者认同构建成本远未归零，自己开了多个副业项目都因后期维护精力超出收益而停滞。有评论者补充”构建 vs 购买”的二元框架忽略第三方竞争者：若内部构建变易，新进入者也容易压低价格。还有人指出开源软件的社区效应——许多功能由少数关键用户请求最终惠及长尾用户，孤立自建无法产生此外部性。一位评论者讲述让 Claude 复制 Google Docs 的尝试，模型”实际上吐了”，反复抵制并解释为何这是糟糕主意；其分析认为 Jira、Salesforce 等有数十个页面，每次只看一个，所以”复制 Jira”的庞大性不显眼，而 Google Docs 几乎一屏就是全部，抗拒分解。也有评论者指出企业软件大量价值在 SSO、多租户、审计日志、合规设计等”企业层”包装，而非核心功能本身。

20. PID 控制器：经典反馈控制机制的原理与实践

维基百科条目介绍了 PID（比例-积分-微分）控制器，这是一种基于反馈的控制回路机制，广泛用于需要持续控制和自动调节的工业控制系统及其他应用。PID 控制器自动比较期望目标值（设定值 SP）与系统实际值（过程变量 PV），用三种方法将 PV 调整到 SP：比例项（P）对当前误差直接成比例响应提供即时校正；积分项（I）累加历史误差以消除残留稳态误差；微分项（D）通过误差变化率预测未来趋势，缓解超调并增强稳定性，尤其在系统快速变化时。

最常见例子是汽车定速巡航：上坡时若发动机功率保持不变车速会下降，PID 控制器调整功率输出以恢复期望速度，做到延迟和超调都很小。PID 理论基础可追溯到 1920 年代初的船舶自动转向系统，后用于制造业过程控制，从气动执行器演进到电子控制器。

数学上 PID 输出是三项的加权和，控制器持续计算 e(t)=r(t)−y(t) 并通过调整控制变量（如控制阀开度）来最小化误差。单用 P 项会留下稳态偏差；I 项累加历史误差消除残差，误差消除后停止增长；D 项作为”预判控制”对变化率进行响应。

HN 讨论涉及多种工程实践。有评论者在 BLDC 电机速度控制中转向使用线性 ADRC（主动扰动抑制控制），因其能应对 PID 难以调好的真实环境变化，但电流控制仍用 PID。有人观察到程序员对经典控制论的兴趣，提到 JEPA 在某种字面意义上就是模型预测控制算法。多位评论者分享亲身使用经历：金属探测器中应用 PID 效果良好；用 PID 控制 GPU 风扇温度，把”风扇曲线”换成”维持理想温度”的思路。一个生动的实验描述：用 PID 控制小型电机带飞轮，手动调参后用手触碰飞轮转速几乎不变，感觉像有巨大电机驱动。也有评论者指出 PID 的实际困境——调参困难，需要深入物理理解，对变化环境（如夏冬温湿度差异）适应性差，因此现代多用粒子群等优化技术自动调参；并预测未来许多工业 PID 将被小型神经网络（少数节点即可）替代。文中也推荐了 PID Without a PhD 这一经典入门资源。