AI来了，前端工程师到底有没有危机

基于一次真实项目改造的真实思考

这周，我坐在椅子上喝咖啡，看着AI用两个小时写完了我需要两周才能写完的代码。我没有恐慌，我在思考一个问题：它能替代我吗？

这次我想分享这次一个挺有意思的前端架构改造——把传统的代码生成器从”生成代码”升级为”生成配置”。整个过程中，AI 写了大约 80% 的代码，我做了大约 20% 的决策和纠偏（可能我参与的还少，也只能按二八原则估算了）。

完成后我坐在椅子上想了很久：如果程序员的工作可以让 AI 完成 80%，那我们的价值到底在哪？

今天想把这次改造的经历复盘一下，单纯想聊聊一个更本质的问题——当 AI 变得越来越强，前端工程师应该怎么办？

先说背景：我要去做什么

现在做各种短平快的后台管理系统，RuoYi框架是个好的选择。这类系统的特点是：大量的 CRUD 页面，结构高度重复——搜索区、表格、分页、弹窗表单、增删改查按钮，翻来覆去就是这些东西。

传统做法是用代码生成器，根据数据库表结构自动生成 Vue 页面代码。问题也很明显：

• 生成即巅峰：一旦手动改了生成的代码，下次重新生成就覆盖了，自定义的东西全丢
• 不可维护：同样的逻辑散落在几十个页面里，改一个 bug 要改几十个文件
• 扩展困难：想加一个通用功能？在每个页面里都加一遍

之前也负责过低代码平台好多年，所以我一直在想怎么去解决下目前遇到的问题，不去把它做的太高大上，简单提升下，换换生成思路——不让生成器生成代码，而是生成”配置”，让一个统一的渲染引擎来负责所有的展示和交互。

这个想法其实在我脑子里已经很久了。看着团队成员面临库表调整，要么就是生成代码覆盖、要么就是去手动改好几个地方、每次改一个 bug或是调整类似的功能 要翻几个页面的时候，我都会冒出这个念头。但一直没有动手。

原因很现实：改动量太大了。 这不是改一个文件的事，要改代码生成器的模板、要写一套完整的渲染引擎、要重新设计配置结构、要确保所有几十个现有页面都能正常跑起来。光想想就头大，更何况做完之后还有海量的回归测试。一个人干的话，保守估计要一个月。

所以这次趁着机会我想先试试 AI——不是让它帮我写代码，而是先看看它能不能自己想到这个方案。如果 AI 能直接给出”配置驱动渲染”的思路，说明这个方向足够自然；如果它给不出来，那说明AI 暂时还替代不了。

结果是：AI 给不出来。

它反反复复就是那几套老路——在生成代码里插标记位、用继承覆盖、搞条件编译。每一条我都否了。插标记位太脆弱，继承覆盖耦合太深，条件编译根本不可维护。折腾了半天，我把自己的想法抛给它——“生成器只出默认配置文件始终覆盖，一次性生成自定义配置文件，合并统一渲染，预留查询、列表、表单、事件扩展位置…”，把之前建模平台的一些简单设计思路给它，AI 看完之后说：“这是一个非常好的设计。”

那一刻我就知道，它知道方向了，可以开干了。我也知道它暂时替代不了我了。

架构设计：一句话说清楚

整个方案提炼了配置生成页面的思想：

代码生成器输出配置文件（gen.config.ts），开发者写扩展配置（custom.config.ts），两者深度合并后交给 CrudRenderer 统一渲染。

代码生成器 → gen.config.ts (纯配置，可覆盖)
开发者     → custom.config.ts (纯配置，永不覆盖)
                    ↘ merge ↙
              CrudRenderer (统一渲染引擎，永不修改)

生成产物和手写扩展在物理文件上完全隔离，你可以随时重新生成，不用担心覆盖任何自定义代码。

确定方案之后，我的角色就是：我定方向，AI 出细节。 我说”要支持树表”，它延伸出”树编码字段、父级编码字段、默认展开”；我说”按钮要能条件显隐”，它设计出”预设动作 + handler + disabled/hidden 函数”。

技术实现：AI 写了什么

AI 一共生成了整套前端代码，包括：

• 类型系统（types.ts）：完整的 CrudConfig 类型定义，覆盖字段、列、按钮、钩子等所有配置项
• 配置合并引擎（mergeConfig.ts）：按 key 做深度合并，字段数组能智能追加
• 字段渲染组件：12 个，覆盖 input、select、date、upload、editor 等所有控件
• 数据加载层：字典加载、远程数据源加载、用户映射等 composable
• 主渲染引擎：CrudRenderer（单表）和 TreeCrudRenderer（树表）两个核心组件
• Velocity 模板：8 个后端模板文件，负责生成前端配置和 API 代码

代码量粗算一下，大概 2000 多行。AI 用了不到两个小时就全部完成了，从方案确认到代码可运行。

如果我自己做呢？我认真估了一下——光写这 2000 行代码至少要一周。再加上类型推敲、合并策略的边界处理、各种控件的 props 对齐、composable 的依赖管理，保守估计 10 到 15 个工作日。这还只是前端部分，还没算后面踩坑修复的时间。

但重点不在于速度，而在于质量。AI 生成的代码有完整的 TypeScript 类型、完善的注释、合理的分层。比我写的都规范。

我在干啥，我只是喝着咖啡，默默的看它在想、在输出…

踩坑：不完美，但会越来越好

AI 两小时交出的 2000 行代码，跑起来之后问题不少。

比如动态 import 的写法在 Vite 里跑不通、生成的骨架文件在 TypeScript 严格模式下报错、帮做重命名替换的时候漏掉了导致页面失败……零零散散修了七八个问题。

但这不是重点。重点是一个很有意思的现象：AI 的错误是有规律的，而且纠偏的速度越来越快。不光会自己总结反思，还会主动去查看其他文件是否有类似的错误

这让我想到一个类比：AI 像一个刚入职的聪明新人。他写代码很快，但不了解项目的坑——不知道 Vite 对动态 import 有限制，不知道 TS 空文件不算模块，不知道你团队的命名约定。但这些他学得很快。你纠正一次，他下次就不会再犯。

所以真正的工作模式是这样的：你负责判断对错，AI 负责快速执行。 你的角色从”写代码的人”变成了”带团队的人”——只不过你的团队里最勤奋的那个成员，是一个不会累、不会请假的 AI。

而这也恰恰说明：你得懂。 你不懂，就没法判断 AI 写的对不对，更没法纠正它的方向。

AI 带来了什么

认真想一下，AI 在这次改造中给我带来了什么？

第一，把”一直想做但没时间做”的事变成了现实。

这个想法在我脑子里转了很久，但改动量太大，一直拖着。AI 把一个人两周的工作压缩到了两个小时。不是效率提升了几倍，而是这件事从”不可能”变成了”可以今天下午就做”。

第二，它不会做架构决策。 这次改造最关键的一步——“生成配置而不是生成代码”——是我否掉了 AI 的三四个方案之后自己定下来的。AI 擅长在给定方向下快速填充细节，但它不擅长在多条路线之间做出取舍。它不知道你的项目有多复杂、团队有几个人、维护周期有多长，而这些恰恰是架构决策的核心输入。

第三，知识面的拓宽。

AI在完成工作的时候，会一直输出它的思路，解决BUG的时候，也会用拟人语气说我看看、我猜测、我试试…如果只看结果，不看它的过程，会漏掉很多有意思的点。遇到 import.meta.glob 这个问题时，AI 不仅给出了解决方案，还解释了 Vite 为什么无法分析纯动态 import。这种”问题 + 原理 + 方案”一体化的输出，本身就是一种高效学习。

但 AI 不是万能的

同样真实的是，AI 也有很多做不到的事：

它不懂数据库的具体业务逻辑。 我在配置里写”某字段只在编辑时显示、新增时隐藏”，这种业务规则 AI 不可能替我决定。

它不理解项目的历史包袱。 比如为什么我们的 API 命名用 list 而不是 getPage，为什么权限标识是 jgxt:stationinfo:add 这种格式——这些都是团队约定，AI 无法自行推断。

它无法判断优先级。 改造过程中有很多可以深挖的方向：性能优化、无障碍支持、动画交互……但什么该做、什么不该做、什么以后再做，只有了解业务全局的人才能判断。

最关键的——它不能替你负责任。 代码上了线，出了 bug，甲方要找的是你，不是 AI。

前端工程师的未来

回到开头的问题：AI 来了，前端工程师有没有危机？

我的答案是：有，但不是你想象的那种危机。

危机不在于”AI 会抢你的工作”，而在于**“会用 AI 的人会抢不会用 AI 的人的工作”**。

这次改造让我深刻体会到，未来的前端工程师需要的核心能力，正在发生根本性的变化：

从”写代码的能力”转向”设计系统、定义规则的能力”。

具体来说：

1. 架构设计能力：AI 能写实现，但不能做架构决策。你要能判断”这个项目该用配置驱动还是模板生成”、“扩展点该预留在哪里”、“生成产物和手写代码怎么隔离”。这次改造中，AI 一开始给出的方案全被我否了——不是它写得不好，是它不知道我项目里踩过哪些坑、维护过哪些烂摊子。

2. 系统设计能力：以前你可能只需要写好一个页面的增删改查，现在你要设计的是”一套规则，让所有页面都能自动跑起来”。CrudConfig 的类型定义、merge 策略、字段映射规则——这些东西写一次，管几十个页面。你的工作从”造零件”变成了”设计流水线”。

3. 问题诊断能力：AI 写的代码有 bug，你要能快速定位和修复。这不是”会调试”就行，而是要对整个技术栈有足够的理解深度。

4. 业务理解能力：把业务需求翻译成技术方案，这个过程 AI 做不好。因为它不了解你的用户、你的业务场景、你的历史包袱。

5. 审美和判断力：AI 生成的代码”能用”，但”好不好”需要人来判断。代码风格、用户体验、性能取舍——这些都没有标准答案。

6. 沟通和协作能力：和产品经理吵架、和后端同事对接口、和甲方解释为什么这个需求不合理——这些”软技能”反而变得更重要了。

最后一点感悟

这次改造做完之后，我最大的感受不是”AI 好厉害”，而是**“我终于有时间做更重要的事了”**。

以前大量的时间花在写重复的 CRUD 页面上，改一下字段名、调一下布局、对一下接口。这些工作价值有限但占时间。

现在这些工作 AI 都能做。我可以把精力放在更值得的事情上：设计更好的架构、定义更清晰的规则、建立更高效的开发流程。

AI 把前端工程师从”搬砖”里解放出来了。但前提是，你得先证明自己能”设计房子”。

AI 不是来取代你的，它是来解放你的。

前提是——你得学会用它。

就像计算器没有淘汰数学家，自动驾驶没有淘汰赛车手，AI 也不会淘汰真正懂技术、懂业务、能解决问题的前端工程师。

它会淘汰的，是那些只会复制粘贴、不愿意学习、拒绝改变的人。

而这跟 AI 无关，跟任何一次技术浪潮都无关。

但，说了这么多，但这套配置驱动的方案，AI能直接帮下一个人做吗？我今天积累的架构经验，AI明天会不会也学会了？欢迎评论区聊聊，你如果问相同的问题，它会不会直接给我这个答案。

📌 关注公众号《秋雨》，专注技术人成长与职场真实记录。