我是在一次迭代评审会上意识到这件事的。
产品经理正在演示一套新的用户引导流程：动画干净流畅，页面能够适配不同尺寸，表单验证也完全按照我们在需求规划时讨论的方式运行。我坐在会议桌对面，一边看她操作，一边等她说出这个功能是谁开发的。因为实现里有一个细节，我想会后找对应的前端工程师确认一下。
然而，她始终没有提到开发者的名字。
会议结束后，我主动问了她。她告诉我，自己先通过 Figma Make 从设计文件里直接生成 React 组件，再把代码交给 v0 整理 TypeScript，最后按照团队的标准流程提交审查。整个过程只花了 48 小时。
直到代码审查阶段，她都没有向工程团队寻求过任何帮助。而那条 Pull Request，恰好还是我批准的。
当时，我甚至没有真正弄清楚那些代码是怎么来的。
功能已经进了生产环境，可我一行代码都没写。回到工位后，我先看了看自己尚未完成的工单，又打开了迭代看板。随后，我坐在那里沉默了很久，脑子里反复出现一个此前从未认真想过的问题：如果产品经理能够在 48 小时内，把一份 Figma 设计直接变成生产功能，全程不需要前端工程师参与，那么前端工程师在这条流程中的角色，到底还剩下什么？
Figma 改变一切之前，前端在做什么
我想先说清楚，传统前端工程师到底负责什么。因为用“被替代”三个字来概括正在发生的变化，其实并不准确。
过去的前端开发是一条明确的交接链。设计师先在 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 加入日常工作流？过去原本需要工程团队投入的那些时间，现在去了哪里？
这场讨论需要尽早发生。否则，等我们真正看懂全部变化时，迭代看板可能早已替行业给出了答案。
发表于 3 天前
|
查看: 2|
回复: 0
