2025-12-17

关于大规模监控的地图和资源总结

以下是对提供的内容的总结：

项目概述:

该项目提供了一个地图，用于追踪美国各地地方政府正在讨论或实施的监控技术，例如Flock摄像头、面部识别技术和自动车牌识别器 (ALPR)。该地图旨在帮助公众了解这些技术的使用情况，并采取行动。

核心功能:

• 会议追踪: alpr.watch 扫描地方政府会议议程，寻找与“Flock”、“车牌识别器”、“ALPR”等关键词相关的讨论。地图上每个标记都显示了这些讨论发生的地点。
• ALPR摄像头可视化: 地图允许用户查看已知的ALPR摄像头的位置。
• 邮件提醒: 用户可以输入电子邮件地址，以便接收其所在区域相关会议的提醒。
• 数据统计: 项目会显示监控的当地议会数量、索引的会议数量以及已绘制的摄像头数量。

关键技术和公司:

• ALPR (自动车牌识别): 一种使用摄像头和人工智能技术捕获、读取和存储车辆车牌信息的系统。通过ALPR系统，可以建立一个庞大的数据库，记录车辆（以及车内人员）的出行轨迹。
• Flock Safety: 美国最大的ALPR摄像头制造商之一，其系统被推广给社区和执法部门。Flock摄像头除了车牌信息外，还会记录车辆的品牌、型号、颜色等特征，并将数据共享给大量的机构和司法管辖区，形成一个覆盖数百万美国人的监控网络。

监控的风险和潜在问题:

• 范围扩大: 项目强调了监控系统范围不断扩大的历史趋势，例如：
  • 最初用于“解决犯罪”的系统，可能会被用于移民执法。
  • 临时项目可能变成永久基础设施。
  • 数据共享协议可能会覆盖越来越多的机构。
  • 技术进步可能导致新的侵入性用途。
  • 法规和监督往往落后于技术部署。

反监控组织和资源:

项目列出了以下致力于保护公民隐私的组织，并鼓励公众支持或参与当地的倡议：

• Electronic Frontier Foundation (EFF): 领先的非营利组织，致力于捍卫数字隐私和公民自由。 (eff.org)
• ACLU: 通过诉讼和宣传，在全国范围内反对监控过度。 (aclu.org)
• Fight for the Future: 一个数字权利组织，动员基层力量反对监控。 (fightforthefuture.org)
• Surveillance Technology Oversight Project (STOP): 在纽约及其他地区对侵入性监控进行诉讼。 (stopspying.org)
• Institute for Justice: 一家公民自由法律公司，已对Flock的无证大规模监控提起诉讼。 (ij.org)
• 当地社区组织: 鼓励用户查找当地的隐私倡导组织。

数据说明:

• 在12月中旬之前的数据可能未经验证。
• 所有未来的标记均已由管理员审核批准。

GitHub Actions 定价变更延期及后续计划总结

GitHub 宣布对 GitHub Actions 的定价和产品模式进行调整，但随后推迟了原定的定价变更，以便重新评估方案。同时，GitHub 将于 2026 年 1 月 1 日继续降低托管运行器（GitHub-hosted runners）的价格，最高可降低 39%。

主要内容如下：

1. 定价变更延期： 原定于实施的针对自托管运行器（self-hosted runners）的定价变更被推迟，GitHub 将重新评估方案，并听取开发者、客户和合作伙伴的反馈。
2. 托管运行器价格降低： 2026 年 1 月 1 日起，GitHub 将继续降低托管运行器的价格，最高可降低 39%。
3. 背景原因： 运行 GitHub Actions 控制平面需要实际成本，GitHub 也在投资自托管运行器，以支持复杂企业场景下的大规模应用。
4. 定价调整的必要性： 过去，自托管运行器用户能够免费使用 GitHub Actions 的基础设施和服务，这导致 GitHub 托管运行器的价格需要补贴一部分成本。新的定价旨在更准确地反映使用情况和价值，并促进平台创新。
5. 影响范围：
   • 96% 的用户将不会受到账单变化的影响。
   • 4% 的用户可能会受到影响，其中 85% 的用户账单将减少，剩余 15% 的用户账单可能增加，平均增加约 13 美元。
   • 公共仓库的 Actions 使用将继续免费。
   • GitHub Enterprise Server 的定价不受影响。
6. 新费用： 将引入每分钟 0.002 美元的 Actions 云平台费用，适用于 GitHub 托管运行器和自托管运行器。
7. 对自托管运行器的投资： GitHub 将加大对自托管运行器体验的投资，包括：
   • GitHub Scale Set Client: 提供轻量级 Go SDK，用于构建自定义的自动扩展解决方案。
   • 多标签支持： 重新引入对 GitHub 托管大型运行器和自托管运行器的多标签支持。
   • Actions Runner Controller 0.14.0： 改进 Helm Charts、日志记录、指标和版本要求。
   • Actions Data Stream： 提供近乎实时的 Actions 事件数据流。
8. 生效时间：
   • 托管运行器价格降低：2026 年 1 月 1 日生效。
   • 自托管运行器云平台费用：2026 年 3 月 1 日生效。

总结: GitHub 暂停了自托管运行器的定价变更，并致力于改进 Actions 平台，同时承诺降低托管运行器的价格，并加大对自托管运行器体验的投资。 通过收集反馈和持续改进，GitHub 旨在为开发者提供更快速、更可靠、更灵活的 CI/CD 体验。

GitHub Actions 价格更新及改进公告 (GitHub Actions 价格更新及改进公告)

以下是对 GitHub Actions 相关公告的总结，包含 2025 年 12 月 16 日的原始公告和后续更新。

主要内容：

• 价格调整暂缓： GitHub 宣布暂时推迟之前宣布的针对自托管 GitHub Actions 的计费变更，以便重新评估方案。
• 托管运行器价格下调： GitHub 将于 2026 年 1 月 1 日降低 GitHub 托管运行器的价格，最多可降低 39%。
• 自托管运行器计费： 从 2026 年 3 月 1 日起，将对自托管运行器的使用收取每分钟 0.002 美元的费用。此费用将计入您的计划包含的免费使用分钟数中。

关键细节：

• 公共仓库不受影响： 在公共仓库中的作业执行价格将保持不变。
• GitHub Enterprise Server 用户不受影响： GitHub Enterprise Server 客户的定价方案不会受到影响，自托管运行器在 GitHub Enterprise Server 上的使用将继续免费。
• 投资自托管体验： GitHub 将增加对自托管体验的投资，以支持更广泛的场景，包括 Windows 支持、平台支持和自动扩展等。
• 免费使用额度： 自 2026 年 3 月 1 日起，自托管运行器将纳入免费使用额度中，并按照标准运行器的方式消耗分钟数。

原因解释：

GitHub 解释说，之前 GitHub Actions 的基础设施和服务成本由托管运行器的价格部分补贴。新的定价旨在更准确地反映使用情况和为每位 Actions 用户提供的价值，并为平台创新和投资提供资金。

影响评估：

• 96% 的客户将不会看到账单变化。
• 受到影响的 4% 的用户中，85% 将看到账单减少，剩余 15% 的用户账单增加幅度为平均 13 美元。
• 针对免费和 Pro 计划的用户，只有 0.09% 的用户会看到账单增加，且平均增加幅度低于 2 美元。
• GitHub 提供了定价计算器和使用报告下载功能，帮助用户估计新的月度成本。

反馈与改进：

GitHub 正在积极收集开发者、客户和合作伙伴的反馈，并已开放讨论区 (https://github.com/orgs/community/discussions/182186)，以用于 GitHub Actions 的路线图规划。

相关资源：

• GitHub Actions 运行器定价文档：https://docs.github.com/billing/reference/actions-runner-pricing
• GitHub 公共路线图：https://github.com/orgs/github/projects/4247
• Actions 定价计算器：https://github.com/pricing/calculator#actions
• 查看和下载使用报告：https://docs.github.com/billing/how-tos/products/view-productlicense-use
• 自托管运行器迁移指南：https://docs.github.com/actions/tutorials/migrate-to-github-runners

总结：Mozilla CEO 讨论限制广告拦截器引发担忧

根据“The Verge”的采访，Mozilla 新任 CEO Anthony Enzor-DeMeo 似乎暗示过限制 Firefox 浏览器中广告拦截器的可能性。他表示，如果 Firefox 阻止广告拦截器，预计可以带来 1.5 亿美元的额外收入，但他个人认为这样做“不符合使命”。

作者对这一潜在举动表示失望和担忧，认为这可能会损害 Mozilla 的核心价值观，即对开放标准和开放网络的承诺，以及强大的插件系统。作者指出，Firefox 长期以来吸引了注重隐私的忠实用户群体，这些用户对项目的发展至关重要，并且经常为普通用户提供技术建议。

作者承认 Mozilla 需要盈利，但批评 CEO 公开讨论限制广告拦截器这一选项，即使他个人不想这样做，也引发了负面公关。作者认为，如果这一选项不再考虑，CEO 不应该提及它。

作者目前对 Mozilla 的未来感到犹豫，但 CEO 的言论表明限制广告拦截器的可能性仍然存在。

关键词: Mozilla, Firefox, 广告拦截器, 开放源代码, FOSS

总结：简化现代图形 API 的必要性

过去几十年，图形 API、着色器框架和驱动程序变得越来越复杂。管道状态对象（PSO）的爆炸式增长导致了 100GB 的本地着色器管道缓存和大规模的云服务器。本文探讨了如何简化与 GPU 交互的方式，并提出了基于现代 GPU 架构的 API 设计思路。

历史回顾与现状:

• 低级 API 的兴起: 2013 年，AMD 在 Xbox One 和 PlayStation 4 上的成功推动了低级 PC 图形 API 的发展，例如 DirectX 12、Vulkan 和 Metal。这些 API 旨在提高性能，但由于现有渲染接口的设计，导致了新的复杂性，例如需要中间层来跟踪资源和管理状态。
• 硬件发展与 API 的滞后: 现代 GPU 架构已经发展到具有完全缓存层次结构、直接内存访问和无绑定纹理等功能。然而，现有的 API 仍然依赖于过时的概念，例如保留模式对象和大量的 PSO。
• PSO 爆炸问题: PSO 爆炸是当前图形 API 面临的最大问题之一，导致了巨大的存储空间占用和加载时间延迟。

现代 GPU 架构的特性:

• 缓存层次结构: 现代 GPU 具有完全缓存层次结构，包括最后一级缓存，可以提高内存访问速度。
• 直接内存访问: CPU 可以使用 PCIe ReBAR 或 UMA 直接写入 GPU 内存。
• 无绑定纹理: 纹理描述符可以直接存储在 GPU 内存中的数组中。
• 64 位 GPU 指针: 64 位 GPU 指针直接支持在着色器中访问内存。

新 API 设计思路:

本文提出了一个简化 API 的设计思路，基于以下原则：

• 简化内存管理: 使用 CUDA 风格的内存分配 API，允许 CPU 直接写入 GPU 内存，并通过复制命令将数据转换成最佳格式。
• 无绑定资源: 移除绑定 API，使用全局可索引的纹理堆，允许直接访问纹理数据。
• 简化着色器管道: 移除复杂的 PSO 概念，将所有状态信息嵌入到简单的 64 位指针中。
• 动态渲染: 采用 Vulkan 1.3 和 Metal 4.0 的动态渲染方式，允许在运行时更改渲染状态，减少 PSO 的数量。
• 统一的着色器: 将所有着色器类型合并到一个统一的框架中，使用内联函数和编译器优化来提高性能。
• GPU 驱动程序优化: 充分利用 GPU 驱动程序的能力，例如 DCC 压缩和 Morton 排序，来提高性能。

具体改进:

• Root 结构: 使用单个 64 位指针作为根数据，包含所有必要的输入参数，简化了数据绑定。
• 纹理描述符堆: 使用全局可索引的纹理描述符堆，简化了纹理管理。
• 动态渲染状态: 允许在运行时更改渲染状态，减少了 PSO 的数量。
• 统一的着色器框架: 简化了着色器框架，减少了 API 复杂性。
• 纹理缓存优化: 利用 GPU 缓存和 DCC 压缩来提高纹理访问速度。

结论:

现代图形 API 已经过时，需要进行简化。本文提出的新 API 设计思路基于现代 GPU 架构的特性，可以显著减少 API 复杂性，提高性能，并为开发者提供更大的灵活性。 虽然实现起来可能需要一些工作，但简化图形 API 的好处远远大于挑战。 展望未来，希望厂商能够简化现有 API，并采用基于现代 GPU 架构的设计理念。

关键词: 图形 API, 着色器, 驱动程序, 性能, 简化, 内存管理, 无绑定, PSO, 渲染, GPU, 现代架构

ty：一款极速的 Python 类型检查器和语言服务器 (Beta 版发布)

TL;DR: ty 是一款用 Rust 编写的极速 Python 类型检查器和语言服务器，旨在替代 mypy、Pyright 和 Pylance 等工具。

概述

Astral 团队，以其 Python 包管理器 uv 和 linter/formatter Ruff 而闻名，宣布了其最新工具 ty 的 Beta 版发布。 ty 旨在提供更快速、更准确的 Python 类型检查和语言服务器体验。团队内部已经开始使用 ty，并建议有经验的用户将其用于生产环境。

关键特性与优势

• 卓越性能: ty 在不使用缓存的情况下，速度比 mypy 和 Pyright 快 10 倍到 60 倍。在编辑器中使用时，速度差距更大。例如，在 PyTorch 项目中编辑文件时，ty 的重新计算时间为 4.7ms，比 Pyright (386ms) 快 80 倍，比 Pyrefly (2.38 秒) 快 500 倍。
• 准确、实用、易用: ty 引入了先进的类型系统特性，例如：
  • 一等交集类型 (first-class intersection types)
  • 高级类型收窄 (advanced type narrowing)
  • 复杂的覆盖率分析 (sophisticated reachability analysis)
  • 避免对用户意图的假设 (avoiding assumptions)
• 开源构建: ty 的开发过程完全公开，采用 MIT 许可证。
• 增量式架构: ty 的核心设计理念是“增量性”，这意味着它只重新计算必要的计算，从而实现编辑器中的快速实时更新。
• 一流的诊断系统: 借鉴了 Rust 编译器的高质量错误信息，ty 提供了清晰、全面的诊断信息，能够解释错误的原因并提供修复建议。

安装与使用

用户可以通过以下方式安装 ty：

• uv tool install ty@latest
• VS Code 扩展：https://marketplace.visualstudio.com/items?itemName=astral-sh.ty

未来发展方向

• 稳定版发布: 预计明年发布稳定版。
• 功能完善: 重点关注 bug 修复、完成 Python 类型规范中的剩余功能，以及对 Pydantic 和 Django 等常用第三方库提供一流支持。
• 语义能力: ty 将为 Astral 工具链提供语义能力，例如：死代码消除、未使用的依赖检测、SemVer 兼容的升级强制、CVE 可达性分析、类型感知的 Linting 等。

致谢

ty 的开发得益于众多贡献者的努力，包括来自各个领域的专家。Astral 团队特别感谢 Salsa 团队、Elixir 团队以及 Python 类型社区的成员们提供的支持和帮助。

人工智能将推动形式化验证走向主流 (人工智能将推动形式化验证走向主流)

文章发布于： 2025年12月8日，作者：Martin Kleppmann

核心观点： 人工智能（AI）将显著降低形式化验证的成本，使其在软件工程领域走向主流。AI不仅能够生成代码，还能辅助编写形式化证明脚本，从而改变软件开发模式。

详细内容：

形式化验证是一种通过数学方法证明代码满足预定义规范的技术。尽管长期存在，但由于其复杂性和高昂成本，一直未能广泛应用。

• 现有工具和案例： 存在多种形式化验证工具，例如Rocq, Isabelle, Lean, F* 和 Agda。已经有大型系统利用形式化验证，例如seL4微内核、C编译器和加密协议栈。
• 传统挑战： 传统形式化验证需要经验丰富的专家（通常是博士），成本极高。例如，seL4微内核的验证就需要20人年，并编写了超过20万行的Isabelle代码。
• AI带来的变革： 近期，基于大型语言模型（LLM）的编码助手开始具备编写形式化证明脚本的能力。虽然目前仍需要人工指导，但未来有望实现自动化。
• AI验证AI代码的必要性： AI生成代码需要形式化验证，以取代人工代码审查，确保代码正确性。形式化验证的精确性可以有效抵消LLM的不确定性。
• 形式化验证新挑战： 随着验证过程自动化，挑战将转移到正确定义规范上，即准确描述需要验证的系统属性。 AI可以协助将自然语言规范翻译成形式化语言，但仍需注意潜在的语义损失。
• 未来展望： 理想状态下，开发者只需用高层次的声明式方式定义代码的属性，AI就能自动生成代码和证明，开发者无需再直接查看AI生成的代码，就像现在无需查看编译器生成的机器码一样。

总结：

1. 形式化验证即将变得更加廉价。
2. AI生成的代码需要形式化验证，以确保其正确性。
3. 形式化验证的精确性可以弥补LLM的模糊性。

作者预测，形式化验证将很快走向主流，但关键在于文化转变，让人们认识到形式化验证在实践中已具备可行性。

(中文翻译)

OpenAI 项目团队结构概览 (OpenAI Project Team Structure Overview)

This document outlines the organizational structure of a project at OpenAI, likely related to a significant new model or initiative. It details various teams and individuals contributing to different areas. Here's a summary:

I. Leadership (领导)

• Research Lead: Gabriel Goh
• Product Lead: Adele Li
• Sora Lead: Bill Peebles
• World Simulation Lead: Aditya Ramesh
• Chief Research Officer: Mark Chen
• Multimodal Lead: Prafulla Dhariwal

II. Core Teams & Contributors (核心团队和贡献者)

• Core Team: A large group of engineers and researchers (approximately 20 individuals listed, including Alex Fang, Alex Yu, Ben Wang, Bing Liang, etc.). This likely represents the primary development team.
• Research Contributors: A group of researchers supporting the core team (approximately 10 individuals listed, including Bram Wallace, Dmytro Okhonko, Haitang Hu, etc.).
• Core Inference: Team focused on the inference process of the model, including Adam Tart, Alyssa Huang, and others.
• Research Collaborators: A broader group of individuals collaborating on research aspects (approximately 20 individuals listed, including Aditya Ramesh, Alex Nichol, Andrew Kondrich, etc.).
• Inference Collaborators: Individuals supporting the inference process (Jiayu Bai, Kevin King, Stanley Hsieh, Weiyi Zheng).

III. Specialized Teams (专业团队)

• Data & Evaluation: Responsible for data management and model evaluation (approximately 20 individuals listed, including Alexandra Barr, Aparna Dutta, Arshi Bhatnagar, etc.).
• Applied: Focuses on applying the model to practical applications (a large group, approximately 30 individuals listed, including Affonso Reis, Alan Gou, Alexandra Vodopianova, etc.).
• Safety, Safety Systems, Integrity, Policy & Trust: Crucial team dedicated to ensuring the safety, security, and ethical considerations of the project (approximately 20 individuals listed, including Abby Fanlo Susk, Adam Wells, Aleah Houze, etc.).
• Product Operations, Program Management and Governance: Manages the project's operational aspects and governance (approximately 5 individuals listed, including Antonio Di Francesco, Filippo Raso, Grace Wu, etc.).
• Legal: Provides legal support (Ally Bennett, Tony Song, Tyce Walters).
• Communications, Marketing, Community, Design & Creative: Handles external communication, marketing, and design aspects (a very large group, approximately 40 individuals listed, including Akash Iyer, Alex Baker-Whitcomb, Angie Luo, etc.).

IV. Special Thanks (特别感谢)

A list of individuals who provided significant support and contributions (approximately 20 individuals listed, including Amy Yang, Arvin Wu, Avital Oliver, etc.).

V. Executive Leadership (执行领导)

• Fidji Simo, Hannah Wong, Jakub Pachocki, Jason Kwon, Johannes Heidecke, Kate Rouch, Lauren Itow, Mark Chen, Mia Glaese, Nick Ryder, Nick Turley, Prafulla Dhariwal, Sam Altman, Sulman Choudhry. This represents the senior management overseeing the project.

Overall Impression: This document reveals a large and diverse team working on a complex project at OpenAI. The organization is structured around core development, research, specialized applications, safety, and external communication, reflecting the significant scope and importance of the undertaking. The sheer number of individuals involved suggests a project of considerable scale and ambition.

GitHub Actions 价格变更总结 (GitHub Actions Pricing Changes Summary)

以下是对 GitHub Actions 价格变更的总结，内容基于原文：

核心变更：

GitHub 将于 2026 年 3 月 1 日起，对所有 GitHub Actions 的使用收取新的平台费用，费用为每分钟 $0.002。 之前，GitHub Actions 的控制平面是免费的。这意味着，即使你使用 GitHub Actions 并在 GitHub 之外的运行器（例如 Blacksmith、自有机器或 AWS 账户）上运行作业，你无需向 GitHub 支付任何费用，仅需支付计算资源费用。 新的费用改变了这一情况。

CI 成本构成：

现在，CI 成本由两部分组成：

• 计算成本： 由运行运行器的实体承担。
• GitHub 平台费用： 按 Actions 使用分钟数收取，每分钟 $0.002。

GitHub 变更原因：

GitHub 长期存在“毕业 churn”问题。随着公司规模扩大，CI 工作负载变得更大、更复杂、更昂贵。当 CI 工作负载达到一定规模时，GitHub 托管的运行器既变得缓慢又昂贵，促使团队转向自托管或使用第三方运行器，例如 Blacksmith。

此前，这种转变的一个重要副作用是，公司可以在不向 GitHub 支付 CI 执行费用情况下，继续使用 GitHub Actions 的控制平面。GitHub 提供调度、编排和工作流自动化，但无法从一些最大的、增长最快的客户那里获得收入。

新的每分钟平台费用改变了这一点，直接将 Actions 控制平面货币化，并为 GitHub 从 CI 中赚取的金额设定了底线，无论作业在哪里运行。 换句话说，自托管不再免费。

GitHub 托管运行器价格调整：

同时，GitHub 降低了 GitHub 托管运行器的价格。这并非偶然。更低的价格使 GitHub 托管的运行器更具吸引力，而平台费用则为自托管引入了新的、不可避免的成本。

GitHub 的视角：

从 GitHub 的角度来看，这是一个合理的举措。大多数 Actions 使用集中在较小的运行器上，因此托管运行器价格的降低可能不会对收入产生重大影响。更重要的是，GitHub 正在以更高的利润率进行平台收入交易，而不是以较低利润率的计算收入。托管运行器本质上是一个计算业务，而平台费用可以通过软件货币化，而无需基础设施成本线性扩展。

对第三方运行器的影响：

平台费用在很大程度上回答了客户过去提出的关于 GitHub 如何看待第三方运行器的问题。现在，GitHub 无论作业在哪里运行，都可以对 Actions 的使用进行货币化，从而将第三方运行器（如 Blacksmith）定位为生态系统合作伙伴，而不是规避手段。

自托管的影响：

在变更之前，自托管是一种避免向 GitHub 支付费用的一种方式。现在不再如此。自托管仍然需要运行 CI 基础设施的运营负担，同时还会产生 GitHub 的每分钟费用。

降低成本的策略：

主要控制变量是减少 CI 作业消耗的分钟数。例如，使用设计用于最大限度地减少实际时间并消除冗余工作的基础设施，就像 Blacksmith 的目标一样。

Blacksmith 的优化方向：

Blacksmith 通过以下方式优化 CI 性能和成本：

• 更快的机器： Blacksmith 在具有 50% 以上单核性能的 CPU 上运行 CI 作业，并且正在部署更先进的实例，进一步减少 CPU 密集型工作负载的运行时间。
• 重用工作： 通过持久化 Docker 层的缓存，允许重用未更改的层，从而将 Docker 构建时间从几分钟缩短到几秒。
• 容器缓存 (Beta)： 预先在运行器上填充服务容器，消除重复的镜像拉取和提取。

总结：

新的平台费用使 CI 性能和成本紧密耦合，降低 CI 时间和 Actions 总量成为关键。

JustJSHTML: 一個使用 GPT-5.2 快速產生的 JavaScript HTML5 解析器

摘要：

本文描述了作者 Simon Willison 如何使用 GPT-5.2 和 Codex CLI 將 Emil Stenström 的純 Python HTML5 解析器 JustHTML 移植到 JavaScript，並創建了名為 JustJSHTML 的新庫。整個過程耗時約 4 小時，並且成功通過了 html5lib-tests 測試套件中的 9,200 個測試項目。

主要內容：

• JustJSHTML 介紹： JustJSHTML 是一個無依賴的 JavaScript HTML5 解析器，API 設計模仿了 JustHTML，並通過了 html5lib-tests 測試套件中的 9,200 個測試項目。項目代碼可以在 simonw/justjshtml 找到。
• 技術背景： HTML5 規範對處理無效 HTML 的方式做了精確的規定，這對於瀏覽器和解析器來說至關重要。html5lib-tests 測試套件是 HTML5 解析器互操作性的黃金標準，被多個項目使用。
• 移植過程：
  • 作者首先準備了環境，克隆了 JustHTML 和 html5lib-tests 倉庫，並創建了 JustJSHTML 目錄。
  • 使用 GPT-5.2 和 Codex CLI，通過一系列提示（總共八個）逐步完成移植任務。
  • 第一個提示要求 Codex 設計新的 JavaScript 庫的 API，並創建 spec.md 文件。
  • 接下來的提示則逐步引導 Codex 實現功能，包括一個簡單的煙霧測試、GitHub Actions 測試、以及擴展公共 API。
  • 作者在過程中進行了監控和少量調整，並在最後添加了一個 playground 界面，方便用戶測試。
• 代碼生成： Codex CLI 總共使用了 2,089,858 個輸入 token，97,122,176 個緩存 token 和 625,563 個輸出 token，生成了 9,000 行 JavaScript 代碼，跨越 43 個 commit。
• 重要發現：
  • 先進的 LLM 可以在極少的監督下執行複雜的多小時任務，並進行大量的工具調用。
  • 如果問題可以歸結為穩健的測試套件，則可以放心地讓代碼代理在上面運行。
  • 將開源庫從一種語言移植到另一種語言，通過代碼代理可以非常有效地完成。
  • 代碼的成本已經大幅下降，因為代碼代理可以自行檢查其工作。
• 開放性問題：
  • 這種開發方式是否違反了版權？
  • 即使合法，是否符合道德規範？
  • 這種方式是否會對開源生態系統產生影響？
  • 作者是否可以聲稱對代碼擁有版權？
  • 是否應該發布通過這種方式構建的軟件庫？
  • 與人工團隊精心打造的庫相比，這種方式構建的庫的質量如何？

總結來說，這篇文章展示了使用 LLM 快速生成和測試大型代碼庫的可能性，並提出了關於這類開發方式的倫理和法律問題。

麻省理工学院教授在家中被枪杀：事件摘要

近日，麻省理工学院（MIT）教授努诺·福·戈梅斯·卢埃罗（Nuno F Gomes Loureiro）在其位于波士顿附近的住所遭到枪击身亡，引发当局的广泛调查。

事件概要：

• 遇害人信息： 努诺·福·戈梅斯·卢埃罗，47岁，葡萄牙籍，麻省理工学院核科学与工程教授，并于2024年被任命为麻省理工学院等离子体科学与核聚变中心主任。
• 事件发生： 卢埃罗于当地时间周一晚上8点30分（格林威治标准时间凌晨1点30分）在家中遭到枪击，并在次日早上于波士顿医院去世。
• 调查状态： 警方正在对该事件进行积极且持续的凶杀案调查，目前尚未逮捕任何人。
• 目击者证词： 一位邻居表示周一晚上听到“三声巨响”，并认为有人正在试图破门而入。
• 家庭情况： 卢埃罗育有三个孩子，他们的母亲为Ines。当地居民Eurydice Hirsey表示，卢埃罗一家正经历着巨大的悲痛和恐惧。

卢埃罗的学术成就：

• 教育背景： 卢埃罗于2000年毕业于里斯本高等技术学院物理学专业，并在2005年于伦敦帝国学院获得物理学博士学位。
• 研究领域： 卢埃罗是一位理论物理学家和核聚变科学家，以其在磁化等离子体动力学领域的研究而闻名，该领域研究带电粒子运动受外部磁场的影响状态。
• 研究内容： 他的研究涉及核聚变真空室中心以及宇宙边缘的复杂问题，并致力于利用清洁的“核聚变能源”来应对气候变化。
• 学术评价： 麻省理工学院前主任Dennis Whyte称赞卢埃罗是一位杰出的科学家和人，一位出色的导师、朋友、教师、同事和领导者。物理系主任Deepto Chakrabarty也表示，卢埃罗是等离子体物理学的倡导者，他最近的研究代表了一个特别令人兴奋的新科学方向。

麻省理工学院的回应：

• 麻省理工学院对卢埃罗的家人、学生、同事以及所有为之悲伤的人表示深切的同情。
• 学校正在为了解和支持认识卢埃罗的人提供帮助和支持。
• 学生们在周二下午前往卢埃罗的住所表达哀思。

更正说明：

文章最初对卢埃罗研究的等离子体类型存在错误，已进行更正。

总结：AI 辅助编程带来的认知负荷与疲劳 (Summary: Cognitive Load and Fatigue from AI-Assisted Coding)

这篇文章探讨了作者在利用 AI 工具（Claude Code 和 Cursor）进行 Vibe 编程时遇到的新现象：认知疲劳。作者是一位有 40 年编程经验的开发者，他发现虽然 AI 极大地提高了代码生成和功能构建的速度，但也带来了意想不到的负面影响。

主要观点：

• AI 加速编程带来的挑战： 传统的编程过程，代码输出速度与任务复杂性相匹配，留给开发者足够的时间思考和处理。而 AI 辅助编程的速度远超人类处理能力，导致开发者难以跟上 AI 的节奏，产生认知超载，最终导致疲劳。
• 认知负荷与机器时间： 作者将这种体验比作在机器的节奏下工作，感觉自己失去了控制权。AI 以极快的速度生成代码、修复 bug，开发者需要不断审查和调整，大脑无法充分消化这些信息，类似于在超速状态下进行马拉松。
• 多巴胺循环加速： 编程的乐趣源于解决问题的多巴胺循环。AI 加速了这一循环，导致开发者被过多的多巴胺和压力荷尔蒙冲击，最终感到疲惫而非满足。
• 上下文切换的频率： AI 频繁地在不同的模块和函数之间切换，导致开发者需要频繁地进行上下文切换，这会消耗大量的脑力资源，加剧疲劳感。
• 角色转变： 开发者逐渐从代码编写者转变为 AI 的管理者和审查者，这增加了工作压力，需要同时处理代码和管理 AI 的输出，如同同时管理多个繁忙的交通路口。
• 应对策略： 作者提出了以下应对策略：
  • 有意识地控制节奏： 在 AI 辅助编程时，需要有意识地放慢速度，避免过度加速。
  • AI 意识的回顾： 定期进行回顾，了解 AI 带来的影响，并调整工作方式。
  • 关注心理健康： 需要关注 AI 辅助编程对开发者心理健康带来的新挑战。
  • 信任 AI： 减少对 AI 的微观管理，给予其更大的自主权。
• 未来展望： 作者认为，未来的编程可能需要在速度之外，也需要有意识地放慢节奏，找到一种新的平衡，适应 AI 带来的变化。

总结： AI 极大地提升了编程效率，但也带来了认知负荷和疲劳等新的挑战。 开发者需要认识到这些挑战，并采取相应的策略来应对，以适应 AI 时代下编程的新模式。

特斯拉Robotaxi事故率居高不下，或将取消安全监管员 (Tesla Robotaxi Crash Rate Remains High, Considering Removal of Safety Supervisors)

根据美国国家公路交通安全管理局（NHTSA）的最新报告，特斯拉在奥斯汀的Robotaxi车队又发生了一起事故。这使得该项目的事故率相较于人类驾驶员而言，仍然居高不下，而特斯拉正计划取消车辆中的安全监管员。

事故报告与信息缺失

特斯拉有义务向NHTSA报告其自动驾驶系统（ADS）相关的事故。自测试车队在德克萨斯州奥斯汀试运营以来，类似报告一直在陆续出现。截至2025年9月，该车队已发生7起事故。最新的报告显示，2025年10月又发生了第8起事故，地点同样在奥斯汀。

报告指出，事故中无人受伤，但由于特斯拉习惯性地对事故报告中的“叙述”部分进行大量删减，以隐藏专有信息，事故的具体情况细节被隐藏。特斯拉过度删减信息，甚至在部分问题上直接表明“参见叙述”，而叙述本身也被删减。

事故情况汇总

以下是特斯拉Robotaxi事故的汇总列表：

事故发生时，Robotaxi车队是“直线行驶”状态，与“其他”对象发生碰撞。

事故率分析

据了解，截至上月，特斯拉Robotaxi车队行驶了约25万英里，共发生7起事故，这意味着Robotaxi平均每行驶4万英里就发生一次事故。而美国普通驾驶员的事故率约为每50万英里一次。因此，特斯拉的“自动驾驶”车辆的事故率是人类驾驶员的10倍。

尽管Robotaxi车队规模在11月有所扩大，达到了29辆，但Robotaxi的行驶里程并未增加，利用率表明特斯拉一次只运行少数车辆。

安全监管员的悖论

更关键的是，这些事故发生在车辆配备了安全监管员的情况下，他们坐在驾驶座或乘客座，并随时准备接管车辆。这些监管员接受过培训，能够介入并控制车辆，以避免软件错误造成的事故。 然而，即使有安全监管员在，Robotaxi的事故率依然很高。因此，如果取消安全监管员，事故率可能会更高。

值得注意的是，埃隆·马斯克最近宣布，特斯拉计划在未来三周内[从奥斯汀的Robotaxi车队中移除安全监管员](https

https://fvwm95.sourceforge.net/

人工智能冲击全球技术行业初级岗位：印度学生面临就业困境

核心要点： 人工智能 (AI) 的快速发展正在全球范围内冲击技术行业的初级岗位，导致大量工程专业的毕业生面临就业困境。印度、中国、迪拜和肯尼亚等地的大学学生正经历着一场“就业浩劫”。

具体情况：

• 印度学生焦虑： 在印度，如 Jabalpur 的 Indian Institute of Information Technology, Design and Manufacturing 这样的顶尖工程学院，学生们原本期望通过计算机科学专业，编写代码，最终进入硅谷。然而，如今他们面临着严峻的现实：AI 正在取代他们所依赖的初级岗位。该校 400 名学生中，仅有不到 25% 获得了工作机会。学生们普遍感到焦虑，一些人考虑攻读更高学位，但毕业后再次求职的竞争力也会下降。
• 全球招聘趋势逆转： SignalFire 的报告显示，过去三年全球大型科技公司招聘的应届毕业生数量下降了超过 50%。即使 2024 年有所反弹，新员工中只有 7% 是应届毕业生。甚至有 37% 的管理者表示他们更愿意使用 AI 而不是雇佣 Z 世代员工。
• 印度 IT 服务业受影响： 印度 IT 服务公司由于自动化和 AI 的应用，已经减少了 20%–25% 的初级岗位。
• 欧洲市场也面临挑战： LinkedIn、Indeed 和 Eures 等招聘平台记录显示，2024 年在欧洲主要国家，初级技术职位减少了 35%。
• 技能需求发生变化： 过去，技术人才供不应求，公司为了争夺人才不惜提高薪资。如今，AI 崛起后，这种局面已不复存在。雇主不再仅仅需要编写代码的工程师，而是需要能够管理项目、与客户沟通、甚至进行销售的复合型人才。
• 课程与市场脱节： 肯尼亚 Technical University of Kenya 的学生 Rita Sande Lukale 发现，原本期望进入系统架构领域的初级岗位已经消失。AI 正在取代数据记录、系统诊断和代码编写等工作，毕业生需要具备更高的技能，例如理解算法和运用工程判断来解决复杂问题。
• 产出压力增大： AI 招聘公司 GoodSpace AI 的产品部门负责人 Liam Fallon 表示，公司要求毕业生利用 AI 提高工作产出 70%。
• 大学滞后： 专家认为，大学的教学实践难以快速适应 AI 驱动的行业需求。
• 就业模式不可持续： IT 招聘公司 Silicon Valley Associates Recruitment 的 Vahid Haghzare 认为，传统的学生学习计算机科学三年或五年后再找工作的模式已经不可持续。

总结：

AI 的快速发展正在改变技术行业的就业格局，对全球范围内的工程专业毕业生，尤其是在印度等新兴经济体，造成了严峻的挑战。学生们需要重新评估职业规划，积极学习新技能，适应快速变化的行业需求，否则将面临难以找到工作的困境。大学也需要加快改革，调整课程设置，以更好地满足行业对人才的需求。

总结：对 Mozilla 新战略的担忧及 Waterfox 的坚持

本文作者，一位 Waterfox 浏览器开发者，对 Mozilla 宣布以 AI 为核心的未来愿景表示担忧。他认为 Mozilla 正犯下根本性的错误，将不透明的 LLM（大型语言模型）置于浏览器核心位置，这与 Mozilla 一直以来所倡导的信任、透明度和用户自主权背道而驰。

主要观点：

• AI 的区分： 作者强调区分“AI”一词，认为 Bergamot 等透明、可审计的机器学习工具与 LLM 不同。LLM 像黑盒，无法审计和理解其运作方式，更无法保证数据安全和用户体验。
• 浏览器应有的职能： 浏览器应作为用户的代理，执行用户的指令。引入 LLM 相当于增加了一层“用户代理用户代理”，AI 成为新的代理，可能重塑用户浏览体验，甚至在用户不知情的情况下做出决策。
• 对 Mozilla 战略的质疑： 作者理解 Mozilla 面临的生存压力，但认为其战略自相矛盾。Mozilla 承诺 AI 可选，但 AI 深度集成到浏览器中，这本身就暗示了需要一个复杂的退出机制。
• Waterfox 的坚持： Waterfox 将继续专注于提供一个简单、高效、尊重用户的浏览器，不包含 LLM。作者强调 Waterfox 的正式治理结构和隐私政策，确保用户有明确的责任方和可追溯性。
• 对“不可避免”的挑战： 作者认为 AI 浏览器可能成为主流，但网络本质上是去中心化的，总会有替代方案。Waterfox 将继续坚持其核心原则，为那些重视独立性和透明度的用户提供选择。

Waterfox 的优势：

• UI 成熟，自定义功能完善。
• 注重性能和网络标准。
• 不包含 LLM。
• 拥有正式的治理结构和隐私政策，提供用户责任方和可追溯性。

作者总结认为，浏览器的核心职责是服务于用户，而不是替用户思考。Waterfox 将坚持这一原则。

中文翻译说明:

• 本文力求准确传达原文信息，并保持简洁明了。
• 使用了 Markdown 格式进行排版。
• 对一些专业术语进行了适当的翻译和解释，以方便中文读者理解。
• 保留了原文的结构和逻辑，使其易于阅读和理解。

苹果公司 App Store 规则持续不合规引发开发者担忧 (苹果公司 App Store 规则持续不合规引发开发者担忧)

摘要:

欧盟监管机构在六个月前裁定苹果公司的 App Store 规则违反《数字市场法案》(DMA) 后，开发者们指出苹果公司仍然在采取不合规行为，似乎认为合规是可选项。代表开发者和消费者权益的“应用公平联盟” (Coalition for App Fairness) 向欧盟委员会主席乌尔苏拉·冯德莱恩及高级专员递交了一封公开信，指责苹果公司持续不遵守 DMA，其修订后的 App Store 条款仍然强制收取法律禁止的费用。

核心问题:

DMA 要求被认定为“守门人”的企业允许开发者在 App Store 之外提供和进行交易，而不收取费用。然而，苹果公司据称试图对这些交易收取高达 20% 的佣金。联盟认为，这是一种公然违反法律的行为，可能会摧毁欧盟委员会多年来的努力。

苹果公司的回应与担忧:

苹果公司表示将在 2026 年 1 月推出新的 App Store 条款，但尚未就这些变更的具体内容或是否符合 DMA 提供明确说明。开发者对此表示怀疑，认为新的条款很可能继续强制执行违反法律的费用。这种不确定性已经对行业造成损害，冻结了投资和创新，使苹果公司能够利用其“守门人”地位，控制整个行业。

跨大西洋对比:

联盟指出，欧盟与美国的监管环境存在显著差异。在美国，在与 Epic Games 的诉讼后，开发者现在可以自由地与客户沟通定价，并提供苹果生态系统之外的支付选项，而无需支付佣金。这引发了一个关键问题：为什么欧盟的开发者和消费者应该得到比美国同行更差的待遇，尤其是在欧盟率先通过旨在修复数字市场的开创性法律的情况下？

结论与呼吁:

联盟呼吁欧盟委员会切实执行 DMA，以加强欧洲的数字竞争力并吸引全球投资。他们表示，如果执行不力，DMA 将沦为一场昂贵的纸面运动。开发者们敦促欧盟委员会维护 DMA 的权威性，确保苹果公司最终遵守法律的原文，而不是自行修改。

相关链接:

• 布鲁塞尔关注 AWS、Azure 云服务可能被认定为守门人
• 苹果、谷歌告诉欧洲，《数字市场法案》对他们或消费者都不起作用
• 谷歌调整 Play Store 费用以避免欧洲监管机构的关注
• 苹果试图推翻 5 亿欧元欧盟罚款