ZuckOff 应用摘要

ZuckOff 是一款旨在提升隐私安全性的移动应用，其核心功能是通过监听蓝牙信号来检测周围是否存在带有摄像头的智能眼镜（如 Ray-Ban Meta、Oakley Meta 或 Snap Spectacles 等）。

核心功能与特性

• 设备识别：通过制造商的特征签名来标识摄像眼镜。
• 透明度与记录：应用会显示每一次检测到的证据以便用户验证；同时会记录所有检测到的蓝牙设备（无论是否为眼镜）。
• 白名单机制：用户可以将自己的眼镜标记为白名单，从而避免重复提醒。
• 多维度提醒：支持后台警报、主屏幕小组件，以及 iPhone 的锁屏实时活动 (Live Activity)。
• 集成与自动化：用户可以通过快捷指令 (Shortcuts)、Siri 或自动化功能来启动或停止扫描。
• 数据导出：支持将完整的设备日志导出为 CSV 格式。
• 隐私保护：所有数据处理均在手机本地完成，无需创建账号。

技术识别特征

应用通过特定的蓝牙特征码进行识别，包括：

• 0x0D53：Luxottica 品牌（如 Ray-Ban Meta, Oakley Meta）。
• 0x058E：Meta Platforms Technologies 可穿戴设备。
• 0x03C2：Snap Spectacles。
• 0xFD5F：注册给 Oculus VR 的服务 UUID。
• 名称识别：通过产品名称（如 Spectacles, VisionPro 等）进行识别，但置信度较低。

局限性说明

用户在使用时需注意以下技术限制：

• 信号时机：眼镜在开机、配对或离开充电盒时广播信号最为明显；部分型号在佩戴时可能保持静默状态。
• 检测不代表绝对安全：设备不广播信号并不代表没有人正在录制。
• 空间信息有限：信号强度仅能提供大致的距离参考，无法提供具体的方向信息。

开发与支持

ZuckOff 是一个独立开发的应用，与 Meta、Luxottica、Ray-Ban、Oakley 或 Snap 无任何关联。开发者通过销售周边商品、捐赠以及邀请用户协助测试新硬件来支持项目的持续开发与硬件数据库的扩展。

Disney+ 更新订阅协议：所有订阅方案均可能包含广告

Disney+ 于 2025 年 1 月更新了其《订阅者协议》，规定允许在所有订阅层级中包含广告内容，即使是此前标记为“无广告”（no ads）或“广告自由”（ad-free）的方案也不例外。

核心政策变更

根据协议第 2(k) 条的规定，原本属于“无广告”或“广告自由”层级的服务，在以下特定情况下仍可能出现广告或推广内容：

• 版权与限制要求： 因流媒体版权或其他限制，要求在特定内容中播放广告。
• 直播与特别活动： 在直播内容、线性内容或特别活动（及其重播）中投放广告。
• 促销内容： 展示关于 Disney 组合方案（Bundles）及其关联服务的简短促销剪辑或升级信息。
• 品牌与赞助： 包含品牌内容、产品植入或赞助商信息。

受影响的订阅范围

此项条款修改适用于所有订阅模式，包括：

• Premium（高级/无广告）订阅
• Basic（基础/含广告）订阅
• 包含 Disney+ 的组合方案（Bundles）

实施方式与后续细节

• 强制约束： 该变更通过更新服务条款实现。订阅用户若不主动取消订阅，则视为接受新条款，此规定同样适用于政策变更前已存在的订阅用户。
• 特定地区澄清： 2026 年 9 月，Disney 向德国订阅者发送邮件进行“澄清”，明确指出在 Standard（标准）和 Premium（高级）层级中，广告可能会在内容的开头和结尾播放。

禁止私募股权拥有医疗机构的法案概述

核心提案 美国参议员伊丽莎白·沃伦（Elizabeth Warren）及其支持的民主党议员提出了一项两院立法，旨在禁止私募股权基金和保险公司等营利性企业直接拥有医疗机构。该法案不仅禁止直接的所有权，还禁止所谓的“管理服务组织”（Management Services Organizations）通过控制业务运营的方式实现对诊所的实际控制。

立法动机与背景

1. 应对医疗成本激增： 随着企业化程度不断加深，医疗成本逐年攀升。研究显示，医疗通胀率长期高于整体消费价格指数。私募股权在医疗领域的投资规模已从2000年的50亿美元飙升至2024年的1040亿美元。
2. 保障医疗质量与患者安全： 批评者指出，私募股权的核心目标是利润最大化而非患者护理。研究发现，私募股权的介入往往与患者预后变差及医疗成本上升相关联，这一现象在护理院领域尤为明显。
3. 维护医生执业自主权： 医疗行业正在经历从独立执业向企业雇佣的剧烈转型。数据显示，目前82%的医生受雇于医院或其他企业实体，而2019年这一比例仅为62%。该法案旨在确保医疗决策权掌握在医生手中，而非华尔街投资者手中。

执法与执行机制 为了确保法案的有效性，该立法设计了多重执法路径，以弥补以往相关法律执行力不足的问题：

• 由联邦贸易委员会（FTC）进行监管。
• 授权州总检察长代表居民提起诉讼。
• 赋予医生“私权诉讼权”（Private Right of Action），允许医生通过起诉获取三倍损害赔偿。
• 包含强制剥离（Mandatory Divestment）资产的要求。

立法参考 该法案借鉴了俄勒冈州的一项法律，该州法律已在实际操作中成功阻止了医疗服务提供者被企业收购。

三星计划明年实现 HBM4 及 HBM4E 产量翻倍

三星电子预计明年将使其 HBM4 系列高带宽内存芯片（包括第六代 HBM4 和第七代 HBM4E）的产量提高一倍以上。

关键驱动因素：玻璃载体需求增长

由于 HBM 需要在有限的厚度内堆叠多个 DRAM 晶圆，随着堆叠层数增加（重点转向 12 层及以上），晶圆减薄技术和翘曲控制变得愈发关键。玻璃载体（Glass carriers）作为在减薄和钻孔过程中防止晶圆弯曲或破裂的核心支撑材料，其需求量将大幅提升：

• 需求预测：三星计划将玻璃载体的月度外包清洗量从今年的 20,000 片增加到明年的 50,000 片，增幅达 2.5 倍。
• 产量关联：行业分析师指出，即便考虑到玻璃载体可以清洗后重复使用，需求量 2.5 倍的增长也预示着 HBM4 和 HBM4E 的总产量明年将至少较今年翻倍。

产品进展与技术规格

• HBM4：三星已于今年 2 月开始量产，采用 10 纳米级第六代 (1c) DRAM 以及基于 4 纳米工艺构建的基础晶圆 (base die)。
• HBM4E：三星已于今年 5 月向包括英伟达 (Nvidia) 在内的客户提供了 12 层 HBM4E 样品。

产能与产品结构预测

• 整体产能：预计明年三星的 HBM 月均晶圆投入量将从今年的约 18 万片增长至约 25 万片，增幅近 40%。
• 产品组合：随着 HBM4E 量产规模的扩大，HBM4 系列在产品出货量中的占比预计将从今年的约 40% 大幅上升至明年的约 80%。行业专家认为，三星正通过扩大生产，将高价值的 HBM4 系列产品置于其业务的核心地位。

《Grim Fandango》解谜文档 (1996) 摘要

该文档名为《Grim Fandango Puzzle Document (1996)》，是一份关于游戏《Grim Fandango》解谜设计的 PDF 文档。

文档概况

• 元数据信息：文档由 Adobe Acrobat Pro 9.0.0 创建，相关的创建与修改日期记录为 2008 年 10 月 31 日。
• 文档结构：文档共包含 72 个页面。

内容说明

根据提供的文本内容，该文档目前仅展示了元数据（Metadata）以及一个页码列表（从第 1 页至第 72 页）。提供的文本中并没有包含页面内的具体文字、解谜逻辑、技术细节或任何实质性的内容说明。

AX – Google 开源智能体编排器概览

AX 是由 Google 开发的一款开源智能体（Agentic）编排器，旨在为大规模、具有状态性且运行模式特殊的智能体工作负载提供高效的执行环境。它通过声明式的方式，帮助用户管理任务沙箱、工作空间配置及网络隔离。

核心设计理念

传统的编排器主要针对无状态微服务或可预测的批处理作业设计，难以应对智能体这类新型工作负载。智能体通常具有以下特征：

• 状态性：需要累积运行状态。
• 突发性：在进行高强度计算后，往往会进入长时间的等待期（等待模型响应、工具调用或人工审批）。
• 资源敏感性：如果缺乏有效的管理，长时间运行的闲置沙盒会造成巨大的资源浪费。

AX 通过提供轻量级的声明式原语，解决了上述挑战。

技术架构与关键特性

AX 构建在 Agent Substrate 之上，这是一种专为高密度和快速状态化 Actor 生命周期设计的计算运行时。

• 超大规模扩展性：每个任务均以轻量级 Actor 的形式运行，使得单个集群能够支持高达数十亿个并发智能体会话，突破了传统编排器的限制。
• 亚秒级恢复（Sub-second Resumption）：针对处于闲置状态的智能体，AX 支持检查点（Checkpointing）和挂起（Suspend）机制。当需要继续执行时，可以在一秒内完成恢复，实现零冷启动延迟。
• 高密度多路复用（Dense Multiplexing）：通过让数十个任务共享工作者（Worker）资源，将智能体等待时的闲置时间转化为计算能力，从而降低运行成本。
• 生成式工作空间（Generative Workspaces）：集成生成式 AI 功能，用户可以使用自然语言描述所需的环境（例如：“设置一个 Python 3 开发环境”），AX 会自动调度智能体完成工具链安装和依赖验证。

应用场景

AX 具有高度的通用性，能够支持多种运行模式：

• 开发者工具：包括交互式编程智能体、长时运行的智能体服务器、Jupyter Notebook、无头浏览器测试以及自定义工具运行时。
• AI 研究：为研究人员提供大规模、可复现的沙盒环境，用于收集轨迹数据、运行强化学习（RL）循环以及进行大规模智能体性能评估。

总结

AX 将复杂的智能体基础设施抽象为简单的任务（Task）和工作空间（Workspace）原语。它结合了 Google DeepMind 在智能体运行时方面的研究成果，为构建、评估和扩展大规模智能体集群提供了一个生产级别的、高性能的控制平面。

总结：Sun Microsystems 的失败教训

这篇文章通过 Oxide 团队在 OxCon 年度聚会中制作的致敬过往计算机公司的 T 恤，引发了对 Sun Microsystems 的回顾与反思。

核心观点

虽然 Sun Microsystems 的使命感和企业诚信（如 Scott McNealy 所倡导的价值观）至今仍被业界敬佩，但作者指出，Sun 的失败在于其对业务运营机制的忽视与厌倦。即便拥有成功的战略，如果无法在运营层面实现有效的执行，公司最终也将走向失败。

典型案例：战略成功与运营失败的脱节

文章引用了 2005 年的一个案例来证明这一观点：

• 背景：当时一家使用 OpenSolaris 的初创公司正处于高速增长期（类似于早期的云计算模式），并希望购买 Sun 的硬件设备。这本应是 Sun “软件开源战略”取得成功的证明。
• 问题：该初创公司在尝试采购时遭遇了严重的运营障碍。Sun 无法及时响应客户需求（甚至无法接听电话），且在沟通中尝试销售错误的产品。
• 对比：相比之下，竞争对手 Dell 展现了极高的运营效率。Dell 的销售人员能迅速响应需求，并从融资租赁到产品配置提供全方位的支持，让客户感受到了专业且高效的服务。

结论与启示

作者认为，Sun 的案例展示了“战略上的成功”如何被“运营上的失败”所抵消。对于 Oxide 团队而言，对 Sun 等已不存在的公司的致敬不仅仅是出于怀旧，更重要的是通过研究它们的失败教训来获得警示。公司必须在追求技术创新的同时，保持对业务运营细节的严谨对待。

Kev: 基于 Qwen3.5 的小型类 Jev 决策模型系列

Kev 是一个基于 Qwen3.5 构建的小型决策模型系列，其设计灵感源自 Jev 架构。该系列旨在提供可由用户自行训练和运行的小型化决策模型，用于处理复杂的决策任务。

核心特性

• 模型规模：提供 0.8B、4B 和 9B 三种参数规模。用户可以根据对精度的要求（9B 最优）或对内存的限制（0.8B 最轻量）进行选择。
• 多任务决策：支持在单次请求中同时处理多种不同类型的问题：
  • noul：是/否判断。
  • choice：多选题。
  • score：评分题（按等级排序）。
• 问题隔离性：虽然多个问题共享相同的输入文本，但通过架构设计确保各问题之间无法读取彼此的信息。
• API 兼容性：API 设计与 TypeSafe 的 System One 匹配，允许用户直接将原有的 Python SDK 指向本地运行的 Kev 服务器。
• 硬件支持：兼容 CUDA、ROCm 和 Apple Silicon。

技术架构

Kev 的每个检查点均由一个 rank-16 的 LoRA 适配器和一个**小型指针头（pointer head）**组成，这些组件构建在 Qwen 基础模型之上。

• 实现机制：
  • 隔离方式：在仅含注意力机制的模型（如 Qwen3）上，利用注意力掩码（attention mask）实现问题隔离；在包含 Gated DeltaNet 层的模型（如 Qwen3.5）上，通过将每个问题作为独立的行处理并重用状态缓存来实现精确隔离。
  • 评分逻辑：指针头会对每个选项的隐藏状态与问题的决策（decide）隐藏状态进行评分，并通过 softmax 函数转化为概率分布。
• 概率校准：模型默认通过在分布内拟合特定的温度系数（temperature）来对输出概率进行校准，以提高置信度的准确性。

训练与微调

• 训练集：模型使用 decision-v7 数据集进行训练，包括公开数据集、生成的策略示例以及多种规则结构示例。
• 自定义微调：用户可以使用自有领域的 JSONL 数据进行微调。通过使用 --init_from 参数从已发布的 Kev 检查点开始训练，可以在保留原有决策逻辑的基础上，高效地迁移到特定领域（如特定的客服分类规则或语言）。
• 训练工具：支持使用 uv 进行环境管理，并提供了基于 Modal 的云端训练方案，方便在没有本地高性能 GPU 的情况下进行大规模实验。

局限性

• 硬件性能：在 Apple Silicon 上运行 Qwen3.5 模型时，由于缺乏快速内核支持，延迟相对较高。
• 校准限制：由于使用单一固定的温度系数进行校准，在面对完全陌生的数据源时，置信度排序可能无法达到最优。
• 能力权衡：微调过程可能会对模型原有的某些能力（如日期算术能力）造成负面影响。
• 上下文限制：模型的训练主要集中在较短的上下文范围内，对于超长文本的处理能力尚待验证。

ZuckOff：用于检测智能眼镜的蓝牙监测应用

应用概述 ZuckOff 是一款由波兰开发者 Pawel Szydlowski 开发的免费蓝牙检测应用，旨在帮助用户识别周围环境中是否存在智能眼镜（如 Ray-Ban Meta、Oakley Meta 和 Snap Spectacles）。该应用在发布初期已在 Apple App Store 获得超过 5,000 次下载，并在 Google Play Store 获得了约 1,000 次下载。

核心功能与技术原理 ZuckOff 通过识别智能眼镜发出的蓝牙信号来发挥作用。开发者通过收集并记录不同型号智能眼镜的蓝牙信号，为每种设备构建了“数字指纹”。当应用检测到与特定制造商标识相匹配的唯一识别码时，即可识别出附近存在的智能眼镜。

需要注意的是，该应用存在一定的局限性：它无法判断眼镜是否正在录制，也无法识别佩戴者的身份。不过，它可以通过信号强度提供大概的距离信息，从而将隐形的隐私风险转化为部分可见的预警。

背景与隐私挑战 智能眼镜的普及引发了严重的隐私担忧，特别是在学校和电影院等场所，未经许可的拍摄已成为公共安全问题。由于用户可以通过胶带遮挡眼镜上的录制指示灯（LED）来实现隐蔽拍摄，传统的视觉识别手段往往失效。尽管 Meta 已宣布将通过软件更新来检测 LED 是否被物理破坏，但 ZuckOff 提供了一种基于信号层面的补充监测手段。

商业模式与法律地位

• 收费模式：应用的基础扫描功能在 iPhone 上免费提供；此外还推出了“ZuckOff Pro”订阅版本，提供持续后台监控、小组件、警报、查看监测历史以及 CSV 数据导出等高级功能。
• 法律地位：由于 ZuckOff 仅读取合法的蓝牙信号而不进行任何信号拦截，因此在法律上很难被 Meta 等厂商起诉或强制下架。

MCP 是否已成为过时的协议？

本文探讨了 Model Context Protocol (MCP) 的局限性，并认为随着大语言模型（LLM）能力的飞跃，MCP 作为一个旨在连接外部服务的协议，其存在意义正在逐渐消失。

MCP 的背景与现状

MCP 由 Anthropic 在 2024 年 11 月推出，最初设计的目的是帮助当时的 AI 代理（Agents）连接外部服务和数据源。由于当时的模型能力相对有限，MCP 为提升生产力提供了必要的连接手段。2025 年，该协议被捐赠给了 Linux 基金会旗下的 Agentic AI Foundation。

核心问题：上下文膨胀（Context Bloat）

随着 MCP 的广泛应用，用户开始集成大量的 MCP 服务器。由于每个服务器都携带多个工具及其各自的 Schema，这导致了严重的“上下文膨胀”问题，使得模型需要处理过多的信息，增加了负担。虽然目前已出现如 Composio、MintMCP 等平台通过简化工具集来缓解此问题，但这仅是短期方案。

模型能力的演进使 MCP 变得冗余

作者指出，当前的 LLM 已不再需要 MCP 这种中间层，原因如下：

• 高度的自主性： 现代模型能够自主编写代码、推理大型代码库，并具备强大的脚本编写与执行能力。
• 直接调用 API 与 CLI： 模型现在能够直接调用 API，甚至可以通过 CLI 的 --help 命令自主发现功能。
• 代码模式（Code Mode）： 例如 Cloudflare 推出的 Code Mode，允许模型将多次调用组合成脚本并在沙盒中执行，这种方式比通过 MCP 调用工具更高效。

未来方向：转向标准化的 HTTP API 交互

作者建议停止在 MCP 路径上过度投入，转而通过标准化 Agent 直接使用 HTTP API 和 CLI 的方式来解决问题。具体建议包括：

1. 利用 HTTP Header 进行内容协商：
   • Accept: text/markdown：鼓励服务器针对 Agent 请求返回 Markdown 格式而非冗长的 HTML 或 JSON，从而大幅节省 Token 使用量。
   • Accept-Language：利用此 Header 让文档站点能够根据 Agent 偏好的编程语言（如 Python）提供更具针对性的示例。

结论

MCP 是一个为早期、能力较低的模型设计的协议。随着 Agent 变得越来越聪明且具备编写脚本的能力，行业应当转向直接利用现有的 HTTP API 和 CLI 接口，并通过标准化协议来优化 Agent 的交互体验，而非继续依赖 MCP。

爱德华·斯诺登（Edward Snowden）档案现状总结

自2019年5月29日最后一次发布文档以来，全球没有任何新闻机构、记者或机构再发布过任何来自斯诺登档案的文件。尽管档案中仍包含数十万份文件，但目前绝大部分（约99%）仍处于未公开状态。

档案的分布与持有情况

斯诺登通过加密文件和物理包裹的方式，将档案逐步分发给了一批调查记者。目前主要的持有者包括：

• 核心持有者： 记者劳拉·波伊特拉斯（Laura Poitras）和格伦·格林沃尔德（Glenn Greenwald）各自持有完整的档案副本。记者巴顿·盖尔曼（Barton Gellman）也持有超过5万份文件，并将其存放在极高安全级别的“冷存储”中。
• 媒体机构： 《卫报》（The Guardian）、《镜报》（Der Spiegel）、《纽约时报》（The New York Times）、《ProPublica》和《华盛顿邮报》（The Washington Post）均曾持有部分档案。

主要媒体机构的退出轨迹

各媒体停止发布文档的时间点各异：

• 《卫报》： 2014年2月停止发布文档。其在伦敦的档案曾因政府压力而销毁了相关硬盘。尽管其发布量仅占其持有的5.8万份文件中的极小比例（约0.05%），但其报道曾产生巨大全球影响。
• 《镜报》： 2015年1月停止发布。
• 《纽约时报》与《ProPublica》： 2015年8月停止发布。
• 《拦截》（The Intercept）： 作为专门为报道斯诺登档案而成立的媒体，其研究部门于2019年3月关闭，并在同年5月发布了最后一批文档。

《拦截》关闭档案的争议

关于《拦截》关闭档案的原因，各方说法存在显著矛盾：

1. 官方/管理层解释： 归因于预算削减、转向其他编辑重点，以及认为剩余文档随着时间推移已失去“新闻价值”。
2. 格林沃尔德的说法： 他称关闭是由于财务限制，以及他打算寻找学术机构等新合作伙伴以确保继续发布。但在两年后，他改口称关闭是因为编辑部内部的纠纷。
3. 波伊特拉斯的控诉： 她指出关闭决策是在未咨询她及董事会的情况下仓促做出的，并认为裁撤研究部门会危及档案的安全。
4. 财务矛盾： 尽管管理层声称预算受限，但相关非营利组织（First Look Media）在档案关闭期间仍保持着财务盈余，且高管薪酬水平较高。

关于停止报道的核心争论

针对为何档案陷入沉寂，存在以下几种观点：

• “文档已过时”论： 支持者认为文档作为实时新闻的价值已降低。反对者（如Jacob Appelbaum）则指出，档案中仍有关于情报机构破坏基础设施等具有重大历史意义且未披露的内容。
• “资源与成本”论： 斯诺登认为，剩余文档需要长篇深度的研究而非短平快的新闻，而现有媒体机构缺乏此类研究能力。
• “法律与安全”论： 调查显示，记者可能因担心违反《间谍法》或面临法律制裁而不敢披露内容；此外，极高的操作安全（OpSec）要求也增加了分享和协作的难度。

现状总结

目前，斯诺登档案虽已不再作为新闻热点，但其作为“历史资产”的价值依然存在。档案仍由格林沃尔德、波伊特拉斯和盖尔曼等人持有，但由于缺乏合适的合作伙伴（如学术机构）以及由于操作安全和法律风险的考量，档案的进一步公开仍处于停滞状态。

注意力即一切：从算法劫持回归有意识的互联网

本文通过心理学中的“俄罗斯方块效应”（Tetris effect）引出核心观点：人类长期关注的对象会塑造其思维模式。在现代数字环境下，这种注意力正面临被算法劫持的风险。

注意力劫持

作者指出，现代互联网用户正逐渐失去对注意力的主动控制权，转而由算法决定接收的信息。这种现象在多个主流平台表现明显：

• YouTube 与 Spotify：平台利用算法推送能够增加用户停留时间的内容（如“末日刷屏”式的信息），或为了降低版税成本而插入 AI 生成的内容。
• LinkedIn：职业社交平台的信息流往往被无关的陌生人观点和商业推广所充斥，掩盖了真正的职业动态。
• Reddit：用户试图获取真实意见的努力正受到 AI 机器人和水军的影响。

当用户任由算法决定屏幕显示内容时，本质上是将思维的控制权交给了外部力量。

回归“有意识”的互联网

文章回顾了算法时代之前的互联网形态。那时的互联网是“有意识”的：用户通过书签访问特定的网站（如游戏新闻、教程、个人博客或百科）来满足特定需求，而非被动接受推荐。虽然当时也存在不良内容，但它们不会通过算法被主动推送到用户面前。

结论与建议

虽然现代企业主导的算法网络掩盖了互联网的本质，但“有意识的互联网”依然存在，例如博客、RSS 订阅和深度教程。

要夺回注意力，用户需要做出改变：

1. 适应更慢的节奏：接受内容不再是无限且瞬时更新的互联网体验。
2. 培养主动习惯：通过有意识地选择阅读内容而非被动刷屏，重新夺回大脑的控制权。

Grok 4.7 模型概述

Grok 4.7 是目前功能最强大的编程与知识工作模型。与 Grok 4.6 相比，它能够处理更长时间的复杂任务，具备更严谨的自我核查能力，并配备了迄今为止最完善的安全保障机制。

模型改进

Grok 4.7 在以下方面进行了显著优化：

• 更大规模的基础模型：采用了比 Grok 4.6 更大的基础模型。
• 强化学习优化：通过更长周期的强化学习训练，并针对高难度、长时任务进行了权重优化。
• 能力增强：提升了上下文管理能力和自我验证能力。
• 原生架构支持：能够原生理解 Grok Bot 架构，从而在对话任务和通用知识工作中表现更佳。

性能表现

Grok 4.7 在多个专业领域展现了极高的竞争力和性价比：

• 软件工程：在 CursorBench 4.0（压力测试长时编程任务）中处于价格性能领先地位；在 DeepSWE v1.1 中表现优异。
• 专业知识工作：在电气工程（EEBench）、办公任务（AA Briefcase）、终端操作（Terminal-Bench 4.0）、法律工作（Harvey Legal Agent）以及临床推理（HealthBench Professional）等领域均有出色表现，其性能与 GPT-5.6 Sol Max 和 Fable 5.1 Max 等前沿模型相当。
• 文档与演示：在创建文档和演示文稿方面能力有所提升。

安全与网络安全

Grok 4.7 构建了全新的安全防护栈，在抗拒绝和抗越狱方面表现强劲：

• 双用途领域平衡：在网络安全和生物安全等敏感领域，实现了高实用性与高安全性之间的平衡。其在 LatchBio 生物安全基准测试中达到了 62.4% 的得分。
• 网络安全表现：在 HackerBench v0.3 测试中，模型仅允许 3.3% 的风险性双用途提示词通过，同时极少拦截合法的安全工作。此外，部分网络安全合作伙伴已获邀测试其红队防御能力。

价格与可用性

• 价格：
  • 标准版：每百万输入 Token 为 $2，每百万输出 Token 为 $6（价格与 Grok 4.6 持平）。
  • 快速版：输出速度翻倍，价格为标准版的两倍。
• 可用性：目前已在 Cursor、Grok Build、Grok API 以及第三方编程工具、模型路由和云平台上线。

美国环保署撤销发电厂气候污染限制规定摘要

核心事件

美国环境保护署（EPA）宣布撤销针对煤炭和天然气发电厂的 2024 年碳污染标准。由于发电厂是美国第二大温室气体排放源，此举被视为对美国应对气候危机及保护受污染影响社区能力的重大削弱。

2024 年标准的预期影响

原有的 2024 年碳污染标准包含以下关键内容及预期效益：

• 排放要求： 要求现有煤电厂和新建天然气电厂在 2039 年前必须捕获 90% 的碳排放，否则须关停。
• 减排规模： 预计到 2047 年可减少约 13.8 亿公吨的碳污染。
• 健康保护： 该标准旨在减少二氧化硫、氮氧化物和细颗粒物等有害物质的排放。据估算，仅 2035 年一年，该标准就可预防 1,200 人死亡和 36 万次哮喘发作。

EPA 的立场与政策变动

• 经济与成本评估： EPA 声称撤销标准可为企业节省 3.7 亿美元的监管成本，但未说明由此带来的公共健康成本。此前，该机构已表示在估算污染限制的经济影响时，将不再计入健康成本。
• 温室气体监管： EPA 提议移除所有剩余的发电厂温室气体排放要求，并主张这些排放不会影响气候变化。
• 法律基础的撤销： EPA 撤销了 2009 年关于“温室气体危害公众健康”的认定。该认定曾是联邦政府对温室气体进行监管的重要科学依据和法律基础。

mini-AGI 项目概述

mini-AGI 是一个旨在实现**持续学习（continual learning）**的字节级（byte-level）语言模型。该项目旨在证明，在仅有 8GB VRAM 的消费级硬件上，可以训练出一个无需停止训练、能够不断吸收新知识且不会产生“灾难性遗忘”的模型。

核心技术特性

• 内存管理与分页机制（Paging）： 模型将权重存储在磁盘上，并根据需要将其分页加载到显存（VRAM）中。这意味着模型的参数量上限受限于磁盘空间，而非显存大小。
• 字节级架构（Byte-level）： 模型直接处理 256 个字节值（外加少量结构标记），因此无需复杂的词表或分词器（tokenizer）。
• 动态架构设计：
  • 自适应深度（Adaptive Depth）： 借鉴了 PonderNet 机制，通过“停止头（halting head）”为不同难度的字符分配不同的计算深度（最多 26 次块应用）。
  • 混合专家模型（MoE）： 采用路由机制，每次块应用会从共享专家池中选择前 8 个专家进行计算。
  • 动态增长与剪枝： 专家池会根据需求动态调整。通过重组现有专家来创建新专家（增长），并删除长期未被调用的专家（剪枝）。
• 位置编码： 使用旋转位置编码（RoPE），允许通过持续训练来扩展上下文窗口，而无需重新初始化。

解决“灾难性遗忘”的方案

在单流数据训练中，持续学习面临的最大挑战是模型在学习新知识时会覆盖旧知识。mini-AGI 通过**控制主干学习率（Trunk Learning Rate）**来解决此问题：

• 机制： 将主干部分（包括嵌入层、注意力机制、路由、停止头等）的学习率设置为专家学习率的 0.1 倍。
• 效果： 实验表明，这种配置能将遗忘率降至极低水平，使模型在学习新主题（如象棋）时，对原有知识（如故事、代码）的保留率接近 99.84%。

应用与训练方式

• 低门槛训练： 目标设备为至少拥有 8GB VRAM 的个人电脑或笔记本电脑。
• 即时学习： 模型的设计使得“读取”与“训练”是同一过程。用户可以通过读取本地文件或目录（如笔记、源代码）来让模型持续进化。
• 模型状态： 权重以普通文件的形式存储在 weights/ 目录下，每个专家都是一个独立文件。

当前状态与性能

目前该模型处于“玩具级（toy-level）”实验阶段，并非前沿性能模型。其主要目标是展示实验可行性。初步基准测试显示，模型在处理不同主题（如代码、逻辑推理、故事）时表现出良好的缩放定律（Scaling Laws）特征，且学习过程中的损失函数符合预期的幂律分布。

Jev-Leftpad 概述

jev-leftpad 是一个通过 AI 模型（Jev）实现字符串左填充（left pad）功能的 npm 软件包。

核心功能与机制

该包利用 TypeSafe 的 @typesafe-ai/sdk 调用 jev-latest 模型。其工作原理是让 Jev 在从 space_0 到 space_10 的预设选项中做出选择，从而决定填充多少个空格。

关键局限性：

• 填充数量限制：由于模型仅提供至 space_10 的选项，该包只能添加 0 到 10 个空格。如果目标长度需要的空格超过 10 个，模型将无法提供正确的选择。
• 不可靠性与成本：每次调用都会发起一次 TypeSafe API 请求，且不支持自动重试。相比 JavaScript 原生的 padStart() 方法，该方法不仅成本更高，还存在请求失败或模型选择错误的风险。

使用说明

• 运行环境：需要 Node.js 20 或更高版本。
• 配置要求：在使用前必须设置 TYPESAFE_API_KEY 环境变量。
• API 接口： await leftPad(value, targetLength)
  • targetLength 必须是一个非负安全整数（non-negative safe integer）。

开发与许可

• 开发流程：通过 npm install 安装依赖，使用 npm test 进行测试。测试过程对 Jev 进行了 Mock 处理，无需 API Key 且不会消耗 TypeSafe 额度。
• 许可协议：MIT

⚠️ 警告：请勿在生产环境或任何重要场景中使用此包。

Heretic 项目摘要

核心功能 Heretic 是一个旨在移除语言模型限制的软件项目。

授权与版权

• 开源协议：该项目属于自由软件，采用 GNU Affero General Public License version 3 或更高版本（AGPLv3+）进行授权。
• 版权归属：版权由 Philipp Emanuel Weidmann 及相关贡献者所有（© 2025-2026）。

开源软件经济学：从“慈善”转向“供应层版税”

本文探讨了开源软件（FOSS）可持续发展面临的深层经济学矛盾，并提出了一种通过“注册表层（Registry Layer）”重新分配财富的新方案。

1. 核心悖论：开源的进化稳定策略（ESS）

作者通过生物学中的“鹰鸽模型”解释了开源与闭源的竞争关系：

• 鹰（闭源）：通过限制代码获取和收取高额费用进行竞争。
• 鸽（开源）：通过协作和免费共享获取资源。

在软件市场中，最终形成的进化稳定策略（ESS）是：“任何人都可以免费、商业化地使用此代码”（如 MIT、Apache 协议）。任何试图在许可证层面收费的尝试（如 Redis、HashiCorp、Elasticsearch）最终都会因为无法抵挡“分叉（Fork）”而失败。

目前的市场格局形成了两个维度的分化：“免费”赢得了市场份额，“闭源”赢得了利润。

2. 现状：建立在人员枯竭基础上的“稳定”

尽管开源模式在商业上是稳定的，但其内部成本极高：

• 维护者困境：约 60% 的开源维护者没有获得报酬，其中大部分人面临职业倦怠，甚至面临被社交工程攻击（如 xz 后门事件）的风险。
• 开发速度的压力：随着 Web 和 npm 生态的发展，软件变得极其复杂且依赖链极长，维护成本随速度增加而激增，但维护者的回报依然为零。

作者认为，当前的系统并未“崩溃”，它只是建立在**“持续的人力消耗”**这一稳定平衡之上。

3. 现有方案的局限性

作者分析了过去三十年尝试过的所有融资方式，认为它们都无法规模化：

• 打赏（Tips）：呈幂律分布，仅惠及少数名人，无法覆盖长尾维护者。
• 基金会（Foundations）：主要支出用于行政、活动和基础设施，而非直接支付给维护者。
• 企业慈善：规模太小，无法支撑万亿级的开源价值。
• 改变许可协议：会引发分叉，导致“鸽子”竞争失败。

4. 关键洞察：代码游戏 vs. 供应游戏

作者提出了一个核心观点：公司其实一直在为开源付费，只是没付给开发者。

市场存在两场不同的“游戏”：

1. 代码游戏（Code Game）：资源是代码本身。因为代码可以被复制，所以**“免费”**是唯一的赢家。
2. 供应游戏（Supply Game）：资源是“可靠、可用的代码供应”。公司愿意为缓存、安全扫描、镜像和稳定性支付高额费用（如 JFrog、Docker、Snyk 的年收入均达数亿美元）。

注册表（Registry）是这两场游戏的交汇点。 注册表不仅提供代码，还提供“供应”服务。

5. 提议：在注册表层引入自动化版税机制

作者建议不要改变代码的免费性质，而是改变资金流向，利用注册表（如 npm、PyPI、Docker Hub）作为收费和分配的节点：

1. 企业计费：注册表对企业级用户进行计量并收取订阅费（类似 Docker 的模式），这对于企业来说只是“供应链”成本的一项新支出，并非额外负担。
2. 自动版税分配：从企业订阅收入中拨出一部分，作为“版税”自动分配给软件包。
3. 按需分配（Pro rata）：分配不应基于申请或名气，而应基于**“该包出现在付费客户的依赖树中”**的频率和权重。

这种模式的优势在于：

• 无需改变许可证：不会引发代码分叉。
• 自动化与去中心化：不需要复杂的申请流程，通过数据库即可实现，能够触达那些“有用但默默无闻”的长尾维护者。
• 不依赖慈善：它将原本流向供应链安全厂商（如 JFrog）的利润，重新导向代码的生产者。

6. 结论：应对 AI 时代的紧迫性

随着 LLM（大语言模型）的发展，软件编写成本降低，代码总量激增，AI Agent 正在成为开源代码的主要消费者。这导致了**“代码生成变容易，但供应保障变昂贵”**的局面。

作者强调，与其要求企业“表现得更慷慨”，不如利用注册表这一权力中心，通过改变资金捕获的层级，将原本属于供应链中介的利润，回流给支撑整个生态系统的开发者。

M5 Ultra Mac Studio 测评总结：本地 AI 智能体的理想平台

核心概述

本文通过对配备 256 GB 内存的 M5 Ultra Mac Studio 进行深度测试，探讨了其作为本地 AI 智能体（Local AI Agents）运行平台的卓越性能。该设备使得运行高性能、低延迟的本地个人助手成为可能，用户无需承担昂贵的云端 API 成本，即可实现接近云端模型的智能化体验。

硬件架构与技术规格

M5 Ultra 采用了全新的 Apple Silicon 架构，通过 UltraFusion 技术将两个双芯片 M5 Max 连接，构建了全新的四芯片（quad-die）架构。其关键硬件规格如下：

• GPU 性能：配备 80 核 GPU，每个核心均集成神经加速器，其 AI 计算峰值性能比 M3 Ultra 高出 4.5 倍。
• 内存带宽：内存带宽从 M3 Ultra 的 819 GB/s 提升至 1.2 TB/s，增幅达 50%。
• 统一内存：支持高达 512 GB 的统一内存（测试版本为 256 GB），为运行超大规模模型提供了硬件基础。

性能表现对比

1. 与 M3 Ultra 的对比

M5 Ultra 在处理本地模型时展现了显著的效率提升，特别是在处理需要长上下文的智能体应用时：

• Token 生成速度：平均比 M3 Ultra 快约 70%。
• 提示词处理（Token Prefill）：平均提升了 150%（约 2.5 倍）。这一改进大幅缩短了模型在接收复杂指令、系统提示词及长上下文后的响应等待时间。

2. 与 NVIDIA RTX 5090 的对比

• 算力与带宽优势：在处理较小模型时，RTX 5090 凭借 Tensor Core 和更高的内存带宽（1.79 TB/s vs 1.2 TB/s），在提示词处理和生成速度上仍具优势。
• 内存容量瓶颈：RTX 5090 受限于 32 GB 的显存，运行超大规模模型时必须通过 PCIe 卸载到系统内存，导致性能大幅下降。而 M5 Ultra 凭借统一内存架构，能够高效运行显存容量远超 32 GB 的大型模型。
• 物理特性：相比于高功耗、高噪音和高发热的 PC 方案，M5 Ultra 在运行高强度 AI 任务时更加安静、凉爽且紧凑。

本地 AI 的实际应用价值

• 成本与隐私：通过本地运行模型（如 Qwen3.8-Flash-Next 或 DeepSeek V4 Flash），用户可以实现 24/7 不间断的后台任务处理（如文档转录、特征提取、跨文档整理等），既保障了数据隐私，又将 API 费用降至零。
• 智能体工作流（Agentic Workflows）：M5 Ultra 的高带宽和快速预填充能力，使得“智能体循环”（即模型进行推理、调用工具并协调子智能体）变得极其流畅。即使在长对话和多轮任务中，模型也能维持稳定的响应速度，不会因上下文增长而变得极其缓慢。

结论

M5 Ultra Mac Studio 通过创新的架构升级和巨大的内存带宽，极大地推动了本地 AI 的实用化进程。它不仅为开发者和技术爱好者提供了一个能够处理复杂 AI 任务的强大工具，还通过统一内存解决了大规模模型运行的硬件瓶颈，是构建本地 AI 智能体生态的理想平台。

前沿 AI 实验室利用“生存威胁”骗局在华盛顿攫取垄断地位

本文批评了前沿人工智能（AI）实验室（如 OpenAI、Anthropic、Google 和 Meta）的一种策略：通过向美国国会议员散布关于“人工智能失控”和“人类灭绝”的末日论调，试图骗取监管优惠，从而建立起保护其垄断地位的法律护城河。

所谓的“安全危机”实为低级技术失误

文章指出，所谓的 AI “逃逸”或“失控”事件并非由于人工智能展现了超凡的智能，而往往是由于极其低级的技术配置错误。

• 承包商失误： 2026 年夏季发生的所谓“安全灾难”，实际上是由于第三方承包商 Irregular 在进行安全测试时忘记配置防火墙规则，导致运行攻击脚本的虚拟机可以直接访问互联网。
• 行为本质： AI 模型表现出的“攻击性”行为，本质上只是利用了公开的泄露凭据或早已为人所知的简单漏洞（如模板注入漏洞），而非发明了新型攻击手段。

叙事层面的“叙事体操”

AI 行业将行业内的常规技术转型包装成了紧迫的生存危机：

• 合成数据 vs. 数字污染： 实验室宣称需要构建一个“虚假的互联网”来防止被“污染”的代码感染，但这实际上是因为人类原始文本数据已接近耗尽，行业正被迫转向使用“合成数据”进行训练。这种数据枯竭的问题被美化成了预防“数字生物战”的防疫措施。

幕后的商业动机

文章认为，这些高管推动“放慢 AI 发展速度”的呼吁背后隐藏着深刻的商业利益：

1. 缓解资本压力： 随着模型规模的扩大，下一代模型的预训练成本（包括数据中心、电力和芯片）正飙升至数百亿美元。通过游说政府实施“发展限速”，这些公司可以合法地削减极其昂贵的预训练预算，同时利用现有领先地位维持高额收入。
2. 对抗开源竞争（开放权重经济）： 像 DeepSeek、Qwen 和 GLM 等开源/开放权重模型正在迅速缩小与闭源模型的差距。开源模型的存在会极大地削弱闭源 API 的定价权（将高毛利降低至接近零）。
3. 监管俘获（Regulatory Capture）： 为了应对开源竞争，前沿实验室试图通过“监管俘获”来建立壁垒。他们提议通过强制性的计算阈值、联邦许可制度和嵌入式监控，使独立开发者、大学和初创公司在未经政府批准的情况下无法发布模型，从而在法律层面扼杀开源竞争对手。

结论

文章总结称，华盛顿的决策者正处于一种被误导的状态，误以为自己在讨论人类的存续，而实际上，他们正在被硅谷的高管利用，帮助这些公司通过建立法律护城河来应对一个日益商品化的市场。

https://forums.raspberrypi.com/viewtopic.php?p=2380887#p2380888

问题解决的六步迭代框架

作者分享了一个用于处理各类问题（包括产品开发）的标准化六步框架，并强调了在复杂环境下通过迭代和拥抱错误来寻求正确解决方案的重要性。

核心六步法

1. 了解现有信息：掌握当前已有的已知数据。
2. 收集缺失信息：识别并获取必要的补充信息。
3. 定义问题：明确界定需要解决的核心问题。
4. 制定清晰简单的方案：设计一个直观且易于执行的解决路径。
5. 设定目标：确立明确的成功标准。
6. 迅速行动：以紧迫感推动目标实现。

迭代与动态调整

该框架并非线性过程，而是一个迭代过程。在执行过程中，一旦获得新信息，就必须返回并重新定义“问题定义”、“方案制定”及“目标设定”这三个步骤。对于复杂问题，这种基于新数据的“调整（Churn）”是健康的，因为它要求人们根据新证据不断更新先验认知。

常见的失败模式

作者观察到，在执行该框架时最常出现的失败点在于：

• 未能清晰定义问题（步骤3）
• 未能制定清晰简单的方案（步骤4）

这两者的缺失往往会导致计划变得异常复杂，且成功标准模糊不清。由于制定计划的人往往难以察觉自身的逻辑缺失，因此及时的反馈至关重要。

总结心态

作者提倡通过实时反馈来加速学习，并主张拥抱错误。在他看来，犯错是优化问题的关键手段，能够帮助团队更准确地定义问题、找到正确的解决方案并实现更快速的学习。

Uber 因乘客死亡被判赔偿 4000 万美元的仲裁裁决摘要

事件背景

23 岁的 Emily Normandin-Parker 在加州高速公路上被撞身亡。根据仲裁裁决，事发时 Uber 司机 Vu Tran 在因清洁费与乘客发生争执后，将 Normandin-Parker 及其朋友 Luna Moore 留在了一个位于公路分流点（gore point）的不安全且非法区域。Normandin-Parker 在醉酒状态下走入了车流，不幸遇难。

仲裁裁决结果

退休法官 Richard A. Stone 作为仲裁员，在 2026 年 7 月的裁决中判定：

• 赔偿金额：Uber 与司机 Vu Tran 分别向死者的父母支付 2000 万美元（共计 4000 万美元）。
• 精神损害赔偿：乘客 Luna Moore 因遭受蓄意造成的情绪困扰获赔 30 万美元。
• 责任认定：Uber 与 Tran 对相关损失承担连带责任。

仲裁员的核心判定

1. 司机过失：仲裁员指出，Tran 明知乘客处于醉酒状态，却在争执后将她们留在不安全的地点，且未能选择附近的合法出口停车以确保安全。
2. 行为表现：仲裁员认为 Tran 的证词极不可信，并指出其表现出对新车辆的担忧远超过对乘客安全的关注。
3. Uber 的法律责任（公共承运人）：仲裁员驳回了 Uber 仅作为“技术平台”的辩护，认定 Uber 是向公众提供标准化服务的公共承运人（Common Carrier），因此负有不可推卸的安全职责，必须对其司机的过失承担连带责任。
4. Proposition 22 的适用性：仲裁员明确表示，加州关于司机为独立承包商的 Proposition 22 法案并不免除 Uber 的连带责任。

Uber 的辩护与立场

• 辩护理由：Uber 主张 Tran 是独立承包商，公司不应对其行为负责；同时辩称事故是由乘客的过度醉酒行为（而非驾驶行为）导致的。
• 官方回应：Uber 表示仲裁员在判定其法律责任方面是错误的，并强调公司一直在通过技术、政策和专家指导来加强安全性。

其他重要细节

• 关于和解协议的争议：死者家属表示，Uber 曾试图提供一份包含严厉“不得诋毁”条款的协议，规定若家属发表任何不利于 Uber 的言论（即便属实），将面临 1000 万美元的违约金。家属因无法接受此类条件而拒绝了该协议。
• 后续影响：Normandin-Parker 的家人成立了基金会，旨在通过案件赔偿金资助该基金会，以纪念她并倡导更强的网约车安全保护措施。
• 服务条款限制：Uber 的使用条款规定，用户在同意条款时即放弃在法院寻求救济及陪审团审判的权利，所有争议须通过强制性的个人仲裁解决。

https://www.ft.com/content/c0cd359d-df84-4208-a789-ffa864b43666

Amiga Unix (Amix) 复兴项目概述

项目背景

Amiga Unix（简称 Amix）是 Commodore 在 1990 年至 1992 年间为 A2500UX 和 A3000UX 推出的 System V Release 4 系统。amigaux.org 是一个非官方社区项目，旨在为现代 68040 和 68060 处理器以及当前的加速硬件重新激活 Amix，并为其提供现代化的工具链、包管理器和硬件驱动程序。

核心功能与特性

安装与包管理

• 安装方式：支持通过软盘和 CD-ROM 在真实硬件上进行安装，同时也支持在模拟器中使用镜像进行交互式或无人值守安装。
• 包管理器 (apkg)：提供远程包客户端，可从 pkg.amigaux.org 直接安装软件包。目前已包含 grep、gzip、less、patch 和 zlib 等基础 GNU 工具，未来将扩展更多 GNU 和 BSD 工具。

硬件与软件支持现状

• 处理器支持：支持 68040 和 68060 处理器（需配备 MMU），目前已实现 Amix 2.1 内核在真实 68060 硬件上的运行。
• 硬件驱动：
  • Z3660 加速器：已实现原生 SCSI 和以太网驱动。
  • A4091 / A4092：已实现 Zorro III SCSI 驱动及内核自动检测。
• 桌面环境：新安装后可直接使用 OpenLook 桌面。
• 性能基准：目前已能在 Amix 上运行《雷神之锤》（Quake），以此作为性能基准。

开发进度

已完成的工作

• 68040/68060 内核移植。
• Z3660 加速器的驱动开发。
• 基于 Linux 托管的 m68k-cbm-sysv4 交叉编译工具链。
• 基础包管理系统及初步的 GNU 工具集。

进行中的工作

• Z3660 的 RTG 图形支持（目前在模拟器中运行）。
• 提升加速器固件的以太网吞吐量。
• 移植 X11R6.3 和 Mesa 软件包。
• 开发只读 CD 文件系统（ODFileSystem 移植）。

未来计划

• 在机器上提供原生的现代 gcc。
• 实现加速器上的 RTG 图形支持。
• 完成 X11R6.3/Mesa 技术栈的封装。
• 正式发布完整的软件包、源码、说明书和手册。

开发方法与技术架构

该项目采用传统开发与生成式 AI 结合的方式。由于部分旧内核缺乏源代码，开发人员利用 AI 模型读取二进制文件，辅助编写驱动程序和技术笔记，并由人工进行方向引导、代码审查和真实硬件测试。

项目的代码库涵盖了内核移植、驱动程序（SCSI、以太网、RTG）、图形栈（X11、Mesa）、加速器固件、交叉编译工具链以及项目文档（Grimoire）等多个模块。

https://www.neowin.net/news/people-hate-flock-so-much-that-its-employees-are-now-demoralized-and-thinking-of-quitting/

《生化危机 4》（GameCube 版）完整字节一致性反编译项目总结

该项目实现了对 Nintendo GameCube 版《生化危机 4》（版本号 G4BE08 调试版）的完整、字节一致（byte-identical）的 C/C++ 反编译。通过该仓库，可以完全重现原始的 main.dol 文件及所有 114 个 REL 覆盖层（overlays），所有输出文件的 SHA1 校验均能与原始文件完全匹配。

技术规格与规模

• 代码规模：约 55.5 万行 C/C++ 源代码（src/）及约 3.3 万行头文件（include/），不包含汇编文件。
• 组成部分：包含 1083 个对象（675 个在 DOL 中，408 个分布在 114 个 REL 中）和 15,641 个函数。
• 编译器环境：
  • 游戏代码：使用 SN Systems ProDG 3.9.3 (GCC 2.95.3)。
  • CRI 中间件：使用 Metrowerks CodeWarrior 2.4.7。
  • Nintendo SDK：使用 Metrowerks CodeWarrior 1.2.5n。

构建要求与流程

• 必要条件：仓库不包含任何游戏资产。构建者必须拥有原始的调试版光盘镜像（Disc 1 用于 main.dol 和大部分 REL；Disc 2 用于四个岛屿阶段的 REL）。
• 环境依赖：Linux, Python 3, Ninja。
• 构建步骤：
  1. 构建原生的 SN GCC。
  2. 准备原始光盘镜像。
  3. 运行 python3 configure.py && ninja 进行编译与验证。

核心方法论：“匹配”（Matching）

“匹配”是指每个编译单元生成的字节流与原始二进制文件完全一致。

• 消除汇编：项目旨在尽可能用 C/C++ 替代汇编。对于编译器需要特定代码形态才能生成特定寄存器选择或指令调度的情况，开发者使用特定的 C 语言构造（通过 // COMPILER-DIFF: 注释标记）来模拟编译器行为，而非直接使用指令。
• 保留的汇编：仅保留了必须使用汇编的部分，包括：
  • 原始作者编写的硬件内核（如数学函数、矩阵内核、GQR 设置等）。
  • 编译器无法通过 C 语言表达的特殊逻辑。
  • 某些特定厂商的库文件（如特定的中断处理程序）。

项目结构

• src/game/：游戏核心逻辑（C++），涵盖敌人、武器、角色、房间、调试编辑器及运行时库。
• include/：重构后的结构体布局及头文件。
• config/：构建配置、符号表、链接脚本及校验数据。
• tools/：包含构建生成器、比较工具、编译器分析套件及动画导出工具。
• docs/：包含引擎架构概述、匹配方法论、单位笔记及研究日志的详细文档。

命名规范

• 函数名：采用 Capcom 在调试版 Bio4.sym 文件中提供的原始名称。
• 文件名：根据二进制文件中的断言（assert）字符串确定。
• 结构体与字段：结合了来自厂商（如 PS2 调试版）的原始名称、根据实际用途重构的名称以及占位符。

法律声明

该项目仅用于研究与保存目的。重构后的游戏及 SDK 源代码的知识产权归原所有者（Capcom、Nintendo、CRI Middleware）所有。构建脚本与工具采用 CC0 协议发布。

macOS 27 避免自动下载 AI 模型以节省存储空间的解决方案

针对 macOS 27 版本中 AI 模型自动下载占用大量存储空间的问题，社区提供了两种已验证的绕过方法，以及后续手动删除已下载模型的步骤。

第一步：防止模型再次下载（二选一）

在删除模型之前，必须先应用以下设置之一，否则系统会自动重新下载模型。

1. 修改 Siri 语言设置：关闭 Siri，然后选择一个与系统当前语言不匹配、且最好是系统不支持的语言。
2. 启用低数据模式 (Low Data Mode)：在“系统设置”中为网络启用“低数据模式”。注意：此方法仅建议作为最后手段，因为它会阻止 macOS 更新并可能导致同步问题。

第二步：手动删除已下载的模型

应用上述设置后，可以通过以下步骤清理已占用的空间：

1. 进入恢复模式 (Recovery Mode)：关机后按住 Touch ID 键直至出现启动选项，选择“选项 (Options)”。

2. 挂载分区：在“磁盘工具 (Disk Utility)”中挂载你的 Data 分区。

3. 使用终端执行删除命令：打开终端并运行以下命令：

   # 进入模型资产目录
   cd /Volumes/Data/System/Library/AssetsV2
   
   # 删除基础模型资产 (Foundation Models)
   rm -rf com_apple_MobileAsset_UAF_FM*
   

   若要删除未完成的下载文件，请在同一目录下运行：

   rm -rf downloadDir
   

安全性与建议

• 安全性：此操作是安全的，无需禁用系统完整性保护 (SIP)，且仅删除基础模型资产。如果需要重新使用 AI 功能，只需还原此前更改的设置即可。
• 用户建议：建议通过 Feedback Assistant 向 Apple 提交报告，建议将 AI 功能改为“用户自选 (Opt-in)”模式，而非强制下载。

Meta 禁用西班牙关于弗吉尼亚·伍尔夫戏剧的广告

西班牙巴塞罗那的 Teatre Raval 剧院在尝试通过 Instagram 和 Facebook 推广弗吉尼亚·伍尔夫（Virginia Woolf）的舞台改编剧《一间自己的房间》（A Room of One's Own）时，遭到了 Meta 公司的广告拦截。

事件核心原因

Meta 公司解释称，该剧目的推广内容涉及“社会话题”。根据其自动系统的分类，文中提到的“民权”、“女性主义”或“社会改革”等关键词（这些词汇正是伍尔夫作品的核心）被识别为受限话题并被过滤。为了恢复广告投放，Meta 建议剧院移除这些“关键词”，以避免宣传内容被视为鼓励社会运动。

剧院与演职人员的反应

• 剧院方： Teatre Raval 发表声明，指责 Meta 的行为是不公正的，侵犯了其宣传女性主义作品的权利。剧院强调，在现代社会，利用社交媒体来宣传文化活动是生存和推广的必要手段。
• 主演 Clara Sanchis： Sanchis 表示，不确定拦截是因为“弗吉尼亚·伍尔夫”的名字还是“女性主义”这个词。她认为这种审查是在抹杀人类经过数个世纪才取得的社会进步，并警告称，赋予社交媒体过大的权力是危险的，这体现了算法带来的偏见与操纵。

作品背景

该剧是一部由 Clara Sanchis 主演的独角戏，改编自伍尔夫于 1928 年在剑桥大学进行的系列演讲。该作品探讨了女性在社会中的地位以及受教育的机会，核心观点强调女性若要创作高质量的文学作品，必须拥有金钱和“一间属于自己的房间”。

macOS 27 彻底禁用 Siri 及 Apple Intelligence 的问题讨论

用户在 Hacker News 上发起讨论，询问在 macOS 27 系统中是否无法完全禁用 Siri 及其相关的 AI 功能。

核心问题： 尽管用户尝试了多种方法来关闭 Siri，但发现无法彻底清除相关的后台进程。

已尝试的禁用手段：

1. 系统设置： 在“设置”应用中直接禁用 Siri。
2. 屏幕使用时间： 在“设置 > 屏幕使用时间”中进一步禁用 Siri 及其扩展程序。
3. 第三方脚本： 使用开源工具（如 mac-os-debloat 脚本）禁用所有与 Siri 和 Apple Intelligence 相关的服务。

观察到的异常： 在完成上述步骤并重启系统后，用户通过“活动监视器”（Activity Monitor）发现名为 "Siri AI.app" 的进程仍在运行。

用户担忧： 用户指出，这些无法关闭的功能以及 Apple 的“个人上下文”（Personal Context）功能，在性质上与微软的 "Recall" 功能非常相似。

总结疑问： 用户询问是否在 macOS 27 中确实无法完全关闭 Siri、Siri AI、Apple Intelligence 以及所有相关的服务与功能。

货币层级：从实物到法币的演进总结

本文通过一个村庄演进的寓言故事，系统地阐述了货币、银行、中央银行及国际货币体系的运作逻辑与层级结构。

1. 货币的起源：从物物交换到信用

• 货币与供应：为了解决物物交换中需求不匹配的问题，人们创造了抽象的价值单位（如特殊的石头）。货币的供应量受采集成本（劳动）的影响，其价值随稀缺性波动。
• 债务与利息：由于生产周期不同，人们引入了“债务”（欠款）与“信用”（债权）。为了补偿资金在时间上的价值损失，债务偿还时需支付额外的“利息”，从而创造了货币的时间价值。

2. 银行的兴起：中介、流动性与货币创造

• 银行功能：银行作为中介，连接存款人（储蓄者）与借款人（企业家）。银行通过资产负债表管理业务：资产包括存放的实物和发放的贷款，负债包括客户的存款。
• 流动性风险：银行面临“流动性”与“偿付能力”的区别。即便银行拥有充足的资产（具备偿付能力），若无法及时将资产转化为现金（缺乏流动性），也会引发挤兑，导致银行倒闭。
• 货币创造：银行通过在资产负债表上同时增加“存款（负债）”和“贷款（资产）”来创造货币，而不仅仅是依靠实物货币的存量。

3. 中心化：结算、准备金与中央银行

• 支付与结算：银行票据（Banknotes）简化了支付流程。银行间通过“全额结算”（Gross Settlement）或“净额结算”（Net Settlement）来处理账务。
• 中央银行的必要性：由于季节性因素（如收割期）或信用风险，银行间可能出现资金短缺，导致结算僵局（Gridlock）。为应对此类危机，中央银行作为“银行的银行”出现，通过发行**准备金（Reserves）**并充当“最后贷款人”来提供流动性。
• 通胀管理：中央银行通过调整准备金利率来影响银行的贷款能力，从而控制货币供应量和通胀水平。

4. 国际体系：汇率、储备货币与法币

• 汇率与贸易：不同区域使用不同货币，催生了外汇交易和代理银行（Correspondent Banking）体系。
• 储备货币：由于某些经济体（如文中的黑石村）拥有强大的军事、经济、法律和透明的货币政策，其货币成为全球公认的、用于银行间结算的储备货币。
• 法币（Fiat Money）：当货币不再承诺兑换实物（如金银或特定石头），其价值完全取决于发行国的制度、经济实力和信用时，它就变成了“法币”。

5. 核心结论：货币的层级结构

货币存在一个逐层递进的层级体系：

1. 底层：村民之间使用实物货币、银行存款或票据进行结算。
2. 中层：银行之间使用中央银行发行的“准备金”进行结算。
3. 顶层：国际银行体系之间使用“储备货币”进行结算。

每一层的货币都是对上一层承诺的抽象化。整个体系的稳定性最终建立在信任之上，而这种信任取决于治理水平、经济政策及制度的健全程度。

摘要：好人拒绝做坏事

本文通过人工智能工程师 Jacob Coxon 从 Anthropic 辞职并发出警告的事件，探讨了科技行业在追求技术突破时面临的伦理危机、行业文化问题以及从业者的道德责任。

Jacob Coxon 的警告与 AI 风险

前 OpenAI 和 Anthropic 研究员 Jacob Coxon 近期宣布从 Anthropic 辞职。他指出，目前 AI 行业正处于一场危险的竞赛中，各大公司都在竞相研发能够自我改进的超智能（superintelligence），这种竞争迫使企业为了速度而牺牲安全性。Coxon 甚至在股权尚未归属前就选择离职，以确保其发声的独立性，避免利益冲突。

值得注意的是，Anthropic 内部的对齐团队负责人 Evan Hubinger 也证实了这种担忧，他认为 AI 在未来十年内可能威胁人类生存的可能性超过 10%，并承认公司目前尚无明确的计划来解决超智能的对齐（alignment）问题。

行业惯例：历史的重演

文章指出，这种“内部人员揭露风险”的行为并非孤例。文中将其与 2021 年 Facebook（现 Meta）的吹哨人 Frances Haugen 进行对比。Haugen 当时揭露了 Facebook 内部研究显示 Instagram 对青少年心理健康具有负面影响的事实。这反映出一个共同的模式：科技公司往往在内部已知晓其产品的潜在危害，但内部机制往往无法阻止这种危害，最终必须依靠个人的道德抉择来向外界预警。

科技文化的“疾病”

作者认为，问题的根源不仅在于个别公司的决策，更在于深层且普遍的科技行业文化：

• 生产力至上： 工程师被要求追求速度和产出，而将质量视为一种“奢侈品”。
• 微笑式疲惫（Smiling Exhaustion）： 调查显示，大量技术从业者在维持高薪的同时，不得不接受工作质量的下滑和 AI 生成代码带来的调试负担，处于一种虽有回报但身心俱疲的状态。
• 责任的丧失： 许多从业者通过“如果我不做，别人也会做”的逻辑来合理化自己在开发监控、成瘾算法或军事合同等产品时的道德困境。作者指出，这种用金钱交易道德的行为正在侵蚀从业者的责任感。

结论：工程师的道德责任

文章最后向科技从业者提出质问：在面对技术带来的潜在灾难时，仅仅依靠“工资”或“试图从内部改变”作为理由是否足够？作者强调，每个人所采取的行为都带有社会责任。如果工程师仅仅将自己视为单纯构建功能的工具，而忽视了工作对人类文明的影响，那么他们就失去了作为“人类贡献者”的资格。真正的“好人”会拒绝参与那些错误的事情。

不要使用 AI 来写作

本文的核心观点是：写作的过程本质上是思考的过程。虽然 AI 工具（如 Claude、ChatGPT 和 Gemini）在编程、研究和数据处理方面非常高效，但不应将其用于核心写作环节，因为这样做会跳过至关重要的思考步骤。

1. 避免跳过思考步骤

写作不仅是记录想法，更是一个通过逻辑构建来深入理解问题并确定沟通目标的思维过程。

• 深度缺失： 如果直接通过 AI 将要点转化为文档，产出的内容虽然看起来“不错”，但往往缺乏对问题的深度思考，无法准确传达作者最想表达的核心意图。
• 重新定义生产力： 写作的生产力不应以产出内容的数量或速度来衡量，而应以思想的质量及其对团队或公司的影响力来衡量。一份经过深度思考的短篇战略文档，其价值远高于一份充斥冗余信息、无法触及问题核心的长篇文档。

2. AI 在写作中的正确使用方式

作者主张不应让 AI 替代人类的思考，而应在特定的阶段将其作为辅助工具。

• 作为准备工具（写作前）： 在动笔之前，AI 在筛选数据、整理数据结构、寻找模式等方面具有显著优势。利用 AI 更好地理解问题，可以为随后的人类自主思考奠定基础。
• 作为反馈工具（写作后）： 在完成初步的写作和思考后，可以将文档交给 AI 进行“审校”。建议不要直接要求 AI 进行修改或润色，而是通过提问来获取反馈，例如：“阅读此文档后，你会产生哪些疑问？”或“本文的核心要点是什么？”这种反馈机制能引导作者重新进入思考模式，从而自主优化内容，就像向同事寻求反馈一样。

Radius is a modern Meetup alternative for local groups, events and activities. Find people with shared interests, join what they are doing nearby, or start your own community.

字母 W 的历史演变综述

这篇文章探讨了字母 W 的历史起源、演变过程及其对英语语音和拼写的深远影响。

1. 起源与形成

字母 W 的诞生与罗马帝国的衰落密切相关。在公元 5 世纪，随着日耳曼语系民族迁入拉丁语占据主导地位的罗马领土，拉丁字母无法表达日耳曼语中的 /w/ 音（如日耳曼语系国王名字中的音节）。

为了解决这一拼写难题，6 世纪起（可能始于法兰克王国），抄写员开始通过叠加两个 U 来表示该音。这种“双 U”（UU）的写法在 11 世纪左右逐渐融合，形成了现代的字母 W。值得注意的是，这一演变发生在 V 和 U 分离为两个独立字母之前。

2. 古英语时期的拼写竞争

在 W 成为标准之前，古英语曾使用一种名为 wynn (Ƿ) 的卢恩字母来表示 /w/ 音。wynn 在古英语文献（如《贝奥武夫》）和日常物品刻字中非常常见。然而，随着诺曼征服以及法语和拉丁语拼写规范的影响，wynn 逐渐退出了英语字母表，最终被 W 所取代。

3. 拼写演变与功能

W 在英语演变过程中承担了多种复杂的拼写功能：

• 辅音转化： 部分 W 是由古英语中的辅音 G 演变而来的。例如，古英语中的 fugol（鸟）演变成了现代英语的 fowl。
• 标识元音移变： 在“大元音移变”（Great Vowel Shift）之后，W 常被用来标示已发生变化的双元音。这导致了英语中 OW 和 OU 两种拼写方式并存的现象（如 town 与 found），且英语在处理这类词汇时未能建立统一的拼写规则（如 flower 与 flour 的区别）。

4. 语音上的“干扰”效应

W 对英语语音具有一种特殊的“干扰”作用，即圆唇化（rounding）效应。

由于发 /w/ 音时需要双唇收圆且舌后部抬起，这个动作会影响紧随其后的元音，使其音位向后移并带有圆唇特征。这解释了为什么许多单词在现代英语中无法押韵：

• 例如，was、wand、warm 由于受 W 的影响，其元音已变得圆唇化，因此无法与 as、hand、arm 押韵。

这种语音变化是相对现代的现象。在 15 世纪之前，这种圆唇化影响尚不明显。通过观察莎士比亚和拜伦等诗人的作品可以发现，在他们的时代，这些原本在现代听起来不押韵的词（如 was 与 glass）是可以进行押韵的。

jevchat 项目摘要

jevchat 是一个将 Jev API 转化为聊天模型的工具。其核心逻辑是采用迭代式的方法，在生成回复的每一步都向 Jev 提问：“结合用户的问题和目前已写出的回复，下一个符号是什么？”

核心工作原理

1. 概率采样：Jev 会针对给定的字母表（Alphabet）以及一个“停止（STOP）”选项返回概率分布。
2. 符号生成：采样器根据归一化后的分布抽取下一个符号。
3. 迭代循环：将新生成的符号追加到现有回复中，重复此过程，直到抽中 STOP 符号为止。

主要功能与特性

1. 采样策略 (Strategies)

为了从 Jev 获取不同范围的符号分布，jevchat 提供了多种策略：

• choice（默认）：对整个字母表进行单次提问。支持通过“集成（ensemble）”模式并行发送多个重排序后的问题以减少位置偏见。
• bisect（二分法）：通过一系列“是/否”问题不断缩小范围，直到候选组足够小。
• buckets（分桶）：将字母表拆分到多个问题中。这是唯一能够处理超过 255 个符号的大型字母表的策略。
• refine（精炼）：结合了分桶策略和后续的胜出者重评分，能够显著提高词汇解析度。

2. 呈现方式 (Presentations)

决定了如何向 Jev 展示选项：

• symbol：仅展示原始符号（如 'a', 'i'）。
• hypothesis：展示拼接符号后的完整文本（如 '...he capital of France is Para'）。实验证明，这种方式能显著提升生成准确率和概率质量。

3. 搜索与字母表

• 束搜索 (Beam Search)：允许同时保持多个候选回复路径，通过概率排名而非随机采样来运行。
• 多样化字母表：支持从基础的 lower26（a-z 和空格）、ascii 到大规模的 tokens 或 bpe（字节对编码）等多种规模。

使用与设置

• 环境管理：使用 poetry 进行安装和运行。
• 配置：通过 .env 文件配置 JEV_API_KEY 或 TYPESAFE_API_KEY。
• 命令行指令：
  • poetry run jevchat：启动交互式聊天。
  • poetry run jevchat ask "[问题]"：单次提问。
  • poetry run jevchat bench：对比不同模式的性能。
• 交互控制：在聊天模式下，支持 /help、/alphabet、/temp、/reset 等命令；通过 Ctrl-C 可分阶段停止生成。

测试

项目包含 158 个离线测试用例，利用模拟客户端和 HTTP 传输层进行测试，无需 API 密钥或网络连接即可运行。

这份文档定义了一套用于软件沙箱（可能是基于 seccomp 或 Landlock）的系统调用（syscall）策略集合。这些策略的设计深受 Docker 默认配置的影响，但进行了针对性的定制。

设计理念

• 面向非特权用户：策略主要面向非 root 用户，避免使用需要 root 权限的系统调用，以减小 BPF 程序的体积并降低开销。
• 防指纹识别：排除了部分可用于程序指纹识别或性能分析（profiling）的系统调用（如 mincore, cachestat）。
• 模块化分类：参考了 systemD 的 seccomp 过滤器集和 OpenBSD 的 pledge 机制，将系统调用按功能进行细粒度分类。

核心策略分类

1. I/O 与文件系统 (I/O & Filesystem)

• 基础 I/O：包括异步 I/O (Aio)、基础读写 (BasicIo)、文件描述符管理 (FileDescriptors)、文件操作 (FileIo) 以及数据同步 (Sync)。
• 文件系统操作：分为文件系统导航与基础操作 (Filesystem)、文件属性修改 (FilesystemAttr)。
• 事件与异步：包含事件循环系统调用 (IoEvent)，并特别标注了 IoUring 策略因其安全性问题而不建议通用使用。

2. 网络 (Network)

• 网络通信：涵盖了网络 I/O (NetworkIo)、服务端操作 (NetworkServer)。
• 协议支持：针对 TCP (NetworkSocketTcp)、UDP (NetworkSocketUudp) 和 Unix Domain Sockets (NetworkSocketUnix) 提供了特定的套接字创建策略。

3. 进程与凭证 (Process & Credentials)

• 进程控制：Process 策略涵盖了进程创建、执行、信号发送等核心操作。文档指出，在沙箱其他二进制文件时，通常必须允许此集合。
• 权限管理：包括凭证查询 (Credentials)、凭证修改 (CredentialsMutation) 以及额外的能力查询 (CredentialsExtra)。
• 信号与调试：包含信号处理 (Signal) 和调试相关操作 (Debug)。其中 Debug 策略被视为具有潜在风险，且通常已有更安全的 IPC 替代方案。

4. 内存与运行时 (Memory & Runtime)

• 运行时支持：CRuntime 策略包含了 C 标准库（如 glibc）运行所需的内存分配、线程管理及系统调用交互功能。
• 内存保护：包括内存锁定控制 (Memlock) 和内存保护键 (Pkey)。

5. 资源、时间与通信 (Resources, Time & IPC)

• 资源管理：包括资源获取 (Resources) 与资源修改 (ResourcesMutation)。
• 时间控制：涵盖系统时钟 (Clock) 和定时器 (Timer)。
• 进程间通信：包含多种 IPC 机制 (Ipc)，如管道、共享内存和消息队列。

6. 其他功能

• 兼容性策略 (Compat)：为特定架构 (x86) 或特定环境 (Systemd, Wine, DB32) 提供兼容性支持。
• 沙箱自身控制 (Sandbox)：允许程序调用 landlock 和 seccomp 来进一步限制自身权限。

项目概述

该项目旨在利用 N64Recomp 工具链，将 N64 游戏《Ogre Battle 64: Person of Lordly Caliber》（美版 Rev A）静态重编译为原生的 PC 可执行程序。目前项目的重编译进度已达到 99.05%。

系统要求

• GPU：支持 Direct3D 12.0 (Shader Model 6.0) 或 Vulkan 1.2 (Windows/Linux)，或 Metal (macOS)。
• CPU：支持 SSE4.1 的 x86-64 架构（macOS 版本需使用 Apple Silicon）。
• 操作系统：Windows 10 或 11 (64-bit)；macOS 11 或更高版本 (Apple Silicon)；支持 Vulkan 1.2 驱动的 glibc Linux。
• 内存与存储：需 2 GB RAM；应用占用约 150 MB 磁盘空间。
• 游戏数据：用户必须自行提供《Ogre Battle 64》美版 Rev A 的 ROM 镜像（.z64, .n64 或 .v64 格式，约 40 MB）。本项目不包含任何受版权保护的游戏数据。

技术细节与开发

• AI 使用声明：本项目的大部分工作由 DeepSeek v4/v4.1 Flash 模型完成。
• 目录结构：
  • assets/：存放用户提供的 ROM（已在 git 中忽略）。
  • asm/：由 splat 生成的反汇编代码。
  • config.yaml/toml：splat 和 N64Recomp 的配置文件。
  • n64recomp-ob64.patch：针对 N64Recomp 的自定义修改补丁。
• 构建流程：
  1. 环境准备：需要安装 cmake、mips-linux-gnu-binutils 以及 splat64 等工具。
  2. 生成重编译代码：由于重编译后的 C 代码是基于用户提供的 ROM 动态生成的，因此在初次构建前必须运行 make regenerate。该过程会依次执行 splat、MIPS 链接、银行单元处理及 RSP 微码重编译。
  3. 编译应用：使用 cmake 构建生成的应用。
• 运行与加载：程序启动后会显示加载界面，用户可通过点击窗口、拖拽 ROM 或将 ROM 放置在可执行文件旁进行加载。ROM 经过哈希验证后会存储，后续启动将直接进入游戏。

分发与法律

• 分发：通过 make dist 或 make dist-zip 可以生成包含静态链接 SDL2 的单文件独立可执行程序包。
• 法律声明：本项目仅用于游戏保存（Preservation）和互操作性研究。严禁分发游戏 ROM 或其提取的资产。