“FDE 又不够了”这句话最近在我们团队群里出现的频率很高。如果你也在互联网公司待过大概率能会心一笑FDE 就是前端开发工程师Frontend Development Engineer的缩写。所谓“FDE 又不够了”翻译过来就是前端需求排不完、开发人力又紧张了。这不是某个团队的偶发现象而是很多前端团队的真实常态需求方永远在催排期永远在延能写前端的人永远不够。面对这种局面多数团队的第一反应是“再招一个前端”。但招聘周期长、培养成本高而且如果问题出在重复劳动太多、协作链路太长、发布流程太慢单纯加人也只是把问题往后推。本文将围绕“前端开发工程师不够用”这个痛点分享一套可落地的前端工程化提效方案。这套方案包含组件库建设、自动化代码生成、配置化页面搭建、CI/CD 流水线四个方向每块都会给出完整示例和落地建议。读完你可以照着在团队里逐步实施把有限的 FDE 资源从重复造轮子中释放出来。1. 为什么前端团队总在喊“FDE 又不够了”1.1 FDE 到底指什么在技术圈里FDE 常见的含义有两种一种是安全领域的 Full Disk Encryption全盘加密另一种则是互联网职场中常说的 Frontend Development Engineer也就是前端开发工程师。结合最近的热搜和团队讨论语境“FDE 又不够了”更多指的是前端开发人力的紧缺。大家用这种自嘲的方式表达一种普遍感受前端需求太多人手永远不够。如果从技术管理的视角看这句话背后真正值得讨论的问题不是“要不要加人”而是“现有的人为什么忙不过来”。1.2 真正的问题开发效率存在明显瓶颈仔细复盘一个前端团队的日常你会发现大量时间并没有花在“写页面”本身而是消耗在几个固定环节重复开发每个后台管理系统都在做表格、表单、弹窗、分页、筛选但每次都是从头写。联调成本高接口文档不清晰、字段频繁变化前端反复修改页面逻辑。构建发布繁琐手动构建、手动上传、手动通知测试一次发布动辄半小时。代码风格不统一每个人一套写法接手别人的代码需要大量时间阅读和踩坑。项目差异大不同项目的基础设施、目录结构、命令不一致切换项目成本很高。这些问题叠加在一起前端团队的实际交付能力会大打折扣。三个人可能只干出了两个人的活问题自然不是“人不够”而是“流程和基建没有把人力转化为生产力”。1.3 解决思路把“人力驱动”变成“工程驱动”面对“FDE 又不够了”的困境我比较推荐的做法不是盲目扩张而是先做一轮工程化提效。核心思路可以概括为组件化把高频页面元素沉淀成可复用组件减少重复开发。自动化用脚本生成重复代码把机械劳动交给机器。配置化让简单需求通过配置生成不占用开发资源。流水线化把构建、测试、发布接入 CI/CD减少人工干预。这四个方向并不需要一次性全部落地你可以根据团队痛点挑选最紧急的一项先做。下面我会依次展开每个方向的实训方法。2. 工程化前提统一项目基础与开发规范2.1 技术选型与版本约定在开始做组件库和脚本之前团队内部必须有一套统一的技术基线。否则即便写了组件换个项目也无法复用。本文示例以 Vue 3 Vite TypeScript 为主要技术栈这也是目前中后台系统比较常见的选择。需要注意的是不要照搬版本号实际版本要根据项目情况调整。以下命令演示的是创建一个 Vue 3 项目的基础操作npm create vitelatest fe-efficiency -- --template vue-ts cd fe-efficiency npm install npm run dev创建完成后的目录结构建议如下fe-efficiency/ ├── src/ │ ├── components/ # 全局公共组件 │ ├── views/ # 页面组件 │ ├── api/ # 接口请求 │ ├── utils/ # 工具函数 │ ├── router/ # 路由配置 │ └── main.ts # 入口文件 ├── scripts/ # Node 自动化脚本 ├── package.json └── vite.config.ts统一目录结构的意义在于任何前端成员进入项目后都能在五分钟内定位到对应的代码位置。这是团队协作的基础也是后续工程化工具能自动化生成代码的前提。2.2 使用 npm scripts 统一命令入口不同项目的本地启动、构建、检查命令如果不一致开发者在切换项目时会频繁出错。建议在 package.json 里将常用操作统一成固定脚本例如{ scripts: { dev: vite, build: vite build, preview: vite preview, lint: eslint . --ext .vue,.ts,.tsx, typecheck: vue-tsc --noEmit, gen:page: node scripts/generate-page.js } }这里的gen:page是我们后续要讲的自动化生成脚本入口。统一命令后新成员只需要记住npm run dev、npm run build等几个高频命令学习成本会明显下降。3. 第一件事搭建可复用的业务组件库3.1 为什么要封装业务组件很多团队已经引入了 Element Plus、Ant Design Vue 这样的基础组件库但页面开发速度依然不快。原因很简单基础组件解决的是“输入框、选择器、表格”这类通用展示问题而业务页面中有大量重复的模式比如“带搜索条件的表格页”“详情弹窗”“批量操作按钮组”。这些业务模式如果不沉淀成自己的业务组件每个页面都会重复写一遍请求、分页、状态管理逻辑。封装业务组件是投入产出比最高的提效手段之一。3.2 一个省人力的业务组件示例以最常见的“通用表格”为例传统写法是每个页面都复制一份 el-table 的骨架和分页逻辑。我们可以把它封装成一个CommonTable组件传入列配置和数据源即可渲染。文件路径src/components/CommonTable/index.vuetemplate div classcommon-table el-table :datadata v-bind$attrs v-loadingloading el-table-column v-forcol in columns :keycol.prop :propcol.prop :labelcol.label :widthcol.width :fixedcol.fixed / /el-table el-pagination v-ifshowPagination v-model:current-pagecurrentPage v-model:page-sizepageSize :totaltotal layouttotal, prev, pager, next current-changehandlePageChange / /div /template script setup langts import { ref, watch } from vue; interface Column { prop: string; label: string; width?: number | string; fixed?: left | right; } const props defineProps{ data: Recordstring, any[]; columns: Column[]; loading?: boolean; showPagination?: boolean; total?: number; }(); const emit defineEmits{ (e: page-change, page: number): void; }(); const currentPage ref(1); const pageSize ref(10); const handlePageChange (page: number) { emit(page-change, page); }; watch( () props.total, () { // 当数据总量变化时可以在这里做分页重置逻辑 } ); /script这个组件在页面中的使用方式template CommonTable :datauserList :columnscolumns :totaltotal :loadingloading page-changefetchUserList / /template script setup langts import { ref, onMounted } from vue; import CommonTable from /components/CommonTable/index.vue; const userList ref([]); const total ref(0); const loading ref(false); const columns [ { prop: id, label: 用户ID }, { prop: name, label: 用户名 }, { prop: email, label: 邮箱 }, { prop: createdAt, label: 创建时间 } ]; const fetchUserList async (page 1) { loading.value true; try { const res await fetch(/api/users?page${page}).then((r) r.json()); userList.value res.list; total.value res.total; } finally { loading.value false; } }; onMounted(() fetchUserList()); /script可以看到页面里不再出现分页相关的重复逻辑只需要关心表格列配置和数据请求。业务组件积累得越多新页面的开发速度就会越快。3.3 多项目复用考虑使用 monorepo 管理如果团队有多个前端项目组件只放在某个项目里其他项目仍然无法复用。这时可以考虑用 monorepo 方式把所有公共组件放在独立包中统一管理。使用 pnpm workspace 时在根目录新建pnpm-workspace.yamlpackages: - packages/*目录规划可以参考monorepo/ ├── packages/ │ ├── ui/ # 公共业务组件 │ ├── utils/ # 公共工具函数 │ └── request/ # 统一请求封装 ├── apps/ │ ├── admin/ # 后台管理项目 │ └── h5/ # H5 项目 └── pnpm-workspace.yaml这样组件升级后所有项目通过统一的版本管理同步更新避免出现“A 项目改了 B 项目没改”的维护困境。不过要注意monorepo 的迁移成本并不低建议团队项目少于五个时不要急于改造。4. 第二件事用 Node 脚本批量生成重复代码4.1 场景CRUD 页面为什么总是写不完后台管理系统的大部分页面都是同一个套路接口请求、列表展示、筛选条件、新增弹窗、编辑弹窗、删除确认、分页。如果每个页面都手写一遍消耗的时间非常可观。更现实的是这类页面逻辑高度相似完全可以由脚本根据模板生成基础代码开发者在生成结果上再按需修改。这样既保证了代码风格统一又大幅缩短了页面搭建时间。4.2 编写一个“页面生成器”脚本下面演示一个 Node 脚本它的功能是根据传入的页面名称自动生成一个标准页面的 Vue 文件。文件路径scripts/generate-page.jsconst fs require(fs); const path require(path); const pageName process.argv[2]; if (!pageName) { console.error(请传入页面名称例如npm run gen:page -- user-management); process.exit(1); } // 将 user-management 转换为 UserManagement const componentName pageName .split(-) .map((part) part.charAt(0).toUpperCase() part.slice(1)) .join(); const pageDir path.resolve(__dirname, ../src/views, pageName); const pageFile path.join(pageDir, index.vue); if (fs.existsSync(pageFile)) { console.error(页面已存在${pageFile}); process.exit(1); } const template template div class${pageName}-page header classpage-header h2${componentName} 管理/h2 /header section classpage-content !-- 搜索区域、表格区域都从这里开始 -- /section /div /template script setup langts import { ref, onMounted } from vue; const loading ref(false); const dataList refRecordstring, any[]([]); const total ref(0); const fetchList async (page 1) { loading.value true; try { // TODO: 替换为实际接口请求 const res await fetch(/api/${pageName}?page page).then((r) r.json()); dataList.value res.list || []; total.value res.total || 0; } finally { loading.value false; } }; onMounted(() { fetchList(); }); /script style scoped .${pageName}-page { padding: 16px; } .page-header { margin-bottom: 16px; } .page-content { background: #fff; border-radius: 8px; padding: 16px; } /style ; fs.mkdirSync(pageDir, { recursive: true }); fs.writeFileSync(pageFile, template, utf-8); console.log(页面生成成功${pageFile});执行命令npm run gen:page -- user-management生成后开发者只需要在模板基础上补充筛选条件和表单字段一个中规中矩的管理页面就完成了。这种脚本的价值不在于写得多么复杂而在于把“每次都要新建文件、复制基础结构”这种机械劳动彻底自动化。4.3 扩展思路接口文档驱动代码生成更进一步的做法是从接口文档自动生成请求函数和类型定义。比如团队使用 Swagger 或 Apifox可以导出接口 JSON再写脚本解析 JSON生成对应的api文件。这种玩法需要一定的脚本开发成本但一旦跑通新增接口时前端几乎不需要手动写请求代码FDE 可以集中精力处理交互和业务逻辑。值得注意的是自动生成的代码必须加上“请勿手动修改”的注释并且建议用 commit 钩子校验防止成员把改动直接提交到生成文件里导致后续重新生成时冲突。5. 第三件事配置化页面引擎让一部分需求“非开发化”5.1 思路从“写代码”到“写配置”后台管理系统中有相当一部分页面是表单加列表的组合。这类页面的字段虽然各不相同但交互模式高度相似。我们可以把这种页面抽象成一套配置规范让开发甚至产品同事通过写配置就能生成页面。这个思路就是低代码方案的核心。团队既可以直接购买现成的低代码平台也可以基于自身技术栈做一个轻量级的“表单渲染引擎”。对大多数团队来说不需要做一个完整平台只需要一个能根据 JSON 配置渲染表单的组件就足够。5.2 最小可用的 SchemaForm 组件下面实现一个简单的 SchemaForm它接收 schema 配置自动渲染出对应的表单控件。文件路径src/components/SchemaForm/index.vuetemplate el-form refformRef :modelformData :rulesrules label-width120px el-form-item v-foritem in schema :keyitem.prop :labelitem.label :propitem.prop el-input v-ifitem.type input v-modelformData[item.prop] :placeholderitem.placeholder / el-select v-else-ifitem.type select v-modelformData[item.prop] :placeholderitem.placeholder el-option v-foropt in item.options || [] :keyopt.value :labelopt.label :valueopt.value / /el-select /el-form-item /el-form /template script setup langts import { reactive } from vue; interface SchemaItem { prop: string; label: string; type: input | select; placeholder?: string; rules?: any[]; options?: { label: string; value: string | number }[]; } const props defineProps{ schema: SchemaItem[]; modelValue?: Recordstring, any; }(); const formData reactiveRecordstring, any({ ...Object.fromEntries( props.schema.map((item) [item.prop, props.modelValue?.[item.prop] ?? ]) ) }); /script页面中使用时只需要维护一份 schema 配置const userFormSchema [ { prop: name, label: 用户名, type: input, placeholder: 请输入用户名, rules: [{ required: true, message: 请输入用户名, trigger: blur }] }, { prop: role, label: 角色, type: select, options: [ { label: 管理员, value: admin }, { label: 普通用户, value: user } ] } ];当这种配置化组件在团队内普及后新增一个表单页面的工作量会从“半天”降低到“半小时”而且交互一致性会非常好。配置化引擎最大的好处是让简单需求不再消耗高级开发者的时间团队里相对基础的成员也能独立完成这类页面搭建。5.3 配置化的边界在哪里配置化不是万能的落地时要克制范围。我建议先只覆盖交互模式最稳定的表单和表格场景不要把复杂的跨页联动、复杂权限、复杂动画都塞进配置里。否则配置项会越来越复杂最终变成一门“新的编程语言”维护成本反而超过直接写代码。判断标准很简单如果一段配置需要写很多注释才能看懂那它已经过度设计了。配置是给简单场景用的复杂场景就该老老实实写页面代码。6. 第四件事把发布流程自动化降低协作成本6.1 前端 CI/CD 解决什么问题“FDE 又不够了”还有一个隐藏原因前端同学每天要花大量时间处理构建和发布。手动构建、手动上传服务器、手动刷新 CDN、手动告知测试这些环节每次都会打断开发节奏。接入 CI/CD 后代码推送触发自动构建、自动跑测试、自动部署到测试环境开发者只需要关注代码本身。这不仅是效率提升也能减少人为操作导致的发布事故。6.2 使用 GitHub Actions 实现自动构建部署以一个标准的前端项目为例在仓库根目录新建文件文件路径.github/workflows/build.ymlname: 前端构建与部署 on: push: branches: - master - release/* pull_request: branches: - master jobs: build: runs-on: ubuntu-latest steps: - name: 检出代码 uses: actions/checkoutv4 - name: 安装 Node.js uses: actions/setup-nodev4 with: node-version: 20 cache: npm - name: 安装依赖 run: npm ci - name: 代码检查 run: npm run lint - name: 类型检查 run: npm run typecheck - name: 执行构建 run: npm run build - name: 上传构建产物 uses: actions/upload-artifactv4 with: name: dist path: dist/上述流程实现了代码提交后的全自动检查与构建。如果你使用的是自有 GitLab也可以采用 GitLab CI 编写类似的 pipeline。关键点是一致的代码推到远端流水线自动完成规范和构建检查。6.3 测试环境自动部署构建完成后通常还需要把产物部署到测试服务器。这个环节依赖团队现有环境如果你已经在使用 Docker、Nginx 或对象存储可以在 Actions 中增加部署步骤。一个典型的部署任务可以是- name: 部署到测试服务 run: | scp -r dist/ useryour-server:/var/www/html/当然scp直接上传是比较粗暴的做法安全性也依赖 SSH 密钥配置。真实项目中更推荐使用 Docker 镜像推送加容器平台拉取的方式或者使用云厂商的对象存储同步工具。这里不做展开核心思想是让测试环境始终与最新代码同步减少“我明明改了你没更新”的扯皮。7. 落地过程中的常见问题与坑点工程化提效听起来很美好但落地时往往会有各种阻力。我把实践中最常踩的坑整理成了表格方便大家对照定位。问题现象常见原因解决思路组件库封装了但没人用组件文档缺失、参数设计混乱、稳定性差先服务一两个真实项目根据反馈迭代再推广到全组自动生成代码质量差模板设计过于简单生成的代码只是骨架在模板中沉淀团队最佳实践把重复逻辑封装到公共函数低代码配置难以维护配置项太多、嵌套过深、逻辑复杂限定配置化适用范围复杂场景坚决使用手写代码CI 构建经常失败依赖版本不锁定、缓存未配置、本地与 CI 环境不一致使用 package-lock.json配置依赖缓存统一 Node 版本发布流程自动化后没人关注失败告警没有通知机制接入钉钉/企微/邮件通知构建失败及时提醒负责人7.1 组件库推进中的典型阻力组件库不是写完就完真正的难点在于推广和持续维护。初期如果强制要求所有项目接组件库很容易遇到激烈反对。比较稳妥的做法是选择一两个新项目作为试点在真实需求中打磨组件的能力边界。当组件的稳定性和文档达到一定水平后再逐步扩大使用范围。7.2 自动化脚本的边界问题自动生成代码最容易被诟病的一点是“生成的代码我不熟悉还不如自己写”。这个问题的背后是模板质量太差。脚本的价值不在于“生成所有代码”而在于“生成 80% 的固定结构剩下 20% 留给开发补充关键逻辑”。如果模板里堆满了业务判断那就是把复杂问题做成了更复杂的配置得不偿失。7.3 低代码平台选择要不要引入外部产品不少团队会犹豫是自研轻量引擎还是直接用外部低代码平台我的建议是先盘一下需求规模。如果只是后台管理系统内部的几十个表单页面完全可以用自研 SchemaForm 解决学习成本低、技术可控。如果团队需要承载大量外部客户的页面搭建需求再考虑采购成熟低代码平台。不要为了“跟上潮流”引入一套过重的平台最后反而增加培训和维护成本。8. 最佳实践少招人的前提是工程基建可持续工程化提效不是一次性项目而是一个持续演进的过程。结合落地经验有几点建议值得每个前端团队参考。8.1 规范先行工具护航无论是组件库还是代码生成脚本都必须依托统一的编码规范。没有规范组件库会越改越乱自动生成的代码也会风格各异。建议把 ESLint、Prettier、Husky、commitlint 纳入项目基础配置让工具在代码提交前就把不规范的地方拦截下来。例如在 package.json 中增加提交校验npm install -D husky lint-staged npx husky-init然后在 package.json 中配置{ lint-staged: { *.{vue,ts,tsx,js}: [eslint --fix, prettier --write] } }这样开发者提交代码时暂存区的文件会自动被检查并修复格式保持统一的代码风格。8.2 小步迭代每次只解决一个痛点不要试图在一个季度内完成组件库、代码生成、低代码引擎、CI/CD 全套建设。工程化改造最怕摊子铺太大最后每个方向都浅尝辄止。更稳妥的推进方式是先统计团队一周内耗时最多的环节选最大的那个痛点切入。比如列表页开发最耗时那就先做 CommonTable发布流程最耗时那就先接 CI/CD。一件事落地并产生明显收益后再推进下一件事。这样团队能持续看到正反馈参与意愿也会更高。8.3 给公共代码配备负责人组件库、脚本、配置化引擎这类公共资源必须有明确的负责人或虚拟小组。否则初期推广顺利后期迭代乏力很快会重新变成“各自为战”。负责人不一定要全职投入但至少要承担以下职责合并组件 PR、维护使用文档、收集反馈、定期发布版本。公共工程越是多人使用越需要有人对它的长期健康负责。8.4 不要盲目追求“高级”很多团队一提工程化就想到微前端、Monorepo、低代码平台、AI 生成代码等热门概念。但对一个前端只有三五人的团队来说微前端和复杂 Monorepo 带来的维护成本可能超过收益。技术选型应该以“解决当前团队最痛的问题”为出发点而不是以“技术听起来够不够高级”为标准。先把手头的重复劳动消灭掉再把工具逐步完善。工程化的目标永远是人效而不是技术炫技。9. 总结与下一步回到“FDE 又不够了”这个问题我的感受是前端人力的紧张本质上反映了团队重复劳动过多、协作链路过长、基础设施薄弱。与其不断扩编团队不如先从工程化角度把效率提上来。本文分享的四件事——统一技术基线、建设业务组件库、用脚本生成重复页面、用配置化引擎承接简单表单需求——每一样都是从日常痛点出发的提效手段。你可以根据自己的团队情况选择切入点。哪怕只是先封装一个通用表格组件也能让下一个迭代的开发节奏明显变快。下一步建议你先花一周时间记录团队成员的耗时分布找到最痛的那个环节然后照着本文的思路设计一个小工具或一个小组件在真实项目里跑一遍。工程化的价值不是在 PPT 里而是在下一个版本的交付速度里。等你发现团队可以少加班、多交付时也许就会明白“FDE 不够”并不一定非要通过招人来解决。