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

HN 每日深度阅读 · 2026-07-18

本期以大模型与开源生态为主线：Moonshot 开源 2.8T 参数 Kimi K3、Mozilla 发布开源 AI 现状报告、LM Studio 推出本地代理 Bionic，显示开源权重正逼近前沿；同时 AWS 天价错账、苹果向 OpenAI 前员工发函。

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

共 20 篇 · 约 11,525 字 · 约 29 分钟读完

1. Moonshot 发布 2.8T 参数开源大模型 Kimi K3

Moonshot 发布了 Kimi K3，一款 2.8 万亿参数的开源前沿模型，基于其自研的 Kimi Delta Attention (KDA) 与 Attention Residuals (AttnRes) 架构，原生支持视觉输入，上下文长度达 100 万 token。K3 采用 MoE 稀疏结构，从 896 个专家中激活 16 个，配合 Stable LatentMoE 框架，官方宣称相比 K2 在整体扩展效率上提升约 2.5 倍。模型现已在 Kimi.com、Kimi Work、Kimi Code 与 Kimi API 上线，完整权重将于 2026 年 7 月 27 日前开源。

官方定位是全球首个开源的 3T 级模型，性能仍略逊于 Claude Fable 5 与 GPT-5.6 Sol，但在多项评测中优于其他被测模型。博文强调其在长时程编码、知识工作与推理上的能力，展示了若干案例：K3 在 24 小时沙盒内自主完成 GPU kernel 优化、从零构建了名为 MiniTriton 的类 Triton 编译器（在部分 workload 上超过 Triton 与 torch.compile）、在 48 小时内使用开源 EDA 工具在 Nangate 45nm 工艺上完成了一颗服务其自身 nano 模型的芯片设计（4 mm²、100MHz、模拟解码吞吐 8700+ tokens/s），并在天体物理”I-Love-Q”关系复现中把研究者一到两周的工作压缩到约两小时。

HN 讨论集中在几点：一是模型规模在开源阵营中登顶，超过 DeepSeek V4 Pro、GLM 5.2 等；二是定价 $3/$15 每 M tokens，与 Anthropic Sonnet 系列持平，被视为中国开源模型中价格偏高，但如果性能属实则合理，前提是推理效率不能落后于 GPT/Claude；三是有评论指出中国实验室在推动”智能商品化”，可能是”补充品商品化”策略以推动硬件与基础设施销售；四是有用户实测称 K3 一次就定位到 Fable 5 多次尝试都没找到的 bug；五是有人担心美国实验室在财务与 VC 预期压力下会更被动。整体反响是对 K3 的能力与开源姿态较为惊讶，但对实际推理成本与”是否 benchmaxx”仍持观望。

2. AWS 计费系统故障：用户收到数十亿美元的错误账单

AWS 计费系统出现大规模异常，众多用户在预算告警邮件中看到从数万到数千亿美元不等的账单金额，帖子标题以 17 亿美元为例。故障源于估算账单数据不准确，AWS 随后修复并发送更正说明。HN 上大量用户分享了各自看到的天价数字，从 78 万到 4370 亿美元不等，多人形容那一瞬间的肾上腺素冲击胜过咖啡。

一位自称曾在 AWS 处理过类似事故的评论者给出了较为可信的技术解释：AWS 的每个 SKU/账单行都在”pricing plan”中定义单位类型、区域与单价，计量数据（metering）本身不含单价，而是通过 account id、region、sku 等 join 到 pricing plan。当 pricing plan 中的单位类型配置错误（例如本应是 GB 却被默认解析为 Byte），计量数据的单位换算就完全错位，导致收费被放大约 2^30 倍。他描述过一次凌晨 2 点被寻呼、几小时内修复并道歉的经历。本次事件也被推测为类似的单位错误。

其他讨论包括：多年前 AWS EC2 预留实例节省计算的隐性 bug，用户花 14 个月争取到 7000 美元退款；一位用户曾被真实扣款 2 万美元，通过州总检察长办公室介入才追回，之后转向 Azure；有人调侃这种量级的账单反而”银行的问题不是你的问题”。也有人借此联想到 Anthropic 早前也曾对零使用用户开出 1600 万美元账单，认为大型云与 AI 服务的计费准确性都值得关注。整体氛围既是黑色幽默也是对云计费透明度与自动风控能力的批评。

3. 100 美元 AI 音乐视频对决：Claude Fable 5 vs GPT-5.6 Sol

tryai.dev 团队搭建了一个小型 agentic harness，让模型在给定歌曲、预算和工具集的前提下自主完成一支完整的音乐视频。工具包括 plan、web_search、get_budget、generate_image、generate_video 以及带 ffmpeg/ffprobe 的 shell。模型可自行选择 FAL 或 Replicate 上的图像/视频生成模型并设定参数，预算耗尽后仍可继续剪辑。测试对象为 Claude Fable 5 与 GPT-5.6 Sol，在 25 美元与 100 美元两档预算下各跑一次，歌曲统一为 Bruno Mars 的《Uptown Funk》。

四次运行都在自主完成状态下产出了完整视频。Fable 5 在 100 美元档使用 Seedance 1.0 Pro 输出 1080p，Sol 在 100 美元档混用 Wan 2.5、Veo 3.1 Lite、Hailuo 2.3 三种视频模型；只有 Sol 的 25 美元档使用了 keyframe + image-to-video 流水线。加上 LLM token 成本后，单次运行总花费在 27 到 74 美元之间，Fable 的 token 成本占比高达 30–40%。作者的观察包括：所有模型都在角色和故事一致性上挣扎，都倾向于把歌词直译成画面（“make a dragon wanna retire” 就真给出一只龙），节奏匹配也较弱。

HN 讨论普遍认为技术进步明显但成品艺术价值近乎为零：一名歌词提到”don’t believe me just watch”时画面直接出现戴手表的手臂，被形容为像在玩你画我猜。评论指出好的 MV 通常与歌词保持隐喻距离、有叙事弧线，而这些 AI 产物只是概念平均值的”灰泥”。多位评论者引用某导演使用 Kling + 传统剪辑软件的作品，说明当前视频模型在人类导演调度下已能达到不错的保真度，而完全自主的一次成型则远远不够。也有人从产业角度指出 AI 正在冲击靠美学而非艺术性谋生的中间层艺术家，并展开了关于”艺术是否必然属于人类”的哲学讨论。

4. 苹果向数十名 OpenAI 员工发出法律信函

据 FT 报道，苹果向数十名近期从苹果跳槽至 OpenAI 的前员工发出了法律信函，涉及 OpenAI 与 Jony Ive 团队正在推进的硬件平台项目。信函内容主要属于”文件保全”（document retention / litigation hold）性质，要求相关人员保存潜在证据。报道将其定位为苹果针对疑似专有信息外泄采取的强硬动作，可能是后续正式诉讼的前奏。

HN 讨论围绕几条主线。第一，多位评论者指出 document hold letter 在硅谷跳槽纠纷中是相当常规的做法，FT 的措辞略显戏剧化；有人认为苹果甚至算是”迟到”，因为若真存在信息带走行为，此类信函本应更早发出。第二，一些评论者猜测苹果必然已握有相当扎实的证据，否则不会波及如此规模的人员，一旦成立可能迫使 OpenAI 硬件部门大规模裁员，进而影响其 IPO 计划。第三，从战略层面有人认为 OpenAI 想做硬件平台却低估了做平台的资源和纪律门槛，即便买下 Jony Ive、投入充足预算，也可能因为在苹果专有信息问题上”耍小聪明”而白白点燃数十亿甚至数百亿美元。第四，讨论者提到苹果对 App Store 的掌控是隐性威慑：极端情况下 ChatGPT 应用可能像 Fortnite 一样被下架。也有人反向猜测这可能是双方以诉讼为杠杆的博弈——OpenAI 借反垄断推动 Siri 采用其模型，苹果则借诉讼 discovery 摸清 OpenAI 硬件进度。少数评论把该事件与 OpenAI 在训练数据版权上的争议并列，认为其在”占用他人资产”上具有一致性。

5. Kaggle AGI 基准 Hackathon 获奖结果引发评审公正性质疑

Google DeepMind 与 Kaggle 联合举办的”Measuring Progress Toward AGI: Cognitive Abilities” hackathon 公布了获奖名单，共有超过 1000 支队伍参与，围绕五个认知能力赛道设计新型基准。四个 25000 美元的 Grand Prize 分别授予 MEDLEY-BENCH（社会压力下的行为元认知）、LearningBench（推理时学习）、GAUGE（不确定性感知与放弃机制）和 Metaproteus（模型对自身输出分布的元认知），另有多个 10000 美元赛道奖。

争议来自参赛者在 discussion 区提交的证据，指出多份获奖作品在评审流程和内容质量上存在明显问题，包括疑似 LLM 生成、benchmark 结果不一致、甚至有作品在文本中直接触发提示注入声称自己应当获奖。HN 讨论普遍持批评态度。多数评论认为整个链路——参赛作品由 AI 生成、评审也由 AI 完成——是”AI 与 AI 的天作之合”，AI 判官显然缺乏识别 slop 的常识。有人指出 AI 时代之下”公平的 hackathon”事实上已很难维系，判断标准从人类技能转向创意与内部资源，很多人靠 prompt injection 获胜。

Kaggle 产品经理 Nick 在评论区做了较长回应，强调评审周期已从 1.5 个月延长到 3 个月，每份获奖作品都经过至少 2 名（部分 3–4 名）人类评委独立打分，并承认定性评审必然存在主观性。但许多评论者对回应并不买账，认为”如果你觉得别的作品更该得奖请指出来”这类回复是在把举证责任推给社区。也有评论借此反思 Kaggle 的定位变化：当没有客观 metric 可爬山、只能依赖 LLM as a Judge 时，比赛质量迅速崩塌。整体事件被视为 AI 时代竞赛与评审机制的一次公开压力测试。

6. Mozilla 发布《开源 AI 现状 2026》报告

Mozilla 联合 SlashData 发布首期《State of Open Source AI》报告，由 CTO Raffi Krikorian 撰写开篇。核心结论是：开源权重模型已在能力上基本追平闭源前沿。Chatbot Arena 上开源与闭源的差距从 2024 年 1 月的 8.04% 收窄至 2024 年 8 月的 0.5%（DeepSeek-R1 曾短暂并列榜首），2026 年 3 月因闭源推理模型再度领先而重新扩大到 3.3%；但差距集中在推理、长上下文与 agentic 任务，编码、指令跟随、通用知识几乎打平。GPT-4 级推理成本在 36 个月内下降约 50 倍（20 美元 → 0.4 美元 / 百万 tokens）。

OpenRouter 数据显示，开源模型的 token 份额从 2024 年底约 1/3 上升到 2026 年中的过半，前五大流量模型均为开源；按 token 计算，中国出品的开源模型每周约 18T tokens，是美国出品的 3 倍以上。开发者调查（n=1410）显示：79% 的 AI 开发者在使用开源模型，71% 使用闭源，50% 同时使用两者；但开源团队的生产化率仅 51%，闭源为 63%，且随着企业规模上升，闭源生产化率显著提升（54%→73%），开源几乎无提升（53%→57%）。开发者流失的主要原因是性能、集成、维护等运营性问题，而非模型能力。各地区共同的痛点是基础设施成本、安全合规、部署复杂度。

HN 讨论热点：一，报告本身文风被多位评论者用 Pangram 等工具判定为 LLM 生成，被认为对一份主张开源 AI 严肃性的报告是自伤；二，图表堆砌、行文空洞，被批评为”AI 想象中的 CTO 演示”；三，多人赞同开源模型可能反过来吞噬 OpenAI 与 Anthropic 的价值，因为超大规模云厂与 Apple 都可无授权费部署，前沿模型将成为高成本负担；四，有评论者指出 Mozilla 讲”开门权”的比喻讽刺，因为 Firefox 自身早已被 Chrome 与 Safari 边缘化；五，普遍批评报告混用 “open source” 与 “open weight”，真正提供训练数据与流程的模型稀少，“开源”一词在 AI 语境已被稀释。

7. 首次在宜居带类地行星上发现大气：LHS 1140b

哈佛研究团队在《Science》报告，首次在一颗位于宿主恒星宜居带内的岩石类地行星周围探测到大气。行星 LHS 1140b 距地球 48 光年，围绕一颗比太阳更小、更冷的红矮星运行。目前唯一确认的气体是氦，很可能存在于大气层上部，本身无法支持生命，但更靠下的大气中可能含有其他更利于生命存在的气体。首席作者 Collin Cherubim 称这是”首次在另一颗恒星宜居带的岩石行星上发现大气”，被视为在系外生命探索上迈出的重要一步。此前已确认约 6000 颗系外行星，其中数十颗在宜居带且为岩石类，但均未探测到大气。文章也回顾了 K2-18b（dimethyl sulphide 信号后被 NASA 重新分析认为不足以确认）与 TRAPPIST-1 系统（1d 已被 JWST 排除类地大气，1e 数据仍不确定）的状况。

HN 讨论较为多元。天体物理向的评论指出 LHS 1140b 更可能是被红矮星强烈剥离的迷你海王星而非真正的类地岩石行星，但也有人引用一篇 arXiv 论文（JWST 发射光谱）称已排除了迷你海王星模型。氦能够被保留意味着行星具备相当高的逃逸速度，也有人打趣即便有生命也很难离开母星。围绕费米悖论展开了另一线讨论：地球生命演化数十亿年，人类具备星际通信能力却仅约 50 年，这一”短时间窗”因素在双向叠加后会大幅压低同时代文明相遇概率，与人类未观测到外星文明的现状相符。技术性讨论包括建造太阳引力透镜望远镜以观测候选行星，以及 48 光年距离下有哪些可行的近光速推进方案。也有评论提醒金星同样是”宜居带内的类地大气行星”，警示不宜过度浪漫化”发现大气”这件事。

8. LM Studio 推出 Bionic：面向开源模型的本地 AI 代理

LM Studio 团队发布了新产品 Bionic，一款围绕开源模型构建的 AI 代理应用，与原有的 LM Studio 分开发布。Bionic 主打三类使用场景：编码（可指向本地代码库进行检查、修改、调试，配合内联 diff 审查改动）、文档与办公（在沙箱化的 Work 项目中处理 PDF、幻灯片、表格等，支持自动检查点与回滚）以及基于 Mistral Voxtral 的本地实时语音转写键盘。

模型执行方式灵活：可完全本地运行、通过 LM Link 连接远端设备，或调用 LM Studio Secure Cloud 上托管的更大规模开源前沿模型（如 GLM 5.2、Kimi K2.7 Code）。官方承诺对所有 Bionic 用户实行零数据保留、不用于训练。定位上，团队希望在开源模型持续变强的趋势下，为用户提供在成本、隐私和算力环境之间自由权衡的代理框架。

HN 讨论集中在几个方向。创始人 Yagil 亲自在评论区发放试用额度，收集反馈。早期试用者反馈体验接近 Codex，接入已有本地模型库很顺畅，但也指出若干粗糙之处：当前工作目录展示不够显眼、模型加载状态显示为”Working”而非”Loading model”、无法预加载或方便地卸载模型、缺少全局系统访问、缺少本地网页搜索与 SSH 等。

争议最大的一点是 Bionic 与 LM Studio 本体均为闭源。多位评论者认为，产品口号强调”为开放模型而生”，但代理与执行层本身却不开放，价值观存在冲突；他们认为在模型日益商品化的当下，harness 层是否开源反而更关键。另有用户对商业模式从纯本地转向包含云推理表示担忧，认为这削弱了当初从 Ollama 迁移过来的动机。也有评论认为这类产品预示着未来 Apple 等厂商会将本地模型与代理内建进操作系统，LLM 会逐渐成为计算的新接口。

9. Kimi K3 发布及”鹈鹕基准”还能告诉我们什么

Simon Willison 撰文介绍 Moonshot AI 新发布的 Kimi K3，号称是首个”开放 3T 级”模型（实际 2.8 万亿参数），权重将在 7 月 27 日前开源。官方基准显示 K3 大体超过 Claude Opus 4.8 max 和 GPT-5.5 high，但仍落后于 Claude Fable 5 和 GPT-5.6 Sol。Artificial Analysis 报告称其在长周期知识工作评测中 Elo 达 1547，相较 K2.6 提升 732 分；每任务成本约 0.94 美元，与 GPT-5.6 Sol 接近、约为 Opus 4.8 的一半；输出 token 比 K2.6 少 21%。定价 $3/$15 每百万 token，是国产模型中定价最高的，与 Claude Sonnet 系列持平。

Simon 用惯例的”生成一只骑自行车的鹈鹕 SVG”测试 K3，消耗 16,658 输出 token（其中 1.3 万为推理 token），花费 25 美分。他坦言这个已运行 21 个月的基准与模型实际能力的相关性已基本断裂——GLM-5.2 生成的鹈鹕比 GPT-5.6 和 Claude Fable 5 都好，但它显然不是同级模型。他仍继续使用它，因为它能作为”hello world”式接入检验，快速反映成本、推理开销、SVG 与空间理解能力，以及不同 reasoning effort 的差异。此外他还发现 K3 存在约 85 token 的隐藏系统提示，模型拒绝泄露。

HN 讨论几个有趣的点：有人认为鹈鹕图像已被大量博客与 GitHub 收录，几乎肯定进入了训练集；有人半开玩笑地提议”SWE-bench-adversarial-pelican-gen”，在长上下文代理任务中间穿插要求生成 SVG 以测试稳定性；也有关于同一模型多次生成结果差异较大、单次采样不足以比较的观点。另有讨论聚焦于中国实验室如何在明显较少的算力下训练出万亿级模型，普遍认为 Kimi 3 与美国前沿模型的差距已缩至约三个月。还有评论指出，参数量重要性不如预期，注意力机制的密度可能才是关键区别。

10. 德州仪器发布 USB Type-C 工程师指南

这是德州仪器（TI）出品的一份 74 页 USB Type-C 与 USB Power Delivery 技术指南。文档系统介绍了 USB-C 接口的基础知识，包括数据速率与功率等级、数据/电源角色、引脚定义与可反插特性、线缆检测与方向识别，以及何时需要 USB PD 控制器。文档回顾了 USB 连接器与 PD 协议的发展历史，重点讲解 USB PD 3.1 规范演进，包括 EPR（扩展功率范围）支持最高 240W 供电，以及 CC 线上的 PD 协商、VCONN、消息类型、数据角色与电源角色互换、Alternate Mode（DisplayPort、Thunderbolt）等机制。信号部分覆盖 USB 2.0、SuperSpeed 在 Type-C 上的传输、eUSB2 在先进制程下的必要性，以及信号复用等主题。

HN 讨论中，一位开发者展示了自己开源的 USB-PD 协议分析器项目，指出协议实际使用时通常直接，但双角色设备或同厂商设备之间的交互会变得极其复杂，且大多数场景仍需专用芯片。多位评论者批评 USB-C 从消费者角度看可用性糟糕：同一接口后面可能是完全不同的能力组合（PD 各等级、经典 5V、Alt Mode 等），线缆与设备均无从辨识，用户不得不自行贴标签区分。有观点将其类比 HTTP——一个统一接口下隐藏巨量复杂性，对专家友好但对普通用户困难。也有人指出这份指南本质上是 TI 推销自家 PD 控制器的软文，因为它虽提到 5V 情形不需要 PD 芯片，却未清晰给出低成本实现方案（例如如何用便宜的负载开关绕过 10μF 上电容限制）。EPR 的握手安全设计和 eUSB2 因先进制程下 3.3V 信号会威胁硅片可靠性而诞生等技术细节，也被评论者认为值得关注。此外有人对 USB-C 是”新接口”还是”新协议”的定位表示困惑。

11. Lisp 入门之路：选哪一门方言

作者面向初学者介绍主流 Lisp 方言的差异与选择建议，强调 Lisp 是一个语言家族而非单一语言，Wikipedia 列出的方言超过 20 种。作者认为方言的选择不像新手想象的那么重要——学习 Lisp 本质是学习一种新的思维方式，掌握其中任何一个后转向另一个都相对容易。

文章重点介绍了 Common Lisp。CL 于 1994 年通过 ANSI 标准化，是最成熟、功能最丰富的方言。最著名的实现 SBCL 可编译到原生代码，性能可比肩 C 和 Rust。CL 内建 COMPILE、LOAD、EVAL、DISASSEMBLE 等语言级功能，拥有强大的 condition/restart 系统，可在生产环境中通过 REPL 连接远程运行的进程进行实时调试。它支持函数式、命令式、元编程和面向对象等多种范式，CLOS 提供多重派发与泛型函数。因为标准稳定，1991 年出版的 PAIP 中的代码大多仍能在现代实现上运行。缺点方面，CL 缺乏一些现代语言常见的便利：更丰富的数据结构字面量、持久化不可变集合、惰性序列以及通用模式匹配；社区较小，分散在多个实现和渠道，文档参差。现实应用包括 Rigetti 的量子计算、Grammarly 的语法服务、Google Flight Search（ITA），以及 Common Lisp 实现的 HN（由 dang 用 SBCL 上的 Clarc 重写 Arc）。

HN 讨论极为热烈。有评论者补充 CL 生态其实并不缺现代便利：Serapeum 提供字面量语法、FSet 提供持久化集合、Trivia 做模式匹配、Series 做惰性序列，CIEL 项目整合了这些库。也有多位用户分享自己的学习路径：有人推荐直接读 Practical Common Lisp 上手，之后再看 PAIP、On Lisp、SICP；有人正用 DrRacket 重读 SICP，感慨 Scheme 极简优雅但工作中未必用得上。有人列出”梦想语言”清单——想要 SBCL 的性能、Clojure 的语法与数据结构、DrRacket 的入门友好度、OCaml 的类型系统、Rust 的开发体验，并寄望 jank 或 Roc。还有反对声音，认为 Lisp 并不像神话中那么特别，On Lisp 大多数例子用 Python 也能实现，只有依赖宏的续延实现是例外，而 async/await 已解决类似需求。

12. 人们面对问题的三种反应（除了解决它之外）

作者作为顾问，总结了组织中面对问题时的四种典型反应：解决问题、把问题推给别处、保护问题、以及催生新问题。文章重点展开前三种。

“推问题”是最常见的结果，即在此处改善的代价是让别处变糟——这正是局部优化的表现。作者认为不必责怪当事人，他们只是在自己面前的规则下博弈；真正需要改变的是上级层面的激励机制和系统视角。“保护问题”引用了 Clay Shirky 2010 年的观察，被 Kevin Kelly 命名为”Shirky 原则”：机构会倾向于维护它们赖以存在的问题，复杂的解决方案（公司、行业）会不自觉地延续它所解决的那个问题。作者建议在着手解决问题前先识别谁会因问题消失而失利，把这些人纳入方案。文章还引用 Neil Postman 的问题——“解决这个问题会制造什么新问题？“以及 Jerry Weinberg 的观点：顾问必须痛恨问题，却又必须能与问题共处，否则会被压垮；能选择性忽略问题的人过得最好。

HN 讨论延伸出几个方向。有人补充第五种反应：忽略或淡化问题——95% 的”表面问题”最好被忽略，把精力留给真正重要的 5%。多位评论者认为”保护问题”最能解释政府和大型组织的低效：如果真的解决了犯罪、无家可归、贫困等问题，相应部门的预算和政治权力就会削弱，负责解决的人反而缺乏动机。类似机制也出现在专家个人层面——被认可的专家往往有意无意维持根因不解决，因为这是其地位的合法性来源；识别这种情况通常需要管理层或外部力量介入。还有评论把这四种反应对照到风险管理的四种策略：规避、缓解、转移、接受。也有人略带讽刺地补充第五种反应——“雇顾问来讨论这个问题”。

13. Frame：用汇编写的 Linux X 服务器

作者延续其”自有软件”路线，用汇编语言从零编写了一个名为 frame 的 X 服务器，替代掉了 4 百万行代码的 X11。frame 无依赖、无库、无 GC，约 2 万行汇编，已能驱动作者的整个桌面，包括 Firefox 和 GIMP。作者的整套 CHasm 汇编栈（Linux 内核 + frame + 平铺窗口管理器 tile + 状态栏 strip + 终端 glass + shell bare + 登录管理 bolt）约 10 万行，取代了原本约 50 倍规模的 gdm/Xorg/i3/conky/wezterm/zsh 组合。作者称这样做的主要动机是延长电池续航——空闲时 frame 与 Xorg 消耗相同的整机功耗（因为面板和 WiFi 占大头），但 Xorg 的 CPU 消耗几乎是 frame 的三倍；tile 和 glass 在三分钟测量中 CPU 时间为零。作者透露开发过程中大量借助 Claude 协助——描述需求、由 Claude 生成代码，同时自己学习硬件层、光标绘制、GPU 交接等知识。

HN 评论几乎一边倒地聚焦在”这其实是 LLM 写的”这一事实上。一开始许多人对手写 2.5 万行汇编感到敬佩，得知是 Claude 生成后感到失望。有资深汇编程序员指出，如果人来写，会用 nasm 的宏系统封装函数序言/尾声、调用约定等模板，源码可以像 C 一样紧凑；而 LLM 生成的代码没有这种压缩，因为对它而言文本长度无所谓。有人调侃这是”把 LLM 当编译器用”，还不如直接 cc -S 或反汇编现成 Xorg。围绕”我写了 X”这个说法的语义也有争议，评论者感慨”写了”一词在 2026 年正在失去含义。也有正面评价——赞赏 X11 从”太庞大无法重写”到”多个从零实现”的转变，并注意到现在出现了几个风格迥异的新 X 服务器实现。有人尝试运行 frame 但无法让窗口获得焦点。也有人期待类似方式修复 Wayland 的痛点，或让 frame 在树莓派等老硬件上流畅运行。

14. lobste.rs 迁移到 SQLite

lobste.rs 完成了从 MariaDB 到 SQLite 的数据库迁移。作者与站长 pushcx 于周六部署，等到周一流量高峰验证稳定后才对外公布。迁移后 CPU 使用下降、内存下降、站点响应更快，下线 MariaDB VPS 后成本减半。相关议题 #539 也被关闭。

迁移始于 2019 年，最初讨论的是迁往 PostgreSQL；2025 年因 K1 收购 MariaDB 引发对未来的担忧，Rahul 提出”lobsters 能跑在 SQLite 上吗？“的详细方案。作者于 2025 年 6 月接手，8 月提交首个 PR，中途因过期被关闭，遂另开 PR，加入性能测试与自研的迁移脚本。首次部署（2 月 21 日）失败——只读流量就把所有 CPU 打到 100%，随后回滚。作者事后修复了搜索的小问题、开发了模拟半数生产数据的批量生成脚本，并解决了三处性能瓶颈：两处大表全表扫描和一处 N+1 查询，另增加慢查询日志。7 月 11 日第二次部署成功。

技术经验方面：SQLite gem 支持用户自定义函数，作者用它补上了 regexp、if、stddev 等 MariaDB 有而 SQLite 缺的函数，避免大量 SQL 迁移改写；SQLite 不支持 unsigned bigint，需要改成有符号；SQLite 的排序规则较弱，原 utf8mb4_general_ci 换成 NOCASE，但后者只支持 ASCII 而非完整 UTF 大小写折叠；FTS5 推荐使用 Contentless-Delete Tables。

HN 讨论意见分化。有用户反馈迁移后站点反而不稳，页面渲染有时耗时数秒，甚至偶尔出现渲染失败；还遇到一个 Rails bug 导致投票数据丢失、站点进入只读数小时——不确定这些是常规迁移期问题还是 SQLite 本身的选型代价。有评论指出原议题中”担心 K1 收购后 MariaDB 会闭源”的理由并不成立，因为 MariaDB 是 MySQL 的 GPL 派生，法律上无法闭源，而 MariaDB Foundation 与商业实体也是分开的。还有讨论涉及 SQLite 的统计信息（会在连接时自动收集）、行删除的物理清理需要 vacuum、WAL 模式下多库 ATTACH 的一致性限制等。也有质疑声——这次迁移是否值得，是否只是”为工程而工程”，未必带来产品层面的改进。

15. 用退役底盘 DIY 一辆电影级摄影追拍车

作者 Dane（transistor-man）分享了将一台从麻省 BMI Surplus 剩余物资商店淘来的神秘遥控底盘改造为地面摄影追拍车（camera chase vehicle）的完整过程。项目起因是四旋翼无人机在贴地低空拍摄时受限于 GPS 高度精度和避障难度，而地面遥控车在拍摄卡丁车等贴地题材时更具优势。

原始底盘来源不明，疑似来自 Lincoln Laboratory，顶部装有一根用途不详的 Z 轴线性执行器，作者花约 50 美元购得。他先测试了原有直流电机线性执行器，能实现缩放式推拉镜头效果，随后拆掉 Z 轴，因为原有 4-40 长立柱过于纤细，无法承受 Movi M10 电影级云台的重量。

文章详细记录了机械改造过程：先用 3D 打印适配件做等比模型确认整体高度和重心问题，然后用 CNC 车削出结构性 M8 沉头螺丝立柱，将云台尽可能贴近底盘以降低翻车风险；电池布局考虑了热插拔便利性和侧向保护；甚至提到用 TPU 打印件增加抗剪切性能的技巧。文章保留了大量失败迭代、机械妥协和现场照片。

HN 评论一片赞誉，认为这是”真正的 Hacker News”——零功利、纯粹表达的硬件项目，在满屏 ML 新模型的信息流中像一片绿洲。有人回忆作者 2015 年发布的”Flying Nimbus”（早于 Onewheel 的独轮电动板），感慨其”多重发现”现象。多位评论者赞叹作者一边有全职工程工作、一边持续产出这种详尽记录的能力，并对比指出这类硬件工程内容是 LLM 难以凭空复现的。也有轻松调侃，如云台上方”猫耳朵”式支架、希望看到翻车第一人称视角、以及底盘上的 googly eyes 装饰。整体讨论呈现出对老式个人网站文化和硬核工程博客的怀旧氛围。

16. Recurse Center 十五周年：一位创始人的感谢帖

这是 Recurse Center（前身 Hacker School）创始成员在 HN 发布的十五周年感谢帖，回顾了这个位于纽约的自由式程序员静修项目从 HN 起步、逐步找到”人生事业”的历程。RC 对参与者完全免费，收入来自向雇主收取的招聘费——校友被公司录用时，公司支付费用，但不从校友薪水中扣除。这一模式在 FAQ 深处才能找到，被评论者猜测是刻意筛掉只冲着”免费”而来、不认真投入体验的申请者。

RC 以”社交规则”（social rules）著称，如”无假装惊讶”等，营造心理安全的学习环境。评论区聚集了大量校友的回忆：十多年前在曼哈顿 Canal Street 附近的空间里编程，晚上和其他 Recursers 逛博物馆、公园、吃廉价饺子；有人当时住在上东区破旧的 Kolping House 廉价房间，物质匮乏却精神富足；另一位在 2021 年通过 RC 找到 DuckDuckGo 的”梦想工作”，至今已工作近五年。还有人通过 RC 结识的朋友后来一起进入 YC 创业。

也有不同的声音：一位参与者坦言自己的体验”相当平淡”，观察到大家很快组成小团体、频繁讨论 Zulip、并暗中比较谁的每周项目能冲上 HN 前三十，从旁观视角看有点像”小型邪教”，但也承认这是文化差异导致，参与者本身都很友善乐于助人，只是这种模式并不适合每个人。

多位评论者感慨 HN 上能持续活跃十五年以上的项目本身就极为罕见，也有人表示一直想申请但因职业空窗风险迟迟未行动，希望有朝一日能参与。整体氛围温暖而怀旧。

17. Kaiser 护士抗议 AI 监控：15 分钟通话时限危及病人护理

CalMatters 报道，Kaiser Permanente 的电话咨询与分诊护士反映，日益强化的职场监控和 AI 系统正在损害其对病人的照护责任。七位现任和前任护士表示，凡是与病人通话超过 15 分钟的，会遭到管理层批评或被叫去做绩效评估。通话时长会计入每月绩效评分。除跟踪通话时长外，Kaiser 还使用软件按日预测护士是否”效率低下”或接听不够快，AI 系统甚至被用来评估护士的共情程度和语气语调。

一位护士回忆，去年曾与一位自杀倾向病人通话一个多小时，直到警察到场才敢挂断，明知这会打乱她数周的平均通话时长；另一位护士面对刚被确诊癌症晚期、需要倾诉的老年病人时，因担心被处分而克制了本应给予的安慰：“我是不是会因为说了脚本之外的话而被处罚？”

事件正值加州护士协会（CNA）代表 2.5 万名护士（含 1000 名呼叫中心护士）与 Kaiser 谈判新合同，AI 议题预计成为焦点。此前护士已在 3 月和去年秋天举行过针对 AI 的罢工与示威。加州立法机构也在审议多项工作场所 AI 监管法案，其中一项将保护推翻自动化护理建议的医生和护士免受报复。

Kaiser 回应否认使用”平均通话时长”评估绩效，称所有工具都有人工审核监督，以病人安全、隐私和公平为优先。但有评论者指出报道细节：护士抱怨的是超过阈值的长通话，而 Kaiser 回应的是”平均时长”，存在语义偷换。作为加州最大私营雇主、服务 900 万加州病人的机构，Kaiser 的 AI 使用方式可能为整个医疗行业管理劳动力设立先例。

HN 讨论围绕几个方向：用机器评估人类共情本身就荒谬；类似做法已扩展到 UHC 等其他保险巨头；欧盟 AI 法案已禁止此类应用；根源在于医疗行业以盈利为主导；也有少数声音质疑爆料真实性，指 Kaiser 因严格协议遵循反而拥有较好的健康结果指标。

18. Show HN：实时围观 SSH 蜜罐里的机器人攻击

作者搭建了一个公开的 SSH 蜜罐实时仪表盘 honeypotlive.cc，将入站连接的源 IP、用户名、密码、执行命令、客户端指纹等遥测数据以直播形式展示，用于安全研究、威胁情报和教育目的。页面免责声明强调，展示的源 IP 可能属于被入侵主机、代理、VPN、扫描器、云实例或僵尸网络节点，并不代表实际攻击者身份；显示的攻击者提交命令、凭证、URL、公钥、恶意软件投递等内容属于不可信数据，不应视为可安全执行的代码。

HN 讨论既有技术兴趣也有恶搞：许多用户打开网站后发现已被人恶意刷屏（如反复输入《蜜蜂总动员》电影开头），把本应展示真实 bot 攻击模式的界面淹没在垃圾内容里，也有人调侃”用 SSH 输入去打 web 界面的 XSS 就更有趣了”。有开发者顺势介绍自己在做的类似项目 honeyprompt，用 LLM 生成响应并支持多协议。

多位评论者感想公网 IP 上背景噪声之大令人震撼，建议增加客户端地理位置、ASN 和国家信息，做一个”攻击来源排行榜”。有人根据自己的实验经验指出，恶意流量中来自 Azure 的比例出乎意料地高。也有隐私建议：可以对 IP 和凭证做定期轮换的密钥哈希，既允许在时间窗口内做关联分析，又不暴露原始值。有人引用了 xkcd 350（关于允许陌生人在自己机器上执行任意代码的漫画）作比。总体是个轻松的社区互动项目，教育价值和娱乐价值兼具。

19. Zilog Z80 五十周年：一颗 8 位处理器的传奇

文章纪念 Zilog Z80 处理器于 1976 年 7 月正式发布五十周年。作者感慨这颗芯片距今已经跨越了半个多世纪的历史节点。Z80 极其成功，被广泛用于早期个人电脑、家用计算机、爱好者机型以及大量工业嵌入式应用；因与 Intel 8080/8085 二进制兼容，它促成了 8 位微机 CP/M 和 Microsoft BASIC 的事实标准。Z80 也衍生出诸多克隆和派生架构，包括初代 Game Boy 使用的 Sharp LR35902。Zilog 后来放弃了 16/32 位路线，回归 Z80 微控制器和更高频流水线化的 eZ80，主要面向工业领域，直到两年前才正式停产原版 Z80。

文章的主要篇幅并非罗列辉煌，而是回溯 Z80 的技术家谱：从 Datapoint 2200 终端的 TTL 拼装 CPU，到 Intel 与 TI 分别被委托做单芯片化（TI 放弃，Intel 完成后命名为 8008），再到 Federico Faggin 从 4004 项目转来推动的 8080，最终诞生了 Z80。作者详细描述了 8008 架构：7 个寄存器（A、B、C、D、E、H、L）加上通过 HL 访问内存的伪寄存器 M，14 位地址空间，独立 32 端口 I/O 空间，内部 8 层调用栈（因原本预设使用串行内存），中断通过 RST 指令跳转到 8 个固定入口，约 3500 个晶体管、DIP18 封装、500kHz、需要双相时钟和 +5V/-9V 双电源。作者还分享了自己作为晚辈爱好者从电子目录中发现 Z80 仍在售、自制 PCB、听老师讲述用特百惠盒装线绕 CP/M 电脑写论文等趣闻，以及从项目中学到的系统工程教训（可靠的上电复位远比想象中难；写链接器比写汇编器难；写编译器”真的能做”）。

HN 评论区变成了一场怀旧盛会：一位近 70 岁的读者回忆 1978 年用示波器和逻辑探针啃 Z80 手册的夜晚；ZX-81、TRS-80 Model I、澳大利亚 Microbee、苏联 ZX Spectrum 克隆机的主人纷纷现身；有人指出文章漏掉了至今仍用 Z80/eZ80 的 TI-84 计算器，被数百万美国学生每天携带；也有人纠正文中”完全二进制兼容 8080”的说法——奇偶标志位行为不同，且 Z80 复用了 8080 的未定义操作码。还有人分享了 FOSS 的开源 Z80 复刻项目 z80-open-silicon。

20. Julia Evans：使用 SQLite 运行网站踩过的几个坑

Julia Evans 分享了在 Django 项目中使用 SQLite 作为生产数据库时学到的若干经验。这是她第四次在网站中用 SQLite，但因为 Django ORM 让数据库承担更多工作，遇到了以前没碰到的问题。她一开始按博客建议启用了 WAL 模式，然后见招拆招。

ANALYZE 很重要：一个基于 FTS5 全文搜索的查询，在 4000 行的表上竟耗时 5 秒。运行 ANALYZE 生成统计信息后，查询立刻降到 0.05 秒。作者猜测原本是某种”意外的二次复杂度”问题，坦承自己还不太会读查询计划。

清理数据很麻烦：删除大量行的操作可能超过 5 秒，此时其他 worker 尝试写库会因超时崩溃、导致 VM 关闭。她的临时方案是分小批次删除，并因此更理解为什么有人偏好支持多写的 Postgres。

备份：介绍了两种方式，一是用 VACUUM INTO 导出后 gzip 再用 restic 上传 S3；二是尝试 Litestream 做增量备份，因为 restic 备份有时会被 OOM 杀掉。她坦承没真正测试过恢复流程，但用 dead man’s switch 监控备份是否正常运行。

其他小贴士：可以把不需要 join 的表拆分到多个 SQLite 数据库文件；Mess with DNS 项目从 Postgres 迁到 SQLite 已稳定运行四年。

HN 评论提供了大量实用补充：sqlite3 CLI 的 .expert 模式可以直接推荐索引，无需自己读查询计划；有人开源了 s3-credentials 工具解决 AWS 凭证生成之痛，并推荐 Cloudflare R2 搭配 restic；有人分享用 sqlite3 .dump | zstd --rsyncable 做增量友好的备份，1.8GB 的 Home Assistant 库压缩后仅 286MB，且不阻塞 writer（WAL 模式下）；对慢 DELETE 建议分批、批间延迟、先 SELECT 预加载 rowid、按插入顺序或反序删除以贴合物理存储布局。也有人问 ORM 的 DELETE 是否因循环单条删除而非批量删除导致慢，并建议改用 SQLite CLI 直接执行以避开 Python 事务开销。另外推荐加入 django-silk 或 debug-toolbar 做自动性能分析。也有一派声音直言：需要网络访问或强并发时就该上 Postgres，别硬撑 SQLite。