从前端工程化到 AI 工程化

最近经常会看到一个问题：AI Coding 越来越强，前端研发工程师未来还应该往哪里走？

这个问题我也一直在想。尤其是这两年系统使用 Claude Code、Codex 和各种 Agent 工作流以后，我越来越确定一件事：AI 不会简单替代前端，但它会重新定义前端研发的价值重心。

如果一个前端同学的主要竞争力只是“把设计稿还原成页面”“根据接口字段写表单和列表”“修一些常规样式问题”，那压力一定会越来越大。因为这些任务输入明确、模式重复、反馈容易验证，本来就很适合被 AI 接管。

但这不代表前端没有未来。恰恰相反，AI 把低杠杆的重复代码工作拿走以后，前端研发需要重新回到一个更本质的问题：我们到底靠什么创造价值？

我自己的成长路径，某种程度上也一直在回答这个问题。

我的路径：从写页面，到沉淀系统

我最早也是从普通业务开发开始的。

电商页面、后台系统、前后端联调、基础组件封装、工程配置，这些都做过。那个阶段最大的收获，不是掌握了某个框架，而是开始理解真实业务里的前端并不只是 UI。页面背后有流程，有数据，有角色协作，也有很多“看起来简单但一旦规模变大就很难维护”的细节。

后来在阿里做直播互动，我负责的是直播互动平台和跨端互动容器。这个阶段对我影响很大。

直播间里的红包雨、福袋、购物车这些玩法，表面看是一个个前端活动，实际难点在于高频迭代、多端运行、灰度发布、异常降级和客户端发版依赖。只靠一次次写业务代码，永远跟不上节奏。所以我们做了生产侧平台，也做了消费侧跨端容器，把物料创建、调试、测试、发布、回滚、多端渲染、JSBridge 通信和降级兜底串成一套体系。

那时候我第一次特别明确地感受到：前端真正的价值，不只是把某个需求做完，而是把一类需求变得更容易被持续生产。

到 XTransfer 以后，这条路径又往前走了一步。

跨境金融业务里，前端面对的不只是页面复杂，还有多仓库、多团队、多语言、多角色协作，以及金融场景下对质量和稳定性的要求。于是我做了 xt-spec 前端代码成熟度治理工具，把规则定义、扫描检测、CI 拦截、修复建议和持续治理串成闭环，推动 20+ 金融前端应用接入，把红线问题从 2157 个治理到 0。

同时也做了多语言可视化编排平台，把原来分散在表格、脚本、代码仓库和人工沟通里的国际化流程收敛到平台侧；做了神策埋点可视化分析插件，把产品、业务、研发依赖多系统切换的分析流程前置到页面现场。

这些事情看起来领域不一样：跨端容器、工程治理、多语言平台、浏览器插件。但底层其实是一件事：

把重复的、高协作成本的、高风险的事情，从“靠人记住和执行”，变成“靠工具、平台、规范和流程自动运转”。

这也是我理解前端未来成长路径的起点。

AI 时代，前端不能只停在执行层

AI 最先冲击的一定是执行层。

以前一个表单页面、一个列表筛选、一个弹窗流程，可能需要人花半天到一天。现在只要上下文足够清楚，组件库和接口约定足够稳定，AI 很快就能生成一个可用版本。

所以前端同学如果还把自己定位成“需求来了我写页面，接口来了我接字段”，未来会越来越被动。

但执行层变便宜，不代表工程师变便宜。真正变贵的是这些能力：

• 能不能判断一个需求背后的业务目标。
• 能不能识别流程里的状态、权限、异常和风险。
• 能不能把重复问题抽象成组件、工具、平台或工作流。
• 能不能设计出让人和 AI 都更容易产出好代码的工程体系。
• 能不能对 AI 生成结果做质量判断和兜底。

AI 擅长完成明确任务，但它不天然知道什么是正确的问题，也不天然知道一个系统长期应该怎么演进。定义问题、设计边界、建立反馈、控制风险，这些仍然需要工程师。

所以前端未来的第一条成长路径，是从执行型研发走向系统型研发。

第一层成长：从页面开发，到业务建模

前端离用户最近，也离业务流程最近。

很多人说前端是 UI 层，但在真实项目里，前端经常是业务复杂度最先显形的地方：哪些状态可以共存，哪些操作需要互斥，异常后如何恢复，权限如何收敛，多语言如何同步，埋点如何验证，性能问题在哪里暴露。

这些问题如果前端只是被动接收，最后就会变成一堆页面补丁；如果前端主动建模，就会变成稳定的业务流程和可复用的工程能力。

我现在越来越觉得，前端同学要有一点 Product Engineer 的能力。不是替代产品经理，而是能理解一个需求为什么存在，能把模糊目标拆成用户路径、状态模型和工程任务。

AI 会让原型变得更容易，也会让“先做出来看看”变得更便宜。前端如果能把产品理解、交互判断和工程实现结合起来，就会比单纯写代码有更高的杠杆。

第二层成长：从组件使用者，到平台和基础设施建设者

我过去做直播互动平台、多语言平台、埋点分析插件和 xt-spec，最大的共同点是：它们都不是单点功能，而是基础设施。

基础设施的价值在 AI 时代会被继续放大。

因为 AI 生成代码的质量，很大程度取决于它所在的工程环境。如果项目没有清楚的组件边界、没有统一的状态模式、没有稳定的接口约定、没有规则和测试兜底，AI 生成出来的东西很容易“当下能跑，长期难维护”。

反过来，如果团队有成熟的组件体系、脚手架、CLI、CI/CD、静态扫描、代码规范、设计系统和业务模板，AI 就能在更高质量的轨道上工作。

这时候前端研发的价值，就从“我亲手写了多少代码”，变成“我设计的系统能不能让更多人，包括 AI，更稳定地写出好代码”。

过去我们做工程化，是为了提升人的研发效率。接下来做工程化，还要考虑如何提升 AI 的研发质量。

这会让前端平台化、工程治理、工具链和研发效能这些方向继续重要，甚至更重要。

第三层成长：从工程治理，到 AI 治理闭环

工程治理这件事，我做 xt-spec 的时候感触很深。

如果治理只靠人看、靠人记、靠人推动，很容易变成短期运动。真正能长期生效的治理，一定要进入日常工作流：规则可执行，问题可定位，增量能拦截，修复有建议，趋势能被持续观察。

AI 加进来以后，治理会往下一步走。

以前工具主要负责发现问题，比如扫描出依赖风险、配置问题、风险写法和规范缺失。未来工具还应该能解释问题、生成修复方案、自动提交 PR，并在验证失败后继续迭代。

这不是简单地“让 AI 帮忙改代码”，而是把静态规则、项目上下文、修复策略、测试验证和人工兜底串成闭环。

前端工程师如果有工程治理经验，会很适合做这类 AI 工程化工具。因为我们既理解代码质量问题，也理解工具链、CI、仓库协作和团队接入成本。

我认为未来很多团队真正需要的，不是一个会聊天的 AI，而是一套能嵌入研发流程的 AI 治理系统。

第四层成长：从使用 AI，到构建 AI 工作流

很多人现在用 AI，还是停留在聊天窗口里。

复制一段代码，问怎么改；贴一个报错，问怎么修；描述一个需求，让它生成页面。这当然有用，但提效更多是个人级的。

真正有价值的是把 AI 接进工作流：

• PR 自动 Review，并在后续变更时做增量 Review。
• 线上日志和异常自动归因，必要时生成修复 PR。
• 依赖升级自动检查、验证和提交。
• 多语言、埋点、权限、表单配置自动补齐。
• 工程扫描结果自动解释、修复、验证和回写。
• 常见需求从文档自动拆解成任务、代码、测试和发布说明。

这些事情和我过去做的平台化、工具化经验是一脉相承的。

以前我们把人工流程沉淀成平台；现在要进一步把平台里的关键节点交给 AI，让 AI 成为流程的一部分。人不再一行行盯着所有细节，而是负责定义目标、设计规则、审核关键结果和处理例外。

这也是我最近越来越关注 Harness、Agent Workflow、Skill、Cron Task 的原因。

AI 时代真正的提效，不只是 prompt 写得更好，而是工作流里人的节点越来越少，反馈循环越来越短，系统可以自我检查、自我修复、自我沉淀。

第五层成长：从前端工程师，到 AI 应用工程师

我觉得前端同学往 AI 应用工程师方向走，是一条很自然的路。

因为前端原本就擅长连接。

连接用户和系统，连接产品和技术，连接浏览器和服务端，连接多端环境，连接工具链和研发流程。AI 应用本质上也需要连接：模型、上下文、工具、数据、权限、记忆、评估、日志、成本和用户体验。

一个真正可用的 AI 应用，不只是套一个聊天框，也不只是调一个模型接口。它需要处理很多工程问题：

• 上下文怎么组织。
• 工具调用怎么设计。
• 权限和数据边界怎么控制。
• 结果怎么评估。
• 失败怎么兜底。
• 成本和延迟怎么平衡。
• 用户如何理解和接管 AI 的行为。

这些问题里有大量前端工程师熟悉的部分。尤其是做过复杂 Web 系统、跨端容器、平台化工具和工程治理的人，会更容易理解 AI 应用落地里的复杂性。

所以我不太认同“前端要被 AI 淘汰”这种简单判断。更准确地说，前端需要从 UI 工程师升级成更完整的应用工程师，再进一步升级成 AI 应用工程师。

我会重点补的能力

如果结合我自己的路径，接下来我会重点补几类能力。

第一是更系统的 AI 应用架构能力。包括 Agent 工作流、工具调用、上下文工程、评估体系、可观测性和成本控制。这些决定 AI 应用能不能从 Demo 走到真实生产。

第二是后端和数据连接能力。前端要做 AI 应用工程，不能只停在页面层，需要能把模型、业务数据、权限系统、任务系统和工作流编排串起来。

第三是工程治理智能化能力。过去我做 xt-spec，是把规则和流程自动化；下一步更值得做的是把扫描、解释、修复、验证和 PR 串成 AI 主导的治理闭环。

第四是持续沉淀能力。AI 时代很容易每天试新工具，但真正产生复利的是把经验沉淀成规则、Skill、模板、脚手架、工作流和团队共识。

这些能力不是和过去的前端经验割裂的，而是在原来的基础上继续往上长。

最后

回头看我自己的路径，从早期业务页面，到阿里的直播互动平台和跨端容器，再到 XTransfer 的工程治理、多语言平台、浏览器插件和 AI Coding 实践，其实一直在做同一件事：

把具体问题抽象成系统，把人工流程沉淀成工具，把一次性交付变成可持续运转的能力。

AI 时代下，我觉得前端研发工程师的成长路径也会沿着这个方向继续展开。

不要只做页面的执行者，要做业务流程的建模者。

不要只做组件的使用者，要做工程系统的设计者。

不要只把 AI 当聊天工具，要把 AI 接进研发工作流。

不要急着逃离前端，而是以前端为起点，继续向平台工程、工程治理和 AI 应用工程延伸。

未来的前端，代码可能会写得更少，但要负责的问题会更大。

这条路不轻松，但比单纯担心“AI 会不会抢走工作”更值得投入。