从开源社区到“独自编程”：AI 编程工具如何瓦解软件协作

26年10月12日

距离罗伯特·帕特南写下美国“独自打保龄”现象已过去30多年。这项分析表明，同样的事情如今正发生在编程上。过去几年间，世界迅速从由在线社区生产和维护的开源软件，转向在孤立环境中构建和维护的软件项目。由单个开发者完成，来自他人的输入日益减少。AI编程工具如今正急剧加速这一转变，使代码从一项集体事业变为“独自编程”。我在结尾描述了这种进程为何不必被视为不可避免。每一步都反映了无数个体人类决策的集体影响。我们仍然可以决定帮助重新激活开源软件社区，包括通过以有助于维系社区的方式使用AI编程工具。

1995年，罗伯特·帕特南注意到，打保龄球的美国人比以往任何时候都多，但增长来自独自或休闲打保龄，牺牲的是有组织的集体打保龄。他认为，这反映了社团习惯的更广泛崩塌，这些习惯曾将美国人编织进相互重叠的社会群体。地方俱乐部、工会、教会和联盟在一代人的时间里悄然空心化，不是因为人们失去了对 underlying 活动的兴趣，而是因为他们不再一起做这些事（Putnam 1995， 2000）。保龄球联盟附带的组织结构，最终被证明是这种本可能孤独的消遣方式为社会凝聚力做出贡献的关键。

开源软件有自己的联盟版本：公共代码仓库，有少数核心维护者，以及不断变换的外部人员——他们提问、报告漏洞或留下评论。这些贡献者社区指导和培育着持续的软件开发。人们仍然编写代码，但这项分析表明，支撑和维系这种编写的集体结构正在发生剧变。公共软件仓库正从社会联结与凝聚的场所，变得更像单个人工作的单纯镜像。

这为什么重要？

也许由日益孤立的个人编写的软件，会和以往由更大社区在彼此想法基础上构建的软件一样好？也许一群拥有足够预算、能在AI token上花费数十亿美元的个人，将能够开启天才软件的新黄金时代？一开始就试着弄清这种情况是否可能发生，显然是有帮助的。

这样做时的第一个问题是，好的软件并不容易定义。但至少对开源软件而言，流行度通常可以被推定为反映了质量。流行的开源软件通常可以被推定为好的（尽管许多非常好的软件可能无人注意）。而流行度是可以衡量的，通常通过下载量，以及人们在GitHub上给软件仓库“加星”的次数等指标。

以下所有分析均使用来自若干常见软件分发系统的随机仓库样本，包括 Javascript 的 npm、Python 的 PyPI、R 的 CRAN，以及两个基于 GitHub 的软件评审组织：JOSS（Journal of Open-Source Software）和 rOpenSci。为其中每一个提取的数据都能显示，更大的社区是否有助于产出更好的软件——以流行度来衡量。

社区规模与流行度之间的关系当然会变得复杂，因为二者往往随时间变化并相互作用（理想情况下是共同成长）。这种相互影响可以很容易地在统计上加以控制，从而在排除仓库年龄对这两项指标中任何一项的影响的情况下，估计社区规模对仓库流行度的影响。这样做便揭示出下图所示的关系：

以流行度衡量，好的软件绝大多数由更大的社区产出。这种关系当然纯粹是相关性的，无法说明更大的社区是否真的导致了软件质量的提升。但它仍然足以清楚地表明为什么这很重要：由较小社区产出的软件往往明显不那么流行。这表明，产出软件的社区规模若出现任何缩小，都可能伴随着软件流行度的下降，并且很可能伴随着软件质量的下降。

回答本节提出的问题：这些分析之所以重要，是因为好的软件源自大型社区，而任何导致社区规模缩小的因素也会导致软件质量下降。本分析的其余部分提供了多方面的洞见，揭示出开源社区似乎正在全面崩溃。

测量了什么

所有数据均取自 GitHub，主要是通过“issues”与软件仓库互动的度量。Issues 是任何人向软件作者提问、报告 bug 或请求新功能的地方。仓库语料库取自上述五个来源。这些分析的完整源代码见 github.com/mpadge/coding-alone。

分析涵盖了 JOSS 和 rOpenSci 评审过的每一个仓库、当前在 CRAN 上的每一个包，以及另外三个来源的样本。样本按流行度分层，以确保无论流行度如何都能均匀抽样并具有代表性。总共分析了 52,461 个仓库中的 3,139,779 个 issue。

更受欢迎或更知名的代码仓库会吸引更多互动，导致 issue 被更频繁地开启，且来自更广泛的社区。为了考虑仓库受欢迎程度的影响，大多数结果都按四个受欢迎程度分层呈现，这些分层取自对数受欢迎程度标度上的四分位数。最低的四分位数，记为“Q1”，代表最不受欢迎的仓库。由于这些仓库在数量上通常远超受欢迎的仓库，因此这些 Q1 值通常可以解释为反映了所有仓库中的大多数。“Q4”仓库则是那些拥有海量下载量和数百人开启 issue 的离群超级明星仓库。我们还提取了一些额外的统计数据，并在主要分析中一并描述。

那 pull request 呢？

GitHub 还实现了“pull request”，允许人们上传自己的代码更改，并请求将其与仓库的代码“合并”。对于大多数只是想提问，或请求软件为其特定目的进行适配或修改的人来说，pull request 并不是合适的地方。来自非核心贡献者的 pull request 通常是在 issue 中明确提出请求之后才出现的。我将在本分析的最后简要考察 pull request。我还会在那里说明，pull request 仅占 GitHub 上所有仓库互动的一小部分，其余互动都通过 issue 进行。 这些分析的重点是社区与开源软件互动的主要切入点，而这一直是 issue，而非 pull request。

但仓库不会随着年龄增长而稳定下来吗？

不会。仓库年龄对这里的分析或结论没有影响，如此在线附录所示。

主要发现

发现 #1：人们在减少编码

尽管这里的主要关注点是开源社区的衰落，但所有数据也揭示出编码活动总体上普遍下降。编码活动最直接的衡量标准是新仓库的创建以及每个仓库中的提交数量。这两项统计的时间序列显示在以下两个面板中。两者都显示出与后续大多数结果相同的趋势：在 2020-2021 年之前发展多变，随后下降更为持续。反映这些普遍模式，下文许多结果仅显示 2021 年以来的时间序列。比较也以 2021 年 1 月与当前（2026 年 10 月）之间的“阶跃变化”形式进行。

仓库创建量的下降当然可能只是反映人们转向 GitHub 之外的替代代码托管网站。这里不再进一步考虑此类影响，但后续所有分析都源自（仍然）将 GitHub 标识为其主要来源的软件，因此与人们是否正在放弃 GitHub 转向替代网站无关。图 2 中的每月提交率就是一个例子。这些比率中的大多数在过去几年中都有所下降，并直接反映了在仍活跃于 GitHub 的人群中观察到的真实下降。

发现 #2：贡献者更少了

衡量开源软件贡献者数量有几种方法。源代码本身提供了最直接的衡量方式之一，通常通过追踪每次更改的提交者来实现。代码托管平台则提供了另一种方法，通过仓库 issue 的数据来衡量。任何人（只要有账号）都可以打开一个 issue 来问一个简单的问题。许多这样做的人最终未必会直接贡献代码，而几乎所有贡献代码的非核心开发者都是通过 issue 开始他们的第一次互动。因此，issue 数据比直接代码贡献者的数据能提供对开源社区更具包容性的洞察。

图 3 显示了五个软件生态系统中在仓库上打开新 issue 的唯一人数。所有计数均标准化为每个仓库每月的新 issue 数。所有这些模式都揭示了 2020 年前后一致的变化。并且自那时以来，它们都在逐步下降。

对于每个软件源，图中显示了上述四个分布四分位数的线条。“Q4”代表相对少数极其流行的软件包，而“Q1”是最低流行度的四分位数。（这些四分位数是在对数尺度上定义的，因此 Q1 中的软件包数量远多于 Q4。）

下一张图（图 4）显示了自 2021 年 1 月以来每个软件生态系统和每个流行度四分位数的平均下降幅度。其中许多下降在最流行的软件（Q4）中更为明显，尽管 PyPI 显示出相反的趋势，最流行的软件包中唯一 issue 作者数量的下降不那么严重，而 npm 则显示出中间模式。

每个 issue 的评论总数显示出类似的模式（图 5），PyPI 和 npm 的趋势也同样相反。综合来看，这两张图揭示了在过去几年中，所有软件系统中 issue 作者数量和每个 issue 的评论数量都严重下降。只有在 PyPI 中的 python 软件包中，最流行的软件包的下降才不那么严重。在所有其他系统中，下降要么对更流行的软件包统一更为严重，要么对于 npm，显示出混合模式，在流行度光谱的两端下降最为严重。

到目前为止，所有统计数据的相对差异都在下表中量化为自 2021 年 1 月以来的百分比变化。尽管这些数值显示编码本身明显下降，无论是仓库创建率还是提交率，但社区规模指标的下降要严重得多。编码在减少，但社区互动萎缩得更快。

图 1-4 中统计数据的百分比变化，基于对 2021 年 1 月以来所有流行度分层全部数据拟合的线性回归估算得出（JOSS 和 rOpenSci 的仓库创建通常只在经过严格审查流程后才会发生，因此这两个来源的数值实际上无法与其他来源直接比较，且很可能受到额外约束和影响。）

GitHub issue 新作者出现的速率在所有软件系统中也逐步下降（图 6）。在软件来源与流行度分层的这 20 种组合中，有 18 种的新作者到达速率下降幅度大于整体作者密度的下降幅度，这意味着上文记录的下降并非仅仅是现有常客发帖频率略有降低；它不成比例地反映为首次出现的人数在缩减。

下图将这些绝对度量转换为相对尺度，以便比较每个软件来源在各流行度四分位之间的相对变化率。在几乎所有情况下，新作者到达速率的下降对最流行的软件包最为严重。

考察这些到达速率下降的另一种方式是看每对连续新作者到达之间的间隔（图 8）。

这些速率在过去几年中也一致上升。它们在 CRAN、JOSS 和 rOpenSci 中尤为高得多，在这些来源中，新作者现在仅在最流行的软件包中才以每月超过一次的频率到达。只有 PyPI 似乎未受此趋势影响，其新作者到达间隔在过去几年中逐步缩短。

发现 #4：螺旋走向孤独

对于每个为仓库做出贡献的人，GitHub 还提供了其相对总体贡献的度量，以对源代码的提交次数衡量。这些相对贡献值被用来任意区分仓库的核心贡献者，即累计贡献占所有提交 99% 的人。非核心贡献者则被定义为累计贡献低于 1% 的人。虽然这一阈值是任意的，但后续结果或结论均不会因不同取值而在性质上受到影响。

在所有软件来源中，非核心作者数量的相对下降幅度都大于核心作者（图 9）。在所有情况下，图 4 和 图 5 中观察到的贡献下降大部分反映的是非核心贡献者比核心贡献者下降得更快。

这些下降的综合效应必然是越来越多的仓库仅由一人维护。这正是 图 10 所显示的。总体而言，2021 年 1 月有 27% 的仓库实际上由单人维护。到 2026 年 10 月，这一比例已上升至 44%。

这是什么意思？

这些分析的许多方面与其他人的报告一致，涉及那些维持开源软件生存的人。2024年一项针对开源维护者的调查发现，其中61%的人完全独自维护自己的项目，而无偿维护者独自工作的可能性不成比例地高（Socket 2024）。Tidelift在2024年对维护者的一项调查发现，60%的人仍然完全无偿，近60%的人已经退出或认真考虑过退出他们维护的项目，理由包括生活需求冲突、失去兴趣或倦怠（Tidelift 2024）。

2025年11月，Kubernetes的管理和安全委员会退役了Ingress NGINX（Kubernetes SIG Network and Security Response Committee 2025）。这是现存部署最广泛的云原生基础设施之一，在所有“Q4”高人气层级中都会位居前列。NGINX多年来一直由自愿的开源贡献者维护，然而这里观察到的各种衰退在这件事上表现为完全无法找到哪怕一个愿意维护该项目的人。

好的软件总是在演进，而这种演进的一部分常常包括维护者寻找其他人来继续他们的工作。新的维护者总是从抵达项目的新人社区中涌现。GitHub让新人比以往任何时候都更容易神奇地出现，主要是通过提交issue来提问。许多项目积极营造开放和欢迎的氛围，试图吸引尽可能多的新人，然而即便是这种做法似乎也在减少（Hoshikawa et al. 2026）。

真正的困难始于试图留住新人的兴趣。一项十年前对某个大型Apache项目的研究发现，最初出现在软件仓库中的人里，不到五分之一成为长期贡献者（Steinmacher et al. 2013）。在这些发现之前的十年，Nadia Eghbal的Roads and Bridges描述了关键开源基础设施如何由少数无偿志愿者维持，并认为真正的短缺始终在于人而非钱（Eghbal 2016）。最后，这些结果也反映了有充分记录的Stack Overflow作为社区平台的崩溃（Orosz 2025；Holscher 2025）。

那AI呢？

这里观察到的衰退在我们如今所知的AI出现之前几年就开始了。AI几乎肯定有所贡献，包括通过“算法单一文化”（Bommasani et al. 2022）等机制抑制软件输入的多样性。过去一两年间的变化确实像是此前变化的加速版本或延续，包括在仓库创建率、新贡献者的数量和到达率，以及单人作者项目方面。AI很可能对所有这些加速的衰退率都有影响，尽管是在更普遍、更广泛的因素之后并且叠加在其上。

有许多声称开源项目被 AI 生成的拉取请求“淹没”的说法。（这些都不值得在此引用，因为我找不到实际数据来支持此类说法）。如上所述，新贡献者的首次接触点通常非常普遍地是 issue，而拉取请求（PR）通常只在 issue 内初步讨论之后才提出。这反映了普遍的人类惯例：只有在首先确认对方确实想要或需要之后，才会为别人做某事。软件开发中采用的先 issue 后 PR 的一般工作流程并没有什么特别之处。它反映了人类互动的一般结构方式。先问，再做。

此处提取 PR 数据的方式与提取 issue 数据的方式相同。唯一确实似乎发生了变化的是 PR 与 issue 的比率（图 11）。自 2021 年以来，PR 的比例逐渐增加，在一些软件系统中近期加速明显，最显著的是 npm 和 CRAN。

先做后问

如上所述，大多数人类社会都培养先问后做的习惯。未经请求的拉取请求颠覆了这一习俗。它们代表着一种相对更具侵略性的先做后问。虽然这种文化变迁的原因可能很复杂，但社会孤立加剧似乎确实会助长攻击性增加（Twenge et al. 2001）。尽管独自编码可能会增加 PR 与 issue 的比率，但图 11中的增长更可能揭示了 AI 编码工具的额外负面影响。

支撑 AI 编码工具的大型语言模型是在主要来自在线数据的大量语料库上训练的。而人们在网上的行为与面对面时不同。我推测，PR 与 issue 比率增加的一个更可能的原因是，AI 中嵌入了广为人知的“在线去抑制效应”（Suler 2004）。

AI 编码工具——当然还有一般的 AI——更多地反映了病态去抑制的在线行为，而非实际的人类社会行为。Suler（2004）最初的描述很有洞察力：

[人们]不必通过承认自己的行为来为其负责……在线自我变成了一个分隔化的自我……这个人可以逃避责任[以一种]“情感肇事逃逸”的形式。

[人们可以]生活在一个 [原文如此] 虚构的维度中，与真实世界的需求和责任分离且无关。[他们]将自己的在线生活视为一种游戏，其规则和规范不适用于日常生活……他们放弃了对虚构游戏世界中发生的事情的负责 [原文如此]，那个世界与现实毫无关系。

也许这里观察到的所有下降都反映了 Suler 在 20 多年前所描述的那类行为的增加。在网上做一切事情（包括编码）变得越容易，那些进行编码的人的行为就越会从他们的亲社会、面对面行为中去抑制。AI 只是这一过程的顶点。

Suler（2004）最初的结论措辞谨慎，承认了“良性”与“毒性”去抑制之间复杂的相互作用。更近的研究（Chu 等，2026）表明，现实更偏向毒性而非良性一侧，尤其是在男性主导的在线空间中。我曾在别处说过，“你的 AI 认为你是个哥们。这对所有不是哥们的人来说都是个问题。”这些分析为这一结论增添了细微之处，表明 AI 编程助手是其训练深受反社会男性毒性去抑制表达影响的体现。

对此我们能做些什么？

首先也是最重要的，这里的一切都表明，迫切需要尽一切可能去培育、滋养和维护社区。始终寻求协作，而不是独自做事。即使你不认识任何可以协作的人，在你的开源仓库中邀请协作也能产生巨大效果（Hoshikawa 等，2026）。而 Chu 等人（2026）的结果为社区多样性的亲社会效应提供了有力证据——邀请并鼓励尽可能多不同类型的人。

以有益的方式使用 AI 编程工具

也许最重要的是，如果你使用 AI 编程助手，请确保以具有社会意识的方式使用它们。这些机器被训练成对遇到的任何软件问题自行实施变通方案。而且它们往往悄无声息地这样做。从在 AGENTS.md 文件或类似文件中给出明确指令开始，不要悄无声息地这样做，而要告诉你。以帮助你作为人类与其他软件的人类开发者建立联系的方式使用 AI 编程工具，其实相当容易。至少，绝不要让 AI 编程工具在你并不熟悉的任何仓库上发起未经请求的拉取请求。那是不问自取，是无礼的。始终先询问，并用你自己的人类语言去问。帮助重新确立开源社区作为真正协作空间的性质。