每日AI乱炖 · 2026-10-12

Amazon 的仓库机器人已经超过 100 万台，人类员工接下来会怎样，是这则新闻要回答的问题。世界上没有任何组织运营的机器人比 Amazon 更多。公司已经有超过 100 万台机器人，在仓库里昼夜不停地工作。这些机器人每天要送出数以千万计的当日达和次日达包裹。未来几年，Amazon 准备把这支机器人队伍再明显做大，做法是新建工厂，让工厂成批生产出能力越来越强的机器人员工。尽管机器人已经部署到这个规模，Amazon 仍然是全球第二大企业雇主。它的 2025 年年报写着，全职和兼职的人类员工加在一起超过 150 万。Amazon 高管的说法是，机器人队伍变大以后，人类员工的负担减轻了。减轻来自任务的转移：履约中心里最艰苦的那些任务由机器人接手，而那些任务，正是体力疲劳和受伤风险最高的一类。劳工倡导组织和独立研究者指出，已有证据表明，由 AI 驱动的仓库自动化，对必须和机器人一起工作的人来说，并不全是好处。乔治梅森大学商学教授 Brian Greenwood 告诉 Ars：「过去 100 年里，我们看到的大多数自动化，通常发生在远离工人的地方——你把那个高风险任务从工人手里拿走，而且是以一种身体上并不靠近工人的方式去做的。」他又说：「协作机器人的兴起真正改变了这个局面，原因有两个：一是它在身体上靠近工人，二是机器人有能力规定工作的节奏。」前一个原因讲距离，机器就在工人旁边；后一个原因讲节奏，干活的快慢可以由机器人来定。这和过去一百年把危险任务从人身边拿走、而且人机并不贴近的做法，正好相反。仓库里超过 100 万台机器人仍在昼夜运转，新工厂还准备把能力更强的机器人员工继续送进这支队伍，2025 年年报里超过 150 万的全职和兼职员工也仍在同一家公司。高管强调的是最苦的活被接走，研究者和劳工组织强调的是，留在机器人旁边的人并没有因此只得到好处。也就是说，超过 100 万台是已经在仓库里昼夜工作的机器人，不是还写在计划里的数字；它们每天要撑起数以千万计的当日达和次日达。未来几年的新工厂，要继续生产更强的机器人员工。人的数字来自 2025 年年报，全职和兼职超过 150 万，同时 Amazon 仍是全球第二大企业雇主。高管说负担减轻，减的是履约中心里最艰苦、最容易疲劳和受伤的任务。Greenwood 对 Ars 补充的是，协作机器人已经靠近工人，并且有能力规定工作节奏。

一次 GitHub 基础设施事件，中断了 Actions、Pull Requests 和 Issues 这三项服务。公司的状态页承认，事件期间这几项服务的性能出现了下降。围绕这次事件的讨论，把底层压力归因于平台活动量的一次急速上升。据这些讨论所称，Actions、PR 和 Issues 每天的数量，在大约八个月里从 5000 万爬到了 20 亿。评论的人把这个数量级的跳跃，联系到 AI 编程智能体的大量出现。这些智能体以程序化的方式工作，大规模生成提交、工作流和 issue。这次事件标出的是一个扩容上的拐点。拐点指的是：这个平台的架构当初并不是为了承受这类自动化负载而设计的，现在却要接住智能体推上来的量。GitHub Actions、Pull Requests 和 Issues，是 GitHub 平台上开发者工作流的核心表面。Actions 提供 CI/CD 自动化，触发它的是发生在 Pull Requests 和 Issues 上的事件，而且这种触发是按整个平台的规模在跑。根据围绕这次事件的讨论，这些系统每天的事件量，在大约八个月内从大约 5000 万增长到大约 20 亿。同一次跳跃被广泛归因于自主 AI 编程智能体的迅速增多。这些智能体做的不只有提交、工作流和 issue，还会以程序化方式创建分支、提交、issue 和 pull request，速度远快于一个人类开发者自己会做的。评论者普遍把这次负载尖峰归因于 AI 编程智能体。有人把后果说得很直：每天的操作从 5000 万走到 20 亿，几乎会撑破任何建立在 AI 出现之前那些假设上的系统。也有人担心的是再往前一步的规模，每天会有数百个这样的自动化项目在跑。少数人指向一条减少依赖的路：用 Forgejo 这类自托管替代方案，降低对 GitHub 的依赖。讨论里的 5000 万和 20 亿带了大约、据称这样的余地，时间也是大约八个月；三种说法分别落在每天的 Actions、PR 和 Issues 数量、每天的事件量，以及每天的操作次数上。状态页写下的，则是这三项服务在事件期间性能下降。也就是说，状态页对得上的是 Actions、Pull Requests 和 Issues 在事件期间性能下降。大约八个月内从大约 5000 万到大约 20 亿，是讨论里的涨幅，并被归到 AI 编程智能体程序化产生的分支、提交、工作流、issue 和 pull request。有人认为这几乎会撑破 AI 出现之前那些假设下的系统，也有人担心每天数百个自动化项目，少数人则提到用 Forgejo 自托管来降低对 GitHub 的依赖。

QGIS 正提议禁止 AI 辅助的贡献进入自己的代码库。提案编号是 Enhancement Proposal #387，现在仍是提议，不是已经生效的禁令。它举出的理由是，低质量、由 LLM 生成的 pull request 越来越多，志愿维护者身上的负担越来越重。提案把分歧放在贡献者的责任上：人要为自己交出去的代码负责，而不是对 AI 工具一概敌视。它想给已经合入的代码立下两条明确标准。一条是人类作者身份必须写明，另一条是评审要有明确规矩。Hacker News 上这场讨论有 323 分、348 条评论。讨论把这一步放进一种更广的做法里：好几个主要开源项目正在收紧门槛，挡住机器人式的提交。维护者说自己已经被 PR 淹没。这些 PR 有两个一起出现的特征：看上去像样，内容却弱；账号很少回复评审意见，甚至从来都不回复。与此同时，工作本身也在转移，从写代码转向核实代码实际上做了什么。QGIS 是一套免费、开源的地理信息系统。使用者可以在 Windows、macOS 和 Linux 上查看、编辑和分析地理空间数据。它是桌面 GIS 里使用最广的平台之一，并且在 GPL 之下维护。拒绝 AI 辅助贡献，在开源治理里已经有一批先例。Zig、NetBSD、GIMP、Gentoo 和 QEMU 都已经转向同一边：含有 LLM 生成代码的 pull request，他们不再收。把 QGIS 放在这些名字旁边，这项决定就不像一条孤立的政策。它更像是在回应一道正在变宽的缺口。缺口的一边，是用 AI 工具生成代码越来越容易；另一边，是能用来甄别外部贡献的评审人力有限，两边没有一起变。维护者因此越来越不得不配给评审时间。配给的办法也很具体，就是限制 AI 生成的 pull request，或者直接拒绝。QGIS 的提案被读成一个信号：在项目本身难以长期维持的时候，能够被证明的人类作者身份，再加上提交之后还跟到底，可能会变成贡献的底线。这里用的是可能会，不是已经变成。评论的人大体同意，维护者正承受一份难以为继的评审负荷。负荷的来源，是那些看似合理、其实薄弱的 LLM 生成 PR。一位 Plotly 维护者描述了具体损害，损害来自不做回应的机器人提交者。开发者还指出另一处特别不可靠：LLM 碰到地理空间数学时容易出错，尽管开口时很有把握。难的已经不是把代码写出来，而是让自己始终对齐代码实际上在做什么。这笔核实的成本，现在同时主导着两头的工作，一头是个人开发，一头是评审者。也就是说，#387 还停在提议：禁止 AI 辅助贡献进代码库，是因为低质量的 LLM pull request 正在加重志愿维护者的负担；它并不主张敌视一切 AI 工具，而是要求合入代码时写明人类作者，并配上明确的评审。Hacker News 的 323 分、348 条评论，把 QGIS 和 Zig、NetBSD、GIMP、Gentoo、QEMU 放在一起，这些项目都在拒绝含 LLM 生成代码的 pull request。QGIS 仍是那套免费开源、以 GPL 维护的桌面 GIS，Windows、macOS、Linux 上都能查看、编辑和分析地理空间数据，也是用得最广的之一。评审时间不够，维护者就只能限制或拒绝 AI 生成的 pull request；项目难以长期维持时，证明得了的人类作者和事后跟进，可能会变成门槛。评论这边大体同意负荷难以为继，PR 像样但弱，提交者很少甚至从不回复。Plotly 的维护者讲了不回应的机器人提交者造成的具体损害。开发者则指出，LLM 在地理空间数学上特别不可靠，尽管说得很有把握。个人开发和评审者现在把主要时间花在核对代码到底做了什么。