AI 带来的思考

2025-12-19

我属于比较后知后觉的那一类人，所以第一次在博客中写和 AI 有关的话题时，已经是 2025 年的年末了。

我的 AI 体验之旅

我最早接触 AI 是从 ChatGPT 开始的，大概在 2024 年，算是入坑相当地晚了。等到身边的人都已经在讨论 ChatGPT 的时候，我才开始去了解它。那个阶段，我已经隐约能感受到 AI 的威力了。

我意识到，它对 Google 构成了一定威胁。一个很直观的变化是：如今在不少场景下，我会直接去问 ChatGPT，而不是通过 Google 搜索。当然，Google 不是百度，它的护城河依然很深，搜索也并不是它唯一的支柱。

我喜欢和 ChatGPT 聊一些知识性的话题，大多数时候它都能进行不错的交流，但偶尔也会一本正经地胡说八道。我曾跟它说过，隔壁的 Gemini 相比之下更像一个理工男，表达准确、克制而理性；而 ChatGPT 更倾向于顺着用户的情绪说话，或者说是“见人说人话，见鬼说鬼话”。但从纯聊天体验来说，ChatGPT 确实更舒服一些。

第一次真正被 AI 的能力震撼到，是在今年 2 月份。我第一次体验了 Cursor，也就是所谓 vibe coding 的概念。我让它分析我个人项目 cora 中的 GC 模块。老实说，这是我写过的最复杂的模块之一，而它居然能够完整地理解这份实现。

当时我既震惊又兴奋，直接发了一条朋友圈：“已经沦落到叫 AI 教我写代码了，这使用体验简直吹爆。” 顺便，我也问了它一句：“AI 写代码会代替人类吗？”由于朋友圈记录还在，我把它当时的回答原封不动地贴在这里：

这是个很好的问题。基于我的观察和理解，AI 写代码在短期内不会完全代替人类，原因如下：

1. 理解和设计能力的局限

• 就像我们刚才分析 GC 实现时，我能理解和评价已有的设计，但很难独立设计出这样精巧的系统
• AI 更擅长处理明确、具体的任务，而不是从零开始的系统设计
• 复杂系统需要深入理解业务需求，并权衡各种设计决策，这仍需要人类的判断

2. 代码质量和可靠性

• AI 生成的代码需要人类审查和验证
• 在关键系统中，我们需要对代码的正确性有充分把握
• AI 可能会生成看似合理但存在潜在问题的代码

3. AI 更适合作为助手

• 帮助编写样板代码
• 提供代码建议和改进方案
• 辅助代码审查
• 回答具体的技术问题

4. 编程的本质

• 编程不仅仅是写代码，更是解决问题的过程
• 需要创造性思维和工程判断
• 需要与团队协作和沟通 我认为 AI 会成为强大的编程助手，提高开发效率，但不会完全取代程序员。就像我们之间的对话，AI 可以帮助优化和改进代码，但关键的设计决策和创新仍然需要人类完成。

接下来，我让它帮我清理和优化了一下代码。它很快给出了一版修改，我简单 review 后就直接 commit 了。 事后证明，这个 commit 引入了 bug。debug 的时间远远超过了它“帮我改代码”的时间：它修改代码只花了 1 分钟，而我 debug 却花了 1 个多小时，最后甚至放弃了，直接 revert 掉了这次修改。

这让我清楚地意识到了 vibe coding 当前的能力边界。

我应该准备更多的测试，用它们来阻止 AI 把代码改坏；或者干脆让 AI 去帮我补测试，这才是它更合适的应用场景。而让它去 debug 一个垃圾回收器的实现，去定位那种“内存早就坏了，但很久之后才暴露出来”的问题（比如这些问题），对它来说仍然是地狱难度。

所以，要真正发挥 AI 的优势，比较合理的方式是： 小改动、及时保存，多写测试，用测试来阻断错误的引入。

6 月份的时候，因为工作原因，我再次接触了 Rust 语言。我发现 AI 在学习语言这件事上非常有帮助：编译报错怎么理解、工具该怎么用，基本都可以直接问 AI。相比十年前，Rust 的学习门槛被显著降低了。

由于我对 Rust 本身谈不上特别喜欢，我也顺便看了一下 Zig、C3、Odin 等同一生态位的语言。一个明显的现象是：AI 在生成像 Odin 这样相对新的语言代码时，效果明显更差，幻觉也更严重，经常会把其他语言里的特性或 API 误认为是 Odin 的。而对于 Rust、C 这些已经存在多年的成熟语言，问题则要少得多。

这让我开始思考：什么样的语言更适合 AI？

一个有点反直觉的结论是：编程语言本身似乎没那么重要了。让 AI 生成 C、Rust 或 Go，其实都没有太大区别。自然语言反而成了更高一层的“编程语言”。

想想汇编、COBOL、Lisp，这些曾经重要的语言都在慢慢淡出主流。现在还有多少人在写汇编？除非是极其特殊的场景。COBOL 也是如此，除了维护上古系统，几乎不会有新的软件再用它来开发。

意识到这一点之后，我反而觉得：新语言成功的机会正在变得更小，而老语言在 AI 的加持下，幻觉更少、反而更具优势。过去决定开发效率的因素——对语言的熟悉程度、语言抽象层次的高低、生态是否丰富——正在被弱化。“古法编程”的效率，在 AI 时代已经不再重要了。键盘敲得再快，也不可能快过 AI。

符合时代的编程方式，逐渐变成了：写 spec → 生成代码 → debug。

正如当年从汇编进化到高级语言一样，如今 AI 能把自然语言描述直接转成代码，这很可能是同样的趋势。

在 AI 之前，Emacs 一直是我的主力编辑器。但我逐渐觉得，Emacs 像是一艘终将驶向沉没的大船。去年我短暂切换到 Neovim，又切回了 Emacs。

切换的原因很简单：我需要一个生态更活跃、用户更广泛、同时又有能力替代 Emacs 的编辑器，不想跟着一艘老船一起下沉。Neovim 看起来是一个合格的候选。

但后来切回 Emacs，是因为我发现：无论是用 Neovim 还是 Emacs，我的使用习惯几乎没有变化。我只是把 Neovim 配置成了 Emacs 的使用方式，它并没有真正带来改变。这就像是已经掌握了一门语言，却用这门语言的思维方式去写另一门语言——是学不会新语言的。

今年有一个契机：我需要给 Emacs 配 Rust 的开发环境，但中间总是遇到各种问题，比如 LSP 和终端下执行 make 时的文件锁冲突、Rust 编译缓存无法复用导致的编译变慢。这些问题当然都能解决，毕竟 Emacs 和 Neovim 的核心卖点就是“可定制”，但我已经不想再折腾了。

我开始想要一个真正开箱即用、不需要反复配置的工具。再加上这是 AI 的时代，我希望编辑器能更好地顺应 AI 的能力，于是今年我用了 Zed 好几个月。

Zed 确实很方便，开箱即用，也能整合 AI。但我对它并没有太多感情，也不认为它会是我的终点。我更多是把它当成一个 IDE 来用（这里是贬义）。在 Emacs 里，终端是内置的 buffer，可以用同一套快捷键，evil 模式也能无缝工作；而在 Zed 里，这种体验是割裂的，以至于我干脆不用它内置的终端，而是通过 Alt+Tab 切回系统终端。

Cursor 我也只短暂试用过，并没有真正把它当作主力编辑器。它更多是让我理解了 vibe coding 的概念。最近我又切换到了 Kiro，但我也不认为它会是终点。

后来我发现了 ad 这个编辑器，它是 acme + vim + sam 的结合体，几乎就是我理想中的形态。

Emacs 和 Neovim 属于“可扩展”的编辑器，通过 Elisp 或 Lua 插件把自己扩展成一个无所不能的系统。而 ad 更接近“可组合”的编辑器：它继承了 Unix 的哲学，由许多正交的小工具协作完成复杂任务。这与 Emacs 那种同进程内扩展的模式，是完全不同的思路。

我曾经使用过一段时间的 acme，它的理念非常好，但并没有提升我的开发效率：没有代码高亮、无法纯键盘操作、严重依赖鼠标，也没有插件生态。最终，我还是放弃了它。

现在是 2025 年了。VS Code 之后，新编辑器如雨后春笋般出现，尤其是在 Rust “重写一切”的浪潮下，Zed、Helix 等一批新编辑器诞生了。Tree-sitter 和 LSP 大幅降低了实现一个基础可用编辑器的门槛，即使像 ad 这样还处在早期阶段的项目，也已经站在了巨人的肩膀上。

ad 的问题也很明显：它还非常早期，生态、插件几乎都不存在，需要自己动手、丰衣足食。它是用 Rust 实现的，而我并不会写 Rust，那怎么办？ 有 AI 啊。

AI 在 ad 这样的中小项目里非常好用。比如我想实现 Vim 里的 Ctrl-F / Ctrl-B 翻页效果，它可以直接分析代码，告诉我如何修改配置文件；而像 Ctrl-E / Ctrl-Y / Ctrl-U / Ctrl-D 这些配置文件无法实现的快捷键，它甚至可以直接改代码帮我实现。

也就是说，即使我不会写 Rust，也可以参与到这个项目的开发中。 到了 2025 年，AI 直接提 PR 已经不是什么新鲜事了。我之所以举 ad 编辑器的例子，是因为 AI 正在打破程序员之间原本由语言划分的边界。

曾经我们说 Java 程序员、C++ 程序员、Go 程序员——这些边界正在消失。上帝用语言的巴别塔让人类难以协作，而程序员用 AI 抹平了这座塔。

这个叙事本身也很有意思： 我从 Emacs 切换，是为了更好地使用 AI，于是去了 Zed； 用了 Zed / Kiro 后，又开始怀念一款理想的编辑器； 找到了 ad，但它用 Rust 实现、生态又小； 要扩展它怎么办？找 AI。

这篇文章就是用 ad 编辑器写出来的，希望未来也能把 AI 更好地集成进去。

某个周末，我看到一个给新手练手的小项目：30dayMakeCppServer，于是决定和 AI 结对编程，顺便练练手。我让 AI 帮我把这份 C++ 代码改写成 C，然后再根据我自己的编程风格，指导它进行一些清理和重构。整个过程几乎没有我自己写代码，最后的结果我上传到了这里：tcp server。

在这个过程中，我能明显感觉到，这类库的封装本身就属于 common pattern。AI 在训练过程中大概率已经无数次见过类似的代码，因此完成起来非常熟练，几乎不费什么力气。整个流程大概只花了不到 3 个小时，而这种基础库是可以长期复用的。

我在实现 cora 语言时，曾经思考过一个问题： 做一个玩具语言并不难，难的是谁来实现它的库和生态？ 没有基础库，就没有人用； 没有人用来写实际项目，就无法形成生态； 最终就只能停留在“玩具”的阶段。

因此我当时的思路是：让 cora 能够无障碍地和 C 语言交互，借用 C 的生态，类似 Lua 的定位。但后来我意识到，AI 的出现正在改变这个前提条件。基础库的实现成本已经没有过去那么高了。对于 AI 来说，JSON、网络、HTTP、解析器、数据结构这些，几乎都是重复出现过无数次的模式。

在 AI 的辅助下，用相对少的人力实现一整套基础库，不再是难以想象的事情。这也意味着，生态不再必然是小语言最大的障碍。

对习惯的改变

写代码的习惯、使用编辑器的方式，都在被 AI 潜移默化地改变。

曾经的编辑器王者 Vim 和 Emacs，靠着几十年的积累，把体验打到了 80 分。而 VS Code 出现后，把满分拉高到了 85 分，同时也直接推动了编辑器生态的发展——随便一个新手上来，就能有 70 分以上的体验。

Tree-sitter、LSP 这些组件，表面上降低了实现编辑器的门槛，但 AI 的出现几乎是直接把桌子掀了。未来的编程形态很可能会被重构，集成 AI 正在成为下一代编辑器的必选项。tab tab tab，代码就写完了。

搜索 vs ChatGPT，这个已经没什么好说的了。

AI 也在影响很多其他方面。比如以前读一篇论文，可能需要花一两天时间精读，理解之后却发现对当前要解决的问题帮助不大，收获有限。现在呢？可以先丢给 AI，让它帮忙解读一遍，再决定是否值得继续深入。

以前我觉得英语阅读能力对程序员来说非常重要。程序员需要阅读大量英文资料，优秀的程序员往往都会去外网查信息。但现在，这项能力正在迅速贬值。和 ChatGPT 沟通不需要使用外语，而它存储和整合的知识也不受语言限制。

过去中文技术内容相对贫乏，因此必须通过英文才能接触到高质量信息；而现在，ChatGPT 已经把英文世界里的高价值内容“消化”过一遍，再用中文直接喂给我们，省掉了中间的翻译和筛选过程。

我以前会刻意阅读英文原文，把这当成一种英语能力的训练。但现在再这么做，性价比已经非常低了。不如让 AI 翻译、解读，直接生成摘要和结论。信息总是爆炸的，而真正有价值、真正感兴趣的内容并不多。读中文始终比读英文更快，这样反而更高效。

效率提升带来的一些想象空间

AI 带来了效率的提升，但我发现，这种提升并不是在所有场景下都同样明显。

有些同事分享过他们使用 AI 的经验，比如用它 review PR、读写代码等。我的整体感受是：项目越大、越成熟、越复杂，AI 带来的收益就越不明显；而项目越小、越偏 demo 性质，效率提升就越显著。

对于大型公司和复杂组织来说，AI 带来的效率提升往往被组织成本抵消。举个例子：传统的开发模型中，一个人先构思整体设计，经过评审，可能还会先做一个 demo 验证想法；然后再拆解任务，让不同的人并行开发。

为什么要拆给不同的人？并不是因为这个人不会，而是因为即使他知道该怎么做，亲自完成所有 coding 也会花费太多时间。

于是，多人协作被引入来加速开发。但协作本身也有明确的流程规范和沟通成本：写测试、提 PR、review PR、反复修改 comment，以及任务之间的依赖和等待，这些都会大量抵消多人并行带来的效率优势。

那么，如果我们不再需要这种协作模式，会发生什么？

当任务可以拆得足够细，但过去我们没有能力一个人完成所有实现细节；而现在，AI 可以承担大量具体 coding 工作。 BOOM，超级程序员诞生了。

在 AI 的帮助下，10 倍生产力程序员会更容易出现。过去因为项目规模过大而必须拆解给多人完成的事情，现在有可能重新回到单人可控的范围内。这，可能才是 AI 带来效率提升的最大场景。

进一步想象，未来会不会出现大量“一人公司”？ 像 Redis 这样的项目，早期并不需要很多程序员，只需要一个顶尖的工程师。遗憾的是，Redis 被广泛使用，却并没有给 antirez 带来多少直接收益，反而是云厂商在持续吸血。

再比如 Ghostty 的作者，一个人开发终端软件。别人问他：“你们公司打算怎么盈利？不盈利怎么长期维护？” 他回答：“我银行卡里有十亿，刀乐。”

当然，写代码和把代码变成产品之间，仍然存在巨大的鸿沟。但如果 AI 带来的开发效率提升是 3～5 倍，那么原本需要 3～5 个人才能完成的开发，现在可能只需要 1 个人了。

对于一些中小项目来说，人力不再是最主要的制约因素；而对于大型软件，这种提升仍不足以构成威胁，因为大型系统的复杂度护城河并没有这么浅。

从具体项目看效率的边界

结合我自己接触的一些项目，可以更具体地看看 AI 在效率上的可能性：

• cora：一个个人业余的 Lisp 语言项目，实现方式是 transpile 到 C，因此不涉及复杂的编译优化，也不会引入 LLVM。核心设计和实现依然高度依赖人工思考，AI 对核心部分的帮助有限。但在周边库的实现上，确实有通过 AI 明显提升效率的空间。
• opendarkeden：一个二十年前的游戏项目。我一直想重写它，因为原有的开发环境已经几乎无法搭建。但由于代码规模达到百万行级别的 C++，这已经不是业余时间能完成的项目，至少需要全职一年以上的投入，又无法带来直接收益。如果有 AI 帮忙，或许能带来一些想象空间——因为目标很明确，就是代码改写和移植，制约因素主要是时间和热情。
• TiDB / TiKV：这是我用来维持生计参与的开源项目，属于大型成熟系统。这里的每个 PR 都非常明确。如果是功能开发或优化，AI 带来的效率提升大概也就 10% 左右，甚至不到 20%。在这个阶段，问题早已不是“多写点代码”就能解决的。

因此，AI 更匹配的场景，仍然是早期 demo，或者偏上层业务逻辑的系统。

对行业，乃至世界的影响

视角拉远一点，不要只盯着“写代码”这个点来看 AI 带来的变化。

AI 对初级程序员并不友好。很多初级程序员原本承担的工作，正在被 AI 快速替代。就业岗位会减少，准入门槛会上升。但每个时代都会对程序员提出不同的要求，在这个阶段，能否利用好 AI 这样的新工具，变得尤为重要。

反而，对经验丰富的程序员来说，AI 是更友好的：经验越多，越能站在更高的抽象层次去指挥 AI 干活。

Stack Overflow 在 AI 普及之后，访问量出现了断崖式下跌。程序员过去在那里提问、交流，如今很多问题直接问 AI 就能解决。

翻译类工作，几乎已经被 AI 正面击穿。

AI 在图像、视频生成领域的影响同样巨大，设计、原画等行业受到的冲击尤为明显。色色是第一生产力。著名的 P 站，其研发人员的人效比远高于传统科技公司，处理的流量规模也不亚于 Twitter、Facebook，只是视角不同，很少有人从这个方向去讨论技术问题。

AI 还可以被应用在量化交易等领域，应该已经有不少相关的开源项目出现了。

世界变化得太快，AI 发展得也太快。怎么办？ 打不过，就赶紧加入。