2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

“前端已死”是危言耸听吗?

  • 2025-03-02
    北京
  • 本文字数:10937 字

    阅读完需:约 36 分钟

“前端已死”是危言耸听吗?

随着互联网技术的快速发展,大前端领域正经历着前所未有的变革。从传统的 Web 开发到移动应用、小程序、IoT、乃至新兴的 AR/VR,大前端技术不仅需要适应越来越多样化的需求场景,还面临着如何更高效地利用现有资源、提升用户体验等挑战。那么,前端开发的本质变了吗?“AI 代替前端”是危言耸听吗?


近日 InfoQ《极客有约》X QCon 直播栏目特别邀请了淘天集团 1688 终端架构负责人曹立成(蒜蓉)担任主持人,和快手基础架构中心负责人周全菜鸟网络资深技术专家唐爽 一起,在 QCon 全球软件开发大会2025 北京站 即将召开之际,共同探讨前端在 AI 时代下的生存法则。


部分精彩观点如下:

  • 会 AI 不一定让你不被淘汰,但是不会 AI 早晚会被淘汰。AI 不会淘汰你,把 AI 用好的人可能会淘汰你,淘汰你的从来都是人。

  • 全栈化改革的目标是减少中间的协同成本,让一个开发者能完成更多任务,同时将更专业的人才放在更需要专业技能的岗位上

  • AI 对前端领域的冲击,实际上对有经验的资深开发者是一个利好。

  • AI 目前还不是神,它仍然像一个 3 到 4 岁智力的孩子,我们需要为其提供更加细致的指导,以确保其能有效工作。

  • 虽然 AI 可以完成大量工作,甚至高达 80% 的工作量,但那剩下的 20% 才是最为关键的部分,而这正是我们人类的优势所在。


在 4 月 10-12 日将于北京举办的 QCon 全球软件开发大会上,我们特别设置了【越挫越勇的大前端】专题。该专题将深入探讨大前端技术在当前及未来一段时间内的演进趋势及其实践案例,特别是在面对不断变化的技术环境时,如何通过融合最新科技成果来推动大前端技术的进步。查看大会日程解锁更多精彩内容:https://qcon.infoq.cn/2025/beijing/track


以下内容基于直播速记整理,经 InfoQ 删减。


完整直播回放可查看:https://www.infoq.cn/video/IoNRKHcNaV3p0TPX2JFz


前端开发的本质发生了什么变化

曹立成: 我们都知道,前端行业这两年变化很大,AI 让代码生成更容易,全栈化让前端的边界变得模糊,甚至很多人都在问:前端开发会被 AI 取代吗?全栈是进化还是无奈?写代码不重要了,关键是怎么向 AI 提问,让它产出更好?今天这场直播就是要直面这些扎心的问题!


我们先从一个最基础的问题聊起——前端开发的核心问题变了吗?过去,我们前端工程师天天研究怎么写代码、怎么优化性能、怎么造轮子。但现在,AI 工具越来越强。有人说:“前端已经不是如何写代码的问题,而是怎么结合 AI 快速产出的问题”,你们怎么看?前端开发的本质真的变了吗,有哪些痛点?


曹立成: 我认为现在前端与客户端的边界逐渐模糊,近年来“大前端”概念的兴起和公司组织架构的调整都体现了这一点。尽管形式上有所变化,开发的本质并未改变。过去,前端领域常被称为“娱乐圈”,充斥着各种框架和工具,甚至有一些开发者因此成为“小明星”。然而,近年来这种现象减少,行业更加关注技术的实际价值。许多大厂为了 KPI 推出的项目,往往只是制造轮子,未能解决根本问题。如今,行业更注重技术的实际应用。尽管轮子数量减少,但对工程师的技术要求却提高了。经过多年的优胜劣汰,行业逐渐回归理性。许多框架和技术方案并未真正解决本质问题,开发的核心仍然在于代码本身。


AI 在前端开发中提供了一些辅助,例如低代码搭建和上层 UI 开发。然而,在中间件和底层开发领域,AI 的帮助有限。在底层代码的采纳上,开发者仍持谨慎态度。前端开发不仅涉及 JavaScript,工具链复杂,边界也在不断拓宽。此外,前端还涵盖 VR、AR 等混合现实技术,涉及图形学、音视频处理等多学科知识。AI 在这些领域的辅助作用有限,尽管它可以取代一些初级工作,例如编写简单的 UI 组件。


从我个人的经验来看,AI 在代码生成方面的采纳率较低。去年,我的代码中 AI 生成的部分不到 10%。尽管 AI 能力增强,但它更适合作为提效工具,而非完全替代开发者。因此,无论是 Web 前端还是客户端开发,开发者都应更加关注语言本质和性能问题,AI 无法解答代码在不同环境下的执行效率和内存消耗等具体问题。这些影响因素复杂多样,仍是开发者需要关注的重点。


周全: 我认为这个问题有些危言耸听,AI 带来了量变,但尚未形成质变。举个例子,团队中常有新人或外包人员协助开发代码,他们能否完全替代正式开发者?显然不能。代码仍需 review、质量检测、自测和优化,这些环节离不开正式开发者的参与。AI 工具的作用与此类似,它可以帮助生成代码,但开发者仍需主导整个过程。


此外,我想问大家多久更新一次开发工具或效率工具?例如,终端工具、IDE、插件等。过去多年,开发工具一直在迭代,从 Turbo C 到现代 IDE,再到各种插件,效率工具从未停止进步。然而,从未有人质疑这些工具会取代开发者。使用新 IDE 提升 10% 的效率,并不意味着团队可以裁员 10%。效率工具无法完全取代开发者,但它们是开发者必须掌握的技能,掌握这些工具可以显著提升开发效率和竞争力。如果开发者连基本的工具更新都跟不上,那么被淘汰是迟早的事,与 AI 无关。


AI 工具确实带来了效率的提升,让开发者能够更快地输出代码和理解需求,掌握 AI 工具的开发者将更具竞争力。因此,问题的核心不在于 AI 是否会取代前端开发,而在于开发者是否能够适应技术进步。会 AI 不一定让你不被淘汰,但是不会 AI 早晚会被淘汰。


唐爽: 前端开发的方式确实在不断变化,但这种变化与 AI 关系不大,而是技术发展的自然结果。我刚开始工作时,还在解决 IE6、IE7 的问题,而现在前端技术的本质并未改变。前端始终是用技术解决业务端的问题,而不是单纯依赖 JavaScript。业务端的问题涉及需求、体验、性能、创新、埋点、数据可视化等多个方面,这些都是前端岗位的核心。


AI 的出现确实减少了重复性代码的编写,例如函数生成等任务,AI 比人类更快。然而,AI 生成的代码仍需人工评估,业务逻辑的调整和优化也离不开开发者的参与,因为只有开发者最清楚业务需求。AI 提升了编码效率,但也带来了新的挑战。例如,AI 可能在项目中生成重复代码,如果没有统一的架构和管控,项目腐化的速度可能会加快。因此,AI 并未降低对开发者的要求,反而要求开发者具备更高的经验和能力,以确保项目的可持续维护性。


观众:AI 时代给前端开发带来了哪些改变?有 AI 加持后,整个前端会往什么方向发展?


周全: 大前端是最接近用户的岗位之一,仅次于产品经理和运营。因此,前端开发者不仅需要专业能力,还需要较强的横向能力和产品思维,以确保动效、用户体验和性能能够满足用户需求。过去,移动端开发主要局限于自身平台,难以参与 AI 等新兴领域,因为这些领域的技术门槛较高,通常需要专业背景,如神经网络和大数据。


然而,随着 AI 技术的发展,尤其是大语言模型的出现,技术门槛显著降低。前端开发者虽然不直接参与模型训练或算法设计,但可以在应用层接入 AI 能力,从而扩展开发范围。这种变化使得前端开发者的优势更加明显,因为他们具备较强的产品能力和横向能力。当 API 的使用变得简单时,前端开发者能够更快地将技术转化为用户价值和业务价值。此外,大前端带有一定的全栈属性。


过去,前端开发者若想涉足后端开发,可能需要学习 Python、SQL 等技术,学习成本较高。而现在,AI 工具可以快速解答技术问题,降低了学习门槛。这使得前端开发者能够更高效地掌握后端、SRE 等领域的技术,从而提升综合能力。


唐爽: 我赞同周老师的观点,AI 时代为前端带来了很好的机遇。过去由于技术和岗位的限制,前端工作主要集中在页面设计和切面实现。现在,我认为前端岗位是最接近用户的,因为我们非常熟悉产品的形态。

前端虽然不是数据的生产者,但却是数据的第一消费者。虽然我们不是交互设计专家,但了解每个交互细节。借助大模型工具如 Cursor、Copilot,开发效率大大提升,过去需要多人合作的工作现在可以由独立开发者完成。有了大模型,许多以前依赖算法的工作变得更容易,而我们熟悉产品界面的实现,可以将这两者结合,完成过去无法做到的任务。


前端岗位将从代码实现者转变为智能体验的架构师或设计师,这些变化使得我们可以将一些普适性和重复性的工作交给 AI 来完成,从而为我们创造更多时间去进行创新和探索例如,我们团队一直在做低代码系统,菜鸟有一个叫“文生应用”的功能,它允许用户通过自然语言描述所需的页面,AI 就可以自动生成该页面。这不仅仅是完成 UI 的设计,AI 还会自动生成元数据和后端数据结构,整个页面可以直接上线并运行。这种系统是前端工程师实现的,展示了过去无法想象的可能性。


曹立成:我们发现 AI 确实能提高生产力,前端开发者的价值也正在改变,这也引出了我们的下一个问题——前端为什么越来越全栈化?以前,我们可以做纯前端,切页面、写组件、调接口,后端的事不管。但现在,有些公司招聘前端都要求懂一点后端,比如 Node.js、数据库、微服务,甚至直接让前端变成全栈开发。大家怎么看,你们公司对前端的要求有什么变化?


唐爽: 菜鸟在过去几年一直在进行全栈化改革,主要将服务端开发人员培养为前端开发者,同时也让部分前端开发者参与服务端的工作。现在,菜鸟没有严格区分前端和后端岗位,而是更多地采用全栈开发模式,所有开发者都被称为“开发工程师”。目前,约 80% 的页面都是由全栈开发人员完成。这些开发人员既负责前端也负责后端,开发模式主要依赖低代码工具。通过低代码体系,原本从事 Java 开发的员工能够快速上手前端工作,快速完成页面开发。这一模式在菜鸟的业务背景下非常有效,尤其是我们 80% 的业务是面向 B 端的 PC 端,主要是各种管理系统。


前端开发的挑战不在于技术复杂度,而在于与服务端的联调。过去,前端与后端的协作往往会增加很多成本,特别是在页面内容和数据处理上。菜鸟希望通过全栈开发,减少这些协同成本,让一个人能负责前后端的开发。菜鸟的全栈化改革并不是让开发者做简单的 CRUD 页面,而是让他们能深入到业务逻辑的层面。前端开发者不仅要做页面开发,也可以参与到业务需求和技术实现中,逐步转向更复杂的工作,提升职业发展的深度。


低代码体系使得前端开发者可以快速适应并参与更多业务工作。同时,一些更复杂的页面,像大屏展示、双十一特殊页面、消费者端和互动游戏等,依然需要前端专家的参与。这些领域需要更高的前端专业能力,也为前端开发者提供了更多挑战和机会。举例来说,我们将传统的 100 多个下拉框整合为一个智能搜索框,提升了 60% 的工作效率,这种创新是传统需求接收和手工开发无法实现的。


全栈化改革的目标是减少中间的协同成本,让一个开发者能完成更多任务,同时将更专业的人才放在更需要专业技能的岗位上,这推动了菜鸟整个技术体系的不断演进。然而,这也带来一些挑战,比如是否会因为全栈化而忽视前端专业性。虽然全栈化可以扩展开发者的技能广度,但前端的专业能力依然重要。全栈化并不意味着放弃专业技能,而是将更多任务整合,让开发者在多个领域发挥作用。


周全: 全栈并不是一个新概念,每隔几年就会被讨论一次。我在 2014 年毕业时加入豆瓣,当时我们称之为“产品开发工程师”,工程师不局限于某一领域,而是为整个产品负责,哪里需要就去做什么。后来,随着前端技术的成熟,全栈的概念逐渐兴起。如今,全栈或大前端的概念如何理解,取决于个人以及所在组织对 ROI(投资回报率)的看法。


对于组织而言,小厂通常希望员工具备全栈能力,能够应对各种问题。然而,大厂则更倾向于专业化分工,不需要员工跨领域填补空缺,而是希望每个人在自己的领域成为专家,发挥最大价值。这种专业化分工在过去一段时间内占据主导地位,大前端的概念也因此被淡化。


然而,随着效能的提升,全栈和大前端的概念再次被提及。首先,企业开始注重成本控制,不再无限制地招聘人员。例如,字节跳动等公司已经开始“去肥增瘦”,优化人员结构。其次,学习成本降低。借助 AI 工具和现有技术,开发人员可以快速切换到其他领域。只要具备基本的研发思维和架构能力,换个语言或平台的成本已经大大降低。AI 工具还能帮助开发人员快速识别和解决技术问题。第三,互联网经过多年的发展,效能基建和分工已经相对成熟。一部分人继续走专家路线,专注于高精尖领域;另一部分人则通过低代码等工具,专注于业务开发。例如,前端的低代码平台和后端的 FaaS(函数即服务)让业务开发变得更加简单。开发人员只需关注业务逻辑,而不需要深入了解底层技术细节。这种分工模式使得业务开发人员的认知复杂度降低,他们只需关注最基本的逻辑即可完成开发任务。这种全栈岗位在成本和效能上达到了较好的平衡。


对于个人而言,是否选择大前端路线取决于职业发展规划。有些同学适合专注于某一领域,成为专家型开发人员,这部分人才在行业中依然稀缺。有些同学则横向能力较强,借助现有工具,可以在全栈领域创造更大价值。


曹立成: 不仅仅是前端开发,所有工种的价值都在发生变化,现在正处于一个大融合的阶段,前端的要求也在变化。淘天集团正在将前端和客户端合并,这与大前端的概念相似,都是在拓宽边界,只是它拓宽的方向是前端和客户端,而不是与服务端的融合。例如,当我们在 APP 里展示 H5 页面时,页面的加载速度和用户体验不仅仅是前端或客户端的问题,而是需要跨工种合作来解决。解决这个问题的方式要么是团队内有融合型的工种,要么是资深开发者同时精通客户端和前端,能独立解决。


无论是业务团队还是技术团队,实际问题都是跨工种的。现在,团队更多是围绕问题和解决方案进行调整,而不是单纯按工种来划分。AI 对前端领域的冲击,实际上对有经验的资深开发者是一个利好。因为他们在某一领域已有深度,拓展其他领域的广度成本较低,AI 可以帮助他们快速进入新领域解决问题。


曹立成:底层技术创新如何影响上层变革?


周全: 这是一个正向命题,底层技术的变革必然引发上层的调整。互联网领域常提到的金字塔原理和第一性原理都表明,底层的变化会直接影响上层的开发模式、效率和交付方式。更关键的问题是,如何让上层在底层技术变革时能够放心、低成本地适应,并符合公司和团队的价值导向。过去,前端领域曾出现大量重复造轮子的现象,不同团队使用不同的技术栈,最终经过试错才确定统一的技术选型。然而,如今团队没有足够的时间、资金和人力去试错,必须快速找到适合的技术方向,这对决策者提出了更高的要求。


当前的技术环境也发生了变化。过去,后端技术更新较慢,追求稳定;移动端以年为单位更新;而前端则以周为单位快速迭代。但现在,所有技术的迭代速度都放缓了。无论是移动端还是开源社区,都缺乏令人眼前一亮的创新技术。因此,如何在现有环境下通过底层技术变革推动业务价值,成为当前的核心问题。


底层技术的变革需要满足三个条件:一是变革必然发生;二是控制变革成本;三是找到创新的技术方向。如何通过正确的底层技术变革带来业务价值,是当前需要探讨的重点。这与上一个话题类似,底层技术的选择同样需要评估 ROI,只有当收益足够大时,决策者才会支持变革。


以跨端技术为例,快手曾尝试过多种技术(如 Flutter、Uni APP 等),但踩过不少坑。如今,面对鸿蒙系统的兴起,我们在选择跨端技术时非常谨慎。例如,KMP(Kotlin Multiplatform)在鸿蒙上的实践效果不错,但在公司内部仍面临质疑:这项技术能否真正为公司带来价值?毕竟,过去的技术尝试并未完全成功。

选择底层技术时,必须算清账:它是否能在短期内带来收益,并在长期内创造持久价值?以跨端技术为例,鸿蒙系统要求开发三个 APP,而通过跨端技术,我们可以将开发成本降低 66%。此外,KMP 允许复用现有安卓代码,进一步节省了人力成本。综合考虑性能、稳定性和生态支持,KMP 成为我们的优选。技术的选择还需要评估其长期成本,不能只追求短期收益,而忽视技术的可持续性。例如,Flutter 近期因团队稳定性问题受到质疑,而 KMP 则因其稳定的生态支持和较低的维护成本脱颖而出。


推动底层技术变革,首先需要评估技术的收益和成本,确保其能为团队带来实质价值。其次,工程师需要具备专业能力,能够通过技术经验和行业趋势做出准确判断。最后,技术的选择还需与现有生态互补,避免重复造轮子。


唐爽: 刚加入菜鸟时,许多业务系统是基于 PC 端的供应链和仓库管理系统,而竞争对手已转向移动化。由于多年的积累,不同时期的系统体验不一致,亟需解决。我们的解决方案是通过技术手段解决业务问题。我常强调三句话:通过建设某个平台或技术手段,实现某种技术能力,最终帮助业务达成目标或解决问题,这三者相辅相成。


当时菜鸟的业务主要基于 PC 端,已有上万个页面。如何快速适配移动端?重新开发一套移动端系统工作量巨大。我们通过低代码体系和统一的设计模式、前端组件体系,实现了一码多端:只需在低代码平台配置 PC 端页面,即可自动适配移动端。这不仅限于响应式设计,而是通过运行时和编译时的转换,完全模拟移动端原生效果,实现“买一送一”——开发一次 PC 端,自动生成移动端。这一底层技术让菜鸟的业务自动具备 PC 和移动端适配能力,大幅减少开发成本。许多业务不再依赖 PC 端操作,员工可以随时随地通过手机处理任务。即使某些操作仍需 PC 端,移动端也能在紧急情况下使用,且开发成本几乎为零。此外,我们的低代码平台积累了上万个页面的描述信息。结合 AI 技术,这些数据可以生成千人千面的内容。例如,根据仓库运营人员的岗位、工作习惯和时间段,自动推荐相关数据。这是低代码与 AI 结合带来的未来探索方向。


底层技术的变革不仅影响了业务,也推动了组织变革。由于大量页面通过低代码搭建,设计师和产品经理的岗位逐渐融合。设计师从仅负责交互设计,扩展到参与产品链路设计,拓宽了职业发展路径。前端开发人员通过低代码了解业务逻辑,从页面逻辑转向业务逻辑,职业发展更加立体。


曹立成: 提到底层技术时,不一定指内核或汇编语言,而是一个相对概念。近年来,像 DeepSeek、鸿蒙系统以及 Meta、苹果的 AR/AI 技术,都是底层技术的发展。这些进步影响了上层产品的使用方式,带来了普惠性的变化,例如,微信正在逐步推出 AI 搜索功能。这些变化表明,近年来底层技术的创新,尤其是 AI 领域的进步,正在迅速推动上层产品和服务的转型,甚至影响了各行各业的工作方式与价值边界的拓展。

前端开发者如何“转型”


曹立成: 现在的前端方向,甚至整个软件开发的主旋律,就是看哪家公司能把 AI 用得更好,例如工程化方面,审查代码、分析项目结构、分析需求等等。想请各位结合经验分享下,AI + 前端,开发流程是否被重塑了,日常工作中,AI 用得好与不好的关键点在哪?以及 AI 的局限性又在哪?


唐爽: 我们使用 VS Code 和 Composer 时,虽然大家使用的是相同的工具和模型,但效果往往因人而异。比如,我们在使用 Composer 时,时间长了可能会遇到一些问题,比如产生幻觉或者代码错误不断增加。那么如何解决这种问题呢?我的做法是:我会同时管理多个 Composer,每个负责不同的任务。例如,一个 Composer 专注于组件开发,另一个负责应用工程开发。专门做组件开发的人员只需要专注于组件本身,应用开发的人员则非常熟悉业务逻辑和页面逻辑,清楚如何与服务端接口对接。而数据埋点开发人员则专注于用户行为的埋点,熟悉整个埋点体系。通过这样的分工,可以确保每个人专注于自己的职责,不会互相干扰。


如果所有任务都交给一个人来做,他的工作量会非常大。而且,在团队中很难找到一个全能的员工。所以,不要强求 AI 解决所有问题,它的上下文也有其局限性。当然,如果连自己的业务逻辑都没有理清楚,就在一个大型工程中开发新功能,这时就不能强求 AI 去解决问题了。在这种情况下,AI 只能为你提供一些启发。所以,首先要理清楚自己的思路,制定一个大致的架构蓝图,然后再去利用 AI。


周全: 尽管业界有很多关于 AI 的讲座,吹捧其神奇效果,实际应用时我们却遇到不少问题。例如,AI 的代码补全和错误排查功能效果较差,有时会给出错误的代码改动建议,甚至在完美的代码中提出多个无关的修改问题,造成效果不理想。


我们还尝试过将 AI 用于“全能”的场景设计,比如让 AI 帮忙创建团队、管理 Git 仓库等,但这些尝试效果不佳,最终我们得出了一个结论:AI 的应用应该更加聚焦和细化,按照场景来分配任务。比如,在进行代码审查时,AI 不应只是全面地列出问题,而应该专注于某一类问题,比如查找 Java 代码中的 NPE(空指针异常)。


AI 目前还不是神,它仍然像一个 3 到 4 岁智力的孩子,我们需要为其提供更加细致的指导,以确保其能有效工作。在实际应用中,通过使用 AI 工具,我们可以自动处理常见的编译错误和相关问题,减少人工干预。这大大提高了效率,节省了人力资源。然而,我认为当前阶段 AI 的智力水平仍然有限,适合用于一些特定场景和细节问题,能够有效节省人力,但不会带来革命性的突破。


代码本身既是逻辑又具有艺术性,AI 目前难以一次性解决其中的复杂思维问题。因此,我们不应对 AI 有过高的期待,而应将其应用于具体且可落地的场景中,以获取更实际的收益。我们在未来的一到两年内应避免将 AI 过于理想化。


曹立成:AI 确实在进步,但我也深刻感受到它的局限性。比如,我有时会写一些 Gradle 脚本,Gradle 语言相对冷门,我尝试让 AI 帮我完成脚本开发,结果发现它生成的代码看起来很漂亮,但实际上根本无法执行。经过反思,我认为这可能是因为我对某些方法是否存在都不确定,而 AI 在这种情况下容易产生“幻觉”,生成一些看似合理但实际上不存在的方法。


后来我发现,当某个领域的资料或代码库比较丰富时,AI 的表现会好一些,因为它本质上依赖于学习已有的数据。但如果资料稀缺,AI 就容易凭空创造,生成一些看似合理但实际无效的代码。这种经历让我意识到,AI 目前还无法完全替代程序员。它虽然在某些场景下能提供帮助,但在复杂或冷门的领域,仍然需要程序员的专业判断和调试能力。


曹立成:在 AI 辅助写代码、跨端开发等等趋势下,前端开发者需要如何转型?是否还需要关心技术?


唐爽: 首先,我们仍然需要继续关注技术。正如我刚才提到的,AI 的出现并没有降低对人的要求,反而提高了要求。因此,对于刚入职的同学,我认为不需要过于担心,关键还是要打好基本功。正如我们之前讨论的,很多项目的架构是需要在复杂的业务中逐渐积累经验的。一个好的架构并不是设计出来的,而是在实践中逐步完善的。有些架构可能是前人经验的积累,你可能没有亲自参与其中,但你仍然可以从中学习。


第二,随着技术的发展,我们需要更好地理解如何提出有效的问题,这是一个至关重要的能力。我们往往难以准确表达问题,尤其是在向 AI 提问时,如何提供适当的信息和上下文是至关重要的。


第三,AI 不会替代人类工作。虽然 AI 可以完成大量工作,甚至高达 80% 的工作量,但那剩下的 20% 才是最为关键的部分,而这正是我们人类的优势所在。AI 的智能水平虽然很高,但它无法取代人类的判断和情感价值。无论是从纯技术角度,还是如何通过技术放大商业指标,AI 目前都无法完全替代。无论是否有 AI,行业的发展仍然在继续。即使没有 AI,技术人员也不可能在同一个岗位上工作一辈子。而且有一个事实值得承认:从前端领域晋升为 CTO 的案例相对较少,相比之下,后端或更懂业务的人晋升为 CTO 的可能性较大。


在 AI 时代,转型的机会依然存在。例如,我的团队中有些人从传统的代码实现者转变为智能体验架构师;过去仅仅负责页面逻辑的人员,逐渐深入到业务领域,成为了小型业务团队的领导者,并有可能在未来晋升为某一领域的 CTO。


我认为,持续学习是非常重要的。在我刚开始从业时,技术主要集中在 PC 端,后来又经历了移动互联网时代。每隔几年,技术发展都会带来一些困惑,前几年元宇宙的兴起也让我们讨论是否应该涉足这一领域。随着 AI 的出现,这些技术变革依旧持续,迫使我们不断学习和适应。AI 的出现为前端开发人员提供了更多的机会。利用好 AI,不仅能提升产品体验,还能完成以往难以实现的任务,尤其是在小规模团队中,甚至是初创公司,这种转变变得更加可行。


周全: 互联网时代永远不变的就是“永远在变”。我记得我上大学的时候,最常用的手机是诺基亚。当时,全班几乎每个人都用诺基亚,但到了 2014 年,几乎所有人都换成了安卓或 iOS 手机。这个变化是显而易见的。同样的,技术也在变化。当时我们做前端开发时,最老的开发者逐渐被淘汰。而现在,我们回头看,PC 端的使用者越来越少,大家都转向了移动端。比如当时使用淘宝时,我认为移动端非常难用,而更倾向于使用网页端,因为网页端可以同时比较多个页面,但现在大家都习惯了移动端,这就是变革。环境和用户的习惯在变化,技术也需要随之调整。从跨端开发到各种操作系统的出现,例如鸿蒙系统、MIUI、ColorOS 等。作为开发者,我们无法忽视这些变化。技术不断演进,我们需要随时适应新的开发场景。这是市场和技术环境的必然变化。


现在,我已经超过 30 岁,写代码的能力比一些年轻的同学差了很多。然而,我依然能够跟上变化,依靠 AI 工具来生成代码。因此,我认为技术环境的变化虽然会带来挑战,但我们依然可以通过学习和适应,不断提升自己的能力。


其次,“Talk is cheap, show me your code”,这句话意味着,我们不应仅仅依赖空谈和理论。对于现在的年轻人来说,AI 的出现确实让很多人开始焦虑。是否意味着我该转行,或者是不是应该多学一些 AI,甚至使用低代码或无代码工具来生成代码?我认为,首先大家可以亲自尝试这些 AI 工具,这些工具的开源代码和文档都已经非常完善,大家完全可以通过实践来理解和应用它们,看看它们是否能在实际场景中提升工作效率。


很多人产生焦虑,可能是因为他们已经失去了亲自实践、动手操作的能力。AI 当前非常火,但未来会是什么?如果我们看一些科幻电影,可能会看到更先进的技术出现。新的技术不断涌现,可能会取代当前的技术。我们需要做的就是适应这些新技术,并利用它们让自己变得更强。


曹立成: 关于 AI 是否能替代我们的问题,本质上是大家内心的焦虑所引发的。无论是 AI 的冲击,还是裁员、行业发展、经济不景气等因素,都可能让我们感受到压力。在这样的背景下,大家的焦虑是可以理解的。面对 AI 时,我常常通过提问来增强自信,当发现 AI 无法解决我的问题时,我就觉得自己依然不可替代。


以最近很火的《哪吒》电影为例,这部电影花费了五年的时间,才完成了每个镜头的打磨。制作团队并没有很强的资金支持,但他们坚持自己的理念,最终得到了回报。这个过程告诉我们,做事需要耐心和坚持。技术领域也是如此,真正做出优质框架或技术方案的团队,能在实践中解决问题,最终会获得认可。


从技术角度讲,认真做出来的技术方案能给用户带来真实的价值。当用户感受到你技术方案的有效性时,你就成功地解决了他们的问题。这个过程需要我们踏实地走下去,而 AI 的出现更多是为那些不太踏实的上层人员带来冲击,真正的技术人员会一步一个脚印地走得更远。


关于是否需要转型的问题,我认为这与个人的职业发展密切相关。作为前端开发者,是否转型并没有标准答案,每个人的路径不同。然而,是否继续关注技术这一点,我认为答案是肯定的。只要你在这条船上,无论你在船头还是船尾,只要船起航了,它就能带着你前进。技术是这条船的动力源泉。很多人希望不被时代抛弃,虽然不一定要成为时代的领袖,但至少不想被落下。因此,关心技术的变化是必要的,技术变化背后原因的分析过程才是值得我们深入思考的,AI 目前还无法替代这种过程。

2025-03-02 15:019933

评论

发布
暂无评论

【web 开发基础】PHP中的预定义数组(46)

迷彩

php web开发基础 11月月更 预定义 超全局数组变量

React源码分析4-深度理解diff算法

goClient1992

React

Hadoop完全分布式环境搭建(三节点)

指剑

hadoop Bigdata 11月月更

CentOS-7.2部署Squid服务

指剑

centos 11月月更 squid

(一)OpenStack---M版---双节点搭建---基础环境配置

指剑

centos OpenStack 11月月更

Centos 7.2搭建MariaDB数据库服务器应用与管理

指剑

centos MariaDB 11月月更

Flink Forward Asia 2022 主论坛概览

Apache Flink

大数据 flink 实时计算

AI简报-重参数化RepVGG

AIWeker

深度学习 AI简报 11月月更

湖仓一体电商项目(十六):业务实现之编写写入ODS层业务代码

Lansonli

湖仓一体电商项目 11月月更

Python第三方模块:PyQt5简介

指剑

Python PyQt5 11月月更

CentOS-7.2部署OpenLDAP服务器以及客户端

指剑

centos openldap 11月月更

【web 开发基础】PHP中数组的遍历(45)

迷彩

数据结构 数组 foreach 11月月更 数组遍历

React源码分析5-commit

goClient1992

React

react源码中的fiber架构

flyzz177

React

世界杯火热进行中, 用一个div画个足球场助助兴

南城FE

CSS css3 前端 足球场

AWS之EC2搭建WordPress博客

指剑

AWS WordPress 11月月更

投入上百人、经历多次双 11,Flink 已经足够强大了吗?

Apache Flink

大数据 flink 实时计算

【web 开发基础】PHP中多维数组的声明 (44)

迷彩

数据结构 一维数组 二维数组 11月月更 多维数组

React源码分析6-hooks源码

goClient1992

React

xxl-job客户端架构流程

IT巅峰技术

Centos 7.2安装FTP服务并进行相关设置

指剑

centos ftp 11月月更

【React技术】开发过程中遇到State和生命周期方法在类里面的运用

恒山其若陋兮

前端 11月月更

python小知识-内置方法和属性应用:反射和单例

AIWeker

Python python小知识 11月月更

湖仓一体电商项目(十五):实时统计商品及一级种类、二级种类访问排行业务需求和分层设计及流程图

Lansonli

湖仓一体电商项目 11月月更

Spark编程基础(Python版)

指剑

Python spark 11月月更

Centos 7.2搭建HTTP服务,并进行相关配置

指剑

centos httpd 11月月更

react源码中的hooks

flyzz177

React

【web 开发基础】PHP中使用array()语言结构新建数组(43)

迷彩

数据结构 array 11月月更 array() 新建数组

Discourse 的左侧边栏可以修改吗

HoneyMoose

react hook 源码完全解读

flyzz177

React

AWS之EC2实例搭建LAMP服务器

指剑

AWS EC2 LAMP 11月月更

“前端已死”是危言耸听吗?_AI&大模型_QCon全球软件开发大会_InfoQ精选文章