# Linux之父Vibe Coding转变：顽固派大佬的AI编程实践观察

> **来源**：[InfoQ - 活久见！连 Linux 之父等"顽固派"大佬，都在用 AI 编程了](https://www.infoq.cn/article/HXqI9KgBQDfh6QjG3E4j)\
> **作者**：木子、高允毅\
> **发布时间**：2026-01-13\
> **核心观点**：连最不吃AI编程这一套的技术大佬，也开始松动对Vibe Coding的态度，但他们的转变并非"投降"，而是有限度地认可AI在重复劳动上的效率价值。

***

## 🎯 为什么这个转变值得关注？

这不仅是"又一个大佬用AI"的新闻，而是一个**信号级别的转变**：

* ⚠️ **顽固派的松动**：Linux之父、Java之父、Redis之父曾对AI编程嗤之以鼻
* ⚠️ **边界重新划定**：他们认可的，是AI在重复劳动上的效率；他们坚守的，是人类程序员不可替代的核心价值
* ⚠️ **实用主义态度**：不是向AI"投降"，而是有限度拥抱，清醒地划定边界

***

## 📋 核心事件概述

### 🎭 事件主角

| 人物                       | 身份               | 之前态度                   | 现在转变                       |
| ------------------------ | ---------------- | ---------------------- | -------------------------- |
| **Linus Torvalds**       | Linux之父          | 对AI编程保持高度警惕，认为90%是营销炒作 | 开始亲自尝试Vibe Coding，态度"相当积极" |
| **James Gosling**        | Java之父           | 坚持手写代码，认为AI无法替代程序员     | 认可AI在文档生成和代码解释上的价值         |
| **Salvatore Sanfilippo** | Redis之父（antirez） | 固执地坚持一行行手写代码           | 公开表示"现在自己写代码已经不再明智"        |

### 📊 关键转折点

**Linus的小项目**：

* 项目名称：AudioNoise（音频采样可视化工具）
* 工具：谷歌的Antigravity（智能体优先开发平台）
* 方式：Vibe Coding
* 效果：AI主要写了Python可视化部分，核心C语言部分（数字信号处理）仍由Linus亲自编写

**项目地址**：[GitHub - torvalds/AudioNoise](https://github.com/torvalds/AudioNoise)

***

## 🔍 一、大佬们的态度转变轨迹

### 🚨 Linus Torvalds：从"90%营销炒作"到"相当积极"

#### 📉 之前的立场

**核心观点**：

> "在过去将近20年里，我并没有从事编程工作。"——并不是远离技术，而是早已从亲手写代码的人，转变成了为整个系统长期演进负责的人。

**对AI的警惕**：

* **极度厌恶过度炒作**：曾在开源峰会上直言当前关于生成式AI的讨论"**90%是行销炒作，只有10%是现实**"
* **关注重点不同**：他关注的重点不是代码写得快不快，而是**代码在多年之后是否还能被理解、维护和演进**
* **主动忽略AI热潮**：因为讨厌炒作，选择在相当长一段时间内主动忽略AI热潮

#### 📈 现在的转变

**转变过程**：

1. **初期尝试**：从"搜索+照猫画虎"开始
2. **逐步深入**：后来直接让AI写代码，甚至自定义组件
3. **效果评价**：最终效果比他手写的还要好

**现在的态度**：

> 对Vibe Coding总体持\*\*"相当积极"\*\*的态度

**边界划定**：

* ✅ **适合场景**：小项目和探索性场景
  * 进入门槛低、反馈速度快
  * 能迅速把模糊的想法变成可运行的程序
  * 用于生成样板代码、辅助脚本，或者"先跑起来看看"
* ❌ **不适合场景**：Linux内核开发
  * 稳定性、安全性和可维护性远比"写得快不快"更重要
  * 代码需要被不同年代、不同背景的维护者反复阅读、修改和重构
  * 任何一次"看起来省事"的生成式决策，都可能变成未来十年的技术债

#### 🎭 对内核社区AI补丁的清醒立场

> **问题不在于AI本身，而在于维护者是否真正理解代码、承担责任。**

在他的眼里：

* AI可以当**帮手**
* 但不能当**甩手掌柜**

### 🚨 Salvatore Sanfilippo（antirez）：从"固执手写"到"不再明智"

#### 📉 之前的立场

**核心信仰**：

* 以"**简洁、可预测**"为信仰的系统级程序员
* 固执地坚持**一行行手写代码**
* 对自动化工具保持**高度警惕**

#### 📈 戏剧性转变

**颠覆性言论**：

> "对于大多数项目而言，除非是为了娱乐，**现在自己写代码已经不再明智了**。"

**转变原因**：

* 在使用Claude Code的过程中，发现AI在极少人工干预的情况下，就能完成原本需要数周的工作
* **实打实的体验**让他改口

#### ⚖️ 对立面思考：转变是否过于激进？

**质疑角度**：

* 🤔 Redis作为系统级软件，antirez的转变是否意味着系统编程也被AI替代？
* 🤔 "不再明智"的判断是否适用于所有项目？

**但需要注意**：

* antirez的言论可能是针对**大多数项目**，而非核心系统软件
* Redis的核心代码仍需深度理解系统原理

### 🚨 James Gosling：有限度的认可

#### 📉 之前的立场

**Java之父的观点**：

* 坚持手写代码
* 认为AI无法替代程序员

#### 📈 现在的态度

**有限度的认可**：

* 认可AI在**文档生成**上的价值
* 认可AI在**代码解释**上的作用
* 认为AI更像一个**智能搜索引擎**，而非编程大神

**核心观点**：

> "AI只能复刻见过的代码，但专业软件开发的精髓，在于**开拓性的创新**——这些内容从来不在现成的代码库里。"

**对资本的吐槽**：

> "科技行业里骗子和炒作者的数量之多，令人难以置信。风险投资者只关心成功获利，而不是开发出真正有用的技术。"

**悲观预言**：

> "绝大多数AI投资都会被烧个精光。"

***

## 🔍 二、批判性分析：转变的本质

### 🧠 苏格拉底式提问

#### Q1: 这个转变暴露了什么本质问题？

**A**:

* **AI能力的边界**正在被重新认识
* **"顽固派"不是反对技术，而是反对过度炒作**
* 当工具真正成熟、噪音下降时，连最谨慎的人也愿意尝试

#### Q2: 为什么他们现在才转变？

**A**:

* **工具成熟度**：工具逐渐成熟，不再是"玩具"
* **噪音下降**：过度炒作的热潮退去，现实价值显现
* **成本效益**：实打实的效率提升，而非理论上的可能

#### Q3: 他们的转变是"投降"吗？

**A**:

* ❌ **不是投降**：他们认可的是AI在**重复劳动**上的效率
* ✅ **坚守核心**：他们坚守的是人类程序员不可替代的核心价值
* 🎯 **边界清晰**：对复杂系统的理解、对工程架构的判断、对长期维护的责任，以及开拓性的创新能力

### ⚖️ 对立面分析：转变是否意味着AI真的成熟了？

#### 🤔 挑战：这真的是技术成熟的信号吗？

**可能的反驳**：

1. **幸存者偏差**：只有成功案例被报道
2. **样本偏差**：大佬们试的都是**小项目**，不是核心系统
3. **时间窗口**：可能只是AI能力的**短暂峰值**，后续可能遇到瓶颈

**但也要考虑**：

* Linus和antirez都是**极度务实**的工程师
* 他们的转变是基于**实际使用体验**，而非理论推测
* 他们的边界划分非常清晰，不是盲目拥抱

### 🎭 魔鬼代言人：为什么这个分析可能是错的？

#### 挑战1：大佬的转变是否代表行业趋势？

**质疑**：

* 🤔 几位大佬的转变是否只是个案？
* 🤔 他们的影响力是否被高估？
* 🤔 普通开发者是否也能获得相同体验？

**反证**：

* 大佬们通常更保守，他们的转变往往意味着技术已经达到**可用性阈值**
* 但也要注意：他们的使用场景可能是**高度筛选**的

#### 挑战2：边界划分是否过于理想化？

**质疑**：

* 🤔 "重复劳动"和"核心价值"的边界是否清晰？
* 🤔 边界是否会随着AI能力提升而不断收缩？
* 🤔 今天的"不适合场景"是否明天就"适合"了？

**深度思考**：

* 边界可能是**动态的**，需要持续评估
* 但**工程原则**（可维护性、可理解性）应该是不变的
* 关键是建立**判断标准**，而非静态边界

***

## 🔍 三、深层洞察：三个层次的启示

### 🎯 技术层：AI编程的适用边界

#### ✅ 适合场景（共识）

| 场景类型      | 特点         | 代表案例               |
| --------- | ---------- | ------------------ |
| **快速原型**  | 验证想法、快速迭代  | Linus的AudioNoise项目 |
| **辅助脚本**  | 重复性任务、样板代码 | 各种自动化脚本            |
| **探索性编程** | 学习新技术、实验功能 | 新框架/库的尝试           |
| **文档生成**  | API文档、代码注释 | Gosling认可的用途       |

#### ❌ 不适合场景（共识）

| 场景类型      | 原因               | 代表案例      |
| --------- | ---------------- | --------- |
| **系统级开发** | 稳定性、安全性、可维护性要求极高 | Linux内核   |
| **核心架构**  | 需要深度理解系统原理       | Redis核心功能 |
| **长期维护**  | 代码需要被多代人理解       | 企业级核心系统   |
| **开拓性创新** | 现有代码库中没有的解决方案    | 全新的技术方案   |

### 🧠 认知层：重新理解"顽固"与"开放"

#### 🎭 重新定义"顽固派"

**传统误解**：

* "顽固派" = 拒绝新技术 = 思想保守

**真实情况**：

* "顽固派" = **极度务实** = 对炒作保持警惕
* 他们不是拒绝技术，而是**拒绝未经验证的技术**
* 他们关注的是**长期价值**，而非短期热度

#### 🔄 重新定义"开放"

**不是盲目拥抱**：

* ❌ "新技术就是好的" → 这是**技术乐观主义**
* ✅ "新技术在合适场景有价值" → 这是**技术实用主义**

**Linus的态度转变**：

* 从"90%炒作"到"相当积极"
* 不是因为AI突然变好了，而是因为：
  1. 工具成熟度提升
  2. 噪音下降，现实价值显现
  3. 找到了**适合的使用场景**

### 🏗️ 工程层：可维护性 vs 开发效率

#### ⚖️ 核心矛盾

**效率派**：

* "代码写得快不快"是首要目标
* AI能快速生成代码 = 更好

**维护派**（Linus的立场）：

* "代码在多年之后是否还能被理解、维护和演进"是首要目标
* 快速生成的代码可能带来长期技术债

#### 🎯 平衡策略

**分场景处理**：

* **探索阶段**：优先效率，快速验证想法
* **生产阶段**：优先可维护性，长期演进考虑

**Linus的实践**：

* AudioNoise项目中：
  * Python可视化部分（探索性）→ 交给AI
  * C语言核心部分（生产级）→ 自己写

***

## 📊 四、数据与观察

### 📈 关键数据点

#### 项目数据

* **AudioNoise项目**：GitHub已收获1600+ Star
* **Boris Cherny的Claude Code**：一年内完成1096次提交
* **Claude Code收入**：超过10亿美元（约合人民币70亿元）

#### 市场观察

* **资本投入**：James Gosling认为"绝大多数AI投资都会被烧个精光"
* **工具成熟度**：从"玩具"到"可用工具"的转变

### 🔍 观察角度

#### 正面观察

* ✅ **工具真正成熟**：连最谨慎的大佬也开始使用
* ✅ **边界逐渐清晰**：不是盲目拥抱，而是有边界的使用
* ✅ **实践指导价值**：大佬们的实践为行业提供参考

#### 警示观察

* ⚠️ **适用范围有限**：不适合系统级开发、核心架构
* ⚠️ **判断力更重要**：需要判断什么时候用、什么时候不用
* ⚠️ **长期影响未知**：过度依赖AI可能带来的长期影响尚未显现

***

## 💡 五、实践启示

### 🎯 对开发者的启示

#### 1️⃣ 保持务实态度

**学习Linus**：

* ✅ 不要盲目拒绝新技术
* ✅ 也不要盲目拥抱新技术
* ✅ **在合适场景尝试，验证实际价值**

#### 2️⃣ 清晰边界意识

**学习大佬们的实践**：

* ✅ **探索性项目**：可以大胆用AI，快速验证想法
* ✅ **核心系统**：保持谨慎，AI辅助而非主导
* ✅ **长期维护**：优先考虑可维护性，而非短期效率

#### 3️⃣ 持续评估标准

**建立判断框架**：

```
使用AI编程前，问自己：
1. 这个项目的长期维护需求是什么？
2. AI生成的代码是否满足可维护性要求？
3. 如果AI生成错误，是否有能力修复？
4. 这个场景是否真的需要AI？
```

### 🏗️ 对团队的启示

#### 1️⃣ 建立使用规范

**参考Linux内核社区**：

* AI生成的补丁必须经过人工审查
* 维护者必须真正理解代码
* 不能把AI当"甩手掌柜"

#### 2️⃣ 分场景制定策略

**探索 vs 生产**：

* **探索阶段**：鼓励使用AI，快速迭代
* **生产阶段**：严格控制，确保质量

#### 3️⃣ 培养判断能力

**团队能力建设**：

* 不是"会不会用AI"
* 而是"**什么时候用AI**"、"**怎么用AI**"

***

## 🚨 六、重要提醒与免责声明

### ⚠️ 信息准确性声明

1. **事件真实性**：
   * AudioNoise项目确实存在，GitHub可查
   * 但大佬们的具体言论和态度可能被媒体解读
2. **观点时效性**：
   * AI工具快速迭代，观点可能随时间变化
   * 2026年1月的观察，可能不适用于未来
3. **适用性边界**：
   * 大佬们的实践基于其**特定场景**
   * 普通开发者的使用场景可能不同
   * 需根据实际情况调整

### 🧠 批判性思维要求

1. **质疑一切结论**
   * 本文的分析也需要质疑
   * 大佬们的转变可能只是个案
   * 行业趋势需要更多数据验证
2. **验证关键信息**
   * AudioNoise项目的实际使用情况
   * 大佬们的具体言论和态度
   * AI工具在实际项目中的效果
3. **考虑对立面**
   * AI编程的优势可能被高估
   * 大佬们的转变可能被过度解读
   * 长期影响尚未显现
4. **保持开放心态**
   * AI辅助编程是新兴领域
   * 最佳实践仍在探索中
   * 适合你的方法需要自己发现

### 🎭 魔鬼代言人：为什么这个分析可能是错的？

#### 挑战1：过度解读了个案

**质疑**：

* 🤔 几位大佬的转变是否代表行业趋势？
* 🤔 他们的使用场景是否过于特殊？
* 🤔 普通开发者能否复制他们的体验？

**反证**：

* 大佬们通常是**滞后指标**（更保守）
* 他们的转变可能意味着技术已达到**可用性阈值**
* 但也要警惕：他们的资源和技术水平远超普通开发者

#### 挑战2：边界可能是动态的

**质疑**：

* 🤔 今天的"不适合"是否明天就"适合"了？
* 🤔 "核心价值"的边界是否会不断收缩？
* 🤔 人类程序员的不可替代性是否被高估？

**深度思考**：

* 边界可能是**动态演化**的
* 但**工程原则**（可维护性、可理解性）应该相对稳定
* 关键是建立**判断框架**，而非静态边界

***

## 📖 七、延伸阅读与资源

### 🔗 相关链接

#### 原文与项目

* [InfoQ原文](https://www.infoq.cn/article/HXqI9KgBQDfh6QjG3E4j)
* [GitHub - torvalds/AudioNoise](https://github.com/torvalds/AudioNoise)
* [The Register - Linus Torvalds on Vibe Coding](https://www.theregister.com/2025/11/18/linus_torvalds_vibe_coding/)
* [antirez - 关于AI编程的观点](https://antirez.com/news/158)
* [Boris Cherny - Claude Code的实践](https://x.com/bcherny/status/2009072293826453669)

#### Assemble知识库相关文档

* \[\[🤖 Vibe工程批判性观测：资深工程师与AI代理共舞]]
* \[\[🚨 Vibe Coding Hell：AI时代学习者的新困境与批判性突围]]
* \[\[🎭 氛围编程大辩论：AI代码生成器的正反博弈]]
* \[\[💼 Cursor实战万字经验：从Token优化到决策者思维的AI编程最佳实践]]
* \[\[🧠 综合批判性分析Prompt]]

### 💡 进一步思考

#### 技术层面

* Linux内核开发的实际需求与AI能力的匹配度
* 系统级编程中AI的适用边界
* 长期维护性 vs 开发效率的平衡策略

#### 认知层面

* "顽固派"转变背后的认知机制
* 技术炒作 vs 实用价值的识别方法
* 如何建立技术采用的判断框架

#### 工程层面

* AI辅助编程的最佳实践
* 代码审查中如何识别AI生成的问题
* 团队中如何平衡AI使用与技能培养

***

## 🎯 八、最终总结：三个层次的收获

### 🎯 观察层：大佬转变的信号意义

**核心洞察**：

* 连最谨慎的大佬也开始使用AI编程
* 但他们的转变是**有限度的、有边界的**
* 这可能是技术达到**可用性阈值**的信号

**反直觉认知**：

* "顽固派"不是拒绝技术，而是**拒绝炒作**
* 他们的转变不是"投降"，而是**实用主义的体现**

### 🛠️ 实践层：边界与策略

**立即可用的判断框架**：

1. **场景分类**：探索性 vs 生产级
2. **风险评估**：可维护性 vs 开发效率
3. **边界划定**：适合场景 vs 不适合场景

**分场景策略**：

* 探索阶段：大胆用AI，快速验证
* 生产阶段：谨慎使用，确保质量
* 核心系统：保持警惕，AI辅助

### 🧠 哲学层：技术与人的关系

**元问题**：

* AI时代的程序员价值在哪里？
* 工具进步是否意味着能力退化？
* 如何在效率与成长之间平衡？

**答案的方向**：

* **核心价值不变**：对复杂系统的理解、架构判断、长期维护责任、开拓性创新
* **工具角色定位**：AI是**帮手**，不是**替代者**
* **边界动态演化**：边界可能变化，但工程原则相对稳定

***

## 💡 最后的思考

> **不是向AI"投降"，而是有限度地认可AI在重复劳动上的效率；不是放弃坚守，而是重新划定边界。**

**关键不是"用不用AI"，而是**：

* 在**什么时候**用AI
* 在**什么场景**用AI
* 用AI做**什么**，不做**什么**

**Linus的态度转变告诉我们**：

* 当工具真正成熟、噪音下降时
* 即使最谨慎的人也会尝试
* 但尝试不等于盲目，**边界意识始终重要**

**最重要的是**：

* 保持**批判性思维**
* 建立**判断框架**
* 在**实践中验证**，而非理论空谈

***

**文章标签**：#VibeCoding #AI编程 #Linux #技术观察 #边界思考 #工程实践

**文章类型**：技术观察与分析\
**学习价值**：⭐⭐⭐⭐⭐\
**适用场景**：理解AI编程的适用边界、建立技术采用的判断框架、学习大佬的实践智慧

> 💡 **特别提示**：本文基于2026年1月的观察，AI工具快速迭代，观点可能随时间变化。请结合实际情况，建立自己的判断框架。

***

*本文档基于InfoQ文章，结合综合批判性分析框架深度解读。*\
\&#xNAN;*包含苏格拉底式提问、对立面分析、魔鬼代言人模式、实践启示。*\
\&#xNAN;*最后更新：2026-01-13*