AI是否在重演前端的“失落十年”？

AI是否在重演前端的“失落十年”？

Mauro Bieg 发布于 2026年5月23日

AI对程序员工作产生的影响，对我们这些前端开发者来说非常熟悉——因为我们以前就经历过。让我们先通过“去技能化”的视角来看前端和智能体编程的转变，然后再从更高层次抽象的角度来看这两次变化。最后，我们会回顾以往的变化，比如从Stack Overflow复制粘贴的兴起，以及包豪斯运动如何应对工业化浪潮。

去技能化

正如AI正在使编程去技能化一样，JavaScript框架在过去十年中已经使前端开发去技能化了。作为一个从HTML/CSS和一点PHP开始，后来使用Ruby on Rails，再后来担任瑞士一家主要报纸（当时使用Next.js）前端团队负责人的人，我亲眼目睹了这种转变。而且，不需要只相信我一个人的话！我并不是第一个这么说的人。Alex Russell称之为“前端的失落十年”。

什么是去技能化？来自维基百科：去技能化是指一个行业或经济体中，熟练劳动被由半熟练或非熟练工人操作的技术所取代的过程。这导致了成本节约……并降低了准入门槛，削弱了工人的议价能力。

让我们看看这如何适用于前端，然后适用于智能体编程。

前端的去技能化

很多程序员可能不知道，前端曾经是一项高度专业化的技能，需要了解语义HTML、CSS、各种浏览器的差异、可访问性、渐进增强、网络性能、界面设计和用户测试等等。为了区别于现在所谓的“前端”，这门秘术的实践者如今经常称之为“前端的前端”。

前端的去技能化始于框架和其他工具的出现，它们将浏览器仅仅视为一个编译目标——就像其他任何应用程序运行时（如JVM或iOS）一样。然后，你可以直接加载一个像Shadcn单选按钮那样的怪物，而无需理解底层的HTML、不同浏览器的细微差别、页面加载性能和可访问性。正如上面维基百科引用的那样，这为企业“节约了成本”，因为他们可以轻松地让任何普通程序员从事前端工作。通常，“全栈开发者”不幸地并不是指那些深刻理解前端和后端的人，而只是一个通才，他只知道足够驾驭一个JavaScript框架来完成两者。这使得企业可以轻松地在不同项目之间调配程序员。同一个通才甚至可以用React Native和Electron来做原生应用！

完成维基百科的引用：这“降低了准入门槛”（这是我一直珍视的东西），但也“削弱了工人的议价能力”。

AI正在使编程去技能化

目前程序员普遍正在经历的事情，似乎与网络开发者已经经历的事情非常相似。手动编写代码的技能工作正在“被由半熟练或非熟练工人操作的技术所取代”。我们仍然不知道，在这场转变结束时，操控智能体AI的工人需要具备什么样的技能组合，以及我们将达到什么样的价格点——无论是劳动力还是本地和远程LLM。但现在已经很清楚，企业绝对会利用这项技术来节约成本和削弱工人的议价能力。

深切的失落感

就像一个多世纪前被流水线工人取代的手工艺人一样，我们感到一种深切的失落感。我们哀叹一项我们花费了半生时间磨练的技能不再被市场重视。我们也感到悲哀，因为新流程导致了更低质量的工作，而很多人似乎并不在乎。

在更高的抽象层次上操作

看待“去技能化”的另一种方式当然是认为这只是利用自动化提高效率。哪个工程师不喜欢自动化呢？毕竟这是我们工作的一大部分！在这种框架下，引入的新技术只是在更高的抽象层次上工作，使得操作者能够专注于大局，而不必为不重要的细节烦恼。但究竟哪些细节被视作“不重要”，是一个后果严重且有时主观的决定。而最终，细节总会泄露出来。

“现代”前端：一座漏水的抽象之塔

抽象通常以性能为代价。但由于如今的计算机非常快，我们常常愿意用一些运行时性能来换取更高的开发者生产力（垃圾回收就是一个例子）。对于负载适中的高性能服务器来说，这是一个非常明智的权衡。但慢速网络上的手机则是另一回事。通过使用像React这样的重型客户端JavaScript框架以及该生态系统中的大量包，你正在抽象掉可访问性、低端手机上的性能或慢速网络等问题。实际上，你选择不去思考这些问题，你选择不去关心它们。

智能体编程：一种不确定的抽象

通过使用智能体AI来编写功能或修复bug，你在更高的抽象层次上描述更改，编写的文字比手动编写所有代码要少。AI会根据其训练数据和周围上下文来填补你省略的细节——有时猜得准，有时不准。你是否觉得这有用，很大程度上取决于你对编程中重要内容的看法。但与以往的编程抽象相比，智能体编程是一种非常漏水的抽象。它不像编译器那样确定，输入或模型的微小变化可能导致截然不同的结果。这导致人们将AI比作“初级工程师”，因为初级工程师也不是确定的。但一个区别当然是，人们有能力学习，而你无需没完没了地调整他们的AGENTS.md或SKILL.md文件。

LLM：Stack Overflow复制粘贴的延伸

到目前为止，我发现关于使用LLM的最佳类比是Google搜索过去的行为。我们所有人都曾在某个时候需要学习一项技能：选择正确的关键词，以便正确的论坛帖子（后来是Stack Overflow帖子）出现在Google搜索结果的第一页。就像提示LLM一样，为了返回其训练数据的正确组合，模糊的网络搜索是在一个高维空间中进行查找。就像LLM一样，这种曾经对措辞的微小变化和Google搜索索引的变化非常敏感。近年来，Google等搜索引擎改变了搜索方式，更积极地规范化输入的术语。对于那些不精通“Google之艺”的人来说，这让搜索变得更容易使用。但对于那些掌握了这项技能的人来说，它让Google搜索变得不那么强大了。专业的关键词曾经直接把我们带到答案。现在它们被归一化为同义词或密切相关的词，我们落到了一个更通用的页面上。

但是Google以及后来的Stack Overflow的出现，不可逆转地改变了编程。程序员不再需要阅读该死的文档，而是可以直接从Stack Overflow盲目地复制粘贴答案，而且令人惊讶的是，很多时候得到的东西多少还能用。从这个角度看，LLM只是同一趋势的延续：工具和抽象让懂行的人稍微快一点，也让不懂行的人能做出一些常常勉强能用的东西。你知道吗？这很好！但不要自欺欺人：抽象终将泄露。到时候，必须有人花时间真正深入理解到底发生了什么并修复它。就像我们教初级程序员在使用Stack Overflow答案之前先阅读和理解一样，现在我们需要教人们阅读和理解LLM吐出来的内容，并理解它如何融入现有的代码库。

质量重要吗？

不幸的是，有些程序员从未达到努力真正理解Stack Overflow答案的阶段。如果能用，何必麻烦？而且虽然不公开承认，但很多公司实际上对这种做法很满意。现在不同的是，公司们公开炫耀他们使用了多少AI，甚至假装不检查输出。虽然LLM确实有有效的用例，但也有许多新方法可以搞乱你的代码，搞乱你组织的沟通和流程。作为一个团队，弄清楚这一点尤其具有挑战性。就像代码审查一样，对于如何使用和集成LLM到我们的工作流程中（如果使用的话），存在广泛分歧的观点。如果团队在重视什么的问题上不一致，这真的会给工作带来麻烦。

还有一个可悲的生活事实：很多公司做得很好，尽管他们生产的软件很糟糕。尽管我们程序员愿意相信，但商业成功和软件质量很少相关。通常，其他因素主导了一切。软件项目经常被视为黑盒，失败的概率和成功差不多，并通过各种方式降低风险（最坏的情况下，不同的团队会再试一次）。前端开发也是如此。不幸的是，一个糟糕的网站对利润的影响相对较小。一个缓慢的网站和大量的cookie横幅会损害转化率吗？当然，但与其他因素如品牌忠诚度和定价相比，这个影响相对较小。而且所有竞争对手的网站都很慢！此外，没有人因为选择React而被解雇。

这是否意味着我们应该停止关心用户和我们的手艺？不。但这确实意味着，找工作变得比以前更难，找到一份允许你这样做的工作也更难。希望当炒作过去，我们更清楚地了解LLM真正适合和不适合什么任务时，钟摆会往回摆一点。但可以肯定地说，我们的职业不会再和以前一样了。

包豪斯运动

当日常用品和建筑突然可以通过工业过程大规模生产时，前几代手工艺人做了什么？一种反应是模仿旧风格，让工业制造出至少看起来像手工制作的部件和建筑。为了对抗这种历史主义趋势，20世纪初的包豪斯运动发展出了一种替代方法。他们不是让工厂工人与手工艺人对立，而是明确的目标是让他们合作，并在考虑工业制造过程的情况下重新发展艺术和手工艺。包豪斯敦促设计师回到作坊，亲自与材料打交道。目标仍然是最终设计出可以大规模生产的产品。但始终牢记最终用户，并深切关心他们。由Dieter Rams和Jonathan Ive所代表的现代工业设计，可以直接追溯到包豪斯。

关心质量和用户

如何将这种思路应用到软件上？软件介于手工艺（我们编写的程序“原样”交付给用户，没有先经过制造步骤）和工业设计（我们将相同的东西交付给可能成千上万的用户，我们从未见过他们与我们的产品交互）之间。需要...