链载Ai

标题: 基于AI的D2C前端代码生成技术深入总结 [打印本页]

作者: 链载Ai    时间: 3 小时前
标题: 基于AI的D2C前端代码生成技术深入总结


ingFang SC";font-weight: bold;color: rgb(58, 92, 244);line-height: 20px;visibility: visible;">


在AI技术日益渗透至各领域的背景下,本文深入探讨了B端(D2C)前端代码生成技术的核心挑战与实战解决方案,诚实地揭示了在实现自动化代码生成过程中遭遇的重重难关。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;visibility: visible !important;width: 113px !important;"/>
产品介绍

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;line-height: 1.75em;">背景

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);visibility: visible;line-height: 1.75em;">

●做为淘天内的AI创新团队,在团队内做了很多AI大模型的探索,了解到AI可以解决大量简单重复的事情,B端场景标准化程度比较高,不管是低代码还是源码开发,理论上都可提效;

●在基础平台也有非常多的B端页面研发,有天然的研发提效诉求,经过调研,预计每年可在团队内部节省非常客观的数据。


ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;line-height: 1.75em;">产品能力

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);visibility: visible;line-height: 1.75em;">

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);visibility: visible;line-height: 1.75em;">

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;visibility: visible;line-height: 1.75em;">落地业务

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);visibility: visible;line-height: 1.75em;">


在实际落地过程中遇到了非常多的问题,通过技术+产品的方式解决了很多问题,这里列举一些印象最深的分享给大家。


遇到的问题


一、prompt管理&测评成本大


问题描述:一开始在idealab上做模型和prompt的评测,但是因为需要大量的测试数据集(100+图片),经常改动一句话就需要重新测评所有的测试数据,导致测评的成本非常高,且不能打分,测评的效率也很低。



二、图片识别准确率过低


问题描述:我们定义了一套准确率的规则,主要是结构布局、组件类型、组件内容;一开始使用GPT4V,图片识别准确率只有50%,不到及格线。



三、某些图片内容识别准确率低


问题描述1:比如:表格详情label项,搜索表格里的搜表单项,表单页面的表单组件的每行个数,有时出现4个,有时5个,子组件的先后顺序都会识别错误。

问题描述2:如table的操作项,通常AI可能会把|或者空格认为是一个操作项,我们定义table的操作项用action表示,但经常会出现多一列叫"操作"的column,表单的标题的*号难以处理。


图一


图二


图三


解决方案一:

[{"height":15,"width":54,"word":"项目管理","x":0,"y":10},{"height":55,"width":15,"word":"新建项目","x":93,"y":-10},{"height":12,"width":13,"word":"2","x":401,"y":71}]


解决方案二:对JSON做预处理


四、上行prompt过长导致模型返回错误&出现幻觉


问题描述:当我们要识别更多组件和不同类型的页面时,我们发现在一套提示词里如果描述了太多的demo示例,导致上行Token过长,AI会产生幻觉;且一套提示词token会超长,导致调用时间变长,很多时候AI会直接返回错误,且调用成本也增加。


解决方案:通过页面类型来拆分出不同的提示词,从而减少prompt过长且出现幻觉的问题,页面类型背后主要还是通过AI+OCR来识别,准确率在95%以上,即使不能很好的识别页面类型,还可以通过通用prompt来兜底。


五、下行组件节点过多导致准确率下降

问题描述:模型返回的组件节点过多,会导致出错率增加准确率下降。


解决方案:实际在很多场景可能只需要对组件做一个标识,比如,是否包含图片,是否是链接,是否能复制,这种情况下识别的准确率会非常高。

六、定制场景差异大,生成内容无法复用

问题描述:实际在对接业务时,业务场景的差异都非常大,我们只能提供非常基础和通用的组件识别,且生成的代码都是通用的fusion和antd组件源码,无法满足业务诉求。


解决方案:我们把之前做的一整套AI能力抽象化和标准化,提供组件化的能力开放出来,让业务只需要定制个别组件,就能完成业务定制页面的识别和代码生成,这样业务定制一套D2C的成本降低80%

AI在D2C方向的总结

AI可提效的点

首先AI不是万能的,AI能通过图片生成的代码主要有(包括但不限于)以下:

    方案一:根据标题中文名称让AI自动生成规范的英文标识命名

    方案二:根据接口文档自动生成name,并自动关联接口和生成请求逻辑,辅助接口联调


AI不适用场景

也是目前我们还没有解决的点。


prompt规范&使用建议


结语


从prompt管理的繁琐与测评效率低下,到图片识别精度的瓶颈,再到定制场景的多样性难题,本文逐一分享了团队的应对策略与优化成果。这不仅是一次技术实践的深度剖析,也是对AI在D2C方向潜力与局限的客观总结,为前端开发者和AI研究者提供了宝贵的经验与启示。






欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5