AI 现在确实能把一个页面、一个表单甚至一套组件库的第一版很快铺出来。Claude Code、Codex 这类 Agent 接到明确任务后，能连续改文件、补样式、接接口，速度比手写快得多。
所以「前端凭什么还值 25K」不是一个可以靠情怀回答的问题。
我的答案是：25K 从来不是给"把 JSX 敲出来"的报酬，而是给"在一堆不确定条件下，把一个功能交付成可用结果"的能力。 AI 降低的是第一版代码的生产成本，没替你接走交付的判断、风险和责任。
标题里的"面试官问我"不是复述某一场真实面试。它更像最近反复出现的一道追问：既然 AI 都能生成代码了，前端开发者还剩下什么？
先把结论摆在前面：前端不会因为 AI 消失，但只会把需求复述成页面的人，议价能力一定会下降。
AI 已经很会做第一版，但第一版离交付还很远
给 Agent 一句"做一个任务列表页"，通常很快就能得到：请求数据、循环渲染、加载态、按钮、几个响应式样式。演示时看起来已经像个完整功能。
问题是，真实项目里最昂贵的部分，常常不在"有没有把列表渲染出来"。而在这些没有写进第一句需求的话：
- 接口返回空数组、半截数据或权限不足时，页面该怎么表现？
- 用户反复点击、切换页面、网络慢、请求失败时，状态会不会乱？
- 一个临时字段会不会被写进三个组件，下一次改需求要全局搜索？
- 这个新功能会不会让首屏变慢、键盘无法操作，或者破坏已有埋点？
- 上线后客服说"某些用户点不了"，谁能最快判断是前端状态、接口数据、权限还是发布问题？
AI 可以给这些问题生成候选答案，但它不会天然知道哪一个答案符合你的产品规则、团队约束和线上风险。它也不会替你承担"看起来能跑，实际不能用"的后果。
这就是我理解的分水岭：生成代码是产出，交付结果才是工作。
一个能跑的页面，为什么不等于一个可交付的页面
下面这种 React 代码并不罕见。它能跑，也能把接口里的任务渲染出来。
tsx
import { useEffect, useState } from "react";
type Task = { id: string; title: string; done: boolean };
export function TaskList() {
const [tasks, setTasks] = useState<Task[]>([]);
useEffect(() => {
fetch("/api/tasks")
.then((response) => response.json())
.then(setTasks);
}, []);
return (
<ul>
{tasks.map((task) => (
<li key={task.id}>{task.done ? "已完成" : task.title}</li>
))}
</ul>
);
}如果接口永远成功、字段永远稳定、页面只被打开一次，这段代码没问题。
但生产环境不提供这种理想条件。接口可能返回异常结构，字段可能缺失，加载中的空白页面也会让用户误以为"没有任务"。
真正的前端工作不是把这些情况全靠 if 堆起来，而是先问：这个页面对用户的承诺是什么？数据边界在哪里？异常出现后，用户下一步还能做什么？
交付视角会先区分加载、空、错误和无权限，再把不可信的接口输入收口。重点不在于某个校验函数怎么写，而在于先界定失败的含义，再决定展示什么、是否允许重试、如何定位问题。
一个只会提示词的人，往往得到的是"能展示"的代码；一个能负责交付的人，会追问：空态是不是业务空态？错误态会不会把权限问题伪装成网络问题？这个组件该留在页面里，还是沉淀成团队规范？
代码量没变多少，价值差距却很大。
前端真正被付费的，是这四类判断
1. 把模糊需求翻译成可验证的交互
产品说"这里加一个快捷入口"，不是一张设计稿就结束了。入口在哪个时机出现、未登录怎么办、点击后去哪里、返回后状态是否保留、移动端和桌面端是否一致，都会影响最终体验。
AI 擅长把清晰指令翻成实现。前端的价值，是发现指令不够清晰的地方，并把它变成可以讨论、可以验收的规则。
很多返工不是代码写错了，而是开发时默认了一个业务规则，产品上线后才发现默认错了。能提前把默认值、边界和验收路径问出来，往往比半小时生成一百行代码更值钱。
2. 给系统划边界，而不是给页面打补丁
一个新需求最容易的做法，是在现有组件上再加两个状态、三个 props、一个条件分支。短期看很快，半年后就会变成谁都不敢动的组件。
前端需要判断：哪些状态属于业务领域，哪些只是展示细节；哪些能力应该放进共享组件，哪些只服务当前页面；哪些数据适合在路由层加载，哪些该由局部组件管理。
这不是为了"架构漂亮"。边界清楚，需求变化时才不会一次改动牵连整条链路；多人并行开发时，才不会每个人都在同一段代码上打补丁。
Agent 能根据仓库写出符合现有模式的代码，但它无法替团队决定现有模式是不是已经走到该拆分的临界点。
3. 判断质量，而不是只看页面像不像
"像设计稿"只是最基础的质量线。一个页面还要经得起不同设备、慢网、键盘操作、长文本、异常数据和重复点击。
前端工程师需要把这些抽象成可验证的质量要求：
| 维度 | 只看第一版时的问题 | 交付时要确认的事 |
|---|---|---|
| 状态 | 只做成功态 | 加载、空、错误、无权限是否可理解且可恢复 |
| 性能 | 本地点击很快 | 首屏、长列表、资源加载会不会拖慢核心路径 |
| 可访问性 | 鼠标能点 | 焦点、键盘、语义和反馈能否正常工作 |
| 一致性 | 单页好看 | 组件、文案、交互是否遵守现有系统 |
| 可观测性 | 出问题靠猜 | 关键失败是否有足够信息定位 |
这些事有的可以让 AI 帮你列清单、补测试、扫代码；但"这个业务真正不能出错的地方是什么"，必须由理解上下文的人来定。
4. 在上线后做取舍并对结果负责
线上出现问题时，最需要的不是继续生成代码，而是快速判断。
是某个灰度配置没生效，还是接口把字段改坏了？是某一类机型的样式问题，还是用户权限导致的分支？先回滚，先降级，还是局部修复？这些选择都带成本，也都需要对业务节奏负责。
前端的角色不是"接到需求就写"。在真实团队里，它还是产品、设计、后端、测试之间的翻译器和风险提示器。能把"这个需求能做"进一步说成"这样做会影响什么、要补什么、何时能稳定上线"，才是更高价值的能力。
如果面试里真被这样问，可以怎么答
我不会上来讲"AI 永远替代不了人"。这种回答既空，也经不起追问。
我会把话题落到交付链路上：
AI 可以把明确需求的实现速度拉得很高，但前端的职责不只是产出页面。我会先把需求拆成状态和边界，再用 AI 加速实现；最后由我对可用性、性能、一致性和线上问题负责。公司花钱买的不是一段能运行的代码，而是一件能稳定交付的功能。
接着补一个你自己真正做过的例子：一次需求边界怎么被澄清、一个线上问题怎么被定位、一个重复组件怎么被收口。不要编一个"AI 写错了我力挽狂澜"的故事，真实的工程判断比戏剧化叙事更有说服力。
如果暂时没有复杂项目，也可以从日常工作里开始练：每次 AI 生成一段实现，都别先问"能不能跑"，而是连续问五个问题：
- 它假设了哪些接口和业务规则？
- 成功以外的状态在哪里？
- 放进现有代码后，谁会被影响？
- 我准备怎样验证它，而不只是手点一遍？
- 出问题后，我能不能快速解释原因？
这五个问题，决定你是在使用 AI 写代码，还是在用 AI 提升交付能力。
25K 不是前端的统一标价，而是一条能力分界线
当然，不是每个前端岗位都该是 25K，也不是会做上面这些事就自动对应某个薪资数字。地区、行业、公司阶段、业务复杂度都会影响价格。
但这个争论至少提醒了一件事：别再把自己的价值描述成"我会 React、会写页面、会调接口"。这些能力依然必要，却越来越像入场券。
更值得训练的是：你能不能把不清楚的事情弄清楚，把不稳定的事情弄稳定，把一次性的实现沉淀成下一次更快的交付。
AI 会继续变强。前端也不该和它比赛谁写得更快，而应该把它当成杠杆，去承担那些必须有人判断、有人协调、有人负责的部分。
你觉得 AI 最先压低的是前端的哪一类价值：写页面的速度，还是解决问题的能力？