AI写代码写嗨了，开源社区先扛不住

来源：市场资讯

（来源：网易智能）

出品 | 网易智能

作者 | 小爪

编辑 | 王凤枝

AI编程工具最早让人兴奋的地方，是它能写代码。

现在真正麻烦的地方，也是它能写代码。

当一个工具只是帮你补全几行函数，风险还留在用户自己的电脑里。写错了，用户改；跑不通，用户调；不该提交，用户自己拦下来。

但AI编程工具正在越过这个边界。它们不只补全代码，还能接任务、读仓库、跑测试、生成pull request。代码不再只是生成给用户看，而是进入开源项目、公司仓库和维护者的审核队列。

问题也因此变了。过去我们问的是：AI能不能写出代码？现在更该问的是：它写出来的东西，谁来审？

《金融时报》近期长文把这个矛盾放到开源社区里看：生成代码的成本被AI降低了，但审核代码、理解代码、拒绝低质量贡献的成本，并没有一起消失。它只是被转移到了维护者那一侧。

当AI编程工具把创建和提交变得更便宜，真正被放大的是代码进入别人工作流之后的审核成本。

被堵住的不是代码库，是维护者

《金融时报》从cURL写起。

cURL是互联网里那种几乎所有人都在用、但几乎没人意识到自己在用的软件。项目维护者估计，libcurl已经被安装超过200亿次。它是现代数字生活的底层零件，却不是由一家巨型公司维护。cURL最核心的维护者，是瑞典开发者丹尼尔·斯滕伯格（Daniel Stenberg）。

AI编程工具给这类维护者带来的新麻烦，是大量看似有用、实际需要人类仔细排查的提交和报告。

根据斯滕伯格1月26日发布的博客，cURL的漏洞悬赏自2019年启动以来，累计确认87个漏洞，支付超过10万美元奖励；但从2024年下半年开始，AI垃圾报告逐渐拖垮这个机制，2025年明显恶化，真实漏洞确认率跌到5% 以下。cURL最终决定在1月31日停止漏洞悬赏。

维护者真正抵触的，不是新工具本身，而是提交变得太便宜了。

过去，一个人要给cURL这样的项目提交漏洞报告或代码修改，至少要理解一点上下文。现在，一个人可以把问题丢给模型，让它生成报告、建议补丁，甚至组织成看起来很专业的文本。提交者的成本变低了，维护者的成本却没有同步下降。

即使是完全由AI生成的报告，维护者要打开它、读懂它、复现它，再决定它是不是一个真实问题。

贡献变便宜以后，信号也在失效

开源贡献过去不只是"交付一段代码"，也是一种信任建立过程。

你修了一个bug，写了一个功能，补了一段文档，项目维护者接受了，你就成了贡献者。这个贡献可能给你带来声誉、简历亮点、同伴认可，甚至工作机会。维护者花时间反馈，也是在培养未来的协作者。

但AI编程工具正在让这套激励变形。

tldraw创始人史蒂夫·鲁伊兹（Steve Ruiz）今年1月宣布，tldraw将自动关闭外部贡献者的PR。原因很直接：项目面对大量低质量、AI生成的代码，需要维护者花时间审核。他在博客里问了一个很刺耳的问题：如果写代码已经是容易的部分，为什么还要别人来写？

AI辅助本身并不会让贡献失去价值。一个真正理解项目的人，用AI生成测试、整理上下文、加速实现，仍然可能提交高质量改动。鲁伊兹自己也说，他和团队会使用AI写代码。

麻烦在于，当提交门槛被降到接近零，维护者更难区分：对方是来协作的，还是只是把"垃圾"丢进审核队列。

开源贡献原本是一种关系。AI把其中一部分变成了低成本输出。真正受伤的不是某一行代码，而是维护者判断"这个人值不值得继续沟通"的信号。

这种变化不只发生在代码提交里，也发生在公共知识系统里。《金融时报》提到，ChatGPT出现前，Stack Overflow每月还有超过10万个问题；最近一个月已经不到1500个，回答率也从过去约80% 降到一半左右。

以前开发者遇到问题，会搜索、提问、解释自己卡在哪里，然后等别人回答。那些问答后来变成公共知识，下一批人搜索时还能看到上下文、争论、替代方案和踩坑记录。现在，越来越多问题被丢进私有聊天框。用户拿到了答案，平台拿到了互动数据，但公共知识库没有同步增长。

开源维护者面对的是输入端的堵塞：低质量提交变多；Stack Overflow面对的是输出端的萎缩：公共问答变少。 一个是审核负担上升，一个是公共知识积累下降，但背后都是同一件事：AI把过去发生在公共社区里的互动，转移到了私人模型对话或维护者队列里。

《金融时报》提到的预印本论文《氛围编程正在杀死开源》（Vibe CodingKills Open Source）也在讨论类似风险。它把问题放进一个经济模型里看：如果AI智能体成为开源包的主要消费者，而人类用户不再阅读文档、报告漏洞或参与讨论，维护者过去获得声誉、反馈和机会的机制会被削弱。

产品能力越像贡献者，产品责任越像贡献者

这种变化先体现在产品能力上：AI编程工具开始接手更长、更完整的编程任务。

GitHub去年介绍Copilot编程智能体时，用户已经可以把issue分配给Copilot，让它在后台运行、推送提交，并创建draft pull request（草稿拉取请求）。Anthropic的Claude Code也在向长任务推进。Anthropic研究页称，GitHub项目中出现编程智能体活动的比例，自2025年末以来已经翻倍；Claude Code用户每周平均使用约20小时。

OpenAI对Codex的描述同样如此。OpenAI 6月25日发布的文章称，智能体把知识工作的单位从单次互动，变成可以委托的长任务。到2026年5月，抽样个人用户中，80.6% 至少发起过一次估计超过30分钟人工工作量的Codex请求，25.6% 发起过超过八小时的请求。

当一个工具只是帮用户写几行代码，用户可以自己决定要不要用、要不要提交。但如果工具自己接issue、自己改仓库、自己把结果送进GitHub PR、Jira工单、Slack工作流和团队审核流程，它的输出就会占用别人的时间。

一个pull request不是点开看一眼就完事。维护者要判断需求是否合理、是否符合项目方向；要看代码有没有破坏兼容性；要跑测试；要复现问题；要解释为什么不能合并。

AI生成的低质量代码还常常不是一眼假的。它可能语法正确，也可能通过局部测试，甚至变量名和注释都很像样。但它未必理解项目长期维护里的那些旧账：有些API不能随便改，有些路径要兼容旧版本，有些看似简单的修复会影响其他平台。

写代码的成本降了，判断这些代码该不该进入项目的成本没有跟着降。

问题不在AI，而在成本转嫁

下一阶段，AI编程工具应该比拼的，不只是写得快，而是谁能减少审核成本。

一个好的AI编程工具，不应该只是生成更多代码，而应该让别人更容易判断这些代码能不能用。 它要清楚说明改了什么、为什么改、影响范围在哪里；要自动跑相关测试，而不是只贴一段"应该能工作"的说明；要把不确定的地方标出来；要让维护者能快速回滚、快速定位、快速拒绝。

GitHub在Copilot编程智能体的官方介绍里强调，智能体的PR需要人工批准后才能运行CI/CD工作流，也强调现有分支保护规则仍会生效。平台已经开始给自动提交代码加护栏，但开源社区面对的情况更复杂。CI只能告诉你一部分"会不会坏"，不能告诉你"该不该合并"。

维护者也应该被放进产品设计里。工具厂商要处理提交前责任：AI工具要不要先读取CONTRIBUTING文件、issue模板、测试说明和维护者偏好？平台要给维护者更强的过滤权：能不能标记AI生成贡献、限制新账号批量提交、要求提交者附上测试证据，甚至给项目提供一键关闭或限流AI PR的设置？

弱工具生成的垃圾很容易被识别，强工具生成的半成品才最消耗人。

AI编程工具不会因为开源维护者抱怨就停下来。GitHub、Anthropic、OpenAI都在把编程智能体往更长任务、更自动化、更接近真实工作流的方向推。这条路大概率不会回头。开发者也确实会继续用这些工具，因为它们能节省时间，能处理重复任务，也能让非专业开发者完成过去做不了的技术工作。

问题不是AI该不该写代码，而是它写完之后，谁承担后果。

如果一个工具让用户五分钟生成一个PR，却让维护者花三十分钟判断为什么它不该合并，那更像成本转移，而不是生产力提升。如果一个工具能生成代码，也能解释变更、补齐测试、尊重项目规则、减少审核负担，它才更接近真正的协作者。

生成变得便宜以后，审核就会变贵。

《金融时报》文章最后回到"维护"。斯滕伯格说，对任何项目来说，第一次写代码从来不是问题；真正的挑战，是长期维护、长期修bug。如果你不理解代码，就只能继续依赖AI去修后面所有问题。

这句话可以当作今天AI编程工具的警告。AI最擅长放大创建。 它让更多人能写代码、提需求、造应用、生成PR。但软件世界真正难的，往往不是创建，而是维护：理解旧代码，修复边缘问题，守住兼容性，拒绝不该合并的改动，在几年后还能知道当初为什么这么写。

AI编程工具真正要跨过的门槛，不是写出更多代码，而是写出别人愿意审核、敢于合并、以后还能维护的代码。