← #806

8 月 17 日的故障，以及接下来要做的工作

查看原文 HN 讨论

文章摘要

这篇文章由 GitHub 首席技术官 Vlad Fedorov（Vladimir Fedorov，曾在 Meta 任负责隐私、广告和平台的工程 SVP，管理超过 2000 人的团队，此前在微软工作、Caltech 计算机科学本硕，创办过数据治理创业公司 UserClouds）于 2026 年 8 月 20 日署名发布，配套的详细技术根因分析（RCA）发布在 githubstatus.com 上。

时间线与影响范围

按 GitHub 状态页的正式 RCA：2026 年 8 月 17 日 13:28–21:15 UTC，共 7 小时 47 分钟，github.com 在 Issues、Pull Requests、各类 API、Actions 和 Copilot 上出现错误率与延迟升高。峰值时 Web/API 错误率约 20%，归档下载与 raw 内容下载的错误率高达约 50%。受影响的还包括 SAML/OIDC 认证、SCIM、Team Sync，以及启用了数据驻留（Data Residency）的 GHEC 中依赖 github.com 上托管的公共 workflow step 定义的 Actions 工作流。

分阶段恢复情况是：随着 Central US（美国中部）数据中心恢复，大部分服务在 16:36 UTC 前恢复；Actions 降级持续到约 18:03 UTC；Copilot Token Service 到 21:02 UTC 才完全恢复。恢复期间团队把部分失败流量从 Central US 挪到了 Northern Virginia（北弗吉尼亚）承接，直到 Central US 的网络故障被排查并解决。

这是 GitHub 8 月的第二起重大事故。前一起是 8 月 6 日 15:05 UTC 至 8 月 7 日 00:14 UTC 的 Actions 故障：workflow 运行失败或长时间排队，GitHub 托管的 runner 和自托管 runner 都受影响，峰值时 71% 的 workflow 运行遭遇基础设施故障，剩余 workflow 中 75% 被延迟超过 5 分钟。

根本原因

8 月 17 日的直接原因是 Central US 负载均衡器的网络饱和，起因是流量创下新峰值。 更精确的链路是：一个 Istio sidecar pod 触到并发上限，却因为一条错误配置的策略未能正确自动扩容——那条策略只监控宿主服务（host service）的上限，没有监控 sidecar 的上限。一处失败级联到更多处，最终四个 HAProxy 节点耗尽了各自的流（flow）上限，导致网关认证路径降级，进而引发大范围的认证延迟与失败。过于乐观的重试逻辑（optimistic retry logic）加剧了问题，把内部负载均衡器压垮。转折点很戏剧化：同时暂停这几个节点上的 HAProxy，立刻带来了广泛的恢复。

Northern Virginia 侧的重试风暴通过两步扑灭：一是用一个 PR 临时降低网关的重试逻辑；二是在负载均衡器上以 403 直接拦掉进来的 Copilot Token Service token 请求，然后按站点逐步把流量爬回去，让调用方能够成功。

Copilot 的残留故障来自客户端行为的放大。 对某个内部端点的响应延迟触发了 VS Code 中一个潜伏的重试 bug，把流量放大了约 10 倍；一次失败的 token 操作可以产生大量额外请求并进入重试循环。数字非常直观：Copilot Token Service 的流量从正常的 7,000–9,000 RPS 飙到 70,000–100,000 RPS。降低网关认证重试、并拦掉会触发重试的响应之后，该服务才稳定下来并完成恢复。另有一个拖慢恢复的复杂因素：codeload 端点上同时存在若干抓取（scraping）攻击。

8 月 6 日那起的根因则是：一次对内部 Actions 服务（负责处理事件、生成 Actions 作业）的例行部署暴露出既有的容量与并发弱点——部署过程中 pod 被替换时，剩余容量被打满，服务崩溃并跨多个集群和下游服务级联。17:00 通过扩容、限流 webhook 触发的工作、并提高积压事件的处理能力恢复。第二阶段的影响是作业分配系统积压后，一个潜伏 bug 让 runner 被分配到已失效的作业并卡在反复重试上，无法领取有效作业。此外一项缓解措施意外影响了部分 Actions Runner Controller（ARC） runner，导致它们离线直到人工恢复（该变更随后被回滚，并将在后续 Runner 与 ARC 版本中加入自动恢复）。有些期间创建的作业既不能重试也不能取消，GitHub 在社区 discussion 里给出了 CLI 和 UI 的处理方案；部分 push 和 PR 事件在故障期间未被处理且无法自动重放，用户需要重新推一个 commit 或手动重跑 workflow。

Fedorov 在博客里给出了一个重要判断：两起故障都不是由代码或配置变更引起的，本质上都是容量失败——我们没能在需求超过容量之前把关键组件扩上去。 他给出的增长数据是自 4 月以来，月度 commit 数从 14 亿涨到 29 亿；「这个增长解释了系统上的压力，但它不为这些故障开脱」。

已做的和接下来要做的

作为年初可靠性承诺的一部分，GitHub 围绕三条优先级推进：加容量、提效率、拆掉架构瓶颈。已完成的部分包括：新增超过 300 万个 CPU 核心、120 PB 高速存储，以及大量网络容量；在现有数据中心里「装满了可用电力所允许的全部硬件」，同时加速向 Azure 迁移。今天 Azure 承载约 58% 的 GitHub 平台负载和一半的 Git 操作，而 5 月时平台负载占比只有 12%。下一个里程碑是一套让读容量随读者数量线性扩展、从而实现无限读操作的架构，将从最大的 monorepo 开始逐步推出。

Fedorov 也承认非容量层面的问题：「随着变更的节奏与复杂度上升，我们现有的运维实践没能跟上」，团队与资源已被重新投向可用性，并加强了测试、更安全的发布、更好的可观测性和更有效的告警；同时正在隔离关键系统、拆除它们之间的共享依赖。

两起故障直接催生了两项即时改动：第一，在服务间调用上统一施加一致的重试上限、重试预算（retry budget）和可变超时，以防止重试风暴和级联负载；第二，重新审视优先级较低的 CPU 与内存告警，找出可能在突发流量峰值中失效的组件。 状态页 RCA 列出的后续行动更具体：修正自动扩容策略以纳入服务网格 sidecar 的并发与容量；审计受影响服务上的 Istio 请求、并发与扩容限制；审查各网关与客户端的重试上限与退避行为；修掉那个放大 Copilot token 流量的 VS Code 重试行为；改进负载均衡器容量监控与跨区域故障转移保障。

HN 评论精华

这条帖子拿到 636 分、约 717 条评论，是本期规模最大的讨论。讨论大幅偏离了复盘本身：真正围绕 RCA 技术细节的讨论只占一小部分，主线是三条——「月 commit 从 14 亿到 29 亿」这个数字意味着什么（以及它是不是 AI 垃圾）、该不该逃离 GitHub / 自托管、以及由此彻底跑偏成一场关于「AI 到底有没有让人更高产」和「数据中心环境成本」的百层大辩论。付费客户的补偿问题、以及「这篇公告里没有一句『对不起』」也各自引出了一串。

• 增长数字与 AI slop。 blakesterz 引出全帖最热的一串：「自 4 月以来月度 commit 从 14 亿涨到 29 亿——太惊人的增速了。」brookst 说自己从每月几十个 commit 变成了几千个，「他们必须在按未来一两年超过每月 1000 亿来做规划」。toephu2 的「考虑到这主要来自 AI slop，就不那么惊人了」引出漫长争吵：seizethecheese 主张「代码是不是 slop在这里无关紧要，服务能承受这种规模的增长本身就令人印象深刻」，Aachen 反问「我们都知道是自动生成的，那怎么算惊人？那里的人并没有变多，2 倍增长甚至可能意味着真人变少了」，airstrike 给出最干净的调解：「这是令人印象深刻的量，不是令人印象深刻的质。」wegwerper 讲了本串最扎心的一条：他们付 GitHub Enterprise 的钱，「因为 GH 不肯把服务等级分层，把 slop 领主和真正的付费客户分开，我们得到的是垃圾级性能」——fragmede 回了个实用信息：「他们有的，找你的客户代表拿另一个域名去打。」
  • tremon 提了本帖技术含量最高的一个问题：为什么 GitHub 报的是 commit 数而不是 push 数？ Brian_K_White 的立场是「commit 不贵，push 才贵」；orf 反驳说 commit 才是复杂度和成本的核心单位（存储、secret 扫描、要能被 commit message 和 comment 引用地索引、单独存取和服务），「而且它就是 git 的核心单位」；jeremyjh 的反驳最细致——GitHub 不会为每个 commit 单独跑 Actions，而是按 push 跑，索引和扫描也是对推送范围的 log 做一次批量扫描，不需要逐个循环；不过他也承认「没有理由认为 commit 对 push 的比例发生了实质变化，所以如果这一直是他们衡量增长的代理指标，那对这个受众来说是个合理的沟通方式」。charrondev 与 tremon 就 secret 扫描是否必须逐 commit 展开细辩：charrondev 认为必须（一个 commit 引入、下一个删除，秘密依然可恢复），tremon 认为最高效的做法是扫描本次推送的所有 blob 对象，不必知道对象在树里的位置；jeremyjh 补充 secret 扫描默认只对公共仓库开启，对组织是 Teams/Enterprise 的付费功能。TorKlingberg 给了一个实际答案：Actions 里是可以配置成逐 commit 跑 CI 的，很多项目这么做以避免「一个 commit 弄坏构建、同一 push 里的下一个 commit 修好」的情况，因为破损的历史让 bisect 变难。johndough 提供了最好的一句注脚：「更大的数字听起来更厉害。『我们十亿美元的基础设施在每秒 50 个 PR 的洪流下崩溃了』听起来就太丢人了。」
  • leptons 讲了个真实到荒诞的案例：他们为某家大型第三方托管商开发时，那套开发系统要求每保存一个文件就 commit + push 一次；他只好写了个构建系统，把整个仓库复制到临时目录，监听主仓库的文件变化并复制到临时目录、在临时目录 commit 并推到 GitHub 的一个中间仓库，再由 action 触发第三方系统更新，「不是我最喜欢的开发方式，但除了 GitHub 挂掉之外没造成什么实际问题」。ninkendo 的回应引用了巴贝奇：「我实在无法正确领会是何种思想上的混乱才能激发出这样一个解决方案。」

• Bun 作为 AI 时代 GitHub 负载的样本。 shdtabasum 半开玩笑地贴出 oven-sh/bun，说「像 Bun 这种自动挡跑的项目多了，这种事就会发生」，随后这条支线自成一片天地：3.3k 个开放 issue、5k 个 PR（mananaysiempre 指出 Nixpkgs 有 11k 个开放 PR，但那更像一堆基本独立的构建脚本集合），vermilingua 注意到「最近的 commit 里超过 50% 来自 robobun」。amoshi 完整还原了一条流水线：人类账号报的 issue 但正文由 AI 写，AI（robobun）回复并创建 PR，AI（coderabbit、claude、github actions）审这个 PR，AI（robobun）应用修复，几轮 AI 往返之后一个人类点了合并——「不撒谎，这有种美感」。bigiain 的回应是本帖最冷的笑话：「某人在给 Linux 发行版做性能分析时，好奇为什么 ssh 连接比预期慢了几百毫秒，然后发现那个 PR 引入了 RCE 后门，一举拿下整个项目。」pluc 说得更直白：「XZ 事件已经告诉我们供应链要怎么防，结果我们转头实现了一套全球标准的『自然语言到动作』，护栏留着以后再说。疯了。」inigyou 做了本帖唯一一次逐 commit 的实证审查：他随机点开 robobun 最近的两个非平凡 commit，第一个的代码改动「看起来什么都不做」，而 commit message 描述了一场关于 C++ 侧垃圾回收的极深调查（某个对象在测试要求它被回收时仍然存活），「难道不该有更好的办法确保对象被回收，比如把变量设成 null？」；第二个是「确保有人冻结或封闭 fs 模块的导出表时它仍然工作」——他去查了关联 issue，发现 issue 也是 robobun 自己报的。charleslmunger 给了一个替 AI 说话的专业视角：第一个问题在处理 GC 生命周期的测试里其实相当常见，很少有解释器/JIT 愿意生成额外指令去清空栈槽或预先破坏寄存器，提前把变量置 null 常被死存储消除掉，「我在 Java 里也写过额外的嵌套作用域或包装器来处理这个」；不过他同意需要注释。CrimsonRain 是本帖最坚定的 Bun 辩护者，列出重写在创纪录时间内基本完成、新增大量特性与 bug 修复、被数百万人通过 Claude Code 使用等成果，称否认 Oven 的成就「除了恐惧和 FUD 什么都不是」；SaucyWrong 提醒他「在 1.4.0 脱离 canary 超过 24 小时之前，先别说『它对 Bun 有效』」。

• RCA 与「sorry」之争。 nycpig 说：「核心工作流全线宕机将近 8 小时，而这篇文章里没有一次出现『sorry』或『apologize』。『如果你那天想发布软件，我们让你失望了』是典型的公司式非道歉。我不干了。」bibimsz 是反方：「这正是我喜欢的地方，它是事实和行动导向的。一句『抱歉』能买到什么『我们让你失望了』买不到的东西？」john_strinlai 补刀：「我很确定如果真出现了『sorry』，也会有人评论说这是『空洞的道歉』。」iSloth 抱怨「这一定是本年度最含糊的故障总结之一」，dcrazy 两次出来指路：根因分析是单独的、并且从博客里链接出去的，它非常具体和技术。dwaltrip 从另一个角度嫌它含糊：「它有那种经过大量编辑的 Claude 味文字的含糊感和别扭的断句。」CrimsonCape 想看的是工程师的第一人称版本：「我到办公室时正一片慌乱，我立刻打电话给 US-2West 的 IT，他们报告机器级联故障……」——「文章里完全缺失。」
  • kjuulh 提出了最实质的架构质疑：「读这份复盘让我震惊，这看起来不像一个服务高吞吐超过十年的服务，几乎像刚起步。解决方案似乎一直是容量、容量，而不是架构或数据层面的改变。」他特别盯住那句「我们的下一个里程碑是让读容量随读者数量线性扩展、实现无限读操作」——「到了这个规模怎么会还没有读副本/读缓存？」xienze 的回答是：「因为相较于 AI 带来的这股绝对洪流，他们确实没在这个量级上运营过。」
  • 重试与惊群（thundering herd）是唯一被认真展开的技术支线。jdm2212 引用「那些服务的错误触发了客户端重试循环，在恢复期间反而增加了流量」，说「我参与过的最糟的故障总有某个版本的这一条」。pixl97 的「指数退避是你的朋友，用的人太少」引出 r3trohack3r 的「别忘了 jitter！」，而 Aachen 的追问（他一直加 jitter 但从没真正遇到过需要它的问题，维基百科上这条实践只有一句话且没有引用）催出了本帖最好的一批经验分享：r3trohack3r 描述了边缘 serverless 平台的下游数据库宕机后，请求路径上每个服务和客户端各有自己的重试策略，一个前门请求在微服务图里放大成几十次内部重试，客户端同时超时、等相同时间、再同时重试，「这是一场脉冲式的、被内部重试放大的、前门几十万请求的惊群」，最后只能把削载调到 100%、等后端恢复后再分级调回；allthetime 给了最好懂的例子（几千个 WebSocket 客户端连着一台便宜小服务器，服务器打个嗝，全部断开，服务器回来，全部同时重连）；dadadad100 指出这是以太网的基本属性（inigyou 补充说那是 1980 年代的以太网，有交换机或超过 100Mbps 就不是这个模型了，但 WiFi 仍在用）；Maxion 提到一个常被忽略的好处：即使规模上惊群还压不垮你，指数退避加 jitter 也能大幅减少日志噪音。kevincox 做了严谨的概念区分：惊群是大量客户端在同一时刻触发请求，而通过重试的请求放大是另一个问题，它造成的流量大但通常比惊群更平稳。to11mtm 问有没有反向代理自带按模式的抖动退避，llama052 和 antonvs 给了答案：Envoy 内建、Istio（基于 Envoy）有熔断和重试的多个旋钮，Istio 可以配置带 jitter 的指数退避，linkerd 提供重试预算和基于背压的削载——「防止重试风暴正是服务网格的功能之一」。Quekid5 提出实用主义反调：指数退避（哪怕带 jitter）常常过度设计，你总得设一个合理上限，「加了上限之后指数就有点没意义了」，固定延迟加大幅 jitter 对多数场景就够了。
• Azure 与「是不是微软的锅」。 ivraatiems 开的第一条评论是全帖最高票之一，用一句戏仿总结这篇文章：「我们承诺解决这些问题，只要不涉及购买 AI 计算机之外的东西、雇人、或使用非微软的产品。」他坚持「把 Azure 说成这个问题的解药，而它实际上是大部分问题的来源，是绝妙的双重话术」，并对「2.8 亿 commit 完全没事、2.9 亿就全站宕机」表示不可信。反驳很集中：dcrazy 说「你在扭曲自己的逻辑好让 Azure 当反派，而且听起来你缺少容量耗尽的经验——东西是慢慢坏，然后突然坏」；cyberax 给了机制解释并附上 AWS 的重试文档和经典的 EBS 故障公告；maccard 给了亲身案例：所有测量指标都显示有大量余量，但某天缓存被填满（磁盘和内存空间都够，只是某个值多年未调），缓存命中率从很高瞬间掉到很低，一切停摆；stackghost 的态度是「我和任何人一样讨厌 Microslop，但你得刻意误读这篇文章才能得出这个解读」。kjellsbells 给出组织政治的现实：「不存在一个微软旗下的重要产品不被要求跑在 Azure 上的宇宙」，semiquaver 反例是 LinkedIn 试了四年后放弃，并认为 Azure 对一家以自有硬件、以 colo 为主的公司（比如 GitHub 或 LinkedIn）是特别糟的迁移目标，需要的架构改动远大于从 AWS 迁过来。sandeepkd 给了一份颇具体的多因归责：（1）基础设施正在迁往 Azure，而所有云厂商此刻都在硬件上挣扎（LinkedIn 也一样）；（2）懂原有系统的核心团队成员或被裁或调离了 GitHub；（3）微软的老将被调来填坑，他们在尽力，但未知太多。Anon1096 从「我做过多个全球前十站点」的角度反驳他「多数系统能轻松吸收 2 倍增长」的说法：在 GitHub 这个量级不存在大量闲置容量待命，「而且『没人会拿关键组件冒险』也很错，原因很简单——在链条断掉之前你不知道哪一环最弱」。
  • mikert89 主张「这种增长率在大公司的分布式系统里很常见，一点也不奇特」，与 jeremyjh、tracerbulletx、jascha_eng、no-name-here、inigyou 打了十几层。jeremyjh 的论点最清楚：绝对数字远不如增长率的变化重要——GitHub 的 commit 数长期并没有每六个月翻倍，「如果在亚马逊流量持续每六个月翻倍，那反而好规划得多，因为它从很早就成了你做每件事的一部分」；把一个十年来每年增长 10% 的基础设施与工程组织，突然扔进每几个月翻倍的新现实，任何地方都会可预测地出故障。mikert89 被追问「举个 Meta 的例子」时以「大概半数核心团队都发生过，听起来你经验不多」回避，antiframe 当场指出「不要回避问题还攻击提问者，这很失礼」；inigyou 用归谬法收尾：「AWS 连续 240 个月每月翻倍？那它现在超过宇宙的原子数了。」

• 离开 GitHub / 自托管。 mort96 的立场很实际：大公司完全负担得起让一名工程师每年花一两天维护自托管的 GitLab 或 Forgejo，除了更好的可靠性，还有一个额外好处——你的源码不会因为进了 Copilot 训练集而意外泄漏；业余爱好者用 Codeberg 很好，社区不错，还能自动挡掉 slop 贡献。ivraatiems 的反对理由是这些系统在 issue 跟踪、知识传递和自动化上缺少 GitHub 的成熟度，另外 Codeberg 有明确的政治立场，「这完全是他们的权利，但对我不吸引——因为他们哪天决定不喜欢我，我就完了」。mort96 回应说任何平台都可能突然认定你的项目违反 ToS（GitHub 也绝不接受任何人使用其平台），而且换 Git 托管并不难，「重新设置 CI 和丢掉 MR 历史确实糟，但不是世界末日，不像丢掉 AWS 账号」。Shish2k 换了个角度评价 GitHub：「用『成熟度』形容 GitHub 对我来说很奇怪——在我常用的所有系统里，它在每一个单项上（代码浏览、issue 跟踪、代码评审、包管理）都是最差的；但它对大多数人足够好，而且这些功能都在一个地方，比拼凑 10 到 15 个高质量但互不相连的系统更方便。」pibaker 给出了最难反驳的锁定理由：GitHub 真正的黏性在社交层面——雇主还是会要你的 GitHub，人们按 star 数评判你的个人项目，从 GitHub 下二进制文件比从别处更放心，潜在贡献者愿意在 GitHub 上留个 PR，但如果要在新平台注册账号并学习它的用法就大概不会，「而且别假定任何竞争者能在不出现类似可靠性问题的前提下吸收 GitHub 流量的哪怕一小部分」。mh- 提供了一个反直觉的事实：GitLab 付费企业版的按座席价格现在比 GitHub 更贵，「当年很多公司迁过去是因为便宜，现在不便宜了。讽刺的是现在公司可能为了稳定性而不是价格迁过去」。0xblinq 对 Forgejo 官网的吐槽（「自托管的轻量软件 forge」这句话什么都没说，「Forgejo 是什么」这个问题没被回答，接下来的文档直接讲怎么安装）引出 mananaysiempre 一段有价值的科普：「software forge」已经是既有术语，指提供协作开发全套功能的软件——至少含带 Web 界面的代码托管、工单和网页托管，如今通常还有代码评审和集成 CI 或至少能接 CI，「它确实模糊，但和 IDE 一样模糊，也就是说仍然足够好用」。0x457 给了具体的自托管评价：Forgejo 不错，但 CI 的故事很惨（基于 act）且缺少 GitHub Apps 之类的东西所以没法用服务账号，「只有 3 个用户时，自托管的可用性比 GitHub 高很容易」；rvz 在帖子发布期间又贴出了新的一次故障状态页，并翻出自己 6 年前反对把一切集中到 GitHub 的旧帖。

• 付费客户被忽略。 rcleveng 的这条列出了他认为文章里该有但完全没有的三点，是本帖最锋利的评论之一：告诉付费客户「我们知道你付了很多钱，我们在故障期间烧掉了你的 Actions 额度——我们会为那些花了你的钱却没给你价值的日子退款」；「我们会确保有一池独立容量来守住你的信任」；「我们会在未达 SLA 时主动退款」。他读到的实际内容是：扩容很难、我们没有足够容量；我们免费送出了海量算力；我不得不说 Azure 不是一堆冒烟的垃圾，否则下一轮薪酬周期我的奖金会被往下调——「注意这里完全没有付费客户的部分，我来替他们补上：付费客户，去死吧，你付我们的钱跟 Windows Server 比根本不是一个有意思的科目。」film42 从小公司视角接上：他 5 个人的公司每月付 GitHub 250 美元，「『看看我们背着多大的负担，照看这么多代码好难啊』这种叙事，对一个每人每月付 50 美元来托管代码和跑 CI 的人来说相当侮辱。如果他们不想要我的钱，我会找一家想要的公司。」
  • 限流与收费成了这串的自然延伸。xyzsparetimexyz 建议按用户设每月推送上限，xienze 反驳这只会加剧「enshittification」的哭声、加速向下一个「这次一定不会挂」的免费平台迁移。dcrazy 半开玩笑地提议「按 issue 和 commit 付费，一次买 1000 个 commit 额度，也许能逼人在推送之前先审一遍 slop」。arn3n 给出了最有说服力的结构性理由说明这不会发生：GitHub 归微软所有，微软有强烈动机让开发者继续用 AI，「我怀疑微软甚至宁愿让 GitHub 亏着运营，只要这个亏损是因为所有用户都在用它的模型、并在为 OpenAI 订阅付费」。bentt 的比喻很妙：「这就像让人免费住你家，却收他们烧掉这栋房子的钱。」functionmouse 的版本更阴谋：「微软也有动机去消灭最大的开源开发中心，它已经拥抱并扩展了它。15 年后他们会说这早就很明显。」关于 GitHub 的成本，conductr 与 otterley 打了一串颇有质量的财务辩论：conductr 主张绝对数字（新增 300 万核）在分析里没用，得看相对于营收或用户的比例，SaaS 即使有高利用率的免费层也常能跑到 90%+ 毛利；otterley 用「你说开一家航空公司的运营成本是高还是低」来反问，conductr 则详细论证 SaaS 与航空业在资本结构和增长风险上根本不可比（GitHub 多买一个机柜在利用率不到 20% 时可能就打平，闲置部分可以断电；航空公司开一条新航线要买飞机、签机场合同、招飞行员和机组、投广告造需求，而且开航就得满载，燃料和人力没法「断电」）。
• 最跑偏的一段：AI 生产力与环境成本。 m4rtink 问「东西这么多还在涨，到底有什么用？我们真的比以前做完了更多事，还是这全是浪费掉的能量？」这个问题引出了本帖体量最大的一片支线。sph 的质疑最有力：「『我做完了多得多的事』快要成为陈词滥调了，但看不到这些惊人生产力提升的任何证据，我开始怀疑你们是不是在集体幻觉。如果大家接受的说法是 100 倍生产力（而且这个数字每天在涨），而 LLM 变得很好用也就大约一年，那软件现状的 100 年进步在哪？如果你声称 100 倍这种人类史上从未有过的跃进，你必须给出非凡的证据，否则就该被打上彻底疯了的标签。我本可以接受『我生产力提高 20%』，那本身就是了不起的成就。」回帖分成几派：agumonkey 和 zingar 描述了同一种体验——东西确实做出来了，但它最后成了「挠痒痒项目」，看到它出现你就满足了，之后再没有驱动力（zingar：「一个月的兴奋建了个我本来没时间做的东西，然后 setup 里有东西坏了，我的动力不足以去修它」）；Agentlien 的解释很尖锐：「用 AI 常常感觉比实际更快，因为你自己在问题上投入的思考和努力更少了」，另一种可能是那些体验到 100 倍的人是诚实且正确的，只是他们原本的生产力糟糕到现在被提升到接近平均的 junior 水平；magicalhippo 给出了最诚实的方差描述：有些内部工具和库他花两天完成、手写要几个月，那接近 50 倍；有一次让 Claude 去追一个他不熟悉的复杂模块里的逻辑问题（没有可复现案例，只能靠日志和客户描述），他花 5 分钟写 prompt，回来时 Claude 已经定位了问题，那确实是 100 倍——但也有很多场合收益微薄甚至为负，「它们以为在修东西，实际在引入更多 bug」；rfgplk 举出 Bun 的 pulse 页说「比例是事实性的，这种速度手工不可能达到」，rimliu 的回应是「速度也许吧，有用性呢？数据不是信息，commit 不（必然）是任何有用的东西」；fooster 给了唯一带业务结果的说法：今年至今 PR 数量约为去年全年的 10 倍且没增加 bug 和故障，被 yladiz 追问「这些特性带来了实际客户增长吗」时答「是的，大量增长」。mikae1 提出一个难以反驳的现实检验：「这是它被推销的方式，但你听说过哪家大科技公司在员工达到 AI 前的产出后就让他们回家吗？」0x696C6961 的轶事是反面证据：「我很多同事在划水，每天交一个自己都几乎没自审过的 AI 生成 PR」——teiferer 说「在好公司这会在下次绩效评估里反噬他们，如果没有，那你就了解到了关于你工作场所的一些事，而且不是好事」，mrguyorama 补了句现实：「中层管理都被砍了，所以每个经理有 30 个直接下属，『没时间』做超过一年几次的 1:1。」ozgung 的问题最直击要害：「有人注意到自己用的软件在质量、性能或能力上有提升吗？」teiferer 的回答是「只在用来做软件的软件里。所以我们都是在自己的泡泡里自我表扬。我确实注意到有提升的是交付压力和要求」。
  • 环境成本那一串同样冗长。croes 反复把话题拉回 CO2 与资源（他强调不是水消耗，而是数据中心建设本身的资源与碳排，以及电力常来自化石燃料，「你以为 Google 和微软为什么撤掉了碳减排目标」）。user43928 主张「在讨论 AI 好处时有人跳出来说『你想过环境吗』总是表演性的」，真实动机是不喜欢 AI 本身或担心劳动力市场；他给出了本串唯一的定量论证：按 2030 年翻倍的预测，约占全球电力消耗的 3%、即 3.4 EJ，不到最终能源消费的 1%（能源密集型工业约 130 EJ，全球最终能源消费 > 450 EJ），因此是「温和的」；他还称今天 AI 已有记录的应用到 2035 年有潜力每年减少 >13 EJ 的能耗。croes 引用 IEA 的数字（全球数据中心约消耗 415 TWh、约占全球电力 1.5%，AI 是新增电力需求的主要加速器；日常推理已占 AI 累计能耗的约 80–90%）并给出立场：「我们正处在需要更少 CO2 而不是适度更多的时点。如果你的医生告诉你减重否则会生病，减重变慢并不是成功。」jangxx 是中间派：「我和别人一样乐于用 Claude Code，但说影响『巨大』是大幅夸大实际结果。」eddieh 拒绝了那条被贴来当论据的 YouTube 视频（「不给上下文的视频链接对论证几乎无用……说服我这个视频值得我一丁点时间是你作为链接者的工作」），并引用了一篇发表在《Sustainability》上的系统性综述，其结论是 AI 的环境足迹是结构性的、日益重要的挑战，受算法、软件流水线、硬件基础设施和部署场景等相互依赖的决策共同塑造，能耗与碳排高度可变、依赖上下文、且常被低估；bblb 用一句话总结了那个 21 分 59 秒的视频：「『我对这个主题一无所知，但我猜电力消耗比已被报告和研究的水消耗更值得担心』——就这些。」
  • yread 引出的开源维护者困境也颇具体：其他项目的维护者被漏洞报告的洪流烧尽而弃坑。fsloth 的立场是「如果这不是你的工作就忽略这些报告；如果真的关键，会有人把钱摆到桌上，那就是生意了」；okeuro49 的反驳是「如果你有高度尽责的人格，这说起来容易做起来难」，fsloth 的回应相当到位：「仅仅去做别人希望的事本身并不是尽责！它可能是，取决于情境，但也可能只是对自我的病态。当让人心理上难受的是『我想象这会让某人失望』，那大概不是尽责，而更像低自尊或共依存。」yread 给出了具体案例来支撑自己的担忧：uclouvain/openjpeg 基本是唯一能读 jp2k 数据的库（「规格复杂，你让 AI 一把实现，我的 AI 说『这是 3000 行难缠的规范，太复杂了』」），issue 里全是缓冲区溢出，最近已无人维护，而它被无数项目使用，「现在这些项目全都可能有漏洞」——zoltan 的回应是「那就别用、换掉、抛弃。我们损失了什么有价值的东西吗？大概没有」。centuryfall 贴了 xkcd 2347。
• 若干一句话的注脚。ryanisnan 挖出这篇文章作者 Vladimir Fedorov 的 GitHub 贡献图：「过去一年零贡献。这是个巨大的、巨大的红旗。」addaon 对着「我们已做的和接下来是什么」这个小标题接了句：「你已经看到我们做了什么。接下来是 8 月 21 日的故障。到时候见！」CodeCompost 提供了一条与官方叙事有张力的现场观察：「『美国中部数据中心未能随之扩容』——我在欧洲，我也遇到了 token 失败」，silverwind 给了答案：「GitHub 没有欧盟实例，全部在美国。」monlockandkey 的建议只有一句：「他们应该把 Ruby 代码重写成一门高性能语言。」annoyingnoob 的总结带着时代感：「GitHub 挂了，硬盘买不到，内存买不到，谢谢 AI！看起来我们正走向技术堵车。」jdm2212 是全帖最坚定的乐观派，他的回应是「这是好事！这才是繁荣经济的样子。外面有人在跟你竞争资源，因为他们有想实现的酷主意」——yoyohello13 的反驳同样直白：「几万人规模的裁员，食品价格失控，人们几乎付不起油钱。至少有些 tech bro 能发布他们的第 50 个 B2B SaaS。我没意识到繁荣的经济这么烂。」