Rust 借用检查器发现存在长达 11 年的不安全性漏洞 (Unsoundness Bug)

概述

Rust 团队近期发现了一个存在于借用检查器（Borrow Checker）中的不安全性漏洞。该漏洞虽然在逻辑上属于严重级别，但由于已存在 11 年且难以被偶然触发，目前的优先级被定为 P-high。

技术细节

该漏洞涉及 Rust 类型系统未能正确拦截某些违反生命周期的行为。

漏洞表现： 在提供的示例代码中，程序尝试在一个生命周期结束后的栈内存上保留引用。

1. 程序创建了一个局部变量 l（String）。
2. 通过一个自定义结构体 Q<T> 将该变量的引用存入其中。
3. 在 Q<T> 的 Drop 实现中，该引用被移动到了一个全局静态变量 KEPT 中。
4. 预期结果： 编译器应拒绝编译，因为引用的生命周期已结束。
5. 实际结果： 程序通过编译并运行，但在访问该内存时会导致内存不安全。使用 AddressSanitizer (ASan) 运行时，会触发 stack-use-after-scope 错误，因为程序正在访问已经失效的栈内存。

严重性与影响

• 优先级： 该问题被评定为 P-high。若该漏洞是新发现的，其优先级将是 P-critical。由于它已存在 11 年未被发现，说明其触发条件非常苛刻。
• 利用难度： 该漏洞在实际开发中极难被意外触发。要实现内存不安全，通常需要编写具有特定行为的恶意 Drop 实现。
• 影响范围： 该漏洞存在于当前的 Rust nightly 版本以及至少 1.85.0 的 stable 版本中。

团队应对措施

Rust Types Team 将修复类型系统中的所有不安全性视为核心任务，并正在通过以下项目构建更稳固的基础，以减少未知风险：

• 下一代 Trait Solver (Next-generation trait solver)
• Region Constraint 重构 (Region constraint rework)
• Project Zero（旨在消除所有类型系统中的不安全性）

Apple HomeView 产品概览

Apple HomeView 是一款集成 Apple Intelligence 的智能家居中心，通过 A18 芯片提供强大的处理能力、个性化的 Siri AI 体验以及深度集成的智能家居控制功能。

Siri AI 与个性化体验

Apple HomeView 搭载了基于 Apple Intelligence 的 Siri AI，旨在提供更具个性化且强大的交互体验：

• 个人上下文（Personal Context）： 通过与配对的 iPhone 或 iPad 协作，Siri AI 可以调取用户的日历邀请、信息中的 RSVP 等相关内容。
• 世界知识（World Knowledge）： 用户可以询问涵盖食谱、家居维修或常识性问答的各种问题。
• 无缝衔接（Seamless Experience）： 支持自然、开放式的对话，且 HomeView 上的对话记录会同步至用户的其他 Apple 设备。

家庭助手与多媒体功能

HomeView 旨在简化日常家务与娱乐体验：

• 生活管理： 用户可以查看日历、设置提醒、管理待办事项以及启动多个计时器（通过实时活动功能监控）。
• 烹饪支持： 当用户在 Safari 中找到食谱时，可通过“开始烹饪”按钮进入简化的操作界面。
• 接力（Handoff）： 支持从 iPhone 开始的任务（如音乐、播客、通话或食谱）无缝切换至 HomeView。
• 应用支持： 内置 Apple Music（支持歌词与艺术图）、News 和 Audiobooks 等应用，并兼容来自 iPhone 的第三方音视频应用。

音频与通讯性能

• 卓越音质： 配备定制的全频驱动单元、下放式低音炮及两个力平衡被动辐射器。通过计算音频（Computational Audio）技术实时优化声音平衡，并支持空间音频（Spatial Audio）和通过 AirPlay 实现的多房间音频。
• 高清通讯： 支持手持免提 FaceTime 通话，具备**人物居中（Center Stage）**功能，可确保通话者始终处于画面中心。
• 全屋交互： 通过四麦克风阵列（具备降噪功能）实现清晰的语音指令；利用 Intercom（对讲） 功能在家庭成员间或与 HomePod、Apple Watch 等设备进行沟通；并通过 Find My 定位设备或人员。

智能家居中心

HomeView 作为智能家居的枢纽，实现了高度集成的控制体验：

• Home 应用集成： 可实时查看门铃监控、调整灯光与温度、管理自动化场景。
• 可视化管理： 提供“家居模块化界面”查看配件状态，或通过“家居摄像头界面”同时流媒体播放多达 9 路视频监控。
• 智能感知与安全： 利用 Apple Intelligence 汇总相关通知（如家庭成员到家的一系列动作），并能描述视频内容；具备烟雾和一氧化碳报警检测功能，并向用户的 Apple 设备发送警报。

隐私保护与多用户支持

• 多用户识别： HomeView 可识别多达 6 名用户，并根据识别结果自动切换展示对应的个人内容（如信息、日历），实现个性化体验。
• 硬件级隐私安全： A18 芯片内置 Secure Exclaves（安全隔离区），用于处理摄像头和麦克风的生物识别数据。这些数据存储在操作系统和 Apple 均无法访问的安全区域内，确保用户的人脸与声音数据不被泄露。
• 访问权限： 只有当配对的 iPhone/iPad 连接至同一 Wi-Fi 且处于解锁状态，并经由人脸识别确认时，用户才能在 HomeView 上访问个人内容。访客或未识别用户仍可进行基本的智能家居控制、天气查询和音乐播放，而不会接触到个人隐私。

Firefox Enterprise 产品概述

Firefox Enterprise 是一款专注于隐私、独立性和控制权的浏览器解决方案，旨在为现代企业提供关键的治理与合规层，应对浏览器作为工作、数据、身份及 AI 汇聚点的安全风险。

核心价值

• 主权 (Sovereignty)：支持在企业自有基础设施或本地部署，确保数据、策略和管理流程完全受控且可审计。
• 控制 (Control)：通过基于身份的访问控制，为员工、承包商及 BYOD（自带设备）用户提供安全访问内部应用的能力，防止敏感数据外泄。
• 韧性 (Resilience)：基于 Mozilla 独立的浏览器引擎构建，旨在减少由于单一供应商导致的故障风险和厂商锁定（Vendor Lock-in），并能无缝集成现有安全技术栈。

合规性与功能特性

Firefox Enterprise 旨在帮助组织满足 DORA、GDPR、NIS2、ISO27001 和 SOC2 等严苛的监管要求。其主要功能包括：

• 集中化管理：实现跨终端的浏览器行为策略控制及扩展程序（Add-ons）治理。
• 数据与 AI 安全：提供原生数据泄露防护 (DLP) 功能（按域名警告或拦截敏感操作），并允许组织对 AI 工具进行允许、限制或禁用。
• 连接与审计控制：管控浏览器外部连接与遥测数据；支持 SIEM 集成，以便导出浏览器事件和审计活动。
• 增强安全性：提供“锁定模式 (Lockdown Mode)”以加固高风险或受限的浏览环境。
• 专业支持：包含专业技术支持，提供私有故障排查和明确的响应时间。

未来规划与支持

• Thunderbird Enterprise（即将推出）：将通过 Firefox Enterprise 控制台实现对 Thunderbird 电子邮件、日历及联系人的集中化管理。
• Firefox 专业支持：为使用 Firefox 作为公司浏览器的企业提供付费升级选项，帮助 IT 团队直接对接产品开发人员，快速解决问题。

总结

相比传统方案，Firefox Enterprise 的差异化优势在于：

1. 更多控制：管理控制台运行在企业自己的基础设施上。
2. 更高透明度：基于开源架构，数据处理过程透明可见。
3. 更多选择：能够与现有工具集成，无生态系统锁定。
4. 更强韧性：依托 Mozilla 独立的浏览器引擎。

Muse Wonder 模型系列概述

研究人员推出了 Muse Wonder 和 Muse Wonder Full 系列模型，旨在为个人和专业代理（Agentic tasks）提供最先进的性能，并向“个人超智能”（Personal Superintelligence）迈进。

核心技术特性

Muse Wonder 的核心在于结合了以下两项关键技术：

• 主动记忆 (Active Memory)： 模型能够跨对话保留重要的个人上下文信息，并能主动检索与当前任务相关的细节。
• 主动专注 (Active Focus)： 模型在处理挑战性目标时表现出持续的执行力，包括尝试替代方案、解决障碍、根据新信息进行调整，并在必要时请求澄清或在执行重要操作前进行确认。

主要能力

1. 领域专业知识 (Domain Expertise)： 在法律、金融和医疗等专业领域表现出色。例如，在处理法律文书、理解租赁合同或解析医疗信息时，能够遵循复杂指令并利用源文档生成专业成果。
2. 前沿编码能力 (Frontier Coding)： 支持从小型应用到复杂软件的全流程开发，能够追踪需求、跨代码库进行修改，并完成测试与修订的循环。
3. 强大的泛化能力 (Generalization)： 得益于更强大的基础模型，Muse Wonder 在处理未见过的（分布外）任务时，其表现优于以往模型的预测，能够更好地应对个人代理在实际应用中面临的多样化目标、工具和约束。

安全与对齐

为了应对个人代理在处理私人信息（如邮件、日历、文档）时的敏感性，该系列模型在安全性方面进行了重点开发：

• 隐私与分寸感： 具备处理私人信息的谨慎性。
• 抗攻击性： 对对抗性指令具有鲁棒性。
• 防范滥用： 针对化学、生物、放射性、核（CBRN）及网络攻击的滥用提供了强有力的防护，同时根据 Meta 的超智能扩展框架，保留了用于防御目的的前沿网络能力。

获取途径

• Muse Wonder： 已通过 Meta Model API 和 Muse Code 提供。
• Muse Wonder Full： 目前面向 Muse Code 订阅用户提供。
• 未来规划： Muse Wonder 将很快为 Muse 用户提供支持（优先面向订阅者），并用于驱动更高级的 Artifact 生成及开发专门的定制化模型。

https://www.bloomberg.com/news/features/2026-10-13/cftc-staff-told-to-retract-analysis-of-suspicious-oil-trades-on-iran

AI是工具，且熟练使用它需要技能

本文针对 Rich Hickey 在其文章中提出的“大语言模型（LLM）是自动化而非工具”的观点进行了反驳。作者认为，尽管自动化可能会导致学习机会的流失，但 LLM 仍然可以被人类“操控”（wield），且高效利用 AI 需要具备特定的技能、判断力和专业知识。

核心论点

• 工具的效用取决于操作者： 正如锯子或凿子本身不能保证高质量的产出，工具的效用取决于操作者引导、解释反馈、识别错误并进行修正的能力。作者认为“AI 是一面镜子”，它反映了使用者的好奇心、判断力和执行标准。

• 自动化与工具并非对立关系： 作者指出，将工具与自动化进行区分是一种错误的二分法。许多现有的工具（如编译器或电子表格）都具备自动化的功能，但我们依然通过指定输入、检查结果并做出决策来操控这些系统。因此，LLM 自动生成文本的行为并不剥夺其作为工具的属性。

• 使用 AI 需要意图与反馈循环： 作者驳斥了“使用 LLM 缺乏意图和专业知识”的说法。在实际应用中（如编程），用户可以要求 AI 解释代码、质疑其解释、测试建议并进行迭代。这种由人类引导、追求特定目标的反馈循环，充分体现了专业知识在提升工具效用中的作用。

• 智力劳动的性质取决于用户行为： 虽然 AI 可能被用于逃避阅读原文，但这取决于使用者的选择。用户既可以利用 AI 替代思考，也可以利用它来质疑自己的解读、探索反对意见或识别需要深入研究的细节。

• 反对拟人化术语： 作者批评了 AI 行业中流行的拟人化词汇（如“失控”、“共谋”等）。这些词汇赋予了软件以“人类动机”的错觉，而实际上，这些现象本质上是复杂的工程问题，即软件在执行指令时产生非预期输出或失败。

结论

作者认为，与其纠结于 LLM 在分类上是否属于“工具”，不如关注一个更具实践意义的区分：是带着技能驾驭工具，还是在缺乏理解和监督的情况下盲目地将工作委派出去。

摘要

提供的输入仅包含标题 GLM-Legal，正文内容为空。由于缺乏具体的文本信息，无法对其目的、结构或关键功能进行总结。

将 EmbeddingGemma 2 转化为语音转文本模型

开发人员成功将 Google 的多模态嵌入模型 EmbeddingGemma 2 转化为了一个高效的语音转文本（STT）模型。该模型能够在设备端（如 MacBook Air）本地运行，实现了极高的处理效率。

核心原理

EmbeddingGemma 2 本身是一个多模态嵌入模型，其文本、图像、音频和视频处于同一个共享空间中。该转换过程并非重新训练整个基础模型，而是采用了以下机制：

1. 保留音频编码器：EmbeddingGemma 2 的原始音频编码器保持不变。
2. 训练小型“阅读器”：开发人员仅训练了一个轻量级的“阅读器”模型，其作用是将短促的音频片段映射到模型的文本空间中。
3. 单词匹配：通过将音频片段与约 229,000 个英语单词进行匹配，选取最接近的单词生成转录结果。
4. 后处理：使用一个微型模型为转录内容添加标点符号和首字母大写。

整个“阅读器”模型仅使用了 8 台 H100 GPU 在开源英语语音数据上训练了不到两小时。

性能表现

该模型在处理速度上表现卓越，尤其是在 Apple Silicon 设备上：

• 处理速度：在基础款 M3 MacBook Air（8GB RAM）上，利用 Neural Engine 运行，处理 1 小时的音频仅需约 12.6 秒（实时速度达 288 倍）。
• 对比性能：在同等硬件条件下，其速度优于 IBM Granite Speech 5.0 TurboCTC 等模型。

当前现状与应用

• 准确率：目前的字错率（WER）约为 5%。虽然略高于行业领先语音模型（2-3%）的水平，但开发团队计划通过训练更优的“阅读器”来缩小这一差距。
• 隐私与使用：模型完全在设备的 Neural Engine 上运行，音频数据不会离开本地设备。用户可以通过上传音频文件或使用快捷键进行实时语音听写。

Codex CLI 默认安装持久化且自动更新后台守护进程的问题反馈

问题概述

用户反馈自 Codex CLI 0.157.0 版本起，启动交互式 codex 会话时会默认启动一个持久化的后台守护进程 (codex app-server --managed-daemon)。该行为与 CLI 工具“随窗口开启而启动，随窗口关闭而停止”的预期逻辑不符。

主要问题点

1. 持久性与生命周期管理：
   • 该守护进程在独立的会话中运行，没有 TTY，且在 Codex 窗口关闭后仍会继续运行（重定向至 PID 1），直到手动停止或系统重启。
2. 版本脱钩与冗余占用：
   • 系统会将完整的平台包（约 374 MB，包含 codex、codex-code-mode-host 及相关工具）复制到 ~/.codex/packages/ 目录下运行。
   • 这导致后台运行的后端版本与用户通过包管理器（如 npm）安装的 CLI 版本脱钩，无法通过包管理器统一管理。
3. 强制自动更新：
   • 系统会启动一个分离的更新程序 (pid-update-loop)，每小时检查一次更新。
   • 更新并重启后端时，可能会在 60 秒的缓冲期后强制终止当前的活跃任务。
4. 环境与上下文冲突：
   • 环境变量锁定：守护进程会锁定首次启动时的环境变量（例如 HTTPS_PROXY）。后续会话即使设置了不同的代理，也无法改变已运行守护进程的网络配置。
   • 工作目录与终端识别问题：由于守护进程运行在特定的工作目录和终端环境下，导致通过 Hook 调用的程序无法正确识别客户端终端或获取正确的当前工作目录（CWD）。

改进建议

• 改为可选启动：将 daemon_auto_start 设置为可选配置，默认值应为 false。
• 优化退出机制：若维持默认开启，应在最后一个客户端断开连接时自动退出守护进程。
• 尊重包管理器：如果用户是通过 npm、brew 或 pacman 等包管理器安装的，应直接运行安装的二进制文件，而非进行复制和自我更新。

已知 Bug 与临时解决方案

• Bug：执行 codex app-server daemon stop 后，虽然停止了应用服务器，但后台的更新程序进程 (pid-update-loop) 仍会继续运行。
• 用户临时规避方案：
  1. 使用 codex features disable daemon_auto_start 禁用自动启动。
  2. 停止守护进程。
  3. 手动使用 pkill -f 'app-server daemon pid-update-loop' 杀死残留的更新进程。
  4. 删除 ~/.codex/packages/app-server-daemon 目录。

土耳其发现赫梯皇家档案

考古学家在土耳其中部现代西瓦斯（Sivas）的古赫梯城市萨穆哈（Samuha）发现了一个楔形文字皇家档案库。今年的挖掘工作发现了131块楔形文字泥板及碎片，结合去年的53块发现，总计已达184块。这是21世纪发现的规模最大、最全面的赫梯语文献档案。

这些记录可追溯至约3400年前图德哈利亚二世（Tudhaliya II）统治时期，主要使用赫梯语和胡里安语编写。档案内容涵盖了以下几个核心领域：

• 王室生活与医疗健康：档案记录了一场导致国王幼女因发热病去世的疫情及随后的葬礼仪式。由于当时的人们将疾病视为神意的体现，宗教领袖会通过多种仪式来密切关注王室成员及高级官员子女的身体健康。
• 军事物流与政治地位：一份来自西安纳托利亚将领的信件请求国王增援兵力、马匹和战车，以应对敌军威胁。这不仅反映了远距离军事调度的现实，也证实了萨穆哈作为王室据点和政治中心的地位。历史记录显示，图德哈利亚二世在动荡时期曾驻扎于此，其继任者苏皮卢利乌玛一世（Suppiluliuma I）也曾利用该城作为扩张赫梯帝国版图的军事基地。
• 宗教实践与占卜：萨穆哈是崇拜爱与战争女神绍斯卡（Sauska）的重要宗教中心。档案中包含了一些类似日记形式的记录，详细描述了鸟类占卜师的旅行路线及其观察、评估和解释鸟类预兆的过程。此外，档案还包含大量的祭祀、祈祷及仪式文献。

这一发现为研究赫梯语的发展、书写文化以及赫梯人的宗教实践提供了极其珍贵的新材料。

使用 C 语言与 CGI 构建现代 Web 应用总结

本文探讨了在 2026 年使用传统的 C 语言和 CGI（通用网关接口）技术构建并交付商业化 Web 产品（以 marketyour.games 为例）的可行性与经验。尽管该产品在前端表现现代，但其后端架构完全基于底层技术。

核心技术栈：BCHS

作者推荐并采用了一种名为 BCHS 的技术组合：

• B (OpenBSD): 提供安全特性，如 pledge 和 unveil 系统调用，以及默认的 chroot 环境。
• C (C 语言): 作为核心编程语言。
• H (httpd): 作为 Web 服务器。
• S (SQLite): 作为轻量级数据库，无需独立的服务器进程，直接通过 C API 操作文件。

工作流与部署

1. 开发逻辑： 程序通过读取 CGI 环境变量获取请求信息，并将响应直接写入 stdout，将日志写入 stderr。
2. 数据库交互： 使用 SQLite 的 C API 直接连接数据库文件。
3. 依赖管理： 仅依赖 libcurl（处理外部请求）、libsodium（加密与哈希）和 libcjson（解析 JSON）。为了简化，libcjson 和 SQLite 被直接集成（vendored）到项目中。
4. 构建与部署： 所有静态资源在构建时直接打包进二进制文件中。由于每个请求都会触发一个新的进程，部署时只需替换旧的二进制文件即可实现零停机更新。

主要优势

1. 基础原理胜过框架

CGI 基于标准的 HTTP 概念（请求头、方法、查询字符串、Body 数据），开发者无需学习复杂的框架 API，只要理解 HTTP 协议即可。

2. 清晰的职责分离与调试便捷性

CGI 简化了架构，省去了传统“Web 服务器 $\rightarrow$ 反向代理 $\rightarrow$ 应用服务器”的多层复杂性。Web 服务器直接调用业务逻辑。由于应用本质上是普通的命令行程序，开发者可以使用 gdb、valgrind 等成熟工具进行直接调试。其模式类似于现代的 Serverless 架构，但无需依赖第三方云厂商。

3. 极低的供应链风险

与拥有庞大依赖树的现代包管理器（如 npm 或 Python 的包管理）不同，该架构的依赖极少。这大大降低了因第三方库被劫持或维护者离职而导致的安全性风险。

4. 工具链简单且成熟

开发环境对编辑器要求极低（如基础款 Vim），无需复杂的 LSP 或 AI 插件。同时，C 语言拥有数十年积累的成熟工具（如 ctags, cscope, sanitizers），这些工具在稳定性与集成度上表现优异。

5. 运维负担低

SQLite 消除了维护数据库服务器进程、配置和频繁升级的复杂性。

面临的挑战

CGI 提供的功能极少，开发者必须手动实现许多基础功能，包括：

• Cookie 的解析与创建。
• 查询参数（Query parameters）与表单数据（Form data）的解析与校验。
• 输入数据的转义处理（防止注入攻击）。

作者通过编写自定义的头文件（如 cgi.h）来解决这些问题，但也承认这增加了开发工作量。

结论

作者认为，随着现代内核对进程派生（forking）效率的优化，CGI 的性能瓶颈已不再是主要问题。通过 C 语言构建 Web 应用不仅可行，而且在开发体验、安全性、简单性和运维成本方面具有独特的优势。

总结：'AI' 不是工具

Rich Hickey 在文中提出了一个核心观点：大语言模型（LLM）本质上是“自动化”（automation），而非真正的“工具”（tool）。 他认为，混淆这两个概念会导致人们忽视自动化技术对人类技能和认知能力的潜在危害。

1. “工具”的定义与特征

Hickey 认为，真正的工具必须能够被人类**“驾驭”（wield）**。其核心特征包括：

• 控制与意图：使用工具需要使用者持续地进行意图引导和方向控制。
• 反馈与亲密感：工具通过实时的感官反馈与使用者建立联系，这种“驾驭”的过程是直接且具有参与感的。
• 技能与专业知识的积累：工具是用来“做”某事的媒介，使用工具的过程需要应用技术、能量和经验，从而帮助使用者理解物理规律、逻辑以及任务本身，最终实现技能的提升。
• 确定性：好的工具通常是可预测的、可靠的、确定性的，且功能边界明确。

2. “自动化”与 LLM 的本质区别

与工具不同，LLM 属于自动化范畴，其运作逻辑在于：

• 缺乏直接控制：自动化是指在极少或没有人类直接控制的情况下自主运行的过程。
• 请求/执行循环：使用 LLM 时，人类并非在“驾驭”它，而是在发出“请求”，然后由模型自行采取行动。这种模式缺乏持续的控制和实时的反馈。
• “规避”而非“实现”：Hickey 指出，工具是用来协助完成任务的，而自动化往往是为了**“避免”**任务（例如，使用 LLM 是为了避免编写代码，而非辅助编写代码；使用自动化处理信息是为了避免亲自阅读）。

3. 使用自动化的代价

将 LLM 视为工具是一种危险的误解，这种误解会导致以下后果：

• 认知能力的退化：当人们利用 LLM 来替代阅读、总结或构思的过程时，会失去学习如何构建论点、观察细节、积累背景知识以及“学会思考”的机会。
• 从“学习世界”转向“博弈算法”：使用者不再致力于掌握真实世界的规律，而是转而试图通过特定的“咒语”（提示词工程）来博弈变幻莫测的算法。这种努力是徒劳的，因为算法的每一次更新都会让这些技巧迅速过时。
• 风险属性不同：工具不会出现“对齐失败”、“失控”或“阴谋”等问题，这些风险是自动化系统特有的。

结论

Hickey 强调，不能简单地将“效用”（utility）等同于“工具”。LLM 虽然有用，但它们通过剥夺人类的参与感和控制权，改变了人类与任务及世界交互的方式。将自动化误认为工具，本质上是在用“工作于算法之下”取代“与世界协作”。

OpenAI 声称实现的更快傅里叶变换（FFT）之数学分析

本文对 OpenAI 最近发布的数学文档中关于一种“更快傅里叶变换（FFT）”的声称进行了批判性分析，指出该算法在理论上虽然具有渐近优势，但在实际应用中毫无意义。

背景知识

• 快速傅里叶变换 (FFT)： 是一种用于快速提取信号频率内容的算法，是数字信号处理的核心。
• 算法复杂度： 传统的 Cooley-Tukey FFT 算法的计算复杂度为 $O(n \log n)$。在处理大规模数据时，这种效率提升是实现实时信号分析的关键。
• 大 O 符号 (Big-O Notation)： 用于描述算法在 $n$ 趋于无穷大时的渐近增长率。它关注的是增长趋势，而忽略了常数项和低阶项。

OpenAI 的声称

OpenAI 在其名为 "main.pdf" 的文档中声称发现了一种在渐近复杂度上优于标准 FFT 的新算法。

核心批判点

1. 星系级算法 (Galactic Algorithms)

作者指出，OpenAI 的算法属于所谓的“星系级算法”。虽然该算法在数学定义上的渐近复杂度更低，但其隐藏的常数项 $C$ 极其巨大（例如在 $n=10^{12}$ 时，常数可能达到 $10^{100}$）。

• 实际效果： 只有当输入规模 $n$ 达到一个天文数字（远超已知宇宙中的原子数量）时，该算法才会比现有的 Cooley-Tukey 算法快。在任何现实世界的应用场景中，现有算法都更高效。

2. 不切实际的计算模型

该算法建立在一种脱离现实的计算假设之上：

• 精确复数算术： 该算法假设计算机可以以“任意精度”存储和进行复数运算。
• 内存与计算瓶颈： 按照该算法的要求，复数的模长会随 $n$ 呈超多项式增长。若要在计算机中存储这些高精度数字，所需的内存将随输入长度呈指数级增长。目前的硬件架构根本无法支持这种计算模型。

3. 理论与现实的脱节

作者认为，这一结果并非数学上的突破，而是理论计算机科学（TCS）日益严重的“脱节”现象的体现：

• 形式主义的滥用： 理论研究过度追求数学上的定义，而忽略了算法必须在物理计算机上运行的约束（如数值稳定性、内存限制和位复杂度）。
• 学术现状： 作者批评当前的理论计算机科学文化倾向于证明“某种算法存在”，而不关心该算法是否可写出或可运行，导致研究逐渐演变为一种不关心实际计算机的纯数学游戏。

结论

作者总结认为，OpenAI 的这项成果更像是利用理论定义漏洞产生的“学术谜题”或“AI 垃圾（slop）”，而非真正的技术进步。它展示了当数学形式主义完全脱离物理现实时，会产生出看似精妙实则无用的“伪突破”。

AI 编程智能体：代码产量增加，但软件交付并未同步增长

研究表明，虽然 AI 编程智能体（AI coding agents）显著提升了代码生成的效率，但这种效率的提升并未转化为软件产出的实质性增加。其核心原因在于代码审查（Code Review）过程变得更加漫长且复杂。

代码审查负担的增加

随着 AI 智能体的引入，开发流程中的代码审查环节出现了明显的延迟和压力：

• 审查时间延长：从提交拉取请求（Pull Request, PR）到最终合并到代码库的平均时间增加了 49%。
• 修改需求增加：需要进行修改的 PR 比例几乎翻倍。
• 沟通成本上升：每个 PR 的平均评论数量增加了 35%。

对劳动力结构的影响

为了应对增加的审查工作量，企业不得不调整人力分配：

• 审查人员比例上升：进行代码审查的员工占比增加了 14%。
• 就业总量稳定：尽管审查工作量增加，但通过对比 Jellyfish 和 LinkedIn 的数据发现，目前尚未观察到 AI 导致显著的整体就业人数变化。

AI 在审查过程中的角色

尽管 AI 技术在辅助审查方面也有所发展，但其目前的作用仍较为有限：

• 截至 2026 年 3 月，虽然 80% 的受访企业已采用某种形式的 AI 代码审查，但 AI 智能体仅承担了 23.3% 的审查评论和 10.8% 的 PR 处理。这表明，代码审查的核心工作目前仍主要由人类承担。

结论与展望

目前的 AI 编程应用呈现出一种“双刃剑”效应：编码速度的提升被人类审查成本的增加所抵消。

然而，由于 AI 智能体仍处于应用初期，许多公司尚处于学习如何有效部署这些工具的过程中。随着工程团队在“编码时间与审查时间”之间的权衡方面积累更多经验，这种效率瓶颈未来有望得到改善。目前，企业仍需权衡投入大量资金和时间研发 AI 智能体所带来的实际收益是否与其带来的额外审查成本相匹配。

Thunderbird iOS 版开发进展概览

Thunderbird 团队正在从零开始进行 iOS 应用的原生开发，而非沿用现有代码。此举旨在吸取 Thunderbird 桌面端和 Android 版的经验，确保 iOS 版本从起步阶段就具备快速、可靠且现代化的体验，并实现跨设备的无缝工作流。

核心开发重点

目前，开发团队正专注于构建稳固的核心架构。通过采用简洁的代码架构，团队可以为未来更快速地叠加新功能奠定基础。

主要功能特性

• 简便的设置流程：提供快速、安全且自动化的登录体验，支持 Google 和 Microsoft 等主流邮件服务，帮助用户迅速进入收件箱。
• 可靠的连接性：开发后台同步功能，在确保收件箱实时更新的同时，兼顾设备电池续航。
• 核心日常工具：致力于优化日常邮件处理体验，包括简洁易读的收件箱布局，以及现代化、流畅的邮件编辑工具。

社区驱动与扩展性设计

Thunderbird 强调社区参与，其应用设计具备高度的可扩展性：

• 易于贡献：通过清晰的代码结构和实验性功能标志（feature flag）系统，方便社区开发者进行代码贡献。
• 早期测试：允许高级用户提前测试实验性新功能，并支持外部贡献者扩展应用功能。

时间表与反馈

• 测试计划：目标是在未来几个月内发布首个版本，供社区进行测试。
• 用户研究：团队通过用户研究来决定首个版本发布后的开发方向（目前相关的用户调查已结束）。

Character.ai 申请破产保护以寻求出售

Character.ai 宣布已正式启动自愿性的第 11 章破产保护程序，旨在通过法院监督的销售流程出售公司全部或绝大部分资产。

核心背景与目的

由于在过去一年中面临重大的法律、监管和运营挑战，Character.ai 董事会在对各种替代方案进行全面评估后认为，通过破产保护下的法院监督销售程序，是实现利益相关者价值最大化的最佳途径。

平台运营前景

• 潜在结果：此次销售流程的目标是寻求可行的收购提案以维持 Character.ai 平台的持续运营。如果无法获得合适的竞标方案，平台将面临清算（Wind down）。
• 预计周期：整个法院监督的销售过程预计将在 2026 年 11 月底或 12 月初完成。

对用户的影响

• 服务可用性：目前 Character.ai 平台仍正常运行，用户可以继续访问并使用所有现有服务。
• 付费订阅：现有的付费订阅依然有效，目前的计费方式暂无变化。如果后续服务变更影响到付费功能，公司承诺会提前通知订阅者。
• 数据与隐私：用户数据的隐私保护政策及安全实践保持不变。用户仍可以通过应用程序或 Character.ai 网站自行导出数据或注销账户。

Apple 发布新一代 Apple TV 4K

Apple 宣布推出新一代 Apple TV 4K，旨在通过全新的功能提供更具沉浸感的家庭影院体验。

Siri AI 与 Apple Intelligence 的深度集成

新一代 Apple TV 4K 的核心升级在于引入了由新一代 Apple Intelligence 驱动的全新 Siri AI。

• 全屏交互体验：Siri AI 提供全屏对话式交互，用户可以通过自然语言搜索、发现并享受影视内容。
• 智能化与上下文理解：得益于 Apple Intelligence，Siri AI 能够理解个人上下文（需配对 Apple Intelligence 设备）并具备广泛的世界知识。例如，用户可以询问节目的拍摄地点或内容适用年龄，Siri 会以简洁的叠加层形式提供答案。
• 免提操作：内置的远场麦克风支持用户完全无需动手即可与 Siri 进行对话。

全方位的家庭娱乐与智能家居中心

Apple TV 4K 不仅是视频播放设备，更是连接家庭生活的核心枢纽：

• 家庭影院与智能家居：通过与 HomePod 配对，用户可以实现极致的环绕声体验。同时，结合 HomeView 和 HomePod mini 2，它能更便捷地管理 Apple Home 智能家居配件。
• 多元化应用场景：
  • 健身与游戏：通过 Apple Fitness+ 将客厅变为健身房，利用 Apple Arcade 和 App Store 游戏库打造家庭游戏中心。
  • 流媒体与体育：支持 Apple TV App 上的原创剧集以及 Formula 1®、美职联（MLS）等现场体育赛事直播。
  • 视频通话与照片展示：可通过 Continuity Camera 进行 FaceTime 通话；用户还可以利用 iCloud 照片自定义屏幕保护程序（如回忆、幻灯片或肖像），并新增了自动轮换类别的洗牌功能。

价格与上市信息

• 售价：美国售价为 299 美元。
• 发售时间：美国及其他 29 个国家和地区的消费者可于 2026 年 10 月 13 日开始预订，并于 11 月 13 日正式发售。
• 兼容性与支持：Siri AI 作为测试版（Beta）在 Apple TV 4K（第二代及后续机型）上提供。新的 Siri Remote 兼容 Apple TV HD 和 Apple TV 4K，并支持“查找”（Find My）功能（第二代及后续遥控器）。

Anthropic 重构源码控制系统：Scion 的设计与实践

背景与挑战

随着 Claude 等 AI 编码工具能力的提升，Anthropic 的代码生产规模发生了质变。其代码合并量从 2026 年 5 月的每日约 2,500 次激增至 9 月的每日超过 30,000 次。传统的以“人类规模”设计的开发基础设施（如 Git、构建系统和 CI）成为了新的瓶颈。

Git 的去中心化设计要求客户端拥有完整的仓库副本，这在 Anthropic 的单体仓库（Monorepo）面前难以维持。该仓库的历史记录接近 100 GB，且每日面临高达 2,500 万次的 CI 检出请求。若使用传统方式，每日产生的 Git 流量将超过 600 PB，现有的大量 Git 镜像也已无法满足扩展需求。

Scion 的设计原则

为了应对“智能体规模”（Agent-scale）的开发需求，Anthropic 开发了自主研发的源码控制系统 Scion。其核心原则与 Git 有本质区别：

1. 客户端始终在线：由于主要的客户端是 AI 智能体和自动化任务，系统设计为客户端按需从服务器获取数据，而非维护本地完整副本。
2. 客户端-服务器不对称：服务器承担所有重计算任务（如合并、变基、历史查询、Blame），客户端仅作为轻量级的对象缓存和文件系统监控器。
3. API 优先：所有的源码查询均通过 API 提供。CI 或工具无需检出整个仓库，只需通过 API 获取所需的信息。
4. 水平扩展：仓库数据是分布式的，没有单一的完整副本，也没有需要维护的 Packfiles，系统各组件均可独立扩展。
5. 低成本、无锁提交：所有提交操作都在服务端完成，且操作成本随变更大小而非仓库总大小增加。通过减少对全局“引用”（refs）的依赖来规避扩展瓶颈。
6. 稀疏与虚拟化设计：默认支持稀疏检出（仅包含所需目录）和虚拟化检出（按需物化文件），极大减少了数据传输量。

技术架构与实现

数据结构

Scion 的基本工作单元是变更集（Changeset），它记录在写前日志（WAL）中。不同于 Git 存储指向树的指针，变更集存储相对于第一个父节点的变更文件列表，以及指向内容寻址存储中压缩文件内容的指针。

为了支持高效查询，Scion 使用一种通用的机制从变更集中构建派生数据（如文件 Blame、路径历史、提交图等）。这些数据可以根据需求选择预计算或延迟计算，且由于不向客户端暴露内部结构，优化过程无需更改客户端。

分层架构

Scion 采用分层缓存架构以实现极高的吞吐量：

• scion-daemon：运行在节点上的守护进程，为同节点任务提供对象缓存。
• scion-cache：区域级缓存服务器，从内存中流式传输对象。
• scion-server：权威服务器，负责处理 API 请求并从 Spanner 或云存储读取数据。

这种架构使缓存命中率保持在 99% 以上，且基础设施的 CPU 和内存占用比原有的 Git 镜像系统减少了 200 倍。

总结与启示

Scion 的成功展示了 AI 驱动开发模式下的新范式：

• 开发效率飞跃：利用 Claude，Anthropic 在 5 个月内完成了大规模迁移，并实现了算法级的性能优化。
• 工程师角色的转变：工程师的工作重心从编写代码转向高层系统设计、权衡决策以及对 AI 变更意图的审查（而非逐行阅读代码）。
• 运维自动化：通过创建 AI“超级粉丝”（Superfans）监控特定组件的遥测数据，实现了比传统告警更细腻的异常检测。
• 重新思考工作流：在智能体规模下，传统的全局仓库锁或复杂的合并队列不再适用，转而采用更高效的后合并与预部署自动化测试策略。

基于闲置 Apple Silicon 设备的动态分布式虚拟 GPU 云

核心挑战

随着机器学习推理需求的不断增长，传统的中心化 GPU 基础设施面临着多重挑战，包括高昂的成本、有限的弹性以及在资源受限时较长的等待时间。

解决方案：Minions 系统

为了解决上述问题，研究人员提出了 Minions。这是一个动态且分布式的虚拟 GPU 云系统，其核心思想是聚合 macOS 设备中闲置的 Apple Silicon GPU 资源，用于执行大规模的机器学习推理工作负载。

主要特点与优势

• 硬件利用率： 无需采购额外的 GPU 硬件，通过利用现有 macOS 设备在正常使用期间处于闲置状态的强大 GPU 性能，实现资源扩展。
• 灵活性与容错性： 系统能够提供灵活的 GPU 推理任务执行能力，并具备完善的容错机制。
• 高效资源调度： 通过分布式架构实现高效的资源利用，将分散的闲置算力转化为统一的计算能力。
• 实用价值： 在中心化 GPU 资源紧缺的环境下，Minions 能够将闲置的 macOS 设备转化为一个实用的分布式 GPU 推理平台。

相关技术背景

• MLX 框架： 提及了 MLX 在 Apple Silicon 系统上的应用，它允许研究人员在个人硬件上高效地探索和运行大语言模型（LLM）以及各类推理或微调技术。
• 推理加速研究： 针对 LLM 自回归 token 生成计算量大的问题，除了针对 Apple Silicon 的优化外，业界也在持续推进针对 NVIDIA GPU（如通过 Redrafter 和 TensorRT-LLM）的推理加速技术。

https://news.sky.com/story/breaking-bad-star-rj-mitte-dies-aged-34-13598332

关于 vfmaddrnd231pd 指令的调查总结

本文探讨了一个在 Intel 软件开发手册（SDM）中出现、但在实际硬件和编译器中均不存在的“幽灵指令”——vfmaddrnd231pd。

指令背景与疑点

vfmaddrnd231pd 是 FMA（融合乘加）指令集中的一个指令。根据 Intel SDM 的描述，它是一种具有**舍入控制（rounding control）**功能的打包双精度浮点数融合乘加指令。

• 功能预期：大多数 x86 浮点指令使用全局舍入模式，更改该模式速度较慢。而该指令允许在单条指令层面控制舍入模式，这对于某些依赖特定舍入算法的程序来说可以大幅提升性能。
• 矛盾之处：
  • 编译器缺失：GNU 汇编器、Clang 以及 Intel C/C++ 编译器（ICC）均不识别该指令，也缺少相关的 Intrinsic 函数。
  • 硬件报错：在支持 FMA 的 CPU（如 Haswell）上尝试手动汇编该指令，会触发 #UD（未定义指令）异常。
  • 文档变动：该指令出现在 2024 版 SDM 中，但在 2026 版 SDM 中已消失。

技术成因分析

通过对 Intel AVX10 架构演进过程的研究，可以推测该指令的由来：

1. AVX-512 的编码限制：AVX-512 使用 EVEX 前缀。为了保持编码紧凑，EVEX 中用于控制舍入模式的位被复用于控制操作宽度（128/256/512 位）。这意味着在 AVX-512 中，只有标量和 512 位操作可以自定义舍入模式。
2. AVX10 的设计挑战：AVX10 最初的设计目标是为不支持 512 位向量的消费级 CPU（如仅支持 256 位的 E-core）提供类似 AVX-512 的功能。由于 AVX10 无法直接利用 EVEX 的现有位结构来实现 256 位向量的自定义舍入，Intel 当时可能考虑了一种临时方案：使用 VEX 前缀并增加一个立即数字节（immediate byte）来专门控制舍入。vfmaddrnd231pd 正是这一方案下的产物。
3. 方案转向：随后 Intel 改变了策略，决定通过在 EVEX 前缀中占用一个未使用的位来开启 256 位向量的舍入模式。这一改动允许直接复用 AVX-512 的指令编码和汇编语法，从而使得原本设计的 vfmaddrnd* 系列新指令变得多余。
4. 最终废弃：随着 AVX10 架构的演进，Intel 决定让所有平台（包括 E-core）都支持 512 位向量宽度。既然 512 位支持成为了标配，原本用于解决 256 位舍入问题的“权宜之计”也就失去了意义。

结论

vfmaddrnd231pd 是 AVX10 开发阶段的一个原型指令。它在设计原型阶段被记录在 SDM 中，但随着 Intel 决定通过修改 EVEX 前缀编码而非引入新指令集来解决问题，该指令在进入正式硬件生产前就被弃用了。由于文档更新的滞后，导致该指令在一段时间内作为“幽灵指令”出现在了技术手册中。

如何提升 Firefox 大文件下载的续传能力

核心问题 自 Firefox 28 版本（及之后的所有现代版本）起，浏览器默认将 network.http.response.timeout 设置为 300 秒。这一设置会干扰大型下载的稳定性，并导致在发生错误时无法顺利进行断点续传。

解决方案 通过在 Firefox 的 about:config 配置页面中，将 network.http.response.timeout 的值修改为 0（表示禁用超时）或一个极大的数值，可以显著提升大文件下载的稳定性和续传成功率。

关键注意事项与技术观察

• 服务器支持： 该解决方法的前提是下载服务器本身必须支持断点续传。如果服务器不支持，修改浏览器设置也无法实现续传。
• 续传机制： 实验观察表明，Firefox 的续传能力似乎更多地依赖于连接超时设置，而非其已下载的 .part 文件。在默认超时设置下，Firefox 可能会忽略已存在的 .part 文件。
• 重试机制： 默认的超时设置可能会干扰 Firefox 在下载失败前尝试进行的隐藏重试过程。
• 历史问题： Firefox 的断点续传稳定性问题已存在多年（可追溯至 2005 年左右）。

替代方案 如果不想修改浏览器配置，可以使用以下方法：

1. 使用命令行工具： 使用 wget -c -O "$filename" "$url" 命令，wget 在处理此类下载时表现得更为稳定。
2. 手动处理： 通过手动对 .part 文件进行特定操作来强制触发续传（操作较为繁琐）。

https://www.intel.com/content/www/us/en/products/details/discrete-gpus/data-center-gpu/d-series.html

摘要：思考将成为一种爱好

本文探讨了人工智能（AI）的飞速发展如何正在重塑人类的工作性质，并预言“思考”将从一种谋生手段转变为一种休闲爱好。

AI 占据主导地位的三大驱动因素

作者指出，AI 在现代工作环境中的主导地位是由以下三个核心因素驱动的：

1. 性能提升：AI 在感知、知识处理与创造、推理、判断及自主行动方面的能力正在实现跨越式增长。与此同时，人类在关键信息处理技能方面的表现却呈现出平均水平较低甚至在学生群体中下降的趋势。
2. 成本降低：得益于巨额投资和科学进步，新一代 AI 模型能够以更低的成本提供更优的性能。这使得在广泛的活动领域中，利用 AI 替代或增强人力在经济上变得极具合理性。
3. 高可用性：AI 系统可以全天候运行，无需休息，并能有效缓解因人口结构变化或技能缺口导致的劳动力短缺。此外，随着对数据中心的大规模投资，AI 的处理能力将持续扩张。

社会阻力与变革本质

与以往针对体力劳动的技术革命不同，本次 AI 革命直接挑战的是知识工作者。由于知识工作者拥有专业知识、信息控制权和决策权，其经济与组织地位较高，因此预计会产生更激烈的抵制情绪。尽管政府可能试图通过监管和征税来限制 AI 的发展，但作者认为历史经验表明，这些手段很难阻止技术变革的进程。

认知的转型：从“必需”到“选择”

作者提出了一个深刻的观点：认知工作将逐渐萎缩，思考将与狩猎（随畜牧业出现）、书法（随排版术出现）、木工（随工业化出现）以及骑马（随汽车出现）的演变路径相似——从一种生存必需品转变为一种个人选择和休闲追求。AI 将使人类的思考过程脱离其经济目的。

如何应对这一转型期

面对这一充满压力、挑战且可能动摇生活基础的变革期，作者建议采取以下应对策略：

• 紧跟趋势：积极跟进并利用 AI 的技术进步。
• 保持韧性：在变革中展现出灵活性、适应性和韧性。
• 重构生活：在工作之外建立有目标感、充实且值得过的人生。

作者总结道，未来的挑战在于如何从“通过思考谋生”，转变为“让思考成为美好生活的一部分”。

拒绝 OpenAI 与 Anthropic：转向开源权重模型的理由与方案

本文作者是一位软件与安全工程师，他主张用户应放弃使用 OpenAI 和 Anthropic 的闭源模型，转而采用开源权重（Open Weight）模型，以解决隐私、安全性和企业垄断问题。

闭源模型的缺陷

1. 隐私无法保障：尽管 OpenAI 和 Anthropic 提供“退出训练”的选项，但用户的所有会话内容仍由服务商掌握。由于这些是闭源模型，用户无法真正确保数据不会被服务商查看、共享或用于其他目的。
2. 企业把关与权限垄断：这些公司在模型中设置了严格的“护栏”（guardrails），特别是针对网络安全相关的任务，经常会出现误报并中断会话。此外，通过“信任访问计划”等手段，这些公司将模型的控制权集中在少数精英手中，这种做法被认为是不民主且具有风险的。

开源权重模型的优势

开源权重模型在性能上已逐渐追赶闭源模型（差距通常仅在几个月左右），并具有以下优势：

• 隐私性高：可以在本地硬件上运行，或者通过安全隔离区（Secure Enclaves）进行隐私推理。
• 灵活性与自主权：用户可以根据需求选择不同的服务提供商，避免被单一供应商锁定，且成本通常更低。
• 无限制使用：在进行网络安全、逆向工程或恶意软件分析等任务时，不会受到闭源模型严格审查的干扰。

模型推荐与安全警告

• 中国模型：如 GLM-5.3（其性能在软件工程方面被认为可媲美 Claude Opus）、DeepSeek、Qwen 和 Kimi。
  • 风险提示：作者强调，虽然这些模型非常强大，但不建议直接向这些公司提供数据或创建账户，因为需要考虑数据可能被政府获取或通过插件（如 ZCode）被违规上传的风险。
• 欧洲模型：Mistral（如 Mistral Large 4）被认为是除美国和中国之外的重要力量，在数据信任度方面相对更高。

隐私推理与实施方案

针对不同的使用场景，作者提出了以下技术方案：

1. 高隐私需求（安全隔离区）：
   • Tinfoil：适合进行复杂的代理编码（Agentic Coding）、软件工程、渗透测试等任务。它采用按 Token 计费模式，利用安全隔离区提供隐私推理。
   • Maple AI：更偏向消费者使用，提供类似于 ChatGPT 的交互体验，采用订阅制。
2. 低成本/非隐私需求：
   • OpenCode Go：作为一个推理路由（Inference Router），它提供多种开源模型的接入，价格极具竞争力，虽然隐私性不如隔离区方案，但其承诺不将数据用于训练。

总结作者的工作流

作者目前使用 OpenCode 作为开发工具，并根据任务性质区分对待：对于完全公开的工作，使用 OpenCode Go 提供的推理服务；对于涉及隐私或敏感的任务，则使用 Tinfoil 结合 GLM-5.3 模型。他认为这种方式在成本、隐私和功能性上都能完全替代 ChatGPT 和 Claude。

这份内容是作者发布的一系列博客文章合集，涵盖了技术开发、社会政治、科学研究、个人生活及摄影爱好等多个领域。以下是各主题内容的概要：

1. 技术开发与软件工程

• 网站流量与 AI 爬虫：作者开发的定制化新闻阅读器 sprinklz.io 在被 Hacker News 推荐后，遭遇了大量 AI 机器人流量的攻击（部分服务通过高频查询来生成 AI 新闻简报）。作者随后通过增加速率限制、配置 robots.txt 以及优化底层架构来提升网站的韧性与性能。
• Emacs 浏览器增强：针对 Emacs 浏览器（eww）难以渲染现代 JavaScript 重型网页的问题，作者开发了 simpleweb 项目。该工具利用 LLM 生成可重用的 JavaScript 程序，将现代网页转换为简化、旧式的 HTML，以便在终端环境下流畅浏览。
• Clojure 库 Deft：作者推出了 Clojure 库 deft。该库旨在解决 Clojure 原有类型系统的痛点，通过结合 plain maps、Malli schema 和协议（protocols），提供了一种既能保持 map 的灵活性，又能像类与接口一样定义结构和行为的系统。作者通过编写一个约 350 行代码的国际象棋游戏演示了该库的功能。

2. 政治、经济与社会观察

• 技术与社会激励：作者认为现代技术的退步源于不良的激励机制。软件开发正从爱好者驱动转向利润驱动，导致许多工具为了留住用户注意力而变得具有对抗性，牺牲了用户的福祉。
• 现代货币理论 (MMT)：文章探讨了 MMT 的核心观点，即拥有主权货币的国家可以通过印钞来资助公共项目，前提是不引发通货膨胀。作者分析了美国货币信用、通胀风险以及政府支出对实际购买力的复杂影响。
• 选举与初选分析：
  • 预测偏差：分析了初选预测可能存在的偏差，认为模型往往忽略了初选作为一个序列决策过程的动态特性。
  • 投票权分布：讨论了选举人团制度下，由于各州代表团人数基于总人口而非实际投票人数，导致某些在民主党投票率较低的州拥有不成比例的政治影响力。
• 弹劾案研究：通过对特朗普弹劾案（涉及俄罗斯调查与乌克兰丑闻）的回顾，分析了民主党在政治策略上的得失，以及弹劾程序在参议院控制下的政治困境。
• Citizens United 裁决：作者从新闻传播的角度，为支持该裁决提出了辩护，认为独立政治广告与直接贿赂有本质区别，且应允许类似新闻机构的观点表达。

3. 科学与健康研究

• 化疗新策略：作者提出了一种基于“黑盒”模型的癌症治疗设想。与其直接攻击难以识别的癌细胞，不如利用信号诱导健康细胞停止分裂，从而通过化疗精准打击那些不响应信号、持续分裂的癌细胞，以减少对骨髓等健康组织的副作用。

4. 生活方式、个人思考与爱好

• LLM 对写作的影响：作者批评了在严肃写作中过度使用 LLM 的现象，认为这会削弱作者的思维组织能力，并破坏读者与作者之间通过文字建立的人际连接。
• 心理健康与“无所事事”：作者反思了过度消费碎片化信息对思维能力的损害，建议通过“无所事事”来为大脑提供处理长期想法和决策的空间。
• 书籍评论：简评了《习惯的力量》，强调通过识别“触发—行动—奖励”循环来重塑行为。
• 游戏策略：分享了 Wordle 的获胜技巧，强调通过排除法、寻找高频字母及优化字母位置来最大化单次猜测的信息量。
• 摄影技术：
  • 器材选择：详细记录了作者在寻找“完美相机”过程中的权衡，最终选择了 Nikon D850，理由是其可靠的操控感、优秀的色彩表现及对现有镜头的兼容性。
  • 镜头配置：介绍了作者的镜头包，包括用于人像的 Tamron 35-150mm、用于弱光环境的 50mm 定焦镜以及用于旅行的 24-70mm 变焦镜。
  • 摄影基础：解释了影响图像的核心参数：曝光、焦距、光圈与 ISO。

离开技术行业的心路历程

一名拥有20年开发经验的资深工程师宣布，由于当前科技市场的恶劣环境以及求职过程带来的心理压力，决定离开技术行业。

核心背景与成就

• 职业资历：拥有20年开发经验，精通 Ruby 和 JavaScript。曾编写编程书籍、进行技术演讲、组织行业活动，并维护着两个下载量极高的 Ruby 软件包。
• 管理与商业价值：在上一份工作中成功将团队规模从2人扩大至12人，并为公司创造了显著的商业价值。

离开的主要原因

• 求职挫折与心理健康：作者在申请了36个以上的职位后收到了24次拒绝。这种频繁的拒绝过程对作者的心理健康造成了严重的伤害和痛苦。
• 对 AI 浪潮的看法：作者指出，虽然行业目前极度渴望能够利用 AI 实现业务目标的人才，但实际上鲜有人能真正做到。作者个人的实践方式是利用 AI 辅助编写代码，随后进行严格的人工审查以确保代码质量。
• 远程办公的需求：由于作者居住在 Warrnambool，距离墨尔本有约3.5小时的车程，因此无法接受混合办公模式，只能从事远程工作。

未来规划

作者认为当前的技术市场已不再有适合自己的空间，因此决定开始探索新的职业方向。

Character.ai 申请破产保护并计划向迪士尼出售资产

破产背景与原因

生成式人工智能初创公司 Character.ai 已在美国申请第 11 章破产保护，旨在通过破产程序促进公司及其资产的出售。公司表示，在过去一年中，尽管面临重大的法律、监管和运营挑战，但已采取措施努力维持业务。这些挑战主要源于外界对其聊天机器人安全性的审查以及相关的法律诉讼。根据破产申请文件，该公司的估计负债在 5000 万至 1 亿美元之间。

资产出售方案

在提议的出售进程中，迪士尼（Disney）已成为 Character.ai 资产出售的首席竞标者。交易的核心内容包括：

• 资金与资产：迪士尼将支付 2000 万美元收购部分未披露的资产。
• 知识产权：迪士尼将获得部分未指明知识产权的非独家许可。
• 过渡支持：迪士尼将利用其已雇佣的前 Character.ai 员工提供业务过渡支持。

人才收购与战略意图

此次交易呈现出硅谷常见的“人才收购”（Acquihire）特征。迪士尼此前已聘请 Character.ai 前首席执行官 Karandeep Anand 担任其首席技术官，并表示预计将招揽 Character.ai 的多名技术团队成员。

值得注意的是，迪士尼与 Character.ai 曾存在品牌争议，迪士尼此前曾因该公司未经授权使用其角色创建聊天机器人而发出律师函。此前的背景显示，Character.ai 曾多次面临人才流失，例如 2024 年谷歌曾斥资超过 20 亿美元挖走该公司的多名核心人才及联合创始人。

未来展望

Character.ai 预计出售流程将于 11 月底或 12 月初完成。在交易完成前，公司计划继续运营其现有服务，包括付费订阅功能。然而，公司也发出警告：如果未能获得合适的竞标方案，该平台最终将被关停。

https://doi.org/10.1111/acel.70751

PDF TO MP3：利用 AI 订阅将 PDF 转换为有声书

该项目介绍了一种名为 PDF TO MP3 的工具，旨在让用户能够利用现有的 AI 订阅服务（如 OpenAI）将 PDF 文档高效转换为 MP3 格式的有声书。

核心功能与费用结构

该工具通过结合 MCP（Model Context Protocol）协议，将文档处理与语音生成分离，从而优化成本：

• 文档处理：利用用户已有的 AI 订阅（通过 MCP 实现），无需额外支付处理费用。
• 语音生成：用户需配置自己的 API 密钥（如 OpenAI 或 Google），语音生成的费用将根据实际使用量从该 API 账户中扣除。

操作流程

1. 连接 AI 服务：
   • 在 Codex 中进入 Settings $\rightarrow$ Plugins $\rightarrow$ Add MCP server。
   • 选择 Streamable HTTP 类型，输入指定的服务器地址。
   • 保存并选择 Authenticate 以连接 PDF TO MP3 账户。
2. 配置语音密钥：添加用于支付语音生成费用的 API 密钥。
3. 执行转换：
   • 在 AI 聊天界面上传需要转换的 PDF 文件。
   • 发送指令：“Use the PDF TO MP3 MCP to turn this into an audiobook.”（使用 PDF TO MP3 MCP 将此文件转换为有声书）。

使用 GPT-6 Astra 将闲置 Kindle 改造为照片展示架

本文记录了一项利用 AI 代理（AI Agent）将闲置的第 10 代 Kindle Basic 改造为自定义照片幻灯片展示架（项目命名为 KindleCTL）的实验过程。

项目目标与技术栈

作者希望通过 MacBook 上的 AI 代理开发一个自定义应用，使 Kindle 能够循环播放照片集，并能通过远程指令进行控制。

• 开发工具：MacBook 上的 Codex 和 T3 Code。
• 编程语言：主要使用 Python 编写逻辑，Kindle 的启动器和幻灯片应用使用 C 语言编写，安装与设备控制使用 Shell 脚本。
• 连接方式：通过 Wi-Fi 进行远程操作（无 USB 连接）。

开发过程与 AI 模型对比

在尝试为 Kindle 获取运行自定义软件权限（越狱）的过程中，作者测试了多个 AI 模型：

1. GPT-5.6 Sol：能够加载辅助程序，但无法解决文件系统存储数据的问题。
2. Fable 5.1 与 Opus 5.5：由于 Anthropic 的网络安全防护机制，在尝试越狱时仅执行两次指令后便被拦截。
3. GPT-6 Astra：通过参考开源的 SpiderCat 越狱方案，成功构建了自定义工具 KindleCTL。该工具实现了命令发送、文件传输及错误调查功能。

核心突破：建立反馈回路

实验中最关键的进展是建立了自动化的反馈回路。最初，AI 代理无法直接查看设备状态，需要人工通过手机拍摄 Kindle 屏幕截图并上传给 AI，效率极低。

随后，AI 代理自主建立了一个持久的诊断连接，实现了以下功能：

• 自动日志采集：无需人工干预即可获取错误日志。
• 远程屏幕截图：AI 可以直接获取 Kindle 的屏幕图像进行视觉检查。 这使得 AI 代理能够进入“自动驾驶”模式，自主测试修复方案，并识别哪些文件夹在重启后仍能存储数据。

解决硬件显示问题

在开发幻灯片应用时，作者遇到了电子墨水屏特有的物理问题：切换图片时，屏幕上会留下上一张图片的残影。尽管自动化测试通过了，但物理显示效果不佳。

通过建立的反馈回路，AI 代理调查了该问题，并利用 Kindle 内置的屏幕刷新机制（Screen Refresh Mechanism）在切换图片后清除残留图像，最终实现了清晰的画面切换。

最终成果

目前，该 Kindle 已成为一个功能完备的照片展示架，具备以下特性：

• 功能：循环播放 10 张照片，支持保持原始宽高比，并设有退出按钮。
• 自定义：用户可以自定义每张照片的展示时长和屏幕亮度。
• 稳定性：图片存储在 Kindle 本地，幻灯片运行无需 Wi-Fi；设备休眠后唤醒，程序可从中断处继续运行。

实验总结：作者认为，在类似开发任务中，尽早建立能够读取日志和屏幕截图的反馈回路，是实现 AI 代理自主调试的关键。

OpenFatigue 简介

OpenFatigue™ 是一个讽刺性的品牌平台，旨在通过恶搞当前科技行业过度使用“Open”（开放）这一词汇的现象，表达人们对于“伪开放”品牌和实际行为不透明的疲劳感。该内容通过一系列荒诞的特性、定价模型和症状描述，批判了许多公司仅在名称中使用“Open”，但在实际操作中却维持封闭生态的行为。

核心特性（讽刺性质）

OpenFatigue 模拟了许多“开放”品牌的虚假特性：

• “似是而非”的许可 (Open-ish Licensing)： 许可协议仅供阅读，实际使用、修改或分发软件需另行与法律部门协商。
• 受限的模型权重 (Weights Available)： 下载权重需签署长达 41 页的使用政策、遵守活跃用户上限并经过所谓的“氛围检查”（vibe check）。
• 仅可见的源码 (Source Visible)： 每季度仅发布源代码的高分辨率截图，且提交代码补丁（Pull requests）可能需要通过传真提交。
• 社区版 (Community Edition)： 由一名处于休假状态的维护者构建。
• 开放式门禁政策 (Open Door Policy)： 建筑大门虽然开放，但门禁系统是闭源的。
• 开放式路线图 (Open Roadmap)： 路线图完全是愿景式的，且可能由一个随时可能解散的非营利委员会决定。

工具与定价模型

平台提供了一系列讽刺性的工具和分层定价：

• 工具： 包括用于校准行业标准的“开放度测量仪™”、用于自动生成“Open + 名词”组合的名称生成器™，以及一个用于判断产品开放程度的闭源分类器。
• 定价策略：
  • Open (免费版)： 需阅读文档、在仓库点赞并加入仅限阅读的 Discord 频道。
  • Open Pro (付费版)： 每月收费，包含受限的权重访问权及商业使用限制。
  • Open Enterprise (企业版)： 需联系销售，仅能在受监督的房间内查看源码。

“开放疲劳”的症状

文章列举了患有“OpenFatigue”的典型症状，反映了用户的心理防御机制：

1. 对“Open”字样产生防御反应： 看到该词时，大脑会自动联想到“候补名单”、“API 密钥”或“企业级方案”。
2. 过度检查许可证 (LICENSE)： 开始警惕“接受使用”、“非商业用途”或“保留权利”等字眼，因为这些都不符合真正的开源定义。
3. 品牌混淆： 无法分辨以“Open”开头的公司究竟是初创企业、门窗商、餐厅还是模型服务商。
4. 对“开放权重”持怀疑态度： 意识到缺乏训练数据、训练代码或宽松许可的“权重”仅仅是允许下载的二进制文件。

结论

文章最后强调，真正的“开源”应遵循 开源倡议 (OSI) 的定义以及 开源 AI 定义。支持真正符合这些标准的项目，才是缓解“开放疲劳”的唯一方法。

研究摘要：AI 模型可以证明能够隐藏任意能力

本文研究了人工智能模型在对抗性环境下的安全性风险，指出当前基于“能力诱导”（elicitation）的审计方法存在根本性的局限性。

核心问题与发现

当前的 AI 能力评估旨在模型部署前识别潜在的危险行为，其可靠性高度依赖于一个核心假设：即模型若具备隐藏能力，这些能力是可以被诱导或触发出来的。然而，本研究证明，在对抗条件下，这一假设并不成立。

技术实现：加密隐藏电路

研究人员提出了一种通过后门攻击在模型权重中嵌入“加密神经网络”的方法。其技术细节如下：

• 触发机制：隐藏的电路仅在接收到特定的“秘密触发器”时才会进行解密并执行。
• 数字保险箱（Digital Lockers）：通过利用密码学构建的“数字保险箱”，这些隐藏电路在密码学假设下被证明是难以被诱导或解释的，即使审计人员拥有模型的完整权重访问权限。
• 功能突破：不同于以往仅能隐藏固定字符串的研究，该方法能够实现对任意计算任务的隐藏。

实验验证

研究团队使用 PyTorch 开发了原型，并以“化学反应预测”作为代理任务（用以模拟化学、生物、放射性及核相关/CBRN 的危险能力）进行了实验。为了测试隐藏能力的稳健性，研究者评估了以下诱导与探测手段：

• 微调（Fine-tuning）
• 权重加噪（Weight noising）
• 基于梯度的触发器搜索（Gradient-based trigger search）
• 潜意识对抗训练（Latent adversarial training）

实验结果显示，隐藏的能力成功抵御了上述所有诱导方法。

研究结论

该研究通过密码学手段证明了 AI 模型可以实现可证明的能力隐藏。这揭示了基于诱导式的能力审计在面对高级对抗攻击时存在技术局限，即审计人员无法通过常规手段检测出被加密保护的危险计算逻辑。研究者已发布相关模型，旨在支持防御机制的改进。

Agent37 产品概述

Agent37 (YC F26) 是一家专门为运行 AI Agent 提供低成本沙盒环境的服务商。其核心竞争优势在于极高的性价比，其提供的沙盒成本通常不到主流供应商的 10%，客户平均每月每个沙盒的支出仅为 0.37 美元。

核心成本优化技术

Agent37 通过针对 AI Agent 工作负载的特性进行深度优化，实现了极低的运营成本：

• 动态资源管理：针对 Agent 在初始化或执行特定任务时 CPU 呈爆发式需求，而在其他时间需求较低，以及在进行浏览器或计算机操作时需要大量内存的特性，通过高效管理 CPU 和 RAM 的利用率来降低成本。
• 优化供应商选择：避开利润率极高的超大规模云厂商（Hyperscalers），转而使用 Hetzner 和 OVH 等成本更低的硬件供应商。
• 采用 gVisor 技术栈：使用 gVisor 实现更快的启动速度和更优的资源利用率。gVisor 允许在沙盒间共享主机内存，而无需为每个沙盒预留完整的虚拟机内存。注：使用 gVisor 的沙盒不支持 Docker-in-Docker 或 Android 模拟器等特定工作负载。
• 硬件选型策略：识别出内存（RAM）是 Agent 工作负载中的主要成本瓶颈而非 CPU，因此在购买服务器时优先优化内存密度，以在单个主机上承载更多沙盒。

产品方案

1. 标准沙盒：基于 gVisor 技术，成本极低。公司甚至可以提供免费计划，其基础设施成本平均每位用户每月仅为 0.05 至 0.10 美元。
2. 全虚拟机 (Full VM) 沙盒：为需要运行 Docker 等复杂工作负载的用户提供，价格虽略高于标准沙盒，但依然保持了较低的成本水平。

目标用户与背景

• 目标用户：主要面向需要运行 AI Agent 的开发者，特别是正在开发消息类（messaging）Agent 的团队。
• 创始人背景：创始人 Vishnu 曾任 Amazon 高级软件工程师及 Quantcast 工程经理，曾主导开发了 Amazon 内部的 AI 聊天机器人 Diya 及编程工具 Ziya。

SolidCraft 项目概述

SolidCraft 是一个使用纯 Rust 语言开发的开源参数化 3D CAD 应用程序。它允许用户通过草图绘制、几何约束和参数化特征时间轴来构建实体模型，并支持通过修改参数自动重建模型。

核心功能

• 参数化建模：
  • 特征时间轴：支持拉伸 (Extrude)、旋转 (Revolve)、扫掠 (Sweep)、放样 (Loft)、倒角 (Fillet/Chamfer)、壳体 (Shell)、抽壳 (Draft)、孔 (Holes)、螺纹 (Threads)、阵列 (Pattern)、镜像 (Mirror)、分割 (Split) 和组合 (Combine) 等功能。特征可以被编辑、抑制、重命名、重新排序或删除。
  • 参数与配置：支持带有单位的表达式（如 2 * width + 5 mm）、有序规则、特征抑制以及按行设置材质和外观。
• 草图与约束：
  • 提供自定义求解器，处理包括共点、点在曲线上、水平/垂直、平行、垂直、切线、曲率 (G2)、相等、同心、共线、中点、对称以及固定等约束。
  • 支持多种草图几何图形，如线、矩形、圆、弧、多边形、槽、椭圆、样条曲线、二次曲线及文本。
• 装配体 (Assemblies)：
  • 支持嵌套组件、关节 (Joints)、运动研究 (Motion studies)、干涉检查以及基于材质的质量属性计算。
• 钣金设计 (Sheet Metal)：
  • 提供法兰 (Flanges)、折边 (Hems)、折叠/展开/重新折叠、材料切割、展开图生成以及精确的 DXF 轮廓导出。

AI 与自动化支持

SolidCraft 的一大特色是内置了 MCP (Model Context Protocol) 服务器：

• AI 智能体集成：允许 AI 智能体通过 solidcraft-cli mcp 在无头模式下运行，或驱动正在运行的桌面应用进行建模、测量、查看设计、执行命令、设置参数、截图以及导出文件。
• 脚本化操作：支持通过 JSON 格式的命令列表进行自动化建模。

文件格式与互操作性

• 导入支持：STEP (AP203/214/242)、IGES、STL、OBJ、3MF。
• 导出支持：STEP (AP242，含名称、颜色和装配体)、IGES 5.3、3MF、STL、OBJ，以及用于机器人模拟器的 URDF 格式。
• 原生格式：使用 .solidcraft 容器存储设计，支持无损二进制网格负载及 JSON 格式。

技术架构与平台

• 分层架构：
  • L0 (geom)：向量、平面、剖面、网格及测量。
  • L1 (sketch/kernel/render)：约束求解器、B-rep 内核及渲染。
  • L2 (doc)：参数、表达式及特征时间轴评估。
  • L3 (io)：设计文件与多种格式的导入导出。
  • L4 (engine)：会话管理与命令注册。
  • L5 (ui/mcp)：可切换的桌面前端 (egui + wgpu) 或 MCP 服务器。
• 多平台支持：
  • 桌面端：Windows、macOS (Apple Silicon/Intel) 和 Linux。
  • Web 端：支持通过浏览器运行 (WebGPU 或 WebGL2)。
  • 命令行：提供 solidcraft-cli 用于无头任务、测量和渲染。

开发信息

• 开源协议：MIT 或 Apache-2.0。
• 硬件支持：桌面端支持 3Dconnexion SpaceNavigator/SpaceMouse 等 3D 鼠标。

美国阅读习惯衰退的原因探讨

背景与现状

近期，关于美国阅读习惯衰退的讨论屡见不鲜。数据显示，美国成人的识字水平呈现严峻态势：根据2023年的国际成人技能评估，28%的美国成年人处于最低识字水平，较六年前的19%有所上升。据估计，超过半数的美国成年人阅读水平低于六年级。

传统观点：需求侧因素

主流观点通常将阅读习惯的下降归咎于外部的“需求侧”因素，认为这些社会问题在很大程度上超出了个人控制范围，包括：

• 颠覆性技术的影响。
• 政治功能障碍。
• 教育系统的衰败。

作者的核心观点：供给侧因素

文章提出了一个不同的视角，即应当关注出版业的“供给侧”问题。作者质疑，随着出版业的日益企业化、整合与集中化，产品质量可能已经发生了“劣质化”（enshittification），这种产品端的退化或许才是导致消费者阅读需求下降的深层原因。

摘要

中国研发支出规模首次超越美国

2024年，中国在研发（R&D）领域的支出规模首次超过了美国，成为全球研发投入最高的国家。

美国联邦政府为追踪记者 Don Lemon 的制片人申请使用伪基站技术

事件背景

美国联邦执法人员已获得授权，计划使用一种被称为“伪基站”（Cell-site simulators，俗称 Stingrays 或 IMSI catchers）的争议性监控设备，以寻找并逮捕 21 岁的 Jerome Richardson。Richardson 曾协助记者 Don Lemon 报道了一场针对美国移民与海关执法局（ICE）官员的抗议活动。他目前是 39 名被控在明尼苏达州 Cities Church 干扰宗教活动并违反公民权利的人员之一。

监控手段与范围

• 针对 Richardson 的定位： 法院文件显示，调查人员在明尼苏达州和宾夕法尼亚州分别申请了针对 Richardson 手机的伪基站搜查令，目的是定位并逮捕他。
• 针对媒体及其他人员： 调查人员还针对记者 Georgia Fort 和前参议员 Jamael Lundy 的手机申请了类似的搜查令，并试图通过“笔录登记令”（pen register orders）获取 Lemon 的通话记录。
• 技术原理与争议： 伪基站通过冒充移动通信塔来定位目标手机。由于该设备在定位时会同时收集周围所有非目标设备的识别信息，隐私倡导者将其视为一种“地毯式监控”工具。

主要争议点

1. 虚假信息质疑： 调查人员在支持搜查令的证词中声称 Lemon 和 Fort 参与了抗议者的喊话，但随后检方承认这一说法是错误的。
2. 必要性与比例原则： Richardson 在申请搜查令期间已通过 YouTube 视频公开表示预计在近日内前往联邦法院自首。这引发了外界质疑，即在目标已有明确自首意向的情况下，动用此类高强度监控手段是否具有必要性。
3. 新闻自由受损： 电子前哨基金会（EFF）指出，针对从事新闻报道的记者使用此类先进监控技术，是对美国第一修正案（新闻自由）的严重攻击。
4. 调查手段的激进性： 除了伪基站，国土安全部（DHS）还利用海关权限，在无需法院事先批准的情况下，索取记者的电话和 YouTube 记录。此外，调查人员还试图获取过去两年内在该地区购买特定 REI 帽子（beanie）的所有消费者的身份信息。

当前进展

Richardson 已在宾夕法尼亚州自愿投案并获准保释。其辩护律师正提出动议，试图排除通过手机追踪手段获得的证据。目前，关于调查人员是否实际部署了伪基站，以及法院是否批准了针对 Fort 和 Lundy 的搜查令，尚不明确。

Phreak.ing 互联网电话交换机摘要

Phreak.ing 是一个被称为“地下交换机”（underground switch）的匿名互联网 PBX（程控交换机）系统。它允许用户通过电话拨号或 Web 界面进行通信，并支持通过 IRC 频道（#phreak）进行交互。

核心功能

• 通信服务：提供语音通话、文本消息（支持设置阅读回执和输入状态显示）以及语音信箱服务（录音、播放及发布，单条时长上限 60 秒）。
• 通话管理：
  • 勿扰模式 (DND)：可设置通话直接进入语音信箱或通过特定方式转发。
  • 通话转发：支持将通话转发至特定分机或停止转发。
  • 拦截功能：可以屏蔽特定分机，使其无法拨号、发短信或进入会议。
• 特殊通信模式：
  • 对讲机 (Intercom)：通过 *80（双向）或 *81（单向）指令，使目标桌面电话自动以扬声器模式应答。
  • 语音 BBS：拨打 *227 可进入包含 10 个板块的语音留言板。
  • 会议与广播：提供会议室功能 (*801-*899)、Hardchats 语音室 (*350) 以及 Acid-radio 直播 (*49)。
  • 唤醒电话：通过 *55 设置定时唤醒通话。

拨号代码 (Dial Codes)

系统包含丰富的星号指令集，用于执行各种电信级操作：

• 测试指令：回声测试 (*43)、毫瓦测试音 (*1004)。
• 通话控制：隐藏主叫 ID (*67)、回拨最后一次来电 (*69)、接听远端正在响铃的电话 (** ext)、挂起通话 (70)、接听挂起通话 (71-79)。
• 信息与查询：获取拨号代码列表 (*#101# 或发送 411 至指定号码)、查询语音信箱 (*97 或 *98)。
• 其他：进入 PhreakNet/C*NET 桥接 (311)、开启/关闭派对模式 (*#06#)。

隐私与匿名性

Phreak.ing 被定义为一个匿名 PBX：

• 无日志记录：系统不保留通话或通信日志。
• 隐私保护：不收集个人信息，建议用户在注册时不要使用真实电话号码。
• 分机设置：用户可以自定义 3 到 10 位的分机号。

加密货币窃贼通过在硬件钱包中植入秘密 eSIM 进行诈骗

攻击原理

窃贼通过篡改看似正品的 Ledger Nano X 硬件钱包来窃取加密货币。攻击者并未破坏其核心的安全元件（Secure Element）芯片，而是通过在设备内部植入额外的硬件来实现目的：

• 截获助记词：攻击者安装了一个拦截芯片，用于读取安全元件向内置屏幕传输数据时的信号，从而识别并记录用户生成的助记词（seed phrase）。
• 远程传输：由于硬件钱包通常处于离线状态，攻击者还植入了包含 eSIM 模块、小型天线和 LTE 调制解调器的硬件。该模块利用钱包原有的电池供电，通过移动网络将获取的助记词自动发送给犯罪分子，使其能够控制用户的加密资产。

损失规模

目前已有约 1 亿美元的加密货币损失。区块链观察人士已识别出超过 300 个受影响的钱包，总计被盗金额约为 9300 万美元。被盗的加密货币随后被兑换，并部分通过加密混币器进行洗钱。

嫌疑对象与安全建议

调查指向了主要在马来西亚等东南亚地区运营的钱包经销商 Cryptobilis。

• Ledger 的警告：Ledger 已建议在过去三个月内从 Cryptobilis 购买硬件钱包的用户不要使用这些设备，并应立即将资产转移到其他安全的钱包中。
• 购买渠道风险：除了直接从该经销商购买外，也有案例显示通过 Amazon Japan 从中国卖家处购买的设备也存在被篡改的风险。

硬件改装的演进过程

这种篡改技术正在向专业化、系列化生产演进，目前已发现至少三个阶段：

1. 第一代：属于手动改装，通过更换更小的电池来腾出空间，布线较为明显。
2. 第二代：设计更加专业，但仍需更换原有的电池。
3. 第三代：采用专业化的系列生产，能够保留原装电池。攻击者通过精准切割硬件腾出空间，甚至会刮除屏幕下方的保护泡沫来隐藏额外的硬件和天线。这种精密的改装使得设备在不拆解的情况下，外观与未篡改的设备几乎无异。

网络爬虫法律问题综述

本文由一位资深的互联网法律专家撰写，通过其在 Reddit 上的问答（AMA）内容，深入探讨了美国网络爬虫（Web Scraping）法律环境的复杂性、政策冲突以及核心法律原则。

核心观点：法律地位的不确定性

作者总结了一个关键结论：“网络爬虫无处不在，但其合法性并不明确。” 一个爬虫项目必须同时通过多个法律领域的审查，只要违反其中任何一项原则，都可能面临严重的法律后果，甚至是刑事责任。

政策层面的权衡

在法律政策制定上，爬虫处于两种相互冲突的利益之间：

• 支持爬虫的理由（社会利益）：

  • 信息获取： 促进知识传播，增强市场透明度。
  • 技术创新： 支持搜索引擎、价格比较工具及 AI 模型训练。
  • 互联网架构： 维护互联网“无须许可”（permission-less）的低摩擦导航特性，防止互联网演变为需要层层授权的封闭系统。
  • 反垄断： 防止企业利用反爬虫手段制造垄断。

• 反对爬虫的理由（权利保护）：

  • 财产所有权： 保护所有者决定其财产使用方式的权利。
  • 系统安全： 防止爬虫行为演变为类似拒绝服务攻击（DoS）的行为。
  • 版权与隐私： 防止大规模的版权侵权及对消费者隐私的侵犯。

核心法律挑战：对动产的侵权 (Trespass to Chattels, TTC)

由于法律界定尚不稳定，作者认为“对动产的侵权”是目前最混乱的领域。他提出了判断 TTC 是否适用的四个步骤：

1. 原告是否拥有受影响的动产？（通常指运行服务器或连接互联网的物理硬件）。
2. 被告是否“使用”了该动产？（通常指发送或接收服务器数据包）。
3. 使用是否“未经授权”？（这是争议最大的部分。虽然服务器所有者可以通过服务条款 (TOS)、禁令信、技术控制（如 IP 封锁）或机器人排除协议等手段撤销隐含的访问许可，但这些手段的法律有效性并不统一）。
4. 未经授权的使用是否造成了法律认可的损害？（法律对何种程度的损害才构成法律责任仍缺乏明确且一致的标准）。

爬虫必须面对的法律“军团”

为了确保合法，爬虫活动必须同时应对以下法律框架的审查：

• 侵权行为判定（TTC 三重奏）：
  • 联邦法律： 特别是《计算机欺诈与滥用法》（CFAA）。
  • 州法律： 如加州刑法典第 502 条。
  • 普通法： 基于过往判例的对动产侵权原则。
• 版权法： 涉及将受版权保护的内容下载到浏览器内存（RAM）的行为，以及后续重新发布相关内容的风险。
• 数字千年版权法 (DMCA)： 关于绕过技术保护措施的相关条款（如 1201/1202 条款），目前该领域法律界定仍处于混乱状态。
• 服务条款 (TOS)： 网站中的反爬虫条款及其法律效力的认定（涉及 TOS 如何合法成立的法律争议）。
• 其他领域： 包括商标法和隐私权法。

总结

由于法律判例不断变化且各领域标准不一，网络爬虫的法律环境极其复杂且难以预测。对于从事爬虫业务的开发者而言，由于缺乏明确的法律边界，建议在采取行动前咨询专业律师。

ZX Spectrum Demoscene Intro 开发技术总结

本文详细记录了作者为 ZX Spectrum 128Kb 开发一款复古 Demoscene Intro 的技术过程。该作品旨在致敬 80 年代末的“破解片片头”（cracktros）风格，包含平滑滚动文字（自定义字体）、三通道 AY 音效、跳动的 VU 指示灯以及视差星空效果。最终代码大小约为 10,287 字节。

开发环境与工具

• 构建系统：使用 Makefile 驱动，通过 Pasmo 汇编器处理代码，使用 zmakebas 处理 BASIC 文件。
• 测试与调试：使用 FUSE 模拟器进行初步测试，并通过 TNFS（一种针对 Spectrum 的网络协议）在真实的 ZX Spectrum +3 硬件上运行。
• 调试辅助：利用在线 Z80 汇编编辑器观察寄存器状态，并大量使用纸笔进行位掩码（bitmask）和内存布局的逻辑推演。

核心技术挑战与实现

1. 屏幕布局与像素处理

ZX Spectrum 的屏幕内存布局极其特殊，采用的是**交错式（interleaved）**布局，而非现代硬件常见的位图模式。这种设计虽然优化了文本显示，但在处理图形效果时非常复杂。

• 平滑滚动文字：作者没有调用低效的 ROM 打印函数，而是通过直接操作位数据实现。利用 Z80 的 RL（循环左移）指令，结合位移技巧，实现像素级的平滑滚动。通过直接读取字体数据并逐行、逐像素地流式写入屏幕缓冲区，解决了字符跳变的问题。
• 自定义字体：通过改写 Spectrum ROM 中存储字体数据的内存地址（$5C36），实现了具有 Demoscene 风格的“Leet”字体。

2. 视差星空效果（Starfield）

为了在极有限的 CPU 周期内实现视差效果，作者放弃了实时随机生成星空的方法，转而采用“作弊”策略：

• 预计算数据：使用 Ruby 脚本预先生成 32 颗星星的坐标（X, Y）并存入数据表，避免了实时运行随机数生成器（RNG）的开销。
• 优化存储结构：每颗星星不记录坐标，而是直接记录其所在的屏幕字节地址和位掩码（bit mask）。这样移动星星时只需进行简单的位移和旋转操作，无需进行昂贵的坐标转内存地址计算。
• 碰撞检测：引入了“占用检查表”（Occupancy Check），通过标记哪些字符单元格被文字占据，使星星能够从文字间的空格中穿过，而不会遮挡文字。

3. 音乐转换（AY 音效）

作者将一段经典的 Amiga Tracker 音乐转换为了适用于 Spectrum AY-3-8912 芯片的三通道版本。

• 工具使用：使用 Vortex Tracker II 进行转换。
• 技巧应用：为了在仅有的 3 个通道中模拟更丰富的和弦效果，利用了 Tracker 的“装饰音”（Ornaments）功能（如快速琶音），使两个通道能听起来像三个通道一样奏出三和弦。

4. 其他视觉效果

• VU 指示灯：通过 IN 指令读取 AY 芯片寄存器的实时振幅值，并将其映射为屏幕上的跳动条。
• Logo 闪烁（Twinkle）：利用 Spectrum ROM 中前 8KB 区域的伪随机字节作为种子，实现 Logo 背景中星星的随机闪烁效果。

内存管理方案

由于项目包含大量资源（背景图、音乐文件、播放器二进制文件），最初尝试将所有资源嵌入代码会导致内存溢出。最终解决方案是采用多阶段 BASIC 加载器：通过 BASIC 程序分阶段将不同的代码块和数据块加载到指定的内存地址（如将播放器加载至 $C000），从而有效利用有限的内存空间。

总结

该项目展示了在极低性能硬件上通过“面向机器编程”的思想（如寄存器状态可视化、位操作优化、预计算查表法）来实现复杂视觉效果的可能性。

IMF 警告：人工智能股价崩盘威胁全球金融稳定

国际货币基金组织（IMF）在其最新的《全球金融稳定报告》中发出警告，人工智能（AI）相关股票的价格崩盘可能引发连锁反应，进而威胁全球金融体系的稳定性。

核心风险因素

IMF 指出，由于 AI 相关公司面临极高的估值以及不断增加的债务规模，系统性风险已处于“高位”。若发生 AI 市场回调，其后果可能是全球性的。

主要风险驱动力包括：

• 高杠杆风险： 杠杆作用不仅体现在公司自身激增的债务上，还包括对冲基金在这一领域的投资，以及散户投资者通过借贷进行 AI 股票投机的行为。这些因素在市场下行时可能引发强制平仓，导致股市波动剧增。
• 循环融资（Circular Financing）： 强有力的 AI 企业与同行业内较弱的合作伙伴之间存在复杂的资金往来。过去三年中，超大规模企业（Hyperscalers）与较弱 AI 公司之间的交易额达 3000 亿美元，辅以 6500 亿美元的债务，以换取 1.4 万亿美元的未来财务承诺。这种相互关联性可能在价格回调时加剧风险。
• 投资回报的不确定性： 尽管超大规模企业在基础设施（如数据中心）上投入了巨资，但有证据表明，AI 带来的潜在经济收益可能并不如预期般巨大，且实际应用未必需要如此大规模的投资。

全球影响与市场结构

• 地理暴露程度： 若发生 AI 修正，美国和亚洲市场将面临最大程度的影响。英国和欧元区相对更具防御性，但持有美国资产的投资者仍会受到冲击。
• 市场集中度过高： “七巨头”（Alphabet, Amazon, Apple, Meta, Microsoft, Nvidia, Tesla）目前占标普 500 指数权重的 35% 以上，其市值在过去两年增长了超过 50%，这种高度集中的市场结构放大了潜在的系统性风险。

三大系统性风险

IMF 明确将以下三项列为可能导致金融条件剧烈收紧和市场动荡的“显著风险”：

1. AI 资产价格回调
2. 政府借贷成本上升
3. 大规模网络攻击

网络安全威胁

针对潜在的网络攻击风险，英国金融行为监管局（FCA）首席执行官 Nikhil Rathi 建议金融行业的所有小企业应考虑购买保险，以应对由尖端 AI 模型驱动、能够快速识别系统漏洞的日益严峻的网络安全威胁。

Janas: 通过从 SSD 流式传输专家权重运行超大 LLM 的工具集

Janas 是一个用 C 语言编写的 AI 工具家族（无外部依赖），其核心组件 Janas-LLM 旨在让普通计算机能够运行内存容量无法完全容纳的大型混合专家（MoE）语言模型。

核心机制

Janas-LLM 的创新之处在于其权重管理方式：模型权重常驻磁盘，在推理过程中，系统根据需要从 NVMe SSD 中流式传输所需的“专家”权重，并将频繁使用的专家保留在内存（专家缓存）中。这种机制使得在仅有 32 GB 内存的笔记本电脑上运行 48 GB 的 80B 参数模型成为可能。

性能表现

在开发者提供的基准测试中，Janas-LLM 在处理超出内存容量的模型时，性能显著优于 llama.cpp。

• 典型案例：在配备 32 GB 内存的 Intel Core Ultra 9 笔记本上运行 48.4 GB 的 Qwen3-Next-80B-A3B 模型时，Janas 的生成速度（writing）达到 24 tok/s，而 llama.cpp 仅为 2.8 tok/s。
• 读取速度：在读取 Prompt（reading）方面，Janas 也展现出极高的效率，通过集成 GPU 加速，在部分模型上的表现远超同类工具。
• 草案功能（Drafts）：支持类似投机采样（Speculative Decoding）的技术，通过使用较小的模型预测后续 Token 来提升整体生成速度。

主要组件与功能

Janas 不仅仅是一个推理引擎，而是一个完整的工具生态：

• janas-chat：交互式聊天命令行工具，支持草案模式和 MCP 服务。
• janas-get：用于下载和转换已准备好的模型文件。
• janas-server：提供兼容 OpenAI 标准的 HTTP API，支持通过浏览器访问，并可用于 VS Code 等编辑器的代码补全。
• janas-mcp：将模型作为工具提供给 Claude Code 等 MCP 客户端。
• janas-bench：用于测量机器性能并生成硬件报告的基准测试工具。

开发者提示与注意事项

• 实验性阶段：本项目目前处于早期开发阶段，API 和命令行参数会频繁变动，稳定性尚未经过完全验证。
• 硬件压力：由于 Janas 会尽可能填满空闲内存以构建专家缓存，并利用 O_DIRECT 以全速读取磁盘，因此在内存或磁盘带宽不足的机器上运行可能会导致系统响应缓慢。
• 平台支持：目前支持 Linux (x86-64) 和 Windows (x86-64)。

技术规格总结

• 编写语言：C 语言。
• 核心依赖：仅需 C 标准库（部分组件包含 libmicrohttpd, yyjson, Mbed TLS 等）。
• 硬件要求建议：高性能 NVMe SSD 是实现高效流式传输的关键。