AI 时代,前端工程师靠什么继续值钱?

最近半年，我在很多群聊里反复看到大家讨论前端岗位。

有人说：“前端的工作不会消失，但岗位要没了。”

有人说：“招聘市场在缩水，刷不出新的工作机会，简历也石沉大海。”

也有人说，同事在 Boss 上发了一个前端岗位，一下收到 400 份简历。

不单是前端，类似的焦虑也出现在后端、甚至 UI UX 的讨论里。

这些讨论隔几天就会出现一次。前端仿佛变成了一艘泰坦尼克号，船上的人都在问应该往后端、AI 还是别的行业游，都想找到自己的救生圈。

很多前端最难受的，是过去几年引以为傲的能力突然不值钱了，也不知道过去学的技术、积累的经验到底还能不能换来职业机会。

知识星球里一位读者说：自己产后回到公司，因为组织变动和其他原因，被迫去外地驻场。技术工作很少，大部分时间都在处理杂活。她问了三个问题：

面对这些问题，我不打算给她列一张“前端转xx”的学习路线。我心里很清楚，如果没想清楚这些研发岗位为什么出现、又为什么变化，后面再学多少新技术，都会像夸父逐日一样，始终追着下一轮变化跑。直到精疲力尽，只剩一句：学不动了。

学后端、数据库、Docker、AI Agent，这些方向都没有错。但把它们全部列出来，只是把“前端还有没有未来”的焦虑，换成了“我还有这么多东西不会”的焦虑。

我更想回答的是另一个问题：

因为写代码只是解决问题的一个环节。公司愿意付钱的，是有人能找到值得解决的问题，再把结果做出来。

我把前一种能力叫作判断力，把后一种能力叫作闭环能力。我的判断是，AI 越强，这两种能力越容易拉开人与人之间的差距。

同样的工具交给不同的人，产出的效率和价值可以相差很大。我觉得差异来自知识体系、理解能力、思考方式，以及使用 AI 的方式。

判断力负责判断该做什么、值不值得做、风险在哪里。闭环能力能把判断推进到设计、实现、验证和交付。公司看到的，是问题有没有解决、结果有没有产生价值。

产品经理、设计师、前端、后端、测试和运维等岗位，有些在过去并不存在。它们是在互联网高速扩张以后逐渐稳定下来的专业分工。随着需求数量、软件规模和交付速度要求一起上升，每个环节都有足够多的工作。

发现和定义需求有产品经理，设计体验有设计师，实现界面有前端，流量和数据有后端，守住质量有测试，保障发布和运行有运维。当每个环节都有足够多的工作，专人专职比一个人从头做到尾更快。

所以那时候，专业技能很值钱。

往前推 10 年，市场上有大量标准化的开发岗位。前端会 HTML、CSS、JavaScript 和 jQuery，能按设计稿把页面做出来；后端会 Java，熟悉 Spring、MyBatis 和 MySQL，都能对应一类很清晰的岗位需求。后来 React、Vue 逐渐普及，框架熟练度又成了新的筛选项。

公司一直在算同一笔账

这轮岗位变化不全是 AI 造成的。增长放缓、过度扩张后的回调和降本增效也在同时发生，AI 只是进一步加快了变化。

先不谈 AI，回到互联网抢人最凶的那几年。

互联网产品的研发虽然前期固定成本高，但是新增用户的边际成本低。用户从一万人涨到两万人，通常不需要把研发团队也扩大一倍。贵的是从 0 到 1 把软件做出来、持续迭代和复杂协作，更贵的是错过时间窗口的机会成本。

当时公司争的是流量和市场。待解决的问题足够多，窗口期又短，多招一个工程师，可能就意味着产品早一个月上线、业务早一步吃到流量。只要工程师解决问题带来的收入、时间和风险收益能够覆盖工资与组织成本，高价抢人就是一笔合理的账。

互联网公司高速扩张时，业务线多，新业务又要快速上线。支付、账号、营销、数据、研发工具等能力如果各做一套，重复建设和协作成本都会很高。于是很多大厂因此建立中台，把重复能力抽出来统一建设，再交给多条业务线复用。业务越多，一套公共能力被复用的次数越多，中台的价值也越大。

但等产品起势、核心系统搭完、业务增速放缓以后，待解决的问题会变少，同样的账就会重新算一遍。过去需要一百个人抢时间，不代表之后一直需要一百个人维护成果。软件仍然需要维护，但高价值问题的数量和优先级变了，新增一个人的边际价值可能已经撑不起总成本。公司会持续核算投入和回报，不会因为过去解决过重要问题，就永远维持原来的投入规模。

中台部门是这类重新核算中比较容易被看见的例子。业务中台和架构部门建设的公共能力都有很大价值，但这些能力建好以后，价值会被各条业务线吸收，建设团队自己的增量产出反而不容易被看见。

如果找不到下一批值得解决的问题，再叠加重复建设、离业务结果远、协调链路长，原来的人员规模就会被重新核算。虽然大厂裁员先动中台，不能当作普遍规律，但在这种核算过程中，中台部门总是容易被问一句：这么多人现在还在解决什么问题？

— 岗位为何重算

专业技能为什么会重新定价

以前，开发者社区常年争论语言和框架，也有人钻研业务里很少用得上的奇技淫巧。很多人付费买课、报培训班，集中学一门语言、一个框架，再准备一些常见面试题，就能进入行业。技术越难、会的人越少，越容易证明自己稀缺；会得越多、越熟，也往往能换到更好的岗位和工资。

这条路当时确实有效。公司需要大量专业执行者，一套标准化技能就能对应一类清晰的岗位需求。现在，需求收缩、工具进化、组织边界变化，课程里最容易讲授的知识和代码实现，也恰好是 AI 最容易提供的部分。课程依然可以帮助人入门，但再往技能清单上增加一门语言、一个框架，已经很难像过去一样直接抬高职业价格。开发者社区里曾经很热闹的语言之争、框架之争，也一下少了很多。

很多人难受的地方就在这里：把上一轮环境给某项专业能力开出的高价，当成了自己的永久价值。而那份高价里一直包含着时代红利。

回到“前端还有没有未来”这个问题，前端工作、前端技能、前端岗位和“我是前端”，说的是四个不同层次的问题。它们发生变化的速度也不一样。

我见过一些经验丰富的大佬，他们的经历很少沿着一条岗位线走到底。前端出身的人写过后端，后端出身的人做过前端，客户端工程师也会去碰服务端、构建工具和基础设施。他们遇到什么问题，就去补什么能力，后来能负责的事情也越来越多。

我更希望大家把自己看作软件工程师。前端、后端和测试描述的是当前分工，人的能力取决于当前环境以及自己要解决的问题。

AI 降低了查文档、搭页面、补测试、改配置、生成接口和起草方案这些任务的成本。完成同一批任务所需的时间减少以后，公司自然会重新计算：原来需要十个人解决的问题，现在还需要十个人吗？

代码只是软件的一个环节。AI 降低了“生产下一份代码”的边际成本，不一定同比降低“交付一套可靠软件”的边际成本。

现在，借助 AI 做出一个看起来不错的技术方案已经很容易。让多个模型来回评审几轮，方案往往能写得又完整又好。但到了实施阶段，历史系统、业务约束、协作、测试、上线和回滚都要有人处理。方案能不能进入生产，结果能不能达到预期，考验的就是闭环能力。

只有项目规范清晰、自动化测试完善、Code Review 和上线门禁成熟时，AI 生成的代码可以被低成本验证，效率才容易传导到最终交付。但是如果团队没有审查、测试和清晰的系统边界，AI 只会让错误代码生产得更快，省下来的时间最后会变成技术债、返工和线上事故。

前端最容易看到这种“生成快、验证慢”的落差。

AI 十分钟生成一组 UI，不代表这个功能已经完成。键盘能不能操作？焦点对不对？加载、错误和空状态有没有处理？放进已有设计系统会不会冲突？真实用户能不能走完整条流程？

O’Reilly 把这种落差叫作 Frontend Verification Gap[2]。现在生成 UI 的速度，已经超过很多团队验证 UI 是否可用的速度。

— 生成不等于交付

问题怎么定义，需求从哪里来，真实约束是什么，模型需要哪些上下文，结果怎么验证和集成，系统怎么安全上线，出了问题谁来处理，用户有没有得到价值，这些事情依然昂贵。

到了公司层面，单一任务的执行变快远远不够。

McKinsey Global Institute 的调查[3]显示，近 90% 的公司表示已经投资 AI，但报告获得可衡量收益的公司不到 40%。BCG 对全球 1,250 多家企业的研究[4]则发现，只有约 5% 已经形成较成熟的 AI 能力，并从中获得规模化的显著价值。

这两项调查衡量的内容不同，却指向同一件事：愿意在 AI 上投入的公司很多，能够把这些投入变成规模化收益的公司仍然很少。

公司想靠 AI 提高整体效率，前后的流程也要跟着改。谁有权限、数据从哪里来、不同岗位怎么配合，都需要重新理顺。否则，AI 在一个环节省下来的时间，很快又会耗在审批、等待、反复交接和信息断层上。

流程之外，很多业务知识只存在于人的经验里。为什么这个客户必须走例外流程，为什么这个字段不能随便改，为什么看起来合理的方案以前失败过——模型读不到这些东西。

只有把这些经验变成数据、规则和工具，再根据实际结果不断修正，它们才可能成为公司的壁垒。

任务成本下降了，但组织流程和业务知识决定了这些效率能不能真的用起来，最后也会影响公司怎么用人。

AI 可能减少解决同一批问题所需的人力，也可能降低软件开发成本，让一些过去不值得投入的问题第一次变得值得解决。它最后会减少多少岗位、又带来多少新的工作，现在还很难判断。但如果一个人的工作范围只停留在 AI 能直接生成的那一段，市场越来越难为这部分能力单独买单。

判断力决定能不能看清问题，闭环能力决定能不能把结果做出来。AI 不会凭空补齐一个人的知识体系。连问题全貌都没见过，很难看出模型漏了什么；看出来以后，还要协调资源、验证结果、处理异常，把问题解决。

以前，掌握一套框架和语言，专业能力就很容易被市场识别。AI 降低执行成本以后，框架和语法仍然有用，却越来越难单独说明一个工程师能负责多大的问题。公司还会看他能不能理解系统、业务和组织，能不能参与决策、拿到结果。一个人能处理的问题越重要、越复杂，公司越愿意把关键任务交给他，也越愿意为这份能力付钱。

— 判断与闭环

有些人对 AI 的排斥，不完全来自就业环境。

如果一个人的自我认同是：

“我会 React，我是前端工程师，所以我有价值。”

那么当 AI 能把前端写得很好，我是谁？身份和价值感同时受到威胁。

这种身份上的不安，让我想起 Ruby 程序员、作家 Jonathan Gillette 写过的一句话：

对工程师来说，把技术用来解决真实问题，也是一种创造。

持续创造，会不断把人交给现实检验。做出来的东西可能失败，原来的判断可能过时，今天得心应手的技能和方法，过几年也可能不再好用，那就重新学、重新调整。

一旦停止创造，React、Vue、Java、Spring 就很容易从解决问题的工具，变成需要保护的收藏品。它们最好越来越稀缺，最好一直保值。一旦 AI 也会了，自己的价值感也会跟着动摇。

所以，我更愿意把过去学过的东西当成材料。学过的技术、做过的项目、踩过的坑，都可以重新组合，用来解决下一个问题。旧经验可以继续使用，新工具也可以继续加进来。

职业研究者 Douglas Hall 把这种职业状态称为 Protean Career。职业不再完全由组织替个人规划，一个人要通过持续学习和身份变化管理自己的职业。

前端可以是起点，不必成为一个人必须终身保护的身份。

前端当然会继续需要高性能渲染、跨端架构等垂直专家。只是这些方向门槛高、岗位少，不适合拿来回答所有人的职业焦虑。

沿着问题不断扩展能力，最后往往能形成一专多能。在问题经常跨过岗位边界的团队里，这类人会更有价值，英文叫 Expert Generalist——专家型通才。

每个人能扩展的范围不同。这里说的一专多能，前提是先在一个领域扎得足够深，能判断什么是好、什么是差；再去举一反三地理解相邻领域的底层规律。遇到需要多个岗位共同处理的问题，也知道该找谁、该补什么，以及怎么继续推进。

前端就是一个很好的专业支点。相比很多后端和基础设施岗位，前端离用户更近，更容易形成 Product Sense —— 产品洞察力。

Product Sense，就是能站在用户的角度发现问题，判断什么值得做、什么样才算做好。页面好不好看，只是其中一部分。

前端能看到用户卡在哪一步、哪些操作反复失败、客服总在解释什么。这些都是信号，却不会自动变成 Product Sense。只按设计稿还原页面，做十年也未必懂用户。只有多问一句需求为什么做，参与设计方案的决策，再根据用户反馈和上线结果检验自己的判断，这种能力才会越来越准。

专业深度也不能丢。浏览器、网络、工程化、性能、可访问性这些知识，会直接决定你能不能给 AI 正确的约束，能不能看出一个看似合理的答案在哪些边界下会失效。

有了这个专业支点，AI 也降低了进入陌生领域的门槛。如果大学第一天就有今天的模型，我大概能少走很多弯路，成长得也会快很多。但这不代表无条件相信模型。它擅长什么、哪里容易胡说、哪些结果必须自己验，仍然需要人判断。模型能力一直在变，人与工具的边界也要持续调整。

AI Coding 的工程方法这两年也换了几轮：从 Prompt Engineering、Context Engineering[5]、Harness Engineering[6]、Loop Engineering[7]，到后来的 Goal[8] 和 Dynamic Workflow[9]。关注点也从一句 Prompt 怎么写，扩展到了上下文、Agent 的执行循环，以及整套开发环境里的规则、工具、验证和反馈。早一点掌握这些方法确实能领先一阵，但它们也会逐渐普及。人与人的差距，仍然来自任务怎么拆、上下文怎么给、结果怎么验，以及哪些步骤需要自己把关。

判断力和闭环能力不是凭空产生的，背后还需要知识体系、学习和思考能力、沟通协作、心力，以及复盘和经验沉淀。

在真实工作里，一个模糊问题从识别到交付，往往会同时用到这些能力。

知识体系决定判断力能走多远。能从代码进入系统，从系统进入业务，再从业务进入组织和决策；进入陌生领域时，先找核心约束和验证方式，再补具体 API。

信息不完整时怎样取舍，什么能交给 AI，什么错误一旦发生就很难补救，都在考验判断力。

单位时间能验证多少想法、能把多少想法变成真实结果，也会体现一个人的闭环能力。

把问题推进到结果，还需要主动性、沟通和协作。不等组织递来完整路线图和标准答案，主动找问题、做实验、拿反馈；需要别人参与时，能把问题和方案说清楚，协调资源继续推进。个人的判断变成团队行动，影响力也会慢慢形成。

心力也很重要。一个人同一时间能承担多少事情，项目反复返工、信息总是不全、迟迟看不到结果时还能不能保持状态、继续往前推进，会直接限制他能负责多大范围的工作。

经历不会自动变成资产。一个问题做完，至少思考三个问题：当时为什么这样判断，结果是怎么验证的，下次哪些部分可以直接复用。这些记录可以整理成工具、流程、规范、文档或知识。下次遇到同类问题，自己不用从头摸索，团队和 AI 也有可以直接使用的上下文，过去做过的事才会继续产生价值。

这些积累，也改变了我看待工作年限的方式。工作年限只能粗略说明一个人待了多久。判断能力时，我会看他完整解决过多少问题，处理的问题有没有越来越复杂，做完以后有没有留下可以复用的经验。如果一个人一年解决的问题，无论数量、难度还是影响，都赶得上别人三五年的积累，他成长得自然会更快。

想让工作经历真正增加判断力，可以有意识地研究、试验和复盘。普通工程师也可以这样做，不需要写论文，更不用换一个头衔。接到问题以后，先研究问题、提出假设、做实验、看结果，再决定下一步怎么做。

Anthropic 的招聘页面[10]直接写道，工程师会做很多研究，研究员也会做很多工程。

— Anthropic：工程师与研究员的边界

OpenAI 对 Research Engineer 的描述[11]里，也写到了怎样处理一个模糊问题。先提出假设、搭建实验、分析结果，再判断证据支持什么。

— OpenAI：从模糊问题到实验

AI 省下来的执行时间，我会留一部分给研究、试验、复盘和判断，让自己能负责的问题范围越来越大，也把经验留在个人和团队里。

答案要从她想回到哪一类开发岗位开始找。

如果手里的工作还有值得解决的问题，也能拿到基本的资源和空间，可以先从中找一个真实问题。

但开头这位读者未必有这个条件。她的技术工作很少，大部分是杂活，问题即使存在，也未必有权限和资源去解决。继续让她“从当前工作里成长”，不够现实。

一个具体问题暂时缺少权限，可以等条件成熟再推进。当前岗位长期没有技术工作，也看不到获得资源的可能，就不要一直等。

这种情况下，不必把每一件杂活都包装成机会。先把目标收窄到“回到正常的开发岗位”，再去看目标城市真实在招什么岗位，拿现有简历投一轮、面几次。市场反馈会告诉她，当前缺的是基础、项目经历，还是某一块技术，不用先给自己列一张越来越长的全栈清单。

转行当然可以，但不要拿当前这份偏离开发的工作，替整个行业下结论。

可以先用真实投递、面试和一段时间的恢复性练习，确认自己还能不能、愿不愿意回到开发岗位。如果目标城市的机会、自己的兴趣、生活约束和重新进入这一行的成本都不合适，再把其他行业拿出来认真比较。转行可以是权衡后的选择，不必成为焦虑时的逃生动作。

如果工作里没有练习场，也可以在工作外做一个小项目，把需求、实现、上线和验证走一遍。项目不用大，也不用强行把前端、后端和 Agent 全部补齐。需要什么就补什么，最后留下一段完整的项目经历，证明自己仍在写代码，也能把问题做完。

公司内部如果还有转回开发或参与技术需求的机会，可以认真争取一次。确认没有空间以后，就不要继续等当前岗位提供成长。先保住收入和精力，同时准备下一份工作，是更现实的选择。

等她开始看下一份工作，这套思路也可以用来筛选机会。公司愿意为一个岗位持续付钱，通常是因为还有值得解决的问题。看一个机会时，我会关心三个问题：公司现在最需要解决什么，愿不愿意给资源和空间，结果有没有清晰反馈。问题足够重要，自己也有机会参与解决，做事的过程中自然会接触新的知识和能力。每天重复救火、没有权限处理根因，只会消耗人。

不管问题来自当前工作还是工作外，学习路线都很少会提前告诉你下一步该补什么。那些反复出现、大家都嫌麻烦、却一直没人处理的问题，往往就是机会。

这些问题不一定是什么大项目。比如，线上偶尔出现提交失败，客服只能让用户重试，研发每次都临时查一遍日志。有的人慢慢习惯了，处理完这一次就算结束；也有人会忍不住继续往下查：为什么总在这里出问题，能不能把错误信息、埋点和链路日志补齐，让下一次排查不用再从头开始。

没有权限、排不上优先级、缺少其他团队配合，都可能让问题暂时改不了。但看见问题以后，可以先把现象、影响和需要的条件记下来。等资源和机会出现，就知道该往哪里推进。

这类问题通常会跨过你当前的岗位边界。用户流程出了问题，原因可能在接口、数据、构建和发布，也可能是上下游信息没有对齐。沿着问题查下去，下一步该补什么能力，也就慢慢清楚了。

我以前主要写前端业务，但对 DevOps 和 CI/CD 已经有比较深入的理解。后来遇到接口、构建和发布上的问题，也会顺着问题继续往下看，慢慢理解后端和软件从开发到上线的整条链路。回头看，很多能力都是在解决这些具体问题时补起来的。

这不要求一个人什么都做，也不意味着无限兜底。每一步不一定亲手完成，但至少要知道问题下一步在哪里、需要找谁、缺什么条件，以及怎样确认结果。

用户能不能正常使用、系统能不能稳定上线、问题有没有真的改善，才决定这件事是否结束。

— 沿着问题成长

找到问题以后，先想清楚七件事

先把注意力从“我要写什么代码”，移到“谁遇到了什么问题，我怎么知道它真的改善了”。

动手写代码以前，可以先把七件事想清楚：

这七个问题可以防止自己一看到问题，就直接想解决方案和代码，漏掉受益人、约束和验收结果。

想清楚以后，答案可能是改一段代码，也可能是补埋点、加监控、改流程、找人协作，甚至暂时什么都不做。技术方案只是解决问题的一种手段。

找一个影响范围可控、两周内能看到变化、失败可以回滚的问题。先确认真的有人在为它付出成本，再把它推进到结果验证。

做完以后，自然会知道下一步该补后端、数据、DevOps、产品还是 Agent。在哪一步卡住，就去补哪一块能力。这样学到的东西马上能用，也不会被职业焦虑牵着到处追新技术。

解决问题的能力到了招聘市场，也会反映在简历和面试里。前面这七件事能做好，就是市场愿意买单的能力。

简历里很常见“使用 XX 技术实现 XX 功能”的写法，然后花很多篇幅证明方案有多复杂。技术细节写了很多，问题背景、受益人和结果却没有交代。

一段有说服力的经历，会讲清楚当时的背景、谁正在为这个问题付出成本、为什么选择这个办法、最后带来了什么变化，以及怎样确认变化真的发生了。

工作量、技术复杂度和问题价值是三笔账。 写了多少代码、做了多少配置、掌握多少框架和语言，能说明工作量和技术复杂度。问题有多重要、工程师做出了哪些判断、最后带来了多少价值，会决定这段经历能不能被市场识别。

几年前招聘高级工程师看这些，今天仍然看这些。AI 让代码越来越便宜，藏在技术名词后面的能力也更容易暴露出来。没有解决过真实问题，再漂亮的叙事也只是包装。

简历和面试怎么讲清楚这些经历，后面的面试系列再展开。

行业周期仍然会影响招聘。长期这样选择机会、处理工作，一个人能负责的事情会越来越多，对某个岗位、某家公司提供机会的依赖也会越来越小，面对变化时手里的选择也会更多。

未来还会有多少岗位叫“前端工程师”，我不知道。但只要公司还需要有人理解用户、判断问题、组织资源并把结果做出来，具备这些能力的人，就依然有自己的位置。

我不再寻找一种永远不会被 AI 取代的能力，因为过去学过的技术、做过的项目、踩过的坑，都不会白费。它们未必还能维持过去的价格，但都可以成为解决下一个问题的材料。