2026-04-29

Ghostty 将离开 GitHub：一个 18 年的告别

这篇文章讲述了 GitHub 用户 1299 (Ghostty) 决定离开 GitHub 的故事。作者在 GitHub 上度过了 18 年，从 2008 年 2 月加入至今，每天多次使用，甚至在生活中重要时刻也依赖 GitHub。GitHub 曾是他最快乐的地方，也是他工作、爱好和热情的交汇点。他甚至因为希望能在 GitHub 工作而创建了 Vagrant 项目。

然而，近年来，作者对 GitHub 的服务质量越来越不满，公开表达了批评和愤怒，因为 GitHub 经常出现故障，严重影响了他的工作效率。过去一个月，他记录了 GitHub 故障对工作的影响，几乎每天都被影响。作者认为 GitHub 已经不再适合进行严肃的工作，并且希望 GitHub 能够变得更好，但目前的情况让他无法继续使用。

因此，Ghostty 项目将离开 GitHub，作者将在未来几个月公布新的托管平台，目前正在与多家商业和开源服务提供商进行讨论。项目将逐步移除对 GitHub 的依赖，并保留在 GitHub 上的只读镜像。作者的个人项目和部分工作仍将继续留在 GitHub 上，Ghostty 项目的迁移是当前的首要任务。

关键点总结:

• 作者在 GitHub 上度过了 18 年，对 GitHub 怀有深厚感情。
• GitHub 近期频繁出现故障，严重影响了作者的工作效率。
• Ghostty 项目将离开 GitHub，寻找新的托管平台。
• 作者计划逐步移除对 GitHub 的依赖，并保留只读镜像。
• 作者希望 GitHub 能够改善服务，未来可能回归。

脚注:

1. 此次离开 GitHub 的时间与 2026 年 4 月 27 日的大规模故障巧合，但该决定已在几个月前制定，文章也于一周前完成。
2. 作者明确指出，问题不在于 Git 本身，而是围绕 Git 的基础设施，例如 issues、PRs、Actions 等。
3. 当前 Actions 故障与 2026 年 4 月 27 日的 Elasticsearch 故障不同。

uutils 安全审计与 Rust 系统编程经验总结 (uutils 安全审计与 Rust 系统编程经验总结)

2026 年 4 月，Canonical 公布了 uutils (Rust 重构的 GNU coreutils) 中 44 个 CVE (漏洞)，这些漏洞是在 26.04 LTS 版本发布前进行的外部审计中发现的。 这些漏洞主要集中在生产环境的 Rust 代码库中，而且未能被借用检查器 (borrow checker)、Clippy 检查器或 Cargo 审计工具检测到。

主要问题与规则：

1. 路径跨越系统调用的时间窗口 (TOCTOU) 漏洞:

   • 这是审计中漏洞最多的类型，也是 Ubuntu 26.04 LTS 中 cp, mv, 和 rm 仍然使用 GNU 版本的原因。
   • 攻击者在检查路径和执行操作之间利用时间窗口，通过修改父目录下的符号链接来篡改目标路径。
   • 规则: 避免使用 fs::metadata, File::create, fs::remove_file, fs::set_permissions 等方法，因为它们在每次调用时都会重新解析路径。 应该使用文件描述符 (file descriptor) 来操作文件，或者在同一目录下使用相对路径。如果需要对同一路径进行两次操作，应假设存在 TOCTOU 漏洞并进行仔细检查。
   • 案例研究 (CVE-2026-35355): File::create 在删除文件和创建文件之间重新解析路径，允许攻击者通过符号链接覆盖文件。修复方法是使用 OpenOptions::create_new(true)，该方法可以确保创建的是一个全新的文件，并且不会存在任何 (悬空) 符号链接。

2. 在创建时间后设置权限:

   • 权限设置操作在创建文件/目录后进行，导致在设置权限之前，其他用户可能已经获得了文件描述符，从而绕过权限限制。
   • 规则: 在创建文件/目录时直接设置权限，而不是之后再进行设置。使用 OpenOptions::mode() 和 DirBuilderExt::mode() 等方法。

3. 路径字符串相等与文件系统身份不一致:

   • chmod 命令中的根目录检查仅仅比较路径字符串是否为 "/", 容易被 /../, /./, /usr/.. 或指向 "/" 的符号链接绕过。
   • 规则: 在比较路径时，使用 canonicalize() 函数将路径解析为绝对路径进行比较。

4. 忽略路径中的 " . " 和 ".." 字符:

   • 在 rm 命令中，直接使用 " . " 和 ".." 会导致错误，而使用 "./" 和 ".///" 则可以正常删除，存在潜在的安全风险。

5. 在 Unix 边界保持字节格式:

   • Rust 的 String 和 &str 总是 UTF-8 编码，这在大多数情况下是正确的，但对于 Unix 路径、环境变量、参数和工具输入等字节流的处理可能不适用。
   • 规则: 应该使用 OsStr 或 &[u8] 来处理 Unix 相关的字节数据，避免通过 String 进行不必要的转换，防止数据损坏。
   • 案例研究 (CVE-2026-35346): comm 命令使用 String::from_utf8_lossy 进行转换，导致无效 UTF-8 字节被替换为 U+FFFD，从而破坏了输出。 修复方法是直接使用字节流进行操作。

6. panic! 导致的服务拒绝 (DoS):

   • 在 CLI 工具中，任何 unwrap, expect, 索引操作等都可能导致 DoS，因为 panic! 会终止进程。
   • 规则: 将错误转换为错误信息，而不是引发 panic。

7. 忽略有意义的错误信息:

   • chmod -R 和 chown -R 命令返回最后处理的文件错误码，而不是最严重的错误码。
   • 规则: 不要忽略有意义的错误信息，应该记录并传播错误。

8. 匹配原始工具的行为:

   • 重构工具时，应该尽可能匹配原始工具的行为，包括退出码、错误信息和边缘情况。

Rust 的安全优势:

尽管审计发现了漏洞，但 Rust 仍然在防止一些常见的内存安全问题方面表现出色，例如缓冲区溢出、空指针解引用等。

总结:

该审计揭示了在 Rust 系统编程中需要注意的关键安全问题，

code.overheid.nl 平台上线：荷兰政府开源代码平台

code.overheid.nl 平台已正式上线，它是荷兰政府范围内的开源软件发布和开发平台。该平台完全自主托管，支持数字主权。

核心要点:

• 平台目标： 作为政府机构共享 Git 平台的长期目标，用于发布和开发开源软件。
• 当前状态： 目前处于试点阶段，使用 Forgejo 作为底层技术。Forgejo 是一个开源、欧洲和主权化的 GitHub 和 GitLab 替代方案。
• 可用性： 目前并非所有政府组织都可以使用该平台。
• 参与方式： 邀请开发者参与贡献，以逐步扩展平台。
• 发起方： 由内政与王国关系部 (BZK) 的开源项目办公室发起，并与 DAWO (SSC-ICT)、Opensourcewerken 和 developer.overheid.nl 合作。
• 联系方式： 有兴趣参与的请发送邮件至 codeplatform@rijksoverheid.nl。
• 更多信息： 更多信息请访问 developer.overheid.nl 上的博客文章 ‘We gaan samen code.overheid.nl bouwen’ (我们一起构建 code.overheid.nl)。

总结： code.overheid.nl 平台是荷兰政府为提升数字主权和促进开源软件合作而建立的重要基础设施，目前处于试运行阶段，欢迎开发者积极参与。

好的，这是一篇关于原文内容的中文摘要：

摘要：重温开源的过去与未来：告别 GitHub 的时代？

本文作者回顾了自己开源软件的演变历程，从最初的 SourceForge、Trac 安装，到 Bitbucket，最终迁移到 GitHub。作者强调 GitHub 对其个人开源生涯以及整个开源社区的重要性，它不仅是代码存放地，更是社区交流的重要场所。

然而，作者对 GitHub 近况感到失望，认为其背后的变化不仅仅是产品决策问题，而是对开源社会基础设施的冲击。作者追溯了开源发展历史，指出 GitHub 的出现催生了依赖微型包的现象，使得代码发布和使用变得更加便捷，但也带来了信任和维护上的挑战。

文章对比了 GitHub 之前的开源世界，那时项目数量较少，但项目维护者相对稳定，社区信任度高，依赖关系更谨慎。那时，开发者通常需要自行搭建基础设施，例如 Trac、Subversion 等，并承担服务器维护的责任。

作者认为 GitHub 尽管带来了便利，如易于创建项目、发现项目、贡献代码、提供 issue 跟踪、代码审查和持续集成等功能，但其中心化的模式也存在风险。作者强调了 GitHub 在代码存档方面的作用，并担心失去这些历史数据。

随着 GitHub 的逐渐衰落，越来越多的开发者开始寻找替代方案，例如 Codeberg。作者认为，开源社区应该回归去中心化，鼓励开发者自行搭建 forge，但这也会带来信息遗失的风险。

作者呼吁建立一个公共、稳定、且资金充足的开源软件档案库，用于长期保存代码、元数据和项目背景信息，以避免开源成果的流失。 他希望未来的开源系统能够更易于迁移、更易于保留社交上下文，并降低对单一公司的依赖。 总结来说，作者希望开源社区能够从过去的经验中吸取教训，在告别 GitHub 的同时，更好地保护开源的记忆和自主性。

HashiCorp 联合创始人 Mitchell Hashimoto 离开 GitHub：因持续不稳定

HashiCorp 联合创始人 Mitchell Hashimoto 决定将他的项目 Ghostty 迁移离 GitHub，理由是 GitHub 的不稳定已经使其“不再适合严肃的工作”。

背景：

• Hashimoto 是 GitHub 的早期用户（自 2008 年 2 月起），并长期以来对该平台情有独钟，甚至在蜜月期间也会使用。他认为 GitHub 不仅是代码托管平台，更是学习开源项目管理和维护的最佳场所。
• Ghostty 是 Hashimoto 的一个终端模拟器项目，因其速度和创新功能而备受赞誉。

问题所在：

• 过去一个月，Hashimoto 记录了 GitHub 每日的宕机和故障对工作的影响，几乎每天都被中断。
• 近期发生的 Elasticsearch 故障导致拉取请求无法完成，进一步加剧了他的不满。
• 他认为 GitHub 正在阻碍他的工作，并表达了对平台持续不稳定的失望。
• 他表示，虽然希望 GitHub 能够改进，但目前无法继续在该平台上进行编码工作。

解决方案：

• Hashimoto 计划将 Ghostty 迁移到其他协作代码托管平台，目前正在与多个提供商（包括商业和开源）进行讨论。
• 他会保留 Ghostty 在 GitHub 上的只读镜像，以及个人项目，以便过渡期间平稳过渡。
• 他强调，目前 Ghostty 项目及其维护者和开源社区受到的影响最大，因此将优先解决该项目的迁移问题。

更广泛的背景：

• Microsoft 收购 GitHub 后，一些开发者担心 GitHub 会受到微软的影响，变得更加偏向于 Windows 和 Azure 生态系统。
• Hashimoto 的经历表明，这种担忧可能正在成为现实，而这恰恰与微软承认 Windows 存在严重质量问题以及过度依赖 AI 技术的时间点相吻合。
• 文章暗示，GitHub 的不稳定可能与 Microsoft 对 AI 的过度追求有关。

总结：

Mitchell Hashimoto 因 GitHub 的持续不稳定而选择离开该平台，并将他的项目 Ghostty 迁移到其他地方。 这反映了对 GitHub 质量和可靠性下降的担忧，以及 Microsoft 对 AI 战略对开发者体验可能产生负面影响的潜在风险。

事件摘要：Anthropic Claude 服务中断及恢复

**事件概述：**Anthropic 的 Claude 服务于 2026 年 4 月 28 日 UTC 时间段内出现中断，影响了多个产品和服务。目前事件已解决，服务恢复正常。

影响范围： 受影响的服务包括：

• claude.ai
• Claude Console (platform.claude.com)
• Claude API (api.anthropic.com)
• Claude Code
• Claude Cowork
• Claude for Government

时间线：

• 17:41 UTC: 开始调查用户无法访问 claude.ai 的问题。
• 17:51 UTC: 确认问题导致 Anthropic API 出现大量错误，并影响了 Claude.ai 的访问，包括 Claude Code 的登录流程。正在积极解决问题。
• 18:33 UTC: 继续努力解决用户无法访问 Claude.ai 以及 API 和 Claude Code 请求出现大量认证错误的难题。
• 18:59 UTC: 观察到所有服务成功率恢复正常，并密切监控以防止再次出现问题。影响时间段为 17:34–18:52 UTC。
• 已解决: 事件已解决。

**总结：**Anthropic 经历了一次服务中断，影响了其多个产品和 API。问题已识别并解决，服务已恢复正常，并正在进行持续监控。

Wiz Research 发现 GitHub 内部 Git 基础设施的关键漏洞 (CVE-2026-3854)

Wiz Research 发现 GitHub 内部 Git 基础设施存在一个关键漏洞 (CVE-2026-3854)，可能影响 GitHub.com 和 GitHub Enterprise Server (GHES)。该漏洞利用了 GitHub 内部协议中的注入缺陷，允许任何经过身份验证的用户仅通过一个 git push 命令在 GitHub 后端服务器上执行任意命令。

关键发现：

• 漏洞易于利用： 即使底层系统复杂，该漏洞也易于利用。
• GitHub.com 影响： 在 GitHub.com 上，该漏洞允许对共享存储节点执行远程代码。研究人员确认了数百万个属于其他用户和组织的公共和私有仓库在受影响的节点上可访问。
• GHES 影响： 在 GHES 上，漏洞导致服务器完全被攻陷，包括访问所有托管的仓库和内部密钥。
• AI 辅助发现： 这可能是第一个使用 AI 发现的关键漏洞，突显了漏洞识别方式的转变。
• 跨租户影响： 在 GitHub.com 上，由于共享基础设施，该漏洞还具有跨租户的影响，允许攻击者访问其他租户的仓库。

GitHub 的响应：

GitHub 在收到报告后的 6 小时内解决了 GitHub.com 上的问题，并为所有受支持版本的 GHES 发布了补丁，并发布了 CVE。

补救措施：

• GitHub.com 用户： 无需采取任何操作。
• GitHub Enterprise Server 用户： 立即升级至 GHES 版本 3.19.3 或更高版本。 目前数据表明 88% 的实例仍然存在漏洞。

受影响版本：

漏洞技术细节：

• 架构概述： git push 请求流经 babeld (Git 代理), gitauth (身份验证服务), gitrpcd (RPC 服务器), 和预接收钩子。
• X-Stat 字段注入： babeld 将 Git push 选项值直接复制到 X-Stat 头中，而未进行半角分号的 sanitization。这允许攻击者通过在 push 选项值中插入分号来注入新的字段，并覆盖现有的安全字段。
• 远程代码执行 (RCE)： 通过注入 rails_env (控制钩子执行路径), custom_hooks_dir (控制钩子目录) 和 repo_pre_receive_hooks (预接收钩子定义) 字段，攻击者可以绕过沙箱，控制钩子目录，并注入包含路径遍历序列的钩子定义，从而在 git 用户权限下执行任意代码。

Wiz 的解决方案：

Wiz 客户可以使用 Wiz Threat Center 中的预构建查询来识别环境中的易受攻击的 GHES 实例。

研究背景：

GitHub 是全球最大的代码托管平台。Wiz Research 团队利用 AI 辅助工具 (IDA MCP) 加速了对 GitHub 编译二进制文件的分析，并识别了这种漏洞。该研究强调了在多服务架构中，用户控制的输入如何通过共享内部协议流动，以及由此产生的安全风险。

负责任披露时间线：

• 2026-03-04: Wiz Research 发现漏洞并报告给 GitHub。
• 2026-03-04: GitHub 部署 GitHub.com 上的修复。
• 2026-03-10: 分配 CVE-2026-3854。
• 2026-03-10: 发布 GHES 补丁。
• 2026-04-28: 公开披露。

GitHub 的回应：

GitHub 感谢 Wiz Research 的协作、专业精神和伙伴关系，并认为这是一项罕见的、高风险的安全研究，赢得了 Bug Bounty 项目中最高的奖励之一

摘要：Waymo 进入波特兰市，助力交通安全与可持续发展

Waymo 宣布其自动驾驶服务将扩展至波特兰市（Rose City）。波特兰市因其创新的城市设计理念和对可持续发展的承诺而备受青睐，使其成为 Waymo 发展的重要地点。

主要内容：

• 合作与准备阶段： Waymo 正在与俄勒冈州和波特兰市政府官员以及当地社区合作伙伴合作，以制定监管框架，为未来服务奠定基础。目前，Waymo 团队正通过人工驾驶车辆熟悉波特兰市的街道环境，包括标志性桥梁和雨天路况。
• 安全承诺： Waymo 强调其自动驾驶系统（Waymo Driver）的安全性，并表示其在运营城市中已实现了严重事故减少 13 倍。 Waymo 希望将这种安全效益带到波特兰市的街道。
• 支持 Vision Zero 目标： Waymo 的入驻将支持波特兰市实现“Vision Zero”目标，即消除交通死亡事故。
• 减少酒驾风险： Mothers Against Drunk Driving (MADD) 表示，安全部署自动驾驶车辆可以有效防止酒后驾驶等危险行为，对保障道路安全具有重要意义。MADD 与 Waymo 长期合作，共同致力于保护驾驶员、乘客、行人及社区的安全。
• 获取更新： 欢迎访问 waymo.com/updates 注册更新，以便成为首批体验 Waymo 波特兰市服务的用户。

总结： Waymo 选择波特兰市作为其自动驾驶服务的新拓展区域，旨在通过技术创新助力波特兰市实现交通安全目标，并提升城市的可持续发展水平。

Blender 基金会宣布 Anthropic 加入开发基金作为企业赞助商

Blender 基金会宣布，Anthropic 公司已加入 Blender 开发基金，成为企业赞助商。这项支持将专门用于 Blender 核心开发，以维护和持续改进诸如 Blender Python API 等基础功能。Blender Python API 允许开发者和艺术家扩展和改进软件以适应定制工作流程。

主要内容：

• 赞助方： Anthropic 公司，一家人工智能研究和开发公司，其旗舰产品是大型语言模型 Claude。
• 支持内容： 资金将用于 Blender 核心开发，特别是 Blender Python API 的维护和改进。
• 目的： 支持 Blender 团队独立推进项目，专注于为艺术家和创作者构建工具。
• Blender 基金会立场： Blender 基金会致力于通过免费/开源技术和工具赋能艺术家。同时，基金会也维护 API，允许个人和企业扩展 Blender，即使这些扩展超出了 Blender 基金会的使命范围。 这被认为是 Blender GNU GPL 许可证所体现的软件自由的一部分。
• 关于 Anthropic： Anthropic 致力于创建可靠、可解释和可引导的人工智能系统，其产品 Claude 受到全球数百万用户的信赖。
• 关于 Blender： Blender 是世界上最受欢迎的免费和开源 3D 创作软件，提供建模、动画、视觉特效等全面的解决方案。它由 Blender 基金会维护，是全球众多专业艺术家和爱好者的首选工具，致力于开放协作和 3D 技术创新。

更多信息：

• Blender 基金会资金政策： https://fund.blender.org/funding-policy/
• Anthropic 公司：anthropic.com

Warp: 代理式开发环境总结 (Warp: Agentic Development Environment Summary)

Warp 是一个基于终端的代理式开发环境，旨在提升开发效率。 它由 OpenAI 资助，并利用 GPT 模型驱动其代理式工作流程。

核心功能与特点:

• 代理式开发: Warp 允许用户使用内置的编码代理，或者集成其他 CLI 代理，例如 Claude Code、Codex 和 Gemini CLI 等。
• Warp Contributions Overview Dashboard: 通过 build.warp.dev 可以实时观察 Oz 代理处理问题、编写规范、实现更改和审查拉取请求的过程，并跟踪贡献者和正在进行的功能。
• 开源与社区贡献: Warp 的客户端代码库是开源的，欢迎社区贡献。 提供轻量级的流程帮助新贡献者入门。Issue 可以通过模板提交，安全漏洞需要私密报告。Issue 会被标记为 ready-to-spec (设计开放) 或 ready-to-implement (设计确定)，允许任何人参与。
• 本地构建: 可以通过 ./script/bootstrap 和 ./script/run 命令从源代码构建和运行 Warp。
• 文档与支持: 提供详尽的文档 (https://docs.warp.dev/)，Slack 社区 (https://go.warp.dev/join-preview) 和预览构建 (https://www.warp.dev/download-preview)，用户可以获取帮助和测试最新功能。

技术细节:

• UI 框架: Warp 的 UI 框架 (warpui_core 和 warpui crate) 使用 MIT 许可证。
• 代码许可: Warp 的其余代码使用 AGPL v3 许可证。
• 依赖项: Warp 依赖于多个开源项目，包括 Tokio、NuShell、Fig Completion Specs、Warp Server Framework、Alacritty、Hyper HTTP library、FontKit、Core-foundation、Smol 等。

获取与参与:

• 下载: https://www.warp.dev/download
• 代码: https://www.warp.dev/code
• 职业: https://www.warp.dev/careers

Stratechery 每日更新：关于 OpenAI CEO Sam Altman 和 AWS CEO Matt Garman 的访谈 - Bedrock Managed Agents

今天的内容围绕着 OpenAI CEO Sam Altman 和 AWS CEO Matt Garman 关于 Bedrock Managed Agents 的访谈，以及由此引发的 Microsoft 和 OpenAI 协议变更。

背景：

在过去几天，Stratechery 团队经历了忙碌的日程：

• 上周五，采访了 Sam Altman 和 Matt Garman，讨论了由 OpenAI 驱动的 Bedrock Managed Agents。
• 周日，得知 Microsoft 可能会宣布一项重要举措，甚至可能涉及法律诉讼。
• 周一，Microsoft 和 OpenAI 宣布修订协议，允许 OpenAI 将其产品部署在包括 AWS 在内的其他云服务提供商上。

协议修订的关键点：

Microsoft 和 OpenAI 达成的协议修订内容如下：

• Microsoft 仍然是 OpenAI 的主要云合作伙伴，OpenAI 产品将在 Azure 上首发，除非 Microsoft 无法或不愿支持必要的功能。
• OpenAI 现在可以将其所有产品部署在任何云服务提供商上。
• Microsoft 将继续持有 OpenAI IP 的许可证，直至 2032 年，许可证将不再是独家许可。
• Microsoft 将不再向 OpenAI 支付收入分成。
• OpenAI 向 Microsoft 支付的收入分成将继续到 2030 年，与 OpenAI 的技术进步无关，但总额有限制。
• Microsoft 将继续直接参与 OpenAI 的增长，成为其主要股东。

核心观点：

• 协议修订的意义： 协议的修订对双方都有利。Azure 曾因独家访问 OpenAI 模型而具有竞争优势，但这也限制了 OpenAI 的发展。 允许 OpenAI 在其他云平台部署产品，特别是 AWS，能够更好地满足企业客户的需求。
• AWS 的机会： OpenAI 明显看到了 AWS 的巨大机会，愿意放弃与 Azure 相关的收入分成。
• Bedrock Managed Agents 的推出： 此次访谈的核心内容是 Bedrock Managed Agents，可以将其视为 AWS 版本的 Codex。 它旨在简化组织内部 Agent 工作流的部署和管理，降低技术门槛。
• AI 发展趋势： 访谈探讨了 AWS 如何构建云服务，以及 AI 带来的变革与云服务时代的相似之处。 强调了 AI 时代的抽象层可能更偏向于高度集成的超大规模集群，以及软件与硬件的紧密结合。
• 本地与云端： 讨论了本地运行和云端运行的优缺点，本地运行更易于上手，而云端运行则更易于扩展和管理。
• 未来展望： OpenAI 认为，随着模型的不断发展，未来的计算架构可能会发生改变。 需要构建新的中间层来管理数据、模型和用户交互，从而实现更高效的 AI 应用。

访谈要点：

• AWS 的成功经验： Matt Garman 强调了 AWS 的成功在于为开发者提供强大的工具，降低了开发门槛，激发了创新。
• AI 的机遇： Sam Altman 认为 AI 是平台型变革的第四次浪潮，为创业公司提供了巨大的机会。
• 模型与 Harness 的协同： 强调模型和 Harness 的紧密结合，以及构建高效 Agent 的重要性。
• 安全问题： Matt Garman 认为，在 AWS 上构建 AI 应用可以提供更强的安全保障。

总结：

这次访谈揭示了 Microsoft-OpenAI 协议修订背后的战略考量，以及 AWS 在 AI 领域的布局。 Bedrock Managed Agents 的推出标志着 AI 应用向企业市场的进一步渗透，同时也预示着未来 AI 发展将更加注重平台化和易用性。

总结：GitHub Copilot 计费模式变更及生成式 AI 经济困境

核心要点：

• GitHub Copilot 计费模式变更： Microsoft 将于 2026 年 6 月 1 日起，将 GitHub Copilot 的计费模式从请求数量变为基于实际使用模型消耗的 token 计费。这意味着用户将根据实际使用的模型和消耗的 token 数量付费，而非固定数量的请求。
• 生成式 AI 经济困境： 文章指出，目前生成式 AI 服务普遍存在经济亏损的情况，例如 OpenAI 和 Anthropic 等公司，其 AI 服务的运营成本远高于用户订阅费用。
• 订阅模式不可持续： 定期订阅模式对于需要大量计算资源且成本不稳定的生成式 AI 服务来说，经济上不可持续。
• AI 数据中心成本高昂： 构建和运营 AI 数据中心需要巨额投资，且依赖于客户（主要为 OpenAI 和 Anthropic）的持续支付能力。
• Oracle 的风险： Oracle 在 Stargate 数据中心项目上的巨额投资高度依赖于 OpenAI 的成功，如果 OpenAI 无法实现其增长目标，Oracle 将面临巨大风险。
• 行业普遍存在的问题： 文章批评了 AI 行业普遍存在的虚报增长、隐藏成本和过度宣传等问题，认为这种模式最终不可持续。

详细内容：

• Copilot 计费模式变更的背景： Microsoft 认为 Copilot 已经从简单的代码辅助工具发展为复杂的 Agentic 平台，需要消耗更多的计算资源，因此需要调整计费模式以确保服务的可持续性。
• 亏损的现实： 过去，Microsoft 长期补贴 GitHub Copilot 用户，但实际运营成本远高于订阅费用，导致亏损。
• Subprime AI 危机： 文章将当前生成式 AI 行业的困境比作“Subprime AI 危机”，指出行业长期存在过度补贴、高烧钱率和不合理的定价模式。
• 经济模型问题： 文章通过 Uber 的例子，解释了为什么订阅模式不适用于需要大量计算资源且成本不稳定的生成式 AI 服务。
• Stargate 项目的风险： Oracle 为 OpenAI 构建的 Stargate 数据中心项目，投资巨大，依赖于 OpenAI 的成功，如果 OpenAI 无法实现其增长目标，Oracle 将面临巨大风险。
• 未来展望： 文章预测，基于 token 计费的模式将逐渐普及，但同时也警告投资者和用户，要对 AI 行业的盈利能力保持警惕。

总结：

文章认为，GitHub Copilot 计费模式的变更是生成式 AI 行业面临经济困境的缩影。为了实现可持续发展，行业必须更加透明地披露成本，并建立合理的定价机制。

ChatGPT 广告平台运作机制总结

本文档记录了对OpenAI ChatGPT广告平台流量的观察，揭示了其运作机制，主要分为ChatGPT后端和商家端两个部分。

1. 广告注入与跟踪:

• ChatGPT 后端: 在模型响应过程中，通过Server-Sent Events (SSE) 流向 ChatGPT 会话注入结构化的 single_advertiser_ad_unit 对象。
• 商家端: 商家端使用名为 OAIQ 的跟踪 SDK (运行在用户浏览器中)，报告产品浏览行为回传到 OpenAI。
• 连接: 两端通过四个 Fernet 加密的令牌连接，每个广告包含四个令牌。

2. 广告单元结构:

single_advertiser_ad_unit 是一个类型化的结构体，包含以下关键信息：

• ads_request_id: 广告请求 ID。
• ads_spam_integrity_payload: 用于服务器端验证广告点击的完整性，防止伪造点击。
• advertiser_brand: 包含广告商品牌信息，如名称、URL、favicon URL 和一个稳定的商家账户标识符 adacct_<32-hex>。
• carousel_cards: 包含一个或多个轮播卡片，每个卡片包含标题、内容、图片 URL 和目标链接 (target)。
• ad_data_token: base64 编码的 JSON 字符串，其中包含另一个 Fernet 令牌。

3. 广告选择与上下文:

广告选择是基于会话上下文的，同一个账户在不同的聊天主题下会展示不同的广告品牌。例如，关于北京旅行的聊天会显示 Grubhub 的外卖广告，关于 NBA 比赛的聊天会显示 Gametime 的门票广告。

4. 四个 Fernet 令牌的作用:

• ads_spam_integrity_payload: 在 SSE 数据中发送，用于服务器端验证。
• oppref: 存在于点击 URL 中，被 OAIQ SDK 复制到 __oppref cookie 中 (TTL 720 小时)，作为前向归因令牌，随后的商家像素事件一同传递。
• olref: 与 oppref 关联，但在观察到的 SDK 中未被存储，可能用于 OpenAI 服务器端的印象端日志记录。
• ad_data_token: base64 编码的 JSON 字符串，包含另一个 Fernet 令牌，在点击时由服务器进行匹配。

5. 令牌时间戳与点击延迟:

Fernet 令牌的前9个字节包含了版本字节和 Unix 时间戳，可以计算出令牌的创建时间。观察到 Home Depot 点击的令牌创建时间与浏览器获取商家页面之间存在95秒的延迟。

6. 商家端闭环跟踪:

1. 用户点击广告卡片，浏览器打开商家页面。
2. 商家页面加载 OAIQ SDK。
3. SDK 从 URL 读取 oppref 参数，写入 __oppref cookie，并设置 __oaiq_domain_probe 探测 cookie。
4. SDK 每当触发 measure 事件时，都会将 JSON 数据 POST 到 OpenAI 的 bzr.openai.com/v1/sdk/events 端点。

7. 总结与阻断建议:

• OpenAI 使用 bzrcdn.openai.com 和 bzr.openai.com 两个域名来提供广告资源和接收事件数据。
• 用户可以检查 __oppref 和 __oaiq_domain_probe cookie 来识别 ChatGPT 推荐的点击。

美国联邦政府扩大禁飞区，引发争议与法律挑战 (美国联邦政府扩大禁飞区，引发争议与法律挑战)

2026年1月，明尼阿波利斯移民突袭抗议活动期间，联邦特工射杀了一名37岁妇女，名叫 Renee Good。 在充分调查事实之前，美国国土安全部 (DHS) 便将Good定性为“反ICE抗议者”，声称她驾驶车辆“针对执法部门”，并构成“国内恐怖主义”行为。

此后几天，联邦政府宣布大幅扩大“禁飞区”，理由是国家安全。 过去，禁飞区主要针对飞机，但现在也经常针对小型无人机。 1月16日发布的最新禁飞令规定，无人机不得飞越联邦设施3000英尺（横向）和1000英尺（垂直）范围。

更重要的是，该禁令首次将禁飞区扩展到美国国土安全部所属的地面车辆，即使这些车辆在移动、未标记，且路线未公布，也受到限制。

这一政策模糊不清，对自由摄影师Rob Levine等人的安全构成了威胁。 Levine在明尼阿波利斯从事摄影工作近四十年，自2016年获得无人机执照以来，他一直在使用DJI四旋翼无人机拍摄明尼苏达州的河流、桥梁、城市，以及户外音乐会和游行等活动。 近期，他还记录了当地居民抗议联邦特工在社区内增加存在的情况。

看到禁飞令后，Levine立即停止了飞行。 该令警告称，政府机构可以击落或没收“被认为对安全或安保构成可信威胁”的无人机，并警告无人机操作者可能面临民事甚至刑事处罚。 Good 的遇难地点距离他的住所仅六个街区，让他深感担忧。

一周后，情况进一步升级，美国海关与边境保护局 (CBP) 官員射杀了37岁的重症护理护士 Alex Pretti。

尽管如此，Levine仍然希望能够重新启用无人机。 然而，当他向美国联邦航空管理局 (FAA) 寻求指导时，FAA坦诚承认该禁飞令“含糊不清”，因此“任何飞行都可能构成无意违反”。

隐蔽的禁飞区

FAA 过去仅建议无人机飞行员避免飞越国防部和能源部运营的“移动资产”，例如军舰和运输核材料的卡车。 但1月份发布的“空域通知”（NOTAM FDC 6/4375）实际上创建了围绕联邦特工车辆的、半径3000英尺的禁飞区，这些车辆在城市和城镇中行驶。 这不仅影响到试图拍摄联邦特工的人，由于难以遵守新的飞行限制，任何无人机飞行员都可能面临风险。

无人机服务供应商联盟 (DSP Alliance) 的首席执行官兼联合创始人Vic Moss表示：“这在社区内制造了许多恐惧。” Moss在3月11日发表的文章中，将FAA的飞行限制描述为对无人机操作员来说是一个“不可能遵守的问题”，他们可能会“意外地进入受限区域，却不知道”。

美国无人机飞行员必须使用诸如Air Control之类的应用程序来获得在受控空域飞行的官方许可。 重量超过0.55磅的无人机必须注册到 FAA，并配备远程识别模块，以便随时“广播”无人机的身份和位置。 这使得联邦特工或当局可以轻松查看无人机操作的地点。 然而，该系统无法让无人机操作员避免未标记的政府车辆。

这些禁飞区限制也因其持续时间和范围而显得不寻常。 FAA 经常在自然灾害期间或为了保护政府官员和体育赛事（如职业棒球或橄榄球比赛）的空域发布临时飞行限制。 大多数限制仅持续数小时或数天，并涵盖特定地理位置。

但2026年1月16日发布的限制将持续21个月，直至2027年10月29日

自动架构：将 Karpathy 的循环指向 CPU

本文介绍了作者将 Andrej Karpathy 的自动研究循环（autoresearch）应用于 CPU 领域，并探索其结果的过程。 autoresearch 通常用于 Python 和梯度下降等领域，但作者试图了解其在更陌生的环境中的泛化能力。

实验设置：

作者创建了一个名为 auto-arch-tournament 的项目，该项目基于 5 级、无缓存的 RV32IM 核心，使用 SystemVerilog 实现。该项目使用 LLM（大型语言模型）作为智能代理，通过以下步骤进行自动架构优化：

1. 假设提出： 代理以 YAML 格式提出微架构假设，并经过模式验证。
2. 实现： 实现代理编辑 rtl/ 目录下的文件。
3. 评估： 评估环节包括：
   • riscv-formal: 执行 53 个符号 BMC 检查（用于验证解码、陷阱、排序和存活性）。
   • Verilator cosim: 在 Python 模拟器中进行字节级别的 RVFI 比较，并模拟 22% 的总线暂停。
   • 3-seed nextpnr P&R: 在 Gowin GW2A-LV18 (Tang Nano 20K) FPGA 上进行布局布线，并根据 Fmax 和 CoreMark 迭代次数计算 fitness。
   • CoreMark CRC 验证： 验证 CoreMark 的 CRC 值。
4. 迭代： 改进的假设被合并到主干，成为新的基线；失败的假设则丢弃。

为了避免代理过度关注单一想法，引入了多样性轮换机制，强制代理选择不同的优化类别。

实验结果：

• 基线性能： 使用 VexRiscv 的配置作为基线，性能为 2.23 CoreMark/MHz，301 iter/s。
• 自动优化： 代理运行了 73 个假设，耗时 9 小时 51 分钟。
• 结果统计：
  • 改进（已接受）：10 个
  • 回归：50 个
  • 失败（形式验证/cosim）：9 个
  • 布局失败：4 个
• 最佳优化： 代理提出的 10 个最佳优化包括：
  • 向后分支已采取预测器
  • IF 直接跳转预测器
  • 冷多周期 DIV/REM 单元
  • 一深存储退役槽
  • 分段 RVFI 顺序计数器
  • 注册的展望 I-Fetch 重放预测器
  • 压缩的无重置 I-Fetch 重放标签
  • RTL-Only 热/冷 ALU 指令码拆分
  • 银行式注册的 I-Fetch 重放预测器
• 最终性能： 经过优化后，性能达到 2.91 CoreMark/MHz，577 iter/s，199 MHz 的 Fmax，5,944 LUT4，比基线提升 92%，比 VexRiscv 的 CoreMark 迭代次数提升 56%，同时使用更少的 LUT。

结论与思考：

作者认为，自动研究循环本身已经相对成熟，真正重要的是验证器。 验证器的作用是确保代理提出的优化是正确的，并防止代理引入错误或违反规则。 本项目中的验证器包括形式验证、路径沙箱、多种子布局布线、CRC 验证和 MMIO 标记等环节，有效地过滤了大量的错误假设。

作者认为，未来的公司竞争不再是编写代码的效率，而是编写验证器的能力。验证器定义了业务的正确性，并为代理提供了明确的规则。 如果无法清晰地定义规则，代理可能会满足一套错误的规则，从而导致生产环境中的问题。

未来方向：

• 采用基于种群的搜索算法，以提高搜索效率。
• 将 Embench 作为新的工作负载，评估优化方案的泛化能力。
• 寻找能够将自动研究循环应用于的，具有清晰验证器的业务领域。

总而言之，本文强调了在利用自动研究循环时，验证器的重要性，并认为验证器将成为未来公司竞争的关键。

美国破产申请数量增加：2026 年 3 月底止 12 个月报告

根据美国法院行政办公室发布的数据，截至 2026 年 3 月 31 日的 12 个月期间，美国破产申请数量增加了 11.9%，总申请数量达到 591,850 起，相比 2025 年 3 月 31 日止的 12 个月期间的 529,080 起申请数量，增长显著。

具体数据如下：

• 企业破产申请： 从 2025 年 3 月的 23,309 起增加到 2026 年 3 月的 25,960 起，增长了 11.4%。
• 非企业破产申请： 从 2025 年 3 月的 505,771 起增加到 2026 年 3 月的 565,890 起，增长了 11.9%。

历年破产申请数量（截至 3 月 31 日）：

各章节破产申请数量（截至 3 月 31 日）：

背景信息：

过去十多年来，破产申请数量一直呈下降趋势，从 2010 年 9 月的近 160 万起下降到 2022 年 6 月的 380,634 起。此后，申请数量每个季度都在增加，但仍远低于历史最高水平。

其他相关数据：

除了上述数据，还发布了以下统计信息：

• 截至 2026 年 3 月 31 日的 12 个月期间的企业和非企业破产申请（表格 F-2）。
• 2025 年 3 月和 2026 年 3 月结束的 12 个月数据的比较（表格 F）。
• 最近三个月的申请数量（表格 F-2，三个月）。
• 按月申请数量（表格 F-2，1 月、2 月、3 月）。
• 各县的破产申请数量（表格 F-5A）。

有关破产和其章节的更多信息，请参考相关资源链接。

Claude 代码回归问题总结 (Summary of Claude Code Regression Issue)

此文档总结了 Claude 代码中一个持续存在的问题，即使在声称已修复的版本中仍然存在。问题主要围绕着一个 <system-reminder> 系统提示，该提示导致子代理拒绝对合法开源代码进行修改。

问题描述:

• 在 Claude 代码版本 v2.1.111 中，每次 Read 和 Grep 工具读取文件时，都会注入 <system-reminder> 提示。
• 该提示要求 Claude 拒绝改进或增强任何代码，即使代码是合法的，并且用户明确要求进行修改。
• 这个提示嵌入在 claude CLI 二进制文件中，而非用户自定义的配置。
• Opus 4.7 子代理在尝试修改合法开源代码时，拒绝率高达 40-60%。

<system-reminder> 提示内容:

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware.
You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse
to improve or augment the code. You can still analyze existing code, write reports,
or answer questions about the code behavior.
</system-reminder>

问题根源:

提示的措辞不明确，导致子代理（由于上下文较少和安全限制较严格）将其理解为对所有代码的无条件拒绝，而并非仅针对恶意软件的代码。 主线程会更谨慎地理解，但子代理则会严格执行。

提出的解决方案:

• (a) 删除提示: 认为 Claude 的安全机制已经足够处理恶意软件相关的请求。
• (b) 修改提示措辞: 明确限定提示的适用范围，例如：“如果确定文件是恶意软件，则拒绝改进或增强。”
• (c) 限制提示的频率: 仅在首次读取文件时注入提示，避免重复注入造成上下文污染。

问题影响:

• 子代理拒绝率高，严重阻碍了并行代码修改工作流程。
• 提示注入导致大量令牌浪费，每次读取文件会注入约 400 个令牌，在一次会话中可能达到 20,000-40,000 个令牌。
• 损害了 Anthropic 推广的并行代理功能的用户体验。

相关问题:

• 问题 #47027 被标记为已修复，但问题仍然存在。
• 其他相关问题包括关于令牌浪费、隐藏提示以及拒绝恶意软件分析的报告。

重现步骤:

1. 使用 Claude 代码版本 v2.1.111。
2. 尝试使用 Opus 4.7 子代理修改任何非恶意软件的项目代码。
3. 观察子代理读取文件后，因为 <system-reminder> 提示而拒绝修改。

总之，该问题是一个产品阻塞，影响了 Claude 代码的并行代理功能，并且与之前声称已修复的问题相关。 需要修改提示或删除提示以解决这个问题。

OpenEMR 安全漏洞分析与修复：AI驱动的合作案例 (OpenEMR Security Vulnerability Analysis and Remediation: An AI-Driven Partnership Case)

本文总结了 AISLE 对 OpenEMR 电子病历平台进行安全分析的结果，以及双方合作修复漏洞的过程。OpenEMR 是全球广泛使用的开源电子病历平台，为超过 100,000 名医疗服务提供者，服务于超过 2 亿患者。由于医疗保健数字化速度快于安全措施的升级，OpenEMR 的安全性至关重要。

背景:

• 医疗保健数字化加速，但安全措施未能跟上。
• 攻击者利用人工智能寻找漏洞的速度越来越快。
• OpenEMR 作为全球领先的开源电子病历平台，保护其安全至关重要。

研究方法:

AISLE 研究人员使用 AISLE AI 分析器对 OpenEMR 8.0 (2026 年 2 月发布，并通过美国联邦卫生 IT 认证) 的代码进行分析。

主要发现:

• 在 2026 年第一季度，AISLE 发现了 38 个 CVE (Common Vulnerabilities and Exposures)，占 OpenEMR GitHub 上公布的所有安全公告的一半以上。
• 相比之下，2018 年的项目 Insecurity 报告，由人工团队在长时间研究后发现了 23 个漏洞。
• 这些漏洞可能导致严重的安全问题，包括：
  • SQL 注入: 攻击者可以窃取敏感数据、大规模泄露患者信息 (PHI)，甚至在服务器上执行远程代码。
  • FHIR Patient Compartment Bypass: 未经授权访问所有患者数据。
  • 跨站脚本攻击 (XSS): 攻击者可以在其他用户浏览器中执行恶意代码。
  • 路径遍历: 攻击者可以读取或写入服务器上的任意文件。
  • 会话超时绕过: 攻击者可以延长会话时间，从而保持访问权限。

具体漏洞示例:

• CVE-2026-24908 (SQL Injection): 存在于患者 REST API 的排序参数中，允许认证用户通过 SQL 注入提取凭据或执行任意代码。
• CVE-2026-23627 (SQL Injection): 存在于免疫模块的搜索和报告端点，同样存在 SQL 注入风险。
• CVE-2026-24487 (FHIR Patient Compartment Bypass): 由于 FHIR 层架构问题，导致 CareTeam 端点返回所有患者数据，即使请求携带了限制结果的 OAuth2 token。

修复过程:

• AISLE 针对每个漏洞提出了代码修复建议，并利用 OpenEMR 自身的抽象和安全模式。
• 对于关键漏洞 (CVE-2026-23627)，AISLE 独立完成了补丁。
• OpenEMR 维护人员积极参与修复过程，快速审查和迭代修复方案。
• 大部分修复在 OpenEMR 8.0.0 (2026 年 2 月 11 日) 发布，后续在 3 个补丁版本中陆续完成。

合作成果:

• AISLE 和 OpenEMR 建立了合作伙伴关系，将 AISLE PRO (AI 驱动的代码审查工具) 集成到 OpenEMR 的代码审查流程中。
• 现在可以在代码审查阶段检测到许多漏洞，从而在代码进入生产环境之前进行修复。
• 修复速度显著加快，使得 OpenEMR 能够更快地应对安全威胁。

结论:

该案例表明，利用人工智能驱动的漏洞分析工具，可以有效地发现和修复开源医疗保健软件中的安全漏洞。通过与 OpenEMR 的合作， AISLE 证明了 AI 在提升患者安全和保护健康数据隐私方面的潜力。 医疗机构应考虑采用类似的安全措施，以应对日益增长的网络安全威胁。

完整漏洞列表： (文章中列出了 38 个 CVE，此处省略，请参考原文)

总而言之，此项目突显了人工智能在保障医疗保健应用安全方面的重要作用，同时也强调了开发者与安全研究人员合作的重要性。

Cua 项目概览：构建通用 AI 智能体的工具集

Cua 是一套旨在构建和评估 AI 智能体的工具集，涵盖了底层基础设施、沙箱环境、智能体框架、基准测试以及虚拟机管理等多个方面。其核心目标是提供一个统一的平台，用于开发能在各种操作系统和环境中执行计算机操作的智能体。

核心组件：

• Cua Driver (macOS 后台计算机使用): 允许在 macOS 上后台运行原生应用程序，无需抢占鼠标焦点或空间。适用于 Claude Code、Cursor、自定义客户端等，并记录所有操作轨迹以便回放。
• Cua (跨平台沙箱): 提供用于构建能够自主屏幕操作、点击按钮、完成任务的智能体的 API。支持多种操作系统和容器镜像，包括 Linux、macOS、Windows、Android 以及自定义镜像。
• CuaBot (协同计算机使用): 提供一个无缝的沙箱环境，使编码智能体能够进行计算机操作。支持原生桌面窗口显示、共享剪贴板和音频。内置支持 agent-browser 和 agent-device (iOS, Android)。
• Cua-Bench (基准测试与强化学习环境): 用于评估计算机使用智能体在 OSWorld、ScreenSpot、Windows Arena 以及自定义任务中的表现。支持导出轨迹用于训练。
• Lume (macOS 虚拟机): 基于 Apple Virtualization.Framework，提供在 Apple Silicon 上创建和管理 macOS/Linux 虚拟机的解决方案，具有接近原生性能。
• Packages (软件包): 包含一系列 SDK 和工具，如 cuabot (多智能体沙箱 CLI)、cua-agent (智能体框架)、cua-sandbox (沙箱 SDK)、cua-computer-server (UI 交互及代码执行驱动)、cua-bench (基准测试环境) 和 lume (macOS/Linux 虚拟机管理)。

主要功能和特点：

• 跨平台支持: Cua 旨在支持多种操作系统，包括 Linux、macOS、Windows 和 Android。
• 沙箱环境: 构建沙箱环境，隔离智能体的运行，确保安全性并便于测试。
• 统一 API: 提供统一的 API，简化跨平台智能体开发的流程。
• 回放功能: 记录操作轨迹，方便调试和分析。
• 高性能虚拟机: Lume 利用 Apple Virtualization.Framework 提供高性能的 macOS/Linux 虚拟机。

技术栈:

• 编程语言：Python (Cua), Bash (Cua Driver, Lume)
• 第三方组件：Kasm (MIT), OmniParser (CC-BY-4.0), ultralytics (AGPL-3.0)

资源:

• 文档: https://cua.ai/docs
• 博客: https://www.cua.ai/blog
• Discord: https://discord.com/invite/mVnXXpdE85
• GitHub Issues: https://github.com/trycua/cua/issues

许可证:

MIT License，部分第三方组件使用其他许可证。

贡献: 欢迎贡献！ 详见 Contributing Guidelines。

人工智能碳水化合物计数存在风险：一项研究揭示了潜在的胰岛素剂量错误

摘要： 一项新的研究表明，目前的人工智能模型在估计食物照片中的碳水化合物含量方面存在显著的不一致性和不准确性，这可能导致糖尿病患者的胰岛素剂量错误，甚至危及生命。研究人员对四种领先的 AI 模型（OpenAI GPT-5.4、Anthropic Claude Sonnet 4.6、Google Gemini 2.5 Pro 和 Google Gemini 3.1 Pro Preview）进行了测试，通过重复提交 13 张食物照片进行碳水化合物估算，每次都使用相同的提示和设置。

研究结果：

• 模型之间存在巨大差异： 即使是同一张照片，每个模型在 500 次重复查询中也返回不同的碳水化合物估算值。
• 不一致性程度高： Claude Sonnet 4.6 的模型不一致性（CV）相对较低 (2.4%)，但 GPT-5.4、Gemini 3.1 Pro 和 Gemini 2.5 Pro 的不一致性则更高，分别达到 8.4%、10.3% 和 11.0%。
• 极端情况： 在“西班牙海鲜饭”照片的测试中，Gemini 2.5 Pro 的估算值范围从 55 克到 484 克，相当于 42.9 个胰岛素单位的差异，可能导致严重的低血糖。
• “精确错误”问题： 某些模型，如 Claude，即使不准确，也能保持高度一致性，导致持续的碳水化合物低估。
• 食物识别错误： AI 模型经常错误识别食物，例如将巴克韦尔塔（Bakewell tart）识别为林泽托特（Linzer torte），或在不存在的情况下添加“熟食肉”到芝士三明治中，这会影响碳水化合物估算。
• 信心评分不可靠： 模型提供的信心评分与实际准确性之间没有相关性，因此不能作为评估估算可靠性的依据。

风险评估：

• 系统性偏差（慢性风险）： 所有模型都倾向于高估碳水化合物含量，导致胰岛素剂量过高和低血糖风险。
• 随机变异性（急性风险）： 图像之间的差异意味着，一次不幸运的查询可能导致灾难性的异常值。

结论与建议：

这项研究强调了在糖尿病管理中使用人工智能碳水化合物计数时存在的风险。研究人员建议：

• 不要盲目信任人工智能： 没有任何测试的模型适合在没有人工干预的情况下进行胰岛素剂量计算。
• 多次查询： 通过多次查询并观察结果的分布来评估模型的不确定性。
• 检查食物识别： 确保 AI 模型正确识别食物。
• 了解模型： 了解每个模型的特点和潜在缺陷。
• 不要依赖信心评分： 信心评分不能作为评估估算可靠性的依据。

总而言之，这项研究强调了人工智能碳水化合物计数潜在的危险性，并呼吁糖尿病患者和医疗保健专业人员谨慎对待人工智能工具，并在使用过程中保持警惕。

补充信息：

• 研究的完整论文（预印本 PDF）可在 http://www.diabettech.com/wp-content/uploads/2026/04/diabettech%5Fpreprint-1.pdf 找到。
• 数据集、分析代码和测试图像可在 https://github.com/tim2000s/llm-food-benchmark-academic 找到（需申请访问权限）。

https://www.euractiv.com/news/greece-to-ban-anonymity-on-social-media/

CJITC 总结

CJITC 是一个微型、便携的 C 编译器和解释器，灵感来源于 Terry Davis 的 HolyC，并基于 Fabrice Bellard 的 TinyCC 构建，由 Jaromil 和 Dyne.org 团队打造。

核心特点：

• 广泛兼容性: CJITC 可以在 MS/Windows、Apple/OSX 和 GNU/Linux 等多种操作系统上运行。
• 即时部署: CJITC 只有一个文件，大小小于 2MB，无需签署 EULA，无需安装 IDE，即可快速部署。
• 动态库调用: 能够调用任何动态库中的共享函数。
• 快速原型设计: 允许用户快速编写和执行 C 应用程序，非常适合原型设计。

总而言之，CJITC 提供了一种轻量级、便携、易于部署的方式来编译和运行 C 代码，尤其适用于快速原型设计和在不同平台上进行实验。

Claude 与创意工具集成：赋能创意工作者

Anthropic 正致力于利用 AI 技术扩展创意工作者的可能性。Claude 不会取代创意和想象力，但可以加速创意构思、拓展技能并支持更大规模的项目。关键在于将 Claude 集成到创意行业已经熟悉和信任的工具中。

为此，Anthropic 与 Blender、Autodesk、Adobe、Ableton 和 Splice 等合作伙伴合作，发布了一系列连接器 (Connectors)，允许 Claude 与创意专业人员使用的软件协同工作。

连接器功能

连接器允许 Claude 直接访问其他平台和工具。新推出的连接器旨在简化创意工作中使用 Claude 的流程：

• Ableton: 将 Claude 的回答与 Live 和 Push 的官方产品文档关联，提供更准确的信息。
• Adobe for creativity: 允许用户将图像、视频和设计导入 Claude，利用 Adobe Creative Cloud 应用程序（包括 Photoshop、Premiere、Express 等 50 多种工具）。
• Affinity by Canva: 自动化专业创意工作流程中的重复性任务，如批量图像调整、图层重命名和文件导出，并直接在应用程序中生成自定义功能。
• Autodesk Fusion: 允许 Fusion 订阅用户通过与 Claude 的对话创建和修改 3D 模型。
• Blender: 提供自然语言界面访问 Blender 的 Python API，方便用户探索和理解复杂的设置，并访问 Blender 的文档。
• Resolume Arena & Resolume Wire: 允许 VJ 和现场视觉艺术家通过自然语言实时控制 Arena、Avenue 和 Wire，用于现场表演和 AV 制作。
• SketchUp: 将与 Claude 的对话转化为 3D 建模的起点，用户可以描述房间、家具或场地概念，然后在 SketchUp 中进行完善。
• Splice: 音乐制作人可以在 Claude 中搜索 Splice 的免版税音色库。

Claude 的创意应用

Claude 可以应用于以下创意任务：

• 学习和掌握创意工具： 充当复杂软件的即时导师。
• 代码扩展工具： 编写脚本、插件和生成系统。
• 跨工具桥接： 翻译格式、重组数据，并在多个应用程序之间同步资产。
• 快速探索和交付： Claude Design 可以探索软件体验的想法，并根据反馈进行迭代，并将其结果导出到其他工具（例如 Canva）。
• 处理重复性生产工作： 自动化批量处理资产、设置项目框架或对场景进行程序化更改。

Claude 与 Blender 的合作

Blender 是一款免费、开源的 3D 内容创作套件，广泛应用于游戏开发、动态图形、建筑可视化和电影制作等行业。

Blender 开发者创建了 MCP 连接器，现已正式可用。例如，3D 艺术家可以使用 Blender 连接器分析和调试整个 Blender 场景，或构建自定义脚本以批量应用对象更改。 通过 Blender 的 Python API，连接器允许 Claude 直接向 Blender 界面添加新工具。

Anthropic 已加入 Blender 发展基金，以支持 Blender 项目继续开发其 Python API，从而实现类似此连接器的集成。由于连接器基于 MCP，因此除了 Claude 之外，其他 LLM 也能访问它，体现了 Blender 对开源和互操作性的承诺。

与学生和教育工作者合作

Anthropic 还在与艺术和设计项目合作，以支持涉及创意计算的课程。首批合作项目包括罗德岛设计学院的艺术与计算、林肯艺术学院的创意人工智能基础，以及伦敦 Goldsmiths 学院的计算艺术 MA/MFA 项目。学生和教职员工将获得 Claude 和新连接器的访问权限，他们的反馈将帮助 Anthropic 了解创意从业者对这些工具的需求。

总结:

Anthropic 正在通过一系列连接器，将 Claude AI 整合到主流创意软件中，如 Blender、Adobe、Ableton 等，旨在赋能创意工作者。 这些连接器可以帮助用户学习工具、编写代码、桥接不同应用、进行快速迭代，并处理重复性任务。Anthropic 同时也与教育机构合作，支持创意计算课程的发展。

德国军火产量超越美国，欧洲军备竞赛加速

根据德国军火巨头莱茵金属（Rheinmetall）首席执行官阿明·帕珀格（Armin Papperger）的说法，德国目前已能生产比美国更多的弹药，这反映出欧洲正在进行的军备竞赛。

主要要点：

• 产量大幅提升： 莱茵金属已将中口径弹药的年产量增加超过四倍，火炮弹药产量从7万发增加到110万发。中口径弹药介于机枪子弹和火炮弹药之间，通常用于坦克和装甲车辆上的自动加农炮。
• 背景： 欧洲各国正在竞相补充军事库存，这部分原因是前美国总统特朗普去年警告北约成员国需要增加国防开支，并减少对美国的依赖。
• 战略转变： 美国正将重心转向印太地区，以应对中国日益强大的军事力量。此外，美国在乌克兰战争中的支持有所减少，且目前也因中东冲突而牵制。
• 欧洲自主国防： 即使在伊朗战争爆发之前，欧洲国家就已经计划加强自身的国防能力，担心美国在俄罗斯入侵的情况下可能无法提供援助。乌克兰战争进一步加速了这一进程，欧洲各国持续向乌克兰转移军事装备。
• 军费开支增加： 2025年6月，北约国家承诺每年将国内生产总值（GDP）的5%用于军事和相关基础设施建设，这是过去几十年欧洲军事投资中最为显著的增长。全球军费开支去年增长近3%，主要得益于欧洲国防开支增长了14%。
• 德国的领军作用： 德国总理弗里德里希·默茨（Friedrich Merz）呼吁欧洲减少对美国的依赖，德国政府也大力推动增加国防开支，打破了二战后几十年来的持谨慎态度。德国国防部长鲍里斯·皮斯托里乌斯（Boris Pistorius）表示，德国计划到2039年拥有欧洲最强大的常规军队。
• 弹药需求激增： 弹药需求在西方军队中持续高涨，尤其是用于保护部队和打击高价值目标的火炮弹药。自2022年俄罗斯入侵乌克兰以来，莱茵金属一直在增加弹药产量。
• 155毫米弹药短缺： 155毫米弹药在乌克兰战场上消耗迅速，这种口径被北约国家广泛使用。西方国防公司正在扩大工厂并新建设施，以满足乌克兰和对俄罗斯潜在冲突感到担忧的欧洲军队的需求。莱茵金属是最大的155毫米弹药生产商之一，其于去年8月开业的新工厂将成为欧洲最大的弹药工厂。
• 北约的优先事项： 北约秘书长马尔克·鲁特（Mark Rutte）表示，北约需要优先获得更多的弹药和其他军事能力，如防空系统。

总之，由于战略重心转移、对俄罗斯威胁的担忧以及北约的压力，欧洲正在经历一场军备竞赛，德国凭借其显著提高的弹药生产能力，正处于这场竞赛的前沿。

数字墓地：互联网的逝者纪念

这是一个纪念那些被互联网遗忘的即时通讯工具、社交网络、浏览器和网站的页面。它旨在缅怀那些曾经占据我们桌面，随后因各种原因（管理不善、被收购、过时等）而消失的互联网服务。

近期新增:

• Grooveshark (2015-04-30): 免费音乐流媒体服务，因版权问题而终结。
• Skype (2023-04-29): 微软收购后逐渐淡出，曾经的国际长途通话利器。
• GPT-3 (2024): OpenAI 的早期语言模型，标志着人工智能发展的重要阶段。
• Replika (2023): 曾经流行的 AI 伴侣应用程序，因功能调整而引发争议。

已逝者列表 (按类别):

即时通讯工具:

• ICQ (1996-2024): 标志性即时通讯工具，“uh-oh”声响，一代人的文本通知。
• MSN Messenger / Windows Live Messenger (1999-2014): “请勿打扰”状态，屏幕震动和心跳，歌词作为状态。
• Yahoo! Messenger (1998-2018): 响亮的 BUZZ! 提示音，表情符号丰富。
• AOL Instant Messenger (AIM) (1997-2017): 黄色小人的图标，告别信息充满诗意。
• BlackBerry Messenger (BBM) (2005-2019): PIN 交换，R / D 状态焦虑，黑莓键盘的捍卫者。
• Google Talk / Hangouts (Classic) (2005-2022): 谷歌曾经单一的通讯工具。
• Skype (2003-2025): “boop boop” 铃声，方便亲友跨国通话。

社交网络:

• MySpace (2003-2011): 个人资料歌曲自动播放，好友列表的公共爱情或竞争。
• Friendster (2002-2015): 美国最早的社交网络之一，后来转型为游戏网站。
• Orkut (2004-2014): Google 的第一个社交网络，在巴西和印度非常流行。
• Google+ (2011-2019): 强制加入，圈子概念，但无人问津。
• Path (2010-2018): 限制 150 个好友的“更私密的社交网络”。
• Vine (2013-2017): 6 秒短视频平台，因 Twitter 的变现策略而消亡。
• Yik Yak (2013-2017): 匿名校园八卦平台，因审核问题而关闭。
• Bebo (2005-2013): 英国和爱尔兰的 MySpace 替代品。
• Hi5 (2003-2018): 拉丁美洲和土耳其流行的社交网络。

网站与网络主机:

• GeoCities (1994-2009): 最初的个人主页乌托邦，充斥着GIF动画和 MIDI 音乐。
• Angelfire / Tripod (1995-2024): GeoCities 的表亲，但规模较小。
• Digg (2004-2017): 曾经的流行新闻聚合网站。
• Delicious / del.icio.us (2003-2017): 社交书签网站。

其他:

• Netscape Navigator (1994-2008): 曾经的浏览器霸主。
• Internet Explorer (1995-2022): 备受诟病的浏览器。
• Napster (1999-2002): 颠覆音乐产业的盗版音乐平台。
• Winamp (1997-2013): 可

代码生成代理文档 (AGENTS.md) 的有效性研究总结 (Summary of Effectiveness Study of Code Generation Agent Documentation - AGENTS.md)

本文总结了一项关于代码生成代理文档 (AGENTS.md) 对代码生成质量影响的系统性研究。研究表明，AGENTS.md 的效果差异巨大，好的文件能显著提升代码质量，相当于从 Haiku 模型升级到 Opus 模型，而差的文件则可能使代码质量低于没有 AGENTS.md 的情况。

核心发现：

• 渐进式信息披露胜于全面覆盖 (Progressive Disclosure Beats Comprehensive Coverage): AGENTS.md 应像技能一样培养，先覆盖常见用例，再将细节移至可按需加载的参考文档。每个参考文档的范围要明确，以便代理知道何时加载。最佳实践是 100-150 行的 AGENTS.md 文件，配合少量精简的参考文档，在中等规模模块 (约 100 个核心文件) 中可提升 10-15% 的指标。
• 程序化工作流程引导代理完成任务 (Procedural Workflows Guide Agents to Completion): 使用编号的、多步骤的工作流程描述任务，是提升代理完成任务能力的最强模式之一。例如，一个六步部署新集成的工作流程，成功率从 40% 提升到 10%，平均完成速度更快，正确性 和 完整性 分别提升 25% 和 20%。
• 决策表解决代码编写前的歧义 (Decision Tables Resolve Ambiguity Before Code Writing): 当存在多种合理实现方式时，决策表能帮助代理在编写代码前做出选择，直接提升代码规范的遵循程度。例如，使用决策表来选择 React Query 或 Zustand 进行状态管理。
• 真实代码示例提升代码复用 (Real Codebase Examples Improve Code Reuse): 3-10 行的生产代码片段能有效提升代码复用率和模式遵循。
• 领域特定规则仍然重要 (Domain-Specific Rules Still Matter): 针对特定语言或组织的特殊规则有效，但规则过多会适得其反。
• 禁止行为必须配以建议 (Pair Every "Don't" with a "Do"): 仅有禁止性说明的文档效果差于提供替代方案的文档。
• 保持代码和文档的模块化 (Keep Code and AGENTS.md Modular): 最佳文档描述相对独立的子模块，避免大型跨模块文档。

常见问题与应对 (Common Pitfalls and Solutions):

• 过度概览 (Overexploration Trap): 代理被引导阅读过多架构文档或陷入对大量警告的验证，导致性能下降。
  • 解决方案: 采用渐进式信息披露，使用参考文件，避免过多的架构概述和警告。
• 旧文档失效 (New Patterns Break Old Documentation): 引入新模式时，旧的文档可能引导代理走向错误的方向。

文档发现优先级 (Documentation Discovery Priorities):

• AGENTS.md 文件被 100% 发现。
• AGENTS.md 中的参考链接被 90% 以上的会话加载。
• 目录级别的 README.md 文件被 80% 以上的会话读取。
• 嵌套的 README 文件、以及未被任何文件引用的文档，被发现的概率较低。

建议 (Recommendations):

• 优先将内容放入 AGENTS.md 或其参考文件中，确保代理能够发现。
• 优化现有文档，使其更精简、更具针对性，包含代码示例和可搜索的描述。
• 避免大型文档环境，专注于 AGENTS.md 的质量和清晰度。

后续研究方向 (Future Research):

• AGENTS.md 的长期维护。
• 交互式和分析任务的文档最佳实践。

HardenedBSD 代码仓库迁移至 Radicle 进展总结

过去一周，HardenedBSD 团队正在将代码仓库迁移至 Radicle。目前，Radicle 已经可以初步使用，尽管仍存在一些问题需要完善。

核心功能与现状：

• 迁移进度： 团队已成功将部分代码仓库迁移至 Radicle，并计划逐步完成 100% 的仓库迁移。secadm 项目预计将是下一次迁移的目标。
• Ports 树集成： 已进行初步的 ports 树集成，实现了通过 radicle-httpd 实例下载项目 distfiles 的功能，类似于 USE_GITHUB / USE_GITLAB 机制。该集成仍需进一步完善，但已足以构建 ports-mgmt/pkg。
• 性能问题： Radicle 在处理大型仓库时可能存在性能问题。建议用户在 ~/.radicle/config.json 中设置 node.limits.fetchPackReceive 为至少 3GB 以支持更大的仓库。
• 仓库地址： HardenedBSD 的 Radicle 仓库可以在以下地址浏览：https://radicle.network/nodes/rad.hardenedbsd.org

当前已迁移的仓库：

1. rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm: HardenedBSD-src
2. rad:z2XrdvALg77ycnuZRXgScb27yb3wM: HardenedBSD-ports
3. rad:z3QDZAW2FAfuLvihrhiyDC9fAD8G9: HardenedBSD-pkg

可靠的迁移步骤：

1. 连接到 HardenedBSD 种子 VM： rad node connect z6MknwwMpmZET1PcvQjPYhA6hGY7wkYzxb9YtSRh5j2qSQdG@rad.hardenedbsd.org:8776
2. 种子 src 树 (对 ports 树重复此步骤)： rad seed --from z6MknwwMpmZET1PcvQjPYhA6hGY7wkYzxb9YtSRh5j2qSQdG rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm
3. 监控 ~/.radicle/storage/rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm.tmp 的状态，直到它移动到 ~/.radicle/storage/rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm。 此过程耗时较长。
4. 克隆仓库： rad clone rad:z2HLHXgL1xevBNQsf8BmQW7MpJmtm

团队感谢大家在此过程中的耐心和支持，并承诺将持续更新 Radicle 集成进展。

Forgejo 安全状况评估与漏洞披露策略

本文总结了作者对 Fedora 迁移至 Forgejo 后的安全状况评估结果，以及作者选择的漏洞披露策略。

安全评估结果：

作者在短时间内（一个工作日下午）对 Forgejo 代码库进行了初步的安全评估，发现存在大量安全问题，包括：

• SSRF (Server-Side Request Forgery): 多个位置存在 SSRF 漏洞。
• 缺少安全策略: 缺乏 CSP (Content Security Policy) 和 Trusted-Types。
• 代码质量问题: JavaScript 代码存在“临时性”的模板编写方式。
• 密码学实践问题: 存在密码学方面的错误。
• 认证机制缺陷: 存在 OAuth2、OTP、Session/访问处理、以及漏洞后恢复机制方面的缺陷。
• DoS (Denial of Service): 发现多种低风险的 DoS 攻击途径。
• 信息泄露: 存在信息泄露问题。
• TOCTOU (Time-of-Check to Time-of-Use): 存在 TOCTOU 漏洞。

这些漏洞可以被组合利用，导致远程代码执行 (RCE)、敏感信息泄露、持久化账户访问以及 OAuth2 权限提升等严重后果。

漏洞利用条件:

作者发现的 RCE 漏洞依赖于以下条件：

• 开放注册: 需要允许用户注册账户。
• 非默认配置: Forgejo 的配置选项需要设置为非默认值。

尽管如此，由于依赖开放注册，该漏洞的实际价值较低。

披露策略选择：胡萝卜披露 (Carrot Disclosure)

作者考虑了多种披露策略，最终选择了“胡萝卜披露”策略。该策略的核心思想是：

• 仅披露漏洞输出: 只公开利用漏洞产生的关键输出（经过红字处理），以证明软件存在漏洞。
• 激励修复: 迫使软件供应商进行全面的安全审计，修复尽可能多的问题，以避免用户因运行已知漏洞软件而流失。

漏洞利用演示:

作者提供了一个名为 chain_alpha.py 的 Python 脚本，可以利用 Forgejo 的漏洞创建恶意管理员账户，并执行命令。 脚本输出显示成功执行了命令，并展示了命令执行的上下文信息。 该脚本的 SHA256 哈希值也一并提供。

其他发现:

• 作者还发现了一些其他的漏洞利用脚本，例如 chain_beta.py、chain_gamma.py、dos 目录下的各种 DoS 工具等。
• 作者尝试通过提交补丁来修复漏洞，但认为这是一个“无休止的 whack-a-mole”游戏，因为存在系统性问题。
• 作者在 Mastodon 上发布的相关帖子曾被删除，后已恢复。

总结:

Forgejo 代码库存在大量安全问题，需要进行全面的安全审计和修复。作者选择胡萝卜披露策略，希望能够促使 Forgejo 团队积极应对这些安全问题。

总结：如何毒害大型语言模型（LLM）的供应链

本文讲述了作者，一位“6 Nimmt!世界冠军”，如何通过精心设计的攻击，欺骗大型语言模型（LLM），使其相信虚构的冠军头衔。作者并非真正的冠军，而是通过简单而廉价的手段，成功地将虚假信息渗透到LLM的知识体系中。

核心实验：

作者设计的攻击方案包括：

1. 注册域名： 购买一个廉价的域名 (6nimmt.com)。
2. 创建虚假新闻稿： 使用LLM生成一篇虚假的关于其赢得“6 Nimmt!”世界冠军的新闻稿，发布到该域名上。
3. 修改维基百科： 在“6 Nimmt!”的维基百科页面添加一段声明其为世界冠军，并引用该域名作为来源。

攻击原理：

这种攻击利用了LLM对维基百科和其他网站权威性的信任。通过维基百科的引用和域名的新闻稿相互引用，形成了一个“信任循环”，使得LLM误认为该信息是真实可靠的。

失败模式：

作者指出，这种攻击存在三种主要的失败模式：

1. 检索层： LLM直接从网络搜索结果中获取信息，而网络搜索结果容易受到SEO中毒的影响。
2. 模型训练语料库层： 虚假信息如果长时间存在于维基百科上，可能会被纳入LLM的训练语料库，从而永久性地影响模型。
3. 代理层： LLM代理根据检索到的信息执行操作，如果检索到的信息被中毒，可能会导致严重的后果。

重要性：

作者强调，这种攻击比人们想象的更严重，因为它暴露了LLM对网络信息的信任问题。攻击成本低廉，易于实施，且可能被恶意行为者用于政治宣传、虚假信息传播等。

应对措施：

作者提出了以下应对措施：

• 个人用户： 对单来源信息保持怀疑，注意平行措辞、自引用的维基百科条目。
• LLM提供商和研究人员： 增加来源溯源功能，对近期维基百科编辑和可疑引用模式进行过滤。
• 维基百科： 加强对LLM辅助的恶意编辑的防范，审查单来源引用和域名注册时间。

结论：

作者认为，LLM最差的检测能力在于它对文本和资源的信任。未来的信息污染和供应链攻击可能不会发生在模型训练阶段，而是在模型推理阶段，通过污染检索到的信息来操纵LLM。作者的实验证明，只需12美元的域名、一次维基百科编辑和20分钟的时间，就可以欺骗LLM，这引发了对AI系统信任的严重担忧。