别怕淘汰，进化为上

1993年，《侏罗纪公园》上映，彻底革新了CGI（计算机生成图像）在电影中的应用[1]。在观众眼中，这是一场魔法般的体验；但对电影行业里的某些人而言，这无异于一记当头棒喝。

导演史蒂文·斯皮尔伯格曾聘请定格动画大师[2]菲尔·蒂皮特负责特效制作。蒂皮特回忆道：

我和视觉特效总监丹尼斯·穆伦一起去给史蒂文展示霸王龙的CGI测试片段，史蒂文看完说："哇，我们就这么干！"然后他问我感受如何，我说："感觉自己要被淘汰了。" .[5]那一刻我突然意识到，我之前积累的所有手艺，好像都用不上了。 菲尔·蒂皮特.[6]

当时蒂皮特已经组建了一支30人的团队，正全力筹备大型逐格动画（go-motion）项目，这场变故对他的打击可想而知。——《侏罗纪公园制作幕后》(https://www.amazon.com/Making-Jurassic-Park-Don-Shay/dp/034538122X)

最近我常常想起这段轶事。我看到程序员群体中弥漫着浓重的悲观情绪，对"被淘汰"的焦虑在网络上尤为明显。

避免被淘汰的最佳途径，是主动进化。我很认同Hacker News用户zkmon的观点：

要学会乘势而上。当年网站和网页应用兴起时，你抓住了浪潮；我入行比互联网普及还早，一路不断转型。学习永远不嫌晚。新技术浪潮会催生新的工作内容和从业者，要努力成为其中一员。驾驭技术，掌握工具，游戏规则从未改变。 zkmon（Hacker News）(https://news.ycombinator.com/item?id=48435521)

zkmon把当下的局面比作90年代中期的互联网浪潮，而我却联想到2000年代初计算机图形学的变革，以及2010年代初"移动优先"理念的崛起。每一代程序员都可能经历一场技术革命，这确实是"游戏规则从未改变"。万物皆流[10]，大语言模型（LLM）不过是又一种工具。进化，就是花时间去理解它的原理，掌握它的最佳用法。

我发现学习LLM原理的最佳资源是Andrej Karpathy的频道。这位博主显然对LLM抱有极大热情，真心希望观众能理解这门技术。他已更新的系列视频总长25小时，内容含金量极高。

看完视频后，推荐接着读Sebastian Raschka所著的《从零构建大语言模型》(https://www.amazon.com/dp/1633437167?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_31)。书中配有大量全彩图示，还有不少难得的"手把手实操"（Now Draw the Owl）环节，是一本非常优秀的入门读物。

如今，手写每一行代码早已不是常态。拒绝使用LLM的人会逐渐落后，因为他们的产出效率无法跟上——我就认识好几位拒绝使用AI编程助手的开发者。约翰·卡马克最近对编程发表了一番有趣的见解：

"编写代码"从来都不是价值的核心，人们不应过度执着于此。解决问题才是核心技能。传统编程所要求的严谨性和精准度，依然是可迁移的宝贵能力，但它们不再是入行的门槛。 这些年来我常想起一位优秀的程序员，他痴迷于汇编语言，坚决不愿转向C语言。我自己也对使用大型现有代码库和低效语言有过类似抵触，但我还是强迫自己跨过去了。 约翰·卡马克(https://x.com/ID_AA_Carmack/status/1762110222321975442)

即便我不再亲手写代码，也依然在间接产出代码。而生成什么代码，完全由我掌控。如果我完全依赖LLM的"感觉式编码"，产出量能达到过去的1000倍，但得到的往往是一堆难以理解的混乱代码。这算坏事吗？如果是做原型或小型个人项目，倒也无所谓；但在其他场景下，代码质量依然至关重要。LLM可能会声称理解项目逻辑并给出解决方案，但我见过它彻底失败、甚至生成幻觉内容的情况。

能够阅读代码、理解架构，这一点依然重要。听起来是理所当然，但我见过很多开发者做不到这一点。因此，我会反复迭代自己的PR（代码提交请求），直到它达到我亲手编写时的质量标准，哪怕这会降低我的效率。每次发现我不喜欢的代码风格，我都会把对应的规则添加到~/.gemini/GEMINI.md或~/.claude/CLAUDE.md中，让AI助手模仿我的风格。过去几个月里，我已经添加了不少类似规则：

• 不要使用魔法数字或魔法字符串，尽量用常量，合适的情况下用枚举。
• 减少代码缩进，避免箭头反模式，善用提前返回和continue语句。
• 函数参数用枚举而非布尔值。
• 遵守分层架构，不要跨层调用。
• 给代码阅读者留出呼吸空间，逻辑块之间加空行，添加简短精准的注释说明代码块的功能和设计意图。

我遇到的最大困难是"上下文切换"。同时负责多个项目或独立功能时，我需要同时驱动多个AI助手，这对脑力是极大的考验。我看到过关于"精神 burnout（倦怠）"的报道，自己也确实感到脑力消耗大幅增加，这绝对是需要警惕的问题。

工具变得如此强大，我对代码评审的要求也随之提高。

现在，提交信息（commit messages）写得差几乎找不到借口。网上有很多关于如何写好提交信息的指南，这篇是我见过最好的。只需花1分钟让LLM总结内容，转化为可添加到GEMINI.md/CLAUDE.md中的指令即可。

撰写提交信息请遵循以下7条规则：
规则1：主题行与正文之间用一个空行分隔。
规则2：主题行长度限制在50字符以内（72字符为绝对上限）。
规则3：主题行首字母大写。
规则4：主题行末尾不加句号。
规则5：主题行使用祈使语气（例如："修复bug"、"新增功能"，而非"已修复"或"新增了"）。测试方法：主题行应能完成这句话："如果应用本次提交，它将[你的主题行内容]"。
规则6：正文手动换行，每行不超过72字符，避免Git格式问题。
规则7：正文用于说明"做了什么"和"为什么这么做"，而非"怎么做"。默认代码本身已说明实现方式，提交信息需补充背景和设计思路。

既然编写代码的门槛大幅降低，我期望软件工程师（SWE）能更用心地设计优雅的解决方案。如果PR一团糟，我会毫不客气地要求开发者提升代码清晰度和简洁性。

PR的代码量也是如此。过去把PR拆分成更小、更易评审的部分很繁琐，现在则完全不是问题。除非有充分理由，否则我会要求开发者拆分PR。

如今很多代码评审工具都集成了LLM，你可以自定义提示词，让它自动完成第一轮评审。对于我维护的代码库，我把GEMINI.md/CLAUDE.md中的规则导入了工具，一键即可触发评审。在提交PR之前，我做的第一件事就是让LLM挑错、提出批评，避免浪费评审者的时间。

编写测试用例曾是件苦差事，现在则不然。要求每个PR都附带单元测试/CI测试完全合理。随着大规模重构越来越普遍，测试的重要性前所未有。人工和LLM评审都可能遗漏问题，但完善的测试应该能捕捉到功能损坏的情况。

现在更有理由拒绝引入外部依赖。过去，为了避免编写稍微复杂一点的代码，引入依赖是常见做法。就在今天早上，我还让LLM写了一个Levenshtein距离算法，而非给项目添加新依赖。

我们现在能用更小的团队完成更多工作。我们或许离90年代的模式不远了——当时4人团队就能做出专业级软件。我得以重启一些因耗时太长或难度太高而放弃的项目：上个月完成了《银河飞将》（Silpheed）视频格式逆向工程，目前世嘉DC版《斑鸠》（Ikaruga）和任天堂SNES版《塞尔达传说：众神的三角力量》的逆向工作也进展顺利。

LLM领域的发展既引人入胜，又颇具趣味：研究的对象本身，就是帮助我们跟上节奏的绝佳工具。LLM可以帮我们快速切入任何代码库，梳理整体架构。我一直在研究llama-cpp、OpenCode、ollama和vLLM的实现原理，还有Tenstorrent、Etched、MatX、d-Matrix、Cerebras Systems等硬件方案，都非常值得关注。

一开始读学术论文对我来说很困难，因为我一直搞不懂数学符号。LLM帮我弥补了这一短板。有个"伙伴"能给出解读，再加以验证，能大幅加快学习速度。

最重要的问题，是找到学习的动力。我们有很多理由不去努力，比如总能听到有人靠转行获得成功的故事。

是否坚持下去，是每个人自己的决定，需要信念与灵感支撑。信念源于内心，而我有时会从成功故事中汲取灵感。这让我回到文章开头的轶事——我并非随机挑选菲尔·蒂皮特的故事。很多人只知道那句被误传的"你是说被淘汰了？"，但后续的故事却鲜为人知。

| ^ | [ 1] | 为《侏罗纪公园》的恐龙注入生命 | | ^ | [ 2] | 此处的"大师"，指参与过《绝地归来》《屠龙记》《机械战警》等作品的资深从业者。 | | ^ | [ 3] | 《侏罗纪公园》制作幕后 | | ^ | [ 4] | 恐龙诞生记 | 《侏罗纪公园》纪录片 | | ^ | [ 5] | 恐龙输入设备口述史 | | ^ | [ 6] | 《侏罗纪公园》完整制作纪录片 | | ^ | [ 7] | 多数软件工程师正面临近乎抑郁的身份危机 | | ^ | [ 8] | LLM正在侵蚀我的软件工程生涯，我不知所措 | | ^ | [ 9] | 开发者真的害怕AI抢走工作吗？ | | ^ | [10] | 赫拉克利特：万物皆流 | | ^ | [11] | 恐龙输入设备口述史 | | ^ | [12] | 第66届奥斯卡颁奖典礼 | 1994年 | | ^ | [13] | 蒂皮特工作室 |