夜雨聆风“前端工程师会不会被 AI 取代”是一个很容易引发焦虑的问题。
它也很容易让讨论变得粗糙。
因为岗位不会像开关一样突然消失，能力也不会整体同时贬值。
更接近真实变化的问法是：
前端工作里，哪些能力正在变便宜，哪些能力正在变贵？
AI 不会一口气取代整个前端岗位。
但它会迅速压低一类工作的价值：判断密度低、上下文少、边界清楚、反馈快、可以模板化描述的部分。
这类工作过去可能是很多人的入门路径。
比如照着设计稿写页面。
比如搬运一个相似组件。
比如补一个弹窗、表格、表单。
比如把接口字段映射到页面。
现在这些事情仍然要做，但“从零写出第一版”的稀缺性会下降。
这才是前端工程师真正需要关注的变化。
不是岗位名称会不会消失。
而是自己的能力结构是否还停留在低判断密度区域。
01｜为什么取代焦虑容易发生在前端
前端特别容易被放进 AI 替代叙事里。
原因并不复杂。
第一，前端结果可视化强。
输入一段需求，AI 生成一个页面，用户很快就能看到效果。
这种演示冲击力很强。
相比后端系统、数据链路、基础设施，页面更容易被截图、录屏和传播。
第二，前端有大量稳定模式。
表格、表单、弹窗、详情页、筛选区、卡片列表、步骤条、仪表盘，这些形态非常常见。
只要需求足够明确，AI 很容易生成一个七八十分的草稿。
第三，很多业务前端工作本身就有重复性。
业务系统里，前端工程师经常在处理相似页面、相似状态和相似交互。
这些任务过去依赖手速、经验和熟练度。
AI 出现后，熟练度仍然重要，但它不再是唯一门槛。
第四，前端反馈周期短。
生成代码、运行页面、看结果、修样式，这条路径很快。
这会让人产生一种感觉：
既然页面能生成，那前端是不是没那么重要了？
这个结论太快。
AI 能生成页面，不代表它理解了产品目标。
它能写出组件，不代表它知道组件边界。
它能跑通主流程，不代表它覆盖了异常状态。
前端的价值不是消失，而是正在迁移。
02｜哪些前端工作会先贬值
先贬值的，不是最难的工作。
恰恰是很多人过去用来证明“我会写前端”的基础工作。
低复杂度页面实现
比如一个普通列表页。
顶部筛选区，中间表格，底部分页，右上角几个按钮。
只要字段、接口、组件库和样式要求给得清楚，AI 很快能生成一个版本。
过去这可能需要半天。
现在第一版可能只需要几分钟。
但第一版变便宜，不代表上线变简单。
页面还要处理权限、空状态、加载状态、错误提示、国际化、埋点、响应式、可访问性和性能。
这些通常不会在“生成一个页面”的 prompt 里自动完整出现。
重复性组件搬运
很多需求不是从零创新，而是“参考 A 页面，在 B 页面做一个类似功能”。
这类任务非常适合 AI。
因为它有清晰样例，也有稳定输出。
但这里仍然有判断：两个页面是否真的语义相同，是否应该抽象公共组件，是否应该保持局部重复。
AI 可以搬运代码。
但它不一定知道什么时候不该抽象。
无判断的代码翻译
比如把一段 JavaScript 改成 TypeScript。
把 Options API 改成 Composition API。
把一个接口返回字段映射成 UI 展示。
这类工作如果上下文清楚，AI 会非常高效。
但如果类型背后有业务语义，或者转换过程中涉及兼容行为，就不能只看语法层面的正确。
表面可运行的小需求
这是最容易误判的一类。
需求看起来简单，AI 也能很快写出来，页面也能跑。
但真实风险藏在边界里。
比如“增加批量删除”。
AI 可能写出按钮、弹窗和接口调用。
但它可能没有处理权限、二次确认、部分失败、删除后分页回退、审计日志和误操作恢复。
团队如果只看主流程，就会误以为任务完成。
03｜哪些能力会变贵
AI 让第一版代码更便宜。
同时，它也让高判断密度能力更重要。
需求拆解能力
模糊需求不能直接交给 AI。
“做一个导出功能”不是可执行需求。
它至少要拆成：
从哪里导出。 谁有权限导出。 导出哪些字段。 是否受筛选条件影响。 空数据怎么办。 大数据量怎么办。 导出失败怎么办。 是否需要记录操作日志。
AI 可以帮助补清单。
但前提是人知道这类问题必须被问出来。
复杂状态建模能力
前端越往后走，越不是在画页面，而是在表达状态。
一个按钮是否可点，可能取决于权限、数据状态、请求状态、业务流程、设备环境和用户选择。
一个 AI 聊天界面是否可用，也不仅是输入框和消息列表。
它还要处理流式输出、取消、中断、重试、工具调用、上下文引用和失败恢复。
AI 可以生成状态代码。
但状态应该如何划分，哪些状态需要暴露给用户，哪些只是内部实现，仍然需要人判断。
代码审查能力
AI 生成代码越快，Review 越重要。
过去 Review 常常看命名、格式、重复逻辑和明显 bug。
以后更需要看：
是否解决了正确问题。 是否破坏了系统边界。 是否复用了项目约定。 是否引入了无关改动。 是否覆盖了关键风险。
AI diff 看起来越完整，越需要人保持怀疑。
用户体验判断能力
界面不是代码的皮肤。
它是用户理解系统的方式。
用户是否知道系统正在做什么，是否知道下一步能做什么，是否能从错误中恢复，这些都不是单纯生成组件能解决的。
尤其 AI 应用里，用户面对的是一个不确定系统。
前端要表达可信度、来源、边界和控制权。
这部分判断会越来越重要。
工程约束意识
项目真正难维护，往往不是某个组件写错。
而是长期缺少边界、规则和复盘。
AI 会放大这种差异。
有规则的项目，AI 能沿着规则提高效率。
没规则的项目，它会更快制造局部补丁。
04｜前端价值正在迁移
过去，很多前端价值体现在“我能把页面写出来”。
这件事仍然重要。
但它不再足够。
价值会更多迁移到几个方向：
把需求组织成可实现、可验证的任务。 把复杂状态表达成清楚的界面。 把 AI 生成代码拉回项目秩序。 把业务规则沉淀成组件、Hook、文档和测试。 把用户体验、工程约束和交付效率放在一起权衡。
这其实是前端本来就应该做的事。
AI 只是加速了分化。
低判断密度部分被压缩。
高判断密度部分被放大。
05｜三个常见误区
第一个误区把前端简化成页面生产。
第二个误区把 AI 工具当成职业护城河。
第三个误区则忽略了新人路径会变化。
新人不是没有机会。
只是过去那种靠大量重复页面积累手感的路径，会被压短。
新的成长方式更依赖阅读、审查、建模和复盘。
06｜能力变化表
这张表不是为了制造新的焦虑。
它只是提醒我们：不要把全部精力放在正在变便宜的能力上。
07｜现在可以开始做的三件事
第一，把需求拆成验收条件
不要只写：
做一个导出功能。
更好的写法是：
在订单列表支持按当前筛选条件导出。只有有权限的用户可见。导出中按钮禁用。空数据时提示无可导出内容。导出失败时保留筛选条件并提示重试。
这种表达会显著提高 AI 输出质量。
也会提高人与人之间的协作质量。
第二，把 Review 当成核心训练
看 AI 代码时，不要只问能不能跑。
要问：
它是否解决了正确问题。 是否破坏了模块边界。 是否复用了已有约定。 是否遗漏了异常状态。 是否引入了无关改动。 是否能被测试证明。
Review 是训练判断力的好方法。
第三，训练复杂状态建模
遇到一个页面，主动画出状态。
加载、空、错误、部分成功、禁用、取消、重试、回滚、并发。
再问每个状态下用户能做什么，系统应该展示什么。
状态越清楚，UI 和代码越稳定。
这项能力在 AI 应用里会更重要。
结尾：前端不会消失，但默认价值会变
AI 会让一部分前端工作变便宜。
尤其是模板化、重复性、低上下文的工作。
但真实产品不会只需要第一版代码。
它还需要需求拆解、状态建模、工程边界、体验判断和质量审查。
前端工程师要关注的不是岗位名称会不会消失，而是自己的能力结构是否还停留在低判断密度工作上。
下一篇继续讨论：
前端工程师做 AI 应用，第一步不该是学大模型原理。
