AIGC 浪潮下，鹅厂新一代前端人的真实工作感受-编程知识

点击链接了解详情

原创作者：张波

腾小云导读

AIGC 这一时代潮流已然不可阻挡，我们要做的不是慌乱，而是把握住这个时代的机会。本文就和大家一起来探索在 AIGC 下，前端工程师即将面临的挑战和机遇。聊聊从以前到现在，AIGC 给我们带来了怎么样的变化，下一代前端工程师又该何去何从？

01 疯狂的 AIGC

记得 ChatGPT4 刚出来的时候，OpenAI 总裁 Greg Brockman 用笔和纸画了一个网页草图，GPT4 仅用几秒的时间便完成了网页的设计和代码的编写。

ChatGPT4 生成网页（视频摘自 YouTube）

不知道当时前端同学们看到是个怎样的想法哈，反正我当时心都凉了，好不容易把 vue 的源码搞懂了，这就没啥用了，饭碗砸了，蓝瘦香菇。

好吧，开个玩笑。AI 已然如此，此时就不得不问那个老生常谈的问题了，前端工程师们该何去何从呢？

想来定有一些同学持悲观态度：前端已死，不值得做下去了，AI 马上就替代了。也会有些同学与之相反吧：AI 降临，神级辅助，又不吃经济，又有大用。

我想说的是，AIGC 一定会对前端开发的未来会产生重大影响，至于这个影响对于前端工程师来说，是正是反，从来都不是工具决定的，而是用工具的人来决定的。我们要做的，不是去担忧焦虑，而是把握住它。

02 范式迁移 —— AIGC 下开发模式改变的本质

在这之前，我们先来聊聊前端开发这些年的发展。

2.1 命令式 -> 声明式

命令式：关注过程，代码能够与自然语言产生一一对应的关系，代码本身描述的是“做事的过程”。

声明式：关注结果，过程在背后，暴露给用户的是声明的结果。

前端开发范式演变：命令式 -> 声明式

jQuery 是命令式开发的典型代表。这种范式的出现让前端开发变得高效，但还远远不够。因此，随着 Vue React 的现世，前端开发迅速地从命令式迁移到了声明式。

可能经常会在社区看到这样的提问：“该学 Vue 还是 React 呢？项目该用 Vue 还是 React 呢？”，这个问题一直都在争论，一直也没有一个明确的答案。可如果有人问到：“该用 jQuery 呢还是 MVVM 框架开发呢？”，我想这个问题是有标准答案的。

为什么会这样呢？很简单，jQuery 和 Vue React 的最本质的区别就在于范式的不同，从命令式到声明式的进化。

为什么前端领域普遍接受了这种范式的迁移？在我看来，有两个原因：

效率的极大提高

业务逻辑越复杂，命令式需要做的工作便越多，因为你要完整去描述整个过程才能实现。而声明式却不需要，只要把结果交给声明式框架，声明式框架背后的命令帮忙做了大量的工作，所以在效率上，命令式和声明式不可同日而语。

更完整更系统

jQuery 只是一个工具，它能做的仅仅是在使用层面加一点速，无法带来质变。而声明式的框架带来了完整的开发体验、系统的打包和发布。

2.2 声明式 -> AIGC 式

我也不知道该如何命名，索性就将其称为 “AIGC式” 了。

前端开发范式演变：声明式 -> AIGC 式

虽然声明式为前端开发带来了极大提升，从效率和完整性皆是。但，有一点它还是没有解决，还是有大量的重复劳动性的工作需要开发者来实现，比如模板编写、样式开发、基础函数编写等等，

这也是为什么，社区出现了大量的诸如低码这样工具来力图解决此问题。

设计稿转代码：像我这样的切图仔几乎每天都在使用的 CoDesign/Figma，能够很大程度上解决手动写模板写样式的工作。图片转代码：相较设计稿转代码，它想要做得更多，直接生成模板结构和样式，一键复制即可在项目中运行，比如 imgcook。低代码/零代码：似乎几乎每隔几年就会在社区里炒起来，以腾讯的 UICore 为代表的，在声明式范式下，为能够更加彻底地解决重复劳动，降低开发成本而出现。

工具虽多，也很好用，但这些工具发展了这么多年，似乎并没有能够彻底改变前端开发。

为什么呢？因为这些工具相对于声明式而言，其实和 jQuery 相对于原生 js 是一样的。都没有逃离所处的范式，jQuery 没有逃离 js 的命令式，这些工具也没有逃离声明式。

原地打圈，不得始终。

那 AIGC 式做到了吗？当然，否则也不用讲了对吧。声明式仍然需要前端工程师辛苦地码代码，即便有工具可以提效，但码农依旧得不到解放，至少大部分业务情况下是无法解放的。

而 AIGC 彻底地颠覆了这一范式，具体如何颠覆的，相信文章开头的视频已经给出了答案，从理解到设计再到编码，甚至部署发布， AI 已经不可阻挡了。

那在这样的范式下，作为前端工程师，要怎么样才能亦步亦趋紧跟紧跟再紧跟呢？

03 下一代前端工程师

AIGC 对前端工程师，准确来说对所有人，都是福音而绝不是洪水猛兽。接纳它，用好它，让它成为自己的 copilot。

很多同学会担心 AI 会取代自己，或多或少都有些许担忧，居安思危是没错的，但完全没必要过多焦虑，我们要做的很简单：

**学会使用工具：**人类和动物的区别，不就是因为人类会探索会使用工具吗？工具的出现绝不是为了取代人类，而是服务于人类。**拥抱它、融入它：**不知道五六十年代的前辈们刚接触电脑时是怎样的想法，想来，也会有些人会觉得电脑会替代自己吧。例如电子邮件的出现，那些靠写信为生人一定会有这样的担忧吧，此时，如果他们故步自封不懂得接纳和拥抱电脑，那么在时代潮流之下，等待他们的一定是被取代；可如果他们拥抱它并且融入它，把电子邮件当做一个工具，以此来提高写信的效率和质量，甚至拓展自己的领域，那么浪潮带来的，一定是肥美的大餐。

3.1 要善于利用

用好，你就已经超越了大部分人了，所谓的码农，不就是用好了某个领域的计算机语言。对于前端开发而言，AI 无疑是最趁手的帮手。

快速生成

正如文章开头视频所示，一个草图就能生成网页代码，如果这个图不是草图，而是完整的设计稿呢？当然，很多同学会问，这与 imgcook 不就差不多了，非也非也，imgcook 是固定模式下的产物，而这个生成是自由、灵活且方便的。除了图以外，文本描述同样能实现相应的效果。

ChatGPT 生成网页

实现的基本效果如下，做到如下，看起来是简陋了一些，但是可以在此基础上继续让 AI 进行丰富。

ChatGPT 生成网页的结果

代码编写

相信非常多的同学都已经用 GPT 来辅助写过代码了，写个冒泡啥，但这似乎无法用在我们工作中哈，下面就举几个在我实际工作中 AI 辅助写代码的例子吧，算是简单地抛一块砖：

**辅助写正则：**正则本身不难，但要想写好写全以避免遗漏，还是有难度的，而且我们的工作中经常会遇到些正则的场景。

前端大神 antfu 的一个用于在 vue2 中写 script setup 的插件中就用到了正则，但他也没写全，导致匹配问题。

希望匹配的字符串是：

<script 任意字符 setup 任意字符 />

库中写的正则如下：

/<script\s(.*\s)?setup(\s.*)?>/

一眼看起来没啥问题，可是，这个正则没匹配到换行的场景。

<script任意字符setup任意字符
/>

遗漏很正常，且看如何利用 AI 来修复这个问题：

ChatGPT 生成正则

ChatGPT 对生成的正则进行解释

只需要简单地描述清楚需求，就能得到答案。也许最终答案并非完全正确，但至少它能给你巨大的帮助和启发。

**复杂逻辑编写：**对于大部分做中后台前端项目的前端来说，似乎自己更多的是 js 工程师，要做的就是逻辑上的处理，比如想要实现文件切片上传，每一片 512 kb，如果文件小于 1M，不需要分片，同时，分片的情况下为每一片打好标记以便于后端接口。

将此任务交给 GPT，让其完成功能方案设计，逻辑编写。

ChatGPT 生成功能方案

具体的结果这里就不展示了。

**代码检查：**只要是人写的，就难保不会出错，所以 CR 基本都植入到了工作流之中。现在完全可以让 AI 来帮忙完成这一过程。当然，要注意资产隐私问题。

ChatGPT 进行代码检查

3.2 要纵观全局

声明范式下，**前端工程师是作为 “框架” 与 “产品” 之间的桥梁。**AIGC 下，前端工程师成为了 “AIGC” 与 “产品” 之间的桥梁。

可能有些同学不太理解这段话，下面我们来从开发流程上来解释一下。

在以前，从需求文档到最终产品上线，存在 4 个层级：

产品经理自然语言编写的需求文档；产品经理描述需求时，前端工程师构建的业务逻辑；前端工程师将业务逻辑转化为代码逻辑；用框架语言实现业务逻辑。

其实，前端工程师在整个流程中充当一个什么样的角色呢？很简单，就是 “框架” 和 “需求文档” 间的中间人，前端工程师将需求文档翻译成框架语言，就这么简单。

在 AIGC 下，整个开发流程发生了变化，层级只有 3 个了：

产品经理自然语言编写的需求文档；产品经理描述需求时，前端工程师构建的业务逻辑；前端工程师利用 AI 来实现业务逻辑。

此时，前端工程师仅需要用自然语言来描述业务逻辑，然后交给 AI，让模型输出代码。自然，此时，前端工程师的角色就是将业务逻辑搬运给 AI。

比如，某产品（网页）上希望能实现一个定时推送消息的功能（用户持续访问网页 30s 后推送）。此时，在前端工程师看来，其代码逻辑就是一个定时器，用自然语言就给 AI 来实现即可：

业务逻辑转化为代码逻辑

在 AI 进入开发流程后，前端工程师能做的不仅仅只有简单的逻辑转义到框架了，还能做地更多。

设计系统

前端设计系统描述了系统的主题、复用的组件以及区域等，然后基于此来搭建一个或多个产品的最终的网页或者应用程序，从而简化大规模的设计。之前，这样一套设计系统几乎都是由设计和交互同学来进行制定。但是使用 AI 辅助下，前端工程师同样可以做到，比如：

利用 AI 设计一套定制的主题、组件、设计语言和研发框架。或者基于现有设计系统，获得更优设计系统的建议。

产品设计

产品的设计需要考虑非常多的因素，市场、人群、地域等等，基于对这些因素的了解缺乏，前端工程师对于产品功能的设计几乎很难提供有效的建议，而前端工程师是真正离用户最近的一环，应当具备相应的敏感度。在 AI 的辅助下，这些因素不再是困扰前端工程师参与产品设计的障碍了。

3.3 要懂得批判

把 AI 用到平时的开发中能够极大地提高效率，但 AI 所给到的信息就一定是符合的吗？

除了与 AI 工具合作，控制它们产生的输出，前端工程师还应该花更多时间专注于 AI 的产出的准确性。我们可以用 AIGC 的产物来增强和改善网站和应用的用户体验。但是，这些产物可能并不完美，存在一些缺陷和问题，因此进行评估和解决。

AI 可以给工程师赋能，工程师也应当发挥领域专业知识和判断力，以确保最佳结果。

评估 AI 产物的可靠性和效果

需要对使用 AI 产物的效果进行评估，以确保其能够达到预期的效果。这包括对 AI 产物的性能、准确性、稳定性等方面进行评估，以确保其能够满足用户的需求和期望。

改进 AI 产物的设计和实现

AI 辅助完成了重复性劳动工作，但对于不完美的 AI 产物，设计和实现进行改进，以提高其可靠性、效果和用户体验。

3.4 要合理使用

工具是来辅助你的，不是替代你的。

**
**

需要明确的是，AI 工具并不能替代我们的工作，它们只是辅助我们完成工作的工具。因此，掌握好专业领域知识，才能更好地利用 AI 工具，提高工作效率。

同时，请不要滥用 AI，AI 协助无可厚非，但所有的事情都交给 AI 不可取。

04 未来可期

AI 技术是前端工程师的一种有力工具，可以帮助我们提高开发效率，消除重复劳动。相信 AIGC 下的前端工程师们不再需要把时间花在曾经的切图上，而是更加专注于领域深层的思考。

随着 AI 技术的进步，一定会有越来越多的前端工程会被自动化，这是必然的趋势。这就需要前端开发者所掌握的技能组合发生转变，紧跟技术的趋势。重要的是，前端工程师们要相信，自己永远不会被机器彻底取代。虽然 AI 能够让许多任务自动化，但它无法拥有你的创造力和独创性。

总的来说，未来乃至现在的前端工程师们需要对新技术要有高适应度，并且需能够融入 AI，学会与 AI 协作，同时不断结合自己领域知识。如此，未来的工程师们定未来可期。

05 望天下再无码农

其实，一直有一个愿望，望天下再无码农。

希望 AI 迅猛发展吧，让一切的无聊重复劳动都交给 AI，让未来的前端工程师能够更多地从事创新性的工作，让机器去完成重复性的任务，让人类的智慧更好地服务于人类的社会。

愿天下再无码农。

06 探讨

6.1 AIGC 下，前端会消失吗？

之前看到一篇文章，是这样说的，前端从 jQ 发展到 MVVM，门槛降了一波，只要会一点代码，就能拿起脚手架开撸；如今，前端从 MVVM 发展到 AIGC，前端已死呀。

我的观点是：“前端工程师永远都不会消失，它可能换了一种形态，也可能变了一种展示方式，但它绝不会消失。” 我赞同一个观点， AI 工具将会被整合进开发者工具当中，用来扩大熟练开发者的生产能力。木匠并没有被电动工具所替代，会计师没有被电子表格替代，摄影师没有被数码相机/智能手机替代，所以前端工程师也不会被 AI 替代。只是未来前端工程师到底需要怎样的技能，这个不得而知，但可以预见的是，学会使用 AI 是必经之路。

6.2 前端开发工程师会过分依赖 AI 吗？

很多同学认为，AI 的强大会让开发者不由自主地去使用它，未来，开发同学会不会过分地依赖 AI 呢？

我的观点是：“依赖没什么不好，如今你我不是每天都依赖电脑，依赖手机吗？看你怎么用罢了，工具没有好坏，人才会有。” 好的工具被人们所依赖，这是天道自然，我们要做的就是，不要过分依赖。有了电脑，我们依旧要学习用手写字；有了汽车，我们依旧要迈开双腿跑步；学会合理利用，自然就不会过分依赖。如果觉得本篇分享对你有帮助，欢迎转发分享。

参考链接：

[1] ChatCPT：https://openai.com/blog/chatgpt

[2] What is the Impact of AI and ML on Front-End Development?：https://www.projectcubicle.com/what-is-the-impact-of-ai-and-ml-on-front-end-development/

[3] 生成式 AI 颠覆前端：https://foresightnews.pro/article/detail/27847

[4] 预测前端开发模式的变化：https://juejin.cn/post/7216182763237818425