导读：人工智能对程序员工作的影响，对于很多前端开发人员来说都非常熟悉——因为以前的年代也经历过这种情况。

我们首先从技能贬值的角度来审视前端和智能体编码的转变，然后再从更高层次的抽象角度来分析这两种变化。最后我们将回顾之前的变化，例如 Stack Overflow 上复制粘贴内容的出现，以及“包豪斯运动（Bauhaus movement ）”如何应对工业化的兴起。

技能贬值

就如同人工智能正在降低编程技能门槛一样，Alex Russell 将其称为“前端失去的十年”。

什么叫技能贬值？

技能贬值是指通过引入由半熟练或非熟练工人操作的技术，淘汰行业或经济体中的熟练劳动力的过程。这会导致成本节约并降低准入门槛，削弱工人的议价能力。

让我们来看这如何应用于前端，然后再应用于智能体编码。

前端技能的退化

很多新入行的程序员可能不知道，前端曾经是一项高度专业化的技能，需要掌握语义化的HTML、CSS、各种浏览器的兼容性、可访问性、渐进增强、网络性能、界面设计和用户测试等诸多知识——这仅仅是其中一部分。为了将他们现在的工作与如今“前端”的概念区分开来，这门拥有古老技艺的实践者们常常称之为“前端的前端”。

前端技能的简化源于框架和相关工具的引入，它们将浏览器视为一个纯粹的编译目标——就像其他任何应用程序运行时环境（例如 JVM 或 iOS）一样。这样一来，你只需加载一个像 Shadcn 单选按钮那样复杂的组件，而无需了解底层 HTML、不同浏览器之间的兼容性问题、页面加载性能以及可访问性等细节。

维基百科上所引述，这“能为企业节省成本”，因为他们可以轻松地让任何普通程序员从事前端开发工作。然而在通常情况下，“全栈开发人员”并非真正精通前端和后端，而只是掌握了足够知识来驾驭 JavaScript 框架的人才。这使得企业可以轻松地在不同项目之间调配程序员。同一位通才甚至还能使用 React Native 和 Electron 开发原生应用。

维基百科指出道：这“降低了准入门槛”，但同时也“削弱了员工的议价能力”。

人工智能正在降低编程技能

目前程序员群体普遍面临的困境，与Web开发人员此前经历的非常相似。手动编写代码这项技术性工作正“被技术取代，取而代之的是半熟练或非熟练的工人能够操作的技术”。

时至现在，我们仍然不清楚，在这场变革结束后，操控智能体人工智能的工作人员究竟需要具备哪些技能，以及最终的成本会是多少——无论是劳动力成本，还是本地和大语言模型（LLM）的成本。但目前已经很明显的是，企业一定会利用这项技术来降低成本，并削弱员工的议价能力。

深深的失落感

就像一个多世纪前被流水线工人取代的工匠一样，我们感到深深的失落。我们悲痛地看到，自己花费半生磨练的技艺不再被市场重视。我们也感到惋惜，因为新的生产流程导致产品质量下降，而很多人似乎对此都漠不关心。

在更高的抽象层次上运作

当然，看待“技能减退”也可以使用另一种方式，可认为这只是通过自动化提高效率。哪个工程师不喜欢自动化呢？毕竟，这是我们工作的重要组成部分！

在这种框架下，引入的新技术仅仅是在更高的抽象层面上运作，使操作者能够专注于大局，而无需关注无关紧要的细节。但究竟哪些细节被认为是“无关紧要的”，这是一个至关重要且有时带有主观性的决定。最终，这些细节总会泄露出来。

“现代”前端：一座漏洞百出的抽象塔

抽象化通常会以牺牲性能为代价。但由于如今计算机速度极快，我们通常愿意牺牲一些运行时性能来换取更高的开发效率（垃圾回收就是一个例子）。对于负载适中的高性能服务器来说，这是一种非常合理的权衡。但对于网络速度较慢的手机而言，情况则截然不同。

通过使用像 React 这样功能强大的客户端 JavaScript 框架，以及该生态系统中的大量软件包，你实际上是在忽略诸如可访问性、低端手机或慢速网络下的性能等问题。

当然，你可以选择不去考虑这些问题，也选择不去关心它们。

AI代理编码：一种非确定性的抽象

通过使用智能体人工智能来编写功能或修复错误，你将在更高层次的抽象层面上描述变更，从而比手动编写代码节省更多文字。

人工智能会通过查看训练数据和上下文来补充人们省略的细节，但它有时猜测准确，有时则不然。你是否觉得这有用，很大程度上取决于你对编码时哪些方面最重要的看法。

但与以往的编程抽象相比，智能体编码是一种非常容易泄漏的抽象。它不像编译器那样具有确定性，输入或模型的细微变化都可能导致截然不同的结果。

这导致人们将人工智能比作“初级工程师”，因为初级工程师的工作也并非完全确定。当然，两者之间的一个区别在于，人类能够学习，而无需你不断地调整 AGENTS.md 或 SKILL.md 文件。

LLM 是 Stack Overflow 上复制粘贴的扩展

目前为止，我发现对使用LLM（逻辑学习模型）的最佳类比是谷歌搜索的运作方式。我们都曾学习过这项技能：选择合适的关键词，让正确的论坛帖子（以及后来的Stack Overflow帖子）出现在谷歌搜索结果的第一页。

就像调用LLM一样，为了返回正确的训练数据集合，模糊网络搜索也是在高维空间中进行查找。就像LLM一样，这种查找对措辞的细微变化以及谷歌搜索索引的更改都非常敏感。

近年谷歌对搜索算法进行了诸多调整，其中一项重要举措就是更加积极地对用户输入的关键词进行规范化处理。对于那些不熟悉谷歌搜索技巧的用户来说，这让搜索变得更加便捷。但对于我们这些已经掌握了搜索技巧的人来说，谷歌搜索的强大功能却大打折扣。过去，专业的关键词能够直接将我们引导至目标答案。而现在，它们会被规范化为同义词或密切相关的词语，最终我们只能看到一个更加通用的页面。

谷歌的出现，以及后来的 Stack Overflow，彻底改变了编程。程序员们不再需要阅读难读的手册，而是可以直接从 Stack Overflow 上复制粘贴答案，而且令人惊讶的是，往往能得到一些能用的东西。从这个角度来看，LLM（语言学习模块）只是这一趋势的延续：它们提供工具和抽象，让真正懂行的人工作效率更高，也让不太懂的人能够得到一些勉强能用的东西。

但我们不应自欺欺人：抽象层迟早会失效。到那时，就必须有人投入时间深入理解问题的根源，并加以修复。就像我们之前教导初级程序员在使用 Stack Overflow 的答案之前先阅读并理解它一样，现在我们需要教导人们阅读并理解 LLM 输出的内容，并理解它如何融入现有的代码库。

质量重要吗？

有些程序员从未真正尝试去理解 Stack Overflow 上的答案，既然有效，何必费那个心呢？虽然没有公开承认，但很多公司实际上对这种做法很满意。如今的不同之处在于，公司会不遗余力地公开宣称自己使用了多少人工智能，却连看看输出结果都不屑一顾。

虽然LLM有一些合理的应用场景，但它也带来了许多新的问题，例如代码出错、组织沟通不畅以及流程混乱。这对于团队来说尤其具有挑战性。就像代码审查一样，对于如何使用LLM并将其集成到工作流程中（如果需要集成的话），存在着巨大的分歧。如果团队对自身重视的方面没有达成共识，这可能会给工作带来真正的阻碍。

令人遗憾的是，很多公司即便软件质量低劣，经营状况依然良好。

尽管我们程序员可能希望改善软件质量，但商业成功与软件质量之间很少存在关联。通常情况下，其他因素起着决定性作用。软件项目往往被视为黑箱，失败的概率几乎与成功的概率相当，并且会通过各种方式降低风险（最坏的情况是，转由另一个团队重新开发）。

前端开发也是如此。做得不好的网站对最终收益的影响相对较小。网站速度慢、广告横幅过多会影响转化率吗？当然会，但与品牌忠诚度和定价等其他因素相比，这种影响微乎其微。而且，所有竞争对手的网站速度也都很慢！再说，也没人会因为选择 React 而被解雇。

这是否意味着我们应该停止关心用户和精进技艺？当然不是。但这确实意味着，找到一份允许你这样做的工作变得更加困难。希望热潮过后，情况会有所好转，届时我们也能更清楚地了解大语言模型（LLM）真正适合哪些任务，不适合哪些任务。

但可以肯定的是，我们的行业将与以往截然不同。

包豪斯运动

当日常用品和建筑物突然可以通过工业化流程大规模生产时，前几代工匠们都做了什么？一种应对方式是模仿旧式风格，让工业生产出至少看起来像是手工制作的小部件和建筑物。

为了对抗这种历史主义的趋势，20世纪初的包豪斯运动发展出了一种替代方法。他们没有让工厂工人与工匠对立，而是明确提出让他们合作，并以工业生产流程为指导，重新发展工艺美术。

包豪斯鼓励设计师重返工坊，亲自接触材料。他们的目标仍然是设计出能够批量生产的产品，但始终将最终用户放在首位，并给予他们充分的关怀。以迪特·拉姆斯和乔纳森·艾维为代表的现代工业设计，其根源可以追溯到包豪斯。

注重质量和用户体验

如何将这种思路转化为软件开发？

软件介于工艺（我们编写的程序“原封不动”地交付给用户，无需经过制造步骤）和工业设计（我们将同样的产品交付给成千上万的用户，但我们永远无法看到他们与我们的产品互动）之间。

能够手工编写代码的必要性显而易见。正如工业设计师需要了解产品所用材料一样，网页设计师也需要精通 HTML 和 CSS。

虽然像 Google、Stack Overflow、现成的库以及现在的 LLM 等工具让初学者更容易上手，但这同时也意味着，让任何事情运转起来的自然门槛正在不断降低。

虽然某个领域的准入门槛很高，但很难找到绝对糟糕的作品。工匠一旦学会了如何制作木椅，通常也会同时学会如何才能把椅子做得尽善尽美。

工业化催生了大量廉价塑料制品，这些产品的设计师往往没有花时间思考它们的用途和使用者——然而，优秀的工业设计依然存在。文字处理器的发明导致了大量格式糟糕的文档出现——但排版和平面设计依然重要。像 Wix 和 Next.js 这样的软件催生了大量加载速度极慢且难以访问的网站——但前端开发领域仍然活跃着许多从业者。同样，人工智能也导致了大量人工智能应用的出现——但这并不意味着我们不再需要那些真正了解自己在做什么，并且对自己的工作充满热情的人。

最终结果会如何？

但和其他行业一样，把事情做好所占的份额会越来越小。

但由于现在做事更容易、成本更低，蛋糕的体积会继续扩大。目前很难说真正靠把事情做好来赚钱的人数是会增加还是减少。依我看，市面上设计糟糕的塑料制品实在太多了。设计新字体如今已不再是一份可持续的全职工作，这的确令人遗憾。但与此同时，在所有这些领域，仍然有很多优秀的作品正在诞生。

有时候，快速打造一个原型或最小可行产品（MVP）才是正确的做法。如果你的产品还没有找到市场契合点，那么快速迭代和学习比事事都考虑未来兼容性更重要。但你需要知道自己想要学习什么，以及如何验证这些学习成果。时机成熟时，通常最好退一步，从一开始就把事情做好。例如，如果前端架构设计糟糕，后期很难实现良好的性能。而且，从简单的技术栈入手，之后再逐步添加功能，比反过来要容易得多。Mastro明确鼓励这样做。

对于系统的任何部分，你都需要了解你正在做的权衡，然后决定是购买服务、使用开源库、让LLM（语言学习管理专家）代工，还是自己编写。当炒作消退后，业界会意识到它只不过是工具箱里的又一个工具而已。但在那之前，我们将看到很多糟糕的事情：糟糕的代码、糟糕的沟通，以及在人工智能的幌子下发生的骇人听闻的裁员。

作者：场长

参考：

https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/