1. 先把“消失”这个词拆开哪些活是真的没了这两年我参与过几次前端岗位的面试也帮几个团队做过技术选型和人员盘点最直观的感受不是“前端没人要了”而是同一个岗位名称下面装的东西正在被换掉。2026 年这个时间点被反复提起本质上不是某个职业会一夜之间蒸发而是岗位内部的工作配比发生了位移那些高度模式化、可被描述成“把 A 转成 B”的活正在被工具吞掉而那些需要判断、需要兜底、需要对业务后果负责的活反而变得比以前更贵。所谓“另一个正在崛起”指的就是后者——一个以 AI 应用工程为核心能力、以交付完整用户价值为目标的混合型角色很多团队干脆就叫它“AI 应用前端”或者“产品工程师”。这篇文章不打算贩卖焦虑也不打算画大饼。我会把话说清楚哪些具体的活正在减少、减少到什么程度、为什么留下来的能力到底长什么样新起来的这个角色每天在干什么、需要哪些硬技能最后给一条我自己验证过、能落地的迁移路线以及一段可以直接抄走的流式对话界面代码。刚入行的、工作三五年的、带团队的朋友都能在里面找到自己该补的那一块。1.1 被压缩的是“翻译型”工作量我习惯把前端的工作分成两类翻译型和决策型。翻译型指的是把一种已经确定的表达机械地转换成另一种表达——设计稿转成 DOM 结构、接口文档转成请求函数、需求文档里的字段转成表单控件。这类工作的特点非常鲜明输入明确、输出可验证、边界情况少、重复率高。而这三四年里被压缩得最厉害的就是它。具体到日常感受最深的有这几块。一是静态页面与组件骨架给一张设计稿生成结构合理、类名规范、响应式断点齐全的代码现在几分钟就能出初稿人只需要做审查和微调。二是中后台的 CRUD 页面列表、筛选、分页、弹窗表单、增删改查这套东西的形态二十年没变过一旦有了统一的 schema 描述生成质量相当稳定。三是样板代码请求封装、错误提示、loading 状态、类型定义这些曾经占据大量时间的胶水代码现在基本可以一次配置、批量产出。注意这里说的是“工作量被压缩”不是“人完全不需要了”。生成出来的东西仍然需要有人判断对不对、合不合规范、会不会在低端设备上崩掉。区别在于过去你花 80% 时间写、20% 时间想现在这个比例反过来了。这个变化对初级岗位的冲击最直接。以前一个新人靠“能照着设计稿把页面写出来”就能站稳脚跟现在这个门槛几乎被抹平了。我见过一些团队在招人时明确不再考察“手写一个轮播图”这类题目因为考不出任何区分度——它已经不能反映候选人的真实价值了。1.2 留下来的是“决策型”能力和翻译型相对的是那些没有标准答案、需要权衡取舍的工作。这类工作有个共同点做错了会有真实后果而且后果往往不在代码层面而在体验和业务层面。举几个我天天在处理的例子。第一是交互方案的取舍。一个表单有 14 个字段是全铺开、分步骤、还是先填三个核心字段再渐进补充每种方案在转化率、完成时长、错误率上的表现都不一样这个判断工具给不了你得靠对用户的理解和对数据的敏感。第二是异常兜底设计。接口超时了是重试、是降级、还是静默失败重试几次指数退避的基数取多少这些决定直接影响用户感知而生成工具只会写“理想路径”。第三是性能预算的分配。一个页面首屏 300KB 还是 800KB把预算花在图片压缩上还是花在减少请求数上这种全局权衡需要有人拍板。还有一块特别重要但经常被忽略可观测性设计。页面上线之后用户在哪一步卡住了、哪个按钮点了没反应、哪个接口的 P95 延迟突然翻倍这些问题的答案要靠提前埋点、靠错误上报、靠链路追踪。搭这套东西的难度不在于写代码而在于提前想清楚“我需要知道什么”。这是我见过区分度最高的能力之一也是工具目前最难替代的部分。1.3 影响范围三类前端正在明显分化我把身边的同行大致分成三类这两年的走向差异非常大做成表格更直观。类型主要工作内容这两年的变化应对方向页面实现型切图、还原设计稿、写静态页面需求量和岗位数同时下降竞争加剧尽快往交互与状态管理方向补中后台业务型CRUD、表单、权限、流程配置单页面工作量下降但需要人做架构和规范往“平台化规范制定”方向走复杂交互与工程型可视化、编辑器、性能优化、工程体系需求稳定甚至上升议价能力变强叠加 AI 应用能力形成复合优势这个分化不是一年之内完成的但从我接触到的招聘需求看第一类的岗位描述正在肉眼可见地减少而第三类的描述里越来越多地出现“有 AI 应用落地经验优先”。这不是巧合它反映的是企业真实的成本核算能被清晰描述的活就一定会被更便宜的方式完成。2. 岗位迁移的底层逻辑价值重心为什么在上移理解了“哪些活没了”还得理解“为什么会没”。如果只是把它归结为工具变强那推导出来的结论只能是“赶紧学工具”这既不准确也不够用。真正发生的事是软件交付链路里价值密度最高的一环换了位置。过去它在下游把东西做出来现在它在上游决定做什么、怎么判断做对了。2.1 从“像素还原”到“意图还原”传统前端的核心契约是“设计稿长什么样页面就长什么样”考验的是对细节的还原能力。但在 AI 应用里用户输入的东西天然是模糊的、不完整的、带歧义的。用户说“帮我看看这个月的数据”他到底要的是趋势图、是异常项、还是和上个月的对比这中间需要有人设计澄清机制、设计默认值策略、设计“猜错了怎么优雅地纠正”。我把它叫做意图还原从一句模糊的话里推导出一个可执行的操作并且为推导错误准备好退路。这件事的技术含量远高于像素还原因为它同时涉及交互设计、状态机设计、错误处理策略。举个具体的例子一个搜索框传统做法是输入关键词、请求接口、渲染列表而意图化的做法是先判断这句话是查询、是比较、还是筛选再决定调用哪个工具、以什么形态展示结果、结果不理想时如何引导用户补充条件。这中间每一步都是判断题。2.2 从“组件复用”到“能力复用”第二个位移是从组件层上升到能力层。以前我们讲复用讲的是按钮、表格、弹窗这些 UI 组件现在讲复用讲的是“一个能被调用的能力单元”——比如“查询订单状态”这个能力它可能对应一个接口、一段提示词、一套结果渲染规则。界面的职责从“展示数据”变成了“编排能力”。这个变化带来的直接后果是前端需要理解的东西变多了。你得知道这个能力在什么条件下会失败、失败之后返回什么结构、返回的结构怎么映射到界面上。我见过不少项目在这里翻车后端返回了一个嵌套三层的错误对象前端按最外层的 message 直接弹了个“操作失败”用户完全不知道自己该干嘛。这类问题的解法不在 UI 层而在于提前定义好能力契约。2.3 成本结构的重算判断力为什么变贵了还有一个更底层的原因算力成本在快速下降而判断错误的成本在上升。生成一段代码几乎不要钱但这段代码如果引入了微妙的竞态问题排查成本可能是写它的十倍。同理模型返回一段内容几乎不要钱但如果这段内容渲染错了、被用户误解了、或者触发了不合适的操作代价就很高。所以企业真正愿意付钱的不是“能写代码的人”而是“能让系统在不确定情况下依然可控的人”。这个能力包含三块一是定义边界知道什么该交给自动化、什么必须人来把关二是设计兜底任何一步失败都有明确的降级路径三是建立反馈上线之后能快速知道哪里出了问题。这三块加起来就是我在前面说的“决策型能力”的具体化。3. 正在崛起的那个岗位AI 应用前端到底做什么说了半天“崛起的是什么”该给个具体画像了。我把它叫做AI 应用工程岗很多团队的职位描述里写的是“前端工程师AI 方向”或者“产品工程师”。它不是一个新的技术栈而是一种新的交付视角从用户说一句话开始到最终看到一个可信的结果结束这整条链路由你负责。3.1 岗位职责的真实切面我把这个岗位的日常拆成五块按出现频率排序。第一块是流式交互的承载也就是把模型逐步返回的内容平滑地渲染出来包括打字机效果、中途中断、重新生成、内容滚动时的定位控制。这块看着简单做起来坑极多后面我会专门讲。第二块是结构化结果的渲染模型返回的往往不是纯文本而是需要被解析成卡片、表格、步骤条甚至可交互表单的结构解析失败要有降级方案。第三块是多轮状态管理。对话不是无状态的用户可能在第 5 轮提到“还是用刚才那个条件”你得能把它找回来。这块本质上是前端状态机的活只是状态的来源更复杂。第四块是工具调用结果的可视化模型决定调用某个能力返回的结果需要以合适的形态呈现加载中、成功、失败、部分成功每种状态都得有对应的界面。第五块是成本与体验的平衡包括请求去重、结果缓存、超时控制、按需加载历史记录。提示这五块里真正需要“前端功底”的是第一、第三、第五块需要“产品思维”的是第二、第四块。如果你只有其中之一补齐另一边的速度比想象中快。3.2 技能地图与三个常见误区硬技能方面我的排序是这样的TypeScript 的熟练度排在第一位因为流式数据的结构极其多变没有类型系统兜底会非常痛苦其次是浏览器原生的流处理能力也就是fetch配合ReadableStream、TextDecoder这套东西很多人只会用封装好的库出了问题是完全抓瞎的第三是状态管理的一致性尤其是并发场景下的状态覆盖问题第四是结构化数据的校验JSON Schema 或类似的校验方案要会用第五是基础的可观测性埋点、错误上报、耗时统计。这里有三个误区我踩过或者见过别人踩。第一个误区是把它当成提示词工程。写提示词只是其中很小的一环绝大多数线上问题出在数据流和渲染层不在提示词。第二个误区是一上来就上框架。市面上的对话 UI 库确实能省事但如果不懂底层怎么解析流遇到“内容重复渲染”“中断后状态残留”这类问题会完全无从下手。第三个误区是忽视非功能需求。移动端弱网、长时间会话的内存增长、大量历史消息的滚动性能这些才是真正拉开差距的地方。3.3 一份 90 天可落地的迁移路线如果你现在的工作还是以页面实现为主我建议按下面这个节奏走每一步都有可交付的成果不至于学了一堆东西却拿不出手。阶段时间目标交付物一第 1-2 周把手写流解析跑通一个能逐字渲染、能中断的最小对话页二第 3-4 周掌握结构化输出与校验返回值能渲染成卡片非法结构自动降级三第 5-6 周掌握多轮状态与工具调用支持“继续上一步”和至少一个能力调用四第 7-8 周补齐性能与可观测性长列表不卡顿关键节点有耗时埋点五第 9-12 周完整落地一个真实场景一个内部可用的小工具有真实用户这个路线里我最看重的其实是第四阶段。因为前三阶段的东西网上资料很多照着做都能跑起来但性能和可观测性没有标准答案你踩过坑才会有感觉。而恰恰是这部分在面试和实际工作中区分度最高。4. 动手实操搭一个流式对话加结构化渲染的界面空谈不如动手。这一节我把一个最小可用版本拆开讲包括目录结构、流解析、结构校验、渲染优化。技术选型是 TypeScript 加 React但思路对 Vue 或原生同样适用。4.1 技术选型与目录结构选型上我有几个明确的偏好。请求层直接用原生fetch不用额外的请求库因为流式响应的处理最终都要落到response.body.getReader()多一层封装反而挡路。校验层用 Zod 这类 schema 库理由很实在它能在运行时给出结构化的错误信息而不是抛一个笼统的异常。渲染层用 React 的并发特性配合requestAnimationFrame做批量更新避免每个字符都触发一次渲染。目录我一般这样切src/ api/ streamChat.ts # 流式请求与解析 schemas/ message.ts # 消息与卡片的结构定义 hooks/ useChatStream.ts # 对话状态机 components/ MessageList.tsx # 虚拟滚动的消息列表 MessageItem.tsx # 单条消息渲染 CardRenderer.tsx # 结构化内容渲染 utils/ throttleFrame.ts # 帧级批量更新这样切的好处是职责清晰streamChat只负责“把字节变成对象”useChatStream只负责“把对象变成状态”组件只负责“把状态变成界面”。出了问题能快速定位在哪一层。4.2 流式解析的核心实现服务端返回的通常是按行分隔的事件流每行以固定前缀开头最后有一个结束标记。解析的关键在于缓冲区管理网络分片不会按你的意愿切分一次读到的内容可能是半行、可能是一行半必须自己拼。export type StreamEvent | { type: delta; text: string } | { type: card; payload: unknown } | { type: error; message: string }; export async function* streamChat( prompt: string, signal: AbortSignal, ): AsyncGeneratorStreamEvent { const res await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ prompt }), signal, }); if (!res.ok || !res.body) { yield { type: error, message: 请求失败: ${res.status} }; return; } const reader res.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; try { while (true) { const { done, value } await reader.read(); if (done) break; // stream: true 保证多字节字符不会被截断 buffer decoder.decode(value, { stream: true }); // 事件之间以空行分隔最后一段可能不完整留在缓冲区 const blocks buffer.split(\n\n); buffer blocks.pop() ?? ; for (const block of blocks) { const line block.trim(); if (!line || line data: [DONE]) continue; const raw line.replace(/^data:\s*/, ); try { yield JSON.parse(raw) as StreamEvent; } catch { // 单条解析失败不应该中断整个流 yield { type: error, message: 事件解析失败 }; } } } } finally { reader.releaseLock(); } }这段代码里有三个地方值得单独说。第一处是decoder.decode(value, { stream: true })这个参数至关重要。中文是多字节编码如果每次分片都独立解码一个汉字被切成两半时就会变成乱码而且这种 bug 只在特定网络条件下复现极难排查。第二处是blocks.pop()保留最后一段因为网络分片很可能把一行切成两截必须等下一次数据到达再拼。第三处是单条事件的解析失败不抛异常而是转成一个错误事件继续往下走这样用户至少能看到部分结果而不是整个界面卡死。4.3 结构化输出的校验与降级渲染模型返回的结构化内容不可全信。字段少给、类型给错、数组超长这些情况我都遇到过。所以校验必须做而且降级方案必须提前想好不能等到线上报错再补。import { z } from zod; export const CardSchema z.object({ kind: z.literal(card), title: z.string().min(1).max(60), items: z.array(z.string().max(120)).min(1).max(5), }); export type Card z.infertypeof CardSchema; export function renderCardOrFallback(raw: unknown) { const parsed CardSchema.safeParse(raw); if (!parsed.success) { // 降级一字段可能只是多了几个尝试宽松解析 const loose z .object({ title: z.string().optional(), items: z.array(z.unknown()).optional() }) .safeParse(raw); if (loose.success loose.data.title) { return { level: degraded as const, title: loose.data.title, items: (loose.data.items ?? []).slice(0, 5).map(String), }; } // 降级二完全无法解析退回纯文本展示 return { level: fallback as const, text: JSON.stringify(raw).slice(0, 200) }; } return { level: ok as const, ...parsed.data }; }这里我用了两级降级。第一级是宽松解析只取能用的字段保证界面不会开天窗第二级是退回原始文本虽然不好看但至少信息没丢。上线之后我发现真实场景里第一级降级触发的比例比预想的高不少主要原因不是模型乱答而是字段长度偶尔超出限制。4.4 渲染性能批量更新与虚拟滚动流式渲染最容易被忽视的问题是渲染次数。如果每收到一个分片就setState一次一秒内可能触发几十次渲染在长对话场景下会明显掉帧。我的做法是用requestAnimationFrame做帧级合并一帧之内收到的所有分片只触发一次更新。export function createFrameBuffer(onFlush: (text: string) void) { let pending ; let rafId 0; function flush() { rafId 0; if (!pending) return; const chunk pending; pending ; onFlush(chunk); } return { push(text: string) { pending text; if (rafId) return; rafId requestAnimationFrame(flush); }, dispose() { if (rafId) cancelAnimationFrame(rafId); rafId 0; pending ; }, }; }配套的还有两件事。一是消息列表必须做虚拟滚动只渲染可视区附近的消息节点否则几十轮对话之后 DOM 节点数量会爆炸滚动会明显发涩。二是自动滚动要区分“用户正在看历史”和“用户停留在底部”两种情况前者不能强行把他拽回底部否则体验极差。我的判断逻辑是看滚动容器距离底部是否小于一个阈值通常取 80 像素左右这个值我调过几次太小会误判太大会让用户觉得卡住了。5. 踩坑实录这几个问题我几乎每次都遇到下面这些不是我一次踩完的是反复在不同项目里撞见慢慢总结出来的。列出来是为了让你少走弯路。5.1 布局抖动与内容闪烁流式渲染最典型的视觉问题就是抖动。原因主要有两个一是文本增长导致容器高度不断变化把下方内容顶来顶去二是结构化的内容和纯文本混排时切换过程会出现瞬间的空档。解法不复杂但必须做。给消息容器预留最小高度并且对正在流式输出的消息使用contain: content之类的布局隔离避免它影响兄弟节点。同时把“正在生成”的状态用独立的占位元素表达等结构完整了再整体替换而不是边生成边替换。还有一个隐蔽的坑是字体加载导致的二次回流。自定义字体加载完成之后文字宽度变化会让整个布局重排一次配合流式输出就会显得特别跳。我的处理是提前用font-display控制或者干脆在首屏关键区域用系统字体。注意任何“看起来只是闪一下”的问题在移动端和低端设备上都会被放大。我习惯在性能面板里开 4 倍降速跑一遍很多在开发机上察觉不到的问题会立刻暴露。5.2 模型输出不稳定怎么兜底不稳定的表现形式比想象的多格式对但内容为空、格式错了但内容对、中途断流、返回了预期之外的字段、甚至返回了两份重复内容。我的一般策略是分三层处理。第一层是校验用 schema 卡住结构第二层是重试但重试要有限制一般最多两次而且第二次要更换策略比如降低对格式的要求第三层是兜底展示实在不行就展示原始文本加一句说明让用户知道发生了什么。这里有个经验不要静默吞掉错误。早期我为了界面干净解析失败就直接不渲染结果用户以为功能坏了反馈的全是“点了没反应”。后来我在消息下方加了一行小字提示“内容格式异常已为你展示原始结果”投诉量立刻降下来了。用户能接受不完美但不能接受莫名其妙。5.3 成本与体验之间的那道线这块说的人少但实际项目里绕不开。流式请求不像普通接口用户可能在生成到一半的时候改主意、关页面、刷新。如果不做处理这些请求会一直跑到结束白白消耗。我的做法是在组件卸载时通过AbortController主动中断同时服务端配合做中断检测。另外历史消息要做截断策略不可能把所有轮次都带上一般是保留最近若干轮加上一条摘要具体的轮次数要按实际场景调我通常从 6 轮起步试。还有一个容易忽略的点是重复请求。用户连点两次发送按钮、或者网络抖动导致的自动重试都可能产生重复内容。前端侧我一般加一个短时间的状态锁同一个会话在生成中不允许再次提交这个锁的粒度要按会话而不是按页面否则多标签场景会互相干扰。5.4 一份排查速查表现象高概率原因排查手法处理方式中文出现乱码分片解码未使用流式模式打印原始字节长度比对解码时加stream: true内容显示不全最后一段缓冲未处理在流结束时打印剩余 buffer结束时补一次解析重复渲染同一段状态更新用了旧值检查 setState 是否函数式改用函数式更新长对话越来越卡DOM 节点过多看元素面板节点数量上虚拟滚动滚动条乱跳自动滚动未区分用户意图记录滚动位置变化加距离阈值判断卡片偶尔空白schema 校验过严打印失败样本增加宽松降级分支关闭页面后仍在消耗未主动中断请求看服务端连接数卸载时 abort6. 几句实话关于转型我自己是怎么走过来的我不太喜欢“转型”这个词它暗示着要丢掉过去重新开始但实际上我做的事情一直是同一件把用户的一句模糊需求变成一次可靠的交付。以前这句话的形态是“把这个页面做出来”现在它的形态是“让用户能顺畅地完成这件事”。变的只是中间那段链路长了、不确定的地方多了需要我在更多节点上做判断。如果非要说有什么具体的体会我想分享三点。第一别急着追新名词。我见过太多人把精力花在记各种框架和概念上结果连一个流式请求的中断都处理不利索。底层的东西变化很慢fetch、ReadableStream、状态一致性这些掌握扎实了上面的东西换多少轮都不慌。第二一定要有真实用户。哪怕是给同事做的一个小工具只要有几个人天天用你遇到的问题就会比看十篇教程都真实。第三把踩过的坑记下来。我有个习惯每次排查完一个疑难问题就写三五行笔记记清楚现象、原因、解法两年下来这些笔记比任何文档都好用因为它们全是真问题。至于 2026 年会不会真的“消失”我的判断是岗位名称可能会变招聘描述里的关键词会换但那种“把复杂问题拆开、把不确定变成可控”的能力任何时候都缺人。真正危险的不是岗位消失而是手里只有一套只能用在特定场景的手法换个环境就不灵了。手上多一门能落到具体交付上的本事比追任何一个热点都实在。