ACM 开源 AI 报告警告：更快的编码正在压垮人工审查

ACM 开源 AI 报告指出了一个代价高昂的逆转：AI 可以快速生成补丁，但仍需由人类决定哪些改动值得信任。这种失衡正为本已面临时间、资金和审查能力限制的维护者增加工作负担。

该报告由美国计算机协会（Association for Computing Machinery，ACM）技术政策委员会发布，考察了 AI 对开源软件的影响。其核心担忧并非 AI 能否编写有用的代码，而是由人类主导的项目能否安全承接大量由机器辅助完成的贡献。

这一区别至关重要，因为开源软件支撑着手机、车辆、云服务和 AI 系统。然而，许多重要项目依赖志愿者或小型团队。在遇到低质量的 AI 投稿后，Godot、curl 等项目已收紧贡献规则。代码大量涌现的承诺，正与人类注意力稀缺的现实相碰撞。

ACM 开源 AI 报告将关注点转向审查

报告认为，更快的代码生产并未消除人类瓶颈，而是将这一瓶颈转移到了审查、治理和维护环节。

这份 ACM TechBrief 于 2026 年发布，由通过 ACM 技术政策委员会开展工作的六位作者撰写。他们包括 Arunachalam Balasubramanian Shrinivass、Simson Garfinkel、Josiah Dykstra、Andy Oram、Nina Shamsi 和 Jonathan M. Smith。

该简报讨论了四项相互关联的压力：网络安全、软件维护、财务可持续性，以及组织对自身开源依赖了解有限的问题。AI 会影响这些领域，但影响方式并不相同。

AI 系统能够发现漏洞、提出补丁、编写测试，并自动化常规开发工作。这些能力可帮助管理良好的项目更快解决明确的问题，也能帮助贡献者准备文档或探索陌生代码库。

然而，拉取请求只是一项修改项目的提议。可信赖的维护者必须判断其是否解决了既定问题、保持兼容性、符合项目标准，并避免带来新的安全风险。

这一判断往往不止是阅读被修改的代码行。审查者可能需要复现问题、检查相关模块、评估架构后果，并在受支持环境中测试行为。

AI 降低了生成看似合理投稿的成本，却没有以同等速度降低理解所有后果的成本。

这种不对称改变了参与的经济模式。贡献者可以生成多个补丁，而维护者可能还在审查第一个补丁。提交者也可能在发起请求后离开，而项目则承接每一个尚未解决的问题。

原始报道将其描述为需要人类检查的代码更多。这一表述抓住了眼前的问题，但更广泛的后果更为严重。

开源版本发布依赖于委托式信任。维护者决定哪些贡献者、流程和产物足够可靠，可以进入正式构建。因此，未经验证产出的增加带来的是治理工作，而不只是编码工作。

报告并未声称每一项 AI 辅助贡献都质量低下。它承认模型质量可能提升。尚未解决的问题在于，每一份额外投稿仍需要一定程度的人类判断。

当生成的代码看起来很有说服力时，这种判断尤其昂贵。补丁可能能够编译并通过可见测试，却误解了某项未记录的假设；它也可能引入看似无害的复杂性，直到后续改动暴露问题。

因此，ACM 开源 AI 报告改变了核心问题。问题不再只是 AI 是否让个体开发者更快，而是项目层面的审查能力是否会随其产出一同增长。

这一重新界定形成了本文的主要冲突：机器生成的充裕产出与人类控制的信任之间的矛盾。

开源维护者面临审查能力缺口

承受最大压力的项目不一定拥有最糟糕的代码，而是那些采用广泛、却缺少足够合格审查者的项目。

合格的审查者需要的不只是通用编程能力。他们必须了解项目架构、兼容性承诺、发布流程和社区预期。

这种知识需要长期积累。一个成熟项目可能拥有数千名用户，却只有一小群人能够批准影响重大的改动。增加一个代码生成器，并不会自动增加一位可信赖的审查者。

当 AI 吸引首次贡献者时，问题会更加突出。新成员的参与可以增强开源社区，前提是贡献者学习其规范，并最终承担维护责任。

传统审查在一定程度上发挥了这种指导功能。维护者会解释为何某项改动需要修改，贡献者则将这些知识带入未来的工作。

机器介导的参与可能打破这种交流。维护者仍要花时间解释项目要求，但提交代码的人可能既不理解，也不会保留这些经验。

Godot 在 2026 年 6 月 30 日宣布更严格的贡献规则时，明确表达了这一担忧。这款开源游戏引擎表示，其合格审查者群体规模较小，而拉取请求积压已难以管理。

Godot 表示，AI 降低了创建拉取请求所需的工作量，却没有减少审查请求所需的工作量。该基金会还质疑，无法培养贡献者或未来维护者的反馈究竟有何价值。

其计划中的规则禁止自主 AI 代理和大量由 AI 编写的代码，同时要求贡献者在使用有限 AI 辅助时承担人工责任并进行披露。

这项政策并非单纯出于意识形态而拒绝 AI，而是试图保护一种稀缺资源：具备充分了解的审查者时间。

风险并不局限于代码投稿。项目还可能收到生成的错误报告、功能提案、安全发现和讨论评论。每一项内容都在争夺同一批维护者的注意力。

一份看似详尽的漏洞报告可能尤其昂贵。审查者必须先确定所称缺陷是否存在，才能安全地将其驳回。即使不会带来修复，虚构报告也可能消耗数小时。

2026 年 7 月的一篇预印本将这种模式称为 AI 贡献洪流。研究人员分析了 294 个代码仓库，其中包含逾 200 万个拉取请求和问题。

他们报告称，拉取请求量在 2025 年增长，而合并率下降。相对于研究模型设定的反事实情形，一次性贡献者的合并率下降了 18.18%。

研究人员还访谈了从业者，并调查了 229 名开源参与者。他们发现的防御策略包括采用更严格的贡献模板，以及更广泛地限制外部投稿。

这些发现并不能证明 AI 导致了每一项被拒绝的请求。代码仓库研究也面临分类和比较方面的局限。但它们确实说明了为何维护者将新增数量视为能力问题。

另一项 2026 年研究考察了 2023 年 1 月至 2026 年 5 月期间的 11,097 个 GitHub 代码仓库。研究报告称，项目采用 AI 编码代理后，审查深度提升了 5.3%。

审查深度衡量的是审查互动的强度，而非最终软件的质量。不过，这一增长支持了一个一致的机制：更快的生成将工作转移至验证环节。

结果便是审查能力缺口。贡献量可以通过低成本自动化扩张，而可信赖的审查仍受限于稀缺的人类专业知识。

更快的 AI 编码带来信任与安全之间的权衡

AI 能够帮助修复开源软件，但同样的速度也可能增加攻击机会，并压垮负责安全发布的人。

ACM 开源 AI 报告将 AI 描述为双用途能力。模型可以定位漏洞并提出修复方案；类似技术也可帮助攻击者寻找弱点，或生成具有说服力的恶意投稿。

Google 的 CodeMender 展示了防御方面的潜力。根据 Google 的说法，该代理在 2025 年 4 月至 10 月期间为开源项目贡献了 72 项安全修复。

部分目标项目的代码规模多达 450 万行。在这一规模下，自动化可能很有价值，因为人工团队无法手动检查每一条路径。

不过，自动化修复仍须进入项目的信任流程。维护者必须验证诊断结果、审查补丁、评估测试，并协调发布时机。

当一款应用依赖众多独立软件包时，这一过程会变得更困难。每个组件都有自己的维护者、发布计划和下游用户。

AI 系统或许能迅速发现多个库中相关的弱点，但整个生态系统未必能以同样速度为每个受影响组件完成修复、发布和部署。

攻击者不承担同样的责任。他们可以生成大量假设、放弃失败尝试，并利用第一个有价值的结果。防御者则必须调查可信发现，同时避免破坏现有系统。

开放代码仓库也带来了供应链风险。恶意行为者可以提交看似有用的软件包、补丁或依赖更新，同时隐藏不受欢迎的行为。

AI 可以让此类投稿更为精致。它能够生成测试、文档和详细说明，营造出认真周全的表象。但呈现质量并不能证明来源或安全性。

因此，通过测试套件不能成为唯一的门槛。测试代表已知预期，极少覆盖每一处安全边界、异常环境或长期维护成本。

审查者必须问：谁理解这项改动，又由谁在未来修复它。他们还需要确定新增依赖、生成文件或陌生模式是否扩大了项目的攻击面。

这一责任归属问题划分了辅助与委托的界限。开发者可以使用 AI，同时仍有能力为每一项设计选择进行辩护；无法解释补丁的贡献者，则会将这项责任转移给项目。

使用开源软件的组织也会继承其后果。许多团队维护着技术知识库，却仍缺少一份反映当前状态的软件依赖地图。

软件物料清单，即 SBOM，提供应用组件的机器可读清单。它可以帮助安全团队在漏洞披露后定位受影响的库。

SBOM 无法说明某个组件是否拥有足够的维护者，无法揭示未解决的拉取请求是否正在积压，也无法显示项目治理是否已被削弱。

它同样无法判断一项 AI 生成的修复是否得到了充分审查。清单是必要的，但组织意识还必须涵盖项目健康状况和维护实践。

因此，取舍并非 AI 与安全之间的对立，而是缺乏问责的速度，与由审查、可追溯性和负责任的所有权支撑的速度之间的选择。

AI 可以缩短从发现问题到形成候选补丁的路径，但无法免除确认该补丁是否应纳入可信发布版本的必要性。

资金模式与开源的价值并不匹配

AI 正在加重维护者的负担，而开源生态系统创造的经济价值远远超过许多单个项目获得的资金。

ACM 简报引用的研究估计，如果开源软件不存在，企业的软件支出将是现在的 3.5 倍。同一项经济价值研究估计，开源在全球范围内为企业创造的需求侧价值达 8.8 万亿美元。

这些数字描述的是组织通过使用共享软件所避免的成本，并不代表维护者获得的收入。

这一差距至关重要，因为开源维护远不只是编写代码。项目还需要发布管理、文档、用户支持、打包、测试、筹款以及社区管理。

AI 可以协助完成其中部分工作，却无法决定项目优先级，也无法调和用户、贡献者和赞助方之间的分歧。

ACM 开源 AI 报告强调了一项引人注目的机构对比：Linux Foundation 报告的 2024 年收入为 292,217,236 美元，而 Apache Software Foundation 为 2,379,402 美元。

这些组织在覆盖范围和运营模式上存在差异，因此不应将其收入视为直接的绩效比较。不过，这种对比仍说明了资源在开源生态中的流动是多么不均衡。

更重要的不平等存在于项目层面。一个被广泛使用的组件，可能没有专门组织、支持合同或全职维护者。

企业可以基于该组件构建盈利服务，却甚至不知道由谁批准发布。往往只有在出现漏洞、项目被弃置或发生破坏性变更后，它们才会审视其治理机制。

这就是搭便车问题：使用者从共享资源中获得价值，却没有按比例为其维护作出贡献。AI 并未制造这一问题，但可能会加剧它。

一家公司可能使用 AI 编程工具，针对外部依赖生成改动。如果其工程师将这些改动提交至上游，接收项目就要承担审查成本。

公司获得了更低成本的代码生成，而志愿维护者则多了一份需要验证的提案。

即便是有用的补丁，也会带来协调工作。维护者必须确保它服务于更广泛的用户社区，而不只是贡献者的私有需求。

糟糕的提交会造成更高的外部成本。提交方组织可以放弃请求，而项目则必须关闭它、解释决定，或处理由此产生的冲突。

资金可以增加审查能力，但金钱本身无法立即造就专业知识。新维护者仍需要时间了解项目，并赢得社区信任。

这意味着支持不应局限于短期漏洞赏金。项目需要为文档、入门培训、测试基础设施、打包和继任规划提供持续资金。

ACM 简报的建议反映了这一更广泛的需求。它呼吁更加重视财务可持续性，以及保障项目可用性的组织性工作。

企业采购方应将此视为供应链管理。如果一个关键依赖由一位筋疲力尽的志愿者维护，这种状况本身就是运营风险。

采购团队通常会评估商业供应商的稳定性，却很少对开源软件包进行同等严格的审查，因为没有账单触发这一流程。

AI 带来的贡献压力使这种疏漏更难辩护。更多自动化产出可以流入项目，但项目的人力容量对下游用户而言仍不可见。

因此，资金问题与审查问题密不可分。一个生成更多提案却不为判断能力提供资金的系统，只会加深瓶颈。

全面禁止 AI 能保护注意力，但也可能缩窄参与渠道

更严格的门槛可以保留短期审查能力，但设计不当的限制同样可能阻挡合法贡献者，并削弱未来维护者的人才储备。

面对大量低价值提交的项目有多种选择。它可以要求披露、限制贡献规模、要求可复现的测试、限制新功能，或禁止某些形式的 AI 使用。

每项规则都会改变成本由谁承担。详细的提交模板会要求贡献者在维护者开始审查前先说明其工作。

权限要求可减少试探性的功能请求。自动检查可在人类审查前拒绝格式错误或缺失测试的提交。

全面禁令提供了更清晰的边界，但执行困难。AI 生成的代码并没有可靠的技术标记，人类编写的工作同样可能质量不佳。

检测工具可能产生误报。如果润色过的文本被视为使用 AI 的证据，以第二语言写作或使用无障碍辅助工具的贡献者可能受到不公平质疑。

严格规则也会提高真正新手的进入门槛。开源依赖于将部分初次贡献者转化为长期参与者。

如果项目关闭所有易于进入的路径，或许能保护今天的审查者，却会减少明天的维护者储备。这正是近期研究指出的可持续性陷阱。

ACM 开源 AI 报告并未提供通用的贡献政策。开源治理仍然是去中心化的，项目在风险、规模和审查能力方面差异很大。

一个小型命令行工具不能照搬大型基金会的流程。密码学库应采用与实验性设计工具不同的保障要求。

不过，维护者提供的证据显示出广泛的怀疑态度。Tidelift 的维护者调查询问：已知使用 AI 会如何影响受访者审查贡献的意愿。

在 344 名受访者中，64% 表示自己更不愿意审查或接受由 AI 生成的贡献。9% 表示更愿意，27% 则不确定。

这项调查早于最新一代编程智能体，随着工具改进，态度可能发生变化。但它仍表明，不能仅凭技术能力就假定贡献者信任存在。

最公平的政策目标应是问责，而非写作风格。贡献者应理解自己的改动、披露相关自动化工具、提供证据，并在需要修改时保持可联系状态。

项目还可以将低风险辅助与实质性委托区分开来。代码补全、机械替换和翻译，与自主开发功能所带来的负担可能不同。

贡献规模同样重要。带有已复现漏洞和针对性测试的聚焦补丁，比未经事先讨论便生成的大范围重构更容易评估。

维护者需要拥有关闭那些带来不成比例审查工作的提交的权力。他们还需要在贡献者投入时间之前，通过政策说明这一界限。

GitHub 等平台可通过赋予项目更强的接收控制能力来提供帮助。实用功能可能包括贡献权限、结构化声明、速率限制和特定仓库检查。

平台支持无法取代本地治理，但可以减少执行各个社区选择所需的行政工作。

怀疑论的观点依然重要：现有证据无法衡量所有 AI 辅助工作。贡献者并不总会披露工具使用情况，研究人员必须根据不完整信号推断采用程度。

审查活动增加，可能反映项目规模扩大或贡献者群体变化。它并不能证明每一条新增审查意见都代表有害的机器产出。

现有证据支持一个更谨慎的结论：生成能力的增长快于许多项目验证贡献的能力，而维护者正以更严格的门槛作出回应。

三个信号将显示压力是否正在缓解

下一项检验在于：项目能否获得审查能力，平台能否改善贡献控制，以及主要使用者能否为其依赖的项目提供资金。

第一个信号是仓库队列中可衡量的变化。研究人员和项目负责人应跟踪审查时间、关闭原因、合并率和重复贡献情况。

健康的干预措施应减少低价值输入，同时不消除成功的新手贡献者。仅仅缩短队列并不够，若项目是通过关闭外部参与实现这一点，情况尤其如此。

最有力的证据应将数量与质量结合起来。项目应报告已接受的变更是否需要更少修改、引发更少回归问题，以及是否吸引了持续参与的贡献者。

第二个信号是平台层面对问责的支持。代码托管平台可以在不试图通过不可靠检测识别 AI 作者身份的情况下，让披露和验证变得更容易。

结构化提交字段可以要求贡献者描述测试、解释设计选择，并确认自己有能力维护该变更。

项目还需要限制高成本贡献类型的工具。维护者应能够要求大型重构或自主智能体提交先进行讨论。

如果平台引入这些控制措施，ACM 开源 AI 报告的诊断就获得了可操作的回应。如果它们只专注于增加智能体产出，不平衡就会加剧。

第三个信号是依赖开源的组织能否提供持续资金。一次性资助固然有帮助，但维护需要经常性支持和付费审查时间。

企业应识别哪些依赖会影响生产、安全和合规，随后审视维护者集中度、发布活动、文档质量和响应能力。

软件物料清单（SBOM）可以通过识别组件来启动这一流程。更困难的一步，是将清单与所有权、治理和投资决策联系起来。

安全团队还应区分补丁可用与补丁部署。AI 可以迅速发现缺陷，但在每个依赖完成更新前，下游产品可能仍然暴露于风险之中。

这种延迟一部分源于技术，一部分源于组织。一支人手不足的项目团队，可能成为众多商业系统中最缓慢的一环。

开发者同样负有责任。任何使用 AI 编程工具从事开源工作的人，都应验证输出并理解周边代码。

一份提交应包含清晰的问题说明、聚焦的范围、相关测试，以及贡献者无需咨询模型也能辩护的解释。

组织可以通过安排经验丰富的工程师支持其上游变更，来降低外部审查成本。它们不应将社区维护者视为无偿质量保障人员。

与此同时，维护者需要被允许根据实际能力设计贡献流程。开放并不意味着必须接受无限量、未经验证的产出。

长期机会并不是将 AI 从开源中排除，而是在自动化能够减少重复工作、又不会使代码脱离人类责任的地方使用它。

AI 辅助审查最终或许能帮助实现这种平衡。一项涉及 587 次补丁审查的研究发现，只有少数生成的评论被直接采纳，尽管额外评论被评价为可作为指导的有用内容。

这一混合结果表明，审查工具可以辅助人类判断，但无法取而代之。项目在依赖这类系统之前，仍需要从自身工作流程中获得证据。

在这些系统成熟之前，这一核心逆转仍将持续：代码生成日益充裕，而具备上下文的判断力依然稀缺。

依托开源构建产品的读者，应当提出三个实际问题。若某位维护者离开，哪些依赖项将不再获得安全更新？谁在资助他们的审查工作？如果自动化提交耗尽了团队剩余的处理能力，你的团队将如何应对？

ACM 关于开源 AI 的报告让这些问题变得紧迫，因为压力已然显现。未来几个月，请关注代码仓库积压、平台管控措施，以及持续性的维护资金。

如果这三方面都能改善，AI 就能为开源生态的能力带来净增益。如果提交量持续上升，而这些条件未能同步改善，更快的编码仍将不断带来更慢的信任建立。