AI是否在重复前端开发的衰落轨迹？

引言：AI对程序员工作的影响，许多前端开发者早已体验过类似情况。

我们将从技能价值下降的角度探讨前端和AI编码的变化，接着从更高层次的抽象角度进行分析。随后回顾历史变化，比如Stack Overflow上复制粘贴内容的兴起，以及“包豪斯运动”如何应对工业化浪潮。

正如AI正在降低编程技能门槛，AlexRussell称之为“前端失落的十年”。

何为技能贬值？

技能贬值指通过引入半熟练或非熟练工人可操作的技术，淘汰熟练劳动力的过程。这会降低成本并降低进入门槛，削弱员工议价能力。

我们先看前端领域如何体现这一点，再看AI编码领域。

很多新入行的程序员可能不了解，前端曾是高度专业化的技能，需要掌握语义化HTML、CSS、浏览器兼容性、可访问性、渐进增强、网络性能、界面设计和用户测试等知识。为区分传统前端与现代“前端”概念，老一辈从业者常称其为“前端的前端”。

前端技能简化源于框架和工具的引入，它们将浏览器视为编译目标。这样只需加载如Shadcn单选按钮等复杂组件，无需了解底层HTML、浏览器兼容性、页面性能和可访问性等细节。

维基百科指出，这“能为企业节省成本”，因为他们可轻松让普通程序员从事前端开发。但通常情况下，“全栈开发人员”并非真正精通前后端，而只是掌握足够JavaScript框架知识的人才。这使企业可轻松在项目间调配程序员。同一位通才甚至能用React Native和Electron开发原生应用。

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

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

时至今日，我们仍不清楚变革结束后，操控AI的工作人员需要哪些技能及最终成本。但很明显，企业会利用这项技术来降低成本，削弱员工议价能力。

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

当然，看待“技能减退”也可认为是通过自动化提高效率。哪个工程师不喜欢自动化呢？这正是我们工作的重要部分！

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

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

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

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

通过AI编写功能或修复错误，你将在更高层次的抽象层描述变更，从而比手动编写代码节省更多文字。

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

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

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

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

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

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

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

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

虽然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/

为什么Linus Torvalds一听到“99%的代码都是人工智能”会生气