1993年《侏罗纪公园》以CGI技术革新电影业，导演斯皮尔伯格原计划用定格动画大师蒂皮特的动感模型技术，但工业光魔的CGI测试效果逼真，令蒂皮特感叹自己“感觉要灭绝了”。

当然，以下是您提供的文章主要内容的中文重述，已保留关键细节并删减了与主题无关的内容：

标题：难道你是说“灭绝”吗？

1993年，《侏罗纪公园》上映，彻底革新了电影中CGI（计算机生成图像）的使用。对公众而言，这体验如同魔法；但对电影行业的一些人来说，却是一次残酷的觉醒。

导演斯皮尔伯格原本聘请了定格动画大师菲尔·蒂皮特，用其“动态运动”技术来制作电影中的全尺寸恐龙。斯皮尔伯格对CGI能否真实呈现恐龙深表怀疑。然而，工业光魔的数字艺术家们制作了一个概念验证：用CGI渲染出一只全纹理、照片级真实的霸王龙在阳光下追逐一群似鸡龙。当斯皮尔伯格看到这个测试片段后，他决定改用CGI。蒂皮特得知后说：“我感觉自己灭绝了。”他当时已为庞大的动态运动任务组建了30人的团队，这一变故让他备受打击。

作者近来常想起这段轶事，因为看到程序员群体中弥漫着悲观情绪，担心自己变得过时。避免“灭绝”的最佳方式是“进化”。正如一位网友所言：“乘上浪潮。当网站/网络应用是浪潮时，你乘上了它。我在互联网出现前就进入软件行业，不断更换我的‘马匹’。你永远不会老到学不会新把戏。新浪潮创造新类型的工作和工作者。成为他们中的一员。驾驭这头野兽，掌握工具。这又是同一场游戏。”

作者认为，每一代程序员都可能经历某种形式的革命。LLM（大语言模型）只是又一个工具。要进化，就得投入时间学习它的工作原理以及如何最好地使用它。

学习LLM的工作原理：作者推荐安德烈·卡帕西的频道（25小时的纯干货视频）和塞巴斯蒂安·拉什卡所著的《从头构建大语言模型》一书。

学习用LLM编写代码：逐行手写代码已不再是常态。拒绝使用LLM的人会落后。约翰·卡马克指出：“‘编码’从来不是价值的来源，人们不应过于执着于此。解决问题才是核心技能。” 作者虽不直接写代码，但间接生成代码。如果完全依赖LLM，可以产生1000倍于以往的代码，但可能得到一团乱麻。对于原型或个人小项目，这或许没问题；但其他情况下，代码质量依然至关重要。LLM可能会失败或产生幻觉。因此，能够阅读代码并理解架构仍然很重要。作者会反复迭代自己的PR（拉取请求），直到达到与“手写”相同的质量水平，并将个人编码规范（如避免魔法数字、减少缩进、使用枚举等）添加到LLM的配置文件中，让AI模仿其风格。作者遇到的最大困难是“上下文切换”，同时驱动多个AI代理会导致精神疲劳。

LLM时代的代码审查：由于工具更好，作者对代码审查的期望更高。现在没有借口写出糟糕的提交信息，可以花一分钟让LLM总结并转化为规范。由于编写代码的难度降低，作者期望软件工程师更注重设计优雅的解决方案，并要求提高代码清晰度和简洁性。PR的代码规模也应更小、更易审查。许多代码审查工具已集成LLM，作者会先让LLM自动进行第一轮审查，避免浪费审阅者的时间。编写测试也不再是痛苦的事，可以要求每个PR都附带单元测试/CI测试。现在也更有理由拒绝引入不必要的依赖，例如让LLM直接编写一个莱文斯坦距离函数，而不是添加一个依赖包。

更小的团队：我们可以用更小的团队完成更多工作。作者已能重拾因耗时或复杂而放弃的项目，例如逆向工程《Silpheed》的视频格式。

如果无法击败它们，就加入它们：LLM领域本身也很有趣，它既是研究对象，也是帮助跟上步伐的绝佳工具。LLM可以帮助深入任何代码库并提供架构指引。作者也在享受阅读llama-cpp、OpenCode等项目的代码。LLM还帮助作者弥补了数学符号方面的短板，有助于阅读研究论文。

寻找动力：最重要的是找到学习的动力。作者以菲尔·蒂皮特的故事结尾：尽管最初受到冲击，但41岁的蒂皮特并未“灭绝”。斯皮尔伯格留任他为“恐龙总监”，因为他和团队懂得如何让生物的动作具有重量、时机和生物意图。蒂皮特与工业光魔共同开发了“恐龙输入设备”，这是一种连接传感器的高度铰接式物理骨架。他的团队像做定格动画一样物理操控该设备，计算机则将动作转化为数字空间。最终，蒂皮特凭借《侏罗纪公园》赢得了奥斯卡最佳视觉效果奖，他的公司也继续参与了《星河战队》、《龙之心》等75部电影的制作。

核心观点：面对技术变革（如LLM），与其恐惧被淘汰，不如主动进化，学习并善用新工具。蒂皮特的故事正是这一观点的最佳例证。

以下是评论内容的总结，涵盖主要观点和论据，并保留关键引用（中英文）：

观点1：LLM提升效率，但需谨慎使用

• 支持者：LLM在代码搜索、流程重构、调试、测试编写等方面显著节省时间（评论5）。
  • 引用："LLMs make me insanely faster in: finding something in the codebase, reconstructing a flow and understanding the architecture, triaging a bug... That saves me hours."
  • 引用："I use LLMs to solve problems, I'm not extinct."（评论6）
• 质疑者：LLM生成代码需仔细审查，可能引入错误，且理解代码的时间抵消了速度优势（评论4、5）。
  • 引用："Which you likely failed to review thoroughly, so may be subtly wrong."（评论4）
  • 引用："I'm still not convinced that I'm faster with an LLM at all, since I add this new bottleneck (the time spent understanding every line)."（评论5）

观点2：LLM并非必然进步，可能带来负面影响

• 批评者：LLM生成内容质量平庸（“slop”），且消耗注意力、能源等稀缺资源，导致信息过载和文化衰退（评论6）。
  • 引用："The result will be mediocre at best, on average it will be slop... GenAI offers us an abundance of stuff we don't want or need."（评论6）
• 担忧者：LLM由营利性公司控制，与黑客精神相悖，可能削弱工作乐趣和职业价值（评论3、7）。
  • 引用："Most LLMs people are using to code are paywalled, and controlled by private, for-profit entities... diametrically opposed to the hacker."（评论3）
  • 引用："If you enjoyed knitting threads together, it was the crushing victory of mediocrity."（评论7）

观点3：LLM是工具，需理性看待其局限性

• 中立者：应学习LLM，但多数时候不使用，因为旧方法可能更好（评论2）。
  • 引用："It's probably best to learn about LLMs, and then don't use them most of the time."（评论2）
• 反思者：LLM的“产出更多”论点站不住脚，因为工作评价不基于数量（评论1）。
  • 引用："Fall behind what? Able to produce 'as much' what? I've never been evaluated on volume in my life."（评论1）

观点4：未来展望：LLM可能超越人类，但需警惕

• 乐观者：AI代码质量将超越多数人类，公司会优先使用（评论10）。
  • 引用："If an AI can reliably write code better than most coders... why on earth would a company not use an AI to write all their code?"（评论10）
• 悲观者：经验丰富的从业者可能被取代，职业前景堪忧（评论9）。
  • 引用："My technical and artistic skills are basically replaced. They are the equivalent of Linotype expert."（评论9）

总结

评论呈现两极分化：部分人认可LLM在特定任务（如调试、原型开发）中的效率提升，但强调需谨慎审查；另一部分人批评其质量平庸、消耗资源，并担忧职业价值和文化衰退。少数观点认为LLM是过渡工具，未来可能超越人类，但当前不应盲目依赖。