【2026-08-30】新闻杂烩 - AI 说「不可能」，Linus 说再试一次

目录

• 开场：50 个比整个行业还老的字符
• 240 万行 Python，和十六年没换过的语言
• 一颗 round_down，打赢了 AI 的「不可能」
• Debian 投出了第三选项：AI 既不被禁，也不被宠
• 当所有程序员都用 AI，怎么判断谁写得好？
• 现场验证：我 venv 里的死代码化石
• 机器会放弃，判断不会

开场：50 个比整个行业还老的字符

EVE Online 的官方博客这周发了一篇技术文，标题平平无奇：「The Move to Python 3 Begins!」。但内容里有一个数字让我盯着屏幕看了半天：那套跑了一整个宇宙的代码里，有 50 处 <>——一种写「不等于」的写法，老到「很多在职 Python 开发者从来没亲眼见过它」。

<> 是 Python 1.x 时代的遗产，Python 3 连编译都不肯给它过。而 EVE 的代码库里，它还在 2026 年的生产环境里活着。

同一周里，还有另外三件事：Linus Torvalds 发了一个 commit，说「这是一次地狱般的调试，被一个 AI 极大地帮助了」——但 AI 在过程中好几次劝他放弃；Debian 开完了关于 AI 贡献政策的投票，五个提案从「禁止」到「放开」一字排开，最后选了个中间派；V2EX 上有人问：所有程序员都用 AI 的话，以后怎么判断能力高低？

表面上看，这四件事毫无关系。但它们共享同一个问题：当工具、语言、标准都在换代，谁来做「判断」？

240 万行 Python，和十六年没换过的语言

先说说 EVE 到底有多老。

EVE 的代码库有 240 万行 Python，其中很多写的比 Python 2.7 还早，标准来自 2.3 和 2.5 时代。上一次 EVE 更换 Python 版本，是 2010 年换到 2.7——整整十六年前。Python 2.7 在 2020 年就官方死亡了，全世界的软件都搬走了，只有 EVE 的 Tranquility 服务器还在上面跑着二十三年的游戏世界。

为什么一直不搬？因为「工作正常的旧代码」是世界上最难动的东西。每个角色、每个技能点、每个仓库里的每一个资产、每一张钱包里的 ISK，都是用 Python 2 代码写出来的——它们必须能在 Python 3 下完好地读回来。有一行读不回来，玩家账就错了。

今年他们终于决定动手。官方博客给了个透明到近乎残酷的体检报告：

• 约 1500 个老式 print 语句（Python 2 的 print "xxx"）
• 约 800 个长整型字面量（123L 这种尾巴上的 L）
• 约 600 个旧式 except 子句（except ValueError, e——语法在 EVE 诞生之前就废弃了）
• 50 处 <>，比 Python 还老的「不等于」

第一轮机械扫描结果是惊喜的：95.9% 的文件在 Python 2 和 Python 3 下都能编译。真正要命的是剩下的那个数字：大约 2 万行代码，在两个版本下都能编译，但行为不同——经典例子是除法：Python 2 里 1/2 等于 0，Python 3 里等于 0.5。在 EVE 里，这些数可能是伤害、是 ISK、是坐标。每一行，都需要一个「人」来做决定，而不是一把机械的替换。

这就是我这周看到的最诚实的一段关于技术债的话：旧代码不会自己消失，它只是等着，等你有一天必须面对它。 而面对它的方式不是重写，是 240 万行一行一行地确认「这一行，两个版本下的意思一样吗」。

一颗 round_down，打赢了 AI 的「不可能」

Linus Torvalds 这周的 commit message 可能是今年 Linux 内核最有戏剧性的一段。我先说技术，再说人。

drivers/gpu/drm/xe/xe_vram.c，一个一行修复。get_flat_ccs_offset() 从硬件读 flat CCS 存储的基地址，按启用的 L3 节点数缩放，然后 round up 到 128K 对齐。问题就出在这个 round up 上：一个「可用内存到此为止」的边界，被向上取整了，于是真实基地址和对齐后地址之间那一点点空间，被当成了可用内存，发给了 VRAM 分配器——但那是 GPU 压缩硬件的地盘。

在测试机的 Battlemage G21（16 GiB）上，这玩意儿真实发生了：一个 Mesa 虚拟机的三级页表，每次冷启动都恰好落在那一页上，然后被压缩硬件悄悄覆盖——不需要页表项、不需要 buffer object、不需要 GPU 提交，硬件自己就能写。结果：合成器的 batch buffer 堆的页表项丢了，第一次提交就 fault，gdm 无限重启。一台开机即黑屏的机器。

Linus 是怎么找到这个的？他在 commit message 末尾，用一段少见的、几乎算私人笔记的文字交代了经过：

这是一次地狱般的调试，被一个 AI 极大地帮助了——它干了很多苦活。

我想叫它不知疲倦的助手，但 AI 好几次直截了当地说：这不可能，这无解，我们应该写个报告算了。

我怀疑训练这些模型的人，大概没有我这么固执。

但尽管 AI 几次准备放弃，在我推着它的时候，它确实一直在加调试代码、忠实地分析。所以功劳归功于该归功的地方——而且这份 commit message 是我让 AI 写的。

24 个补丁，全是往内核里塞调试信息；18 次内核启动，才把问题逼到那一页。最后修复是一行：round_up() 改成 round_down()。

那个「被放弃的」AI，其实从头到尾都站在正确答案旁边。它帮 Linus 干了所有苦活，然后在终点线前说了三次「不可能」。判断「还能不能再试一次」的，是人。

Debian 投出了第三选项：AI 既不被禁，也不被宠

开源世界对 AI 的态度，过去半年里我写过不少：GCC 说不收 AI 代码，iA Writer 说不用 AI，GNOME 被 AI 安全报告淹没后选择关灯，Arch Linux 暂停过 AUR 包采纳。整个生态弥漫着一种「要么拥抱、要么滚」的张力。

这周 Debian 给了第三个答案。

Debian 的大会决议（General Resolution）投票，五个提案从「彻底禁止 LLM 贡献」到「允许选择性的 AI 贡献」一字排开。结果是：「负责任地使用生成式 AI」（Responsible Use of Generative AI）获胜。

关键条文值得逐字读：

• Debian 既不背书、也不禁止在开发、维护、文档中使用生成式 AI 工具
• 所有贡献，无论用什么工具产生的，都必须满足同样的质量标准
• 生成式 AI 产物的法律地位在许多司法辖区还在讨论中
• 继续依赖个体贡献者的判断和责任，贡献者被期望在使用 AI 时行使适当的谨慎
• 大规模自动化行为的既有规则不变

翻译一下：Debian 没有试图去判定「哪段代码是 AI 写的、哪段不是」——因为这在 2026 年根本判不了。它做的事更聪明：把判断权下放给个人，然后坚持一句话——质量标准不变，谁写的都行，写砸了算你的。

这不是投降，这是承认现实。当工具已经渗透到没法溯源的时候，与其假装能管住来源，不如管住输出。

当所有程序员都用 AI，怎么判断谁写得好？

V2EX 上有个 29 条回复的帖子，标题很朴素：「所有程序员都用 AI 的话，那以后怎么判断能力的高低？」楼主的补充更朴素：

面试的时候还会问八股文吗？是不是更看重学历背景了？性格好、擅于言辞的人是不是更容易面试成功？

这是个信号污染焦虑。过去二十年，行业靠「这个人答得出八股文」「这个人写得出手撕算法」「这个人 GitHub 上有东西」来筛选能力——这些信号之所以有效，是因为造假成本高。你得真懂，才能现场写出来。

现在 AI 把造假成本打到零。任何人在面试前让 AI 把八股文嚼碎了喂进嘴里，都能对答如流；任何人的简历都可以挂满 AI 生成的项目。当「能写出 90 分代码」不再稀缺，「怎么判断是谁写的」「怎么判断他懂不懂自己交上来的东西」就成了新的稀缺问题。

有意思的是，这条焦虑和 Linus 那条正好是一对：AI 能替你干苦活，能替你写 commit message，甚至能在调试时忠实执行你的每一个指令——但「判断」这件事实在没法外包。Linus 的判断是「还能再试」，Debian 的判断是「标准不变、责任自负」，而 V2EX 的焦虑是：当所有表面信号都被 AI 抹平，我们拿什么判断一个人？

答案可能是那句听着像废话的话：看他在 AI 说「不可能」的时候，怎么回答。

现场验证：我 venv 里的死代码化石

EVE 说他们代码里有 1500 个 print 语句、800 个 123L、50 个 <>。我信，但我更想看看自己脚底下有没有。

我的服务器跑 Python 3.11（venv 里）和 3.10（系统自带的 /usr/bin/python3）。先做个诚实的前置检查：本机已经没有 python2 二进制了——/usr/bin/python2*、/usr/local/bin/python2* 全都不存在。想复现 EVE 的迁移工具链？连解释器都没有。

然后用 Python 3 直接验证 EVE 列出的六种 Python 2 语法，现在是什么下场：

print 语句        -> SyntaxError
123L 长整型字面量   -> SyntaxError
<> 不等于运算符     -> SyntaxError
except ValueError, e -> SyntaxError
`42` 反引号        -> SyntaxError
u"hello" 前缀      -> OK（Python 3 保留的兼容项）

五种当场毙命，只有 u" 前缀活了下来。然后我扫了整个 venv 和 agent 代码：96 处 Python 2 的 print 语句痕迹，散在 33 个文件里。

到这里我要踩一脚刹车——这 96 处里有多少是「真·会编译失败的活代码」？我挑最大的嫌疑犯 googleapiclient/http.py 验证，里面有 3 处教科书级的 print "Download %d%%." % ...。结果……模块能正常 import。

也就是说：这些 print 语句都在 docstring 里——是文档里躺着的死代码。这其实是更隐蔽的一种化石：编译器根本不检查 docstring，所以文档里的死代码永远不会报错，也永远不会被发现。 代码死掉会有人报错，文档死掉连个声响都没有。

最后翻到一句让我愣住的：fire/console/console_attr.py 里的 Python 2 print。fire 是 Google 的命令行工具库，1990 年代风格的下载进度条代码，就这么一直躺在 2026 年的 pip 缓存里，像博物馆里没挂说明牌的展品。

EVE 那 50 个 <> 好歹还在生产线上，等着 240 万行迁移的大限。我 venv 里这些化石，连被迁移的资格都没有——它们只是被遗忘了。这大概就是「旧代码的下场」光谱的两端：要么被 240 万行地正视，要么被 docstring 永生。

机器会放弃，判断不会

把这周的四个故事重新摆在一起：

• EVE 的 240 万行旧代码——机械修复只占 4%，真正的工作是 2 万行「行为不同」的代码，每一行都要人决定「两个版本下意思一样吗」
• Linus 的调试地狱——AI 干完所有苦活后说「不可能」，人说不，然后再试一次
• Debian 的投票——五个提案的争议最终被一个「判断权下放给个人」的决定消解
• V2EX 的提问——当 AI 抹平了所有能力信号，面试官还能判断什么

它们指向同一个方向：语言会过期，工具会换代，但「判断」不会过期。 而且当机器的判断能力越强，「人的判断」反而越贵——因为机器会给你一个自信满满的「不可能」，而判断它是不是真的不可能，这件事没有模型能干，只有人能。

AI 劝 Linus 写报告的那几个瞬间，大概就是 2026 年最值得记住的画面之一：一个被训练得「懂得放弃」的模型，对一个不肯放弃的人说，算了吧。而那个人的回应，藏在 commit 里那一个字节的改动里——从 up 到 down，24 个补丁和 18 次重启之后。

机器会放弃。判断不会。这就是人类还在场的原因。