作者呼吁停止用AI批量生成开源贡献记录来装饰简历,讨论了AI slop对开源生态的侵蚀及识别方法。程序员作为贡献者或维护者均直接受影响。
对开源项目的成功贡献是一种特殊的货币。GitHub 尤其通过多种方式在鼓励这种行为:它会在仓库页面展示贡献者的头像,会通过动态订阅向你的粉丝展示你的贡献,会在你个人主页的活动图中显示每日贡献数。潜在的招聘经理经常关注这些。招聘人员也经常通过这种方式寻找和筛选候选人。如果你是一名(在职或求职中的)软件开发人员,优化这些信号往往能为你带来优势。
作为一名开源项目维护者,我可以明显察觉到过去一年外部贡献模式的变化。我们收到 pull request 的频率远高于 issue。如果我们确实收到 issue,它们往往附带着 AI 生成的分析。我们收到的安全漏洞报告比以往多得多,而且经常还附带着 AI 生成的修复方案。
我并不怀疑这些贡献中有一部分确实来自对我们的项目真正感兴趣的人,但讽刺的一面让我相信,其中很大一部分是人们意识到 AI 可以被用来为自己在 GitHub 上刷存在感。现在很容易做到:让 Claude 生成一份有趣的开源项目列表,然后让 Claude 找出其中的一些问题,再让 Claude 提出一些 PR 来修复它们。你甚至不需要真正使用这些项目,也不需要关心它们,但你完全可以对外制造出一种你关心、你发现问题、你投入时间修复的假象。在互联网上,没人知道你是条狗,但借助 LLM,你可以毫不费力地让你的 GitHub 个人资料夸大你的人类能力。
最近,一位从 2018 年底到几周前在 GitHub 上几乎没有任何贡献、与我们的项目也没有任何已知交集的贡献者,提交了三个独立的 PR 来修正注释中的拼写和语法错误。Claude 做了这些修改,大概也写了 PR 的描述,甚至还代表用户签署了提交,并在提交信息的 trailer 中插入了它的共同作者身份。谁知道它是不是自己开的 PR 呢。我非常想知道,初始 prompt 是“去找问题”还是特别针对拼写和语法问题。
这些更改无害且正确,但这并没有让我对接受或合并它们感到更好。相反,我忍不住问自己:为什么是这个,为什么是现在?为什么在所有的问题、TODO 和 FIXME 中,他们偏偏提交了这些?然后我突然意识到,这些贡献根本就不是关于我们的项目的。
我关闭了所有三个 PR,没有留下任何评论。
也许这不合理,但说实话,我只是对鼓励人们用这种杂活来浪费我们的时间不感兴趣。我不想开一个先例,去接受那些实际上没有任何实质改善的 PR,也不希望我们的贡献者列表变成让机器人改错字的奖励。
同样的模式也出现在安全漏洞报告中。传统上 CVE 会归功于其报告者,但我们最近收到的所有报告显然都是 AI 生成的。当然,安全修复总是重要的,但我不禁再次怀疑,这是因为人们真正关心这些修复,还是因为他们在寻找一个轻松的 credit。我们最近在评估此类报告的严重程度时已经变得更加挑剔,在某些情况下,甚至拒绝为低严重级别的项目发布 CVE 通知。关于私下披露正在消亡这件事,我有一些看法,也许改天会写出来,但协调私下修复、披露通知和发布版本所涉及的工作量已经大到要求我们必须有所取舍。
归根结底,开源是建立在信任之上的。重要的指标不是你能让 LLM 生成多少个 pull request,也不是你能积累多少个 CVE,而是你能否真正让一个项目变得更好。如果你想要为开源项目做贡献,就因为你在乎而贡献。如果你要的只是又一个绿色格子或又一个贡献者徽章,请去别处。