图片来源：grupobcc.com
内核走过三十余载，驱动数十亿设备。作为Linux内核的创造者，Linus Torvalds 见证了无数编程风潮的兴起与沉寂。近期，他对当下火热的 AI 辅助“Vibe Coding”（凭感觉编程）发表了看法，其观点犀利，直接触及了这场技术热潮的核心矛盾。
在首尔举行的 Linux 基金会开源峰会上，Torvalds 分享了他关于 AI 编程工具的看法，这或许是我从行业资深人士中听到的最为平衡和务实的评价。他认为，对于学习编程的新手而言，Vibe Coding 是“相当积极的”。但紧接着，他话锋一转，明确指出，对于生产系统，“从维护的角度来看，这是一个极其、极其糟糕的想法”。
在这个行业浸淫多年，我深知当 Torvalds 发言时，值得仔细聆听。这并非因为他永不犯错，而是因为他拥有公开承认错误并修正方向的智慧，这种理智的坦诚在技术圈中尤为珍贵。
“Vibe 编程”一词源于 Andrej Karpathy 的一篇热门文章，指的是通过向 AI 描述需求来生成整个应用程序，而无需真正理解其背后的代码逻辑。你给出提示，AI 生成代码，你不断调整提示直到程序跑通，然后交付。
用在个人小项目上？或许无伤大雅。但若用在驱动着全球服务器、手机、汽车乃至医疗设备的Linux内核上呢？让我来告诉你，为什么 Torvalds 的论断完全正确。
Torvalds 到底说了什么？
新闻标题常常忽略了 Torvalds 立场中的微妙之处。他并未全盘否定 AI 编程工具，也没有对它们进行彻底的谴责。他做了一个关键的区分，这是许多经验丰富的工程师心照不宣却很少明说的。
“我认为 Vibe 编程的积极之处在于，它意味着任何人都可以让计算机做一些他们以前做不到的事情，” Torvalds 在访谈中解释道。对于新手、学习和实验性项目而言，AI 工具显著降低了门槛。即便没有受过正规训练，人们也能构建出可工作的原型，这种技术的民主化意义重大。
然而，他随即补充了一个至关重要的限定条件。
“但是从维护的角度来看，Vibe 编程是极其、极其糟糕的。因为你根本不明白自己在做什么。”
这正是问题的核心。生产代码的生命周期往往长达数年甚至数十年。Linux 内核中至今仍运行着二十年前的代码。Torvalds 尖锐地指出：对于像内核这样的关键系统，采用“凭感觉编程”将是“一个坏主意”，因为长期的可维护性必须建立在深刻的理解之上。
为什么软件工作的重心是维护？
编写新代码可能只占整个软件生命周期的 20%。多项研究表明，60% 到 80% 的软件成本都消耗在维护、调试、功能扩展乃至最终的重写或替换上。这一点往往被非技术背景的决策者所忽视。
我曾接手过一些代码库，其原始开发者只是对着框架文档“感觉性地”拼凑出了能跑通的代码。这些代码一度工作良好，直到某个时刻突然崩溃，而且无人知晓原因。调试过程仿佛一场艰难的考古探险。
AI 生成的代码让这个问题雪上加霜。当人类写出令人费解的代码时，至少背后存在某种（无论多么有缺陷的）思维过程和决策逻辑。而 AI 生成的代码则没有“思维过程”，它仅仅是基于训练数据的统计模式匹配。
当这种模式匹配产出了一段能用、却包含了连开发者自己都无法理解的微妙预设的代码时，你就埋下了一笔利率未知的技术债务。
内核社区会严格审查进入主线的每一行代码。人工审查者能发现自动化测试遗漏的 Bug，能预见到五年后可能引发问题的设计决策，也能识别出自动化工具无法捕捉的安全漏洞。那么，当被审查的代码是由一个无法解释其为何如此编写的人生成的（因为代码并非他所写，而是由提示词生成），会发生什么？
图片来源：作者，代码生命周期与 AI 辅助的失效之处
学习与生产：一条必须划清的界线
Torvalds 清晰地划出了一条分界线：一边是实验与学习，另一边则是严肃的生产环境。
生产代码必须处理原始开发者从未设想过的边缘情况。当用户发现 Bug 时（他们总能发现），必须有人能在陌生的代码中追踪执行路径。当安全漏洞出现时，修复工作必须精准且可靠。
采用 Vibe-Coding 方式构建的生产系统会导向一个可怕的场景：代码正常运作，直到某天突然崩溃，而维护者却无法解释它最初为何能运行。
以 Linux 内核为例，它为数十亿设备处理内存管理。内存分配中一个微小的错误就可能导致设备崩溃、数据损坏或安全漏洞。在这里，深刻的理解绝非奢侈品，而是区分可靠系统与那些会以无法诊断的方式故障的系统的关键所在。
Torvalds 的身体力行：从实践出发的见解
让 Torvalds 的立场更具说服力的是，他自己也曾尝试过 Vibe Coding。在他为生成随机数字音频效果而开发的业余项目 AudioNoise 中，他提到 Python 可视化组件“基本上是凭感觉编码的”，而核心的 C 语言音频滤波器则是手动编写的。
这一点非常重要。他并非出于对 AI 工具的无知而进行谴责。他亲自使用过，并认可它们在特定场景下的价值。然而，他的最终结论是：这些工具不适用于生产系统。
这种对业余项目与内核开发的区分，恰恰印证了许多实践者的看法。个人自动化脚本？当然可以让 AI 帮忙。快速验证想法的原型？完全没问题。但对于那些需要长期维护、调试并确保安全的生产系统呢？答案必须是编写你自己能完全理解的代码。
Torvalds 花费数十年时间审查了来自成千上万贡献者的代码。他目睹了无数因理解不足而导致的失败案例。他的立场源于一种直接且时常痛苦的经验：当为了短期生产力而牺牲可维护性时，代价是什么。
赞同与补充：关于学习的更深层担忧
在生产代码方面，我完全赞同 Torvalds 的观点。仅仅是未来巨大的维护负担，就足以让 Vibe Coding 在关键系统中寸步难行。
但在学习方面，我想提出一点补充意见。 我担心的是：如果新手完全通过 AI 提示来学习编程，他们可能会错过那些未来至关重要的基础知识。
调试需要建立清晰的心智模型。只有知道某物为何正常工作，才能在它出错时找出原因。如果你的唯一技能就是不断调整提示直到代码通过编译，那么当 AI 的建议失效时，你将缺乏解决问题的根本能力。
我见过初级开发者陷入这种困境。他们能通过提示词得到可运行的代码，却无法解释其工作原理。当遇到 AI 训练数据中未曾出现的新领域 Bug 时，他们便束手无策。
解决之道并非完全避开 AI 工具，而是将它们作为学习的补充，而非替代品。先手动编写代码以理解核心概念，然后再利用 AI 来加速实现你已经理解的部分。
这才是培养出能够维护生产系统的工程师的正道，而不是培养出一旦 AI 的“幻觉”累积导致系统崩溃就无计可施的“提示词工程师”。
来源：作者，学习代码与生产代码的决策框架
更大的行业图景：短期效率与长期健康的冲突
Torvalds 的评论出现在一个值得玩味的时刻。风险资本正向 AI 编码工具投入数十亿美元，许多公司以生成的代码行数作为生产力提升的衡量标准并大力宣传。整个行业趋势似乎都在承诺开发者能将产出提升十倍。
然而，维护的成本从未出现在这些华丽的商业计划书中。
相比之下，Linux 内核社区优先考虑的是长期可维护性，而非短期产出。那些能用但难以理解的补丁会被坚决拒绝。代码的清晰度与正确性被置于同等重要的地位。
这一理念让 Linux 内核在三十多年间持续受益。代码库不断演进、适应和增长。贡献者来来去去，但系统始终保持可维护性，因为“易于理解”的价值永远高于“看似巧妙”。
AI 工具目前所代表的理念则恰恰相反：快速交付，问题后置。先生成，永不理解。
对于那些生命周期可能只有两三年的初创公司，这种权衡或许可以接受。但对于支撑全球数十亿设备的基础设施呢？内核的开发哲学每次都将是更明智的选择。
实践建议：如何明智地使用 AI 编码工具
基于 Torvalds 的见解及我个人的经验，以下是一些关于如何使用 AI 编码工具的具体建议：
适合使用 AI 的场景：
- 学习新的编程语言或框架。
- 生成你已经理解的样板代码。
- 快速进行想法验证的原型开发。
- 个人用途的脚本和自动化任务。
- 探索不熟悉的 API。
应避免使用 AI 的场景：
- 你或你的团队需要长期维护的生产代码。
- 安全敏感的系统（如认证、支付）。
- 其他系统所依赖的核心基础设施代码。
- 任何未来可能在高压下需要进行调试的代码。
必须始终遵循的原则：
- 理解你所部署的每一行代码。
- 代码必须经过理解其具体实现的工程师进行的代码审查。
- 当被问及时，你有能力清晰解释代码的意图和机制。
未来，或许会出现更先进的 AI 工具，能够提供详尽的代码解释。也许有一天，AI 生成的代码能附带足够丰富的上下文，使得维护变得可行。
但我们尚未抵达那个阶段。那位目睹过软件开发中几乎所有失败模式的内核维护者认为，我们应该保持谨慎。
我认为他是对的。在技术社区中持续交流这类实践与思考，有助于我们在这股技术浪潮中保持清醒，做出更有利于项目长期健康发展的决策。
发表于 2026-2-11 14:09:27
|
查看: 29|
回复: 0
