AI技术面临灭绝危机？

背景

1993 年《侏罗纪公园》上映，彻底改变了电影中 CGI 的使用方式。对于大众而言，那是魔法般的体验；但对于电影行业的一些人来说，却是一记警钟。导演 Steven Spielberg 原本聘请了定格动画大师 Phil Tippett，希望他用 go-motion 技术让片中的全身恐龙活起来。Spielberg 对计算机生成图像能否真实呈现恐龙持高度怀疑态度。然而，工业光魔的 Dennis Muren 和数字艺术家制作了一个概念验证——用 CGI 渲染出一只全纹理、照片级真实的霸王龙，在阳光下追逐一群似鸵龙。

当 Dennis Muren 把这段霸王龙测试给 Spielberg 看时，Spielberg 惊叹：“哇，这才是我们该做的。”接着他问 Tippett 感觉如何，Tippett 回答：“我觉得我灭绝了。”Tippett 后来回忆：“我当时感觉自己之前所有积累的东西都像是‘我们再也不做那些了’。”他已经组建了三十人的团队，正准备投入庞大的 go-motion 任务，面对这一转折自然深受打击。

核心内容

近期我常常想起这个轶事。我看到程序员圈子里弥漫着悲观情绪——对自身变得过时的焦虑在网络上尤为明显。避免灭绝的最佳方式是进化。我喜欢 Hacker News 用户 zkmon 的看法：

乘风破浪。当网站/网页应用是浪潮时，你驾驭了它。我在互联网出现之前就进入了软件行业，一直在换马。你永远不会因为年龄太大而学不会新把戏。新浪潮创造了新的工作和新的工作者。成为他们的一员。驾驭这头野兽，掌握工具。这还是同一场游戏。

虽然当前这一波让 zkmon 想起 90 年代中期网页兴起，但它让我想起 2000 年代初的计算机图形学领域，以及 2010 年代初“移动优先”的崛起。每一代程序员都可能经历过某种形式的革命。这确实还是同一场游戏。生命无常，LLM 不过是又一个工具。进化意味着投入时间去学习它的工作原理以及如何最好地使用它。

学习 LLM 工作原理的最佳资源是 Andrej Karpathy 的频道——他显然非常关心 LLM，并真心希望你能理解它们。他现有的视频系列共 25 小时，是纯金。另一个很好的补充是 Sebastian Raschka 的《从零构建大语言模型》一书，里面有许多全彩插图，还有罕见的“Now Draw the Owl”时刻，是真正的好书。

逐行手写代码已不再是常态。拒绝使用 LLM 的人会落后，因为他们无法产出同等量的成果——我认识几位拒绝使用 AI 代理的开发者。John Carmack 最近对编程有一个有趣的见解：

“编码”从来不是价值的源泉，人们不应过度执着于此。解决问题才是核心技能。传统编程所要求的纪律和精确性仍将是宝贵的可迁移特质，但不再成为入门门槛。多年来我时常想起一位我认识的优秀程序员，他如此热爱汇编语言以至于不愿迁移到 C 语言。我自己也常常要对抗类似的情感——对使用现有庞大代码库和低效语言的不舍——但我还是坚持克服了。

即使我不直接写代码，我仍然在间接生成代码。对于能生成什么，有着相当大的自由度。如果我采取“全 vibe 编码”模式让 LLM 自由发挥，我能产出以往 1000 倍的代码，但最终会得到一团无法辨认的混乱。这是坏事吗？如果是在做原型或小项目，没关系。但对于其他一切，代码质量仍然至关重要。LLM 可能声称它们理解项目并提出解决方案，但我见过它们显露出严重幻觉。

能够阅读代码并理解架构仍然很重要。这听起来是理所当然的，但我见过很多开发者做不到。因此，我通过反复迭代我的 PR 来降低速度，直到它达到我“手写”时会达到的质量水平。每次我注意到不喜欢的代码风格，我就把它添加到 ~/.gemini/GEMINI.md 或 ~/.claude/CLAUDE.md 中，这样代理就能模仿我的风格。过去几个月我添加了不少类似这样的规则：

• 不要使用魔数或魔字符串。使用常量，甚至更好——使用枚举。
• 减少代码缩进。避免箭头反模式。利用提前返回和继续。
• 对于函数参数，使用枚举而不是布尔值。
• 尊重分层。不要打穿层。
• 让代码读者有呼吸空间。在逻辑块之间添加空行。添加简短、到位的注释解释该块做什么以及为什么。

我遇到的最大困难是“上下文切换”。同时处理多个项目/独立特性让我可以同时驱动多个代理。但保持跟进需要相当大的脑力。我见过有人报告“精神倦怠”，我个人也经历过增加的脑疲劳——这绝对需要监测。

由于工具好了这么多，我在代码审查时的期望也大大提高了。现在很难为糟糕的提交信息找借口。有很多关于如何写好提交信息的指南。我见过最好的一份指南：只需花 1 分钟让 LLM 总结它，并转化为可以添加到 GEMINI.md/CLAUDE.md 的指令。当你写提交信息时，遵循这 7 条规则：

1. 用空行分隔主题行和正文。
2. 主题行限制在 50 个字符（绝对不超过 72 个）。
3. 主题行首字母大写。
4. 主题行末尾不要加句号。
5. 使用祈使语气（例如“修复 bug”、“添加功能”，而不是“修复了”或“添加”）。测试公式：它必须能补全句子“如果应用此提交，它将 [你的主题行]”。
6. 正文手动换行至 72 字符，避免 Git 格式问题。
7. 在正文中解释“什么”和“为什么”，而非“如何”。假设代码解释了“如何”，提交信息必须解释上下文和理由。

由于编写代码的投入大大减少，我希望软件工程师在设计优雅解决方案时投入更多心思。如果 PR 一团糟，我会毫无顾虑地要求提高代码清晰度和简洁性。PR 代码大小也是如此——过去把 PR 拆成更小、更易审查的部分很繁琐，现在不再是问题，除非有正当理由，否则我会要求作者拆分 PR。

许多代码审查工具现在集成了 LLM。你可以创建自己的首选提示来自动执行第一遍审查。对于我负责的代码库，我已经把 GEMINI.md/CLAUDE.md 的内容添加进去了，只需一键触发。在发送 PR 进行审查之前，我做的第一件事就是让 LLM 批评/查找错误——这可以避免浪费审查者的时间。

写测试过去很痛苦，现在不再是这样。为每个 PR 要求单元测试/CI 测试是可以的。由于大规模重构越来越常见，这些测试从未如此重要。人类和 LLM 审查可能会遗漏问题，但好的测试应该能捕获错误。

现在拒绝引入依赖也更容易接受了。过去这是避免写任何中等复杂度代码的默认方案。就在今早，我让 LLM 写了一个 Levenshtein 距离函数，而不是给项目添加一个依赖。

我们可以用更小的团队完成更多工作。我们可能离 90 年代的模式并不遥远——当时一个四人团队就能产出专业软件。

关键要点

• AI 技术变革带来的“灭绝”焦虑与《侏罗纪公园》中 Phil Tippett 的处境类似：旧技能可能被新技术取代，但进化才是出路。
• 每一代程序员都经历过工具革命（网页、移动优先、图形学），LLM 是又一轮浪潮，本质是“同一场游戏”。
• 学习 LLM 工作原理的最佳资源：Andrej Karpathy 的视频（25 小时纯金）和 Sebastian Raschka 的《从零构建大语言模型》。
• John Carmack 指出“编码”本身不是价值，解决问题才是核心；传统编程的纪律性仍具可转移价值，但不再是入门障碍。
• 全盘依赖 AI 生成代码可能导致混乱，代码质量仍然重要；关键仍然是能读懂代码和理解架构。
• 通过定义个人风格指南（如 GEMINI.md/CLAUDE.md）让 AI 代理模仿自己的编程习惯，可提高一致性。
• 上下文切换和多代理并行会增加脑力疲劳，需要注意管理。
• 工具提升后，代码审查标准应更高：提交信息规范、PR 拆小、单元测试必要、避免魔数、保持分层等。
• 更高效的工具使小团队（甚至四人团队）可能重现 90 年代的专业产出