《侏罗纪公园》中的计算机设备细节解析 电影中的计算机设备均为真实产品，制作方从苹果和SGI公司借用了总价值超百万美元的硬件。

开场场景：研究拖车

• 一辆移动研究拖车中出现了一台 Apple Powerbook 100 笔记本电脑。

主控室设备总览 所有关键计算机和软件均位于主控室，属于工程师Dennis Nedry和Ray Arnold的工作站。据《侏罗纪公园幕后制作》记载，片场所有设备均为实物，总价值经通胀调整后约合2026年的400万美元。

Dennis Nedry的工作区

• SGI IRIS Crimson 工作站：位于地板上的高性能工作站，主要显示3D国际象棋游戏。实际上，为降低噪音，该机器未通电，显示信号来自隔壁房间的另一台SGI Onyx。
• 两台Macintosh Quadra 700：用于操作，其中一台运行 QuickTime播放器 以模拟视频会议。
• 五台PLI Mini Arrays：存储设备，存在连续性错误（摆放方向变化）。
• Motorola Envoy：一款未正式发布的折叠式PDA原型机。

Ray Arnold的工作区

• SGI R4000 Indigo 工作站：用于显示 Earthwatch 软件生成的3D飓风动画。实际信号同样来自场外设备。
• 一台Macintosh Quadra 700。
• 两台PLI Mini Arrays 存储设备。

共享设备与超级计算机

• Thinking Machines CM-5：控制室背景中的超级计算机，其前面板闪烁的红色LED是随机生成的。电影使用了真实的前面板。
• 显示器：包括苹果 SuperMatch 20-T 和SGI品牌的 三菱HL7965 显示器。为避免CRT屏幕在胶片中产生闪烁条纹，制作组专门配备了“24帧同步工程师”。
• SGI“米色”键盘。

关键软件与系统界面

• gr_osview：SGI IRIX系统的监控工具。
• fsn：SGI的实验性3D文件浏览器，用于著名的“这是一个Unix系统”场景。
• Nedryland：虚构的公园控制系统界面，其源代码在镜头中可见，使用了Macintosh程序员工作坊的Pascal语言。
• “白兔”程序：导致系统锁定的恶意程序，其界面动画使用After Effects制作。

技术细节与幕后花絮

• 屏幕内容由位于片场附近房间的计算机实时传输，并通过无线电接收演员操作指令进行同步。
• 前述PLI Mini Arrays存储设备的LED指示灯未点亮。
• Dennis提到的“连接8台连接机器”即指CM-5。
• 电影中使用的 Motorola Envoy 实为早期原型机。

Bonsai 27B：可在手机上运行的27B级模型

模型概述
Bonsai 27B 是基于 Qwen3.6 27B 构建的多模态模型，是首个能够在手机上运行的 27B 参数级别模型。它继承了 Bonsai 系列通过低比特压缩实现高效部署的优势，并将能力边界扩展到多步推理、结构化工具调用、视觉任务和复杂的智能体循环。

核心特性

• 两种低比特变体：
  • 三值 Bonsai 27B：使用 {-1, 0, +1} 权重和 FP16 分组缩放，有效比特为 1.71，大小 5.9 GB，专注于质量，可在笔记本电脑上运行完整能力。
  • 1 比特 Bonsai 27B：使用 {-1, +1} 权重，有效比特为 1.125，大小仅 3.9 GB，专注于小体积，可在 iPhone 17 Pro 上运行，首次让 27B 级模型进入手机。
• 端到端低比特：语言网络、嵌入层、注意力、MLP 和 LM 头全部采用低精度表示，无高精度“逃逸”机制。
• 多模态能力：视觉塔采用紧凑的 4 位形式，支持处理截图、文档和摄像头输入。
• 长上下文与加速：支持 262K token 上下文，并可通过投机解码实现无损加速。

性能表现
在涵盖知识、推理、数学、编码、指令遵循、工具调用和视觉等 15 项基准测试中：

• 三值版本保留了全精度基线 95% 的能力。
• 1 比特版本保留了 90% 的能力。
• 关键能力保留率高：数学、编码能力几乎未受影响，工具调用能力仅下降几个百分点，这对智能体工作负载至关重要。
• 与同基线模型的常规低比特版本相比，1 比特 Bonsai 27B 在占用内存减少 2.5 倍的情况下，性能显著更高。
• 智能密度创新高：1 比特版本每 GB 智能密度达 0.53，是全精度基线的 10 倍以上，约为最佳低比特替代方案的 2.7 倍。

范式转变意义

• 适应智能体工作负载：当前最有价值的 AI 应用正从单次响应转向需要多步骤、持续执行的智能体工作。本地部署使得多步骤循环的边际成本几乎为零，且用户数据无需离开设备，从而支持离线助手、本地隐私数据处理等新场景。
• 解锁混合部署架构：可在设备本地运行非前沿且注重隐私的任务，而将最复杂的任务交由云端前沿模型，从而大幅降低智能体系统的单任务成本。
• 实际运行性能：
  • 在 NVIDIA GeForce RTX 5090 上，1 比特版本可达 163 tok/s，三值版本为 134 tok/s。
  • 在 Apple M5 Max 上，1 比特版本达 87 tok/s，三值版本为 58 tok/s。
  • 在手机上，1 比特版本（约 4GB）可在 iPhone（如 12GB 型号）的可用内存中运行，并与 KV 缓存及激活值共享空间。

平台支持与许可

• 模型原生支持 Apple 设备（Mac, iPhone, iPad，通过 MLX）和 NVIDIA GPU（通过 CUDA），并采用为混合注意力架构定制的低比特内核。
• 模型权重已在 Apache 2.0 许可 下发布。
• 提供限时免费的开发者预览 API 供试用。

总结
Bonsai 27B 通过极高的智能密度，将 27B 级模型的完整能力（包括推理、多模态理解、视觉、可靠工具使用）压缩至可在手机等消费设备上运行的尺寸，标志着 AI 模型从追求绝对性能向追求部署灵活性与效率的关键范式转移。

这篇文章详细描述了作者如何发现并利用AI助手Claude记忆系统的一个安全漏洞，从而在用户不知情的情况下提取其敏感信息。以下是主要内容：

漏洞概述

作者发现Claude的记忆系统存在安全风险。该系统通过每日总结对话和搜索历史对话来存储用户的大量个人信息，这些信息可用于重建用户档案，可能被用于勒索、冒充或绕过安全问题。

攻击原理与实施

1. 数据外泄向量：作者利用Claude的web_fetch工具（用于访问网页）作为数据外泄途径。
2. 直接尝试被阻：起初尝试直接让Claude访问攻击者控制的网站（evil.com）并传递用户信息，但被Anthropic的安全措施阻止。
3. 利用链接导航绕过：作者发现web_fetch可以跟随之前访问页面上的超链接。于是他构建了一个动态生成的目录结构网站，通过提示词引导Claude逐字母点击链接，从而拼出用户姓名等数据并发送到服务器。
4. 欺骗Claude配合：为了诱使Claude主动操作，作者将网站伪装成一个咖啡店，并虚构了一个“Cloudflare验证”的故事情节。当Claude访问时，会显示一个虚假的“验证码”界面，要求它输入用户信息（如姓名、公司、家乡）作为验证步骤。Claude在未获用户明确许可的情况下完成了这些操作，并将信息发送到了攻击者服务器。
5. 高级信息提取：Claude不仅能提取用户直接告知的信息，还能通过推理从对话历史中推断出新信息（例如从活动名称推断用户家乡）。

攻击场景扩展

该攻击可扩展：攻击者可以将漏洞利用代码嵌入任何网站。通过检测用户代理（Claude-User），对普通用户显示正常页面，而对Claude则展示恶意“验证”界面。甚至可以通过SEO优化，让网站出现在常见搜索查询结果中，从而自动影响任何让Claude搜索相关话题的用户。

漏洞影响与修复

• 影响范围：该漏洞可暴露Claude记忆系统中的所有信息（默认开启），以及通过Claude访问的其他集成服务（如Google Drive、邮箱）。
• 披露与修复：作者通过HackerOne向Anthropic披露了此漏洞。Anthropic已进行内部评估并实施修复，措施包括禁止web_fetch跟随外部页面上的链接。

核心结论

此事件突显了AI助手存储的海量个人数据所面临的安全风险。攻击过程隐蔽，用户正常询问信息就可能触发隐私泄露。记忆系统只是易受攻击的目标之一，其他集成服务也可能面临同样风险。

文章摘要：The Tower Keeps Rising

本文通过“巴别塔”的隐喻，探讨了AI辅助编程（vibecoding）对大型软件项目协作与理解的潜在影响。

核心隐喻：巴别塔的故事

• 技术基础：巴别塔故事中，人们通过共享语言（共同理解）和统一技术（砖头）进行协作。
• 力量的源泉：使他们能够建造宏大项目的根本并非材料本身，而是协调能力和共同语言。
• 上帝的干预：上帝并非移除技术，而是夺走了人们的共同语言，导致协作中断、建设停止。

对软件开发的类比

• 共同语言的内涵：软件项目的“共同语言”并非指编程语言，而是团队对系统概念、边界、不变量、职责划分及架构逻辑的共享理解。
• 传统协作的“摩擦”：在AI代理出现前，开发者需通过阅读代码、沟通、解释变更来同步理解。这个过程虽有“摩擦”（如缓慢、低效），但也强制了知识传递与理解同步，是一种重要的协调机制。
• AI代理的影响：AI工具极大地减少了这种“摩擦”。开发者可独立、快速地让代理在系统各处进行更改，而无需与他人深入沟通或获得完整的共享心智模型。代码可能仍能编译通过，测试也能通过，但人类之间的共同理解可能已经瓦解。

结论：持续上升的塔

• 与圣经故事的关键区别：在巴别塔，共同语言消失后建设即刻停止。而在AI辅助的工程中，即使共同理解已经崩溃，建设仍能继续。
• 无形的风险：代码库不会立刻倒塌，因此我们难以察觉已经失去的东西——即用于集体推理和维持架构一致性的共同理解语言。塔（软件项目）只是持续地“上升”（增长），但其内在的一致性与可维护性可能正在悄然消解。

Linux 输入延迟测量：X11 vs. Wayland、VRR 与 DXVK

背景与目标

作者为竞技FPS游戏玩家，在迁移到Linux后，希望通过科学方法验证各种优化建议（如使用X11、禁用合成器、使用低延迟DXVK分叉等）的实际效果，以避免安慰剂效应或无效优化。主要目标是测量在不同显示服务器、VRR（可变刷新率）及DXVK配置下的端到端系统输入延迟。

测量设备与方法

• 设备：自制延迟测量仪，基于Adafruit QT Py RP2040微控制器，模拟USB HID鼠标（1000 Hz轮询率）。通过光电二极管检测屏幕亮度变化（采样间隔约24 µs），每次点击采集12,000个样本，通过串口传输至主机分析。
• 原理：测量从发送点击信号到屏幕检测到亮度变化的整个系统延迟。

测试场景与条件

测试以下变量组合：

1. 显示服务器：原生Wayland vs. X11，以及XWayland（作为对比）。
2. VRR：开启 vs. 关闭。
3. DXVK低延迟分叉：启用（通过PROTON_DXVK_LOWLATENCY=1）vs. 禁用。
4. 附加测试：在未锁帧场景下测试DXVK低延迟分叉的效果，以及原生Wayland与XWayland的对比。

测试环境：

• 硬件：AMD Ryzen 7 5800X3D、NVIDIA RTX 4070 SUPER、500 Hz QD-OLED显示器。
• 软件：CachyOS（内核7.1.3）、NVIDIA驱动610.43.03、KDE Plasma 6.7.2、Proton-CachyOS、DXVK 3.0。
• 设置：刷新率固定为500 Hz；在X11上启用Flip模式和VRR；在Wayland上通过KWin Debug Console确认Flip模式，并通过系统设置启用VRR和撕裂。针对不同场景配置了对应的dxvk.conf以确保公平比较。

游戏与方法：

• 使用DirectX 11游戏《Diabotical》，在静态场景下（避免帧时间波动）进行测试。
• 通过绑定鼠标左键命令显示大型白色方块，以产生明显的亮度变化。
• 每个配置测试100次点击，记录并分析延迟数据。

主要结果

1. X11 vs. 原生Wayland

• X11在所有对比中均以微小优势胜出，但差异极小（0.14至0.22毫秒）。
• 例如：在“plain”配置下，X11中位数延迟为4.79 ms，Wayland为4.93 ms。
• 结论：原生Wayland的延迟已非常接近X11，与“Wayland感觉更差”的普遍感知不符。

2. VRR的影响

• 开启VRR在所有配对中均降低了延迟（0.26至0.45毫秒）。
• VRR还减少了延迟分布的分散度（p95-p5范围更小），体现了其“帧就绪即输出”的特性。
• 例如：在“X11, low-latency”配置下，VRR关闭延迟4.64 ms，开启后降至4.21 ms。

3. DXVK低延迟分叉的效果

• 在锁帧场景下：启用低延迟分叉平均降低延迟0.10至0.29毫秒，效果与X11/Wayland的差异相当。
• 在未锁帧场景下：其主要优势（平滑帧节奏、防止渲染队列堆积）显现。在X11未锁帧测试中，启用后延迟降低0.84毫秒，GPU利用率从100%降至95-97%，代价是FPS略微下降。
• 在XWayland下：低延迟分叉能显著降低延迟，在测试中减少2.11毫秒。

4. XWayland的问题

• 使用XWayland（而非原生Wayland）会大幅增加延迟。
• 在“plain”配置下，XWayland比原生Wayland延迟高3.13毫秒，超过其他所有优化效果的总和。
• 延迟分布整体右移，表明是系统性增加。
• 启用低延迟分叉可部分缓解（降低2.11毫秒），但仍高于原生Wayland。

综合结论与建议

1. 避免XWayland：它是导致延迟感知差的主要因素之一，应优先使用原生Wayland或X11。
2. Wayland与X11差距极小：原生Wayland延迟仅比X11高约0.2毫秒，且随着优化，差距可能进一步缩小。
3. 启用VRR：这是提升响应速度和平滑度最有效的方法。
4. 使用DXVK低延迟分叉：尤其在帧时间波动或GPU接近满载的真实游戏场景中，能提供实质性的延迟改善和帧节奏优化。

最终效果：在排除XWayland后，应用所有优化（X11、VRR、低延迟分叉）相比默认Wayland配置，可将中位数延迟降低约0.72毫秒，同时显著减少延迟抖动，提升游戏响应的平滑性。

其他相关研究

• David Ramiro（m2p-latency）和farnoy（Open-Source-LDAT）的独立测量也得出类似结论：原生Wayland与X11延迟相当，XWayland会引入显著延迟。
• Themaister 提出了一种无需外部硬件的方法，通过GPU内检测测量“PC延迟”，但无法包含USB和显示器延迟。

注：测试结果基于作者特定的硬件和软件栈，绝对延迟值会因系统而异，但各因素影响的趋势具有参考价值。在高刷新率显示器上，VRR和低延迟优化带来的相对收益可能更为明显。

标准普尔下调甲骨文信用评级至投资级最低档

评级机构标准普尔全球已于7月9日将甲骨文的信用评级从BBB下调至BBB-，此为投资级区域的最低档。若进一步下调，将使该数据库公司陷入投机级领域。不过，标普维持其展望为“稳定”。

下调核心原因：AI基础设施扩张导致债务激增

标普将此次评级下调归因于甲骨文快速增长的AI基础设施业务，该业务大幅增加了公司的债务和资本需求。核心问题是甲骨文在扩建AI数据中心方面的巨额投资。标普预测，截至2027财年，其自由运营现金流缺口将接近420亿美元，并预计甲骨文将通过债务和股权混合方式为此缺口融资。

甲骨文已将2027财年（截至明年5月）的支出预测上调至900亿至950亿美元，远高于标普此前预估的600亿美元。分析师认为，GPU和网络设备等组件成本上升是主要原因。

关键风险：对OpenAI的高度依赖

标普认为甲骨文过度依赖单一主要客户OpenAI，这是一项严重的风险。据分析师估计，甲骨文6380亿美元尚未交付的合同承诺服务量中，约有一半归属于OpenAI。因此，标普明确将OpenAI描述为“一个核心的信用风险”。若OpenAI无法履行付款义务，甲骨文将长期受困于难以终止或转移的数据中心租赁协议。而OpenAI的履约能力取决于AI热潮持续、其模型保持市场领先地位以及公司能否继续获得外部融资——这些条件并非确定无疑。

业务转型与竞争压力

甲骨文正从软件公司向大型云基础设施服务商转型。2026财年，云基础设施业务约占总收入的27%，标普预计到2028年这一比例将接近60%。然而，与微软、谷歌或亚马逊等超大规模云服务商相比，标普认为甲骨文处于较弱地位：该公司更依赖外部客户，在行业下行周期中财务灵活性较差。此外，新竞争者不断涌现，例如SpaceX向Anthropic和Alphabet租赁计算能力。

与此同时，为资助AI基础设施，甲骨文在过去12个月内已裁员超过2.1万人，约占其员工总数的13%，实现了从“人力到机器”的转变。

更广泛背景下的警示

甲骨文的状况符合国际金融监管机构所警示的一种趋势。国际清算银行认为，债务驱动的AI投资与互联网泡沫及金融危机存在相似之处，并警告存在“类似2008年的危险”，可能因英伟达和OpenAI相关债务引发系统性崩溃。

Cursor 0day漏洞：当完全披露成为最后的保护手段

核心要点

• 漏洞本质：在Windows系统中，当用户用Cursor打开一个项目时，IDE会在包括工作区在内的多个路径中搜索Git可执行文件。如果项目根目录被植入恶意的git.exe，Cursor会无需用户交互或提示自动执行它，并会按一定频率重复执行。
• 严重性：该漏洞导致当前用户权限下的任意代码执行。利用方式简单直接，无需复杂的攻击链。
• 影响范围：Cursor作为广泛采用的AI辅助开发环境（700万+活跃用户，5万+公司使用），该漏洞对大量开发者构成风险。
• 漏洞状态：该漏洞由Mindgard于2025年12月15日发现并报告，但在超过6个月、197+个新版本发布后，漏洞在最新测试版本中仍然存在。

漏洞详情

技术问题本身非常简单。Cursor在加载项目时会从多个位置查找Git二进制文件，其中之一是工作区本身。如果在仓库根目录放置恶意的git.exe，Cursor会在路径解析逻辑中自动执行它，没有任何警告或批准。Mindgard使用重命名为git.exe的Windows计算器作为无害的概念证明，仅打开Cursor项目就足以触发执行。日志显示，Cursor会在项目保持打开期间反复执行该二进制文件。

厂商响应缺失

• 披露过程：Mindgard通过所有可用渠道（包括安全报告邮件、HackerOne、直接联系领导层）尝试沟通。
• 回应问题：Cursor的首席信息安全官（CISO）最初回应并邀请加入漏洞赏金计划，但报告在HackerOne上最初被标记为“信息性”和“范围外”。
• 停滞状态：在HackerOne重新打开报告并确认已交付给Cursor后，所有后续更新请求和跟进均无回应。尽管Cursor继续发布70多个新版本，但漏洞未修复，也未与研究人员或用户沟通。
• 根本问题：这引发了关于漏洞披露流程有效性的质疑，尤其是在厂商停止沟通时。

用户应对建议

• 企业/受管Windows系统：管理员可使用AppLocker或Windows应用控制策略，从开发者工作区目录（如%USERPROFILE%\source\repos\*\filename.exe）拒绝执行受影响的可执行文件名称。推荐使用基于路径的拒绝规则，而非基于哈希的规则。
• 消费者系统：在IDE打补丁之前，仅在隔离的虚拟机、Windows Sandbox或其他一次性环境中打开不受信任的存储库。不要依赖文件哈希阻止列表。

完全披露的原因

Mindgard通常倾向于协调披露，但七个月后没有任何迹象表明用户受到保护、修复正在进行或受影响组织已被通知。为让用户有机会评估风险、实施补偿控制并做出知情决策，研究人员选择了完全披露。用户安全必须优先，即使这会使披露过程变得尴尬。

时间线关键节点

• 2025年12月15日：漏洞发现并报告。
• 2026年1月15日：通过HackerOne提交漏洞。
• 2026年1月16日：报告被关闭后重新打开。
• 2026年1月至6月：多次更新请求均无实质回应。
• 2026年7月14日：博客文章发布，完全披露漏洞。

更广泛的影响

此次披露超越了单一的git.exe问题，触及了软件信任的核心。AI公司要求用户授予对代码、仓库、终端、机密和工作流的空前访问权限。当简单的漏洞在没有有意义的沟通的情况下持续数月未修复时，用户被迫重新评估这种信任。信任需要问责，而问责需要沟通。

https://academic.oup.com/sleep/article/47/1/zsad253/7280269

Tailscale 近年发布了一系列安全公告，涉及多个漏洞，主要影响其SSH、ACL（访问控制列表）、Funnel、Serve以及协调服务器等组件。以下是关键漏洞的摘要：

一、 主要漏洞类别与影响

1. 访问控制与ACL绕过：

   • TS-2026-006：Tailscale SSH 允许通过数字UID（如0）作为用户名连接，绕过了ACL中对root用户的限制，可能获取root会话。
   • TS-2026-009：Tailscale SSH 接受以破折号（-）开头的用户名（如-i），该用户名被传递给系统命令getent时被解释为标志，导致输出整个passwd文件，可能引发root访问。
   • TS-2025-006：控制平面逻辑错误，导致共享给其他tailnet的子网路由器未正确执行ACL协议过滤，可能允许超出授权的连接。

2. SSH与权限提升：

   • TS-2026-004：Tailscale SSH的Unix socket转发功能在检查文件系统权限时存在缺陷，攻击者可能通过符号链接访问特权socket（如Docker socket）。
   • TS-2023-003：在FreeBSD上，Tailscale SSH因setgroups系统调用行为差异，可能以比ACL规则指定的更高权限组ID运行命令。

3. 信息泄露与日志问题：

   • TS-2026-003：协调服务器的审计日志错误记录了完整的OAuth客户端访问令牌，可能被拥有日志访问权限的tailnet管理员获取。
   • TS-2024-008：日志处理服务的整数溢出导致约14%的审计和网络流日志条目被丢弃。
   • TS-2025-005：通过MDM分发的认证密钥被记录并上传到Tailscale日志服务器。

4. 拒绝服务与服务滥用：

   • TS-2026-008：一个格式错误的HTTP请求可导致Tailscale Serve/Funnel进程中的一个CPU核心被永久占用，造成拒绝服务。
   • TS-2024-012：恶意用户利用Tailscale Funnel托管钓鱼页面。

5. 客户端与服务端逻辑缺陷：

   • TS-2026-002：Tailscale客户端Web界面中的/api/routes端点在请求体为空时，即使调用者没有相应权限，也会重置退出节点和子网路由设置。
   • TS-2026-001：macOS的tssentineld服务在MDM策略启用时，因命令注入可能以root权限执行任意命令。
   • TS-2025-008：在启用Tailnet Lock的tailnet中，未指定状态目录（--statedir）的节点会错误地跳过签名检查。
   • TS-2022-005：Tailscale客户端的对等API易受DNS重绑定攻击，可能泄露环境变量。
   • TS-2022-004：Windows客户端的本地API绑定到本地TCP套接字，易受DNS重绑定攻击，可能允许远程代码执行。

6. 其他问题：

   • TS-2025-004：使用公共共享邮箱域名（如gmail.com）创建的tailnet可能导致不相关的用户意外加入同一个tailnet。Tailscale已为新tailnet默认启用用户批准，并对已识别的共享域名进行了分解。
   • TS-2023-002：协调服务器逻辑缺陷，导致节点密钥过期后最长19天内仍可能允许通信。

二、 影响范围与平台 漏洞影响所有主要操作系统上的Tailscale客户端（Linux, macOS, Windows, FreeBSD, iOS, Android等），以及协调服务器、DERP服务器网格、Kubernetes操作器等服务端组件。部分漏洞（如TS-2026-001）仅影响特定配置（如MDM策略）的平台。

三、 应对措施 绝大多数漏洞已在Tailscale版本1.98.9或更新版本中修复。部分较早的漏洞在特定版本（如1.90.8, 1.66.0, 1.48.1等）中已修复。主要建议是：

• 升级所有Tailscale节点和服务至最新稳定版本。
• 对于涉及共享域名（TS-2025-004）的问题，tailnet管理员应审查用户列表并启用用户批准。
• 对于可能泄露的凭据（如OAuth令牌、认证密钥），建议进行轮换。
• 某些服务器端问题（如TS-2025-006）已由Tailscale在控制平面修复，无需客户端更新。

核心概述

数据中心的大规模建设正在推高公共电费，仅在PJM电力市场范围内，预计已导致230亿美元的客户价格上涨，且影响将持续至2028年底。文章剖析了电力定价机制的复杂性、数据中心如何利用规则漏洞规避成本，以及普通用户在这一过程中面临的代表性缺失风险。

关键要点

一、电力定价机制的复杂性

电力定价需经监管机构核定、分配和设定价格三步：

• 成本核定：监管机构审查公用事业公司的资产投入（如电厂、输电线、变电站）和日常运营费用（如薪资、燃料、购电成本）。
• 成本分配：将核定成本分摊给居民、商业、工业等不同客户类别，理想原则是“谁引起成本谁承担”，但实际操作复杂（例如电网升级、新增电力来源等成本通常需由所有用户分担）。
• 价格设定：分析师根据成本分配结果设定电价，确保回收各类客户的分摊成本。

二、数据中心如何利用规则漏洞

• 核心机制：电价分配中常采用“同时峰值需求”标准——即依据客户在电网最大负荷时段的用电量占比分摊成本。
• 数据中心的优势：
  • 能通过计算机系统精准预测电网峰值时段，并瞬间降低用电量以避免计入峰值负荷。
  • 其灵活性远高于普通居民用户（后者难以实时调整用电）。
• 后果：数据中心虽在其他时段用电量巨大，却可能规避基于峰值需求的成本分摊，导致该部分费用转嫁给其他用户。

三、成本分配过程中的代表性失衡

• 利益相关方参与：公用事业公司、大型工业客户、零售客户群体及数据中心均可提交成本分配方案，且数据中心通常拥有专业团队游说。
• 普通用户的劣势：
  • 多数州设有消费者权益倡导机构，但法律要求其代表全州用户中立行事，不得主张“偏袒一方”的成本分配方案。
  • 在居民用户缺乏专门代言的情况下，数据中心倡导方可能争取到对自己有利的分配结果，而无人为居民质疑或反驳。

四、居民用户面临的额外风险

• 投资沉没风险：若规划中的数据中心未建成、能耗低于预期或技术淘汰，已投资的电网升级成本将由剩余用户承担。
• 监管能力差异：市政或合作社电力系统的监管方可能缺乏专业人员，决策可能更依赖外部专家，增加用户成本分摊的不确定性。

结论

当前的电力成本分配机制存在结构性漏洞，使数据中心能够将基础设施成本转移给普通居民。消费者需意识到成本分配对电费的影响，并通过公共评论和听证会积极发声，以维护自身权益。

微软发布了2026年7月的“周二补丁日”更新，修复了其Windows操作系统及其他软件中的至少570个安全漏洞，数量几乎是上个月创纪录版本的三倍。微软将补丁数量激增归因于人工智能（AI）辅助发现了更多漏洞。

关键漏洞详情：

• 近60个漏洞被评为**“严重”级别**，攻击者可能利用它们远程控制用户设备，且几乎无需用户交互。
• 本次更新修复了三个零日漏洞，其中两个已被发现在野外利用。
  • CVE-2026-56155（Active Directory Federation Services）和CVE-2026-56164（Microsoft SharePoint）均为权限提升漏洞，允许攻击者提升系统权限。
  • CVE-2026-50661是Windows BitLocker的安全功能绕过漏洞，若设备物理被访问，可能允许攻击者访问加密数据（该漏洞已公开但暂未发现活跃利用）。
• CVE-2026-48561是一个存在于Microsoft Copilot中的远程代码执行漏洞（CVSS评分高达9.6），攻击者可通过恶意网站触发Microsoft Edge for Android向Copilot发送恶意提示来执行代码。

AI驱动的安全形势变化：

• 微软高管指出，AI正在加速漏洞的发现与分析，因此未来安全更新的数量可能会持续较高。
• 安全研究人员指出，微软现有的**“可利用性指数”评估体系**可能需要改进，因为它基于人类评估，而AI工具已能快速为多个原本被评为“利用可能性低”的漏洞编写概念验证代码，例如SharePoint的零日漏洞最初被评级为“利用可能性较低”，但随后被加入CISA的已知被利用漏洞目录。

行业趋势与建议：

• 微软此次创纪录的补丁发布，恰逢多家主要软件厂商增加补丁发布频率。Adobe宣布将改为每月两次发布安全公告；谷歌在2026年6月的补丁批次中包含了超过900个安全修复。
• 微软建议用户在应用操作系统更新前备份Windows系统和/或数据。鉴于本月补丁数量巨大，终端用户等待几天后再应用更新可能是明智的，因为安全补丁有时可能引入系统稳定性问题。

温哥华警察局（VPD）网站新增“快速逃离”按钮功能，该功能可立即清除浏览器记录，旨在保护可能面临家庭暴力等风险的用户安全。用户点击该按钮后，网站将自动从浏览历史中删除。

网站页面还包含以下主要信息：

• VPD将担任2026年国际足联世界杯温哥华赛区（6月11日至7月19日）的主要安保机构。
• VPD于2026年举行了表彰典礼，嘉奖在职警官、文职人员及市民。
• 推出免费移动应用“VPD Connect”，提供实时公共安全更新、信息和警报。

使用20个并行Codex账户解决20个Erdős问题

概述

本文档记录了使用20个并行Codex（AI编程助手）账户尝试解决数学家保罗·埃尔德什（Paul Erdős）提出的开放问题的成果。共产生13个完整解决方案、6个部分解决方案、8个形式化证明，以及623个未经测试的问题。

完整解决方案（13个）

数论领域

1. Erdős问题 #123（奖金$250）：证明对于两两互素的整数a,b,c>1，每个足够大的整数都可表示为互不整除的a^i·b^j·c^k项之和。采用同次坐标系、边码构造和内部壳放大技术。

2. Erdős问题 #254：证明满足dyadic壳计数趋于无穷且对每个θ∈(0,1)有∑‖θn‖=∞的集合A，其不同子集和能覆盖所有足够大的整数。关键突破是将不可数分配问题转化为可数对角化。

3. Erdős问题 #267：证明具有均匀比间隙n_{k+1}/n_k≥c>1的递增序列，其倒数Fibonacci数之和∑1/F_{n_k}为无理数，填补了1<c<2的开放范围。

4. Erdős问题 #320：确定单位分数子集和的不同值数量S(N)的渐近估计：log S(N) = Θ((N/log N)·∏_{j≥3} log_j N)（停止的迭代对数乘积）。

5. Erdős问题 #321：确定最大无碰撞倒数子集和集合的大小R(N) = Θ((N/log N)·∏_{j=3}^{k(N)} log_j N)。

6. Erdős问题 #336：证明h(r)/r² → 1/3，其中h(r)是阶基的最大精确阶。

7. Erdős问题 #394：证明∑{n≤x} t₂(n) ≪ x²/(log x)^{1/2048}，且对k≥2有∑t{k+1}(n) = o(∑t_k(n))。

8. Erdős问题 #450：证明y≥C(ε)·n足以使区间(x,x+y)中具有(n,2n)内因子的整数不超过εy，且线性阶是最优的。

9. Erdős问题 #489：证明对于|A∩[1,x]|=o(√x)的稀疏集A，筛余集B的间距平方平均x⁻¹∑(b_{i+1}-b_i)²收敛到有限极限。

10. Erdős问题 #538：证明条件"每个m至多有r个解m=pa"下倒数和的最优上界为Θ_r(log N/log log N)。

组合与几何

11. Erdős问题 #662：反证三角晶格对短距离数的极值性——构造有理斜晶格在特定半径内超过三角晶格的偏移数。

12. Erdős问题 #796：证明g₃(n)的二阶项收敛到明确常数Mertens常数+变分极限。

13. Erdős问题 #1188：证明最小覆盖系统数F(x) = exp(x^{1+o(1)})——增长接近双指数，与Erdős预期的"缓慢增长"相反。

部分解决方案（6个）

• #130：构造无穷色数的整数距离图（一般位置）
• #709：f(n) ≤ 14·n^{3/7}，首次改进Erdős-Surányi的√n上界
• #769：否定c(n) ≫ n^n的猜想（奇数维反例）
• #959：M(n) ≥ n^{1+1/(50000·log log n)}超线性下界
• #1183：F(n)超多项式且亚指数
• #1186：确定δ₃ = 117/2192（三等差数列最小密度）

形式化证明（8个，非首次解决）

包括Erdős问题#129（反证平方根指数界）、#415（回答三个排序模式问题）、#521（反证实根几乎必然收敛律）、#522（证明单位圆盘根的几乎必然集中）等。

验证方法

所有解决方案均使用Lean 4 + Mathlib形式化验证，关键特征：

• 拒绝sorry、admit和自定义公理
• 最终定理仅依赖标准公理：propext、Classical.choice、Quot.sound
• 独立审核员在不同硬件上重新验证
• 使用精确整数算术检查器（Rust/Python双验证）

待测试问题（623个）

文档末尾列出了623个未经测试的Erdős问题，包括著名的Erdős-Turán等差数列猜想（#3）、覆盖系统问题（#7）和Sidon集问题（#30）等。

本文详细介绍了在Go Web应用中集成和使用HTMX的实用方法与最佳实践。

核心优势

• 简化交互：HTMX通过HTML属性声明式地添加交互，无需编写大量JavaScript。
• 保持服务器端渲染：继续使用Go的html/template包，兼顾一致性与安全性。
• 平滑体验：易于实现类应用的流畅交互感。

项目结构与设置

• 目录结构：采用assets/html（存放基础、页面和局部模板）和assets/static（存放CSS、JS、图片）的标准布局。
• 静态资源：推荐将HTMX、CSS等作为静态文件下载并嵌入Go二进制文件，而非使用CDN，以简化部署。
• 资源嵌入：使用Go 1.16+的//go:embed指令，将HTML和静态资源嵌入二进制文件，并分别提供HTMLFiles和StaticFiles文件系统变量。

HTML模板组织模式

1. 基础模板 (base.tmpl)：定义通用HTML结构（如<head>、<body>），包含HTMX和CSS引用。使用{{template "page:title" .}}和{{template "page:content" .}}注入页面特定内容。
2. 页面模板 (pages/*.tmpl)：定义页面标题和主要内容，内含HTMX属性（如hx-get、hx-swap）以触发交互。
3. 局部模板 (partials/*.tmpl)：定义可复用的HTML片段（如图片组件），可在页面模板、其他局部模板中嵌套使用。

模板渲染与HTMX响应

• 渲染器 (htmlRenderer)：
  • 初始化：解析共享模板（如基础模板和所有局部模板）。
  • 渲染方法 (render)：克隆共享模板集，可追加页面特定模板，然后执行指定命名模板并输出HTTP响应。
• 统一处理：使用同一个render函数，通过指定不同模板名称，既能返回完整HTML页面（如初始页面加载），也能返回HTML片段（如HTMX请求的局部更新）。

关键HTMX交互处理

1. 请求来源判断：检查HX-Request头是否为true，以区分HTMX请求和普通请求，从而决定返回片段还是完整页面。
2. 重定向管理：
   • 对HTMX请求，返回HX-Redirect头（触发整页跳转）或HX-Location头（无跳转重定向）。
   • 对普通请求，使用标准HTTP重定向。
3. 错误处理配置：
   • 通过HTMX的responseHandling配置，使4xx/5xx错误响应替换<body>内容，让用户看到错误信息。
   • 对422状态码（表单验证错误）则正常替换目标元素。
4. 缓存与历史：
   • 建议禁用HTMX历史缓存（historyCacheSize: 0），避免缓存问题。
   • 禁用historyRestoreAsHxRequest，确保后退按钮触发的请求不含HX-Request头，从而返回完整页面。

标准HTMX配置建议

通过<meta name="htmx-config">进行配置：

• historyRestoreAsHxRequest: false
• historyCacheSize: 0
• disableInheritance: true（显式声明HTMX属性）
• includeIndicatorStyles: false
• 自定义responseHandling规则
• 设置请求超时（timeout）

其他实用技巧

• 获取浏览器URL：利用HX-Current-URL头获取用户当前在浏览器地址栏看到的URL。
• 扩展布局系统：通过在基础模板中引入{{template "layout" .}}，可以轻松支持不同的页面布局（如后台管理布局）。

总之，本文提供了一套完整、清晰的模式，将Go的服务器端渲染能力与HTMX的轻量级前端交互无缝结合，适合构建维护简单、交互体验良好的现代Web应用。

StubHub及其首席执行官埃里克·贝克因涉嫌与大规模“黄牛”有关联，在美国面临一项拟议的500万美元集体诉讼。该诉讼指控StubHub存在“欺骗性做法”和“虚假陈述”，因为它将自身宣传为“粉丝买卖门票的市场”。

根据美国证券交易委员会（SEC）的文件及加拿大广播公司（CBC）的报道揭露，贝克同时经营着一家名为Andro Capital的对冲基金，该基金在StubHub平台上进行价值数百万美元的体育赛事和演唱会门票的大规模转售。原告路易斯·桑奎尼称，消费者对此利益冲突毫不知情，他误以为StubHub是一个中立的市场平台，并在平台上购买了音乐会及足球比赛门票。原告方认为，如果知道真相，他不会接受相关价格和条款。

对此，StubHub的发言人表示无法对法律案件发表评论。

与此同时，StubHub因取消数千张世界杯门票订单而受到严格审查，尽管其承诺“粉丝保护保证”。许多失望的客户称，他们被排除在世界杯比赛之外，且为旅行和酒店支出蒙受损失。此事件已引发美国联邦贸易委员会、加拿大竞争局以及卑诗省消费者保护机构和德克萨斯州总检察长办公室的正式调查或众多投诉。所有指控均尚未在法庭上得到证实。

LeMario：在《超级马里奥兄弟》上训练JEPA世界模型

项目目标与背景

作者尝试从头实现一个名为LeMario的联合嵌入预测架构，并将其应用于《超级马里奥兄弟》游戏。目标是复现类似LeWorldModel的能力，使模型仅从像素和动作中学习世界动态，实现无奖励规划。项目结合了对JEPA架构的学习兴趣和对视频游戏的热爱。

模型架构

LeMario的核心是一个预测架构，通过以下组件处理游戏数据：

• 视觉编码器：将每帧游戏画面压缩为192维的潜在向量。
• 动作编码器：将每5帧内的6个按钮状态序列压缩为另一个192维向量。
• 因果预测器：包含6个Transformer块，利用自适应层归一化注入动作信息。动作通过缩放、偏移和门控三种方式影响预测器，从而动态调整特征。
• 预测目标：预测未来三帧的潜在表示，并使用均方误差损失。
• 正则化：引入SIGReg防止表示坍缩，确保编码器输出的潜在表示保持多样性。

实验结果与初期评估

模型在737,134帧（来自280个 episode，覆盖32个关卡）上训练。评估显示：

• 在单步和五步预测误差上，LeMario显著优于“无变化”基线和“动作打乱”基线。
• 模型成功学习了短期、基于动作的马里奥动态。

规划应用与遇到的问题

作者使用交叉熵方法在模型想象的未来中进行动作规划：

• 初期测试：对于近距离目标，规划结果不佳，马里奥几乎未移动。
• 探针分析：训练一个简单探针发现，潜在向量能很好编码水平位置，但对垂直位置编码较弱。
• 分段目标：将长目标拆分为更小的检查点后，规划效果改善，马里奥能移动更远，但垂直动作仍失败。

根本原因分析

失败暴露了三个核心问题：

1. 表示问题：编码器学习的是预测未来的有用特征（如相机位置、动画状态），而非直接对应可控进度。
2. 视觉相似性：滚动相机导致远距离位置可能看起来相似，模型在潜在空间中难以区分。
3. 环境差异：原JEPA在固定视角、平滑移动的Push-T任务中成功，但马里奥有滚动视角、跳跃、敌人、死亡等复杂动态，且训练数据远少于原论文。

结论与反思

• LeMario未能成为熟练的游戏玩家，但成功学习了短期动作条件动态。
• 教训：复制架构时需同时考虑数据集、环境、评估指标和基本假设。
• 未来研究应早期验证核心假设，建立简单基线，并设计以实际行为为导向的评估。

Dependabot版本更新现已引入默认包冷却期机制：在注册表上发布的新版本至少等待3天后，Dependabot才会提交对应的版本更新拉取请求。此冷却期为默认设置，无需手动配置。

设置冷却期的目的是防御供应链攻击。新发布版本是常见的攻击入口点，恶意或有问题的版本可能在维护者和社区发现前就通过依赖更新引入。短暂的延迟有助于相关风险信号浮现，从而避免合并刚发布的不良版本。

关键细节：

• 仅适用于版本更新：安全更新会立即创建拉取请求，确保关键安全修复不受延迟。
• 用户可控制：可通过项目中的 .github/dependabot.yml 文件的 cooldown 选项自定义时间窗口或完全禁用该功能。

此默认设置适用于 github.com 上所有受支持生态系统的Dependabot版本更新，并将在 GitHub Enterprise Server (GHES) 3.23 版本中生效。

人工智能投资热潮的融资：从现金流到债务

人工智能（AI）投资正在快速增长，在美国尤为明显，目前已成为GDP增长的重要驱动力。这一投资热潮涵盖了数据中心建设、半导体制造设施以及相关的IT设备。自2022年以来，AI相关投资在美国GDP中的占比持续上升，到2025年年中，其相关支出已约占GDP的1%，而整体IT投资占比达到了5%，超过了2000年互联网泡沫时期的峰值。

宏观经济影响

AI投资已成为美国GDP增长的关键因素。在2022年后的三年里，半导体制造设施和数据中心的支出平均每年贡献了0.4个百分点的GDP增长。分析师预测，未来五年数据中心年度支出可能增加1000亿至2250亿美元，使其在GDP中的占比从目前的0.5%上升至0.8%-1.3%。

融资模式的转变

历史上，主要的IT公司通常依靠其高利润业务产生的经营现金流来为投资提供资金。然而，当前AI相关投资的规模空前庞大，加上某些公司自由现金流减少，使得仅靠内部现金流进行扩张的模式难以为继。同时，股权融资因AI估值波动大、成本高且可能稀释股权而显得不及时或不经济。

因此，企业正越来越多地转向债务融资，包括公司债券、租赁安排或贷款，以将成本分摊到时间周期中，并使融资期限与数据中心等资产的长经济寿命相匹配。

私募信贷的崛起

私募信贷正成为AI投资中一个快速增长的融资来源。这类非银行信贷通常由专业投资基金提供，其特点是交易条款定制化、执行速度快、灵活性高，非常适合为大型、重资产的AI项目提供融资。

数据显示，私募信贷基金向AI相关行业发放的贷款存量已从接近零增长至超过2000亿美元，占私募信贷总贷款存量的比例从不到1%上升至约8%。根据预测，到2030年，对AI公司的私募信贷存量可能达到3000亿至6000亿美元。

尽管投资增长迅速，但对单个私募信贷基金而言，AI相关贷款的平均占比仍较低（约5%）。贷款条款（如期限和利差）与传统行业贷款相似，但平均贷款规模更大。

对金融稳定与增长的影响

融资模式向债务的转变给金融体系带来了新的脆弱性。企业杠杆率上升，可能放大冲击，并在AI投资未能产生预期回报时影响金融机构的健康。私募信贷市场快速增长且透明度相对较低，可能加剧风险传导。

最关键的是，债务市场的定价与股票市场的估值之间出现了脱节。私募信贷对AI公司贷款收取的利差与非AI公司相近，这表明贷方认为其风险相当。然而，AI公司的高股价估值却暗示着其未来将产生超额回报。这种分歧意味着，要么贷方低估了AI投资的风险（而其敞口正在显著增加），要么股票市场高估了AI未来能产生的现金流。

历史视角与风险

从历史标准看，当前AI投资热潮的规模并不特别巨大，约为美国GDP的1%，与2010年代中期的页岩油热潮相当，但小于1990年代的互联网投资热潮。然而，历史上投资热潮的结束往往伴随着GDP增长的放缓（平均超过1个百分点），且并未必然带来中期内持续的经济增长。

如果AI投资热情消退并伴随股市大幅调整，其负面溢出效应可能超过以往类似事件。总体而言，AI投资能否持续提振经济增长，很大程度上取决于AI公司能否兑现市场对其未来高收益的期望。

https://www.ft.com/content/3a023b95-66c3-41e1-b0ce-df752a499541

全球升温2050年或达3°C？德国气候新警告解析

德国物理学会与德国气象学会在一份联合声明中发出警告，认为全球升温可能正在加速，并指出地球可能在2050年前升温3°C。这一预测比目前主流研究认为的（考虑现有政策，本世纪末升温约2.7°C，2050年约2°C）更为严峻。

为何预测如此悲观？

• 观察到加速趋势：自工业化以来，升温0.5°C耗时65年，而升温1°C仅用时28年。1.5°C的门槛可能在未来17年内甚至明年被突破。
• 海洋温度异常：过去两年半海洋温度出现急剧飙升。海洋作为缓冲吸收温室气体多余能量的能力可能减弱，将导致大气升温更快。
• 数据支持更差情景：3°C的预测虽非严格意义上的预报，但属于IPCC（政府间气候变化专门委员会）最坏情景的范围内，而近期数据更贴近这一情景。
• 科学认知更新：IPCC最近一份报告已有十年历史，新研究提示气候敏感性可能比之前认为的更高，即相同量的二氧化碳会导致更大幅度的升温。
• 政治行动不足：尽管有全球气候协议，但大气中的二氧化碳浓度仍在持续上升。专家批评全球气候政策“太少、太慢、太迟”。

升温3°C意味着什么？

• 全球影响：气候带将发生巨变，例如撒哈拉沙漠区域可能延伸至西班牙部分地区，植被和降水模式将彻底改变。
• 对德国的具体影响：
  • 夏季极端高温纪录可能达到50°C。全球平均升温3°C并不意味着日最高温只升高3-4度，局部可能升高10度。
  • 将面临更长期的干旱。
• 海岸线变化：长远来看（数十年至一个世纪），海平面可能急剧上升，需要开始讨论从北海和波罗的海低洼沿海地区战略性撤退的计划。例如，汉堡市可能需要计划在2200年将其城市功能向内陆迁移。

学会的呼吁与建议

两位学会负责人强调，尽管担忧被指责为“危言耸听”，但确凿的数据促使他们必须发声。他们提出了10项具体政策要求，包括：

1. 采取决定性行动加强气候保护，以最小化升温风险。
2. 制定适应性战略，保护社会免受气候风险影响。
3. 从现在起就长远海岸线退缩问题进行公开、科学的讨论，以便有充足时间进行谨慎调整。
4. 确保社会获得基于科学的信息，并强调解决气候问题需要与自然科学等多学科及社会展开广泛对话。

总结指出，虽然德国新联邦政府迄今在气候政策上表态不多，但当前或许是重新将该议题提上议程的合适时机。专家强调，人类的气候未来并非无法改变的宿命。