Pop!_OS：全面禁止AI生成代码
Pop!_OS bans AI-generated code from much of its codebase
System76 宣布在 Pop!_OS 及其 Cosmic 桌面环境的代码库中禁止使用 AI 生成的代码。这一决定引发了 Hacker News 社区的热烈讨论，许多开发者表示 AI 生成的代码往往导致项目难以维护，甚至变成一团乱麻。尽管有人担心这会让 Pop!_OS 在安全攻防中处于劣势，但支持者认为，作为小众项目，他们有能力坚持“全人类编写”的高标准。然而，讽刺的是，Pop!_OS 依然依赖上游如 Linux 内核等接受 AI 输入的项目。这一政策也导致部分贡献者的 PR 被拒，引发关于开源协作与 AI 工具边界的深思。
那些声称编程问题已经解决的人，显然没有真正关注现实情况。
HN 评论区
148- brink
我也发现 AI 并没有兑现许多承诺，因此我缩减了 AI 的权限。我的项目正变得无法维护，一团糟。那些声称编程问题已经解决的人，根本没在关注实际状况。
- lkramer
我有一个正在审核中的 PR 因此被关闭了。我在 VPN 的网络小部件中遇到了密码问题，曾使用 Claude 帮我识别问题并制定修复方案。我确实花了很多时间手工打磨，确保代码质量，但我尊重他们的决定，没有任何不满。不过，作为一个一直苦于找不到时间和机会为开源做贡献的人，这确实是个小小的挫折。
- sippingabonedry
完全是作秀。
你构建的操作系统基于数千个开源包，其中许多都包含 AI 生成的代码。你们会逐个审计并移除这些有问题的包吗？那对于那些一旦移除就会导致系统彻底崩溃的包呢？
- ItsMattyG
我不觉得这在攻防差距面前能行得通，毕竟随着 AI 在网络安全和发现 0day 漏洞方面越来越强……不过也许这问题够冷门，根本无关紧要？
- winrid
我在想，问题主要出在代码本身，还是 AI 撰写的 PR，以及人们用 AI 与维护者沟通？我个人直接禁止后者，我可不想和 opus 多聊一句，哈哈。
- YuechenLi
好吧，这可能会引发争议，但 LLM 的代码 token 不是免费的，我每周的配额经常在做一些重量级项目时就耗尽了。所以我不明白，为什么有人愿意自掏腰包故意提交糟糕的 PR？我倾向于相信人们的善意，除非有相反证据。因此，对于大型开源项目近乎全面禁止 LLM 生成的代码，在我看来有点过激，核心问题似乎应该是审查流程和政策需要与时俱进。
举个例子，今年早些时候，我参与了一个开源游戏引擎的开发，其中有一个从 2021 年左右就存在的文本渲染 bug，导致引擎无法投入生产使用，社区和我自己为此开发了大量变通方案。有一天我终于受够了，让 Claude 帮我调试。Claude 只用了 10 分钟就找到了 bug，修复方案仅仅是渲染器中 3 行代码的改动（没错，就三行）。
于是我写了回归测试，记录了 bug 详情，并提交了修复 PR，心想大概不到一周就能合并，然后大家都能继续推进。维护者在 PR 上的反馈还算不错，但这个 PR 却搁置了近 6 个月未合并，最后因上游的一次糟糕的 squash 操作被关闭了。我相当确定那个 bug 至今仍在。
顺便提一句，如果有人愿意用 AI 为我的 Github 项目做贡献，我会欣喜若狂。
- northstar702
这里有一个持续讨论的类似话题，来自一位 AWS 专家（前 AWS CTO）：
“显然，AI 并非在所有软件开发团队中都带来积极成果。客户问我是否应该减缓团队中 AI 的采用速度。
你会如何回应？
是？否？”
https://www.linkedin.com/feed/update/urn:li:activity:7510679...
感觉其中一部分是学习习惯的问题，即熟练掌握工具（AI 代理）本身的使用，以及围绕它的更好工作流，但 AI 目前仍不完美。
- teekert
“……许多 AI 贡献缺乏规划，对软件架构的理解也很浅显。因此，团队希望‘优先处理来自我们团队和常规贡献者的贡献’。”
听起来很合理，即便是对 LLM 的狂热用户来说也是如此。毕竟，总得划条线。这条线或许过于简单，但目前管用。