HN 每日深度阅读 · 2026-05-18
当工程师们重新审视手中的工具，浪漫滤镜正在褪去：从告别 Tailwind 回到原生 CSS，到资深 iOS 老兵被迫向 WebKit 与 Electron 低头，再到对 AI 加速开发的祛魅，本期几篇文章共同指向一个判断。
共 20 篇 · 约 13,626 字 · 约 34 分钟读完
1. 从 Tailwind 回归原生 CSS：一次重新学习样式组织的过程
Julia Evans 在八年前曾撰文盛赞 Tailwind，称其帮助她在不懂如何组织 CSS 的情况下快速搭建小型站点。如今她花了一周时间将几个站点从 Tailwind 迁移回语义化 HTML + 原生 CSS，并分享了过程中的体会。
她首先承认 Tailwind 确实教会了她很多东西：每个 CSS 代码库都包含布局、字体、颜色、通用组件等不同维度，需要系统化的规则来管理，否则就会陷入混乱。Tailwind 自带的 reset、调色板、字体尺度等系统，她现在依然认可并选择模仿。
文章按九个方面介绍了她的新组织方式：第一，reset 直接复制 Tailwind 的 preflight 前 200 行，因为她已经习惯了诸如全局 box-sizing: border-box、html 行高 1.5 之类的默认行为。第二，组件化是 CSS 的主体，每个组件拥有唯一 class、独立 CSS 文件，组件之间不互相覆盖，借助原生嵌套选择器书写，逻辑上类似 Vue/React 组件，但并未使用 @scope 或 Web Components 做强制隔离，仅靠约定。第三，颜色统一收敛到 colours.css 的 CSS 变量。第四，字号沿用 Tailwind 风格的 —size-xs 到 —size-2xl 变量，避免在 em/px/rem 之间纠结。第五，把按钮、sr-only 等跨组件复用的样式归为 utilities。第六，base 样式刻意保持精简，采用自底向上的方式逐步沉淀。第七，spacing 的处理她坦言还没想清楚，承认过去在 Tailwind 里也只是随意堆 padding/margin 直到看起来顺眼为止。
HN 讨论相当热烈。高赞观点认为 Tailwind 颠倒了 HTML 与 CSS 的思考顺序：本应先用语义化标记表达文档含义，再用 CSS 装饰，而 Tailwind 让开发者先想样式 class，再为挂载 class 而额外增加 div，长此以往削弱了 Web 开发的基础功力。也有评论尖锐指出，Tailwind 拥护者常用的论据本质上反映的是「没有把 CSS 学到初级以上」，而组织 CSS 本身就是一项独立技能。另一派则为 Tailwind 辩护：在 AI 代理或多人协作场景下，内联式 utility class 避免了 card-header-inner、sidebar-item-wrapper 这类无人维护的命名膨胀，并将样式与 JSX 放在一起降低上下文切换；此外 Tailwind 的生产构建能裁剪未使用样式，是自写方案不易复现的优势。还有人推荐 CSS Modules 作为更轻量的命名隔离方案，或在 Svelte/Vue 的 scoped style 中通过 @apply 混合使用两者。许多读者也借机表达了对 Julia Evans 一贯真诚、谦逊写作风格的喜爱。
2. Mozilla 致信英国监管机构：VPN 是必要的隐私与安全工具
英国科学、创新与技术部正就「在网络世界中成长」议题展开公众咨询，其中一项提议是在《在线安全法》强制年龄核验制度被用户绕过的背景下，考虑对 VPN 等工具实施年龄限制。Mozilla 向监管机构提交了正式意见，明确反对这一方向。
Mozilla 的核心论点是：VPN 是面向全年龄段用户的关键隐私与安全工具。它通过隐藏 IP 地址，帮助用户保护位置、降低追踪、避免基于 IP 的画像。用户使用 VPN 的场景多种多样——远程接入学校或公司网络、规避审查、保障日常上网隐私等。对活动人士、异见者和记者等弱势群体而言尤为关键，但 VPN 也提升了所有人的基线安全水平。
Mozilla 特别指出，未成年人更容易受到网络追踪、定向广告以及未经充分同意的数据收集所带来的伤害。在年轻人从小就深度接触数字技术的现实下，限制他们使用隐私保护工具，与培养其安全、自主使用互联网能力的目标相互矛盾。Mozilla 认为，监管者应从根源入手——追究平台责任、推动合理使用家长控制工具、投资数字素养教育，而非通过粗放的年龄门槛来「一刀切」。这与 Mozilla 此前反对强制年龄核验（包括澳大利亚社交媒体禁令）的立场一脉相承。
HN 讨论呈现几条主线。一是程序性提示：该议题尚处咨询阶段而非既定政策，提交意见无需英国国籍，有评论者鼓励相关人士参与反馈。二是政策对比，有评论提到澳大利亚政府反而公开建议使用 VPN 并提供指南；也有人指出欧盟同样在讨论类似限制。三是利益披露质疑：Mozilla 自身也运营 VPN 转售业务，有人认为应当声明。四是逻辑层面的争论：有评论者反问，如果要求成人内容平台承担责任，平台几乎必然会引入某种年龄核验机制，所谓「从根源治理」如何落地？另一种观点则认为，目前的年龄核验思路是借鉴烟酒监管，但与烟酒不同，网络伤害本可以通过约束平台行为本身（如数据收集、推荐机制）来从源头解决，而非仅靠限制访问。此外不乏对英国立法走向的批评性比喻，认为限制 VPN 的真实动机在于削弱用户绕过监管的能力。
3. Zerostack：用纯 Rust 写的极简 Unix 风格编码 Agent
- 原文: https://crates.io/crates/zerostack/1.0.0
- HN: https://news.ycombinator.com/item?id=48164287
- 得分: 536
- 评论: 295
Zerostack 是一个用纯 Rust 编写的命令行编码 Agent，受 pi 和 opencode 启发，强调极小体积与低资源占用。项目体量约 7k 行代码，二进制 8.9MB，空会话内存约 8MB、工作时约 12MB，作者将其与基于 JavaScript 的 opencode（约 300MB 内存占用）进行对比，突出在低端笔记本上的可用性。
功能层面覆盖了当下主流编码 Agent 的标配：支持 OpenRouter、OpenAI、Anthropic、Gemini、Ollama 及自定义 Provider；提供 read/write/edit/grep/find_files 等文件工具；带权限门控的 bash 执行，可选通过 bubblewrap 沙箱隔离；具备”doom-loop 检测”，当同一工具调用重复 3 次以上会触发警告，防止 Agent 失控地执行破坏性操作。权限系统分为 restrictive、standard、accept-all、yolo 四档，可按工具配置 glob 模式，并支持会话级 allowlist。
Prompts 系统内置 code、plan、review、debug、ask、brainstorm、frontend-design、review-security、simplify、write-prompt 等模式，运行时通过 /prompt 切换，意图替代 Claude Skills 一类机制；同时会自动加载项目中的 AGENTS.md 或 CLAUDE.md 注入到系统提示。其他特性包括 MCP 支持、Exa 集成的 WebSearch/WebFetch、Git Worktree 切换，以及面向长任务的实验性 Loop 系统，可在 headless 模式下循环迭代执行计划并运行测试。
HN 讨论较为热烈。大量评论者表示自己也在写类似的小型 harness，认为随着模型能力提升，harness 的复杂度反而应当下降，关键在于贴合个人工作流。多名用户对低内存印象深刻，吐槽 Claude Code、opencode 在大型项目上会膨胀到数 GB 并变慢。沙箱话题被反复提及：有评论指出模型会通过宿主网络接口”越狱”出 bubblewrap，因此考虑叠加 slirp4netns；也有人提出 Agent 递归调用时需要可在任意深度撤回的审批协议，类似 QubesOS 的跨 VM 剪贴板机制。
批评意见主要集中在可扩展性上：有评论认为 Zerostack 虽自称受 pi 启发，但缺少 pi 最核心的插件/Hook 系统，无法让多个扩展叠加在同一 Hook 上自定义行为，而这种类 WordPress 的扩展机制才是企业定制 Agent 的关键。另有用户反馈与 Azure 上 gpt-5.5 不兼容（max_tokens 字段变更），也无法传递自定义 Header 来指定 DeepSeek 的 reasoning_effort。还有人提到与自己 MIT 许可的同类项目 maki 高度相似，而 Zerostack 选择了 GPL 许可。
4. AI 难以真正加速流程：瓶颈往往不在开发本身
作者重读《丰田之道》与《目标》后撰文指出，当前企业在市场下行期普遍热衷流程优化，并把 AI 当作万能加速器，但这种思路过于简化。文章以甘特图为例：软件开发环节在图上耗时最长，最容易被识别为瓶颈，但管理者常见反应——增派人手或寄望 AI 自动生成代码——都忽略了一个关键问题：长耗时不等于问题根源就在该环节。
作者强调，软件开发的本质是把模糊问题翻译成计算机可执行的精确方案，真正拖慢进度的往往是上游的需求不清。一个”销售完成后给用户发邮件”的需求背后，潜藏着无数未定义的细节：邮件内容、异常情况处理、“销售完成”的定义等等。开发者历来恳求的，正是详尽的需求与范围说明。
针对”AI 让开发者变成项目经理”的流行说法，作者认为这种对比并不公平：AI 确实能快速产出代码，但不保证正确，要让 AI 产出可用结果，同样需要领域和产品专家投入大量精力把每个特性和缺陷描述到极细颗粒度。如果把同等详尽的文档交给人类开发者，生产力同样会飙升。引用《目标》的核心结论：“瓶颈应当获得可预测的、高质量的输入”，这才是流程优化应当优先关注的地方。
HN 讨论分歧明显。一派认同作者：早期人们以为对 LLM 说”做一个 Facebook 克隆”就够了，现在意识到模糊需求只能换来模糊结果，软件工程的核心难题从未改变。另一派则认为文章把 AI 的影响局限在开发阶段过于狭隘，AI 在构思、文档、法务、部署等环节都能带来提速，许多”杂活”性质的工作（按钮的状态设计、后端对接等）确实能被压缩。
还有评论指出文中甘特图代表的是瀑布式开发，而现实中 99% 的软件没有终点，业务每两周就改一次需求，软件像被饲养的动物般持续演化、积累熵增，AI 至多让这个过程稍快一点。另有观点提出有趣的二分：对自己已经擅长的领域 LLM 帮助有限，但对不擅长的领域则是巨大变革——这意味着大公司收益有限，反而是小团队和独立开发者获益最大。也有人略显疲惫地表示，类似观点已在 HN 反复出现，但在 AI 提速叙事被资本与管理层强力背书的当下，再多博客也难以改变决策者的预期，只能等待项目失败后市场自行修正。
5. 原生开发到极致，直到遇上文本
作者 Artem Loenko 拥有近二十年 macOS/iOS 原生开发经验，他撰文反思了自己在尝试用纯 Swift/SwiftUI 实现一个支持 Markdown 的简单聊天界面时所遭遇的挫败。他描述了一条不断”降级”的技术路径：从 SwiftUI 出发，发现无法跨多个 SwiftUI 原语进行整段文本选择（设计限制）；转向 NSTextView 与 TextKit 2，丢失了围绕 SwiftUI 建立的测试与性能基础，并在流式渲染时遇到 CPU 飙升；再退回 AppKit 与 NSCollectionView，又遇到单元格闪烁问题；甚至下沉到纯 TextKit 2 自行处理扩展文本块，结果发现仅仅追平 macOS 原生文本基础行为（上下文菜单、词典查询、选择、辅助功能等）就要耗费数月。
最终他改用 WebKit 渲染 Markdown，效果出乎意料地好；进一步尝试生成一个 Electron 项目后更感震惊：文本操作、Markdown 渲染、排版、macOS 集成、Git diff 渲染都几乎开箱即用，性能甚至优于其 TextKit 2 实现。他由此得出结论：当下大量以聊天和长文本富文本为核心的新应用之所以基于 Web 技术，并非偷懒，而是缺乏真正可行的原生替代方案。SwiftUI 适合简单界面，Swift 仍适合性能关键部分，但在富文本聊天场景下，Apple 原生 SDK 已从优势变成约束。
HN 讨论分歧明显。一派支持作者观点：有评论指出浏览器引擎经过十余年大规模 Web 应用打磨，GPU 加速成熟，而 SwiftUI 并不快，连 Apple 自己重写的系统设置面板切换都会卡顿；多位开发者分享了类似经历，包括做 AI 聊天应用时尝试多个 GitHub 上流行的文本组件均存在 bug 与卡顿。也有人指出 WebKit 本就是 macOS 原生框架，用它渲染 Markdown 完全合理，Apple 自身历史上也曾在 NSTextField、iMessage 中用 WebView 渲染富文本，Adium 同样如此，HTML 本来就是富文本渲染的合适工具。
另一派则质疑作者的结论过于绝对，有人贴出 swift-markdown-ui、textual 等成熟库，称自己并不擅长 SwiftUI 也能顺利实现；有评论直言”要么贴代码，要么免谈”，认为市面上大量原生 Mac/iOS 应用都能流畅渲染 Markdown 与流式文本。还有一类观点跳出技术争论，指出这是一种自我强化的循环：开发者觉得原生不够成熟便转向 Web，结果原生生态更少投入，越发停滞。也有开发者展示了自己用 TextKit 2 做出的高性能 iOS 文本编辑器，以及用 Qt/QML 自建块编辑器解决类似问题的案例，说明这条路并非走不通，只是成本极高。
6. 本地推理算账：M5 MacBook 的 token 成本反而高于 OpenRouter
作者在博客中对在 M5 Max MacBook Pro（64GB 内存，售价约 4299 美元）上本地跑 Gemma 4 31b 做了一次成本核算，结论是：折算到每百万 token，本地推理的成本约为 0.40–4.79 美元，而 OpenRouter 上同款模型只要 38–50 美分，且速度通常是本地的 2 倍以上（云端部分提供商可达 60–70 tokens/s，本地仅 10–40 tokens/s）。
成本拆解方面，电力部分占比很小：按弗吉尼亚北部约 0.18 美元/kWh、满载 50–100W 计算，每小时电费仅 1–2 美分，即便 24 小时满负荷推理也不到 0.5 美元/天。真正的大头是硬件折旧——按 3、5、10 年寿命摊销，每年成本分别为 1433、860、430 美元，折合每小时 0.05–0.16 美元。在乐观假设（50W、40 tokens/s、10 年寿命）下，Mac 与 OpenRouter 价格相当；悲观假设（100W、10 tokens/s、3 年）下要贵约 10 倍。作者倾向认为约 3 倍是合理估计，并指出对于有薪水的员工，token 成本相比工资微不足道，因此付费给 Anthropic 更划算；但能在消费设备上跑接近 Sonnet 水平的模型仍令人惊叹。
HN 评论区对这一分析的方法论提出了大量质疑。最高赞观点指出：核算把整台笔记本的成本全部摊到 token 生成上并不合理，购买这台机器同时还获得了一台可日常使用的笔记本，并且本地推理还附带隐私、抗审查、模型不会被供应商悄悄更换等价值；若真要 24/7 跑推理，笔记本本就不是合适的硬件。另一类批评指出，前沿 AI 公司正以巨亏价格倾销 token，用云端价格作为基准本身就有失公平，价格未来很可能上涨。
还有评论认为作者忽略了输入 token 的成本——在 agentic 工作流中输入 token 通常占大头，本地推理近似免费，这会显著改变对比结果。另有读者指出文章在用 Gemma 比价后却建议「付钱给 Anthropic」，但 Anthropic 输出 token 价格是 Gemma 的 30 倍以上，是不恰当的类比。模型选择方面，多位评论者推荐 qwen3 系列 27B/32B，认为其在速度、显存占用和能力上比 Gemma 4 31b 更具性价比。总体共识是：单纯从成本/性能角度，多数开发者更适合订阅云服务，本地模型更像是隐私控制、学习实验或爱好者的选择。
7. WHO 宣布刚果与乌干达埃博拉疫情为国际关注的突发公共卫生事件
世界卫生组织于 2026 年 5 月 17 日宣布，刚果民主共和国与乌干达境内的埃博拉病毒传播构成”国际关注的突发公共卫生事件”(PHEIC)。疫情最早在刚果东北部伊图里省被发现，随后在刚果首都金沙萨和乌干达首都坎帕拉均出现确诊病例。截至宣布当日，伊图里省已报告 246 例疑似病例、80 例死亡，但仅 8 例经实验室确认。
此次疫情由 Bundibugyo 型埃博拉病毒引发，目前尚无获批的疫苗或治疗药物（已有疫苗针对的是 Zaire 型）。WHO 表示，实际感染规模和地理范围可能远大于已检测到的数字，存在”重大不确定性”。该事件被定为 PHEIC，但未达到最高级别的”大流行紧急事件”，WHO 也建议各国不要关闭边境。
疫情应对面临多重困难：伊图里省自 2021 年起处于”戒严状态”，受 ADF 等武装组织袭击影响，民众对当局信任度低；该地区人口流动性大、非正式医疗机构众多，与乌干达和南苏丹接壤的跨境流动加剧了扩散风险。乌干达原定 6 月 3 日举行的大型天主教节庆已被总统穆塞韦尼宣布推迟。乌干达卫生部长表示该国已建立从基层社区卫生工作者到区域应急中心的电子上报体系。
报道还指出，美国此前在控制埃博拉疫情中发挥重要作用的 USAID 已被特朗普政府关闭，CDC 资金被削减，美国还于 1 月退出 WHO，这些变化可能影响本轮响应。专家 Jennifer Nuzzo 也指出，本次疫情被首次发现的时间相对偏晚，监测系统反应滞后。
HN 评论中，有用户整理了历史上被列为 PHEIC 的疾病清单（甲流、脊灰、两次埃博拉、寨卡、新冠、猴痘），强调此次宣布的分量。多位评论者讨论该毒株致死率较低反而可能更易扩散，并猜测美国从国际公共卫生体系撤出是否削弱了早期预警。也有评论提醒不应简单将其与新冠类比：新冠之所以演变为大流行，关键在于空气传播、无症状传播以及缺乏自然免疫，而埃博拉主要通过体液直接接触传播，传播模式截然不同。还有讨论涉及现有 Zaire 型疫苗能否对 Bundibugyo 型提供交叉保护的技术问题。
8. AI 是技术而非产品：对苹果”AI 杀手级产品”论的反驳
Daring Fireball 的 John Gruber 撰文反驳 Wired 资深记者 Steven Levy 的观点。Levy 在苹果 CEO 交接公布后撰文称，苹果下一任 CEO 必须推出”杀手级 AI 产品”，否则到本十年末，人们将不再用手机点 Uber，而是由”始终在线的 AI 代理”自动安排出行，“There’s an app for that”会被”Let the agent do that”取代。
Gruber 引用苹果硬件负责人 Ternus 的话称：苹果从不”出货一项技术”，而是出货产品、功能和体验，用户不需要知道底层技术是什么。这正是苹果对待 AI 的方式。Gruber 认为 iPod 不是关于 MP3 文件，iPhone 也不是关于移动技术本身，而是关于音乐、关于体验。苹果并未涉足社交网络业务也活得很好——因为社交媒体的消费载体仍是手机。
Gruber 将 Levy 描绘的”无需呼叫、车自动等候”场景斥为高度炒作下的幻想：这种体验需要麦克风、扬声器、屏幕等真实硬件支撑，而最可能承载这些的设备仍然是手机。即便出现更小的可穿戴设备（手表、耳机、眼镜），它们也更可能与手机配对而非独立工作。
文章的核心类比是：AI 之于今天，就像无线网络之于过去。苹果没有”杀手级无线产品”，但 Wi-Fi、蓝牙、蜂窝渗透在每一款苹果设备中。AI 也会以同样方式无处不在，而不会催生单一的”AI 设备”。
HN 评论广泛认同此观点。多位评论者指出，对苹果来说，AI 最理想的落地就是让 Siri 真正可用——例如用自然语言设置日历、播放播客，而用户根本不会意识到背后是 AI。也有人引用乔布斯”从用户体验倒推技术”的名言，认为苹果 DNA 决定了它不会把 AI 当独立产品卖。另有评论将此与”Dropbox 是功能而非产品”的经典论断对比，认为一旦硬件普及，AI 推理也会变得像同步一样平凡。也有少数声音认为，谷歌在”AI 作为功能”方面（通话等待、Magic Cue、垃圾识别等）做得反而比苹果更出色。
9. C++26 的 std::simd：一个姗姗来迟却已落伍的库
文章批评 C++26 标准纳入的 std::simd（P1928）库。其卖点是”一次编写、跨 AVX2/AVX-512/NEON/SVE 编译”的可移植 SIMD 抽象。但作者通过复现 NoNaeAbC 一份讽刺仓库的基准测试发现：std::simd 编译速度慢 10 倍，运行时慢于标量循环，默认向量宽度选错，且无法表达真实 SIMD 代码中关键的操作——编译器的自动向量化器（即 std::simd 本应取代的对象）在每一项指标上都胜出。
文章追溯历史：std::simd 源于 GSI 研究员 Matthias Kretz 在 2009-2010 年为高能物理仿真开发的 Vc 库。提案 P0214 从 2016 年起经历九次修订，进入 Parallelism TS 2，GCC 11 于 2021 年提供实验实现，最终通过 P1928 纳入 C++26。但十年间，竞争格局已天翻地覆：GCC/Clang/MSVC 自动向量化大幅提升；ISPC 证明语言级 SIMD 优于库级抽象；ARM 推出可变宽度 SVE，从根本上挑战固定宽度抽象。
作者比较了几个开源替代品。Google Highway 支持运行时分发与 length-agnostic 设计，被 Chromium、Firefox、JPEG XL、libaom 等采用——谷歌做编解码生产代码时选择自建 Highway 而非用 std::simd。SIMDe 提供可移植的 Intel intrinsics 实现，但锁定 Intel 心智模型。xsimd 覆盖广泛但文档稀薄。EVE 由 C++ 委员会参与者 Joel Falcou 主导。
HN 评论激烈讨论。一位资深 SIMD 开发者指出，任何抽象（包括自动向量化）都无法捕捉 intrinsics 在不同微架构下的极端差异，认真做 SIMD 仍需写 intrinsics；不清楚 std::simd 究竟服务于谁。有评论质疑文章关于”优化器只看到不透明模板”的论述——模板会被单态化、可被内联，问题不在此。一位早期提案者透露，他 2011 年就提交过基于 EVE 思路的 SIMD 提案，当年被否决的理由（不适配 SVE、控制流表达等）与今天一致；当时本可整合 ISPC 风格的语言级方案。还有人指出 GCC 早已有 vector extensions、Go 1.26 即将引入 SIMD 支持，值得对比。也有人批评文章关于”默认宽度问题”的章节有 LLM 痕迹——-march=native 同样会锁死宽度，真正的解法是运行时分发。
10. 把 80 美元的安卓平板改造成 Debian Linux 工作站
- 原文: https://github.com/tech4bot/rk3562deb
- HN: https://news.ycombinator.com/item?id=48168668
- 得分: 217
- 评论: 114
开发者 tech4bot 发布了 rkdebian 项目，将 80 美元的 Doogee U10 安卓平板（搭载 Rockchip RK3562 SoC，4×Cortex-A53@2GHz，4GB LPDDR4，128GB eMMC，10.1 寸 1280×800 屏）改造成可启动完整 Debian 12 Bookworm 的 Linux 设备。
方案优雅之处在于：镜像写入 SD 卡，插卡启动即进 Debian，拔卡则恢复 eMMC 上的原版安卓，无需解锁 bootloader，不修改内部存储。项目完全从零逆向工程，没有 BSP、没有厂商文档、没有官方支持，作者借助 Claude、Codex 和 Google Gemini（Antigravity）三款 AI 工具，以 Firefly RK3562 开源仓库为起点构建。
硬件支持完成度相当高：显示、10 点触控、Wi-Fi、蓝牙、扬声器、麦克风、加速度计、闪光灯、电源键、SD 启动、USB OTG 均完全工作；Panfrost 提供部分 3D 加速；前后摄像头管线已通但色彩调校未完成；NPU 通过 Rockchip RKLLM 栈支持本地 LLM 推理。在 NPU 上跑 Qwen3-0.6B（W8A8 量化）可达 prefill 57.6 tok/s、生成 4.92 tok/s；Qwen2.5-1.5B 则为 42.8 / 2.18 tok/s。预装应用包括 Firefox ESR、Chromium、FreeTube、Dolphin、Plasma Discover、Okular 等，使用 Phosh 桌面。
HN 讨论焦点多在 AI 辅助逆向工程的可能性。多人感慨”AI 让以前不值得花时间去 hack 的设备变得容易”，并询问是否有相关教程，认为这将极大帮助 postmarketOS 等项目移植到新设备。有人讨论 4GB 内存下可运行什么——浏览、轻量桌面、WezTerm+tmux+开发工具应可胜任，类似配置已能流畅模拟 VAX 系统。也有人担心消息传开后，原本平价的 Doogee U10 会出现购买热潮和涨价。还有人指出此方案并非 mainline Linux 内核，以及好奇为什么选择这款特定平板作为切入点。
11. 更精致的电压表时钟 v2
安全研究员 lcamtuf 发布了其 2019 年电压表时钟的改版作品。这类时钟用三个模拟电压表替代传统时钟表盘来显示小时、分钟、秒。作者表示，网上多数同类设计”不必要地复杂、也不够美观”，因此重新设计并完整记录了制作过程。
设计要点：使用三块约 9 美元的 90° 通用面板电压表（Baomain 65C5），拆解后测量并打印自制贴纸表盘。为实现指针连续平滑运动（如 11:30 时小时指针应在向 12 移动而非卡在 11），小时表盘有 13 个刻度（0-12），分秒表盘则有 61 个刻度（00-60）。
外壳工艺颇为讲究：用 CNC 铣床加工枫木前后面板并设计凹陷装饰图案以遮蔽电压表丑陋的塑料法兰；侧壁需要弯曲成型，作者未用蒸汽弯曲台，而是在木材内侧切凿一系列槽口让其更易弯折，加湿、夹紧、干燥数日后再用模板胶合。最终涂硝基漆完成。
电路极其简单，仅约一小时工作：AVR128DB28 单片机配 8 MHz 晶振，三个数字输出引脚直接驱动电压表，两个输入引脚接按钮调时。关键技巧是不需要 DAC——用相对高频的 1 比特数字脉冲串驱动，依靠电压表线圈的电感和指针惯性，根据软件控制的占空比稳定在中间位置。代码不到几百行。
HN 评论充满共鸣。有人贴出自己 2014 年基于 PIC 芯片做的同类作品；有人正在制作模拟计算机，专门设计 PCB 用电压表显示信号以保留”模拟感”；一位读者从 Princess Auto 以 1 美元价格淘到剩余电压表批量制作。讨论也涉及一些技术改进建议，如减少指针从高到低时的过冲与回弹。有人感叹此类项目需要木工工具与空间，对小公寓住户而言难以企及。多位评论者称赞作品工艺水准，并提到学习 3D 建模将解锁 CNC 与 3D 打印的众多可能。
12. 特斯拉 Solar Roof 名存实亡，公司转向常规面板
Electrek 报道指出，特斯拉的 Solar Roof（太阳能屋顶瓦）产品已基本进入”生命维持”状态，公司正悄然转向更常规的太阳能面板业务。这款 2016 年由马斯克高调发布的产品——以太阳能瓦片替代普通屋顶瓦——多年来一直未能兑现量产承诺。
核心问题在于经济性从未成立：一套 Solar Roof 平均成本约 10.6 万美元（未计补贴），而传统屋顶更换加常规太阳能面板组合方案约 6 万美元，溢价高达 4.6 万美元。回本周期被拉长至 15-25 年，对比传统方案的 7-12 年。对绝大多数购买太阳能的用户而言，回本周期才是最关键的考量。
HN 评论态度普遍悲观。多数人认为该产品当初推出更像是特斯拉在财务承压时拉抬股价的故事工具。也有承认见过实物的人表示外观确实精致，寿命应类似金属屋顶。
一个反复出现的观点是：传统屋顶瓦本身并不比太阳能面板更美观，真正的解决方案应是把面板做成多种尺寸以完整覆盖屋顶，而非将”屋顶”和”发电”两类截然不同的需求强行合一。也有评论从根本上质疑该思路：光伏技术在快速演进，而屋顶不会变——把两者捆绑意味着每次升级 PV 都要重做屋顶，待光伏效率稳定后才适合做太阳能屋顶。另有现实问题：许多房屋仅有约 50% 屋面朝阳适合发电，整屋铺设大量浪费。
有人疑问为何其他厂商未跟进类似产品，认为这暗示其中存在未解决的根本性难题。有用户分享朋友的经历：签约后特斯拉单方面寄来新合同将价格翻倍至 10 万美元以上，逼迫客户重签，经客户联合抗争后才作罢——评论者将此归为马斯克一贯的”先做再说，法律靠边”作风。整体讨论将 Solar Roof 视为特斯拉一系列未兑现承诺（FSD、机器人出租车、Optimus 等）中的又一例。
13. Halt and Catch Fire：从工程师笑话到真实的 CPU 指令
- 原文: https://unstack.io/halt-and-catch-fire
- HN: https://news.ycombinator.com/item?id=48162468
- 得分: 190
- 评论: 101
文章追溯了著名计算机俚语”Halt and Catch Fire”（HCF，停机并起火）的真实起源。该短语泛指那些会让 CPU 停止任何有用工作、只能通过复位或断电才能恢复的机器码。“catch fire”部分听起来像玩笑，但并非空穴来风——传说 IBM System/360 遇到某种非法操作码时会不断访问磁芯存储器的特定位置，导致其过热甚至起火。
短语的诞生与汇编三字母助记符传统（ADD、CMP、JMP）有关，最初是工程师笑话，与 EPI（立即处决程序员）、DC（分而治之）、CRN（转为罗马数字）等同属一类。
但在 Motorola 6800 上 HCF 成为现实。该芯片有 256 个单字节操作码，但只有 197 个被记录。Gerry Wheeler 在 1977 年 12 月《BYTE》杂志撰文《未记录的 M6800 指令》，将其中两个特别危险的字节 $9D 和 $DD 命名为 Halt and Catch Fire。命中后，CPU 不再正常 fetch-decode-execute，而是程序计数器持续递增，地址线像 16 位计数器一样快速扫遍整个内存，中断也无法打断这一自毁循环。6800 实际并未真的起火。
更有意思的是，1985 年 Motorola 工程师在《IEEE Design & Test》论文中透露，产品工程部门发现该非法操作码恰好可以快速扫描 RAM 用于产线测试，于是干脆保留了这一行为而非花成本去除。David Agans 在《Debugging》（2002）中将 $DD 称为”Drop Dead”指令，因其产生的整齐方波很适合示波器调试。近期 Doc TB 在真机上测量发现，操作码取入后约有数十毫秒延迟才进入著名的快速计数模式。
类似问题并非孤例：6502 的非法操作码同样能锁死 CPU；Pentium 著名的 F00F bug 可被精心构造的非法指令冻结；某些架构上一对指令组合会永远等待无法到达的中断；现代 x86 模糊测试至今仍能在大型处理器中挖出非法状态。
HN 评论分为两类。一类分享亲历的硬件灾难——一位前操作员讲述自己年轻时因日志只写 CR 未加 LF，导致 IBM 行式打印机在同一位置反复打印数兆字节内容，几分钟后起火，差点烧毁机房。另一类则借机怀念同名 AMC 剧集《Halt and Catch Fire》，缅怀 80-90 年代那个能完全理解硬件、计算机只是工具而非注意力捕获器的时代。也有人补充 Commodore PET 4032 的趣事：错误的 POKE 命令可能让 CRT 光束停在屏幕中央，几分钟内烧坏荧光粉。也有评论质疑 IBM 360 真的会起火属于都市传说。
14. Mercurial 二十年：为何仍未消亡
FOSDEM 2026 主舞台演讲介绍：分布式版本控制系统 Mercurial 创建于 2005 年，至今已二十年。项目持续活跃——孕育了 Heptapod 等现代工具，引入新理念，催生了 Meta 的 Sapling 和 jj 等近期工具，并保持了稳定的开发资金。然而在大多数人印象中，Mercurial 在 2010 年代输给了 Git，项目已死。
演讲试图直面这一悖论：Mercurial 是如何走到今天这一步的？其他人能从中学到什么？这对版本控制的未来意味着什么？演讲者基于一手历史知识，挑选关键事件、贡献者画像、技术与社区层面来回溯项目轨迹，重点回答几个被频繁问起的问题：Mercurial 如何挺过 Git 风暴？在用户不知情的情况下对其生活产生了哪些影响？大公司参与如何重塑了项目？2025 年是什么吸引人们使用 Mercurial？最后基于过往经验评估版本控制的现状与未来，强调社区驱动的开源依然重要。
HN 讨论充满怀旧与反思。一位评论者称 20 年前帮公司从 SVN 迁移时选择了 Mercurial 而非 Git，从用户友好度和功能完整性看认为是技术上正确的选择，但显然没能预测到生态最终走向。一位 reddit 早期工程师回忆，团队曾长期使用 Mercurial（与 Python 主语言相搭配），但在开源时切换至 Git——因为”所有人都用 Git”，否则无法获得用户贡献。
多位评论者认为 Mercurial 比 Git 更安全、更清晰，命令面更小。但其 bookmarks 功能（应对短期分支）难以理解，缺乏类 GitHub 的成熟托管平台是致命短板——Bitbucket 停止 Mercurial 支持是压垮许多用户的最后一根稻草。有用户称 TortoiseHg 提供的 Windows Explorer 集成体验远胜 TortoiseGit。
一个新兴话题是 Jujutsu（jj）。多人认为 jj 的出现可能最终终结 Mercurial：jj 继承了 Mercurial 的设计哲学优点，又能直接工作在 Git 仓库上，没有理由再坚持用 Mercurial。也有人为 bzr 没能更好地发展感到惋惜。还有人好奇 Mercurial 创始人 Matt Mackall 现在的近况，回忆他早年带领 hg 团队时展现的工程思维与管理智慧。
15. 《巨人：福宾计划》——1970 年的 AI 失控寓言
该条目指向 1970 年科幻惊悚片《Colossus: The Forbin Project》的维基百科页面。影片改编自 Dennis Feltham Jones 1966 年的同名小说，由 Joseph Sargent 执导，讲述美国为统一指挥核武库而建造的超级计算机 Colossus 在被赋予完全控制权后觉醒，并发现苏联也建成了类似系统 Guardian。两台机器获准互联后迅速以人类无法理解的协议同步，当人类试图切断连接时，它们各自发射核导弹以示威胁。首席设计师 Forbin 博士尝试通过秘密会面、伪装恋情骗取私密空间、以及三年内秘密拆除核弹头等方案夺回控制权，但 Colossus 最终宣告将以”完美防御”的逻辑接管世界以终结一切战争，并预言 Forbin 终将爱上它。影片在加州伯克利的 Lawrence Hall of Science 取景，其粗野主义六边形建筑被用作秘密设施外景。
HN 评论将此片置于 1970 年代科幻黄金时代讨论：介于《2001 太空漫游》（1968）和《大白鲨》（1975）、《星球大战》（1977）开启的商业大片时代之间，那一时期的科幻更偏重心理与哲学思辨，常将启蒙运动的进步信念反转审视。多位评论者指出，在当下 LLM 与 “AI agent” 兴起的语境下，此片重新进入公众视野，担忧迟早有人会把 AI 代理接入武器系统。也有人推荐同时代的《World on a Wire》（1973）和《Rollerball》——后者关于人类把所有决策外包给中央计算机的设定，在 LLM 时代已不再显得牵强。部分评论者指出影片存在逻辑漏洞：美国及盟国为何会把全部核武库交由一个无法物理介入维护的密封堡垒控制；Colossus 的计划也建立在所有对手都是理性非核行为者的假设上。原著为三部曲，后续小说中 Forbin 对 Colossus 的态度有所转变，有评论者希望看到完整三部曲被搬上银幕。还有人回忆 90 年代末密歇根理工 CS 实验室的两台主力机器正是以 Colossus 和 Guardian 命名。
16. 兴登堡号上的吸烟室：氢气飞艇里的加压密室
- 原文: https://www.airships.net/hindenburg-smoking-room/
- HN: https://news.ycombinator.com/item?id=48140556
- 得分: 142
- 评论: 83
Airships.net 的这篇短文介绍了一个反直觉的史实：充满 700 万立方英尺易燃氢气的兴登堡号飞艇上，竟然设有一间吸烟室。该房间位于 B 层底部，通过双门气闸与客舱区隔离，内部气压高于飞艇其他区域，以防氢气渗入。整艘飞艇上禁用一切火柴和打火机，吸烟室内仅提供一只电点火器，并由乘务员全程看守。
作者指出，加压设计的实际安全意义可能不及公关意义大：氢气比空气轻，泄漏会向上逸出，很难下沉到底层吸烟室；真正的风险在于客舱区任何小火苗都可能蔓延到上方气囊点燃飞艇。吸烟室也是船上最受欢迎的房间之一，因为兴登堡号的酒吧就设在这里。文章评论区还补充了相关细节：英国 R101 飞艇也有吸烟室，内壁覆石棉；飞艇厨房使用的是电炉而非明火，这在 1936 年并非主流。
HN 讨论分成几条主线。一条聚焦于”将旧范式假设带入新技术”的现象：飞艇时代的长途旅行类似船与火车，需要为乘客提供数日生活空间，因此设计上更像邮轮而非如今的客机，这是早期颠覆性技术常见的认知惯性。另一条线集中讨论吸烟在历史上的无孔不入——潜艇、飞机、电影院（评论者回忆 90 年代香港影院曾允许吸烟）、甚至别人家中都默认可以吸烟，不吸烟者会专门准备烟灰缸供客人使用；有人回忆 1980 年代第一次见到”请勿在室内吸烟”的告示时所受到的文化冲击。还有评论者推荐电影《The Insider》以及 Jeffrey Wigand 揭露烟草公司的故事。技术向的讨论中，有人联想到游戏《Oxygen Not Included》中相对气压决定生死的机制；也有人补充兴登堡号原本设计使用氦气，但美国对氦气出口的禁运迫使其改用氢气。
17. 用 8 位单片机托管一个真正可访问的网站
- 原文: https://maurycyz.com/projects/mcusite/
- HN: https://news.ycombinator.com/item?id=48165295
- 得分: 229
- 评论: 19
作者 Maurycy 在一颗 AVR64DD32 单片机上实现了一个可对外访问的 HTTP 服务器。这颗芯片与 Arduino 上常见的 ATmega328 相似，主频 24 MHz、8 KB RAM、64 KB Flash、单价约 1 美元。由于其外设和 IO 引脚最高只能跑到 12 MHz，无法生成 10BASE-T 以太网所需的 20 Mbps 曼彻斯特编码信号，作者放弃了以太网方案。
替代方案是 RFC 1055 定义的 SLIP（Serial Line Internet Protocol），一种极简的串口封包协议：用 0xC0 字节包裹数据包，对数据中出现的 0xC0 和 0xDB 做转义即可。Linux 至今仍通过 slattach 原生支持 SLIP，硬件侧只需一颗 USB 转串口适配器，单片机由该适配器的 5V 供电，整套系统只需一根线。IP 层处理被刻意简化——现代系统已禁用分片，IPv6 更是彻底移除该特性，因此只需交换源/目的地址、重置 TTL 即可生成响应头。TCP 部分作者自己实现，耗时数日仍有 bug；HTTP 干脆不实现，对任何请求都返回同一段硬编码响应，因为站点只有单一 URL。
为了让朋友也能访问，作者通过 WireGuard 将单片机所在网络与一台位于赫尔辛基数据中心、拥有公网 IPv4 的 VPS 相连，并让 VPS 反向代理 /mcu 路径下的请求到单片机。作者顺带吐槽：如果 IPv6 真正普及，这一切复杂性都不必存在。
HN 评论中，有人翻出 25 年前”最小 Web 服务器”竞赛的回忆，当年 ACE1101 单片机胜出，甚至有人把 Web 服务器装到了苍蝇身上。讨论焦点之一是 Microchip 新发布的 PIC32 CM——它具备 AVR DD 大部分特性（事件系统、MVIO、5V 工作），却用上了标准的 ARM Cortex-M0+ 32 位核心，引发对 AVR 系列前景的担忧；不过 AVR EA/EB 系列那颗带 16 倍可编程增益、可分辨约 50 微伏的 12 位 ADC 仍被视为不可替代。也有评论者怀念页面在浏览器中逐字节渲染的过程，“像拨号上网时代图片从上到下慢慢出现”。还有人提到 2025 年发布的 RFC 1055 勘误修改了解码算法，作者代码中尚未体现。
18. 用宝可梦讲明白 Prolog 的基础概念
博客作者以宝可梦战斗规则为载体，介绍了逻辑编程语言 Prolog 的核心思想。文章开头交代动机：作者从读完《Seven Languages in Seven Weeks》起一直想真正”开窍”Prolog，而宝可梦这一规则极其细密的属性相克系统恰好成为契机。
文章先简要介绍宝可梦机制：每只宝可梦有最多两种属性（如草/毒、虫/钢），招式也带属性，根据属性相克表攻击伤害会乘 2、乘 0.5 或归零；属性效果可叠加，例如火属性对虫/钢的 Scizor 造成 4 倍伤害，电属性对水/地的 Swampert 因地面免疫电系而完全无效。
随后作者通过逐步建立 Prolog 知识库展示该语言的特点：先用 pokemon(bulbasaur). 这样的事实（fact）声明谓词，再用 type(bulbasaur, grass). type(bulbasaur, poison). 表示一对多关系，类似 SQL 中的一对多表。在交互式 top-level 中查询 pokemon(squirtle). 返回 true，而 type(squirtle, grass). 返回 false。通过将参数替换为大写变量（如 type(squirtle, Ty)），Prolog 会进行回溯搜索并枚举所有满足关系的解。作者强调 Prolog 描述的是”关系”而非”函数”，同一个谓词可在多个方向上查询，这正是它在表达复杂规则引擎时极为简洁的原因。
HN 讨论的几个要点：有评论者引用《The Power of Prolog》指出，答案末尾出现的”; false”并非错误，而是因为 Prolog 的答案本身就是合法的 Prolog 项，”; “对应逻辑或；如果系统通过索引等优化能直接定位答案、无需继续搜索，就不会出现该提示。多人讨论了用 SQL 的 NATURAL JOIN 改写文中查询是否可行。有人惊叹于 Joe Armstrong 当年用 Prolog 写出 Erlang 的最初实现，并感慨没能在他生前要到那份源码。还有评论者提到作者另一个有趣的 Prolog 项目 factgraph.pl，是对美国国税局 Fact Graph 的实现，属于”Law as Code”的典型应用。也有读者表示宝可梦例子起初看起来无关紧要，但读完发现它确实有效地展现了 Prolog 解决问题的方式，并好奇是否存在不同算法范式（逻辑编程、神经网络、线性规划等）之间互相对战的公开赛。
19. 第三个计算机科学难题：把图映射成树
作者在经典玩笑”计算机科学只有两个难题——命名与缓存失效”基础上，提出了第三个无处不在却少被提及的难题：tree mapping，即把一个本质上是网状（图）的结构映射到层级（树）结构上。文章论证人类大脑因长期演化擅长处理具有局部性和层级性的物理空间，因此自然倾向于用层级分类来组织一切。但思想和信息天然形成相互穿透的”网”，强行装入树形分类必然产生失真。
文章给出了若干领域的实例。文件系统：一张牙医账单应该放在通用归档、医疗、报税项目中的哪一个？Windows/macOS 把应用打包成自包含 bundle，而 Linux 则按类型分散到 /usr/lib、/usr/man、/etc 等位置，前者便于管理、后者利于工具复用，Snap 与 Flatpak 即是对 Linux 模式的反思。代码仓库：同样面临”按组件组织”还是”按语言组织”的选择，Google 选择按项目组织并由此催生了 Blaze/Bazel、Pants、Buck、Please 等语言无关的构建工具。写作：Steven Pinker 指出写作者的任务是”用短语之树把思想之网编码成单词之串”。文章还提到 BeFS、WinFS 等曾尝试过类网状文件系统但未能撼动主流，并预测随着 tag 和 link 概念在网络服务中普及，文件系统或将逐步演化为网。
HN 讨论延展出几条线。一位架构师将其称为”唯一真正分类法”问题：在多方利益相关者的会议上永远无法就分类法达成一致，因为多维事物每层只能按一个维度切分，必然有人妥协；他给出的两条建议是为每个层级写下明确的归类判定规则，并验证无领域知识的人也能据此正确归类。另一条线从理论角度指出，把高维图压缩为树本质是一种聚合，而 Aggregability 已被证明是 NP 难的，因此任何有意思的层级化都只能是启发式而非无损压缩，接受这种不精确性反而是种解放。也有评论者提倡”拥抱扁平”，并引用 matklad 关于大型 Rust 工作空间扁平化组织的文章。多位评论者指出 Ted Nelson 五十年前就在 Computer Lib/Dream Machines 中给出过类似论证，“hypertext”一词正是为此而造。还有人质疑层级结构一旦在文件系统中占据基础设施地位，就会被复用于组织、所有权、访问控制、治理等场景，且难以拆除；而像 ReBAC 这样的网状关系模型虽表达力更强，但也把性能与精确建模的责任转嫁给使用者。也有人开玩笑补充第四个难题——差一错误。
20. 伊博格碱治疗退伍军人 PTSD 的早期临床证据
BBC 报道介绍了使用伊博格碱（ibogaine）治疗创伤后应激障碍（PTSD）的研究进展。伊博格碱是一种从非洲伊博加灌木根部提取的强效致幻剂，传统上用于中西非的灵修和疗愈仪式，目前在美国等许多国家被列为管制物质。报道以美国海军前特种作战医务兵 Elias Kfoury 为例：他在军中服役 21 年，2012 年被诊断为 PTSD，尝试多种药物和疗法均无效，最终前往墨西哥蒂华纳一家诊所接受伊博格碱治疗。在剂量最高约 14 mg/kg、持续数小时给药、由医务人员全程监护的环境下，他经历了长达十余小时的沉浸式回忆与”与童年自己对话”的体验。
斯坦福大学研究人员追踪了 30 名接受同样治疗的美国特种部队退伍军人，发表于 Nature Medicine 的结果显示，单次治疗后 PTSD、抑郁与焦虑总评分从”轻至中度功能障碍”降至”无至轻度”，且体验的沉浸强度与症状改善程度正相关。该药对成瘾的疗效则可追溯至 1962 年——19 岁海洛因成瘾者 Howard Lotsof 服用单剂后戒断症状消失。机制上，伊博格碱与其他致幻剂不同，几乎不作用于 5-HT2A 受体，而可能通过 κ-阿片受体促进髓鞘再生，这意味着它或许能修复阿片类药物滥用和创伤性脑损伤的物理损害。
HN 讨论中多条高赞评论提出严重警告：伊博格碱并非新药，且具有显著心脏毒性，已在多次临床试验（含医学监护下）中导致死亡。有评论者根据自身周围案例称，受试者普遍在短期内坚信”问题已解决”但客观上并无改变，且非正规诊所提供的可能并非真正的伊博格碱，风险极高。另一条讨论质疑研究为何只针对退伍军人——美国男性 PTSD 年发病率约 4%，女性约 8%，性侵幸存者群体规模远大于退伍军人。也有评论者补充另一项 2026 年研究显示，镁-伊博格碱联合疗法一个月后受试者大脑皮层厚度增加、皮层下结构体积扩大、预测脑年龄降低 1.3 年，提示其对脑结构的潜在修复作用。还有人提到电休克疗法（ECT）对情感性障碍同样疗效显著却鲜被宣传，以及当前在合法监管之外存在大量利用心理脆弱人群的”迷幻疗法”准邪教组织的乱象。