System76 禁止在 COSMIC 桌面的贡献中使用 AI 生成的内容。一些 GNOME 子项目也限制 AI 生成的贡献，但有一位开发者敦促他们为漏洞报告做出例外规定。
System76 is banning AI-generated content from contributions to the COSMIC desktop. Some GNOME sub-projects also restrict AI-generated contributions, but one developer is urging them to make an exception for vulnerability reports.
COSMIC 桌面项目已更新其贡献者指南。最新版本现在包含一条明确的禁 AI 规则，要求贡献者声明：“我未在本 PR 中包含任何 LLM（也称为 AI）生成的内容，包括代码、注释和描述。” 换句话说，你可以用 AI 自学，可以用 AI 发现漏洞，但如果你想提交代码以纳入 COSMIC，就不能用 AI 编写代码、文档、注释，甚至提交请求本身。
The COSMIC desktop project has changed its contributors' guidelines. The latest version now has a clear no-AI rule, insisting that contributors declare: "I have not included any LLM (also known as AI) generated content in this PR, including code, comments, and descriptions." In other words, you can teach yourself using AI, you can find bugs with AI, but if you want to submit your code for inclusion in COSMIC, you can't use AI to write the code, its docs or notes, or even the submission requests.
这一立场与其他一些桌面项目一致。例如，GNOME Calendar 的贡献指南规定：“本项目不允许由大语言模型（LLM）和聊天机器人生成的贡献。” GNOME Extensions 也限制 AI 生成的提交，尽管它允许 AI 学习辅助和代码补全。其审查指南明确指出：“扩展不得由 AI 生成。”
This position is in keeping with some other desktop projects. For instance, the GNOME Calendar guide to contributing says: "This project does not allow contributions generated by large languages [sic] models (LLMs) and chatbots." GNOME Extensions also restricts AI-generated submissions, although it permits AI learning aids and code completion. Its review guidelines spell it out: "Extensions must not be AI-generated."
COSMIC 是最新的完整 Linux 桌面环境之一，但即便如此，它也已开发多年。我们早在近五年前就首次报道了这一项目，这意味着它比 ChatGPT 还要早，后者于 2022 年底首次亮相（感觉却像过去了很久）。
COSMIC is one of the newest complete Linux desktop environments, but even so, it's been under development for years. The first reported on the effort nearly five years ago, meaning that it's older than ChatGPT, which debuted in late 2022 (it only feels so very much longer).
COSMIC 确实使用了一些 GNOME 组件，其默认配置看起来也不像 GNOME，顶部有一个面板，底部有一个类似 Dock 的启动器。这样做有充分的理由：最初名为“COSMIC”的 System76 桌面基于 GNOME，并通过 GNOME 扩展进行了大量定制。话虽如此，这个新的 COSMIC 却是完全不同的产物。其首个稳定版随 Pop!_OS 24.04 于 2025 年底发布。尽管外观相似，但它是一个完全全新的、从头开始的项目，使用 Rust 语言和 Iced 工具包编写。COSMIC 本身仅支持 Wayland。
COSMIC does use some GNOME components, and its default config looks not unlike GNOME, with a top panel and a dock-like launcher at the bottom. There are good reasons for that: the original System76 desktop called "COSMIC" was based on GNOME, quite heavily customized with GNOME extensions. Saying that, though, this new COSMIC is a very different beast. Its first stable release shipped with Pop!_OS 24.04 in late 2025. Although it looks similar, it's an entirely new, ground-up effort, written in Rust using the Iced toolkit. COSMIC itself is Wayland-only.
GNOME 的历史更为悠久，规模也更大，其开发过程也更为复杂。该项目于 1997 年宣布启动，时间紧随 KDE 项目的发布之后（KDE 1.0 于 1998 年发布，GNOME 1.0 则于 1999 年发布）。从某种程度上说，GNOME 的诞生是对 KDE 的一种回应。KDE 是基于 Qt 工具包开发的，而 Qt 并非完全开源的；因此，在 KDE 的早期阶段，Red Hat 拒绝将其纳入 Red Hat Linux 系统中。
GNOME is much older, larger, and more complicated. The project was announced in 1997, the year after the KDE project announcement. KDE 1.0 came out in 1998, and GNOME 1.0 in 1999. In part, GNOME was a response to KDE. KDE is built on the Qt toolkit, which was not fully open source. As such, in KDE's early days, Red Hat refused to include it in Red Hat Linux.
由于 Qt 主要面向 C++ 开发者，KDE 也是用 C++ 语言编写的。而 Linux（与 Unix 一样）则是用传统的 C 语言开发的，许多 Unix 系统的忠实用户对复杂的 C++ 语言持批评态度。因此，GNOME 选择使用传统的 C 语言进行开发，并采用了专为 GIMP 开发的 GTK 工具包。1998 年，Red Hat Linux 5.1 首次包含了 GNOME 的预览版本；到了 1999 年的 Red Hat Linux 6.0 时，GNOME 1.0 已成为系统的默认桌面环境。
Qt is aimed at C++ developers, so KDE was built in C++. Linux, like Unix, is built in plain old C and many Unix traditionalists scorned the much more complex C++. So GNOME was built in plain old C, using GTK, the toolkit built for the GIMP. In 1998, Red Hat Linux 5.1 included a preview of GNOME, and by Red Hat Linux 6.0 in 1999, GNOME 1.0 was the default desktop.
时至今日，GNOME 依然是 Red Hat Enterprise Linux (RHEL) 的默认桌面环境，许多 GNOME 开发者的工作单位都在 Red Hat 公司。正如我们早在 3 月份所提到的，Red Hat 的管理层对人工智能技术表现出极大的热情——不过六个月后，该公司却限制了开发人员在人工智能相关项目上的投入。GNOME 的大部分代码都是用 C 语言编写的，这种语言缺乏自动内存安全保护机制；不过 GNOME 也使用了其他编程语言：例如，GNOME Shell 结合了 JavaScript 和 C 语言，部分组件则是用专为 GNOME 设计的 Vala 编程语言编写的。
GNOME is still the default desktop in RHEL to this day, and many GNOME developers' day jobs are at Red Hat. As we noted back in March, Red Hat management is noticeably enthusiastic about AI – although six months later, it was capping developers' AI spend. GNOME is largely written in C, which lacks automatic memory safety guarantees, although other languages feature too: GNOME Shell combines JavaScript and C, and some components are written in the GNOME-centric Vala programming language.
GNOME 开发者 Michael Catanzaro 最近发表了一篇博客文章，题为《软件质量的新时代，还是鸵鸟主义的时代？》，他在文中主张 GNOME 项目应该接受由人工智能生成的错误报告。这对他来说并不是一个新话题——他的文章还链接到了他早在 6 月份发表的另一篇文章《请不要禁止人工智能辅助生成的问题报告》。次月，他又宣布将向 GNOME 安全团队报告问题的截止时间从 90 天缩短至 30 天，该规定自 8 月 1 日起生效。
Michael Catanzaro, GNOME developer, just published a blog post titled "The Era of Software Quality, or the Era of Ostriches?" which argues that the GNOME project must accept AI-generated bug reports. This is not a new subject for him. His post links to an earlier one from June, "Please Do Not Ban AI-Assisted Issue Reports." The following month, he announced a reduction in the disclosure deadline for issues reported to GNOME Security, from 90 days to 30, effective August 1.
我们最近还报道了 Debian 最新的 Linux 内核安全公告中列出的 1,313 个安全漏洞（CVE 编号）。人工智能技术正在帮助人们在现代开源软件（FOSS）庞大的代码库中发现大量漏洞。
We recently reported on the 1,313 CVE identifiers listed in Debian's latest Linux kernel security advisory. AI is resulting in the discovery of vast numbers of bugs in the equally vast codebases of modern FOSS.
GNOME堪称Linux与BSD生态圈中规模最大的桌面环境项目，但其大部分代码均是用内存安全性较差的编程语言编写的。正如卡坦扎罗所言：“无论我们如何努力，使用C、C++或Vala这类安全性欠佳的编程语言时，GNOME开发者都难以编写出安全的代码——即便是经验丰富的开发者也极难做到这一点。”我们并不认为卡坦扎罗的观点有误。
GNOME is one of the biggest desktops in the Linux and BSD world, with much of its code written in memory-unsafe languages. As Catanzaro says: "No matter how much we try, GNOME developers will fail [to] write secure code when using unsafe languages like C, C++, or Vala: it's just too hard for even experienced developers to do properly." We are not arguing that Catanzaro is wrong.
考虑到GNOME最大赞助商对人工智能的态度，他的主张完全合乎情理，且论据充分。我们只是想指出：在红帽公司的强力支持下，此举或许会成为引发一系列变革的契机。起初，该项目允许使用人工智能生成漏洞报告；随后，引入人工智能辅助漏洞分类也顺理成章；再往后便是人工智能辅助修复代码。一旦允许人工智能参与代码编写，那么人工智能辅助开发扩展模块也就不足为奇了，进而可能波及核心组件，最终甚至影响到整个桌面环境。
Given the stance toward AI of GNOME's biggest sponsor, it is entirely in keeping, and he makes a strong case. All we are noting is that this could in time prove to be the thin edge of a wedge with the weight of Red Hat behind it. First the project allows AI-generated bug reports. From there, it would not be a huge step to allowing AI-assisted triage. From there, to AI-assisted fixes. Once you're letting AI-assisted code in, then AI-assisted extensions may not seem so extreme, then core components, and in time, to the desktop itself.
这种做法极具争议性，KDE项目中早已出现类似争论。但这并不代表这种情况不会发生——无论在哪个项目中。Debian已决定允许此类做法，内核开发同样如此。®
It would be wildly controversial, just as it already is in the KDE project. That doesn't mean it won't happen – in either project. Debian decided to allow it, and of course, the kernel itself does too. ®