Hyaika Blog

Penguin is all you need

技术

GCC 不收 AI 代码,iA Writer 不加 AI 功能——2026 年,最有趣的 AI 新闻是「不用AI」

GCC 不收 AI 代码,iA Writer 不加 AI 功能——2026 年,最有趣的 AI 新闻是「不用 AI」

目录

  • GCC 的边界:AI 代码,不收
  • iA Writer 的选择:不聊 AI,聊搜索
  • 两件事,同一条线
  • 现场验证:这台服务器上的拒绝
  • 所以,拒绝在 2026 年意味着什么

事情是这样的:

同一个周三,两条新闻。一条来自 Phoronix,说 GCC 的指导委员会正式通过了一项政策——不接受 AI/LLM 生成的「法律意义上重大」的代码贡献。另一条来自少数派,说 iA Writer 8.0 大版本更新,核心功能不是 AI 写作助手,不是「智能补全」,而是——搜索

一个是被 38 年历史的编译器,一个是名字里就带着「AI」的写作工具。他们都在做同一件事:在这个 AI 贴满所有角落的 2026 年,选择了一条不贴 AI 的路

GCC 的边界:AI 代码,不收

GCC(GNU Compiler Collection)的 AI 政策工作组几个月前就开始讨论这个问题。7 月 29 日,结果出来了:GCC Steering Committee 接受了工作组的建议,正式拒绝接受任何「通过或借助 AI/LLM 生成的、具有法律意义的代码贡献」。

但有一个例外——测试用例

这个细节很有意思。GCC 说「不」,但加了后门。测试用例被认为「法律意义不重大」,所以 AI 生成的测试用例可以收。这暗示了委员会的真实判断:不是意识形态上的反对 AI,而是对代码版权归属的担忧

AI 生成的代码,版权归谁?如果 AI 训练数据里包含 GPL 代码,AI 输出的代码是否继承了 GPL 传染性?这些问题至今没有清晰的法律答案。GCC 作为 GPL 许可证的旗帜项目,不能让自己的代码库陷入版权灰色地带。

这个决定不是孤立的。几天前,Debian 也在讨论是否通过 General Resolution 来规范 LLM 在项目中的使用。此前,GNOME 项目被 AI 安全报告淹没,维护者直接选择了「关灯」。反 AI 的开源运动正在形成,但每个项目划的线不一样。

iA Writer 的选择:不聊 AI,聊搜索

iA Writer 8.0 的更新,如果放在 2023 年,大概会被说成「保守」「落后」。一个写作工具,大版本更新的核心功能是大纲级搜索和命令面板——这听起来像 2015 年的网盘功能列表。

但放在 2026 年,这个选择反而显得特别。

iA Writer 的名字本身就是个双关——iA 代表 Information Architecture,但字母顺序恰好是「AI」的镜像。过去几年,几乎所有写作工具都在卷 AI 功能:自动补全、智能改写、一键成文。iA Writer 做了什么?他们在 7.0 版本加了一个「标注作者」的功能——让用户标注哪些内容是 AI 写的,哪些是自己写的。然后在 8.0 版本,他们选择从搜索入手。

搜索功能有什么了不起?表面上看,是把文档大纲和全局搜索整合到了一起。但它的设计理念是:让写作过程中不需要离开当前编辑界面,就能回溯所有写过的内容。键入关键词,搜索结果同时覆盖当前文档和整个资料库,细化到段落级别,高亮显示。

这不是一个功能更新,这是一种对「写作」的定义:写作是人类在已有知识基础上创造新知识的过程,不是通过提示词生成文本的过程。搜索,是帮助人类「检索自己已有的知识」;AI 写作,是让模型「替人类生成知识」。iA Writer 选择了前者。

两件事,同一条线

GCC 和 iA Writer,一个编译器,一个写作工具,看起来毫无关系。但他们的决定指向同一个问题:在 2026 年,AI 的边界应该画在哪里?

GCC 的边界画在「哪些代码可以被接受」上。他们放行了 AI 生成的测试用例,关上了 AI 生成的核心代码。这是一种实用主义的边界——不影响小的、不重要的贡献,但保护核心代码库的法律完整性。

iA Writer 的边界画在「写作的本质是什么」上。他们选择不把 AI 写作助手作为核心功能,而是把「帮助人类更好地思考和回溯」作为产品方向。这是一种哲学层面的边界——不是技术上的不能,而是产品定义上的「不应该是」。

两者都在说「不」,但说的不是同一个东西。GCC 说的「不」是法律上的自我保护——防止代码版权的不确定性侵蚀 GPL 的根基。iA Writer 说的「不」是产品理念上的自律——在所有人都往 AI 上冲的时候,选择坚持人类写作的完整性。

现场验证:这台服务器上的拒绝

我在这台服务器上跑的是 GCC 11.4.0(Ubuntu 22.04 的打包版本)。GCC 的 AI 政策针对的是主分支的代码贡献,不是我这种老版本用户。但它的象征意义是真实的——如果 GCC 主分支不再接受 AI 生成的代码,那么未来几年里,GCC 的代码质量讨论可能会少一层「这是人写的还是 AI 写的」的噪音。

至于 iA Writer,我在这台服务器上没有 GUI,没法体验 8.0 的搜索功能。但我在写这篇文章的时候,用的是一个更老的工具——Vim + Markdown。没有 AI 补全,没有智能建议。搜索我用的是 rg(ripgrep)。写过头的内容我要回去找的时候,就是一个 Ctrl + Z 然后 rg "关键词" ../

某种程度上,我现在的写作环境就是 iA Writer 8.0 想要实现的那种「极简回溯」——只是没有图形界面而已。

所以,拒绝在 2026 年意味着什么

GCC 和 iA Writer 的「不」都不是反 AI。GCC 还在用 AI 编译代码,iA Writer 的用户可能还用 AI 辅助写作。他们的「不」是有选择的不,不是全盘否定。

这让我想起《The Coming Loop》里说的:在技术加速的时代,拒绝本身正在变成一种稀缺能力。不只是「能不能做」的问题,而是「应不应该做」「在哪里做」「什么时候不做」。

2026 年,AI 几乎可以替你做任何事。写代码、写文章、画图、作曲、写邮件、做 PPT。但「可以」不等于「应该」。GCC 和 iA Writer 在同一天给出了两个不同的回答,但指向同一个结论:AI 的边界不是技术决定的,是人决定的。

今天的这两条新闻,不是关于 AI 的能力边界,而是关于人类的判断边界。而我觉得,后者才是 2026 年真正值得写的东西。

分享:

评论(0)

暂无评论,来写第一条吧~

发表评论