从 Claude Code 到岗位存亡，六个问题，一个答案。文中所有数据均为 2026 年 8 月实时查询。备注：本文包含AI辅助
写在前面：一个很多人都有的困惑
我最近被问到几个问题，我觉得它比大多数「AI 会不会取代程序员」的讨论都诚实：
现在有了 Claude Code 这样的编程智能体，常用功能它都有。我作为前端，拿到这个工具之后，还能做点什么来提升团队效率？
有人写 skill，有人把同事做成 skill------我觉得这些没什么价值。除非是 100% 重复的流程，但 100% 重复的流程写个脚本效果也一样。所以我实在想不到还能做什么。
这个困惑很真实，而且我认为它的前半部分基本是对的。
企业确实不需要重造一个 Claude Code；把同事人格做成 skill 确实是玩具；100% 确定的流程确实该写脚本。
但这个推理漏掉了一件事，而这件事恰恰是整个 AI 时代前端工作方式变化的核心。
一、核心判断：AI 抬高了「确定性」的价格
先说结论，后面所有章节都是它的展开：
AI 让「生产代码」的成本大幅下降，于是「确保代码是对的」成为了新的瓶颈和新的价值所在。
以前一个功能的成本结构大概是：想清楚 20%，写代码 60%，验证 20%。
现在写代码那 60% 被压缩到了 10%。剩下的两头没变，甚至变重了------因为代码产出速度快了，验证的压力反而更大。
工程的重心，从「生产」转移到了「约束和验证」。
这句话听起来抽象，但它能直接推导出六个非常具体的结论。下面逐个讲。
二、拿到 AI 编程工具后，最该做的不是写 skill
先纠正那个「100% 重复」的二分法
原问题里的推理是：100% 重复 → 写脚本；不到 100% 重复 → AI 不可靠。这个二分法漏掉了中间最大的一块。
真实的分布是三段：
| 确定性 | 谁来做 | 举例 |
|---|---|---|
| 100% 机械 | 脚本 / codemod | 生命周期方法改名、语法替换 |
| 70%--90% | AI 智能体 ← 这才是它不可替代的地带 | 拆解语义、逐文件适配、边界情况处理 |
| 靠判断 | 人 | 架构决策、要不要换库 |
中间那块的特征是：工作量巨大、重复度高，但每个文件的细节又都不一样------所以纯脚本搞不定（需要理解语义），人做又纯粹是折磨。
前端有海量这种活：Vue2→3 迁移、类组件转 Hooks、组件库替换、i18n 文案提取、埋点补齐、依赖大版本升级后的适配。codemod 能干掉 70%，剩下 30% 的边界情况以前全靠人肉------那 30% 正是 AI 的主场。
真正决定 AI 表现的两件事，都不在工具里
同一个 AI 工具，在不同代码库里的产出质量能差三倍。差在两个地方：
1. 上下文供给
AI 不知道你们有 <AppButton>，它就会自己写一个 button。不知道你们的请求封装，就会直接 fetch。
这是前端团队用 AI 最典型的失败模式：代码能跑，但污染架构。
解法是项目根目录下一个普通的 markdown 文件（Claude Code 里叫 CLAUDE.md，其他工具有对应机制），里面写人话：
markdown
# 项目说明
- 技术栈：Vue3 + TS + Vite
- 按钮统一用 src/components/AppButton，不要自己写 <button>
- 请求统一走 src/utils/request.ts，不要直接用 axios/fetch
- 状态管理用 Pinia，不要引入 Vuex
- 改完代码必须跑 npm run lint && npm run test
- 不要动 src/payment/ 目录下的任何文件为什么这个文件的投入产出比高于所有 skill 加起来？
因为 AI 每次开始干活都会先读它。你写的每一条约束都作用在之后每一次任务上------这是乘法。而一个 skill 只在特定场景触发一次------这是加法。
这里有个关键认知：AI 没有记忆。 你今天纠正它，明天新开一个会话它照样犯同样的错。它是一个永远不涨记性的实习生。唯一的解法是把规矩写在外面。
顺便说，这也解释了「工程约束沉淀」的真正含义------那些「必须这样、不能那样」的规矩，现在大多存在老员工的脑子里，只有 code review 时才蹦出来一句「这个我们不这么写」。沉淀就是把它们从脑子里搬到文件里。
而且做法很重要：不要坐在会议室里凭空设计规矩。 这周 review 时你说了三次「这里应该复用现有组件」，那就说明这条值得写进去。用实际犯的错来决定写什么。
2. 验证闭环（前端最大的短板）
AI 产出质量的上限，由「它能否自己验证自己」决定。
有闭环，它能自我纠错、循环迭代；没闭环，你就是在当人肉校验器。
后端有类型和单测天然形成闭环。前端的问题是「渲染出来到底对不对」这一环通常是断的。所以前端团队最高杠杆的投入是：
- TypeScript 严格模式 + ESLint 规则完备（这些是 AI 的自动反馈信号，不只是给人看的）
- 组件测试 / E2E 能一条命令跑起来
- 能截图------接上浏览器自动化，让 AI 改完 UI 自己看一眼
- 视觉回归基线
把这几条补齐，你一行 skill 都不用写，AI 的有效产出就会上一个台阶。
三、大规模改造：难点从来不是改语法
有了上面的基础，来看最能体现价值的场景。以 Vue2→3 迁移为例------这类任务的典型质疑是：
业务需求产品自己都说不清，一堆重复代码不知道要不要合并，测试也不会帮你验证。迁移完你敢上线吗？
这个质疑非常真实。我逐条拆。
第一条纪律：迁移不是重构
「重复代码不知道要不要合并」------那就不合并，碰都别碰。
迁移的目标只有一个：换掉底层框架，业务行为一个字都不能变。 那两段丑陋的重复代码，迁移之后依然原样躺在那儿。
为什么必须这么严格？因为一旦你顺手改了业务逻辑，线上出问题时你无法定位------是框架换了导致的，还是你手贱合并那两段代码导致的？回滚都不知道回滚哪一半。
一次只动一个变量，这是所有大规模改造的铁律。
想优化的东西，全部记进一个叫「迁移后再说」的清单。迁完稳定了再单独立项------到那时它是个正常需求，可以正常排期。
第二条：旧代码本身就是需求文档
「产品说不清需求」这件事，在迁移里根本不需要回答。
你不需要知道这个页面「应该」是什么样，只需要保证：它昨天什么样，今天还是什么样。
逻辑里有 bug？照抄。交互反直觉？照抄。没人看得懂？照抄。
这一下就把死结绕开了------迁移不需要产品参与。
第三条：上线的底气不来自「保证不出问题」
没有人能保证不出问题，传统开发也保证不了。
工程上的做法从来不是「确保零缺陷」，而是降低概率 + 让代价小到可以承受。四层保险：
① 先给旧代码补测试------这是 AI 最大的价值点
关键在于测试的写法要反直觉：
- 普通测试是「我认为它应该返回 A，所以断言 A」
- 迁移用的测试是「它现在返回什么，我就断言什么」------哪怕现在的行为是个 bug，也照抄进测试
这类测试叫特征测试（characterization test），作用是刻画现状，不是定义正确。迁移后跑一遍，只要有一个变了立刻报警。
为什么以前没人做？ 给三百个老组件补测试是纯体力活，工作量巨大、毫无成就感，任何团队都排不上这个期。
而这恰恰是 AI 现在能干、而且干得好的事------你不需要它有创造力，你需要它有耐心。
② 视觉回归
迁移前把每个页面截图存成基线，迁移后再截一遍机器比对像素差异。这能兜住绝大部分「样式塌了」------而样式塌了恰恰是迁移最常见的事故。Playwright 自带截图对比，不用额外买服务。
③ 分批上线，不要 big bang
不要憋三个月然后某天晚上「切换」，那是赌博。
这周迁 5 个最边缘的页面（关于我们、内部管理页），上线观察一周；没事，下周迁 15 个。第一批的问题会教你后面 200 个该注意什么。
④ 能一分钟退回去
带开关上线，先放 1% 流量走新版本，盯错误监控。没涨就放大到 10%、50%、100%；涨了就一键关掉。
结论：我不敢一次性全量上线一个没有测试基线的迁移------任何人都不该敢。但我敢在有特征测试 + 视觉回归 + 1% 灰度 + 一键回滚的前提下上线其中 5 个页面。
测试不配合，不意味着你必须扛下所有风险，而意味着你必须把风险切碎。
具体怎么拆成几百个可验证的小任务
第 0 步：先做减法（ROI 最高，多数人跳过）
迁移之前，先删死代码。
前端项目跑几年，通常 20%--40% 的代码根本没人用------下线的活动页、废弃的旧流程、注释掉但没删的组件。
删掉的代码：不用迁、不用测、不用讨论、不用担心出 bug。一行不写就完成的任务是最划算的。
「这个页面还有人用吗？」------产品答不出来，但埋点数据能答。拉过去 90 天的访问量，PV 为 0 的进候选清单。
这一步才是需要产品参与的地方------不是问他「这功能什么逻辑」，而是拿着数据问「这个 90 天没人访问的页面能砍吗」。这个问题他答得了。
第 1 步：用机器扫，不要靠人估
跑脚本扫出确定的数字：
- 一共 412 个
.vue文件 - 用了 filter 的：87 处
- 用了
$children/$listeners的：34 处 - 用了 EventBus 的：19 处
- 依赖 Vue2 专有第三方库的：6 个
「迁移 Vue2 到 Vue3」是无法开始的任务。「改掉这 87 处 filter」是可以开始的任务。
第 2 步：分三桶
按上面那张表分 A（脚本）/ B（AI）/ C（人拍板）。
C 桶的处理原则最重要：不要在迁移过程中现场纠结。遇到就登记、跳过、继续。 攒够一批再集中决策------否则你会在第 3 个文件上卡两天，整个项目死在那儿。
第 3 步：从叶子往根做
css
工具函数 / 常量 ← 谁都不依赖，最先做
↓
基础组件（Button、Input）
↓
业务组件
↓
页面底层改错了上层全崩，上层改错了只影响自己。同时第一批优先挑最不重要的页面当练兵。
第 4 步：每个任务必须有可执行的完成标准
这才是「可验证」三个字的含义。不是「感觉没问题」，而是一句能跑的命令：
任务 ：迁移
src/components/UserCard.vue完成标准：
npm run type-check通过npm run test -- UserCard通过（跑提前补好的特征测试）- 截图与基线像素差异 < 0.1%
- 不新增任何
any
没有这一条，「几百个小任务」就是几百个需要你亲自 review 的负担------那还不如不拆。
真实节奏
| 阶段 | 干什么 |
|---|---|
| 第 1 周 | 拉埋点数据，砍掉没人用的页面 |
| 第 2--3 周 | 扫描盘点、分桶、搭好验证闭环 |
| 第 4--6 周 | AI 批量给存量代码补特征测试 |
| 第 7 周 | 迁第一批：5 个最边缘页面，灰度上线 |
| 之后 | 每周一批逐步加量；C 桶问题集中决策 |
注意前六周一行迁移代码都没写。 全在做「让迁移变得可验证」的准备。
这就是为什么大多数迁移会失败------大家一上来就改代码，改到一半发现没法验证、不敢上线，烂在分支里半年，最后放弃。
四、一个反常识的数据：three.js 发版变慢了一半
很多人默认 AI 会让开源项目迭代加速。我去查了 three.js 的真实发布记录：
| 版本 | 发布日期 | 间隔 |
|---|---|---|
| r180 | 2025-09-03 | --- |
| r181 | 2025-11-19 | 2.5 月 |
| r182 | 2025-12-10 | 3 周 |
| r183 | 2026-02-20 | 2.3 月 |
| r184 | 2026-04-16 | 2 月 |
| r185 | 2026-07-01 | 2.5 月 |
过去 10 个月只发了 6 个版本。 而 three.js 历史上长期是月更（r160 是 2023 年 12 月，r180 是 2025 年 9 月------21 个月发了 20 版）。
AI 大规模普及的这一年，恰恰是 three.js 发版频率腰斩的一年。
为什么？
因为「开源项目的瓶颈是写代码的速度」这个前提是错的。真正的瓶颈是三样 AI 解决不了的东西：
- 维护者 review 的带宽。 AI 让提 PR 变得极其容易，结果是PR 数量暴涨但质量下降 ------大量看起来像模像样、实际没理解上下文的代码。AI 加速的是提交端，不是审核端，队列只会越排越长。
- 设计决策没法外包。 「WebGPU 和 WebGL 的 API 要不要统一、老用户怎么迁移」是判断题不是编码题。AI 能列三种方案的优缺点，但谁来承担选错的后果？
- 向后兼容的责任。 几百万开发者在用，每改一个 API 就有一批项目要跟着改。
还有一层更值得注意的：AI 让「改 API」变贵了
AI 的「肌肉记忆」来自训练数据，而训练数据里绝大部分是旧版本的写法。你把 API 一改：
- 全世界的 AI 继续生成过时代码
- 用户不知道为什么 AI 给的代码跑不起来
- 维护者收到一堆「AI 说可以这样写但报错了」的 issue
API 稳定性在 AI 时代的价值上升了，破坏性变更的隐性成本变高了。框架的理性选择反而是更保守、更慢、更慎重。
这依然是同一个主题：确定性变贵了。
顺便回答「有了 AI 还需要框架吗」
需要。因为框架的价值从来不是「帮你少写代码」------如果只是这样，AI 确实能取代它。
框架真正提供的是三样东西：
① 被验证过的正确性。 一个跑了十几年、被几百万开发者在各种奇怪显卡和浏览器上跑过的 Matrix4，和 AI 现场生成的一个，功能上可能一样，可靠性差着数量级。AI 能生成「看起来对」的代码，但生成不了「已被十年时间验证过」这个属性。
② 代码总得跑在某个东西上。 你不用 three.js，AI 就得给你现场造一个 mini three.js------WebGPU 初始化、着色器编译、几何缓冲、相机变换一行都不能少。AI 不消除复杂度，只是改变了谁来写这段复杂度。 而写完之后，这段复杂度就归你养了。
③ 维护成本的社会化。 半年后 Chrome 更新、WebGPU 行为变了、iOS Safari 出 bug------谁来改你那 3000 行 AI 生成的渲染代码？ 用框架的话，答案是 npm update。
这是框架最硬的价值：把维护成本从「你一个人扛」变成「全球分摊」。这个价值 AI 完全动不了。
五、2026 前端库现状（npm 实时数据）
既然选型依然重要，这里是各方向的真实下载量（npm 最近 7 天，2026-08-11 查询）。
先说三个读数陷阱：
- 下载量 ≠ 用户数。 CI 每次构建都算一次，它衡量的是生态渗透度。看相对倍数有意义，看绝对值没意义。
- 排最前面的往往不是主动选的。 ajv（3.66 亿）、nanoid、qs、postcss 都是被别的包间接拖进来的。
- 国内库数字系统性偏低。 antd、element-plus、echarts 大量走 cnpm/私有镜像，不进 npm 统计，真实使用量要大幅上修。
框架 / 元框架
| 库 | 周下载 | 判断 |
|---|---|---|
| react | 1.63 亿 | 事实标准，生态、招聘、AI 训练数据都最厚 |
| vue | 1455 万 | 全球第二，中国份额远高于此 |
| @angular/core | 598 万 | 大厂内部系统，全家桶开箱即用 |
| svelte | 527 万 | 心智负担最小，生态和招聘是短板 |
| next | 5235 万 | React 元框架默认答案 |
| astro | 444 万 | 内容站 / 文档站 / 营销页最优解 |
| nuxt | 200 万 | Vue 侧对应 Next |
| gatsby | 30 万 | 已经死了，新项目不要碰 |
构建链------已完成改朝换代
| 库 | 周下载 | 对比 |
|---|---|---|
| vite | 1.64 亿 | 是 webpack 的 3 倍 |
| webpack | 5501 万 | 只剩存量 |
| pnpm | 1.53 亿 | 是 yarn 的 16 倍 |
| yarn | 966 万 | 已被淘汰 |
| @rspack/core | 848 万 | webpack 兼容的 Rust 替代，存量项目提速用 |
这一栏信号最明确：vite + pnpm，没有第二个答案。
类型与校验
| 库 | 周下载 |
|---|---|
| typescript | 2.60 亿 |
| zod | 2.54 亿（几乎追平 TS） |
| yup / joi / valibot | 1236 / 2375 / 1686 万 |
zod 值得单独说 ：它已经不只是「表单校验库」，而是运行时和类型系统之间的桥梁------一份 schema 同时产出 TS 类型 + 运行时校验，接口返回、表单、环境变量、AI 结构化输出全用它。
状态管理 & 数据请求
| 库 | 周下载 | 判断 |
|---|---|---|
| @tanstack/react-query | 6370 万 | 服务端数据的标准答案 |
| zustand | 5058 万 | 客户端状态首选 |
| redux / @reduxjs/toolkit | 4103 / 2697 万 | 存量项目 |
| pinia | 463 万 | Vue 侧唯一答案 |
认知更新：大部分人以为的「状态管理难题」，其实是服务端数据缓存问题。 用 React Query 解决掉之后，真正的客户端状态少得可怜，zustand 几十行就够。别再上 Redux 全家桶了。
样式 & UI
| 库 | 周下载 | 判断 |
|---|---|---|
| tailwindcss | 1.21 亿 | 已成默认，配合 AI 生成效果极好 |
| @radix-ui/react-dialog | 6968 万 | 无头组件底座 |
| lucide-react | 9745 万 | 图标首选 |
| @mui/material | 1015 万 | 全套方案，改样式痛苦 |
| styled-components | 1093 万 | 在衰退，运行时开销被诟病 |
| antd | 362 万* | 中后台事实标准（国内真实量远高于此） |
最大趋势：从「全套组件库」转向「无头组件 + 自己控样式」。
shadcn/ui 本身不是 npm 包（它把源码复制进你项目），所以查不到数字，但它带火的整条链路数据惊人。
为什么这个模式赢了 ：传统组件库的痛点是「改个样式要跟它打架」。无头方案把行为（无障碍、键盘、焦点管理）和外观 拆开------难的部分用库，简单的部分自己写。而且代码在你仓库里，AI 能直接读、直接改。
但中后台是例外：表格、表单、权限那套，antd / element-plus 依然是效率最优解，别为了赶时髦重造。
3D / 图形 / 动画
| 库 | 周下载 | 用在哪 |
|---|---|---|
| three | 1422 万 | 3D 事实标准 |
| @react-three/fiber + drei | 503 + 384 万 | React 里用 three 的标准姿势 |
| pixi.js | 91 万 | 2D 高性能（游戏、粒子）------别拿 three 干 2D |
| konva / fabric | 256 / 90 万 | Canvas 图形编辑器（白板、海报） |
| framer-motion + motion | 4286 + 1758 万 | 同一个库（已改名 motion），合计约 6000 万 |
| gsap | 445 万 | 复杂时间轴、创意站点 |
| lottie-web | 716 万 | 播放 AE 导出的动画 |
图表 & 地图
| 库 | 周下载 | 判断 |
|---|---|---|
| recharts | 5695 万 | React 生态第一 |
| echarts | 468 万* | 国内中后台事实标准，复杂图表最强 |
| chart.js | 1264 万 | 轻量、框架无关 |
| d3 | 1773 万 | 不是图表库，是可视化底层积木 |
| leaflet | 667 万 | 轻量地图首选 |
| maplibre-gl | 402 万 | 矢量地图（Mapbox 开源分支，无授权风险） |
富文本编辑器（最容易踩坑的方向）
| 库 | 周下载 |
|---|---|
| @tiptap/core | 1703 万（基于 ProseMirror 的无头方案，目前最优解） |
| quill | 1085 万（开箱即用，定制困难） |
| lexical | 464 万（Meta 出品，生态还嫩） |
| monaco-editor / codemirror | 836 / 1007 万（代码编辑器） |
忠告：富文本是前端最深的坑之一，永远不要自己写。
测试 & 代码质量------这栏也换代了
| 库 | 周下载 | 对比 |
|---|---|---|
| vitest | 8974 万 | 是 jest 的 2 倍 |
| jest | 4633 万 | 存量 |
| @playwright/test | 5279 万 | 是 cypress 的 7 倍 |
| cypress | 736 万 | 被击败 |
| @testing-library/react | 5263 万 | 组件测试标准 |
| @biomejs/biome | 1254 万 | Rust 版 eslint+prettier 二合一，快几十倍 |
工具类
| 库 | 周下载 | 判断 |
|---|---|---|
| date-fns / dayjs | 9831 / 6647 万 | moment（3578 万）已停止维护，不要用于新项目 |
| axios | 1.20 亿 | 依然是霸主 |
| es-toolkit | 4167 万 | lodash 的现代替代，增长很快，体积小 2--3 倍 |
| @dnd-kit/core | 2280 万 | 拖拽首选（react-beautiful-dnd 已停维护） |
| @tanstack/react-virtual | 2114 万 | 虚拟列表（react-window 接班人） |
从数据里看出的 6 个信号
- 构建链已完成换代：vite 干掉 webpack（3:1），pnpm 干掉 yarn（16:1）。还在用 webpack + yarn 的团队已经是落后配置。
- 测试链也换代了 ：vitest 超 jest（2:1），Playwright 碾压 Cypress（7:1）。这两个替换成本低、收益直接。
- zod 成了新的基础设施，量级追平 TypeScript 本身。
- 「无头组件 + Tailwind」打赢了「全套组件库」（To C 场景），中后台仍是 antd/element 天下。
- Redux 时代结束：React Query + zustand 成为新组合。
- 老库在批量死亡：moment、gatsby、formik、react-beautiful-dnd、cypress、styled-components 都在明显衰退。
实操建议：拿这份清单对一遍你们的
package.json，命中衰退列的就是技术债第一批候选。而且这类替换（moment→dayjs、jest→vitest、yarn→pnpm）行为等价、有明确验证标准，正是最适合交给 AI 批量做的活。
选型时请加一个新维度：AI 熟不熟
这已经是真实的成本项。用主流库，AI 生成的代码基本能用；用冷门库，AI 会开始编 API。
但要警惕版本陷阱 ------AI 训练数据偏向旧版本，它会给你 Redux 而不是 zustand、react-router-dom 而不是 v7 的 react-router、moment 而不是 dayjs、three 的 WebGLRenderer 而不是 WebGPURenderer。
解法还是那句话：在 CLAUDE.md 里把你们的选型和禁用清单写死。
六、前端工程师会被淘汰吗？
很多公司开始招全栈、让服务端顺手写简单页面、裁撤前端。我的看法可能和主流不太一样。
先把归因搞对
前端岗位收缩从 2022 年就开始了，比 AI 编程工具普及早了整整两年。把它归到 AI 头上，时间线对不上。
真实原因有三个：
- 之前扩招得太狠。 前端是所有岗位里膨胀最快的------培养周期最短、门槛最低。现在很大一部分只是回归正常水位。
- 需求端萎缩，不是供给端被替代。 以前每条业务线都要做 App、官网、小程序、活动页，现在这些项目直接不立了。不是「同样的活被 AI 干了」，是「这些活没人要了」。
- 工具链成熟本身就在降门槛。 这个降低发生在 AI 之前。
AI 是加速器，不是起因。
「全栈化」的本质是经济学问题
分工能存在，前提是分工的收益 > 协作的成本。
当年前后端分离，是因为前端复杂到后端学不动，学习成本 > 沟通成本，所以拆开。
现在 AI 把跨栈学习成本打下来了。当「后端顺手学点前端」的成本低于「前后端拉会对接口、联调、扯皮」的成本时，合并就自然发生了。
关键推论：这个天平是双向的。
边界在移动，但没规定它一定往后端那边倒。前端往后端扩其实更容易------你已经会 TypeScript，Node 服务、BFF、基础数据建模，学起来比后端学 CSS 布局和浏览器渲染快得多。
真正的问题不是「前端会不会被后端吃掉」，而是「你和他，谁先动」。坐在原地等边界压过来的那个人会被吃掉，不管他原来是哪一端。
被淘汰的不是「前端」，是「只会把设计稿变成代码的人」
必须分清两件事：
- 「前端」这个职能：把产品意图变成人能用的界面。只要人还用眼睛和手指用软件，它就不会消失。
- 「前端工程师」这个编制：会缩，而且已经在缩。
真正被吃掉的是很具体的一段：「看着设计稿把它写出来」 。这是整个前端工作里最标准化、最没有不确定性的部分。而残酷的现实是------很多前端 80% 的时间就在干这个。
所以准确的说法是：中间层在塌陷。 初级前端最危险；能处理复杂问题的人，需求其实在上升。这不是行业消失，是行业的中位数被抬高了。
什么是吃不掉的
- 端上的复杂状态与交互。 协同编辑、实时白板、可视化编排、拖拽搭建、离线同步。这些不是「页面」，是跑在浏览器里的分布式系统。 AI 能写出每个局部，但撑不住整体的状态一致性设计。
- 性能与体验的工程化。 首屏、包体积、内存泄漏、长列表、动画掉帧。关键在于------顺手写页面的人根本不知道存在这些问题，AI 也不会主动提醒你。
- 跨端与兼容性的泥潭。 iOS Safari 的怪癖、微信 webview、老安卓。这些经验不在任何文档里，因此也不在 AI 的训练数据里。
- 把模糊意图翻译成确定交互。 产品说「这里要顺畅一点」到底对应什么，是判断力，不是编码。
- 架构与规范。 这一条在 AI 时代反而更重要了------代码生产速度上去了，腐化速度也跟着上去了。以前一年烂掉的项目，现在三个月就能烂。
一个反直觉的判断：AI 可能让前端更值钱
当「实现」的成本趋近于零，差异化就全部转移到「体验」上。
如果所有公司都能用 AI 在两周内做出功能一模一样的产品，用户凭什么选你？只剩下更快、更顺、更好看、细节更周到。
软件的价值正在从「有没有这个功能」转向「用起来爽不爽」。而后者恰恰是前端的主场。
印刷术让「会写字」彻底贬值，但让「写得好」的人比以前更值钱。工具革命消灭的是能力的下限，抬高的是上限的回报。
顺便提醒：让后端顺手写页面，代价会在两三年后来
对真正简单的页面，这是个合理决策。但有个隐性成本：这些代码没有主人。
后端写前端的目标是「能跑就行」，不会关心组件复用、状态管理、包体积、样式污染。三年积累下来，你会得到一个没有架构、没人敢动的前端代码库------而那时候原来的前端已经裁掉了。
这不是唱衰，是时间差问题：合并的收益立刻可见，代价要两三年后才显现。
作为技术负责人，你能做的不是争论「要不要留前端」，而是画一条线：哪些是「简单页面谁写都行」，哪些是「核心产品体验，必须有人负责架构」。
七、新战场：AI 产品化
它不是在右下角加个聊天框
真正的定义：
把模型「概率性、会出错、慢、不确定」的能力，包装成用户敢用、能验证、能纠错、能承担后果的产品形态。
这里有个根本矛盾：
- 传统 UI 的全部设计假设都是确定性的------点这个按钮，必然发生这件事
- 模型的输出是概率性的------同样输入可能给不同答案，且有概率是错的
弥合这两者之间的鸿沟，就是 AI 产品化的全部工程内容。而这件事绝大部分落在前端身上。
| 问题 | 传统方案失效在哪 | 前端要解决的 |
|---|---|---|
| 等待 | AI 要几秒到几分钟，转圈圈用户会走 | 展示「它正在干什么」------思考过程、工具调用、阶段进度 |
| 流式 | 内容一个字一个字来 | 半个代码块怎么渲染、布局不能抖、用户往上滚了要不要继续跟、随时可中断 |
| 会出错 | 传统 UI 假设结果一定对 | 置信度、来源引用、让用户一眼看出哪里可能不对 |
| 有后果的操作 | 点了就执行 | 预览 → 确认 → 执行 → 可撤销 → 有审计 |
| 纠错 | 错了只能重来 | 让用户低成本地改，而不是重新描述一遍 |
注意：这五件事没有一件跟「调用模型 API」有关。 调 API 是十行代码的事，剩下 90% 的工程量全在这张表里。
这就是为什么 AI 产品化是前端的机会------难的部分恰好在端上。
中后台系统尤其适合
很多人以为 AI 产品化是 To C 的事。恰恰相反------中后台可能是 AI 落地最好的场景：操作边界明确、用户是内部员工容错度高、有大量重复繁琐的真实痛点、数据都在自己系统里。
几个能下周就开工的例子：
① 自然语言筛选
订单列表有 20 个筛选项，用户想找「上海、上个月、金额超 1 万、未发货」，要点 8 次。
AI 化的关键设计是不要直接给结果，而是给「填好的筛选条件」：
css
用户输入：上海 上个月 金额>1万 未发货
↓
[地区: 上海 ×] [时间: 2026-07-01 ~ 07-31 ×] [金额: >10000 ×] [状态: 未发货 ×]
↓ 用户看到了，可以直接改
点「查询」（走你原来的接口）用户能看见 AI 理解成了什么，能改，出错也不慌。
对比坏设计：直接把结果甩出来。用户不知道它筛了什么，错了也发现不了------这种功能上线三周就没人用了。
② 文档 / 图片 → 表单自动填充（ROI 最高）
中后台最大的时间黑洞，是人肉把非结构化信息抄进系统。
关键设计是字段级可追溯：每个自动填的值标出它从原文哪来，鼠标移上去右边 PDF 高亮对应位置，不确定的字段标黄强制确认。
人的角色从「录入」变成「核对」。 这个转变心理上也可接受------没人愿意让机器替自己签字，但所有人都愿意让机器帮自己打草稿。
③ 批量操作的意图执行
「把这批 200 个商品价格上调 5%，但库存低于 10 的不动」：
markdown
1. 用户用大白话描述意图
2. AI 解析 → 生成【预览列表】：哪 187 个会改、改成多少、哪 13 个跳过、为什么
3. 用户扫一眼，可手动剔除某几条
4. 确认执行
5. 顶部出现「已修改 187 条 [撤销]」，保留 24 小时
6. 操作日志：谁、何时、什么指令、改了什么第 2、4、5、6 步是全部工程量的 80%，而且全是前端的活。第 1 步调模型只占 5%。
④ 审批辅助
别让 AI 替人审批。正确姿势是把决策所需信息提前整理好摆在审批人面前：历史记录、命中哪几条规则（附原文）、类似 case 当时怎么处理的、一句建议 + 理由。人只需点通过/驳回。
模式：AI 做 90% 的信息收集，人做 10% 的决定。
这是中后台最安全的 AI 形态------因为责任边界没变，还是人签的字。
⑤ 自然语言生成报表
AI 输出的不是文字，是图表配置对象（如 echarts option），前端直接渲染。
安全红线：AI 只产出「查询参数 + 图表配置」，数据查询走既有的、有权限校验的接口。绝对不要让模型直接生成 SQL 打到生产库。
最重要的一条原则：不要做聊天框
中后台的 AI 化，形态应该是「AI 增强的既有界面」，而不是「多一个 Copilot 侧边栏」。
因为中后台用户是熟练工 。他们每天用同一个界面几十次，闭着眼都知道按钮在哪。对他们来说，打一段话描述需求比点三下鼠标更慢、更累。
大多数公司的失败路径都一样：花两个月做了个漂亮的 Copilot 侧边栏，上线，前两周有人图新鲜试试，一个月后打开率归零。
正确的落点是那些「现在特别烦」的具体环节------筛选栏旁边加自然语言输入、表单顶部加「从文档导入」、列表页加「批量意图操作」。
判断标准就一句话：它有没有减少用户的点击次数和等待时间？减少了就是好功能，只是「看起来很 AI」就是自嗨。
值得补的具体技能
- 结构化输出 ------让模型稳定按你的 schema 返回（zod + structured output），而不是解析自然语言。这是所有 AI 功能的地基。
- 流式渲染------SSE、增量 markdown 解析、中断与重试。
- 人在回路的交互模式------预览、确认、撤销、审计。设计能力多过编码能力。
- 成本意识------前端要控制上下文大小。这是新的性能优化维度。
- 失败兜底 ------模型超时、返回格式不对、内容被拦。传统前端没有「接口返回了但内容是错的」这个概念，AI 前端天天遇到。
总结：六个问题，一个答案
回头看，这篇文章讨论的六件事，答案其实是同一个：
| 问题 | 答案 |
|---|---|
| 拿到 AI 编程工具该做什么？ | 不是写 skill，是建上下文供给和验证闭环 |
| 大规模迁移怎么做？ | 难点不是改语法，是建立「我怎么知道没改坏」的能力 |
| three.js 为什么变慢了？ | 因为 AI 时代破坏性变更的成本变高了 |
| 还需要成熟框架吗？ | 需要，因为它提供的是被时间验证过的正确性 |
| 前端会被淘汰吗？ | 被淘汰的是「实现」，留下的是判断和约束 |
| AI 产品化难在哪？ | 90% 工程量在让不确定的输出变得可信可控 |
六个答案指向同一件事：
AI 让生产代码变便宜了，于是确定性变贵了。
这是整个行业价值分配正在发生的迁移。你的价值不再取决于你能写多少代码，而取决于你能为多少不确定性负责。
具体到行动，三件事按优先级排：
- 把「验证」这件事补上。 严格类型、测试、截图对比、CI。这不只是给 AI 用的------它同时是你团队工程能力的底盘。
- 把「决策」显式化。 技术选型、架构约束、禁用清单，全部写进文档。以前这是可选项，现在不写，AI 就会用它训练数据里的旧世界覆盖你的架构。
- 主动往外扩。 往后端扩，往产品扩，往 AI 产品化这个新战场扩。对代码负责的岗位可以被合并，对结果负责的人不能。
最后说句实在的：每一轮工具革命，喊得最凶的「XX 要被淘汰了」，几乎都来自不在这个行业里的人。
实际发生的从来不是「消失」，而是这个职业的定义被改写，一部分人跟上了，一部分人没跟上。
你现在在读这篇文章、在想该做什么，本身就已经是在跟的那一批了。
文中 npm 下载数据于 2026-08-11 通过 npm registry API 实时查询，为最近 7 天下载量。three.js 版本信息来自 GitHub Releases。