我是在一次迭代评审会上意识到这件事的。产品经理正在演示一套新的用户引导流程动画干净流畅页面能够适配不同尺寸表单验证也完全按照我们在需求规划时讨论的方式运行。我坐在会议桌对面一边看她操作一边等她说出这个功能是谁开发的。因为实现里有一个细节我想会后找对应的前端工程师确认一下。然而她一直没有提到开发者的名字。会议结束后我主动问了她。她告诉我自己先使用Figma Make从设计文件中直接生成React组件再把代码交给v0整理TypeScript最后按照团队的标准流程提交审查。整个过程只花了48小时。直到代码审查阶段她都没有向工程团队寻求任何帮助。而那条Pull Request恰好还是我批准的。当时甚至没有真正弄清楚那些代码是怎么来的。功能已经进入生产环境。可我一行代码都没有写。回到工位后我先看了看自己尚未完成的工单又打开了迭代看板。随后我坐在那里沉默了很久脑子里反复出现一个此前从未认真想过的问题。如果产品经理能够在48小时内把一份Figma设计直接变成生产功能全程不需要前端工程师参与那么前端工程师在这条流程中的角色到底还剩下什么一个很香的 AI 平台GPT-5.6 低倍率且不降智 和 Claude Code 4.8 只要 0.25倍率包含 image-2生图。重点是 首字请求都在 5s 内。入口https://ai.aiyuhub.comFigma改变一切之前前端在做什么我想先说清楚传统前端工程师到底负责什么。因为用“被替代”三个字来概括正在发生的变化实际上并不准确。过去的前端开发是一条明确的交接链。设计师先在Figma中完成设计稿然后把文件交给前端工程师。工程师再把视觉设计转换为代码处理设计效果与技术可行性之间的差距。在这个过程中前端需要管理页面状态对接后端API设计组件结构处理响应式布局补齐设计稿无法表达的交互细节在视觉效果与工程限制之间作出取舍。前端工程师既理解设计意图也清楚技术边界。他的真正价值是在设计与系统之间搭建一座桥梁。而现在正在消失的恰恰是这座桥。不是因为前端工程师造桥的能力变差了而是因为已经出现了能够自动完成大部分搭建工作的工具。Figma Make使用Claude直接从设计文件生成可交互的React应用。你可以用自然语言描述需求也可以从已经存在的设计稿出发让工具生成相应组件。随后Vercel的v0可以继续整理和完善这些代码。过去从设计师的想法走到可用于生产的组件需要一名同时了解设计系统和TypeScript的专业工程师。如今这条流水线的大部分环节已经可以在没有前端工程师深度参与的情况下运行。这不是遥远的未来。它就发生在我的那场迭代评审会上。当智能体从设计文件出发我想具体描述一下现在从Figma走向生产环境的流程已经完整到了什么程度。因为很多没有亲眼看过的人可能仍然认为AI生成前端只是做出一个看起来相似、实际无法使用的页面。设计师首先打开Figma Make。他可以用自然语言描述组件也可以直接选中现有设计元素要求工具生成对应代码。系统会读取设计Token间距规范字体与字号颜色体系组件关系页面结构。随后它会生成符合设计系统的React组件。不是勉强接近也不只是“看起来差不多”。在标准场景中它可以相当准确地还原设计。生成结果再进入v0继续调整。接下来可以由工程师补充交互、管理状态并连接API。当然也可以由设计师或产品经理自己完成。这些工具已经把过去纯技术性的前端工作开放给了任何真正理解“这个组件应该做什么”的人。前端工程师在流程中并没有彻底消失。仍然需要专业判断的部分包括组件在大规模使用时如何运行AI经常忽略哪些无障碍要求当前状态管理方案会不会影响应用其他模块生成代码是否符合团队已有架构页面在异常数据和复杂边界情况下是否可靠。真正的专业能力依然重要。只是与18个月前相比它被需要的范围已经缩小了。而那些已经不再依赖深度专业知识的工作过去恰好占据了我们大部分时间。评审会之前我其实早该发现回过头看变化早就已经出现。只是当时的我没有把那些迹象连接起来。在用户引导功能上线前两个迭代我们团队悄悄停止了设计到开发的正式交接会议。我确实注意到过但当时以为设计团队只是越来越擅长制作不需要额外解释的Figma文件。这个判断并不完全错误。设计文件的确变得更容易交付。但真正原因是设计团队已经开始在完成设计的同时生成组件。于是交接讨论的重点不再是如何把视觉稿翻译成代码而是业务逻辑与系统集成。再往前一个迭代合作团队中的一名初级前端工程师曾随口提到她最近收到的工单明显减少了。她以为是产品路线发生了调整。她也只说对了一部分。产品路线确实改变了但它开始更多地倾向于那些设计团队可以通过Figma Make完成原型、甚至直接交付的功能。于是标准UI工作不再大量进入工程队列。当时这两件事在我眼里都不构成某种趋势。它们只是工作流程中的小调整。事实上它们也确实是小调整。然而当这些小变化不断积累它们同时也成了另一组早期数据在我的公司里负责完成前端工作的人正在发生结构性改变。那些很难直视的数据评审会结束后我开始寻找相关数据。我想知道眼前的变化究竟只发生在我的公司还是整个行业都在经历同样的事情。越来越多专门的前端岗位正在被吸收到全栈职位中。至少有一项行业分析认为对于标准UI开发而言从Figma到AI组件再到生产环境的流程已经接近闭环。而正在被压缩的工作类型恰好就是今年之前最占用我时间的内容表单管理仪表盘落地页CRUD界面常见UI模式标准响应式布局。市场变化的速度可能比大多数前端工程师意识到的更快。因为这种压缩不是通过一次公开宣布完成的。它是逐渐发生的。一张工单接着一张工单。一个迭代接着一个迭代。没有人宣布组织重构也没有人告诉你岗位即将消失。前端工程师依然在职。只是公司开始发现完成同样数量的产品功能已经不再需要过去那么多专门的前端工时。这种威胁与裁员并不相同。裁员有明确日期也会出现在日历邀请中。而这种变化只会让你的迭代看板一次次提醒你这个季度分给你的工作似乎比上个季度又少了一点。我现在仍然在做什么关于AI与工程师的讨论经常走向两个极端。一种观点完全否认威胁认为AI生成的代码永远无法用于真实生产。另一种观点则认为工程师已经失去全部价值很快会被彻底取代。这两种说法都不准确。从Figma到生产的自动化流程仍然有很多事情做不好。它无法真正决定当一万个用户同时操作时组件架构应该如何扩展。根据WebAIM在2026年的分析95.9%的AI生成界面仍然存在无障碍问题。自动化工具也无法可靠识别这些失败。它更无法充分理解一套经历多年演进的代码库不知道两年前为什么采用某种设计模式更不清楚贸然修改之后会破坏哪些隐藏逻辑。如果一段AI生成的身份验证流程在并发用户增加后发生错误仍然需要有经验的工程师发现问题。如果表单缺少aria-label导致依赖键盘或辅助技术的用户几乎无法操作也仍然需要真正理解无障碍设计的人指出来。如果某种状态管理方式会在系统规模扩大后引发连锁故障最后负责识别并阻止它的通常还是资深前端工程师。这样的工程师依然不可或缺。真正的问题并不是他们是否还有价值。问题是当大量标准UI工作已经被工具压缩后一家公司究竟还需要多少这样的工程师对于大多数公司来说答案很可能是比过去更少。反复想到的那件事完成用户引导流程的产品经理并没有故意绕开我。她不是在试图排挤工程团队更没有把自己的行为理解为对前端岗位的重构。她只是使用公司提供的工具以当时最高效的方式解决一个需要解决的问题。在她看来这不过是一种更快的功能交付方式。而现实中的岗位变化往往就是这样发生的。不是管理层召开会议正式决定替代前端工程师。而是48位产品经理和设计师各自作出48个独立决定使用自己已经拥有的工具把手里的功能先做出来。每一个决定单独看都非常合理。然而当它们汇集到一起结果就不再只是效率提升那么简单。上周我把这段经历告诉了团队里的一位Staff Engineer。他认真听完只问了我一个问题如果六个月后每个产品经理都能使用这些工具而且已经完全掌握了它们你的工作会变成什么样我当时没有答案。直到现在我仍然在寻找答案。也许未来的前端工程师不会再以“把设计稿写成页面”为核心工作。角色可能会逐渐转向制定前端架构与技术规范审核AI生成代码处理复杂状态与系统集成保证性能、安全和无障碍建设组件平台与设计系统为产品和设计团队提供工程护栏解决自动化工具无法覆盖的异常与规模问题。这些工作更重要也更接近真正的工程判断。但它们的数量未必足以支撑过去那么大的纯前端团队。这才是最令人不安的部分。前端工程不会消失。真正可能消失的是大量以“设计稿翻译成代码”为主要内容的前端岗位。我很想知道你正在看到什么。如果你是一名前端工程师过去两个季度里你的工单数量发生变化了吗你是否亲眼看过某项功能正式上线而它并不是由你或其他前端工程师开发的如果你是产品经理或设计师你是否已经把Figma Make或v0加入日常工作流过去原本需要工程团队投入的那些时间现在去了哪里欢迎把经历写在评论区。这场讨论需要尽早发生。否则等我们真正看懂全部变化时迭代看板可能早已替行业给出了答案。