AI 前端工程师

这篇文章想从个人视角聊一聊：在 AI 时代，工程师该如何成长并生存下去。

在我还是初级工程师时，读过的文章中给我印象最深的一篇，是裴辉东的《前端工程师职业路线图：面向初级工程师的三条专业发展路径》。文章将前端工程师的职业发展分为三条路径：Web 专精（Software Engineer）/ 产品专精（Product Engineer）/ 运营专精（Full-Stack Engineer），还进一步梳理了“优秀工程师的五项基本能力”和“成为资深工程师的三个要点”。那时，最大的议题还是思考自己该在每条路径上积累哪些能力。然而，读完那篇文章还不到两年，议题本身就彻底变了。

最近和工程师同事们聊天时，我能感觉到，大家的烦恼和过去几年听到的已经不太一样了。

• “公司引入 AI 之后，把设计稿丢给它，基本都能做出来。方便倒是方便……”
• “招聘市场冷得厉害。”
• “直接合并 AI 写的代码又有点怕，可要逐一检查，效率又会下降，挺让人纠结的。”

我也经历过类似的阶段，现在仍然身处其中。一两年前，我还只把 AI 当作“好用的辅助工具”，如今却已经到了无法想象没有 AI 要怎么开发的程度（我写这篇文章时，也在请 Claude 帮忙做调研）。这篇文章算是裴辉东那篇文章的续篇。我想从自己的视角梳理一下：这段时间里，景象发生了怎样的变化；面对变化后的环境，前端工程师又该进一步培养哪些能力。

这次我也尽可能查找并核验了大量资料，但这个领域变化实在太快，文章发布时，其中部分内容可能已经过时，还请大家谅解。如果有值得反驳或讨论之处，欢迎随时留言。

“现在不是什么都能让 AI 做了吗？”

首先，有一件事必须说清楚：“AI 什么都能做”这句话是真的吗？到什么程度是真的，又从哪里开始只是幻想？

2025 年 2 月，OpenAI 联合创始人、前特斯拉 AI 总监 Andrej Karpathy 在 Twitter 上写下了这样一句话。

出现了一种我称之为“vibe coding”的新编程方式：你完全顺着感觉走，拥抱指数级增长，甚至忘记代码本身的存在。

There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

所谓 vibe coding，简单来说就是“把键盘交给 AI，自己只用自然语言描述想要的东西”的编程方式。没有架构文档，没有样板代码，也不用搜索分号。代码就这样跟着感觉跑起来。不到一年，这个词就成了英语开发者社区里的标准用语。

但整整一年后的 2026 年 2 月，同一位 Karpathy 却往后退了一步。他提议用 “agentic engineering” 取代 vibe coding。两者的区别很明确。

• Vibe coding：描述自己想要什么，然后接受产出
• Agentic engineering：设计系统、明确约束，再用 AI 加速实现那些已经在脑中推理完成的方案

一年前，“只要吩咐一下，它就全都能做出来”还是基本共识；如今，“设计该让 AI 做什么、怎么做的能力”本身，已经成为一种工程能力。这股趋势并不只来自某一个人的推文。同一时期，Google 工程师 Addy Osmani 出版了《Beyond Vibe Coding: From Coder to AI-Era Developer》，并明确指出：“AI 只是助手，不是可以自主信赖的程序员。你才是资深开发者，LLM 的存在是为了加速你的判断。”

工具正在狂飙

工具阵营也顺应这股趋势快速演进。截至 2026 年 5 月，最常被提及的编程工具包括 Cursor、Claude Code、GitHub Copilot、Windsurf、v0 by Vercel、Bolt.new 和 Devin。

v0 的变化尤其具有象征意义。Vercel 使用了“90% problem”这个说法，意思是现实开发中 90% 的工作都发生在现有代码库和基础设施之内。起初，只要能做好全新项目原型就够了；如今，v0 已经可以直接导入 GitHub 仓库进行开发、强制遵循设计系统，并自动读取部署环境变量。对于资深工程师提出的“AI 不就只会做好玩具式演示吗”这一质疑，工具阵营正在亲自作答。

大型科技公司的代码库最能体现这种变化。

Google 的 Sundar Pichai 在 2024 年 10 月的第三季度财报电话会议上宣布，“超过 25% 的新代码由 AI 生成，再由工程师审核和批准”，到 2025 年 4 月，这一比例已升至 30% 以上。Microsoft 的 Satya Nadella 在 2025 年 4 月的 LlamaCon 上透露，“我们的代码中，最多有 30% 是 AI 编写的”。Meta 的内部目标甚至已经提高到“截至 2026 年上半年，让 65% 的工程师使用 AI 生成至少 75% 的提交内容”。

韩国国内的趋势也没有不同。Toss 为了让开发者不再需要自己找文档、提升开发者体验，搭建了基于 AI 的文档系统，并更进一步探讨了“AI 时代，取消设计师岗位之后发生的事”之类的话题。Daangn 每周二通过 AI Show & Tell 分享各团队的实验，还开始打出“超越工程师，成为构建者”的招聘口号。Woowa Brothers 则通过“在 AI 编写代码的时代，你还愿意成为开发者吗？”等文章传递这样的信息：“开发者的本质不在代码，而在于定义和解决问题的能力。”

但数字讲述的是另一个故事

只看到这里，很容易得出“现在只要吩咐一下，什么都能做”的结论。但真正查看数据后，故事却有些不同。

先看综合分析软件开发现状的 2025 Stack Overflow Developer Survey 中的数据。

• 84% 的开发者表示正在使用或计划使用 AI 工具。（高于 2024 年的 76%）
• 51% 的专业开发者每天都使用 AI 工具。
• 但对 AI 工具的好感度（positive sentiment）反而下降了。2023 年和 2024 年都在 70% 以上，2025 年却降到了 60%。
• 从业 10 年以上的资深开发者对 AI 输出的信任度最低。

总结起来就是：“大家确实都在用，但越用越不放心。”

非营利研究机构 METR 在 2025 年开展的一项实验，更鲜明地展现了认知与现实之间的落差。这是一项对照实验：16 名熟练的开源开发者平均拥有 5 年经验和 1,500 次提交，研究者让他们完成 246 项任务，并随机决定是否允许使用 AI。结果如下。

• 开始前，开发者预测“使用 AI 会快 24%”。
• 完成任务后，他们仍自我评价“感觉大约快了 20%”。
• 但实际测量结果却是：慢了 19%。

研究人员指出的原因很有意思。AI 生成代码的接受率低于 44%；即使代码被拒绝，审查和测试它也要花时间；就连被接受的代码，也需要大量时间来审核和修改。明明变慢了，却误以为自己变快了——这种落差正是资深开发者对 AI 日益怀疑的原因之一。

此外，“AI 编写的代码质量”本身也并不理想。来看 Veracode 让 100 多个 AI 模型编写代码的实验。

• AI 生成代码中有 45% 包含 OWASP Top 10 安全漏洞。
• XSS（跨站脚本）防护失败率为 86%。
• 日志注入（Log Injection）防护失败率为 88%。
• 另一项研究报告称，AI 代码的漏洞密度是人类代码的 2.7 倍。

尤其是与前端直接相关的 XSS 防护失败率高达 86%，值得更严肃地看待。直接合并 AI 写出的表单输入框究竟意味着什么，这个数字已经说明得很清楚。（有过前端安全审计经验的开发者，哪怕亲手写 dangerouslySetInnerHTML 时也会觉得别扭、心里不安；AI 悄悄塞进去的就更让人害怕了。）

质量方面也释放出相似的信号。GitClear 分析了 2020 至 2024 年间 2.11 亿行代码变更，结果如下。

• 编写后两周内被回滚（reverted）的代码比例（Code Churn）：2020 年 5.5% → 2024 年 7.9%
• 重构所占比例：2021 年 25% → 2024 年低于 10%
• 复制粘贴（克隆）比例：2021 年 8.3% → 2024 年 12.3%（2025 年更是增长到四倍）

这并不难解读。快速产出代码的能力增强了，但写出值得再次打磨的代码的能力却下降了。分析《财富》50 强企业的 Apiiro 数据给出的结果更为强烈：借助 AI 开发的开发者，提交数量是同事的 3～4 倍，却制造出 10 倍的安全问题。权限提升路径（privilege escalation）暴增 322%，架构设计缺陷则暴增 153%。

AI 取代了什么，又没能取代什么

工具在狂飙，数据却很微妙。那么 AI 究竟取代了什么，又有哪些事情尚未取代？只有把这条界线划清楚，我们才知道该把时间投入在哪里。

被取代的，是开发者亲手输入代码的那部分工作。编写样板代码和重复代码的场景减少了；只要有设计稿，几分钟内就能产出符合约定水准的页面；搜索语法和 API 所需的时间，以及学习曲线，也都大幅缩短。简而言之，AI 拉平了“生产速度”。

但在“判断”这一领域，它还没能取代人。（准确地说，更接近于“尚未达到我们的期待”。虽然每个人运用 AI 的能力存在差距，但这里以平均使用体验为准展开讨论。）

首先遇到的难题，是将需求转化为规格。把模糊的业务需求转化成明确的边界情况和状态机，仍然更需要人类深度参与。理解系统层面的影响也是如此：这个组件会如何影响 bundle、依赖项能否 tree-shaking、数据获取模式会怎样影响 Core Web Vitals 中的 INP（Interaction to Next Paint）得分——面对这类问题，即便 AI 给出了看似合理的答案，最终仍要由人再看一遍才能放心。

如前文所述，45% 的 OWASP 漏洞意味着安全与风险评估也不能忽视；除此之外，还有维护设计系统与一致性，即检查新组件是否与现有系统的 token、无障碍规范和交互模式保持一致；以及理解客户与市场语境，即判断为什么需要这项功能、它应该放进哪条用户流程。这些领域同样如此。

最后，借用 yceffort 文章中的说法，“系统复杂度与团队对该系统理解程度之间的差距”就是认知债务（Cognitive Debt）。AI 引入后，这条差距反而扩大得更快，因此缩小差距本身依然是人的职责。

消失的不是开发者，而是开发者过去所做工作的形式。瓶颈已从“创造的速度”转移到“决策的速度”。

同样地，Toss 的《开发者会被 AI 取代吗？》给出了更沉重的判断。文章的核心是：AI 并非取代所有人力，而是在移除学徒阶梯（apprenticeship ladder）。等到如今的资深工程师在 10～20 年后退休时，能够设计复杂系统的下一代人才将会不足。这已不只是“我们公司明年该怎么招聘”的问题，而像是一颗埋在整个行业里的延时炸弹。（我认为这是在这个令人忧虑的时期写得非常好的一篇文章。）

AI 做出的“能运行的第一个版本”占 70%。走到“可以真正提供给用户使用的版本”，剩下的 30% 属于人。而补足这 30% 的能力并非一朝一夕可以形成。这正是学徒阶梯问题的本质：如果编写样板代码和简单组件、让自己“亲手沾上代码”的时间消失了，能够补足那 30% 的人也会一同消失。

裴辉东的原文将写出好代码、最大化当前价值（在快速发布与长期可维护性之间取得平衡）、基于数据决策、帮助同事有效决策、持续学习列为“优秀工程师的五项基本能力”。这五项在 AI 时代依然有效，但其中最后一项正处在最危险的位置。学习本身没有消失，改变的是学习对象。过去我们学习“这个工具怎么用”，现在则应该把时间花在理解“整个系统是如何运转的”上。更可怕的是 Evan Moon 所指出的：“当 AI 代替人编写代码时，大脑的认知负荷会骤然降低。”认知负荷降低听起来是件好事，但危险在于，这种负荷恰恰是学习的材料。越轻松，越难成长。

这里自然会出现一个问题：那么，裴辉东文章中的三条路径（Web 专精/产品专精/运营专精）如今已经没有意义了吗？

我的看法不同。这些路径本身依然有效，只是每条路径都顺应 AI 时代向前演进了一个阶段。下面就来梳理各条路径的景象发生了怎样的变化。

从生产者到“验证者”

在裴辉东的原文中，Web 专精路径被归入 Software Engineer。其核心包括“深入理解并运用互联网、Web 浏览器和 HTML/CSS/JS”，了解 Web 生态工具的优缺点并具备故障排查经验，以及对新技术保持敏锐。通往资深岗位的方向则包括 Web 生态工具厂商工程师 / 前端教育者 / 复杂产品组织的技术负责人。简单说，他们是“深入钻研浏览器与 HTML/CSS/JS 工作原理的人”。直到一两年前，他们最大的武器还是“能比任何人都更准确地写代码”。

AI 时代，他们的价值发生了怎样的变化？如果只看写代码的速度，AI 已经追了上来。但**“准确评估 AI 所写代码的能力”**，反而几乎成了他们独有的优势。

• 使用 AI 的普通人：已经按我的需求实现了，运行也正常。
• 使用 AI 的开发者：虽然能运行，但这个依赖项可能引发某些问题；这种模式按这样的方式改进才更符合约定。再把相关部分检查一遍吧。

前文提到的 Veracode 研究中，有 XSS 防护失败率 86%、日志注入防护失败率 88% 这两项数据。能够发现并解决这些问题的人，正是像我们这样的专业人士。他们会自然演变为负责 AI 产出质量保证（QA）的资深角色。

此外，专业人士的领域中还新增了一个全新的主题：**生成式 UI（Generative UI）**与 AI 界面设计。比如，以流式方式呈现 LLM 回答的聊天 UI、可在中途停止的 abort 控件、Markdown/代码块的渐进式渲染、以内联方式展示工具调用结果的用户体验，以及运用 Vercel AI SDK 或 MCP（Model Context Protocol）进行助手集成。在这个领域，“既准确理解 Web 工作原理，又理解 LLM 的运行特性，并能加以应用和利用的人”正迎来爆发式需求。

自然而然地演进为 Product Engineer

产品专精是受益最大的一条路径。对市场和客户理解深入、经常与外部利益相关者沟通的人，一旦加上 AI，就拥有了强大得多的武器。这条路径的另一项特点，是其资深发展方向中也包括增长工程师、顾问 / 转型为 PM、PO、CPO等向其他职能的扩展。

一个有趣的变化是，这条路径的名称开始成为全球标准。原文其实已经将其称为“Product Engineer”，但我读到那篇文章时，这个表达对我来说还有些陌生。一年后的今天，它已经普及到Vercel 将职位描述中的“Fullstack Engineer”统一改为“Product Engineer”的程度。

Lee Robinson 将 Product Engineer 的核心素质归纳为三项。

• 重视迭代（Iteration）：快速完成部署 → 反馈 → 调整的循环。
• 以客户为中心：直接与客户交谈并改进产品。
• 务实：“所有技术选择都只是手段。”对产品目标没有贡献的工具要果断舍弃。

这里有一个陷阱：如果产品专精工程师只被理解为“做得快的人”，就会很危险。AI 出现后，这种风险更大了，因为“快速塞进功能”如今任何职能的人都可以借助 AI 工具完成。Product Engineer 的差异化优势在于“准确定义客户问题，并用最小的解决方案快速验证”，而不在于“手快”。

在这股趋势下，Design Engineer 开始升级为正式岗位。Vercel 正在把设计工程师作为年薪 20 万美元以上的正式发展路径进行招聘，Linear 和 Stripe 也在朝类似方向发展。这个岗位直接消除了前端与设计之间的交接。AI 能快速把图画出来，因此，同时处理“该画什么 + 画出的结果是否符合一致的设计系统”的能力变得更加稀缺。

AI 编排者

运营专精是变化最剧烈的一条路径。裴辉东的原文将其归为 Full-Stack Engineer，定义是“高度关注项目结构、集成、测试和部署，能亲自处理简单的 API 与基础设施，填补组织空白并改善流程的人”。过去一两年间，运营 AI 智能体本身的职责又叠加在这条路径之上，使其边界迅速扩张。

在梳理2026 年趋势时，Addy Osmani 将**“编排编程智能体（Orchestrating Coding Agents）”**列为核心概念。它意味着不再只是让一个 AI 做事，而是设计并运营一个让多个 AI 智能体同时协作的系统。在同样的脉络下，他提出了名为“agent-skills”的框架，并有人主张将专业工作流、质量门槛和行业最佳实践直接编码进智能体的行为逻辑中。

汇总相关资料后，我认为运营路径工程师接下来需要掌握的新关键词如下。

• MCP（Model Context Protocol）：Anthropic 提出的 LLM 与外部工具连接标准
• AI 治理：管理谁能在什么上下文中使用 AI，以及密钥或机密信息是否会泄露
• 智能体评估（Evaluation）：自动评测智能体产出的流水线
• AI 门禁：PR 合并前自动验证安全与质量，并为 AI 代码添加标签

原文将大型组织的平台团队工程师 / 技术负责人 / 敏捷教练 / 技术项目经理（TPM）/ CTO等岗位列为运营路径的资深发展方向。这些方向如今依然有效，只是可以认为又增加了 “AI 开发基础设施负责人”、**“开发者生产力（DevProd）工程师”**等新岗位。

三条路径各自演进的同时，也有一些能力在所有路径中都变得更加重要。我原本想以五年后为基准来思考，但按照如今的发展速度，就连一年都显得太长。因此，先把视野缩短到“明年”左右，谈谈在我看来会变得更加重要的能力。

五项能力

第一项是编写规格（Specification）的能力。 AI 时代，“编程的起点”不是键盘，而是规格。准确写清楚要让 AI 做什么的能力，已经比代码本身更重要。这里所说的规格，并不是什么宏大的 RFC 文档，而是像这样一些东西：用代码写下业务逻辑预期行为的测试；整理 UI 组件场景和视觉契约的 Storybook story；明确数据流契约的类型定义。归根结底，这是预先铺设一套能自动验证 AI 产出的标准。缺少这一步就开始让 AI 编程，问题会不断累积。

第二项是验证与判断力。 AI 会自信地生成看似合理、实则错误的代码。因此，我认为“快速而准确地审查 AI 代码的能力”本身就是核心。要能判断它是否漏掉了安全标头、输入净化、CSRF 令牌，无障碍能力（ARIA、键盘导航、焦点陷阱）是否仍然有效，以及渲染成本、内存、包体积等性能影响是否存在问题。不经审查就把 AI 垃圾代码扔进 PR，是工程师的失职。点击合并按钮的仍然是人，这份责任不能推给 AI。Stack Overflow 调查中，资深工程师对 AI 的信任度最低，很可能正是因为他们拥有发现这些细节的眼光。

第三项是系统理解与架构思维。 AI 擅长一次处理一个文件，对流程和关联也具备出色的理解能力。AI 能快速修复症状，但能力出众的开发者会寻找根本原因。培养这项能力的方法之一，是有意识地开展 Architecture Retrospective 等活动。代码变化得越快，团队就越需要主动提升对系统的理解，否则认知债务会迅速积累。

第四项是 AI 编排能力。 运用 AI 本身的能力，也正在分化成独立的技能组合。这已经不只是“善于写提示词”，而是需要整体掌握：把工作拆分成小工单的能力；为同一项工作选择合适模型的能力；设计智能体评估与验证流水线的能力；以及智能体失败时的回滚策略。Steve Yegge 将这一趋势归纳为六个阶段（traditional → completions → chat → coding agents → agent clusters → agent fleets）。

第五项是 Context Engineering。 这是从 2025 年年中起，Karpathy 与 Shopify CEO Tobi Lütke 一同推动的概念。简单说，就是“设计要让 AI 看到哪些上下文、以什么形式呈现、呈现多少的能力”。具体表现包括：把项目约定、架构原则和禁忌事项整理到 AI 随时能够触及的地方，即维护 CLAUDE.md / rules 文件；不把所有文件都塞进上下文，只筛选相关模块展示给 AI，即有意缩减上下文；将计划 → 实现 → 验证拆分到不同会话，避免上下文污染，即明确划分阶段；以及通过标准接口接入设计系统、API schema、监控数据等外部上下文，即通过 MCP 引入外部上下文。Anthropic 官方文档将其称为“the new prompt engineering”，并明确指出，单个提示词绝不可能容纳系统的架构知识、模式和隐性经验。换句话说，比起“一次写出好的提示词”，“设计一个让 AI 始终获得优质上下文的环境”已经重要得多。

读到这里，自然会产生一个问题：那么具体该怎么学习？我自己采用的方法大致有四种。

学习方法

原文提到的“持续学习”依然有效，但学习时间的分配必须改变。

有些领域过去投入了很多时间，如今可以减少；相对地，也有些复杂领域过去因为太难或耗时太久而没有去做。后者包括编写测试规格、使用性能测量工具（Lighthouse、WebPageTest、Chrome DevTools Performance）、无障碍（WCAG）、安全（尤其是 OWASP Top 10）等。另外，还有 Vercel AI SDK、LangChain.js、MCP、流式 UI 模式、智能体评估流水线等需要从头学习的新领域。重要的是认识到自己需要哪些能力，并合理分配时间。

AI 生成的代码很容易变得庞大，一分钟就能产出几百行。因此，如果不主动管理 PR 大小和合并周期，代码审查本身就会崩溃。公司引入 AI 后，平均 PR 大小增加了 18%，每个 PR 的事故数量增加了 24%，变更失败率增加了 30%。结合前文的数据来看，如果写得太大、一次性合并，就很难掌握流程和体现意图，因此细分工作单元非常重要。

这也直接关联到 Evan Moon 文章所指出的认知负荷降低问题。最好每天单独留出一两个小时，在不使用 AI 的情况下写代码。例如亲手画架构图，或逐行阅读自己不熟悉领域的代码。（我自己也会在每天午饭后容易犯困的时段，不用 AI 写一会儿代码。这段时间让我不至于离曾经熟悉的感觉越来越远。）

这并不只是为了“不忘记旧方法”。AI 代劳了多少时间，你自己的深度就少成长多少。验证与判断力、系统理解等能力，都是亲自碰壁时间的函数。

所以，我们要做的是

虽然前面写了很长，但其实，AI 时代能够生存下来的前端工程师形象，与原文得出的结论并没有太大不同。原文列出的优秀资深工程师的三个要点如下。

• 努力忠于基本功。（持续保持并加强五项基本能力）
• 即便不是名义上的领导者，也通过示范性行动自然地发挥影响力。
• 不满足于做好分配到手的工作，而是审视前后语境，创造更大的影响力。

把这些应用到 AI 时代，就会变成下面这样。

• 忠于 AI 生成的代码之外的基本功（Web、系统、业务领域）。
• 方向由自己决定，而不是交给 AI。即便不是名义上的负责人，也要判断“该往哪里走”。
• 不只把 AI 当作个人生产力工具，还要用它解决团队和系统的瓶颈。

从 Open AI 权威专家 Andrej Karpathy 的文章来看，他如今强调的 “agentic engineering”，核心归根结底也是一样的：设计系统、明确约束，再用 AI 加速实现那些已经在脑中推理完成的方案。工具变了，但方向键仍然掌握在人手中。

原文最后传达的信息，同样是“不满足于做好分配到手的工作，而是审视前后语境，创造更大影响力的人”才会成为资深工程师。AI 时代只是“影响力”的定义发生了变化。有人会把 AI 一小时做出的页面，以“能运行就行”为由直接合并；也有人会再花 30 分钟，检查这个页面在无障碍、安全、性能和系统一致性方面究竟有多合理。一年后被认可为资深工程师的，会是后者。站在 70%（运行）与 30%（应用和运用）的边界上，选择站到 30% 那一侧的人，才能生存下来。

希望读到这篇文章的前端工程师，也能对“现在还该继续学什么？”这个问题找到自己的答案。没有人知道标准答案，但我相当确信：越是在 AI 编写代码的时代，越是能看到“代码之外的东西”的人，越能生存下去。希望一年后还能再次整理成文章，回顾这幅景象又发生了怎样的变化。就此收笔。

（如果一年后再看，这篇文章显得过于理所当然或已经过时，那或许正说明我们应对得很好。）

参考资料

참고 자료