2026-08-28

46 篇热帖

1. Get your Windows license refund (en.refund4freedom.org)

Windows 预装许可退款指南与运动摘要

本文旨在倡导一项权利运动,要求消费者在购买笔记本电脑或智能手机等通用计算设备时,有权拒绝支付其不想要的预装操作系统(如 Microsoft Windows)的许可费用。

核心主张与诉求

运动认为,硬件设备应当在软件选择上保持中立。消费者的核心诉求包括:

  1. 软件选择自由:制造商不应强制消费者购买或使用特定的操作系统。
  2. 定价透明:消费者应有权选择购买不含预装软件(含操作系统)的设备,并享受相应的价格减免。
  3. 便捷的退款流程:退款程序应公开、简单且易于操作,不应要求消费者为了移除软件而必须寄送整个设备进行维修。

如何申请许可退款

若消费者希望申请退款,建议遵循以下步骤:

  1. 留存证据:在格式化存储设备前,拍摄或录制合同中关于退款条款的相关页面。
  2. 联系厂商:通过电话、聊天或电子邮件联系制造商客服,并完整保留所有沟通记录(包括通话时间、联系人及聊天文本)。
  3. 提交正式申请:若厂商拒绝请求,应填写并提交正式的退款申请表。

主要制造商政策概况

根据现有资料,不同厂商对待预装软件退款的态度和流程差异巨大:

厂商 是否有退款程序 备注
Asus (华硕) 是 流程相对便捷。无需邮寄设备;退款金额在 9 至 65 欧元之间;需在购买后 30 天内通过邮件申请,且在开机时未接受 EULA 协议。
Lenovo (联想) 是 需要将电脑寄送到联想协助中心。
Acer (宏碁) 是 需要通过官网填写表格,并将电脑寄送到协助中心。
MSI (微星) 是 需在官网注册并提交工单,通常需要将设备寄往波兰。
HP (惠普) 否 缺乏明确的退款程序,且多次有客户反映请求被忽略。
Dell (戴尔) 否 条款规定,若不接受预装操作系统许可,则需退还整台电脑。

维权案例与实践

通过收集的用户报告显示,即便厂商初期拒绝,消费者仍可通过法律手段或持续沟通获得补偿:

  • 法律途径:多名用户(如来自意大利的用户)通过向治安法官提起诉讼,成功从 Acer、Lenovo、HP 和 Dell 等厂商处获得了 Windows 许可费的退款。部分案例甚至涉及到了法律费用赔偿或因恶意诉讼导致的损害赔偿。
  • 成功案例:用户通过不同方式成功拿回了约 40 至 130 欧元不等的退款,证明了该诉求的可行性。

其他建议与资源

  • 替代方案:建议消费者寻找支持 Linux 的友好型商店购买免许可设备,或通过特定资源学习如何在智能手机上安装其他操作系统。
  • 参与运动:鼓励消费者通过社交媒体标签 #Refund4Freedom 和 #GetYourWindowsRefund 分享自己的维权经历,以增强运动的影响力。
2. “It works better in the app” (shkspr.mobi)

“在应用中体验更好”:对移动应用功能碎片化的批判

本文通过作者在尝试使用 Google Calendar(谷歌日历)时遇到的功能缺失问题,探讨了现代移动应用开发中存在的过度追求用户留存而牺牲功能完整性的现象。

核心事件

作者试图在运行 Android 系统的 Google Pixel 手机上通过 URL 订阅一个事件日历,但发现 Google Calendar 的移动端应用并不支持此功能。根据谷歌官方说明,用户必须通过电脑端的网页浏览器才能完成日历订阅。作者最终通过在手机浏览器中开启“桌面模式”访问网页版完成订阅后,该日历才同步显示在移动应用中。

主要观点

  • 企业目标的错位:作者认为,许多公司(不仅限于 Google)开发 App 的首要动力是为了提高用户参与度等关键绩效指标(KPI)或目标与关键结果(OKR),从而获得奖金。这导致许多应用功能不全,虽然试图占据用户的首屏,但当用户进行某些特定操作时,却不得不被重新引导回网页端。
  • App 与 Web 的演进关系:
    • 更新成本:从 Symbian 到 BlackBerry 等早期移动平台,App 的核心痛点在于更新困难(需要测试大量设备并经过漫长的分发流程)。为了解决动态获取功能的问题,人类最终“重新发明”了 Web 浏览器。
    • 功能边界模糊:虽然原生 App 在某些特定领域仍具优势,但 Web 技术(如 Service Workers 实现离线功能、便捷的网站图标添加等)正在不断缩小与 App 之间的差距。

结论

作者批评了目前许多“半成品”式应用的现状。他指出,如果企业决定开发移动应用,就应当提供完整、闭环且功能完备的产品体验,而不是让用户在应用与网页之间来回跳转。

3. GLM-5.3 is now open-weight (huggingface.co)

GLM-5.3 开源权重发布摘要

GLM-5.3 已正式发布开源权重。该模型沿用了 GLM-5.2 的底座模型,其性能提升主要源于后训练(post-training)阶段的优化。与 GLM-5.2 相比,GLM-5.3 在复杂编程和长程任务(long-horizon tasks)方面表现更为出色。

核心能力提升

  • 编程能力增强:GLM-5.3 是目前能力最强的开源编程模型。在内部的 Z.ai Code Bench 测试中,其表现较 GLM-5.2 提升了 50%。同时,在 Terminal Bench 3.0 和 Agents' Last Exam 等公开基准测试中也达到了开源领域的 SOTA(顶尖)水平。
  • 网络安全能力(Cyber Capability):随着后训练规模的扩大,模型展现出了超预期的网络安全能力。GLM-5.3 在漏洞发现基准测试 CyberGym 上达到了 SOTA 水平;在漏洞利用(exploitation)链条的后续环节中,其表现提升尤为显著,在相关基准测试中的性能是 GLM-5.2 的两倍以上。

本地部署支持

GLM-5.3 支持多种主流框架的本地部署,包括:

  • 推理框架:SGLang, vLLM, TokenSpeed, Transformers, KTransformers, Unsloth。
  • 硬件平台:针对 Ascend NPU 平台,支持 vLLM-Ascend、xLLM 和 SGLang。

使用注意事项

  • 思考预算控制:模型支持通过 reasoning_effort 参数控制思考深度,可选等级为 low(低)、high(高)和 max(最大)。若不传参或设置其他值,默认值为 max。在进行基准测试或排行榜复现时,建议保持默认的 max 设置。
  • 对话模板设置:在对话场景下,建议显式将 clear_thinking 参数设置为 true(该参数默认为 false)。
4. GUIs should be fully keyboard-driven (ckardaris.com)

摘要:GUI 应当实现完全的键盘驱动

本文探讨了关于开发终端用户界面 (TUI) 与图形用户界面 (GUI) 的辩论,并针对“TUI 因其键盘驱动特性而优于 GUI”这一观点提出了反驳。

核心争议

在关于开发者是否应停止开发 TUI 并转向 GUI 的讨论中,一个常见的论点是:TUI 应该比 GUI 更受青睐,因为 TUI 更容易通过键盘进行操作。

主要观点

作者认为,这一论点缺乏坚实的基础,其核心逻辑存在误区:

  • GUI 的功能性:GUI 框架的功能通常是 TUI 的超集。TUI 在键盘操作上的优势,实际上反映了许多 GUI 应用在键盘导航设计上的不足,而非 TUI 本身的本质优势。
  • 设计规范的支持:许多 GUI 框架的设计指南都明确鼓励开发者提供完整的键盘驱动支持。例如,GNOME 人机交互指南规定,用户不仅可以通过指针完成所有操作,也应当能够通过键盘移动并与用户界面的任何部分进行交互。
  • 技术可行性与开发者意愿:在大多数情况下,实现键盘导航并非技术难题,而是一个开发者的意愿问题。作者通过自身开发 GUI 应用(如 Klisi)的经验指出,投入时间实现覆盖全功能的键盘快捷键是提升用户体验的关键。

结论

开发者不应在用户体验上妥协。为了提供更直观、更高效的交互,GUI 开发应当致力于实现完整的键盘驱动功能,而不应忽视这一重要特性。

5. Htmx 4.0 (four.htmx.org)

htmx 4.0 发布概述

htmx 4.0.0 正式发布,其核心变化是将内部实现从 XMLHttpRequest 迁移到了 fetch() API,以简化异步编程并支持 HTML 流式传输。

三大核心变更

  1. 属性继承 (Attribute Inheritance):

    • 从隐式变为显式:在 htmx 2 中,父元素的属性默认会被子元素继承;在 htmx 4 中,除非显式声明,否则不再继承。
    • 使用方法:若需继承属性,必须在属性名后添加 :inherited 后缀(例如:hx-confirm:inherited="Are you sure?")。这是从 2.x 迁移到 4.x 的主要工作量所在。
  2. 事件标准化 (Events):

    • 统一命名规范:所有事件现在遵循 htmx:phase:action[:sub-action] 的格式(例如:htmx:before:request、htmx:after:swap)。
    • 移除旧事件:移除了 htmx:xhr:* 事件(因切换至 fetch())以及 htmx:validation:* 事件(转而使用浏览器原生表单验证)。
  3. 历史记录支持 (History):

    • 放弃 localStorage 缓存:为了避免第三方 JavaScript 库引起的 DOM 状态不一致问题,htmx 4 在后退导航时不再从 localStorage 恢复快照,而是重新请求页面并进行交换。
    • 替代方案:若需要本地缓存,可使用 hx-history-cache 扩展,该扩展通过 sessionStorage 实现并优化了与 Alpine.js 等工具的兼容性。

主要新功能

  • Morph Swaps(变形交换):原生内置了对形态变形交换(Morphing swaps)的支持,利用改进的算法实现更平滑的 DOM 更新。
  • <hx-partial> 标签:提供了一种比“带外交换”(out-of-band swaps)更清晰的方式,用于在一个操作中更新多个不同的目标元素。
  • 扩展程序生态:
    • 功能性扩展:包括 hx-preload(预加载)、hx-download(基于 fetch 的下载)、hx-alpine-compat(兼容 Alpine.js)等。
    • 流式传输扩展:支持 SSE (hx-sse)、WebSockets (hx-ws) 和 multipart (hx-multipart)。
    • hx-live:一种与 htmx 紧密集成的轻量级前端脚本解决方案,支持基于 DOM 的响应式开发。
  • htmax.js 捆绑包:为了方便用户,官方提供了一个集成了常用扩展的单一 JS 文件。

升级与安装

  • 升级工具:官方提供了 npx htmx.org@4.0.0 upgrade-check 命令行工具,用于自动扫描代码库中的旧属性、事件名及 API 调用。
  • LLM 支持:为 AI 辅助编程提供了专门的指导、调试及迁移技能文件(Skills files)。
  • 发布策略:为了避免破坏依赖非版本化 CDN 的用户,htmx 2.x 将继续保持 NPM 的 latest 标签;4.0 版本将标记为 next,该策略预计持续到 2027 年初。
6. U.S. sanctions against the A/I Collective (www.inventati.org)

A/I (Autistici/Inventati) 集体简介与运营原则

背景与宗旨 A/I (Autistici/Inventati) 集体成立于 2001 年,由来自自主反资本主义运动、关注技术领域并活跃于数字权利斗争的个人及集体组成。该集体的核心目标是为活动人士及其他个体提供数字自卫平台和工具,以满足其对自由通信的需求。

运营模式

  • 免费与数据保护:集体提供的所有服务均完全免费,不进行任何形式的用户个人数据控制或商品化。
  • 志愿者驱动:集体成员均为志愿者,凭借多年在激进活动中积累的技术、政治和法律研究经验开展工作。其运作基于团结和自我组织的原则,不获取任何形式的薪酬。
  • 资金来源:集体的财务策略完全依赖于自愿捐款。

服务准则与申请流程

  • 非商业用途限制:服务严格仅限于非商业用途,旨在支持与集体价值观相符的特定个人或团体。
  • 人工审核机制:为确保申请符合上述前提条件,每项服务请求均由志愿者通过对话形式进行人工审核。所有请求在处理后均会进行匿名化处理并予以销毁。
  • 用户要求:用户在申请服务前,必须仔细阅读并同意集体的宣言、政策以及隐私政策。
7. Luanti removed from Google Play due to baseless AI copyright notice (blog.luanti.org)

Luanti 因无理的 AI 版权通知从 Google Play 下架

事件概述

Luanti 的 Android 应用目前已从 Google Play 商店下架。此次下架是由于 Tracer.AI 代表微软(Microsoft)提交了一份 DMCA(数字千年版权法)通知,声称 Luanti 侵犯了 Minecraft 的版权。Luanti 官方对此表示坚决反对,强调其应用内并不包含任何来自 Minecraft 或其他来源的专有代码或资产。

Luanti 的澄清与技术细节

Luanti 官方针对版权指控提供了以下技术与事实说明:

  • 平台性质:Luanti 是一个开源的体素(voxel)游戏创作平台,旨在让用户创建、分享和游玩方块类游戏。它本身并不自带任何游戏或游戏资产。
  • 资产构成:
    • 引擎资产:应用内置的所有纹理均为原创,字体也已按许可协议进行了正确归属。
    • 游戏内容:Luanti 不再内置“Minetest Game”,该游戏现在通过客户端独立下载,其所有资产均为原创且拥有合法授权。
    • 第三方内容:用户通过 ContentDB 下载的游戏、模组和材质包均为第三方内容。ContentDB 设有志愿审核机制,并正在研究使用感知哈希算法进行自动检测,但始终坚持由人工做出最终决策。
  • 艺术风格争议:官方指出,使用 3D 立方体或体素作为艺术风格属于一种游戏类型(类似于 Minecraft 受 Infiniminer 启发),不应被任何公司通过 DMCA 手段进行垄断。

关于 Tracer.AI 与重复发生的争议

Tracer.AI 是一家使用 AI 代理进行自动化品牌保护和侵权检测的平台。Luanti 指出,这种高度自动化的流程导致了大量误报。类似事件此前已多次发生:

  • 2023 年事件:Luanti 曾遭遇过同样的错误通知,经过 46 天的申诉后才恢复上架。
  • 其他案例:今年,另一款名为 Allumeria 的独立游戏也因 Tracer.AI 的类似通知被暂时从 Steam 下架,最终在公众压力下撤回了指控。

系统性问题与诉求

Luanti 对当前的版权保护机制提出了质疑:

  1. 法律合规性问题:根据 DMCA 第 512(g)(2)(c) 条,服务商在收到反通知后应在 10 至 14 个工作日内恢复内容。Luanti 指责 Google 未能遵守这一法律规定的时间表。
  2. 对 AI 滥用的担忧:开发者呼吁微软、Mojang 和 Tracer.AI 停止依赖未经人工核实、缺乏实质证据且内容模糊的 AI 工具发送版权通知。
  3. 对 Google 的要求:要求 Google 改进通知验证流程,允许用户在应用不被长时间下架的情况下进行回应,并严格遵守版权法。

当前状态与获取途径

Luanti 已提交反通知,并希望应用能尽快恢复。目前,用户仍可以通过 F-Droid 或 Luanti 官方网站 下载 APK 安装包。

8. Inception-style curved map for turn-by-turn directions (www.orbify.eu)

Orbify 弯曲地图演示摘要

产品概述

Orbify 展示了一种类似于“盗梦空间”(Inception-style)风格的弯曲地图技术,旨在为转向导航(turn-by-turn directions)提供创新的视觉呈现方式。

技术细节

  • 核心技术:该项目采用了一种正在申请专利的“扭曲技术”(Warping technology,专利号:PCT/EP2026/058725)。
  • 渲染引擎:3D 渲染由 PlayCanvas 引擎驱动。
  • 演示模型:当前演示版本使用的是由 Justin Eastman 制作的安大略省汉密尔顿体育场(Hamilton Stadium)模型。

交互控制

用户可以通过以下操作方式在 Web 演示中进行交互:

  • 移动:使用 WASD 键。
  • 平移:通过鼠标左键拖动。
  • 旋转:通过鼠标右键拖动。

商业与联系信息

Orbify AS 目前正在寻求以下方面的合作机会:

  • 试点项目、技术协作、行业合作伙伴关系以及投资洽谈。

联系方式:

9. Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache (blog.cloudflare.com)

Cloudflare DNS 缓存优化总结:节省 100 TB 内存

Cloudflare 通过对其 Big Pineapple 平台(支撑 1.1.1.1 等 DNS 服务)的 DNS 缓存进行五项连续的内存优化,成功将单个缓存条目的内存占用减少了 50% 以上。在大规模部署中,这为整个集群节省了约 100 TB 的内存,并显著提升了性能。

核心优化措施

1. 替换 Vec<T> 和 String

由于 DNS 缓存条目在存储后不再修改,原本用于支持动态增长的 Vec<T> 和 String 中的 capacity(容量)字段变得冗余。

  • 改进: 使用 Box<[T]> 和 Box<str> 代替。
  • 效果: 每个条目节省了 64 字节的字段开销,并消除了由于预留空间导致的堆内存浪费。

2. 减少列表与指针数量

原本将 DNS 响应分为“回答”、“权威”和“附加”三个独立的列表存储,每个列表都需要 8 字节的指针和 8 字节的长度。

  • 改进: 将所有记录存储在单个列表中,并使用两个 2 字节的 u16 偏移量来标识不同部分的起始位置。
  • 效果: 每个条目节省了 28 字节。

3. 移除冗余的所有者(Owner)信息

许多 DNS 记录的所有者域名与查询域名完全相同(例如 example.com A 返回的记录所有者也是 example.com)。

  • 改进: 仅在记录所有者与查询域名不同时(如 CNAME 场景)才存储完整的域名;否则,在读取时通过缓存键(Cache Key)直接推断。
  • 效果: 大多数记录不再需要为所有者字段进行堆分配。

4. 解决 Rust Enum 的内存占用问题

在 Rust 中,枚举(Enum)的大小取决于其最大变体。由于 NAPTR 变体非常大(136 字节),导致即使是仅需 4 字节的 A 记录也会占用 144 字节。

  • 改进思路转变: 最初尝试通过“装箱(Boxing)”大变体来减小枚举体积,但发现这会增加分配器开销并破坏内存局部性(导致 CPU 缓存命中率下降)。
  • 最终方案(存储为字节格式): 放弃解析后的枚举列表,转而将所有记录数据存储在一个连续的 Box<[u8]> 字节缓冲区中。每个记录由一个 2 字节的长度前缀和原始字节组成。

5. 采用紧凑的字节缓冲区存储

  • 优势:
    • 消除了枚举带来的对齐填充(Padding)和变体开销。
    • 将多个记录的分配合并为一个单一的堆分配,提高了内存局部性。
    • 性能加速: 对于大多数常见记录类型(A, AAAA, TXT 等),可以直接将缓冲区中的字节拷贝到输出消息中,无需重新序列化,显著降低了查询延迟。

优化结果

通过这些改进,Cloudflare 在生产环境中实现了内存占用与性能的双重提升:

指标 优化前 优化后 变化
单个条目净占用 953 字节 420 字节 -56%
单个条目分配量 1.1 KB 461 字节 -58%
缓存插入吞吐量 625,000 entries/s 893,000 entries/s +43%
缓存查询延迟 828 ns 670 ns -19%

总结: 此次优化不仅释放了相当于 130 台 Gen 13 服务器的内存资源,还通过减少内存分配和提升内存局部性,实现了更高的吞吐量和更低的查询延迟。

11. Gemini-3.5-Transcribe (blog.google)

Gemini 3.5 Transcribe 产品概述

Google 推出了 Gemini 3.5 Transcribe,这是一款专为智能语音交互设计的最新语音转文本(Speech-to-Text)模型。与传统模型不同,该模型能够直接将原始音频转换为准确、精简且经过格式化处理的文本,能够有效处理背景噪音、专业术语以及语言中的不流利现象(如“嗯”、“啊”等填充词)。

核心功能与技术优势

  • 智能转录:能够无缝处理自我纠正(例如:“周二——不对,是周三”),自动去除填充词,并自动对文本进行格式化。
  • 高精度与低延迟:根据 Artificial Analysis 的数据,该模型在流式传输场景下的平均字错误率(WER)为 4.0%,在非流式场景下为 2.6%。相比前代模型 Chirp 3,其最终转录时间缩短了 70%。
  • 自定义词汇与多语言支持:支持识别专业术语和特定拼写;能够自动检测并转录超过 85 种语言,并处理不同的地区口音和方言。
  • 多发言人识别:在处理预录音频时,能够准确识别多达三位发言人并提供时间戳(3 位以上发言人的支持目前处于实验阶段)。
  • 函数调用(Function Calling):模型可以将复杂任务(如图像生成或文件分析)委托给其他 Gemini 模型执行。

开发者 API 支持

Gemini 3.5 Transcribe 通过两种不同的 API 接入开发者工作流:

  1. 实时流式 API (Live API):使用模型 gemini-3.5-transcribe-live,提供亚秒级延迟的双向实时流式传输,适用于交互式语音应用。
  2. 预录音频处理 API (Interactions API):使用模型 gemini-3.5-transcribe,适用于转录会议、通话记录等,支持发言人归属和单词级时间戳。

开发者可以通过 Google AI Studio 和 Gemini Enterprise Agent Platform 获取访问权限。

产品生态集成应用

Gemini 3.5 Transcribe 已或即将集成到 Google 的多项产品中,以实现更自然的语音交互:

  • Android (Gboard/Rambler):通过 Rambler 功能将口语转化为格式化文本,用户可以通过语音进行拼写纠正或更改写作风格。
  • macOS Gemini App:支持结合屏幕上下文的语音指令,实现总结本地文件、跨应用处理文本或直接生成图像等复杂工作流。
  • Google AI Studio & Antigravity:支持通过语音进行应用开发(Vibe coding),并结合屏幕上下文和聊天历史确保转录的精准度。
  • Chrome (即将推出):用户可以在网页的任何输入框中使用语音进行输入,简化回复草拟或提示词输入的过程。
13. Hilariously fast volume computation with the divergence theorem (2018) (alyssarosenzweig.ca)

基于散度定理的高效 3D 网格体积计算算法

本文介绍了一种利用散度定理(Divergence Theorem)快速计算简单、封闭且由三角形构成的 3D 网格体积的算法。

数学推导

体积 $V$ 的定义为区域 $R$ 上常数 1 的三重积分: $$V = \iiint_R 1 dV$$

通过选取向量场 $\mathbf{F}(x, y, z) = \langle x, 0, 0 \rangle$,由于其散度 $\text{div} \mathbf{F} = 1$,根据散度定理,体积可以转化为表面积分: $$V = \iint_S \mathbf{F} \cdot d\mathbf{S}$$

对于由三角形 $T_i$ 组成的网格表面 $S$,该积分等于每个三角形面片积分之和。通过对三角形进行参数化,并利用 $\mathbf{F}$ 仅包含 $x$ 分量的特性,表面积分可以简化。由于 $\mathbf{F}$ 的 $y$ 和 $z$ 分量为零,计算过程中仅需提取叉积 $\Delta_{i1} \times \Delta_{i2}$ 的 $x$ 分量。

通过对三角形面内的 $x$ 坐标进行积分 $\iint_{T_i} x dA$,可以得出最终的紧凑公式: $$V = \frac{1}{6} \sum_{i=0} (\Delta_{i1} \times \Delta_{i2})x (T{i0x} + T_{i1x} + T_{i2x})$$ 其中:

  • $\Delta_{i1}$ 和 $\Delta_{i2}$ 是三角形两个边的向量差。
  • $T_{ix}$ 是三角形三个顶点在 $x$ 轴上的坐标。

性能分析

该算法具有极高的计算效率,其优势体现在以下几个方面:

  • 复杂度:算法的时间复杂度为 $O(n)$,其中 $n$ 是三角形的数量。
  • 计算开销:算法不涉及任何数值积分或微分运算。在遍历三角形的循环内部,每个三角形仅需 7 次加法和 3 次乘法。整个算法的总计算量约为 $11n$ 次浮点运算(具体为 $8n-1$ 次加法和 $3n+1$ 次乘法)。
  • 对比优势:常见的体积计算方法(如通过渲染网格并进行采样)计算成本极高,而本算法仅需单次循环即可完成。
  • 实际表现:以性能较低的硬件(如 Raspberry Pi)为例,在 60 FPS 的应用环境下,该算法每帧可处理约 3000 万个三角形。
14. EPA says power for data centers can sidestep pollution laws (www.epa.gov)

美国环保署(EPA)发布新指南:离网发电设施可豁免酸雨计划污染监管

美国环境保护署(EPA)于2026年7月发布了一项指导意见,明确了《清洁空气法》(CAA)中的“酸雨计划”(ARP)不适用于未连接到公共电网的“离网”(islanded)发电设施。

核心内容与影响

  • 政策豁免: 该指南澄清,由于“离网”发电设施既不向公众售电,也不需要向美国能源部(DOE)履行发电单元的报告义务,因此它们不属于酸雨计划的监管范围。
  • 支持数据中心建设: 这一政策为数据中心开发商提供了更大的灵活性,使其能够更快速、更自主地建设和运营电力设施,同时有助于减轻社区公共电网的负担。
  • 维护AI领先地位: EPA 空气与辐射助理管理员 Aaron Szabo 表示,此举旨在确保美国在人工智能领域的领先地位,同时保护社区免受公用事业价格上涨的影响。

政治与经济背景

该指南进一步落实了特朗普总统的“纳税人保护承诺”(Ratepayer Protection Pledge)。根据该承诺,签署企业需承诺自行筹措并支付其设施所需的全部能源及配套基础设施成本。此举旨在通过约束电力公司、开发商及监管州,防止企业成本转嫁给普通家庭,从而避免电费上涨。

风险提示

EPA 特别指出,虽然目前的离网设施可以豁免监管,但如果一家公司在未来将这些设施接入公共电网,该设施届时可能必须遵守酸雨计划的相关规定。

15. Just the rumour of a bug is enough to find an exploit these days (anil.recoil.org)

摘要:AI 代理时代下的开源安全挑战与应对

本文通过 OCaml 的 cohttp 库最近发生的一个路径遍历漏洞(OSEC-2026-16)案例,探讨了在 AI 代理(Agentic systems)时代,开源软件安全面临的严峻挑战。

核心问题:从“漏洞传闻”到“自动化攻击”的极速转化

作者指出,传统的安全处理流程(即在私下修复漏洞、通知用户后再公开公告)正在失效。在 cohttp 的案例中,仅仅在 GitHub 上公开修复漏洞的 Pull Request(PR)仅十分钟后,作者的服务器就遭到了针对该漏洞特征的探测。

主要威胁点包括:

  • AI 代理的极速利用能力: 现代 AI 代理(如 DeepSeek V4 Pro)只需获得关于漏洞类型的模糊方向,就能在极短时间内(甚至不到一分钟)独立发现相关问题并生成攻击载荷。
  • 安全禁运(Embargoes)失效: 过去通过保密来保护用户的方法已不再稳妥,因为 AI 能够从公开代码库的微小变化中迅速推断出漏洞细节。
  • 利用时间提前: 数据显示,漏洞的平均利用时间(Mean time to exploit)已趋于负值,这意味着攻击往往发生在补丁发布之前。
  • “缺陷经济学”(Bugonomics)失衡: 攻击者利用 AI 大规模生成漏洞利用程序,而维护者的修复、验证和发布能力受限于人力和复杂的回归测试,导致防御方的“修复吞吐量”远低于攻击方的“利用吞吐量”。

开源维护者的困境

开源维护者在防御 AI 攻击时处于劣势:

  1. 工具不对等: 顶尖的 AI 模型(如 Claude 或 GPT 系列)通常设有安全护栏,限制了开发者利用它们进行安全研究,而攻击者却能轻易使用这些工具。
  2. 分发难度大: 与 Google Chrome 等拥有自主控制权的商业软件不同,开源库(如 OCaml 或 Docker)通常被嵌入到各种下游产品中,维护者很难直接控制终端用户的更新节奏。

应对策略建议

为了应对这一现状,作者提出了三个维度的应对思路:

1. 极高私密性的补丁开发

由于目前的 GitHub 私有 Fork 功能在 CI 集成和多仓库协作方面存在局限,开源社区需要更健壮的讨论基础设施和“信任网络”(Web-of-trust),以确保漏洞细节仅在受信任的维护者之间传递,避免信息泄露。

2. 持续交付与快速发布机制

效仿大型商业项目(如 Chrome)的快速更新模式,通过以下手段提升防御速度:

  • 跨生态系统的包管理: 更好地追踪库在下游产品中的嵌入位置。
  • 自动化扫描与分拣: 利用工具(如 Scrutineer)辅助维护者快速识别漏洞。
  • 鲁棒的质量控制: 在多种平台和架构上建立无需人工干预的自动化 CI 环境,支持快速推送补丁。

3. 协议层的预防性保护(虚拟补丁)

在软件补丁尚未完全分发到终端之前,通过网络基础设施层(如 CDN 或网关)实施“虚拟补丁”。例如,针对路径遍历漏洞,可以在协议层直接实施 URL 规范化规则,从而在几秒钟内实现全局性的防御。

结论

面对 AI 驱动的自动化攻击浪潮,开源社区不能仅依赖传统的修补流程,而需要结合私密开发、持续发布以及协议层主动防护的多重手段,以重塑互联网的免疫系统。

16. The Twelve-Factor App (2025) (12factor.net)

十二要素应用方法论 (The Twelve-Factor App) 概述

“十二要素应用方法论”是一套用于构建软件即服务(SaaS)应用的开发标准。该方法论旨在通过规范化的开发实践,提升应用的自动化程度、可移植性、云原生适配性、部署敏捷性以及扩展能力。

核心目标

该方法论致力于实现以下目标:

  • 自动化设置:使用声明式格式进行设置自动化,以降低新开发者的参与成本。
  • 高可移植性:与底层操作系统保持简洁的契约,确保应用能在不同执行环境中无缝迁移。
  • 云平台适配:适用于现代云平台,无需复杂的服务器维护和系统管理。
  • 持续部署:最大限度地减少开发与生产环境之间的差异,实现敏捷的持续部署。
  • 易于扩展:在不改变工具、架构或开发实践的情况下,实现应用的水平扩展。

背景与适用性

该方法论总结了 Heroku 在开发和运维成千上万个应用过程中的经验,旨在为现代应用开发中的系统性问题提供统一的术语和概念解决方案。它具有极高的通用性,适用于任何编程语言以及任何后端服务组合(如数据库、消息队列、内存缓存等)。其主要受众为开发人员及运维工程师。

十二要素核心内容

  1. 代码库 (Codebase):一个应用对应一个由版本控制系统管理的代码库,但可以进行多次部署。
  2. 依赖 (Dependencies):显式地声明并隔离应用的所有依赖项。
  3. 配置 (Config):将应用配置存储在环境变量中。
  4. 后端服务 (Backing services):将后端服务(如数据库、缓存等)视为附加资源。
  5. 构建、发布、运行 (Build, release, run):严格分离构建、发布和运行这三个阶段。
  6. 进程 (Processes):将应用作为一组无状态进程执行。
  7. 端口绑定 (Port binding):通过端口绑定来导出服务。
  8. 并发 (Concurrency):通过进程模型实现应用的水平扩展。
  9. 适时丢弃 (Disposability):通过快速启动和优雅关闭来增强系统的鲁棒性。
  10. 开发与生产一致性 (Dev/prod parity):尽可能保持开发、测试和生产环境的高度相似。
  11. 日志 (Logs):将日志视为连续的事件流。
  12. 管理进程 (Admin processes):将管理或维护任务作为一次性进程运行。
17. Show HN: We built open OpenRouter that turns usage into a better model (github.com)

Experiential 项目概述

Experiential 是一个专为智能体(Agent)工作流设计的开源网关和路由系统。其核心目标是通过统一的接口管理多种模型,并利用生产环境的实际流量来优化模型的质量、速度和成本。

核心功能

  1. 统一模型接入:通过兼容 OpenAI 的 API,用户可以同时调用托管模型、自带密钥(BYOK)模型以及本地运行的模型。
  2. 精细化权限与预算控制:支持针对不同的用户或智能体设置访问权限,限制其可使用的模型、应用场景及消费预算。
  3. 流量驱动的优化:能够将生产环境的实际流量转化为自定义路由或优化后的模型,从而在质量、响应速度和成本之间取得平衡。

使用方式

1. 本地部署

用户可以通过 Python 环境快速启动本地网关:

  • 安装:pip install experiential
  • 启动:运行 exp 命令,通过设置向导完成供应商选择、身份配置及预算设置,并获取访问密钥。

2. 托管服务

对于希望避免自行维护网关的用户,可以使用 Experiential 提供的托管平台(platform.experientiallabs.ai)。该平台提供兼容 OpenAI 和 Anthropic Messages 的 API,用户可以上传现有的 LLM 追踪数据(Telemetry)并连接自己的推理供应商密钥(如 OpenAI, Anthropic, Gemini, Azure 等)。

3. 编程集成

开发者可以使用官方提供的 Python SDK 轻松调用构建好的项目路由:

import exp

with exp.load_router("my-project") as client:
    response = client.chat.completions.create(
        model="my-project",
        messages=[{"role": "user", "content": "hello"}],
    )

优化工作流

Experiential 提供了一套从数据采集到模型微调的闭环优化流程:

  1. 收集追踪数据:通过 OpenTelemetry (OTLP) 收集智能体运行时的追踪信息。
  2. 构建路由 (Build):使用 exp build 命令,根据收集到的追踪数据模拟并构建一个针对特定任务优化的项目路由。
  3. 模型优化 (Optimize):使用 exp optimize 命令,结合 Tinker 等工具,利用采集到的数据对用户拥有的开源模型进行微调,使其在特定任务上表现更佳。

数据隐私与遥测

系统默认开启匿名的 PostHog 产品遥测,用于改进产品。该遥测过程不会包含提示词(Prompts)、追踪轨迹、操作路径、模型名称、凭据或任何原始客户内容。用户可以通过 exp config telemetry 命令自行开启或关闭该功能。

18. Please stop flooding our projects with AI slop to furnish your CV (neilalexander.dev)

开源项目警惕:停止利用 AI 生成“垃圾内容”来美化简历

背景:GitHub 贡献作为职业“货币”

在软件开发领域,GitHub 的贡献记录(如头像显示、活动动态、贡献热力图等)已成为开发者的一种“货币”。招聘人员和猎头经常通过这些指标来筛选和评估候选人的技术能力与活跃度。因此,许多开发者致力于优化这些信号,以提升自己的求职竞争力。

现状:AI 生成内容的激增

开源项目的维护者观察到,近一年来外部贡献的模式发生了显著变化。目前,维护者收到的 Pull Request (PR) 和 Issue 中,带有 AI 生成痕迹的情况日益增多。特别是在安全漏洞报告方面,大量报告不仅由 AI 分析,甚至还附带了 AI 生成的修复建议。

动机:利用 AI 操纵 GitHub 指标

文章指出,许多此类贡献并非出于对项目的真实兴趣,而是为了“刷数据”。开发者可以利用大语言模型(LLM,如 Claude)来自动化整个流程:

  1. 让 AI 寻找感兴趣的开源项目。
  2. 让 AI 找出项目中的问题。
  3. 让 AI 生成修复方案并提交 PR。

这种行为旨在通过 AI 的力量,在 GitHub 个人主页上制造出一种“积极参与开源”或“具备解决问题能力”的假象,从而在不投入实际精力的情况下,人为地夸大个人的技术能力。

负面影响与维护者的应对

这种趋势给开源维护者带来了多重困扰:

  • 低价值的“琐事”消耗精力:文章举例提到,有贡献者在长期无活跃记录后,突然利用 AI 提交了多个仅针对注释中拼写和语法错误的修复 PR。虽然这些修改本身无害,但由于其缺乏实质意义且完全由 AI 代劳,维护者认为这属于浪费时间的“琐事”。为了避免设立“接受低价值贡献”的先例,并防止贡献者名单沦为“机器人修复错别字的奖励清单”,维护者选择直接关闭此类 PR。
  • 安全漏洞报告的质量下降:大量 AI 生成的安全漏洞报告增加了维护者的评估负担。由于提交这些报告的人可能并非出于修复漏洞的初衷,而是为了获取 CVE(通用漏洞披露)的署名权,维护者不得不更加严苛地筛选报告的严重性,以应对协调修复和披露所带来的巨大工作量。

核心观点:开源建立在信任之上

文章强调,开源项目的核心价值在于信任和实质性的改进。衡量一个贡献者的标准不应是其利用 AI 产出了多少 PR 或积累了多少 CVE,而在于其是否真正让项目变得更好。对于那些仅仅为了追求 GitHub 的“绿格子”或贡献者勋章而利用 AI 批量生产内容的人,文章呼吁他们寻找其他途径,不要占用开源社区的资源。

19. Migrating to HTTPX2 (github.com)

OpenAI Python SDK 迁移至 HTTPX2 指南摘要

OpenAI Python SDK 的同步和异步 HTTP 客户端现已从 httpx 迁移至 HTTPX2。HTTPX2 会随 openai 库自动安装,而原有的 httpx 不再作为传递依赖安装。

核心变化

1. 默认客户端的使用

如果开发者在使用 OpenAI 或 AsyncOpenAI 时没有提供自定义的 http_client,现有的 API 调用、响应模型解析、流式 API、身份验证、重试机制以及数值型超时设置将保持原样,无需额外操作。

  • 注意:如果应用代码中直接导入了 httpx,由于 SDK 不再自动安装它,开发者需要手动添加 httpx 依赖或将其迁移至 httpx2。

2. TLS 证书与信任库(重要变更)

这是本次迁移中影响最大的变化:

  • 验证机制变更:HTTPX2 不再使用 certifi 提供的 CA 束,而是改用操作系统自身的信任库。
  • 潜在风险:在缺少系统 CA 证书的精简版容器镜像、使用企业 TLS 检测代理的环境或依赖自定义 certifi 束的部署中,可能会导致证书验证失败。
  • 解决方案:
    • 配置环境变量 SSL_CERT_FILE 或 SSL_CERT_DIR。
    • 通过 DefaultHttpx2Client(verify=ssl_context) 传入自定义的 ssl.SSLContext。

3. 自定义 HTTP 客户端

开发者应转向使用 HTTPX2 的客户端和配置对象。SDK 提供了辅助类以保留推荐的超时、连接池和重定向默认设置:

  • 推荐使用:DefaultHttpx2Client 和 DefaultAsyncHttpx2Client(原 DefaultHttpxClient 系列名称仍可用,但建议使用带 2 的新名称以明确表示使用 HTTPX2)。
  • 对象替换对照表:
原 HTTPX 对象 对应 HTTPX2 对象
httpx.Client httpx2.Client
httpx.AsyncClient httpx2.AsyncClient
httpx.Timeout httpx2.Timeout
httpx.URL httpx2.URL
httpx.Limits httpx2.Limits
httpx.HTTPTransport httpx2.HTTPTransport
httpx.AsyncHTTPTransport httpx2.AsyncHTTPTransport
httpx.MockTransport httpx2.MockTransport

4. 认证、钩子与响应

  • 认证与事件钩子:自定义身份验证类和事件钩子(event hooks)接收的对象需更新为 httpx2.Request 和 httpx2.Response。
  • 原始响应:在使用原生客户端时,通过 with_raw_response 获取的响应对象将是 httpx2.Response 类型。
  • 异常处理:应用应继续捕获 SDK 级别的异常(如 openai.APITimeoutError),但在使用原生客户端时,底层传输层异常将变为 HTTPX2 异常。

5. aiohttp 与测试

  • aiohttp:通过 pip install 'openai[aiohttp]' 安装的扩展现在使用原生的 HTTPX2 传输层,不再依赖外部的 httpx-aiohttp 适配器。
  • 请求 Mock:测试工具(如 Mock 拦截器)必须能够拦截 HTTPX2 的请求并返回 HTTPX2 的响应。

临时过渡方案:兼容旧版 HTTPX

如果应用由于依赖旧版传输层、集成工具或 Mock 库而无法立即迁移,可以采用“逃生舱”方案:

  1. 手动安装 httpx。
  2. 使用 typing.cast(Any, httpx.Client()) 将旧版客户端注入 SDK。
  • 警告:此方案仅限运行时使用,会破坏静态类型检查(如 mypy/Pyright)。这仅作为迁移期间的临时手段,未来可能会被废弃。
20. Show HN: OpenTIE and OpenXWA, Modern Ports of Tie Fighter and X-Wing Alliance (github.com)

OpenTIE 与 OpenXWA 项目概述

OpenTIE 是《星球大战:TIE Fighter》的开源重新实现版,旨在让玩家能够在现代操作系统(Windows、macOS 和 Linux)上原生运行该游戏。

核心功能与特性

OpenTIE 的一大特色是能够整合 1995 年 Collector's CD-ROM 版与 1998 年 Windows 版的优势。用户可以根据需求独立选择不同版本的元素,官方推荐的组合配置如下:

  • 1995 版元素: 菜单、过场动画以及自适应的 iMUSE 音乐。
  • 1998 版元素: 飞行模拟系统和 3D 资产。

⚠️ 重要提示: OpenTIE 不包含任何原始游戏内容。用户必须拥有至少一个版本的合法完整安装(例如通过 GOG 或 Steam 获取)才能运行。

关键增强功能

  • 自适应音乐 (iMUSE): 重新实现了 1995 版的 iMUSE 系统,使音乐能随任务事件无缝切换。支持 Roland SC-55 硬件仿真(需用户提供兼容 ROM)、内置的 OPL3 FM 合成器仿真以及通过 FluidSynth 使用自定义 SoundFont。
  • 图形表现: 提供两种模式,玩家可通过 TAB 键实时切换:
    • 经典模式: 保留原始的游戏视觉效果。
    • 现代模式: 提供高分辨率渲染、先进的光照效果(阴影、环境光遮蔽、泛光)、运动模糊、MSAA、AMD FidelityFX FSR 3.1.4 超分辨率技术以及 HDR 输出。
  • 飞行体验优化: 飞行模拟更新频率最高可达 240 Hz,以匹配现代高刷新率显示器,提供更平滑的动作和更灵敏的控制。同时支持现代游戏手柄和飞行操纵杆。

技术规格与支持平台

平台 目标架构 图形后端
Windows x86-64 Direct3D 12 或 Vulkan
macOS macOS 13+ (arm64 或 x86-64) Metal
Linux x86-64 (glibc 2.35+) Vulkan

相关项目

OpenXWA 是由同一团队开发的另一个开源项目,旨在为《星球大战:X-Wing Alliance》提供类似的现代移植支持,同样支持 Windows、macOS 和 Linux。


注:OpenTIE 目前仍处于活跃开发阶段,可能存在 Bug 或与原版行为不一致的情况。

21. Gemini Omni 1.1 Flash (blog.google)

Gemini Omni 1.1 Flash 功能概述

Google DeepMind 推出了 Gemini Omni 1.1 Flash,这是一套全新的创意控制和生成式视频功能,旨在通过 Gemini API 为开发者提供专业级的视频制作能力。该版本通过提升可控性、迭代速度和画面质量,使其能够支持生成式视频工作流、创意工具及媒体编辑软件的专业化部署。

主要功能特性

1. 场景扩展 (Scene Extension)

该功能允许用户基于现有视频无缝生成后续镜头。

  • 上下文增强:模型现在可以分析多达 10 秒的前置视频上下文(此前仅能参考最后 1 秒),显著提升了视觉连贯性和叙事的一致性。
  • 扩展规格:支持以 10 秒为增量进行扩展,累计总长度最高可达 40 秒。

2. 首尾帧指定 (First and Last Frame Specification)

用户可以通过指定镜头的起始帧和结束帧,实现高度可控的视频生成。

  • 应用场景:适用于复杂的相机轨道运动(Camera Orbits)、缩放转场(Zoom Transitions)或无缝循环剪辑(Looping Clips)。

3. 高效 360p 草稿模式 (360p Drafting)

为了加速原型设计和分镜迭代,Omni 1.1 提供了轻量级的 360p 分辨率选项。

  • 性能优势:生成速度比标准的 720p 分辨率快高达 60%,且成本仅为后者的三分之一。

4. 4K 超分辨率输出 (4K Upscaling)

支持生成 1080p 或 4K 分辨率的高清视频,能够满足专业制作级别的画质需求。

5. 多模态视频参考 (Video References)

开发者可以在创作场景时,在多模态输入中引用长达 3 秒的视频作为参考。

  • 核心价值:通过视频参考,用户可以更好地保持视觉上下文的一致性以及角色特征的稳定性。

获取与使用途径

  • 开发者平台:
    • Google AI Studio:可直接进行功能测试。
    • Gemini Enterprise Agent Platform:企业用户可通过 Agent Platform API 进行集成开发。
    • 技术文档:官方提供 API 文档、Cookbook 以及提示词指南(Prompting Guides)。
  • 个人订阅用户:
    • Google Flow:所有 Google AI Plus、Pro 和 Ultra 订阅者均可使用。
    • Gemini App:所有 Google AI Plus、Pro 和 Ultra 订阅者均可使用“场景扩展”功能。
22. I used AWS cognito for a startup. I wouldn't do it again (joshkaramuth.com)

AWS Cognito 使用经验总结与教训

本文作者分享了在创业过程中使用 AWS Cognito 作为身份验证解决方案的负面经历。尽管 Cognito 拥有 AWS 生态集成优势和较高的免费额度,但作者认为其在开发体验(DX)方面的缺陷导致了巨大的工程成本。

主要问题汇总

1. 文档质量与混乱

  • 受众模糊:文档试图同时服务于企业架构师、前端开发者和移动端开发者,导致内容缺乏针对性且逻辑不连贯。
  • 版本不一致:代码示例极其混乱,混杂了旧版 JavaScript SDK、Amplify v1 API 以及原始 AWS SDK,开发者难以判断应使用哪个版本。

2. 破坏性的版本更新

  • API 重构:以 Amplify 从 v5 升级到 v6 为例,更新并非简单的重构,而是底层的重新架构。这导致开发者必须重写整个身份验证逻辑,而非仅仅进行代码优化,造成了大量重复劳动。

3. 本地开发困难

  • 强依赖云端:由于 Cognito 是云端服务,开发者难以在本地环境进行完全脱机测试。
  • 模拟工具不精准:虽然存在社区提供的本地模拟器(如 serverless-offline),但其与真实 AWS 环境的差异会导致“本地测试通过,线上环境报错”的问题,增加了调试难度。

4. 自定义程度极低

  • UI 定制受限:Cognito 提供的托管 UI(Hosted UI)仅支持极基础的品牌化修改(如更换 Logo),难以满足现代应用的审美和交互需求。
  • 矛盾点:若要实现深度自定义,开发者必须放弃托管 UI 转而使用 SDK 自行构建,这使得托管 UI 的初衷失去了意义。

5. 配置的不可更改性

  • 属性配置陷阱:用户池(User Pool)的属性配置(如将 Email 设为标准属性还是自定义属性)一旦设定便无法更改。
  • 高昂的纠错成本:若初始配置出现错误,开发者无法通过修改设置来修复,只能选择删除整个用户池并重建,或者编写复杂的脚本进行用户迁移,这在生产环境下风险极高。

核心教训

  • 开发者体验优先:在选择工具时,不应仅因为“集成在现有生态中”或“价格便宜”而妥协。开发者在处理文档错误、应对破坏性更新和解决配置问题上花费的时间成本,往往远超付费身份验证服务的费用。
  • 原型测试建议:在决定使用 Cognito 之前,应先进行一个包含自定义属性、邮箱验证和密码重置等复杂流程的小型概念验证(PoC),以评估其真实的开发难度和文档完整度。
24. Sovereign Tech Agency invests €500k in Flatpak (modal.cx)

德国主权技术机构投资 50 万欧元用于 Flatpak 开发

项目概述

德国**主权技术机构(Sovereign Tech Agency, STA)**通过其主权技术基金(STF)计划,向 Flatpak 的开发与管理投资 508,640 欧元。该项目为期两年,由 Modal 共同组织,并由 Para-Real Ltd. 提供支持。

Flatpak 是 Fedora Silverblue、openSUSE Aeon、SteamOS 和 GNOME OS 等基于镜像操作系统的核心应用分发方式,也是 GNOME、KDE 和 elementary 等主要桌面生态系统的首选格式。此次投资旨在通过增强 Flatpak 的功能,提升自由软件桌面生态系统的安全性、稳健性以及用户与开发者的体验。

核心目标与背景

尽管 Flatpak 是目前 GNU/Linux 上最成熟的应用分发方案,但在安全沙箱(Sandboxing)功能上仍落后于 Android 和 iOS 等商业平台。目前存在一些技术局限性,例如无法将音频输出与麦克风访问权限分离,且在网络和 VPN 方面缺乏专门的“门户”(Portals)。此外,由于此类平台级工作需要高度专业化的知识,且现有维护者精力有限,导致开发进度在近年来有所放缓。

技术路线图

此次投资将重点修复沙箱安全漏洞、引入长期需求的基础设施并确保日常维护。

1. 新增门户 (New Portals)

  • 音频 (Audio):实现针对 PipeWire 的静态套接字权限,通过 WirePlumber 策略管理设备访问,并开发音频权限门户(例如:允许使用扬声器但不授予麦克风权限)。
  • 网络 (Network):通过新的静态权限实现网络与宿主机的隔离(区分主机、本地网络、互联网及特定端口),防止不必要的设备暴露。
  • VPN:参考 Android 和 iOS 的 API 开发新门户,允许第三方 VPN 应用管理系统级连接。
  • 写作辅助 (Writing Assistance):开发拼写检查门户,允许沙箱内的应用共享系统词典,并支持通过门户提供语法纠错等高级编辑建议。
  • 密码自动填充 (Password Auto-Fill):研究并设计安全的密码自动填充门户,以取代目前不安全的 NativeMessaging 方法。

2. 基础设施与维护

  • 权限声明 (Entitlements):建立一套新系统用于声明特定门户的静态权限,便于应用商店审核人员验证功能,并支持引入第三方辅助工具。
  • 意图系统 (Intents):开发抽象系统,允许应用声明其提供的服务,从而实现深度链接(Deep-linking)或原生处理网页 URL。
  • 门户维护 (Portals Maintenance):将门户迁移至 libdex,增加集成测试,并优化系统权限对话框。

团队与执行

该项目由 Sebastian 和 Adrian 负责技术领导,Kateryna 和 Cade 负责组织支持。技术执行团队由多位资深承包商组成,包括来自 2023/2024 GNOME STF 项目的 Philip Withnall、Julian Sparber 和 Dhanuka Warusadura,以及 Zelda Ahmed、Ignacy Kuchciński、Hari Rana、Eva 和资深设计师 Sam Hewitt。

该项目预计将持续运行至 2027 年底,旨在通过扩大专业人才储备和建立更正式的项目结构,为 Flatpak 建设长期的社区能力。

25. Two German airport workers die of malaria after 'mosquito arrives on plane' (www.bbc.com)

法兰克福机场爆发疟疾疫情,导致两名员工死亡

德国法兰克福机场近期爆发了一起罕见的疟疾疫情,共导致6名男性员工感染,其中2名员工已不幸因病去世。

疫情概况与传播原因

  • 感染情况:疫情涉及6名在机场不同岗位工作的男性员工。该疫情最早于今年7月被检测到,当时已有4名员工染病。
  • 传播途径:德国公共卫生官员认为,携带疟原虫的蚊子是通过飞机抵达法兰克福机场,从而引发了此次爆发。
  • 疾病特性:疟疾由寄生虫引起,通过蚊子叮咬传播,不会在人与人之间直接传播。

应对措施与调查进展

  • 调查行动:法兰克福公共卫生部门正在对此次疫情进行调查。机场运营商 Fraport 已在机场安装了诱蚊陷阱,捕获的蚊子将被送往实验室进行分析,以确定其种类和来源。
  • 员工告知:Fraport 已向全体员工提供相关信息,并建议出现症状的人员及时就医。
  • 风险评估:官方表示,法兰克福当地民众面临的风险“非常非常低”。

医学背景与专家观点

  • 诊断挑战:德国联邦政府机构罗伯特·科赫研究所指出,由于感染者通常没有热带地区的旅行史,可能导致疟疾被误诊或延迟诊断,进而增加病情恶化的风险。
  • 罕见性:在德国,疟疾病例大多发生在从疟疾流行地区归来的长途旅行者身上,机场引发的疟疾传播非常罕见。
  • 历史记录:这是法兰克福机场自2023年以来再次出现的机场疟疾病例。
26. Doctors are finally learning to manage antidepressant withdrawal (www.newscientist.com)

医生正逐步学会管理抗抑郁药的撤药反应

现状与问题:SSRIs 的过度依赖与误诊

选择性血清素再摄取抑制剂(SSRIs)因其安全性高、副作用相对较轻,已成为治疗抑郁和焦虑的主流药物。在美国、英国和澳大利亚,服用比例均在 14% 至 16% 以上。然而,由于这些药物被视为“安全”,临床上对其长期使用的监测和停药指导严重不足。

目前存在的主要问题包括:

  • 长期使用的研究缺失:药物临床试验通常仅持续 8 周,但现实中许多患者的服药时间超过 5 年甚至 10 年,关于长期使用的副作用和撤药机制的研究尚不充分。
  • 撤药症状被误诊为“病情复发”:许多患者在尝试减药时会经历严重的撤药反应(如头晕、失眠、恐慌、甚至“脑电击感”等生理症状)。医生往往将这些症状误认为是原始抑郁症的复发,从而导致患者被建议增加剂量或无限期维持用药,形成了药物依赖的恶性循环。

潜在的长期健康风险

新兴研究表明,长期服用抗抑郁药可能带来除心理影响之外的其他健康风险:

  • 心脏风险:有研究发现,服用抗抑郁药至少 6 年的人群,发生心脏骤停等致死性心脏事件的风险增加了 74%。
  • 认知风险:在老年人群中,长期使用 SSRIs 可能与认知能力更快速的下降有关。部分研究甚至发现,服用此类药物的人脑部可能积累更多与阿尔茨海默病相关的 tau 蛋白缠结。

治疗范式的转变:更科学的管理与替代方案

面对这些挑战,精神医学界正朝着更谨慎、更多元的方向发展:

1. 更科学的减药策略

专家(如 Mark Horowitz)提倡一种更为缓慢且精准的递减方法:

  • 极慢速递减:减药过程应以患者能耐受的速度进行。如果出现撤药症状,应维持当前剂量直至症状缓解,甚至适度增加剂量。
  • 使用液体药物:为了实现更细微的剂量调整,建议使用液体形式的药物,而非传统的片剂,以便进行微量递减。

2. 临床指导的改进

  • 定期评估:新的临床建议要求医生至少每年对患者的用药必要性进行一次重新评估,以决定是否可以安全减药或停药。
  • 指南更新:英国、澳大利亚和美国的部分医疗机构已开始采纳更具指导性的减药临床手册和指南。

3. 推广非药物疗法

对于症状较轻的患者,医疗服务机构正越来越多地转向非药物的“一线治疗”方案,例如:

  • 谈话疗法(如认知行为疗法 CBT、正念、冥想)。
  • 运动疗法(研究表明其缓解抑郁的效果与药物相当,且无副作用)。

总结而言,这一转变并非要求全面摒弃抗抑郁药,而是旨在将 SSRIs 重新定位为多样化治疗方案中的一部分,通过更科学的减药管理和更广泛的替代手段,减少患者对药物的过度依赖并降低长期风险。

27. M5Stack Launches PaperMono (shop.m5stack.com)

M5Stack 发布 PaperMono E-Ink 开发终端

M5Stack 正式推出了 PaperMono,这是一款基于 ESP32-S3 的紧凑型电子墨水(E-Ink)开发终端。该设备专为低功耗信息显示、交互及物联网(IoT)连接项目设计,将显示、交互、电源与连接功能集成于一体。

核心功能与特性

  • 显示与交互:配备 3.97 英寸 4 级灰度 E-Ink 显示屏,提供类似纸张的视觉体验。屏幕支持触摸输入,并集成了前光功能,以便在低光环境下使用。此外,设备支持 CrossPoint Reader 固件,可提供灵活的阅读体验。
  • 连接性:标准版集成了 NFC 和 LoRa 技术,适用于数字徽章、身份显示、远程消息传递及传感器状态监控等需要近场识别或远距离低功耗通信的场景。
  • 硬件基础:搭载 ESP32-S3R8 芯片,支持 Wi-Fi 连接。设备内置 1150mAh 电池,并配备 microSD 存储、实时时钟 (RTC) 和惯性测量单元 (IMU),为开发者提供了完善的实验基础。

版本对比

PaperMono 提供两种版本以适应不同的开发需求:

特性 PaperMono (标准版) PaperMono-Lite (轻量版)
核心平台 ESP32-S3R8 ESP32-S3R8
显示屏 3.97 英寸触摸 E-Ink 3.97 英寸触摸 E-Ink
前光 支持 支持
NFC/LoRa 支持 不支持

PaperMono-Lite 专为仅需要核心 E-Ink 开发体验、无需特定无线连接功能的开发者设计。

应用场景

PaperMono 的设计涵盖了多种低功耗 IoT 应用领域,包括:

  • 迷你电子墨水阅读器
  • 低功耗 E-Ink 仪表盘
  • NFC 数字徽章
  • LoRa 远程状态显示器
  • 电子标牌、门禁终端及智能交通终端
28. Flock CEO gets his house blurred out on Google Maps and Zillow (twitter.com)

内容摘要

根据提供的内容,Flock 公司的首席执行官(CEO)已在 Google Maps 和 Zillow 平台上将其住所进行了模糊处理。由于原贴内容违反了 X(原 Twitter)平台的规则,正文部分无法显示。

29. Autistici/Inventati's main .org domain goes dark after US terrorism designation (mastodon.bida.im)

Autistici/Inventati 域名失效事件摘要

事件概述 由于被美国列为恐怖组织,Autistici/Inventati 的主要域名 autistici.org 已停止服务。

核心影响

  • 域名失效:主域名 autistici.org 目前处于无法访问状态。
  • 邮件服务中断:随之失效的还包括邮件服务器 mail.autistici.org,导致该组织的所有用户邮箱目前均无法使用。

后续计划 相关人员已通过 Mastodon 发布公告,表示将尽快发布关于如何重新登录及恢复邮件访问的详细说明。

30. Show HN: Voronoi Go (voronoigo.com)

Voronoi Go 概述

Voronoi Go 是一款基于 Web 浏览器的策略类视频游戏,它对传统的围棋玩法进行了创新性的重新设计。

核心特性

  • 去网格化机制:与传统围棋依赖固定棋盘格线不同,该游戏取消了网格限制,转而采用基于几何原理(Voronoi 图形概念)的动态机制。
  • 游戏玩法:玩家通过这种流动的、由几何驱动的方式进行博弈,通过占领领土来击败对手。
  • 游戏类型:策略游戏 (Strategy)。
  • 运行平台:Web 浏览器。

相关信息

31. Meta Paid $17B – Gets to Write Safety Rules for Other SocMedia Platform (www.techdirt.com)

Meta 与 52 个州达成儿童安全和解:以巨额赔偿换取行业监管话语权

事件概述

Meta 已与美国 52 个州及地方总检察长达成和解,旨在解决有关其平台儿童安全问题的诉讼。根据和解协议,Meta 将支付约 127 亿至 180 亿美元(具体金额取决于不同文件记录),并承诺对其平台实施一系列旨在提升青少年安全性的功能改进。

核心争议:监管捕获与行业标准

文章指出,该和解协议的核心风险在于**“监管捕获”(Regulatory Capture)**。尽管政府无法直接通过立法强制社交媒体实施特定的内容控制(这可能违反美国宪法第一修正案),但通过“和解”的形式,这些原本属于企业自主选择的行为在法律层面获得了类似“政府行为”的地位。

此外,Meta 被要求“鼓励”YouTube 和 TikTok 采用类似的安全性功能。协议结构甚至规定,如果 YouTube 和 TikTok 采纳了这些措施并支付相应款项,Meta 的赔偿金额也会相应增加。这意味着 Meta 正在通过此举确立一套有利于巨头的“行业标准”。

主要安全功能清单

Meta 将实施包括但不限于以下措施:

  • 时间管理:默认每日 2 小时使用时长限制(需家长许可方可关闭);包含“夜间模式”(午夜至凌晨 6 点禁用)和“学校模式”(白天静默通知)。
  • 算法与控制:允许青少年默认使用非算法推荐的信息流;默认关闭自动播放功能;隐藏点赞数。
  • 内容限制:禁止使用模拟整容效果的极端美妆滤镜;将青少年默认置于 13+ 内容设置中。
  • 年龄验证(Age Assurance):投入技术加强对未成年账号的识别,并推动应用商店提供经核实的年龄信息。
  • 家长控制:增强家长对青少年使用情况的监督与通知功能。

专家与机构的批评观点

包括电子前哨基金会(EFF)和 Fight for the Future 在内的组织对该协议表达了深切担忧:

  1. 隐私与监控风险:强制性的年龄验证要求收集更多用户个人信息,这不仅侵犯了隐私和匿名权,还增加了数据泄露和政府调取数据的风险。
  2. 侵犯言论自由:通过政府压力强制限制特定内容的过滤(如美容滤镜),可能构成对受宪法保护言论的非法干预。
  3. 扼杀创新与竞争:
    • 合规成本:协议中设定的标准(如对英语和西班牙语报告需在 6 小时内做出回应)对于拥有庞大团队的巨头来说可行,但对于资源有限的初创公司则是无法逾越的门槛。
    • 行业壁垒:这种“行业最佳实践”将使新进入者难以通过不同的创新模式生存,从而巩固 Meta 等巨头的市场地位。
  4. 效果存疑:协议要求的独立审计仅关注 Meta 是否“执行”了承诺的功能,而非这些功能是否真的“有效”保护了儿童。

总结

文章认为,这并非一次单纯的“巨头受罚”,而是一场复杂的利益交换:Meta 通过支付短期内可承受的赔偿金,换取了定义整个社交媒体行业规则的机会,从而构建了一个竞争对手难以跨越的“监管护城河”。

32. State of the Map 2026 (2026.stateofthemap.org)

State of the Map 2026 会议概览

State of the Map 是 OpenStreetMap (OSM) 制图师及用户的年度盛会。2026 年的会议将以混合模式举行,包括在法国巴黎举办的线下会议以及线上会议。

活动详情

  • 时间:2026 年 8 月 28 日至 30 日
  • 地点:法国巴黎,Champs-sur-Marne,Cité Descartes
  • 形式:为期三天的会议,内容涵盖演讲、研讨会、讨论环节等多种活动。

参会资源

会议为线下及线上参会者提供了丰富的资源链接,包括:

  • 行程与指南:包含会场交通指南、会议日程(提供移动端专用版本)以及社交活动信息。
  • 交流渠道:参会者可以通过 Matrix、Telegram 聊天室或 Mastodon 等社交媒体平台进行互动。
  • 内容展示:提供会议海报展示及直播链接。
  • 线上互动:持有“Venueless”门票的参会者可通过专用链接进入互动页面,进行观看直播、提问及参与分会场(break-out rooms)讨论。

合作伙伴

本次会议的合作伙伴包括:

  • IGN
  • Geodata Paris
  • Université Gustave Eiffel
  • École des Ponts ParisTech
  • Equinix

支持 OpenStreetMap

会议呼吁公众通过捐赠来支持 OpenStreetMap 项目,以帮助提升其系统的稳定性、质量和独立性。

33. We found a division by zero bug in FFmpeg with a vibecoded fuzzer (code.ffmpeg.org)

该内容并非关于 FFmpeg 漏洞的技术文章,而是一则关于网站防护机制 Anubis 的说明文档。其核心内容摘要如下:

Anubis 防护机制说明

  • 核心目的:为了应对 AI 公司大规模抓取网页导致服务器宕机及资源不可用的问题,管理员部署了名为 "Anubis" 的防护系统。
  • 工作原理:Anubis 采用了一种类似于 Hashcash 的**工作量证明(Proof-of-Work, PoW)**方案。该设计的初衷是:对于单个用户而言,由此产生的额外计算负载几乎可以忽略不计;但对于大规模抓取者,这种机制会显著增加其抓取成本,从而达到防范效果。
  • 技术演进方向:目前的 PoW 方案仅作为过渡手段。开发者的长期目标是开发更精准的无头浏览器(Headless Browsers)识别技术(例如通过字体渲染特征进行指纹识别),以便在不干扰合法用户的前提下实现精准拦截。
  • 用户注意事项:
    • Anubis 需要依赖现代 JavaScript 特性才能正常运行。
    • 使用了如 JShelter 等会禁用高级 JavaScript 功能的插件可能会导致无法通过验证。
34. Select * from Internet.blogposts (pfrazee.leaflet.pub)

社交媒体的“围墙花园”问题与 atproto 的解决方案

本文探讨了现代社交媒体平台走向“围墙花园”化的趋势,并介绍了通过 atproto 协议构建开放、互操作性社交网络的愿景与技术实现。

核心问题:围墙花园与 API 的封闭化

文章以 X(原 Twitter)向开源项目 Nitter 发出停止侵权函为例,指出社交媒体正在从开放的生态系统转向封闭的“围墙花园”。

  • 历史转变:早期的 Twitter API 非常开放,允许开发者构建各类工具;但随着开发者从资产变为负担,平台开始通过限制速率、设置付费层级、强制登录及技术封锁来收紧控制。
  • API 的局限性:传统的 API 无法满足现代应用的需求,其缺陷包括:
    • 预设菜单限制:API 只能回答开发者预设好的问题,无法进行复杂的自定义查询。
    • 效率低下:由于速率限制和数据分片,获取大规模数据需要耗费大量时间。
    • 无法跨平台关联:不同服务商的数据处于孤岛状态,无法进行交叉引用。
    • 索引困难:开发者无法通过受限的接口建立完整的全局索引,难以实现高效的搜索和推荐。

愿景:实现“从互联网中查询一切”

作者提出,理想的网络应当像数据库一样,允许用户执行类似 SELECT * FROM internet 的操作。这意味着我们需要实现:

  • 身份持久性:用户的身份和关系应独立于特定的应用程序而存在。
  • 可操作的数据导出:数据不应只是静态的存档,而应是“活的”(operable),能够让用户在不同服务间迁移并继续进行交互。
  • 共享数据库模型:不再是向中心化机构请求数据,而是通过共享数据逻辑来实现互操作。

atproto 的技术实现

atproto 旨在通过去中心化的方式解决上述问题,其核心架构逻辑如下:

  1. 个人数据服务器 (PDS):通过建立庞大的 PDS 网络,用户拥有自己的数据存储点,应用程序与这些服务器进行交互。
  2. 本地数据复制与聚合:为了处理复杂的查询需求,应用程序并不直接向 PDS 发送复杂的查询请求,而是通过复制并聚合数据到本地数据库来实现。
  3. 写入/摄取循环 (Write/Ingest Loop):
    • 写入 (Write):用户通过应用将记录发送至 PDS。
    • 摄取 (Ingest):PDS 将更改同步并复制到其他应用,应用通过监听事件(如 onPut)将新数据存入本地数据库。
    • 优化策略:应用可以使用“乐观更新”(Optimistic Updates)技术,在等待网络确认的同时先更新本地 UI,提升用户体验。

生态现状

目前 atproto 网络已展现出显著的规模和生命力:

  • 数据规模:拥有超过 4610 万个账户、245 亿条记录(包括数十亿条帖子和点赞),以及 5000 多个 PDS。
  • 活跃应用:Bluesky、Tangled、Leaflet 等应用已在运行。
  • 开发者工具:通过 jetstream 服务,开发者可以实时接入网络中的动态数据流(如关注、转发、发布等事件)。
35. Interactive Warhammer 40k Galaxy Map (cartographia40k.com)

互动式战锤40K银河系地图概述

该内容描述了一个名为“互动式战锤40K银河系地图”的交互工具。其核心功能如下:

  • 交互机制:用户可以通过在地图上选择不同的“制图记录”(cartographic record)来进行操作。
  • 主要功能:通过选择特定的记录,用户可以打开并查阅与之相关的详细“档案”(dossier)。
36. $900M paid out to end wind farm project going to firm run by Mar-a-Lago neighbor (www.independent.co.uk)

特朗普政府支付巨额补偿金终止风电项目,资金流向其邻居关联公司

据报道,特朗普政府已与德国能源公司 RWE 达成一项和解协议,将支付 12 亿美元以换取该公司放弃在纽约州、加利福尼亚州和路易斯安那州的海上风电租赁权。此举符合特朗普政府扩大化石燃料产业并限制风能项目的政策导向。

根据协议条款,RWE 必须将所得资金投资于“传统能源”领域。其中,RWE 计划将其中 9 亿美元用于购买路易斯安那州一个液化天然气(LNG)项目的股份。

争议焦点与利益关联

该 LNG 项目的股份将从 Stonespeak 公司购得,该公司由澳大利亚亿万富翁迈克尔·多雷尔(Michael Dorrell)领导。调查显示,多雷尔与特朗普之间存在密切联系:

  • 地理关系: 多雷尔在佛罗里达州海湖庄园(Mar-a-Lago)附近拥有房产。
  • 政治联系: 多雷尔曾向特朗普-万斯就职委员会捐款 100 万美元,并曾公开表示自己与特朗普的政治核心圈有密切社交往来。

各方回应

  • 白宫: 坚称所有操作均符合程序,否认存在利益冲突,并将此类报道描述为“旨在破坏公众对媒体信任的议程驱动型报道”。
  • 内政部: 发言人表示,内政部并未指示 RWE 选择特定的投资对象。
  • 民主党人: 部分民主党议员对该协议表示强烈不满,批评其为浪费纳税人资金的行为,并认为此事涉嫌腐败。
37. Previewing the Model Hardware Standard (www.anthropic.com)

Model Hardware Standard (MHS) 研究预览摘要

概述

Model Hardware Standard (MHS) 是由 Anthropic 与 HHMI Janelia 研究园区共同开发的一项共享规范,旨在让 AI Agent(智能体)能够安全地操作各类物理设备,如显微镜、液体处理设备和机械臂等。目前,MHS 已向首批科学研究实验室和先进制造商开放研究预览。

解决的核心问题

在传统环境中,实验室或制造设施的硬件集成通常需要数周甚至数月的时间,且不同设备之间往往无法直接通信,需要专家进行定制化开发。MHS 的目标是将这种集成工作缩短至数小时或数分钟,并允许 AI 驱动的工具实现全天候的自主实验和工作流,包括实时参数更新及硬件错误恢复。

技术原理与功能

MHS 通过引入标准化驱动程序来打破硬件孤岛:

  1. 标准化指令与发现机制:驱动程序使用简单的“读”(如获取温度)和“写”(如设置温度)等原语(Primitives)进行操作。设备以标准格式进行广播,使 Agent 能够跨网络发现并与之通信。
  2. 物理特性描述(标签系统):为了弥补 AI 对物理世界感知能力的不足,MHS 允许用户通过自然语言为设备添加标签(如机械臂的重量、安全限制等)。这些信息会被自动转化为参考文件,使 Agent 在面对从未见过的设备时,也能了解其操作特性与安全边界。
  3. 多维控制机制:Agent 通过 Model Context Protocol (MCP)、命令行界面 (CLI) 和代码文件 (APIs) 三种机制来控制硬件,从而实现跨设备的单行代码编排。
  4. 高层级任务编排:Agent 不仅能执行指令,还能监督工作进度。对于长时任务,Agent 可以将驱动命令链式组合成确定性的代码脚本,从而在无需每一步都进行实时推理的情况下高效运行。

应用案例

MHS 在多个前沿领域展示了其实际价值:

  • 生物技术:Genentech 使用其自动化蛋白质分析;华盛顿大学实验室利用其实现远程监控和无碰撞的机械臂协作;CMU 通过它将剂量反应实验的速度提升了三倍。
  • 量子计算:QuEra Computing 利用 MHS 让 Agent 控制激光系统,实现了 99.3% 的激光“锁定”自动恢复率。
  • 显微学与环境科学:HHMI Janelia 用它统一了多种供应商的显微镜设备;Tetsuwan Scientific 利用其通过 qPCR 工作流监测环境污染。

行业合作伙伴与安全性

多家行业巨头正在为 MHS 提供支持,包括 AWS(通过 Strands Robots 库)、Doosan Robotics、Tecan、Universal Robots、QIAGEN 等。

安全性与未来计划: 由于 AI 在空间和物理推理方面仍存在局限(例如可能无法区分物理故障与软件错误),MHS 目前处于研究预览阶段。Anthropic 正在利用此阶段开发物理安全路线图和安全评估标准,旨在为未来将 MHS 开源奠定基础,确保 AI 在操作物理世界时的安全与合规。

39. USDA recalls 30k pounds of Argentine beef sold in Texas and Florida (cbsaustin.com)

美国农业部召回销往德州和佛州的3万磅阿根廷牛肉

召回概况 美国农业部(USDA)宣布召回近30,000磅从阿根廷进口并销往德克萨斯州和佛罗里达州的生牛肉。此次召回的主要原因是进口过程中未能按规定进行复检。

风险等级与争议 尽管召回通知中并未提及任何具体的污染物,但USDA食品安全检验局(FSIS)已将此次召回定为“I级健康危害”(Class I health hazard),这是该机构设定的最高风险类别。

食品安全专家、教授Darin Detwiler对此表示质疑。他认为,如果仅仅是因错过边境复检而导致的“文书或官僚主义问题”,将其列为最高风险级别显得十分矛盾,这暗示问题的严重性可能超出了单纯的行政疏忽。

政治背景与各方反应 此次召回正值特朗普宣布一项新计划之后,该计划拟在未来90天内允许最多30万磅外国牛肉以低于当前市场价25%的价格进入美国。这一时机引发了激烈的政治争议:

  • 民主党方面: 参议员候选人James Talarico批评该计划是“政治噱头”,认为大量外国牛肉涌入会削弱美国农民和牧童的竞争力,并对德州经济造成不利影响。
  • 共和党方面: 共和党候选人Ken Paxton的竞选团队对这批牛肉未按法律要求进行联邦复检的行为表示强烈谴责,强调德州牧民遵循着全球最严格的标准,并要求政府就此事给出解释,确保类似情况不再发生。

目前,相关分销商尚未就此事发表评论。

40. AI Engineer Notebooks – free, framework-free RAG/agents/evals on Colab (github.com)

AI Engineer Notebooks 项目摘要

AI Engineer Notebooks 是一个旨在为后端或全栈工程师提供实战训练的 Google Colab 笔记本集合。该项目专注于培养 AI 工程师(AI Engineer) 和 前向部署工程师(FDE) 的核心技能,涵盖了从提示词工程、RAG、智能体(Agents)到评估(Evals)、微调及模型部署的全栈应用层知识。

核心设计理念

  • 去框架化(Framework-free): 强调直接使用原始 API 进行开发(如编写智能体循环、RAG 流程),而非依赖 LangChain 或 LlamaIndex 等框架。其目的是让学习者在掌握底层原理及模式后再使用封装工具,以便能更好地判断何时该使用或不使用框架。
  • 评估驱动(Evals-centric): 将“在调整前先测量”作为核心原则,通过持续的评估机制(Evals)来衡量系统性能,这是区分演示原型与生产级系统的关键。
  • 低成本运行: 全程使用免费的 Groq API,降低了学习者的经济负担。
  • 实战导向: 包含真实的案例研究和一项结课项目(Capstone),将所学技能应用于解决实际生产环境中的问题。

课程结构与内容

学习路径按顺序从基础到高级,每个笔记本都是自包含的(自动安装依赖并从 Colab 秘钥读取 API Key):

  1. 基础准备 (00-01): 环境设置、成本控制、模型 API 调用基础(提示词工程、结构化输出、工具调用、流式传输、上下文管理与缓存)。
  2. 评估基础 (02): 学习如何使用黄金集(Golden sets)和指标来衡量模型输出。
  3. RAG (03): 深入检索增强生成(RAG)流程,包括嵌入(Embeddings)、检索策略、混合检索与重排序(Reranking)、分块(Chunking)策略以及 RAG 失败的诊断。
  4. 高级评估 (04): 构建黄金集、使用 LLM 作为裁判(LLM as Judge)以及建立回归测试(Regression evals)以实现持续集成(CI)。
  5. 智能体 (05): 从零构建智能体循环、工具设计、护栏(Guardrails)与预算控制、MCP 协议、技能封装及测试套件工程。
  6. 模型适配 (06): 探讨微调(Fine-tuning)、RAG 与提示词工程之间的权衡(含 LoRA/QLoRA 概念)。
  7. 安全性 (07): 学习提示词注入(Prompt injection)、信任边界及 OWASP LLM Top 10 风险。
  8. 运维与性能 (08-10):
    • LLMOps: 可观测性、可靠性(重试/回退)、实验跟踪(MLflow)。
    • 推理服务: 推理框架(vLLM, TGI 等)及性能优化(吞吐量与延迟)。
    • 系统设计: 模拟 ML 系统设计面试,进行 QPS、显存、延迟及成本估算。
  9. 客户工程 (11): 学习如何将模糊的客户需求转化为可评估的技术需求(Scoping & Discovery)。
  10. 实战应用 (12):
    • 案例研究: 包含客户支持助手(生产环境调试)、合同提取(Pipeline vs Agent 成本对比)及红队鲁棒性基准测试。
    • 结课项目 (Capstone): 要求学习者独立开发并部署一个包含服务组件和评估报告的真实项目,用于简历展示。

技术规范

  • 兼容性: 全程遵循 OpenAI 兼容接口,便于模式迁移至 Anthropic 等其他模型。
  • 工具链: 使用 aien 轻量级辅助包处理凭据加载和环境设置;在涉及 GPU 的高级主题(如微调和推理服务)时,提供基于 Colab T4 GPU 的概念说明及可选代码。
  • 数据一致性: 在 RAG 和评估章节中使用共享语料库,确保评估结果能准确反映检索系统的表现。
41. Terminal-Bench-Science: Evaluating AI agents on scientific research workflows (www.terminal-bench-science.ai)

Terminal-Bench-Science: 科学研究工作流 AI 智能体评估基准

概述 Terminal-Bench-Science 是一个由斯坦福大学研究人员领导、并由全球多领域专家协作构建的基准测试,旨在评估 AI 智能体在真实科学研究工作流中的能力。该项目旨在开发能够执行高技术难度、耗时较长的科学任务的 AI 助手,从而让科学家能够专注于定义研究问题、提出假设、解释结果和沟通发现等核心环节,从而加速科学发现。

核心设计理念

  • 由科学家定义标准: 不同于模型开发者或数据供应商,该基准由执业科学家设计,确保评估内容反映真实的科研实践,而非教科书题目或标准化练习。
  • 可验证的能力证据: 通过对分析、模拟、证明、代码和数据产品等具体成果进行任务特定的测试,提供科学能力的客观、可重复验证。
  • 持续演进的反馈循环: 该基准是持续更新的,旨在建立科学需求与 AI 开发之间的反馈循环,随着 AI 前沿技术的进步而不断通过新任务和改进后的任务进行校准。

任务覆盖与筛选机制 在 0.1 版本中,基准测试包含 70 个专家策划的任务,涵盖以下五个主要科学领域:

  • 生命科学: 包括生物学、医学、神经科学等。
  • 物理科学: 包括天文学、物理学、材料科学、化学等。
  • 地球科学: 包括地质学、大气与气候、海洋学等。
  • 数学科学: 包括应用数学、运筹学、形式数学、统计学等。
  • 工程科学: 包括机械、航空航天、电子与计算机、化学工程等。

任务通过严格的**“提议 $\rightarrow$ 构建 $\rightarrow$ 评审”**流程进行筛选。在 920 个提议中,只有 70 个任务最终进入 0.1 版本。这种高度的选择性确保了任务不仅在科学上具有意义,而且对前沿 AI 智能体具有足够的挑战性,并能进行严格的评估。

性能表现 (0.1 版本) 目前的测试结果表明,AI 智能体在科学研究领域的表现仍有巨大的提升空间:

  • 顶尖表现: Claude Opus 5(配合 Claude Code)表现最强,任务解决率为 30.0%。
  • 其他领先模型: GPT-5.6 Sol (22.4%) 和 Claude Fable 5 (21.4%) 分列第二、三位。
  • 整体水平: 大多数模型(如 GPT-5.6 Terra、Kimi K3、Grok 4.6 等)的解决率均低于 10%。

评估还涵盖了成本与解决率以及 Token 使用量与解决率的权衡。例如,Claude Opus 5 虽然达到了最高的解决率,但也消耗了最高的评估成本(约 7,000 美元);而 GPT-5.6 Sol 在达到较高解决率的同时,成本显著低于 Claude Fable 5。

未来规划 Terminal-Bench-Science 0.1 只是一个开始。项目组正致力于 0.2 版本 的开发,通过定期发布新版本来增加任务、扩大领域覆盖范围,并淘汰已被智能体“饱和”(即过容易)的任务。

协作与支持 这是一项开放的学术协作,由斯坦福大学和 Laude Institute 主持,并得到了斯坦福 AI 实验室 (SAIL)、斯坦福人类中心人工智能研究院 (HAI)、艾伦人工智能研究所 (Ai2) 等多家顶尖科研机构的支持。

42. Smaller reactors bring nuclear power closer to fulfilling its promise (www.nature.com)

小型模块化反应堆(SMR)与核能技术革新总结

随着全球对清洁能源需求的增长(尤其是人工智能数据中心),核能产业正经历从传统大型轻水反应堆向**小型模块化反应堆(SMR)**转型的趋势。

1. SMR 的核心优势与争议

  • 模块化设计:与传统发电量达 1,000 MWe 的大型反应堆不同,SMR 的发电量最高约为 300 MWe。其核心优势在于“模块化”,即大部分组件可在工厂预制后运至现场组装,类似于“乐高”式构建,旨在降低建设成本并缩短工期。
  • 经济性争议:批评者认为,除非能实现大规模工厂化生产,否则 SMR 的单位成本未必比大型反应堆更低。
  • 投资趋势:美国能源部(DoE)和欧盟均已投入巨额资金支持 SMR 的开发与部署。

2. 关键技术创新与安全性

新一代反应堆正尝试摆脱传统的轻水冷却方式,转向更安全、更高效的燃料与冷却技术:

  • Kairos Power (Hermes 1):
    • 燃料:采用 TRISO 燃料(一种包裹在碳陶瓷壳层中的微型铀颗粒)。这种燃料具有极高的耐热性,被称为“走开式安全”(walk-away safe),即使在极端事故温度下也不会熔化。
    • 冷却剂:使用熔盐(FLiBe)。熔盐沸点极高,允许反应堆在常压下运行,消除了高压容器的需求,并降低了压力导致放射性物质泄露的风险。此外,该设计支持在线换料。
  • TerraPower (Natrium):
    • 冷却剂:采用液态钠。钠具有高沸点且能与铯、碘等危险放射性元素结合,从而将其留在反应堆内。
    • 被动安全:其全金属设计允许通过自然空气循环进行被动冷却,无需外部电力或泵送即可防止类似福岛事故的熔毁风险。
    • 储能功能:利用熔盐存储热量,以应对电力需求波动。
  • 熔盐反应堆 (MSR):
    • 这类设计将燃料与冷却剂混合为液体。其优势在于高效率、低压运行,并且能够利用锕系元素(核废料)作为燃料进行后续反应,从而大幅减少核废料。

3. 面临的技术挑战

尽管前景广阔,但新技术的落地仍面临重大障碍:

  • 燃料供应:TRISO 等新型燃料需要高丰度低浓缩铀 (HALEU),目前全球相关产能尚在建设中,成本较高。
  • 材料科学:
    • 腐蚀问题:熔盐具有强腐蚀性(例如会溶解钢材中的铬),对反应堆结构材料提出了严苛要求。
    • 辐射损伤:高温与强辐射会导致材料原子位移并形成缺陷,造成材料变脆。研发能抵御高温、辐射和腐蚀的新型合金(如磁性钢或钒基合金)是当前的研究重点。

4. 监管与部署前景

由于 SMR 具有更高的固有安全性(如常压运行、被动冷却),监管机构(如美国 NRC)正在研究允许根据技术特性设置更小的应急规划区。这意味着 SMR 可以更靠近电力需求中心(如城市或工业区)进行部署,提高能源利用效率。

43. HTTPX2 – A next-generation HTTP client for Python (github.com)

HTTPX2 概述

HTTPX2 是一个专为 Python 设计的下一代全功能 HTTP 客户端库。作为原 httpx 项目的延续,该项目目前由 Pydantic 接手管理,旨在为用户提供持续的维护、及时的安全更新以及稳定的功能演进。

核心特性

HTTPX2 在继承了 requests 易用性的基础上,提供了以下高级功能:

  • API 兼容性:提供与 requests 高度兼容的 API 接口。
  • 协议支持:全面支持 HTTP/1.1 和 HTTP/2 协议。
  • 同步与异步:同时提供标准的同步接口和强大的异步(Async)支持。
  • 命令行工具:内置集成的命令行客户端,方便直接进行 HTTP 请求测试。
  • 应用集成:支持直接向 WSGI 或 ASGI 应用程序发送请求。
  • 工程质量:具备严格的超时控制、完全的类型注解(Type Annotations)以及 100% 的测试覆盖率。
  • 标准功能:继承了 requests 的所有标准特性,包括连接池、Cookie 持久化、SSL 验证、国际化域名(IDNA)、代理支持、多部分文件上传、自动解压缩等。

安装方式

可以使用 pip 进行安装:

  • 基础安装:
    pip install httpx2
    
  • 启用 HTTP/2 支持:
    pip install httpx2[http2]
    
  • 安装命令行客户端(可选依赖):
    pip install 'httpx2[cli]'
    

可观测性

HTTPX2 与 Pydantic Logfire(基于 OpenTelemetry 的观测平台)具有原生集成能力。通过简单的几行代码进行配置,即可实现对所有 HTTP 请求的追踪(Traces)、耗时统计和状态码监控,无需复杂的额外配置。

技术架构与依赖

HTTPX2 构建在多个优秀的开源库之上:

  • 底层传输:httpcore2(使用 h11 实现 HTTP/1.1)。
  • 并发处理:anyio(提供支持 asyncio 和 trio 的结构化并发原语)。
  • 安全与国际化:truststore(操作系统级 SSL 验证)和 idna(国际化域名支持)。
  • 可选依赖:包括 h2 (HTTP/2)、socksio (SOCKS 代理)、rich & click (增强命令行体验) 以及 brotli/zstd (压缩算法支持) 等。

该项目采用 BSD 许可证 发布。

45. Silicon Valley is in denial in face of widespread backlash (www.bloodinthemachine.com)

硅谷在广泛抵制面前陷入否认状态

本文指出,硅谷正面临着民众对其核心技术目标(尤其是生成式 AI 及其基础设施)的广泛且持续的抵制,而行业领导层却对此表现出否认或脱离现实的态度。

抵制的主要领域

公众的负面情绪集中在以下几个方面:

  • 数据中心建设:大量民众反对在居住区建设大规模数据中心。一项调查显示,75% 的美国人反对在居住地附近建造此类设施。
  • 监控技术:公众对 Flock 等监控摄像头的应用表示强烈不满。
  • AI 穿戴设备:Meta 推出的集成了 AI 功能的智能眼镜被部分公众视为对隐私的侵犯。
  • 生成式 AI:社会对生成式 AI 的整体情绪趋于负面,调查显示仅有 9% 的美国人对 AI 感到兴奋多于担忧。

行业反应与争议

面对日益增长的抵制浪潮,科技行业领导者和政策支持者并未表现出实质性的改进或反思,反而采取了以下反应:

  • 否认与阴谋论:一些人将反对运动归咎于“中共的心理战(psy-op)”、精神错乱或受雇佣的“托儿”。
  • 技术决定论:部分观点认为,在技术发展问题上不应听取普通民众的意见。
  • 荒谬的辩解:甚至出现了认为反对数据中心建设是对“即将产生意识的 AI”进行“种族灭绝式人口控制”的极端说法。

抵制背后的深层原因

文章认为,公众的抵制并非无理取闹,而是基于对以下问题的理性反应:

  1. 缺乏民主参与:大型基础设施项目(如数据中心)在缺乏公众咨询和民主决策的情况下强行推进,侵入了公共空间和个人生活。
  2. 经济与环境成本不匹配:相比于数据中心带来的噪音、高能耗和环境影响,其为当地社区提供的就业机会(多为短期建筑工或极少数 IT 岗位)微乎其微,而收益却流向了远方的科技巨头。
  3. 隐私与权力失衡:监控技术(如 Flock 摄像头)被用于追踪公民,加剧了民众在日益增长的不平等和权力不对称感中的无力感。
  4. 就业与分配问题:在劳动力收入份额下降、消费信心低迷的背景下,科技高管公开承诺用软件取代数百万个工作岗位,这进一步加剧了公众对 AI 带来的经济不确定性的恐惧。

结论

当前的抵制是对硅谷核心项目(快速扩张、大规模提取公共数据以实现私人利益)的直接拒绝。尽管行业试图通过掩盖矛盾或攻击反对者来维持现状,但这种广泛的民意表明,公众并不认为这些技术的代价是值得的。

46. An investigation into the state of corvid–human relations (www.audubon.org)

鸦科动物与人类关系的调查研究

本文探讨了鸦科动物(如乌鸦、渡鸦等)与人类之间复杂且多层次的互动关系,分析了这种联系究竟是基于生存需求的实用主义行为,还是可以被视为一种真正的“友谊”。

友谊与实用主义之争

许多人通过定期喂食与当地的乌鸦建立了深厚的情感连接,甚至将其视为朋友。然而,科学家对这种互动的动机持有不同观点:

  • 生存驱动论:行为生态学家 Anne B. Clark 指出,乌鸦可能仅仅将人类视为生存资源的来源。人类的庭院提供了相对安全的觅食场所,而人类提供的食物则是一种额外的奖励。关于乌鸦向人类留下“礼物”(如硬币、钥匙)的行为,Clark 认为这可能只是幼鸟在玩耍或为了捡起食物而丢弃手中物品的偶然行为。
  • 策略性智能论:鸦科生物学家 John Marzluff 则认为,考虑到鸦科动物极高的智商,这种行为可能是策略性的。如果乌鸦发现留下物体能换取奖励,它们可能会通过学习将此行为常态化。

友谊的哲学标准

哲学家 Thom van Dooren 从哲学角度提出了衡量“友谊”的几个标准,并认为乌鸦在某些方面符合这些条件:

  1. 个体识别:友谊始于对彼此个体的识别。研究表明,乌鸦具有卓越的面孔识别能力,不仅能记住人类,还能记住谁曾伤害过它们,并能在数年后通过特定的鸣叫或行为进行回应。
  2. 主体间性参与(Intersubjective Engagement):这涉及两个意识形态的交汇。乌鸦对人类目光的关注以及眼神交流,表明它们能够参与到一种共同的现实感知中。
  3. 叙事能力:友谊需要对经历进行某种逻辑构建。通过实验证明,乌鸦在解决问题时展现出了类似“心理演练”的神经活动,暗示它们能够为自己的经验构建某种形式的“叙事”。

进化与文化协同演化

人类与鸦科动物的关系具有深远的历史背景,被视为一种“文化协同演化”:

  • 历史互动:在史前时代,鸦科动物通过跟随人类狩猎和捕鱼来获取食物,而人类则通过各种手段(如驱赶、制作稻草人)来应对这些竞争者。这种长期的互动塑造了彼此的习性。
  • 文化影响:鸦科动物在世界各地的神话中扮演着重要角色,如北美原住民文化中的渡鸦,以及古希腊神话中的关联。
  • 城市化适应:随着人类向城市迁移,乌鸦也随之改变了行为模式,例如在电线杆上筑巢,并对人类表现出较低的戒心。这种适应性可能是通过世代传承的文化学习或生物进化实现的。

结论:独立的生命轨迹

尽管人类倾向于在与鸦科动物的互动中寻找情感寄托和叙事意义,但必须认识到,这种关系往往是由动物主导的。乌鸦拥有完全独立于人类的社会生活——无论是它们复杂的家族关系,还是在冬季大规模聚集的栖息行为,都表明它们拥有属于自己的、不依赖于人类观察的社会逻辑与生存叙事。