从“页面切图仔”到 CLI 自动化：一次 H5 活动开发效率优化实践
在很多互联网产品中，H5 活动页几乎是不可避免的一类业务：节日活动、拉新活动、排行榜活动、抽奖活动、签到活动……这些页面往往周期短、上线频繁，而且视觉设计高度定制。
对于前端开发来说，这类需求有一个非常典型的特点：
每个活动看起来都不一样，但开发流程几乎完全一样。
于是我们经常会陷入一种循环：
新活动
↓
搭页面结构
↓
还原设计稿
↓
写业务逻辑
↓
上线
↓
下一个活动
在这样的业务背景下，开发效率就变得尤为重要。如果每次活动都从头搭建页面、写组件、处理 UI，那么开发成本会非常高。
在过去一段时间里，我尝试通过一系列工程优化手段，逐步改造自己的 H5 活动开发流程。从最初的古法纯手工编码，到 CLI 自动化，再到思考 UI 自动化和设计稿生成，这个过程让我对“工程效率优化”有了很多新的理解。
这篇文章记录的就是这次探索的完整过程。
一、背景：H5 活动开发的典型问题
在很多公司中，活动开发通常具有几个典型特点：
- 周期短：活动往往在一两周内完成开发并上线
- UI 高度定制：几乎每个活动的视觉设计都不同
- 上线频繁：每个月可能会有多个活动
- 重复开发多：虽然 UI 不一样，但开发流程非常相似
一个典型的活动开发流程通常是这样的：
活动策划出需求
↓
设计稿评审
↓
新建活动
↓
搭页面结构
↓
实现 UI
↓
编写业务逻辑
↓
调试与上线
表面上看，每个活动都不一样，但实际开发过程中会出现很多重复劳动，例如：
- 新建活动目录
- 创建页面组件
- 创建样式文件
- 创建 API 文件
- 创建弹窗组件
- 写基础布局结构
- 接入通用组件
这些工作虽然不复杂，但每次活动都要重复做一遍。
久而久之，我开始思考一个问题：
有没有办法减少这些重复开发？
二、第一阶段：CLI 自动化
我最先优化的，是项目初始化流程。
在没有自动化之前，每次新活动都需要手动修改、创建一系列文件，例如：
src/router/activities/index.js // h5活动的路由
src/api/index.js // 数据请求的文件
src/views/activities/spring2026 // spring2026活动所需要的结构
├ index.vue
├ index.less
├ components/
同时还要写一些基础代码，例如：
- 页面容器
- 通用布局
- 基础样式
- 类型定义
这些步骤虽然简单，但非常机械。
于是我开发了一个 活动开发 CLI 工具。
只需要在指定目录（src/views）下新建 .vue 文件：
mkdir src/views/activities/spring-2026
touch src/views/activities/newActivity/spring-2026.vue
CLI 就会自动生成完整的活动开发骨架：
src/views/activities/spring-2026
├ index.vue
├ index.less
├ api.ts
├ components/
├ types.ts
同时自动写入：
- 页面容器结构
- 基础样式
- 常用组件引用
- API 模板
- 类型定义
这样，原本需要复制和手动准备的工作，现在只需要几秒。
这个 CLI 工具大大减少了重复、机械且低价值的劳动，同时解决了在新活动开发时因为人工操作而出现低级错误的问题。
而在活动开发这种节奏很快的业务中，减少低级错误其实比单纯提升速度更重要。
三、第二阶段：组件复用探索
当 CLI 解决了大部分初始化问题后，我开始思考另一个问题：
能不能进一步减少 UI 开发的工作量？
最先想到的方案是：组件复用。
例如，活动页面中最常见的 UI 之一就是弹窗。几乎每个活动都会有：
- 规则弹窗
- 奖励弹窗
- 排行榜弹窗
- 任务弹窗
于是我尝试封装一个通用弹窗组件，例如：
<BasePopup
titleImg=""
:show="true"
closeBtn
@refresh=""
...
/>
统一了遮罩层样式、弹窗标题的位置、插槽等
我希望后续活动中的弹窗都尽量基于这个组件来实现。
四、现实问题：活动页面 UI 高度定制
然而很快我就发现，这种抽象方式并不理想。
因为活动弹窗通常是高度定制的，例如：
- 背景图不同
- 边框样式不同
- 标题结构不同
- 按钮位置不同
- 内容布局不同
为了适配这些差异，组件的 props 变得越来越多，例如：
titleImage
backgroundImage
showCloseButton
buttonLayout
contentType
组件内部也开始出现大量判断逻辑：
if(type === 'reward') ...
if(type === 'rule') ...
最终结果是：
- 组件越来越复杂
- 可读性越来越差
- 维护成本越来越高
这时我意识到一个问题：
为了适配多个活动而统一弹窗组件的收益其实并不大。
五、一个重要的工程经验：重复 ≠ 适合抽象
这次尝试让我意识到一个重要的工程原则：
不是所有重复代码都适合抽象。
抽象通常需要满足两个条件：
稳定
变化少
而活动 UI 的特点恰恰是：
视觉变化非常大
也就是说，虽然“弹窗”这个概念是重复的，但它的视觉结构和布局却经常变化。
因此，强行做统一组件往往会适得其反。
六、第三阶段：思考低代码方案
当组件复用的方案不理想时，我开始思考另一条路线：
低代码平台。
也就是通过 JSON 配置来生成页面，例如：
{
"type": "popup",
"title": "活动规则",
"content": "..."
}
这种方案在一些后台系统中非常常见。
但在实际分析后，我发现低代码也存在明显问题。
七、低代码的局限性
低代码通常适合：
展示型页面
例如：
- 表单页面
- 信息展示页面
- 管理后台页面
这些页面UI和业务逻辑相对更稳定，但活动页面往往包含大量定制的UI和负责特定玩法业务逻辑，例如：
- 接口请求
- 状态控制
- 倒计时
- 任务流程
- 奖励领取
- 条件判断
这些逻辑如果用 JSON 描述，会变得非常复杂，反而需要抽出精力来维护配置JSON Schema。
例如：
visibleIf:
status == "done" && userLevel > 3
随着逻辑增加，配置会越来越难维护。
因此我得出了一个结论：
低代码并不一定适合 H5 活动开发。
八、重新审视问题：真正重复的是什么？
在经历了组件抽象和低代码尝试之后，我重新审视了整个开发流程。
这时我才意识到一个关键问题：
我一直在优化“组件开发”，但真正耗时间的其实是“设计稿还原”。
例如：
- 搭页面布局
- 写 position 定位
- 下载图片资源上传oss
- 调整尺寸
- 处理滚动区域
这些工作通常：
机械
重复
耗时
于是我开始思考：
能不能从设计稿自动生成页面骨架？
九、设计稿自动化的探索
最直觉的方案是：
Figma 插件。
通过读取设计稿结构，自动生成代码。
但对于工具开发来说，一个很重要的判断标准是：
工具本身的复杂度不能超过要解决的问题。
- 插件开发成本高
- 需要设计师配合
- 设计稿结构必须规范
- 维护成本较高
对于活动开发这种快节奏来说，可能不是最合适的选择。
十、当前方案：工程自动化 + 半自动 UI
经过一系列尝试后，我最终形成了一套比较现实的开发流程：
CLI 自动生成活动骨架
↓
优先开发活动内高频使用的组件
↓
快速搭建 UI
↓
补充业务逻辑
通过这种方式，活动开发效率已经明显提升。
活动的开发周期已经从：7-10 天 → 5 天
十一、未来可能的优化方向
虽然现在的流程已经比较高效，但仍然有进一步优化的空间。
未来可以探索几个方向。
1. UI 骨架生成工具
设计稿 → 页面骨架代码。
例如：
- 自动生成布局结构
- 自动填充图片资源
- 自动生成定位样式
开发者再进行调整。
2. 活动视觉模板库
沉淀常见活动模式，例如：
- 规则弹窗模板
- 奖励弹窗模板
- 排行榜弹窗模板
- 任务弹窗模板
减少 UI 重复开发。
3. 设计稿辅助工具
而不是完全自动生成页面。
例如：
设计稿 → 代码草稿
开发者再进行修改。
十二、总结
这次工程优化让我学到一件非常重要的事情：
工程优化的关键不是技术，而是找到真正的重复劳动。
在 H5 活动开发中：最适合自动化的不是 UI 组件而是开发流程
通过：CLI + 模板 + 流程优化 就可以显著提升开发效率。
很多时候，我们在讨论工程化时，容易第一时间想到的是：
- 微前端
- 低代码平台
- 大型框架
但回过头来看，这次优化给我最大的启发其实很简单：
不是所有重复都值得抽象，不是所有问题都需要平台化解决。
很多时候，先把真正重复的流程自动化，就已经能带来非常明显的效率提升。
对于具体业务来说，最有效的工程优化往往来自一些很小的工具。
有时候： 一个简单的 CLI，可能比一个复杂的平台更有价值。
如果你也在做活动类业务，欢迎交流你们是怎么做提效的。
