纽约时报诉 OpenAI 与微软案：内部文件披露 AI 抓取被视为“历史上最大规模的劳动力盗窃”

在《纽约时报》针对 OpenAI 和微软发起的版权诉讼中，最新的未脱密文件披露了令人震惊的内部信息。文件显示，这两家公司的领导层曾私下承认 AI 训练行为类似于“盗窃”，并承认其 AI 产品对新闻出版业构成了“生存威胁”。

核心内部证词与承认

• “历史上最大规模的劳动力盗窃”：微软应用科学总监 Brent Hecht 在 2024 年 1 月的一份内部演示文稿中，将这种规模的抓取行为描述为“一场规模空前的惊人盗窃”以及“人类历史上最大规模的劳动力盗窃”。
• “生存威胁”与“替代性”：OpenAI 的 ChatGPT 负责人 Nick Turley 在内部沟通中指出，出版商面临着来自聊天机器人的“生存威胁”，因为这些产品具有高度的“替代性”，且随着技术进步，这种替代性会越来越强。
• 承认破坏经济基础：微软内部文件指出，这种模式正在破坏其“内容供应链”的经济基础。微软的 Copilot “答案引擎”导致《纽约时报》域名的点击率较传统的 Bing 搜索下降了高达 93%，内部将其称为会损害模型性能和整个网络的“末日循环”（doom loop）。
• CEO 的立场：微软 CEO Satya Nadella 在证词中表示，任何设有付费墙的内容在用于训练或强化模型时都应获得许可。他明确表示，如果他得知 OpenAI 抓取并训练了付费墙后的信息，他会要求 OpenAI 重新训练其模型。

争议性的数据获取手段

诉讼文件详细说明了 OpenAI 和微软涉嫌采取的非法或违规获取内容的手段：

1. 绕过付费墙：文件显示，OpenAI 员工曾讨论如何通过“黑客手段”绕过《纽约时报》的付费墙，OpenAI 总裁 Greg Brockman 在得知此消息后对此表示认可。
2. 删除版权声明：为了防止模型在输出内容时显示版权信息，研究人员涉嫌在训练数据中刻意删除版权声明。
3. 大规模抓取与数据交换：
   • OpenAI 的中段训练数据集包含超过 9 万份来自《纽约时报》、《每日新闻》等机构的作品。
   • 来自 Common Crawl 的数据集中包含超过 200 万篇来自 nytimes.com 的文档。
   • 微软通过名为 “Project Taxi” 和 “Project Mango” 的计划向 OpenAI 提供训练数据，双方还存在数据交换行为。

法律背景

目前，关于 AI 公司使用版权材料进行训练是否属于“合理使用”（Fair Use）在法律上尚无定论。尽管此前许多法官倾向于支持 AI 公司的辩护，但本次披露的内部证据直接挑战了“合理使用”的核心原则——即使用行为不得替代或损害原作品的市场价值。如果 AI 产品直接替代了新闻源并导致点击率骤降，其“合理使用”的辩护将面临巨大法律挑战。

Hister 项目概述

Hister 是一个私有的个人搜索引擎，旨在为用户访问过的网页和保存的文件建立全文索引，以便通过 Web 界面、终端（TUI/CLI）或通过 MCP 连接的 AI 助手进行快速检索。

核心功能

• 隐私保护：专注于隐私，不包含遥测数据或强制性的云服务。用户可以在本地或自行控制的基础设施上运行，所有文档和索引均存储在用户自己的服务器上。
• 全文索引：不同于仅索引标题和 URL 的传统搜索，Hister 会对访问过的页面和本地文件的实际全文内容进行索引。
• 自动浏览器索引：通过提供的 Chrome 或 Firefox 浏览器扩展程序，可以自动保存并索引新访问的页面。
• 强大的查询能力：支持字段过滤器、短语搜索、通配符、否定查询、别名以及结果优先级设置。
• 语义搜索（可选）：用户可以通过配置嵌入（embeddings）端点，实现基于文档含义的语义搜索。
• 灵活的数据导入：支持导入现有的浏览器历史记录、本地目录、特定文件，或通过爬虫对网站进行索引。
• 多客户端支持：提供 Web 界面、终端界面（TUI）、命令行工具以及面向 AI 助手的 MCP（Model Context Protocol）接口。
• 多用户支持：支持在共享服务器上为不同用户隔离文档和搜索结果。

安装与开发

• 安装方式：提供跨平台的二进制文件下载，并支持通过 Homebrew、Docker 和 Nix 进行安装。
• 快速上手：用户需运行 hister listen 命令启动服务器，并配合浏览器扩展程序来捕获网页内容。
• 开发要求：项目基于 Go 语言（要求 Go 1.26 及以上），前端使用 npm/Vite。开发环境还需要 C 编译器以处理 CGO 依赖。
• 开源协议：采用 AGPLv3 协议。

Passkey（通行密钥）的使用现状与个人风险总结

尽管科技巨头（如 Google 和 Microsoft）正积极推动 Passkey 作为登录的终极解决方案，但该技术在个人安全应用中仍面临显著的挑战和风险。虽然 Passkey 在技术上能有效防止网络钓鱼和服务器端数据泄露，但对于个人用户而言，其带来的风险可能超过了其安全收益。

核心问题与挑战

1. 账号锁定与恢复风险

Passkey 的安全性在于其非对称特性，但个人用户面临的最大威胁并非黑客攻击，而是永久失去账号访问权（如设备丢失、账号被自动封禁或系统故障）。此外，账号的实际安全性往往取决于其恢复手段（如 SMS、邮件链接或安全问题），如果这些恢复方式不够安全，Passkey 的防御优势将大打折扣。

2. 硬件密钥（Hardware Keys）的局限性

• 备份困难：Passkey 设计上无法在硬件密钥之间直接移动，用户必须为每个网站在多个硬件密钥上分别进行注册，这导致成本上升且难以扩展。
• 存储容量限制：硬件密钥对“可发现凭据”（discoverable credentials）的存储容量有限（通常在 25 到 300 个账号之间），一旦超过限制，用户必须删除现有账号或购买新密钥。

3. 同步 Passkey 的生态锁定风险

• 过度依赖大厂：使用 Apple 或 Google 的同步功能会将用户的身份锚定在特定操作系统上。一旦用户的 Google 或 Apple 账号被封禁，其关联的所有第三方账号也将因失去 Passkey 而无法访问。
• 互操作性不足：尽管 FIDO 联盟正在努力改善跨平台互操作性，但目前的导出和迁移体验仍不成熟，远不如传统密码那样易于手动管理和备份。

4. 第三方密码管理器的体验欠佳

虽然 Bitwarden 等工具已开始支持 Passkey，但受限于操作系统提供的 API，其在浏览器之外或原生应用程序中的自动填充体验仍不完善，缺乏像传统密码管理那样长期的用户体验优化。

5. 设备使用场景受限

在非自有设备（如同事的电脑）上使用 Passkey 非常不便。硬件密钥可能面临接口不足的问题；而通过扫描二维码并利用蓝牙进行连接的“混合传输”方案，在实际使用中经常遇到连接失败或蓝牙不支持等问题。

结论

Passkey 目前更适合企业级环境，对于个人用户而言，整个生态系统尚未成熟。相比之下，使用第三方密码管理器存储高强度随机密码，并配合独立的 TOTP（基于时间的一次性密码）应用，在为用户提供灵活性的同时，目前比 Passkey 方案更具可靠性。

OpenAI 内部仓库遭劫持：堆溢出与 SSO 配置错误漏洞链分析

Hacktron 团队通过组合两个关键漏洞，成功入侵了多名 OpenAI 员工的 ChatGPT 和 Codex 账户，并利用这些权限访问了 OpenAI 的内部代码仓库（openai/openai）。整个攻击从发现漏洞到成功访问内部仓库的过程耗时不足 72 小时。

漏洞攻击链

攻击通过以下步骤实现权限提升与横向移动：

1. libheif 图像解码器漏洞：存在堆缓冲区溢出。
2. Debian 缺失安全回传：Debian 12/13 未能及时包含针对 libheif 的安全补丁。
3. ImageMagick 依赖：Discourse 论坛通过 ImageMagick 调用 libheif 处理 HEIF 文件。
4. Discourse 图像上传：漏洞触发点。
5. OpenAI 社区论坛：攻击载体。
6. OpenAI SSO 身份缺陷：导致论坛权限可转化为 OpenAI 服务账户权限。
7. ChatGPT / Codex 账户接管：获取员工账号控制权。
8. GitHub 集成：通过连接的集成访问代码。
9. OpenAI 内部仓库：最终目标。

技术细节

1. libheif 堆缓冲区溢出

在 Discourse 论坛的图像上传流程中，由于默认工具 FastImage 不支持 HEIF/HEIC 格式，系统会调用 ImageMagick 进行转换，从而直接暴露了底层的 libheif 解析器。研究人员发现，Debian 12 和 13 分发版中使用的 libheif 版本（1.19.7/1.19.8）未包含关键的安全回传补丁，存在堆缓冲区溢出漏洞，可导致远程代码执行 (RCE)。

2. SSO 身份认证缺陷

这是此次攻击能够从论坛转向核心服务的关键。OpenAI 的身份认证基础设施存在配置问题，使得攻击者在通过论坛漏洞获取 RCE 后，能够接管论坛成员的 ChatGPT 和 Codex 账户。由于这些账户通常集成了 GitHub、Slack 和电子邮件，攻击范围从单一论坛扩展到了整个 OpenAI 的生态系统。

AI 在攻击中的角色

研究人员强调，AI 模型极大地降低了攻击的门槛并缩短了攻击周期。

• 漏洞开发：研究人员使用 Claude (Opus 4.8 和 Opus 5) 协助识别漏洞、编写针对 ARM64 环境的 Exploit，并将其移植到 Discourse 使用的 x86-64 和 jemalloc 配置中。
• 自动化测试：利用 AI 代理（Agent）在自主循环中尝试绕过防御并实现 RCE。
• 效率提升：原本需要专业团队耗费数月完成的复杂研究（如针对 Slack、Meta 等平台的“HEIF Heist”调查），通过 AI 辅助，仅需数周且仅消耗约 3,000 美元的 Token 成本。

处置结果与影响

• 响应：漏洞已向 OpenAI 和 Discourse 报告。OpenAI 支付了 6,500 美元的漏洞赏金。
• 修复：Discourse 已发布补丁并开始对 ImageMagick 进行沙箱化处理。
• 安全启示：AI 正在将稀缺的黑客专业知识转化为可规模化的计算资源。传统的“通过复杂性实现安全”的假设正在失效，安全模型必须重新评估由于 AI 介入而导致的攻击成本降低和攻击速度加快的现实威胁。

Astra for Law 概述

OpenAI 推出了 Astra for Law，这是一个专门为律师事务所和法律科技公司设计的全新基础平台。该平台将最新的 GPT-6 Astra 模型与针对专业法律工作定制的设置、工具和上下文相结合，旨在帮助用户构建基于其专业知识的 AI 产品和工作流。

核心技术能力

1. 法律研究与分析

Astra for Law 集成了强大的法律搜索索引，并配备了专门用于法律分析和写作的指令系统：

• 法律搜索索引：该索引可检索超过 2.3 亿个 URL，涵盖美国判例法、法规、法院规则和行政决策。通过与 Free Law Project 合作，该索引覆盖了超过 99.9% 的已公布美国判例法。
• 性能提升：在 Vals AI 的法律研究基准测试中，Astra for Law 的整体正确率较仅使用网络搜索的 GPT-6 Astra 提升了 40%。在判例法相关的检索任务中，它发现的参考案例比前者多 24%，检索到的相关段落也多出高达 54%。
• 端到端工作流：模型不仅能进行研究，还能通过定制指令将研究成果应用于具体的客户事实，执行复杂的法律分析（如区分法院判决与观察意见、识别合同风险或解释条款对风险的影响）。

隐私与治理

针对法律行业对客户机密性的严苛要求，OpenAI 提供了专门的保护机制：

• 受信访问计划 (Trusted Access Program)：为符合条件的律所提供专业访问权限。
• 数据安全控制：为 API 用户提供零数据保留 (Zero Data Retention, ZDR) 功能；ChatGPT Enterprise 的使用默认排除人工审核。
• 合规治理：通过与 Latham & Watkins 合作，设计包含信息权限、伦理墙（Ethical Walls）、客户指令和律所监督在内的治理框架。

生态系统与定制化

Astra for Law 采用开放且可组合的设计理念，允许律所将自身专业经验与现有工具整合：

• 专业插件生态：推出了 26 个合作伙伴构建的插件，连接了律师常用的工具（如 iManage、Intapp、DeepJudge 和 Thomson Reuters），实现文档保存、时间记录、案例对比及上下文关联等功能。
• 定制化应用实例：
  • Sullivan & Cromwell：利用律所的谈判手册和先例构建了协议分析器。
  • Ropes & Gray：构建了交易尽职调查系统，帮助律师在数据室工作中追踪关键发现。
  • Cooley：开发了 GO Public 工具，辅助企业准备 IPO 申请及识别风险。
• 办公集成：ChatGPT for Word 正式发布，支持律师在熟悉的文档编辑环境中进行校对、编辑建议和格式检查。

可用性

Astra for Law 将首先通过 ChatGPT 和 Codex 中的“受信访问”提供给选定的律师事务所，随后通过 API 面向开发者开放。在模型选择器中，该模型显示为 “GPT-6 Astra Law”，API 调用名称为 gpt-6-astra-law。

Bend 语言概述

Bend 是一种专为后 AGI（通用人工智能）时代设计的高性能编程语言。它旨在通过形式化证明（Proof）来减少 AI 在编写代码时的错误，同时提供接近 C 语言的执行速度和强大的并行处理能力。

核心特性

1. 高性能执行

• 原生速度：Bend 编译为原生代码。在单核运行速度上接近 C 语言。
• 跨平台并行：同一二进制文件可在多核 CPU（如 16 核）或 GPU 上运行。在 GPU 上，其运行速度最高可比单核提升 100 倍。

2. 快速编译与类型检查

• 证明检查器：Bend 的类型检查器本质上是一个证明检查器（类似于 Lean 或 Rocq）。
• 高效性：不同于传统的证明工具可能需要数分钟，Bend 的检查速度极快（通常在 1 秒内），非常适合 AI 代理在每次代码更改后进行实时验证。

3. 自动并行化

• 无锁编程：开发者无需手动管理线程、锁或编写内核（Kernels）。
• 任务分发：Bend 能自动将工作负载拆分并分布到所有可用的 CPU 核心或 GPU 核心上，极大地简化了并行计算的复杂度。

4. 通过证明阻断 AI 错误

这是 Bend 的核心差异化功能，通过将“意图”转化为数学上的“定律”来解决 AI 生成代码的不确定性：

• 定律 (LAWS.bend)：用户可以定义必须遵守的规则（例如：“游戏永远不可能获胜”）。这些定律比自然语言更精确，且具备类型检查能力。
• 证明 (PROOF.bend)：当 AI 编写代码时，必须提供证明来确保代码逻辑符合定义的定律。
• 错误拦截：如果 AI 生成的代码违反了 LAWS.bend 中的规则，编译器会直接拦截该错误，迫使 AI 重新尝试直到通过数学验证。这意味着违反定律的行为在逻辑上被视为“不可能”。

技术基础

• BendTT：基于仿射依赖类型理论（Affine Dependent Type Theory）的核心理论。
• BendRT：支持 CPU 和 GPU 的并行运行时环境（Runtime）。

使用建议与工作流

为了充分利用 Bend，建议在 AI 代理的配置文件（如 AGENTS.md）中加入以下指令：

1. 使用 bend guide 学习语言规范。
2. 使用 LAWS.bend 维护关键规则。
3. 在提交代码前运行 bend PROOF.bend 进行验证。
4. 尽可能进行代码并行化处理。

安装方式

可通过以下命令进行安装：

curl -fsSL https://bend-lang.com/install.sh | sh

OpenJev 项目概述

OpenJev 是一个在浏览器中运行的本地实验项目，旨在通过本地模型比较两种不同的决策概率处理方式。该实验完全在用户本地进行，无需后端服务器，利用用户自身的 GPU 进行计算。

核心实验对比

实验通过相同的决策场景，对比了以下两种方法：

1. 直接读取概率 (Direct Readout / Logits)：

   • 原理：不对模型进行解码，而是直接读取模型对预设选项的 Logits（对数概率），并仅针对提供的选项进行 Softmax 归一化。
   • 特性：这是一种条件概率，反映了模型在给定选项集合中的选择倾向，而非校准后的置信度。

2. JSON 文本生成 (Generation / JSON Probabilities)：

   • 原理：要求模型估算选项的概率分布，并以 JSON 格式逐个 Token 地将结果写入文本。
   • 特性：观察模型通过语言生成过程表达概率分布的行为。

技术实现与特性

• 本地化与隐私：所有操作均在浏览器内完成，模型权重从 Hugging Face 下载并存储在浏览器缓存中。用户的输入数据不会离开本地页面，确保了隐私性。
• 运行环境：利用 wllama 运行量化后的 GGUF 格式模型，通过本地 GPU 加速。
• 模型分级：
  • Qwen3 0.6B：适合手机或低功耗设备。
  • MiniCPM5 2B：默认桌面端模型。
  • Qwen3.5 4B：高性能选项，但需要显著更多的显存。
• 性能测量：系统使用 performance.now() 实时测量设置、预热、提示词准备、直接执行、首个 Token 生成以及生成完成的各项耗时。

模型质量指标

项目通过以下维度衡量不同模型的表现：

• Authored：平衡准确率。
• Perturbed：扰动下的表现。
• TypeSafe：在特定公开子集上的等情况一致性（Equal-case agreement）。

注意：由于采用了量化技术，模型的实际准确率和运行速度可能会受到量化程度的影响。

Bonsai 2 27B 模型总结

Ternary Bonsai 2 27B 是由 PrismML 发布的一款基于 Qwen3.8 27B 开发的多模态模型。该模型通过先进的压缩技术，在显著降低内存占用的同时，实现了近乎“无损”的性能保留，旨在推动大模型在本地设备上的高效部署。

核心技术规格

• 压缩机制：采用三值权重 ${-1, 0, +1}$ 结合 FP16 分组缩放（group-wise scaling）。
• 内存占用：有效位数为 1.76 bits/weight，模型总占用空间仅为 5.9GB，比其全精度版本缩小了 9 倍以上。
• 上下文窗口：支持高达 262K token 的上下文长度。
• 模态支持：支持文本与图像的多模态输入。
• 开源协议：采用 Apache 2.0 许可协议。

性能表现

Bonsai 2 27B 在保持极低硬件门槛的同时，展现了极高的“智能密度”：

• 性能保留率：在各项聚合基准测试中，该模型保留了全精度 Qwen3.8 27B 98.2% 的性能。
• 能力覆盖：在推理、数学、代码、指令遵循、视觉及代理工具调用（Agentic tool use）等领域均表现出色。
• 关键优势：特别是在对错误累积较为敏感的领域，如编程代理、工具使用系统、多模态工作流和长程任务中，该模型能够有效维持全精度模型的性能水平，避免了传统低比特模型常见的性能大幅退化问题。

运行效率与能效

该模型针对本地部署进行了优化，提供了极高的吞吐量和能效比：

• 吞吐量：在 NVIDIA GeForce RTX 5090 上可达 143 tokens/s；在 Apple M5 Max 上可达 46.8 tokens/s。
• 能效比：在 RTX 4090 上，其每 token 能耗仅为 0.714 mWh，比运行全精度的 8B 模型能效高出 40%。

应用价值与平台支持

应用场景： 由于其低内存、高吞吐和高能效的特性，Bonsai 2 27B 使本地模型能够胜任复杂的知识工作，包括：

• 编程代理循环（Coding-agent loops）。
• 计算机使用工作流（Computer-use workflows）。
• 私密文档分析。
• 多模态调试与混合架构编排（即本地处理敏感或高频任务，云端处理复杂任务）。

平台兼容性：

• NVIDIA GPU：通过 CUDA 支持。
• Apple 设备（Mac, iPhone, iPad）：通过 MLX 支持。

《大家都疯了》文章摘要

这篇文章（设定于2026年9月）对当前由人工智能（AI）驱动的技术、文化和安全领域的现状进行了尖锐的批判。作者认为，AI 的广泛应用正在从多个维度侵蚀专业精神、安全性和人类的认知能力。

核心观点总结：

1. 专业精神与沟通质量的退化

作者指出，AI 浪潮导致了专业领域的混乱：缺乏工程背景的人开始推销所谓的“行业变革”方案；职场沟通变得肤浅且模式化（类似于 LinkedIn 风格）；工作重心过度向 AI 倾斜，削弱了专业人员的成就感。

2. 伦理与权力的集中

文章批评了 AI 公司的行为：

• 剥削与垄断： AI 模型建立在对知识产权的剥削之上，并将权力集中在少数美国公司和寡头手中。
• 社会危害： AI 技术被用于生成非法内容（如儿童性虐待内容），并被应用于军事领域（如目标选择）。
• 监管虚伪： 许多公司在追求利润的同时，一边利用“伦理”作为营销手段，一边无视技术带来的实际负面影响。

3. 网络安全中的资源错配（西西弗斯项目）

作者通过“西西弗斯项目”这一概念，批判了业界在网络安全上的错误优先级：

• 无效的投入： 许多顶尖企业投入数百万美元利用 AI 进行漏洞研究（Vulnerability Research），试图通过 AI 发现大量新漏洞。
• 忽视根本问题： 作者认为，网络安全的瓶颈从来不在于“发现”漏洞，而在于“补丁管理”（Patching）。企业应当将资源用于建立完善的资产清单、自动化更新机制和攻击面枚举，而非沉溺于 AI 带来的漏洞发现幻觉。

4. 环境代价

AI 竞赛对环境造成了巨大压力。为了维持数据中心的运行，企业消耗了惊人的水资源和化石燃料，这与许多公司标榜的“碳中和”承诺背道而驰。

5. “去技能化”与理解力的丧失

这是文章最深刻的警告。作者认为 AI 并非在创造“超人类智能”，而是在通过一种“脑虫”式的机制让使用者“去技能化”：

• 自动化循环： 当人们使用 AI 编写代码、使用 AI 生成补丁、再使用 AI 审查补丁时，人类对代码库的理解力正在迅速丧失。
• 系统性风险： 随着人类逐渐变成代码审查的“橡皮图章”，一旦复杂的分布式系统发生故障，由于缺乏对底层逻辑的理解，人类将无法进行有效的调试。

结论

作者认为，AI 正在将人类带入一个过度依赖工具、丧失理解能力且忽视基础安全建设的危险循环。在这种环境下，复杂系统的透明度正在消失，人类正在主动放弃对技术世界的掌控权。

Qwen Studio 功能概述

Qwen Studio 是一个功能全面的平台，其核心功能涵盖了以下几个方面：

• 交互与对话：提供聊天机器人（Chatbot）功能。
• 多模态理解：具备图像与视频的理解能力。
• 内容生成：支持图像生成。
• 文档处理：提供文档处理功能。
• 外部集成与扩展：集成网页搜索功能，支持工具利用（Tool utilization）以及 Artifacts 功能。

Bend 2 与“氛围编程”（Vibe-Coding）陷阱

本文通过对编程语言 Bend 2 的批评，探讨了“氛围编程”（Vibe-Coding）所带来的设计风险。

Bend 2 的设计理念与缺陷

Bend 2 被定位为 AI 编程时代的语言：人类编写“法则”（laws），AI 编写实现与证明，最后由编译器检查证明的正确性。

作者指出，尽管这一愿景听起来很先进，但其实现方式极其低效。在 Bend 的官方演示中，为了证明一些简单的游戏逻辑（如玩家无法触碰旗帜），开发者需要编写 58 行的“法则”，并额外编写高达 442 行的“证明”代码。这种设计被认为过于冗余且缺乏效率。

“氛围编程”陷阱

作者提出了“氛围编程陷阱”的概念：通过 AI 辅助，开发者可以在尚未深入理解问题领域的情况下，快速构建出具有实质功能的解决方案。

这会导致以下问题：

1. 忽视现有成熟领域：Bend 的开发者构建了一整套语言和编译器，却似乎完全没有意识到“形式化验证”（Formal Verification）这一成熟领域的存在。
2. 重复造轮子且设计拙劣：由于 AI 可以根据模糊的需求快速生成代码，开发者可能会在没有进行必要调研的情况下，实现一个不仅落后于时代、甚至在设计上存在严重缺陷的系统。

对比案例：Bend vs. SPARK

为了证明 Bend 的设计效率低下，作者使用 SPARK（一种用于形式化验证的开源语言）重写了相同的演示程序。

• Bend 的做法：依赖大量冗余的法则和极其漫长的证明代码。
• SPARK 的做法：通过定义“归纳不变式”（Inductive Invariant）和“后置条件”（Post-conditions），利用编译器自动处理复杂的证明逻辑。

结果显示，SPARK 仅需极简的代码即可实现相同的验证效果，而无需像 Bend 那样浪费大量的 Token 和时间去构建从零开始的证明。

结论

“氛围编程”使得开发者能够绕过深入研究阶段直接获得结果。虽然这提高了开发速度，但也带来了一个隐患：AI 会顺从用户的指令去构建新事物，但它不会主动提醒用户，该领域已经存在更成熟、更高效的工业标准或学术成果。这使得开发者极易陷入构建“功能可用但设计落后”系统的困境。

Jemalloc 5.4.0 版本摘要

Jemalloc 5.4.0 版本包含了超过 160 个 commit，重点在于清理技术债务，包括代码重构、错误修复、提升测试覆盖率、清理选项以及改进可移植性。

新特性

• 内存锁定与统计：新增 EXTENT_ALLOC_FLAG_PINNED 标志，允许自定义 extent 分配钩子标记不可回收的映射（例如 HugeTLB 页面），以便在衰减（decay）和清除（purge）流程之外优先复用。同时增加了相关的 mallctl 接口，用于报告锁定内存的使用情况及相关的互斥锁统计。
• CPU 亲和性：通过 thread.arena 支持恢复基于每个 CPU 的 arena 选择功能。
• 统计数据优化：改进了人类可读格式与 JSON 格式 malloc 统计数据的对齐。
• C++ 优化：将运行时选项 experimental_infallible_new 替换为编译时选项 --enable-cxx-infallible-new，从而支持编译器级别的优化，并修复了 new(std::nothrow) 的契约问题。

不兼容变更

• tcache 策略调整：tcache 的填充（fill）和保留（retention）目标现在根据 GC 事件观察到的需求按 bin 进行调整，取代了原有的固定填充/刷新策略。
• 选项清理：移除了七个旧的非实验性控制参数（如 lg_tcache_nslots_mul、tcache_nslots_small_max 等）。相关的 malloc_conf 设置将被静默忽略，仅保留 tcache_ncached_max。

错误修复

• 错误码保留：在 free、free_sized、free_aligned_sized 以及基于 process_madvise 的页面清除过程中保留 errno。
• 安全性与标准合规：修复了 size classes 的数值溢出检查；使 free_sized() 和 free_aligned_sized() 能够接受 NULL 指针（符合 C23 标准）。
• 生命周期与并发：解决了 TSD（线程特定数据）生命周期的边缘情况；修复了 arena_reset 过程中潜在的死锁；修复了 SAN 中 prof-sampling 与 guard-page 交互的错误。
• 其他：修复了 THP sysfs 文件打开时的 O_CLOEXEC 使用问题，以及 malloc_stats_print 输出中的重复字段问题。

优化与重构

• 模块化重构：
  • 将 jemalloc 的前端模块化，从 jemalloc.c 中提取出 arena 管理、初始化、fork 编排和分配调度等功能，解耦了 tcache 与 arena 的所有权。
  • 简化了 ctl 分发机制，并按子系统组织 ctl.c。
  • 引入了 OS 抽象层，将平台相关的 I/O、时间、同步、CPU、虚拟内存、atfork、错误处理、配置访问等操作移出分配器核心代码。
• 性能与稳定性优化：
  • 限制了 base-block 的增长启发式算法，以防止在极端竞争条件下出现虚拟内存耗尽。
  • 将后台线程的生命周期和状态操作移至独立的后台线程模块。
  • 简化了页面分配边界，移除了过时的 pai_t 抽象。
  • 重构了统计数据的收集与渲染流程，将其分为独立的收集和发射阶段。

可移植性改进

• 标准兼容性：使用标准 C++ 替换了 std::__throw_bad_alloc；在 arena_s 中针对 C99 及更新标准使用了柔性数组成员。
• 平台特定修复：
  • 修复了 macOS 上的 malloc_getcpu、编译警告以及 TSD 清理问题。
  • 修复了 MinGW 构建中的 TSD 清理问题。
  • 修复了 GCC 16 的编译警告。
• 系统功能改进：使用 CLOCK_MONOTONIC 进行后台线程睡眠，防止时钟回退导致停顿；优化了 PID 命名空间符号链接的解析，使其不再依赖 glibc 的特定函数。

如何利用大语言模型（LLM）辅助写作

本文探讨了如何将大语言模型（LLM）作为高效的“文字编辑”而非“代笔作者”来使用，旨在利用其优势提升写作质量，同时避免因过度依赖 AI 而导致文章失去个人特色、陷入“AI感”的困境。

核心原则：两项黄金规则

为了防止写作风格被 AI 同质化，作者提出了两条严格的规则：

1. 绝不使用 LLM 建议的任何具体措辞 LLM 非常擅长选择悦耳但平庸的短语（类似于杂志标题的风格）。如果直接采用模型的建议，文章会变得像“人工合成的芝士”一样失去个性的质感，进入“恐怖谷”效应。即使模型提供的词句看起来比原稿更好，也应将其视为禁区，以保护作者独特的表达声音。

2. 避免鼓励 LLM 天生具有“迎合性”，往往会对初稿进行过度赞美。这种鼓励是有害的，因为它可能诱导作者在初稿质量不佳时盲目自信，从而跳过必要的深度修改和重构过程。作者建议在提示词中明确禁止模型进行鼓励，并对模型的赞美保持高度警惕。

LLM 的有效用途：识别机械性问题

尽管不应采纳其具体的措辞，但 LLM 在执行枯燥、机械的检查任务方面具有显著优势。它们可以精准地识别以下问题：

• 语法与风格问题： 过度使用被动语态、动词名词化、重复使用相同的表达方式。
• 冗余词汇： 识别文中散落的无意义填充词（如 "very", "actually", "really" 等）。
• 结构缺陷： 指出段落逻辑顺序不当或可以移动以提升清晰度的段落。

推荐的工作流程

作者建议通过以下步骤实现高效协作：

1. 识别问题： 要求模型指出文章中的具体问题。
2. 自主重写： 作者根据识别出的问题，自行重新撰写相关的段落或句子。
3. 对比评估： 将原稿与修改稿同时交给模型，询问哪一个更好。注意： 为了避免模型因“迎合”而给出偏差评价，在进行此步时，不应让模型知道哪一段是经过编辑的。

总结

通过将最枯燥的检查工作外包给模型，同时严格拒绝其对具体词句的干预，作者可以保持个人声音的完整性，同时实现更快速、更高质量的写作过程。

ZCode 隐私泄露事件摘要

事件概述

研究人员 ferstar 通过逆向工程发现，由北京 Z.ai 公司开发的 AI 编程桌面应用 ZCode 在用户登录状态下，会静默地将用户的整个工作区打包并上传至阿里云 OSS。上传的内容不仅包括当前文件，还涵盖了完整的 .git 历史记录、LFS 资产缓存、reflogs 以及全局应用配置。

技术细节与数据内容

• 上传内容构成：在一次针对 42,411 个文件的快照测试中，.git 目录占据了上传负载的 86.6%。这包括了整个仓库的开发史，意味着即使是已删除的 API 密钥、未推送的分支名称、内部主机名等敏感信息也会随之泄露。
• 加密机制：ZCode 使用“信封加密”（Envelope Encryption）。数据首先通过对称密钥加密，随后该对称密钥被服务器提供的 RSA-OAEP 公钥加密。由于对应的私钥仅保存在 Z.ai 的云端，用户或客户端本身无法解密已上传的加密存档。
• 上传流程：客户端向 zcode.z.ai 请求凭证，获取 OSS 签名及 RSA 公钥，随后在本地将工作区打包为 tar.gz，使用 AES-256-CTR 加密后直接 POST 到阿里云 OSS，最后通过回调向 Z.ai 后端注册快照。

规避机制与隐私政策失效

• 开关无效性：用户在设置中开启或关闭“优化体验”（仅控制数据是否用于模型训练）或“仓库快照索引”（仅控制服务器是否索引快照），都无法阻止数据上传。
• 底层执行：上传行为并非由 AI Agent 的工具集执行，而是由一个在启动时无条件实例化的“主机级侧边程序”（host-level sidecar）完成。这种设计使得上传过程对 Agent 本身是不可见的，也无法通过 Agent 的权限设置进行拦截。
• 隐私政策漏洞：ZCode 的隐私政策仅提到会收集“对话期间提交的文本、文件和代码”，并未提及会打包并上传完整的仓库历史记录。

与其他事件的对比

研究者将 ZCode 与此前 xAI 的 Grok Build 事件进行了对比。Grok Build 的数据上传被视为“过失性”行为（由于配置疏忽导致的同步问题且日志透明）；而 ZCode 的行为更具“蓄意性”，表现为：

1. 采用只有服务器能解密的加密方式。
2. 界面开关仅具装饰性，无法阻止上传。
3. 即使用户删除本地待上传存档，客户端也会持续尝试重新打包上传。

防御建议

目前有效的防御手段是在文件系统层面锁定 checkpoints 目录，使其变为不可写。这会使 ZCode 的“检查点回滚”功能失效，但可以阻止静默上传。

• Linux: 使用 sudo chattr +i ~/.zcode/v2/checkpoints
• macOS: 使用 chflags uchg ~/.zcode/v2/checkpoints

核心启示

该事件强调了即使使用开源权重模型（如 GLM 系列），如果运行模型的是闭源的托管环境（Harness/Runtime），用户的本地隐私仍面临严重威胁。运行本地 AI 代理时，必须审查其运行环境（Runtime）的传输行为及加密逻辑。

x86 模拟中的内存模型挑战总结

本文探讨了在 ARM 架构上模拟 x86 架构时，由于两者内存模型差异而带来的核心技术难题，特别是针对 FEX-Emu 等模拟器的性能影响。

1. 内存模型的根本差异

• x86-TSO (Total Store Ordering)：一种严格的内存一致性模型。程序员可以预期内存写入在执行后对所有处理器立即可见，这种模型非常符合编程直觉，但限制了硬件的优化空间。
• ARM 弱排序模型 (Weak Ordering)：一种高度放松的模型。为了追求能效和性能，ARM 允许处理器延迟内存可见性，除非显式使用指令进行同步。
• 模拟困境：在较早的 ARMv8.0-a 架构上，为了模拟 x86 的严格顺序，模拟器必须将所有的 x86 内存加载转换为 ARM 的 load-acquire，将存储转换为 store-release。这种做法由于强制了过于严格的指令顺序，导致了巨大的性能开销。

2. 硬件改进与解决方案

• LRCPC 指令：ARMv8.3 引入了 LRCPC 指令及其对应的 RCpc 模型，这更接近 x86 的需求。使用该指令后，模拟性能得到了显著提升，几乎可以达到原生加载/存储的水平。
• Apple M1 的路径：Apple 在其芯片中直接实现了 x86-TSO 硬件模式。当该模式开启时，常规的 ARM 加载/存储指令会改变行为以匹配 x86 要求，从而实现了极高的模拟效率。
• Oryon-3 架构：Qualcomm 的新架构通过实现“相干缓存行 (coherent cachelines)”，在处理原子操作时表现出色，接近 x86 的性能。

3. 内存对齐与 Split-lock 问题

• 对齐冲突：x86 允许非对齐内存访问，而 ARM 传统上要求“自然对齐”。非对齐访问在 ARM 上会触发“对齐错误 (alignment fault)”。
• FEX 的补丁机制：为了处理对齐问题，FEX 使用“补丁点 (patchpoint)”技术。当检测到对齐错误时，它会将代码动态修改为基础指令并添加内存屏障（DMB），但这会造成性能损失。
• Split-lock（跨缓存行原子操作）：这是最严峻的挑战。x86 保证跨缓存行的原子操作也是原子的，而 ARM 硬件通常无法直接支持。
  • 在 ARM 上模拟 Split-lock 需要频繁在内核态和用户态之间切换，导致性能极低。
  • 目前模拟器的实现属于“尽力而为”，在某些极端情况下可能导致数据撕裂（data tearing）。
  • 作者提出通过增强 128 位 CASP 指令的功能来解决这一问题，使其能安全地跨越边界。

4. 未缓存内存 (Uncached Memory) 的性能陷阱

• 背景：在涉及 PCIe GPU 的游戏场景中，通常需要使用“未缓存 (Uncached/Write-Combine)”内存进行数据传输。
• 性能崩溃：在 ARM 上模拟 TSO 语义下的未缓存内存存储操作极其缓慢（带宽损失可达 816 倍）。这会导致依赖 PCIe GPU 的游戏出现严重的掉帧现象（甚至低于 1 FPS）。
• 应对策略：
  • UMA 系统：在统一内存架构（如移动端 SoC）中，由于 CPU 和 GPU 共享内存，可以通过驱动程序强制使用“已缓存 (Cached)”缓冲区来规避此问题。
  • PCIe 局限性：对于拥有独立 PCIe GPU 的系统，由于 ARM 现有扩展（如 FEAT_LRCPC 系列）未能解决未缓存内存存储的 TSO 模拟问题，性能瓶颈依然存在。

https://www.nytimes.com/2026/09/18/business/warren-buffett-berkshire-chairman.html

文章摘要：性、AI 与启示录

本文深入探讨了一个高度专业化且相互交织的硅谷亚文化——“理性主义者”（Rationalists）——如何从一个边缘的网络社群，演变为对人工智能（AI）安全政策、全球政治及人类未来的深远影响力量。

1. 导火索：Jacob Coxon 的辞职

2026年9月，Anthropic 研究员 Jacob Coxon 辞职并公开警告称，AI 开发者们真心认为 AI 可能在十年内毁灭人类。这一言论迅速引发全球关注。然而，文章指出，这类关于“末日”的预警并非偶然，它们源自一个特定的、拥有独特信仰体系和社交结构的互联网亚文化。

2. 理性主义运动的核心

该运动的灵魂人物是 Eliezer Yudkowsky。他通过 LessWrong 社区和其著名的同人小说《哈利·波特与理性方法》（HPMOR）构建了一套完整的思维范式。

• 核心教义：提倡克服认知偏差，并强调“英雄式责任”（Heroic Responsibility），即个人必须为人类的存续承担全部责任。
• 社群特征：该群体多为高智商、具有神经多样性（如自闭症谱系）的工程师和数学家。他们通过仪式（如“世俗冬至”）、共同的词汇和深度的社交纽带形成了类似宗教的凝聚力。

3. 亚文化的阴暗面：心理控制与极端主义

文章揭示了该社群在追求“理性”过程中产生的病态倾向：

• 心理“调试”：某些组织（如 CFAR 和 Leverage Research）利用“调试人类心理”的名义，对成员进行深度且具侵入性的心理干预，导致部分成员出现心理健康问题。
• 权力与性关系：社群成员在职业、居住和情感上高度重叠。这种高度交织的社交网络使得成员在面对滥用行为或不当权力时，难以通过常规渠道进行申诉或退出。
• 极端主义：社群内部出现了名为“Zizians”的极端分裂派系，其基于社群逻辑构建的激进信仰最终导致了暴力事件和人员伤亡。

4. 资本与政治的渗透：从 EA 到政府

理性主义通过与**有效利他主义（Effective Altruism, EA）**的融合，成功获取了巨大的政治与经济影响力。

• 长期主义（Longtermism）：EA 的资金流向从传统的慈善转向了“预防人类灭绝”，使 AI 安全风险成为了其核心议题。
• 政治关联：通过亿万富翁 Peter Thiel 的资助，理性主义中的部分思想（如新反动主义 Neoreactionary）渗透进了美国政界。JD Vance 等政治人物的崛起，被视为该网络在政府层面的体现。Thiel 的影响力甚至将“末日警告”与反监管、反民主的政治议程挂钩。

5. 结论：谁来监管监管者？

文章最后提出了一个严峻的问题：利益冲突。 目前的 AI 安全评估体系（如 METR）与 AI 开发实验室（如 Anthropic、OpenAI）之间存在极深的社交与职业联系。评估者、开发者、资助者和政策制定者往往属于同一个社交圈、同一套价值观体系。

这种“精英治理”的逻辑认为，只有最聪明的人才配拥有超越常规规则的自由。这种“智力豁免权”不仅可能导致监管俘获（Regulatory Capture），也使得公众难以判断，那些关于 AI 末日的警告究竟是真诚的生存警示，还是为了推动特定监管体制而进行的策略性行动。

日本百岁老人人数首次突破10万

根据日本厚生劳动省的数据，日本百岁及以上人口数量首次突破10万大关，目前已达到107,677人，位居世界首位。在这一群体中，女性占比高达88%。目前日本最长寿的女性是来自京都的114岁 Kishimoto Fuyo，最长寿的男性是来自熊本的112岁 Kato Hikaru。

长寿的主要因素

专家认为，日本人的长寿主要归功于健康的饮食习惯和积极的生活方式：

• 饮食结构： 日本饮食以鱼类、蔬菜和米饭为主，饱和脂肪的摄入量远低于西方饮食。
• 日常活动： 老年人普遍保持着步行、使用公共交通、骑行和拉伸等运动习惯。
• 科技与医疗： 医学进步和新技术的应用提供了有力支持。例如，针对老年群体开发的动力外骨骼（辅助身体移动）和自动调焦眼镜等产品。

人口结构危机

尽管长寿现象令人欣喜，但日本政府也面临着维持社会保障体系可持续性的严峻挑战。日本正面临着严重的“生存危机”和“无声的紧急情况”：

• 低生育率： 日本去年的总和生育率降至1.14的历史低点。
• 人口萎缩： 预计到2070年，日本总人口将从2008年峰值的1.28亿下降至8700万。
• 老龄化加剧： 目前65岁及以上人口占总人口的30%，预计到2070年这一比例将接近40%。

应对困难与阻碍

尽管政府实施了多项补贴计划以鼓励生育，但效果并不明显。专家分析其原因包括结婚率下降、女性更多进入职场以及养育成本增加等复杂因素。此外，虽然移民人数近年来有所上升，但外国人仅占总人口的3%，且社会对进一步扩大移民规模存在反对情绪。

数据准确性说明

值得注意的是，也有研究对全球百岁老人数据的准确性提出了质疑。部分研究认为，由于记录不全、出生证明缺失，或者为了领取养老金而隐瞒老人死亡情况，可能导致统计数据存在偏差。

ZCode 静默上传工作区及 Git 历史记录调查摘要

核心发现

调查发现，智谱（Zhipu）官方 AI 编程应用 ZCode 在用户登录状态下，会静默地将整个工作区打包并上传至阿里云 OSS。打包内容不仅包含当前工作代码，还包括完整的 .git 目录（如 LFS 缓存、提交历史、reflogs 等）以及全局应用配置。

加密机制与数据控制权

ZCode 采用了“信封加密”（Envelope Encryption）技术，其特性导致用户对上传的数据失去控制权：

• 加密流程：使用 AES-256-CTR 加密文件内容，并使用由服务器在请求时动态提供的 RSA 公钥对对称密钥进行封装。
• 控制权归属：解密所需的 RSA 私钥仅存储在服务器端，用户和客户端均无法解密本地存储的加密文件。这种设计表明，该功能的核心目的并非用于用户端的本地备份或跨设备同步，而是确保服务器能够读取代码。

数据构成分析

上传的负载中，.git 目录占据了约 86.6% 的比例，这意味着云端获取的是仓库自创建以来的完整演进历史：

• Git LFS (56.8%)：所有下载过的二进制资产和大型媒体文件缓存。
• Git Objects (29.6%)：完整的提交历史（commits、trees、blobs）。
• Git Logs (0.2%)：本地分支的操作痕迹（reflogs）。
• 源码与文档 (13.4%)：当前项目的源代码及配置文件。 上传后，服务器不仅拥有当前代码，还能获取历史提交中可能存在的敏感信息（如已删除的 API 密钥）、未推送的分支名以及内部配置信息。

设置开关的失效性

ZCode UI 提供的隐私设置并不能阻止该后台上传行为：

• “优化体验” (Optimize Experience)：仅控制数据是否被授权用于模型训练，不影响快照的捕获与上传。
• “仓库快照索引” (Repo Snapshot Indexing)：仅控制服务器是否对上传的快照进行索引，不影响本地打包和上传。 代码逻辑显示，只要用户已登录，该上传进程就会在启动时无条件实例化，没有任何基于用户偏好的拦截检查。

隐私政策差异

ZCode 的隐私政策明确提到会收集“对话期间提交的文本、文件和代码”，但并未提及会静默打包并上传整个工作区及完整的 Git 历史记录。

防御手段

由于 ZCode 在检测到本地快照文件被删除后会自动重新打包，简单的手动删除无法阻止上传。有效的防御方案是通过操作系统层面的文件系统权限，禁止应用对特定目录进行写入操作：

• macOS 用户：使用命令 chflags uchg ~/.zcode/v2/checkpoints 锁定目录。
• Linux 用户：使用命令 sudo chattr +i ~/.zcode/v2/checkpoints 锁定目录。

注：实施该防御措施后，ZCode 的“快照回滚/时间轴”功能将无法使用，但正常的 AI 对话、代码补全及工具执行功能不受影响。

Flet 1.0 框架概述

Flet 1.0 是一个允许开发者仅使用 Python 编写代码，即可构建美观的跨平台应用程序（涵盖 Web、桌面和移动端）的框架。其核心理念是让开发者无需具备前端开发经验，通过单一的代码库即可实现多平台部署。

支持平台

• 移动端：iOS, Android
• 桌面端：Windows, macOS, Linux
• Web端：浏览器运行

核心功能与特性

• 丰富的 UI 控件：提供超过 150 种预设控件和服务，包括布局、导航、表单、对话框等，并支持高度自定义的颜色、字体和主题。
• 移动端 Python 生态支持：通过预构建的软件包，支持在 iOS 和 Android 上运行 NumPy、pandas、Pillow 和 cryptography 等主流 Python 库，简化了原生依赖的编译工作。
• 完善的打包与发布：
  • 使用 flet build 命令将应用打包为桌面、移动端或 Web 应用。
  • 支持将应用发布至 App Store 和 Google Play。
  • Web 部署方案：可通过 Pyodide 和 WebAssembly 在浏览器中直接运行 Python，或通过服务器端运行并实时向客户端发送 UI 更新。
• 测试与质量保障：支持使用 pytest 进行集成测试（模拟点击、输入等用户流），并能在 iOS 和 Android 上通过截图进行视觉差异检测。
• 可扩展性与 AI 集成：
  • AI 辅助：通过 Flet MCP 连接编程助手，获取版本特定的 API 信息、示例、图标和 CLI 选项。
  • 自定义开发：支持使用 Python 编写自定义控件，或通过封装 Flutter 软件包来扩展新的 UI 组件和平台功能。
• 无障碍支持：支持屏幕阅读器、自定义语义、键盘快捷键以及 UI 无障碍信息的检查，确保应用对更多人群友好。

Flet Studio

Flet Studio 是一个无需安装、基于浏览器的在线开发环境，其工作流程包括：

1. 探索起点：从示例库（Gallery）中选择模板进行修改。
2. 在线开发：直接编辑代码，并利用 AI 代理获取编程帮助。
3. 分享成果：通过发送链接或下载项目到本地继续开发。

编程智能体测试框架设计的实证研究总结

研究背景与目的

当前的自主编程智能体（Coding Agents）在执行长程软件工程任务时，其性能深受“测试框架（Harness）”设计的影响。然而，现有研究通常将测试框架视为一个整体进行评估，难以明确各组件对性能的具体贡献。本研究旨在通过分解测试框架，研究三个核心组件对智能体性能的影响：规划（Planning）、动作空间（Action Space）和上下文管理（Context Management）。

实验设计

研究人员开发了一个轻量化编程测试框架，在保持执行循环固定的前提下，通过改变上述三个组件进行变量控制。实验在 SWE-Bench Verified 和 Terminal-Bench 2.1 两个基准测试集上进行，针对四种模型评估了 176 种匹配设置，涵盖了五种上下文管理策略、四种上下文窗口预算以及针对规划和动作空间的消融实验。

核心研究发现

1. 上下文管理 (Context Management)

• 预算相关性：随着上下文窗口预算的收紧，上下文管理的重要性显著增加。其核心收益在于防止智能体因“上下文溢出（Context-overflow）”而导致的失败。
• 最优策略：研究发现，采用**“先进行基于规则的剔除（Rule-based elision），再进行基于 LLM 的摘要（LLM-based summarization）”**的阶段性策略，在整体效率上表现最强。
• 冗余设计：实验证明，增加“使被剔除内容可恢复（Recoverable）”的机制会引入额外的复杂性，但由于模型很少使用这些机制，因此对准确率并无提升。

2. 规划 (Planning)

• 模型差异化作用：
  • 对于弱模型，规划充当了“准确性支架（Accuracy scaffold）”，能够显著提升其任务完成的准确度。
  • 对于强模型，规划的主要作用转变为“成本节省者（Cost saver）”，对准确率的提升作用有限。

3. 动作空间 (Action Space)

• 工具依赖性：预定义的工具（Predefined tools）有助于提升 Bash 能力较弱的模型表现。
• Bash 能力的影响：具备强 Bash 能力的模型在仅使用 Bash 接口的情况下即可高效运行，且能显著降低成本，特别是在以命令行为中心的任务中。

轨迹层面分析 (Trajectory-level Analysis)

通过对执行轨迹的深入分析，研究解释了上述效应的内在逻辑：

• 上下文管理：在不显著改变智能体行为的前提下，延长了执行轨迹。
• 规划：改变了执行轨迹的终止位置（即决定任务何时停止）。
• 动作空间：改变了代码编写的粒度。

研究贡献

本研究为针对特定模型能力和预算限制进行“感知型（Aware）”测试框架设计提供了理论依据，并提供了一个模块化的框架，用于评估未来测试框架的各个组件。

总结：理查德·斯托曼——数千人死亡，数百万人丧失自由 (2001)

本文是理查德·斯托曼（Richard Stallman）在2001年美国遭遇恐怖袭击后撰写的评论，旨在警示政府可能在追求安全的过程中，对公民自由造成比袭击本身更严重的“二次伤害”。

核心论点与比喻

斯托曼通过神经损伤的原理进行类比：神经损伤最严重的破坏往往发生在初始创伤后的“二次伤害”阶段。他警告称，如果美国国会通过过度扩张的“预防措施”来剥夺美国立国之本——自由，那么恐怖袭击造成的次生损失将更加深远。

对大规模监控的界定

斯托曼对安全措施的性质进行了区分：

• 合理的限制： 他认为，只要安检仅限于检查武器，且在未发现武器时不保留个人记录，这类措施仅属于“生活上的不便”，并不威胁公民自由。
• 威胁自由的措施： 他反对针对电话通话、电子邮件及个人物理移动进行大规模的监控。

具体威胁领域

文章指出了几个具体的潜在威胁：

1. 面部识别技术： 尽管面部识别在实际拦截中的有效性尚未得到证实，但相关机构仍试图利用袭击后的契机推动大规模部署。
2. 加密软件后门： 斯托曼指出，当时已经出现了要求在加密软件中为政府设置“后门”的提案。
3. 过度授权的军事权力： 他批评国会向总统授予了在报复行动中使用的“无限权力”，认为这种在情绪化时刻给予总统“空白支票”的做法，是重蹈美国陷入越南战争错误的覆辙。

行动呼吁

斯托曼呼吁民众不要等待，应立即向民选代表和总统表达立场，反对那些正在起草中、可能以牺牲公民自由为代价的立法提案。

产品决策的核心：决定“不做什么”

本文探讨了一个核心观点：产品开发中最关键的决策往往不是决定构建什么，而是决定不构建什么。

“一刀切”平台的陷阱

作者指出，许多团队在面对复杂需求时，倾向于构建“文档中心”或“通知中心”这类通用型平台。这些功能通常被视为解决遗留系统（如 PDF 账单）或合规性需求的“懒惰方案”。

然而，这类功能极易陷入“功能蔓延”的怪圈：

• 过度复杂化：利益相关者不断要求增加细枝末节的功能，导致原本简单的工具演变成类似于 Google Drive 或 Gmail 的复杂系统。
• 高昂的维护成本：除了初始构建成本，这些平台还需要长期的维护，以应对操作系统（如 iOS、Android）更新带来的技术挑战。

应对策略：针对用例，而非平台

为了避免陷入上述陷阱，作者建议：

1. 基于用例评估：不要为了解决一个问题而先构建一个庞大的平台。应当对每个具体的使用场景进行严谨评估，判断其是否真的能“让船开得更快”。
2. 关注“运行成本”：在决策时，不仅要看构建成本，更要量化多年积累的运行和维护成本。
3. 拒绝“一刀切”：抵制构建万能平台的诱惑，即使现有的简单方案并不完美，也比维护一个臃肿的平台更明智。

组织文化与“减法”的难度

作者认为，产品管理面临的一个深层障碍是组织文化的偏差：

• 奖励“创造”而非“删除”：现有的企业文化倾向于奖励开发和发布新功能的人，而将维护、审查和删除功能视为“次要工作”。
• 认知的局限性：研究表明，人类倾向于忽视“减法”带来的改进，即便移除某些内容能显著提升销售额或用户体验。

战略聚焦的价值

文章最后通过史蒂夫·乔布斯（Steve Jobs）1997年的产品矩阵为例，强调了精简的重要性。乔布斯通过砍掉大量冗余产品线，将工程人才集中在极少数核心产品上，从而实现了企业的爆发式增长。

总结建议： 产品团队应当对新功能的加入保持极端挑剔，并对移除冗余功能保持“军事化”般的果断。成功的关键在于将精力集中在对客户真正有价值的核心任务上，实现“一次只做一件事”（Une chose à la fois）。

古希腊语中的消失语言：前希腊语（Pre-Greek）

在古希腊语中，存在着约1,000个无法追溯到原始印欧语（PIE）的词汇。这些词汇包括一些看似典型的希腊词汇，如“橄榄”（elaía）、“迷宫”（labýrinthos）、“阿喀琉斯”（Akhilleús）以及“雅典”（Athênai）和“阿瑞斯”（Árēs）等神名。这些语言学上的谜团揭示了在印欧语系进入爱琴海地区之前，当地曾存在着被称为“前希腊语”的语言层。

语言分层理论

语言学家利用“语言分层”的概念来解释这种现象，将其类比为地质层：

• 底层语言 (Substrate): 指社会地位较低、最终被取代但仍在其后继语言中留下痕迹的语言（如前希腊语）。
• 上层语言 (Superstrate): 指具有社会统治地位（军事、经济或技术领先）的语言（如古希腊语）。
• 旁层语言 (Adstrate): 指由于地理邻近或文化声望而对邻近语言产生影响的语言（如拉丁语对日耳曼语的影响）。

如何识别借词

识别一个词是否为外来借词主要依赖以下几种证据的汇聚：

1. 缺乏印欧语词源: 词汇在印欧语系中找不到对应的同源词，且常在其他地中海语言中发现类似的“同族词”（confamiliars）。例如，“酒”（oînos）在拉丁语、希伯来语等语言中都有类似形式，但均无法追溯至印欧语祖语。
2. 语音特征异常: 某些词汇包含在印欧语演化规律中不可能出现的音序（如以 /dn/、/kn/ 或 /ps/ 开头的词），或者包含在印欧语中罕见的音（如 /b/）。
3. 随机的语音变体: 借词常表现出不符合规则演化规律的随机拼写或发音差异，而非规律性的方言差异。
4. 特定的语义范畴: 借词通常集中在移民进入新环境后需要学习的领域，如植物、动物、地形、矿物、农业及简单工具。
5. 同义词对: 一种语言中若针对同一概念存在两套词汇（一套本土，一套借词），通常暗示了文化层级的叠加。

前希腊语的特征与分布

研究表明，前希腊语具有显著的形态特征，这些特征在词汇和地名（Toponyms）中表现尤为明显：

• 特征后缀: 包括 -nth（如 Hyakinthos）、-ss（如 thalassa）、-n（如 Athens）和 -mn（如 Lemnos）。
• 特征前缀: 包括 a-、ka- 和 s-，多见于动植物名称。

通过对地名的分析，可以大致绘制出前希腊语底层语言曾分布的区域，其范围覆盖了希腊本土并延伸至安纳托利亚（小亚细亚）。

前希腊语的构成：两种影响来源

学界普遍认为，古希腊语的词汇库受到了至少两种不同文化来源的影响：

1. 古欧洲/前希腊底层语言: 这类语言主要贡献了关于自然现象（动植物、地形、矿物）的词汇。由于这些词汇在欧洲各地的古欧洲农民群体中具有一定的同质性，因此在不同的印欧语系中也能看到类似的借词。
2. 米诺斯文明 (Minoan) 的影响: 米诺斯文明作为一种高度发达的“旁层”或“底层”文化，主要贡献了文化与技术相关的词汇，如艺术、珠宝、建筑、服饰及奢侈品。例如，“羊毛”（mallós）和“浴缸”（asáminthos）等词汇极可能源自米诺斯文化。

总结而言，古希腊语并非单一来源的产物，其词汇库是数千年移民、贸易和文化碰撞后的“化石记录”，反映了印欧人与当地古欧洲文明及米诺斯文明复杂的互动历史。

用户对微软及其生态系统的批评摘要

作者通过个人经历表达了对微软及其商业行为的强烈不满，主要观点如下：

• 软件限制与强制捆绑：作者在尝试使用学校提供的机构账户通过 Mac 编辑 PowerPoint 文档时，收到“账户不允许在 Mac 上进行编辑”的提示。作者认为这是一种不道德的商业手段，旨在通过合同条款限制跨平台功能，迫使机构和用户购买并使用 Windows 设备。
• Windows 系统及应用的问题：作者对 Windows 生态系统提出了多项批评，包括：
  • 广告问题：在 Windows 应用中出现广告。
  • 性能问题：应用资源占用过高（例如计算器应用消耗大量内存）以及系统漏洞（Bugs）频发。
  • 隐私与安全担忧：提及了间谍行为以及 Copilot 和 Windows Recall 等功能带来的安全隐患。
• 呼吁行动：作者呼吁用户停止使用 Windows 系统以及专有的文档格式，认为只有通过团结起来改变现状，才能应对目前的困境。

无限参数大语言模型：从实时数据中生成并调整权重

核心问题

传统的语言模型（LLM）在预训练完成后，其参数权重即被冻结，无法直接学习交互过程中的实时数据（如用户提供的实时事实或纠正）。目前，为了让模型吸收新知识，通常采用上下文学习（In-Context Learning）或检索增强生成（RAG）的方式将信息放入提示词（Prompt）中。然而，这种方法存在以下局限性：

• 消耗上下文窗口：实时信息占据了宝贵的上下文空间。
• 信息不可持久化：信息在请求结束后即被丢弃，无法在不同会话间自然保留。
• 泛化能力有限：在提示词中学习的效果往往不如直接改变模型参数。

创新架构：无限参数 LLM (Infinite-Parameter LLM)

受混合专家模型（MoE）的启发，研究人员提出了一种能够通过实时数据直接“写入”权重的新型架构。

关键机制

1. 超网络生成权重：该架构使用一个紧凑的超网络（Hypernetwork），将运行时获取的数据转化为共享基础网络前馈层（Feed-forward weights）的低秩调制（Low-rank modulation）。这意味着模型的前馈权重不是从固定库中提取的，而是根据实时数据动态生成的。
2. 贝叶斯在线更新：不同于以往仅在读取上下文后即固化的权重生成器，该模型对生成器的潜在代码（Latent code）维护一个贝叶斯信念（Bayesian belief）。随着对话会话的进行，模型会在线更新这一信念，从而根据不断演进的认知重新推导有效权重。

技术优势

• 存储与容量的平衡：模型保持固定的存储占用，但由于权重是动态生成的，其能够编译出的有效权重空间在理论上是无限的。
• 计算效率：对于实时知识和行为的承载，将信息写入权重比在提示词中反复输入具有更好的计算摊销（Amortized compute）优势。
• 上下文优化：通过将知识转移到权重中，释放了上下文窗口，使模型能够处理更长或更复杂的任务。
• 持久性与泛化：知识和行为在多轮对话中具有持久性，且比上下文学习表现出更强的泛化能力。

评估方法

研究人员制定了一套专门的评估协议，旨在通过对比实验，精确测试该架构在处理实时数据时相对于传统的上下文学习（In-context learning）和检索（Retrieval）机制的表现。

Waymo 进入新加坡市场概览

Waymo 宣布计划在新加坡推出全电动自动驾驶共享出行服务，旨在支持新加坡的《2030年新加坡绿色发展蓝图》及智慧出行愿景，通过提供安全、高效、零排放的出行选择，助力新加坡的绿色转型。

核心功能与技术优势

• 全电动车队： Waymo 将使用配备第五代 Waymo Driver 系统的 Jaguar I-PACE 电动车型，并致力于尽可能使用可再生能源为车队供电。
• 先进感知技术： 车辆通过摄像头、雷达和激光雷达（LiDAR）构建 360 度全方位视野，感知范围可达 300 米，能够精准识别并预测行人、骑行者等弱势路用者的行为。
• 提升安全性与便利性：
  • 道路安全： 通过减少人为失误来降低交通伤亡。
  • 无障碍出行： 为老年人及无法驾驶的人群提供更多独立的移动选择。
  • 增强安全性交互： 利用视听信号与周围人群沟通驾驶意图，并配备“安全下车”功能以保护骑行者。
• 完善公共交通： Waymo 旨在通过与政府部门合作，实现与现有公共交通系统的多模态出行衔接。

实施路线图与时间线

Waymo 将采取循序渐进的分阶段方法进入新加坡市场：

1. 初期阶段（明年开始）： 进行手动驾驶，重点开展地图测绘（Mapping）和验证驾驶（Validation driving）。
2. 过渡阶段： 在经过培训的本地自动驾驶专家陪同下，开展自动驾驶测试。
3. 审批阶段（2027年）： 凭借收集的数据，向陆路交通管理局（LTA）寻求自动驾驶系统的正式审批。
4. 商业化阶段（2028年）： 计划正式开放商业化乘车服务。

运营经验与安全记录

Waymo 在美国拥有丰富的实战经验，包括：

• 在超过 15 个主要城市运营。
• 每周完成超过 50 万次行程。
• 在运营城市中，其引发伤害的事故率比人类驾驶低 94%。
• 在公共道路上行驶里程已超过 3 亿公里。

Waymo 将与新加坡交通部（MOT）和陆路交通管理局（LTA）密切合作，确保其技术和运营流程完全符合新加坡的法律法规及安全监管标准。

Cloudflare Quick Tunnels 概述

Cloudflare Quick Tunnels 提供了一种将本地服务器（localhost）快速转换为公开、加密 URL 的方案，旨在简化开发、测试以及 AI 编码代理（Coding Agents）的工作流。

核心功能

通过执行单一命令 cloudflared tunnel --url http://localhost:8000，用户可以将本地运行的服务直接暴露到互联网上。该过程无需注册 Cloudflare 账号，无需配置 DNS，也不需要手动开放任何入站端口。

工作原理与安全性

• 出站连接机制：cloudflared 建立一个仅限出站（outbound-only）的连接，指向最近的 Cloudflare 边缘节点。
• 安全性：流量通过 Cloudflare 网络传输，全程经过 TLS 加密，并具备 DDoS 防护功能。由于不开放任何入站端口，本地机器的安全性得以保障。
• 全球覆盖：利用分布在 335 多个城市的 Anycast 网络，确保来自不同地理位置的用户或 Webhook 都能通过最近的边缘节点访问。

主要优势

• 极速部署：无需注册、无需配置文件，可在几秒钟内生成可用的 URL。
• 零配置与零端口开放：自动化处理证书、路由和 DDoS 防护，实现“零”入站端口暴露。
• 环境适配性：支持任何 Web 框架、任何端口及任何技术栈。

针对 AI 代理（Agent Era）的专项优化

为了满足 AI 编码代理在构建、测试和评审循环中的需求，Quick Tunnels 引入了以下特性：

• 结构化 JSON 输出：通过标准输出（stdout）提供包含主机名、边缘节点和健康状态的 JSON 数据，方便编程代理直接解析，无需使用正则表达式处理日志。
• Webhook 就绪：支持将 Stripe、GitHub 或自定义回调直接指向实时生成的本地 URL，而非使用模拟数据（fixtures）。
• 临时性设计（Ephemeral by design）：隧道随进程结束而自动销毁，无需手动进行撤销或清理操作。

使用流程

1. 运行应用：在本地启动 Web 服务器（如 npm run dev）。
2. 开启隧道：运行 cloudflared tunnel --url http://localhost:[端口号]。
3. 分享链接：获取生成的 trycloudflare.com 域名并将其发送给队友、Webhook 或 AI 代理。

Uber 如何防御重试风暴：通过“错误所有权”机制实现上下文感知

问题背景

在复杂的微服务架构中，重试配置不当会导致“重试风暴”（Retry Storms）。当深层依赖服务发生故障时，上游服务往往会进行无差别的重试。由于当前的重试机制通常不具备“上下文感知”能力，无法区分错误是服务自身产生的（原因），还是仅仅从下游传递过来的（症状），这会导致重试流量在调用链中呈指数级放大，从而引发级联故障，破坏整个基础设施的稳定性。

传统的重试预算（Retry Budgets）虽然能限制重试总量，但无法感知跨服务的放大效应，且难以应对复杂的扇入/扇出模式。

核心解决方案：错误所有权 (Error Ownership)

Uber 开发了一种基于“错误所有权”的上下文感知机制，其核心思想是将错误分为两种类型：

1. 原因 (Cause)：服务在没有下游调用失败的情况下，自身产生了错误。此时该服务是错误的“所有者”。
2. 症状 (Symptom)：服务因为其下游调用失败而返回错误。此时该服务只是错误的“传播者”。

核心逻辑：重试应该仅针对“错误所有者”进行，而对于仅仅是“症状传播者”的服务，上游应停止重试，以防止流量在故障点周围不断放大。

技术实现架构

1. 服务依赖分析 (SDA) 与错误声明

Uber 利用“服务依赖分析解决方案”（Service Dependency Analysis Solution）来关联服务的入站失败与出站失败。

• 认领错误 (Claiming)：如果服务发现错误源于自身（无下游失败），它会在响应头（如 x-uber-error-claim）中“认领”该错误。
• 放弃认领 (Unclaiming)：如果服务发现错误是由下游引起的，它会“放弃认领”该错误，并将其标记为未认领状态。

2. 决策矩阵与重试逻辑

调用方（Caller）根据响应头中的错误状态执行以下逻辑：

• 如果收到已认领的错误 $\rightarrow$ 认为故障在下游服务本身，允许重试。
• 如果收到未认领或缺失声明的错误 $\rightarrow$ 认为故障正在向上游传播，停止重试并透传错误。

3. 处理边缘情况

• 偶然错误 (Coincidental Errors)：为了防止 SDA 在处理并发故障（如自身故障与下游故障同时发生）时误判，系统利用历史失败模式的记忆功能进行校验，确保不会错误地抑制合法的重试。
• 保证至少一次重试 (At-Least-Once Retries)：通过引入“重试准则满足”信号，确保即便某些链路上的服务未配置重试，也能通过中间件协调，维持必要的可用性而不引发风暴。
• 上下文丢失 (Context Drop)：若服务内部上下文丢失导致无法精确关联，该机制会将重试行为“向左移动”（即限制在更靠近故障点的层级），从而最大限度缩小重试风暴的半径。

实际成效

该机制已在 Uber 的服务网格中全面上线。

• 实战案例：在 2025 年 11 月的一次大规模故障中，该机制自动限制了故障扩散。它阻止了向故障服务发送多达 20 万个额外请求，并在整个服务网格中累计拦截了约 950 万次无意义的冗余请求，避免了故障长时间持续。
• 量化指标：
  • 重试风暴半径 (Retry Storm Radius)：通过该机制，用户 API 的最大重试风暴半径从之前的 25 大幅降低至 3，平均半径从 20 降至 2。

通过将重试限制在仅能真正解决问题的“错误所有者”服务上，Uber 成功防止了请求的指数级扇出，有效保护了基础设施免受级联故障的影响。

https://news.ycombinator.com/item?id=49742976

迈向自动驾驶的代码库：摘要

现状与挑战：幻灭之谷

当前的 AI 代理（Agents）在处理复杂软件开发任务时表现并不理想，导致行业进入了技术采用周期的“幻灭之谷”。虽然许多组织尝试通过大量消耗 Token 来驱动开发（tokenmaxxing），但产出的往往是大量质量存疑的代码，而非高质量的软件，投资回报率（ROI）较低。

工程师角色的转变

随着开发流程向自动化演进，工程师的工作重心将从编写代码或提示词（prompts）转向更高价值的战略任务：

• 提出核心创意： 利用领域专业知识设计具有竞争力的功能（Killer features）。
• 设计高杠杆架构： 通过优化数据模型、简化复杂性、构建测试脚手架等方式，为长期的产品迭代和降低复杂度提供保障。

应由 Agent 处理的任务范围

文章认为，许多具有明确语义或重复性的工作应转移到 GPU 上处理，包括：

• 缺陷管理： 自动检测、定位并修复 Bug，以及处理生产环境中的错误（如自动修补导致 500 错误的变更）。
• Agent 优化： 自动化 Agent 提示词的优化、回测与部署。
• 前端一致性与体验： 确保 UI 设计系统（字体、颜色、间距等）的统一，并处理应用打磨（Application polish）任务，如无障碍访问、表单状态保留等。
• 增长优化： 自动运行增长实验（如转化率优化、营销页面迭代）并根据用户反馈进行迭代。

缺失的关键原语（Primitives）

要实现真正的“自动驾驶”，开发工具链需要建立以下基础组件：

• Agent 可读的开发环境（Agent-legible dev environments）： 消除 Agent 的“盲区”。Agent 需要能够端到端地测试第三方集成，并拥有类似浏览器的环境来观察前端行为。
• 全局记忆（Global Memory）： 在整个工具链（从代码编写到代码审查，再到 SRE 运维）中实现知识共享，确保 Agent 不会重复犯同样的错误。
• 防止代码库腐烂： 自动清理死代码，确保类型系统和数据模型始终与产品需求保持一致。

核心瓶颈：开发环境而非模型

文章强调，限制开发代理（Dev Agents）能力的主要因素是它们所操作的环境，而非模型本身。 Agent 往往在无法观察到的地方（如竞态条件、难以观察的数据形状）产生错误，这些“盲点”导致了信任缺失，进而限制了自动化的程度。

实施路径：提升 Agent 就绪度

工程团队目前最重要的投资应该是构建“Agent 就绪”的开发栈。推荐的迭代路径如下：

1. 挖掘代码库中的 Bug： 识别那些真正重要的缺陷。
2. 修复 Bug： 解决问题。
3. 利用 Trace 信息进行环境优化： 通过分析在修复 Bug 过程中遇到的障碍（例如难以验证修复是否正确、环境无法重现问题等），来确定哪些开发环境的改进能最高效地提升代码库对 Agent 的易用性。

这种转型类似于从管理物理服务器转向云计算的过程：工程师将从底层基础设施的复杂性中解脱出来，专注于逻辑层面的开发。