每日AI乱炖 · 2026-10-12

这里是由Robin为你带来的咸话咸说之每日AI乱炖

Amazon 仓库里的机器人已经超过 100 万台，昼夜不停地工作。GitHub 一次基础设施事件中断了 Actions、Pull Requests 和 Issues，状态页承认这几项服务的性能在事件期间下降，讨论把活动量的上升联系到 AI 编程智能体。QGIS 的 Enhancement Proposal #387 仍是提议，想禁止 AI 辅助的贡献进入代码库，并要求合入的代码写明人类作者。

超过一百万台机器人，已经在仓库里昼夜转

世界上没有任何组织运营的机器人比 Amazon 更多。公司已经有超过 100 万台机器人在仓库里昼夜不停地工作，每天送出数以千万计的当日达和次日达包裹。超过 100 万台是已经在转的数字，不是还写在计划里的目标。未来几年，Amazon 准备把这支队伍再明显做大，做法是新建工厂，让工厂成批生产出能力越来越强的机器人员工。来源：Ars Technica

机器人部署到这个规模，Amazon 仍然是全球第二大企业雇主。它的 2025 年年报写着，全职和兼职的人类员工加在一起超过 150 万。高管的说法是，机器人队伍变大以后，人类员工的负担减轻了。减轻来自任务的转移：履约中心里最艰苦的那些任务由机器人接手，而那些任务，正是体力疲劳和受伤风险最高的一类。劳工倡导组织和独立研究者指出，已有证据表明，由 AI 驱动的仓库自动化，对必须和机器人一起工作的人来说，并不全是好处。

差别在于机器离人有多近，以及谁来定干活的快慢。乔治梅森大学商学教授 Brian Greenwood 告诉 Ars：「过去 100 年里，我们看到的大多数自动化，通常发生在远离工人的地方——你把那个高风险任务从工人手里拿走，而且是以一种身体上并不靠近工人的方式去做的。」他又说：「协作机器人的兴起真正改变了这个局面，原因有两个：一是它在身体上靠近工人，二是机器人有能力规定工作的节奏。」前一个讲距离，机器就在工人旁边；后一个讲节奏，干活的快慢可以由机器人来定。这和过去一百年把危险任务从人身边拿走、而且人机并不贴近的做法，正好相反。高管强调的是最苦的活被接走，研究者和劳工组织强调的是，留在机器人旁边的人并没有因此只得到好处。

状态页记下性能下降，讨论把量归到编程智能体

一次 GitHub 基础设施事件，中断了 Actions、Pull Requests 和 Issues 这三项服务。公司的状态页承认，事件期间这几项服务的性能出现了下降。这三项是开发者工作流的核心表面。Actions 提供 CI/CD 自动化，触发它的是发生在 Pull Requests 和 Issues 上的事件，而且这种触发是按整个平台的规模在跑。状态页写下的，是这三项服务在事件期间性能下降。来源：GitHub 状态页

围绕这次事件的讨论，把底层压力归因于平台活动量的一次急速上升。据这些讨论所称，Actions、PR 和 Issues 每天的数量，在大约八个月里从 5000 万爬到了 20 亿。另一种说法把每天的事件量写成：大约八个月内从大约 5000 万增长到大约 20 亿。第三种说法落在每天的操作次数上。评论的人把这个数量级的跳跃，联系到 AI 编程智能体的大量出现。这些智能体以程序化的方式工作，大规模生成提交、工作流和 issue，还会创建分支、提交、issue 和 pull request，速度远快于一个人类开发者自己会做的。

这次事件标出的是一个扩容上的拐点。拐点指的是：这个平台的架构当初并不是为了承受这类自动化负载而设计的，现在却要接住智能体推上来的量。评论者普遍把这次负载尖峰归因于 AI 编程智能体。有人把后果说得很直：每天的操作从 5000 万走到 20 亿，几乎会撑破任何建立在 AI 出现之前那些假设上的系统。也有人担心再往前一步的规模，每天会有数百个这样的自动化项目在跑。少数人指向一条减少依赖的路，用 Forgejo 这类自托管替代方案，降低对 GitHub 的依赖。讨论里的 5000 万和 20 亿带了大约、据称这样的余地，时间也是大约八个月。

QGIS 的 #387 还是提议：合进去的代码，得写明人是谁

QGIS 正提议禁止 AI 辅助的贡献进入自己的代码库。提案编号是 Enhancement Proposal #387，现在仍是提议，不是已经生效的禁令。它举出的理由是，低质量、由 LLM 生成的 pull request 越来越多，志愿维护者身上的负担越来越重。提案把分歧放在贡献者的责任上：人要为自己交出去的代码负责，而不是对 AI 工具一概敌视。它想给已经合入的代码立下两条明确标准。一条是人类作者身份必须写明，另一条是评审要有明确规矩。来源：QGIS Enhancement Proposal #387

QGIS 是一套免费、开源的地理信息系统，在 GPL 之下维护。使用者可以在 Windows、macOS 和 Linux 上查看、编辑和分析地理空间数据。它是桌面 GIS 里使用最广的平台之一。Hacker News 上这场讨论有 323 分、348 条评论，把 QGIS 和 Zig、NetBSD、GIMP、Gentoo、QEMU 放在一起。这些项目都在拒绝含有 LLM 生成代码的 pull request。用 AI 工具生成代码越来越容易，能用来甄别外部贡献的评审人力有限，两边没有一起变。维护者因此越来越不得不配给评审时间，办法是限制 AI 生成的 pull request，或者直接拒绝。

维护者说自己已经被 PR 淹没。这些 PR 看上去像样，内容却弱，账号很少回复评审意见，甚至从来都不回复。与此同时，工作从写代码转向核实代码实际上做了什么。评论的人大体同意，维护者正承受一份难以为继的评审负荷，负荷来自那些看似合理、其实薄弱的 LLM 生成 PR。一位 Plotly 维护者描述了具体损害，损害来自不做回应的机器人提交者。开发者还指出另一处特别不可靠：LLM 碰到地理空间数学时容易出错，尽管开口时很有把握。难的已经不是把代码写出来，而是让自己始终对齐代码实际上在做什么。这笔核实的成本，现在同时主导着个人开发和评审者两头的工作。在项目本身难以长期维持的时候，能够被证明的人类作者身份，再加上提交之后还跟到底，可能会变成贡献的底线。

超过 100 万台机器人已经在仓库里昼夜工作，协作机器人靠近工人，也有能力规定干活的节奏；未来几年的新工厂，还要继续生产更强的机器人员工。GitHub 状态页承认的是 Actions、Pull Requests 和 Issues 在事件期间性能下降，讨论则把大约八个月里从大约 5000 万到大约 20 亿的跳跃，归到程序化生成分支、提交和 pull request 的 AI 编程智能体。QGIS 的 #387 还停在提议。维护者把时间从写代码挪去核对那些看上去像样、内容却弱的 pull request，提案要的是合入时写明人类作者。三处的产出不同，还留在人这边的是同一类事：协作机器人有能力规定工作节奏，平台要接住当初不是为这类自动化负载设计的量，维护者则要核对代码到底做了什么。

🎧 本期已同步制作为播客节目，点击收听《每日AI乱炖 · 2026-10-12》。