引言： 项目开发复杂度不会消失只会转移，期望解决越多问题平台就越复杂；功能越多，越灵活的低代码平台就越难用。
一、前言
1.1 背景与目标
长期以来，公司内部不管是业务侧还是管理层，有众多关于“低代码”的需求、想象以及探索。期望通过一次系统的调研，对这些信息进行归纳、汇总，形成文档资料，并达成以下两个目标：
- 统一大家对低代码平台、表单设计器的认识，明确它们的适用场景
- 确认表单设计器产品的定位、用户、使用场景，以及可能存在的问题
1.2 相关概念名词
- 低代码平台
低代码平台是一种快速开发技术，它允许开发者通过图形化界面拖拉拽的形式和少量编码来构建应用程序。
- 表单设计器
表单设计器是低代码平台中的一项核心功能，它允许用户通过图形化界面来创建和管理表单，而无需编写代码。类似的还有大屏设计器、表格设计器。
- 表单
包含有文本框、下拉菜单等表单元素的页面，泛指中后台系统中常见的CURD页面。
二、结论概述
2.1 关于表单设计器
目前对表单设计器的诉求有三种：①集成可视化设计能力到自己项目；②辅助设计；③辅助开发。
经实际的验证、分析，辅助设计和辅助开发的目标，在外包、软件定制开发领域不可行、价值不大。根本原因是：可视化操作成本高、应对定制化需求能力差。
2.2 关于低代码平台
低代码平台提供了一种有别于传统手动编码的应用交付方式。它的使用价值是：设计完成即开发完成，无需关注编码、服务器、部署等事务。
我们如果硬把它作为辅助编码的工具，纳入传统研发流程中，并不能完全体现和发挥它的价值。
三、使用场景分析
目前已知的对于表单设计器、低代码平台类的诉求或探索尝试。
3.1 开发人员集成表单设计能力到自己项目
需求描述
在自己的产品/项目中集成”表单设计“的能力，支持用户可视化的生成表单。表单数据保存后，在后续流程设计环节中能够被加载使用。
用户：业务侧开发人员
使用案例：
开发人员集成技术组件到自己项目，实现业务流程中“可视化表单”相关的需求。
调研结果
通过技术选型，vForm和amis都满足需求，业务侧基于这些三方插件，就能实现对应业务功能。可借鉴的开源项目有若依的工作流平台。
3.2 替代Axure作为设计人员的设计工具
需求描述
设计部门希望在平台中进行产品设计后直接就能生成代码，打通产品设计到生成代码的中间环节，实现设计完成即开发完成，或者完成80%的代码编写工作。平台包含/能够替代Axure原型设计的能力。
用户
- 设计人员：设计部门需要画原型的产品设计人员（不是UI设计人员）。
- 开发人员：前端开发人员
使用案例
-
设计人员：设计稿=》可视化编辑页面=》在线预览/演示
-
开发人员：导出代码=》微调=》运行调试=》打包发布
调研结果
结论是不可行，因为实现这样=平台的复杂度和难度严重超标。
目标的达成需要满足以下几个关键点：
-
设计功能满足设计人员可视化设计页面的需要
- vFrom能够满足基本可视化操作，但与Axure、墨刀、蓝湖等软件对标的话易用性不足，如果优化的话其中的复杂度和成本不言而喻。
- 实际投入使用，还需要大量的丰富完善可视化组件，并提供配套的组件管理、项目管理功能。
-
导出的代码能够满足开发人员二次开发的需要
- vForm生成的SFC(.vue)文件会丢失事件、数据源等逻辑，需要修改设计器源码实现，难度较高。
-
此外，还有一个有待解决的关键问题：当开发人员导出代码微调交付后，设计变更了，新导出的代码如何与已有代码融合同步？
PS：其实这是一个典型的D2C需求，详情参看章节四：Design to Code。
3.3 辅助开发人员提升编码效率
需求描述
开发人员拿到设计稿后，基于表单设计器平台可视化的设计页面，并导出代码，以降低前端开发人员还原设计稿的编码成本，提升表单类页面的研发效率。
用户：前端开发人员
使用案例：
-
编码的方式：设计稿=》查看标注=》手写代码=》运行调试=》查看标注=》手写代码=》运行调试
-
平台的方式（二次开发）：设计稿=》可视化编辑页面=》导出代码=》微调=》运行调试
-
平台的方式（零代码）：设计稿=》可视化编辑页面=》运行调试
调研结果
- 可视化拖拽的开发方式相较于手工编码并不快，低代码平台在提升编码效率方面价值不大 如果是开发人员拖拉拽的方式在平台中还原设计稿，整体投入的时间并不会显著提升，还改变既有的研发习惯。
- 设计器普遍存在操作难的问题，比如节点对不齐、配置不方便、批量操作难、特殊需求实现成本高
- 应对定制化的需求成本较高 如果出现平台已有组件不满足、需要大量自定义组件的情况，研发成本要高于直接编码的方式。
3.4 动态/复杂表单组件场景
有很多实际上是动态表单、表单组件的需求，会通过“表单设计器”的字眼沟通传递，实际上它们与表单设计器完全不相干。
比如xxx项目，沟通以表单设计器 开头，但经过深入沟通，他们实际上就是出于典型表单页面复用的考虑，需要抽象封装一些表单组件。
四、Design to Code
4.1 D2C介绍
Design to Code（简称D2C）是一种将设计稿（如UI设计图）自动转换为可维护的前端代码的技术或工具，旨在提高开发效率，降低设计师与开发人员之间的沟通成本。
- 打通从设计到开发的复杂过程，设计完成即开发完成
- 将 UI 还原的工作交给工具，开发人员更专注于实现业务逻辑。
4.2 调研结论
当下的结论是，在辅助编码方面，提供的价值还不大，需要持续关注。
原因是目前已试用的产品生成的代码，与我们实际需要的代码还有不小的差距。
关键问题有：
- 不符合公司研发规范
- 不能自动识别组件并输出组件化的代码
- 不能自动识别并匹配内部组件库
4.3 产品试用结果
| 产品名称 | 功能&特性 | 感受总结 |
|---|---|---|
| code.fun | 1. 支持Sketch、PSD、Figma等设计稿，生成vue、react、小程序等平台的代码。 2. 提供编辑器功能，允许手动分组、标记组件、切换布局方式等。 3. 支持AI智能处理和人工干预。 | 1. 目前只支持移动端项目，桌面PC端内测中；2. 支持组件化功能解决自动生成组件代码的问题 3.支持选取指定节点区域的生成代码【亮点】 |
| imgcook | 1. 由阿里巴巴开发，支持Sketch、PSD、静态图片等形式的视觉稿作为输入，生成可维护的前端代码。 2. 提供imgcook-cli、imgcook VS Code插件等工程效率工具。 3. 支持用户自定义DSL、自定义Plugin等。 | 对外开放使用大厂背书，较多已有的使用案例上传设计稿比code.fun便捷识别并生成组件代码功能存疑 |
| Semi Design | 提供设计稿转代码功能，支持一键识别Figma页面中的图层布局和Semi组件，转译为JSX和CSS代码。 支持多种代码风格输出，如React + Scss、React + Tailwind和JSON Schema。 允许设计师继续通过Figma原生方式使用变体，无需手动标注组件。 | 1. 限定Figma设计软件和Semi组件库，更适合Semi组件用户 |
| Zuoyan Lens | zuoyan lens是一个通过智能算法将设计稿转换为前端页面的产品（design to code），是低代码平台的一个分支方向， 他的输入是设计稿，产出是前端页面，中间无需值守即可自动完成。此项目可以一键将 Sketch、Photoshop 的设计稿转换为可维护的前端代码。100 个 page 的工作量 10 分钟内即可轻松搞定，极大释放前端生产力。 | 1. 提供了更广泛的平台支持和开放的AST转换能力2.仅支持移动端，PC端暂无适配 |
| Plasmic | — | — |
| 蓝湖 | 仅支持Vant组件库 | |
| DECO | 不支持组件库 | |
| scriptecho | 仅支持生成vue3；尝鲜9.9每月 | |
| 鲸鱼Code | 限定tailwindcss技术栈不支持自定义组件库最低49.9每月 |
五、总结
回答章节一调研目标中提到的问题
5.1 关于低代码平台
低代码平台的核心价值
低代码平台提供了一种有别于传统手动编码的应用交付方式。相对手动编码，它的提升和价值在于
- 学习成本低，非开发人员也能很快上手
- 设计完成即开发完成，相较于传统编码的方式，它无需关注编码、服务器、部署等事务
我们在原有的研发流程中 使用低代码平台，并不能发挥和体现它最核心的价值。
低代码平台的优劣势
优势：降低软件的开发、配置、部署成本
劣势：灵活性差，依赖平台的限制和规则，不适用于复杂的业务流程
低代码平台的适用场景
适用的场景：
- 适用于快速构建和测试新想法或概念验证的快速原型开发
- 适用于企业内部使用的管理工具，如人力资源管理
- 适用于没有UI设计稿，仅基于平台已有物料设计就能满足需求的项目
它们的共同的特征是定制化程度不高，基于平台已有的组件物料就能够完成应用开发。
不适用的场景：
- 业务流程复杂、定制化程度高的项目
- 辅助开发，提升研发效率
- 已有UI设计，来低代码平台还原UI设计稿的场景
5.2 关于表单设计器
使用场景
明确的两个需求都是需要在项目中集成可视化表单设计的能力，且业务场景都是工作流/流程管控。
产品定位
用户是业务侧开发人员，需要的产品形态是技术组件。
5.3 关于效能提升
基于业务侧实际需要，以研发流程为脉络、以效能提升为目标，成体系的规划提升方案。
