大模型下B端前端代码辅助生成的思考与实践 ｜ 得物技术

背景

在B端前端开发中，开发者们总会遇到一个绕不开的痛点——重复劳动。大量CRUD页面的核心元素模块高度相似，但每次开发依然需要手动搭建，时间都花在了这些基础元素的堆砌上，直接拖累了业务需求的

。更麻烦的是，不同开发者的，等到了敏捷迭代阶段，接手别人代码时的学习成本往往高得离谱。

而AI大模型的持续进化，恰好为这个问题提供了一条新思路。如今的模型已经具备了基础的理解能力，能够完成

。像页面搭建这种通用场景，AI生成的指令完全能够满足日常需求，进而提升通用业务的开发效率。

生成链路一览

从整体流程来看，B端页面常见的列表、表单、详情等类型都支持代码生成。整个链路大致分为三步：

• 输入自然语言描述
• 借助大模型按指定规则提取出关键的搭建信息
• 将搭建信息与代码模板结合，通过AST操作输出最终的前端代码

表达需求

图形化配置

辅助代码生成的第一步，是告诉工具“你想要一个什么样的界面”。说到这，大多数人首先想到的是

——也就是目前主流的低代码产品形态。用户通过一系列图形化操作来完成页面搭建，比如拖拽组件、配置属性等。

这种模式对于通用场景（比如业务逻辑简单的CURD页面）或特定业务场景（比如会场搭建）确实能显著提效。但问题在于，它本质上是图形化的交互操作，对前端交互设计有较高要求，用户也需要一定的学习成本。随着需求复杂度不断攀升，配置表单的交互会越来越臃肿，维护成本随之水涨船高。所以，在实际的前端开发中，大家对页面配置的态度其实是比较

的。

AI直接生成代码

AI直接生成代码，在工具函数这类小型场景中应用得比较多。但如果要落地到公司内部的特定业务场景，有几个现实问题就不得不面对：

• 生成定制化：
  团队往往有自己的技术栈和重型通用组件。要让AI生成符合要求的代码，就需要把这些领域知识“喂”给模型。但受限于长文本预训练只能通过单次会话注入，token的消耗相当可观。

• 准确度：
  这是衡量辅助编码能力的核心指标。AI生成代码本身就有不小的准确度挑战，如果还要加上大段prompt进行预训练，输出中的细节越多，模型幻觉带来的失败率就越高。准确度解决不了，辅助编码的价值就会大打折扣。

• 内容截断：
  GPT单次会话有长度限制。对于复杂需求，生成代码有一定几率被截断，影响最终的成功率。

自然语言转指令

其实，GPT还有一个被很多人低估的能力——

。指令意味着行动。举个例子：假设我们定义一个函数方法，输入是自然语言，结合GPT与内置prompt，让它稳定输出几个特定的单词。那么，我们是不是就可以基于这些单词的输出去执行后续的操作？

相比

，这种方式有几个明显的：

1. 学习门槛低：
   自然语言是人类最原生的表达方式，你只用说出自己的想法即可。当然，描述时最好遵循一些约定规范，但这比起图形化配置的学习效率，提升是肉眼可见的。

2. 复杂度黑盒：
   图形化配置的复杂度是随页面一起增长的，而且这些复杂度会毫不遮掩地展现在用户面前。用户很容易迷失在满屏的配置项中，配置成本越滚越大。而自然语言的方式，把这种内在的复杂性屏蔽掉了。

3. 敏捷迭代：
   如果在产品端要新增一个页面配置功能，基于大模型的方式可能只需要调整几条prompt就能搞定。但图形化配置，则需要重新开发一套复杂的表单来支持输入。

这里大家可能会有一个疑问：

这个方案之所以可行，主要基于以下几点：

1. 从长文本中提取关键信息属于

   总结
   型任务，大模型在总结场景下的准确度远高于扩散型输出（比如直接生成完整代码）。
2. 指令信息只提取需求中的关键点，不需要预训练代码相关的技术栈。这样一来，prompt的优化空间非常大，通过持续迭代和完善prompt内容，可以显著提升输出的准确性。
3. 输出结果是可以验证的。对于不同表述的同一需求，我们可以通过单元测试来预测输出的准确性。一旦发现bad case，就将它纳入测试集，不断优化prompt，形成正向闭环。

对于代码辅助来说，基于用户的需求描述，经过prompt处理后，我们能拿到结构化的信息，为后续的代码生成奠定基础。

信息转化为代码

通过大模型拿到自然语言对应的可编码信息后，接下来就是将这些信息真正转化为代码。对于一个有明确业务场景的页面来说，代码生成通常包含两部分：主代码模板（比如列表、表单、详情框架）+ 业务组件。

转化流程

我们如何开发代码的？

这一步其实很像开发者日常写代码的流程。拿到需求后，我们会在脑海中提取关键信息（也就是前面提到的

），然后在IDE中创建一个文件，开始动手：

首先建立代码模板，然后根据场景引入对应的重型组件。比如列表场景引入ProTable，表单场景引入ProForm。接着在ProTable这类重型组件上添加属性，比如headerTitle、pageSize等列表相关配置。根据需求描述引入业务组件——比如识别到筛选项中包含“类目选择”，就会在useColumns中插入对应的业务组件；如果需求中提到“导入导出”，则在页面指定位置引入导入导出组件。拿到mock接口地址后，新增请求层，并在页面中引入。以上这些常见的代码插入场景，都可以封装进JSON中，然后通过代码模板结合AST插入或字符串模板替换的方式，生成最终代码。

源码生成

定位

源码辅助工具的定位，是帮助开发者减少重复工作、提升编码效率。它和低代码页面搭建属于完全不同的赛道。低代码重在特定场景下搭建完整的页面，其功能数量是可枚举的，业界也有不少优秀实践。而源码辅助工具的目标，是尽可能多地初始化业务需求代码，后续的修改和维护则完全交给用户，重点提升新增页面的开发效率。具体的功能架构可参照下图。

组件向量搜索与嵌入

对于前端开发而言，提效的本质是“少写代码”。更快的页面生成是其中一环，但良好的组件抽离同样至关重要。我们结合向量化技术对组件的引入链路进行了优化，无论是要初始化模板，还是操作存量代码，都能快速搜索并定位到需要的组件。

组件信息录入

支持快速获取组件的描述内容与引入范式，一键录入组件。组件描述会被转化为向量数据，存入向量数据库。

组件向量搜索

用户输入描述后，该描述会被转化为向量，基于余弦相似度与组件列表进行比对，找到相似度最高的TOP N组件。

组件快速插入

在存量代码中，用户可以通过自然语言描述快速搜索匹配度最高的组件，按下回车即可完成插入。

未来展望

• 组件嵌入模板：
  目前组件已支持向量搜索，后续可以通过结合源码页面生成，实现动态匹配组件并嵌入到模板中。

• 存量代码的编辑生成：
  当前仅支持新增页面的源码生成，未来会支持对存量页面进行局部代码的新增与编辑。

• 代码模板流水线：
  将AST的代码操作工具化，进一步打通自然语言与代码写入之间的链路，提升场景拓展的效率。