AI时代前端开发是否会重蹈覆辙,步入又一个失落的十年
Mauro Bieg
人工智能对开发者工作模式的冲击，对我们众多前端从业者而言并不陌生——因为我们此前已亲身经历过类似的变革。
本文将从技术价值贬值的维度审视前端与AI辅助编程的演进，随后从更宏观的抽象视角对比这两种转变。最后，我们将回顾历史先例，如Stack Overflow复制粘贴文化的兴起，以及包豪斯运动如何应对工业化的浪潮。
正如AI正在削弱编程技术的价值，JavaScript框架在过去十余年间同样降低了前端开发的门槛。我最初学习的是HTML/CSS及部分PHP，随后接触Ruby on Rails，并曾担任瑞士某大型报社前端团队负责人（当时使用Next.js），因此亲眼见证了这一演变过程。这并非我个人的主观臆断！AlexRussell将这种现象称为"前端失去的十年"。
何为技术价值贬值？（源自维基百科）
技术价值贬值是指通过引入由半熟练或不熟练工人操作的技术，替代行业或经济体中的熟练劳动力的过程。这能实现成本节约[...]并降低入门标准，削弱[从业者]的议价地位。
让我们审视这一概念如何应用于前端开发，再延伸至AI编程领域。
许多开发者或许不了解，前端曾是一项高度专业化的技能，要求掌握语义化HTML、CSS、跨浏览器兼容、无障碍访问、渐进增强、网络性能、界面设计及用户测试等众多知识——这仅是冰山一角。为区分他们过去的工作与如今"前端"的概念，这些资深从业者常将其称为"前端的前端"。
前端技术的简化源于框架和工具的引入，它们将浏览器视为纯粹的编译目标——如同其他应用运行时环境（如JVM或iOS）一般。如此一来，你只需调用如Shadcn单选按钮这般复杂的组件，而无需深究底层HTML、浏览器兼容差异、页面加载性能及无障碍访问等细节。
正如维基百科所述，这"能为企业节约成本"，因为企业可以轻而易举地让普通开发者承担前端工作。然而，所谓的"全栈开发者"往往并非真正精通前后端，而仅是掌握了足以驾驭JavaScript框架的通才。这使得企业能够灵活调配人力资源。同一位通才甚至能运用React Native和Electron开发原生应用！维基百科最终指出：这"降低了入门门槛"（我一直高度重视这一点），但同时也"削弱了员工的议价地位"。
当前开发者群体面临的困境，与网页开发者此前经历的如出一辙。手工编码这项技术性工作正"被技术替代，由半熟练或不熟练的工人操作的技术所取代"。
我们尚不明晰，变革完成后，操控AI编程工具的工作者究竟需要何种技能，以及最终的成本几何——无论是人力成本，还是本地及远程LLM的支出。但目前已清晰可见的是，企业必将利用这项技术削减开支，并削弱员工的议价地位。
如同一个多世纪前被流水线工人替代的工匠，我们深感失落。我们痛心地看到，倾注半生心血磨练的技艺不再被市场珍视。我们同样惋惜，因为新兴生产流程导致产品质量下滑，而众多人似乎对此漠不关心。
当然，换一种视角看待"技术减退"，可将其视为通过自动化提升效率。哪位工程师不青睐自动化呢？毕竟，这是我们工作的核心组成部分！
在此框架下，引入的新技术不过是在更高的抽象层级运作，使操作者能够聚焦全局，无需顾虑细枝末节。但究竟哪些细节被视为"无关紧要"，这是一个关键且带有主观性的决策。最终，这些细节总会暴露出来。
抽象化通常以牺牲性能为代价。但由于当前计算机性能卓越，我们通常愿意舍弃部分运行时性能以换取更高的开发效率（垃圾回收即是一例）。对于负载适中的高性能服务器，这是一种相当合理的权衡。但对于网络条件欠佳的移动设备，情况则截然不同。
通过使用如React这般功能强大的客户端JavaScript框架，以及该生态中的海量软件包，你实际上忽视了可访问性、低端设备或网络缓慢环境下的性能等问题。实际上，你选择忽略这些问题，也选择对其漠不关心。
通过AI编程工具来编写功能或修复缺陷，你是在更高的抽象层级描述变更，从而比手工编码节省更多精力。AI会依据其训练数据和上下文补充你省略的细节——有时猜测精准，有时则大相径庭。你是否认为这有用，很大程度取决于你对编码时哪些方面最为关键的看法。
但与以往的编程抽象相比，AI编程是一种极易失效的抽象。它不像编译器那样具有确定性，输入或模型的细微变化都可能导致截然不同的结果。这促使人们将AI比作"初级工程师"，因为初级工程师的工作同样并非完全确定。当然，两者之间的一大差异在于，人类能够学习，而无需你持续调整他们的AGENTS.md或SKILL.md文件。
因此，目前为止，我发现对使用LLM的最佳类比是谷歌搜索的运作方式。我们都曾习得这项技能：挑选恰当的关键词，让正确的论坛帖子（以及后来的Stack Overflow帖子）出现在谷歌搜索结果的首位。正如调用LLM一样，为返回正确的训练数据集，模糊网络搜索也是在高维空间中进行检索。而且，如同LLM一般，这种检索对措辞的细微变化以及谷歌搜索索引的更新极为敏感。
近年来，谷歌对搜索算法进行了多项调整，其中一项关键举措便是更加积极地对用户输入的关键词进行规范化处理。对于不熟悉谷歌搜索技巧的用户而言，这无疑让搜索变得更加便捷。但对于我们这些已掌握搜索技巧的人，谷歌搜索的效能却大打折扣。过去，精准的关键词能直接将我们导向目标答案。而现在，它们会被规范化为同义词或密切相关的内容，最终我们只能获得一个更加宽泛的页面。
但谷歌的出现，以及后来的Stack Overflow，彻底改变了编程。开发者们不再需要翻阅冗长的手册，而可直接从Stack Overflow复制粘贴答案，且往往能得到勉强可行的结果。从这个角度看，LLM只是这一趋势的延续：它们提供工具和抽象，让真正精通的人效率更高，也让不太熟悉的人能得到勉强可行的成果。你知道吗？这太棒了！
但我们不应自欺欺人：抽象层迟早会失效。届时，就必须有人投入时间深入理解问题的根源，并加以修复。正如我们先前教导初级开发者在使用Stack Overflow答案前先阅读并理解它，如今我们需要教导人们阅读并理解LLM的输出，并理解它如何融入现有代码库。
遗憾的是，部分开发者从未真正尝试理解Stack Overflow上的答案。既然有效，何必费心呢？虽然没有公开承认，但众多企业实际上对这种做法颇为满意。如今的差异在于，企业会不遗余力地公开宣称使用了多少AI，却连查看输出结果都懒得做。
虽然LLM确实存在一些合理的应用场景，但也带来了诸多新问题，如代码缺陷、团队沟通不畅及流程混乱。这对团队而言尤为棘手。正如代码审查一般，对于如何使用LLM并将其整合到工作流程中（若需整合的话），存在巨大分歧。若团队对自身重视的方面缺乏共识，这可能成为工作的真正阻碍。
令人遗憾的是，众多企业即便软件质量低劣，运营状况依然良好。尽管我们开发者可能期望如此，但商业成功与软件质量之间鲜有关联。通常，其他因素起着决定性作用。软件项目常被视为黑箱，失败与成功的概率相近，且会通过各种方式降低风险（最坏情形下，由另一团队重新开发）。
前端开发亦是如此。遗憾的是，劣质网站对最终收益的影响相对有限。网站加载缓慢、广告横幅泛滥会影响转化率吗？当然会，但与品牌忠诚度和定价等其他因素相比，这种影响微不足道。而且，所有竞争对手的网站速度同样缓慢！再说，也没人会因为选择React而被解雇。
这是否意味着我们应该停止关注用户和精进技艺？当然不是。但这确实意味着，找到一份允许你这样做的职位变得更加困难。希望热潮过后，情况会有所改善，届时我们也能更清晰地了解LLM真正适用于哪些任务，不适用于哪些。但可以确定的是，我们的行业将与以往截然不同。
当日常用品和建筑物突然可通过工业化流程大规模生产时，前几代工匠们如何应对？一种策略是模仿旧式风格，让工业生产出至少看似手工制作的小部件和建筑物。
为对抗这种历史主义倾向，20世纪初的包豪斯运动发展出一种替代方案。他们没有让工厂工人与工匠对立，而是明确提出让他们协作，并以工业化生产流程为指导，重塑工艺美术。包豪斯鼓励设计师重返工坊，亲身接触材料。他们的目标依旧是设计能够批量生产的产品，但始终将最终用户置于首位，并给予充分关怀。以迪特·拉姆斯和乔纳森·艾维为代表的现代工业设计，其根源可追溯至包豪斯。
我们如何将这种思路转化为软件开发？
软件介于工艺（我们编写的程序"原封不动"地交付给用户，无需经过制造步骤）和工业设计（我们将同样的产品交付给成千上万的用户，但我们永远无法目睹他们与产品的互动）之间。
掌握手工编码的必要性不言而喻。正如工业设计师需要了解产品所用材料，网页设计师也需要精通HTML和CSS。
虽然如Google、Stack Overflow、现成的库以及当前的LLM等工具让初学者更容易上手，但这同时也意味着，让任何事情运转起来的自然门槛正在不断降低。
虽然某个领域的准入门槛很高，但很难找到绝对糟糕的作品。工匠一旦学会了如何制作木椅，通常也会同时学会如何才能把椅子做得尽善尽美。
工业化催生了大量廉价塑料制品，这些产品的设计师往往没有花时间思考它们的用途和使用者——然而，优秀的工业设计依然存在。文字处理器的发明导致了大量格式糟糕的文档出现——但排版和平面设计依然重要。像Wix和Next.js这样的软件催生了大量加载速度极慢且难以访问的网站——但前端开发领域仍然活跃着众多从业者。同样，人工智能也导致了大量应用的涌现——但这并不意味着我们不再需要那些真正了解自己在做什么，并且对自己的工作充满热忱的人。
但和其他行业一样，把事情做好所占的份额会越来越小。但由于现在做事更容易、成本更低，蛋糕的体积会继续扩大。目前很难说真正靠把事情做好来盈利的人数是会增加还是减少。依我看，市面上设计糟糕的塑料制品实在太多了。设计新字体如今已不再是一份可持续的全职工作，这的确令人遗憾。但与此同时，在所有这些领域，仍然有很多优秀的作品正在诞生。
你知道吗？有时候，快速打造一个原型或最小可行产品才是正确的做法。如果你的产品尚未找到市场契合点，那么快速迭代和学习比事事都考虑未来兼容性更重要。但你需要知道自己想要学习什么，以及如何验证这些学习成果。时机成熟时，通常最好退一步，从一开始就把事情做好。例如，若前端架构设计糟糕，后期很难实现良好的性能。而且，从简单的技术栈入手，之后再逐步添加功能，比反过来要容易得多。Mastro明确鼓励这样做。
对于系统的任何部分，你都需要了解你正在做的权衡，然后决定是购买服务、使用开源库、让LLM代工，还是自己编写。当炒作消退后，业界会意识到它只不过是工具箱里的又一个工具而已。但在那之前，我们将看到很多糟糕的事情：糟糕的代码、糟糕的沟通，以及在人工智能的幌子下发生的骇人听闻的裁员。