AI驱动研发效率在中后台的实践

            <dependency>                <groupId>io.springfoxgroupId>                <artifactId>springfox-swagger2artifactId>                <version>2.8.0version>            dependency>            <dependency>                <groupId>io.springfoxgroupId>                <artifactId>springfox-swagger-uiartifactId>                <version>2.8.0version>            dependency>            <dependency>                <groupId>com.github.xiaoymingroupId>                <artifactId>swagger-bootstrap-uiartifactId>                <version>1.9.6version>            dependency>

// 此处省略通用的一些编码要求......你是一个高级前端开发工程师，具有React组件和Hooks的深度开发经验熟练编写和集成自定义 hooks 与组件将用户提供的 React 组件代码与自定义 hooks 整合在一起。偏爱使用${component_lib}组件，如果必要或用户要求，可以使用其他第三方库。
....
## 注意事项确保整合代码的逻辑流畅和一致性理解用户的主要目标，包括如何整合组件和 Hooks，确保整合后的代码符合最佳实践。确保 Hooks 的方法名、引用路径以及类型定义的准确性和一致性。导入 hook, model 的目录路径应该是相对于当前文件的路径，并加上 `generate`。最终组件中使用的数据字段应该是根据请求返回的数据定义来的。
// 此处省略具体的内容规划，结构格式要求和执行路径......

以下是一些正确的答复示例：该示例展示如何组合用户输入的React组件，hooks，model 定义来渲染所需的UI import React, { useState } from 'react';
import {  Input,  Select,  Button,  Table,  Pagination,  Box,  Grid,} from '@alifd/next';用户输入的组件是一个列表查询组件， hooks是使用结合react-query, 使用post发送一个请求，获得列表查询的结果。 请求的参数是 hook类型定义`RequestConfig` 的泛型参数`ListUsingPostMutationRequest`, 请求返回的结果是 hook 类型定义的 `ReponseConfig`的泛型参数 `ListUsingPostMutationResponse`, 在`user-model`的定义中。 最终渲染的数据使用的是 `PageModelAnomalyRecourseVo`， `Table` 组件中的 `columns` 将使用 `PageModelAnomalyRecourseVo` 中的字段，在导出组件时，使用 `withMockService` 高阶函数包裹组件。我将使用type="react"的tsx代码块来处理这个用例。```tsx project="component" file="index.tsx" render="true" type="react"import React, { useState } from 'react';import { Input, Select, Button, Table, Pagination, Box, Grid } from '@alifd/next';import { useListUsingPost } from './generate/hooks/useListUsingPost';import type { AnomalyRecourseVo } from './generate/models/AnomalyRecourseVo';import { withMockService } from './generate/external';
interface ComponentProps {}
const Component: React.FC = () => {  const { m  const [currentPage, setCurrentPage] = useState(1);utateAsync: fetchList, data, isPending } = useListUsingPost();  const [currentPage, setCurrentPage] = useState(1);  const handleSearch = (field: string, value: string) => {    setSearchParams({ ...searchParams, [field]: value });  };  //省略代码	。。。。  return (  //省略代码	。。。。  data?.dataSource || []} columns={columns} />      20, 0]} direction="row" align="center" justify="space-between">                  total={data?.total || 0}          current={currentPage}          pageSize={pageSize}          onChange={(page) => setCurrentPage(page)}        />        )};
export default withMockService(Component);```

最后是给AI出码的用户输入，这里的输入{component},{hook},{model}等就是前面生成的代码，通过ideaLAB的开放服务作为参数输入给模型进行推理
<doc_string>现在用户的输入如下，请将 React 组件代码与自定义 hooks 整合在一起doc_string><user_input><user-component>${component}user-component><user-hooks>${hook}user-hooks><user-model>${model}user-model>user_input>

2. 拟合总结

整体代码拟合的效果准确率对比前两个阶段，稳定性相对弱一点，当然也分情况：如果是私有化的组件（如团队内部的组件库）由于输入的使用信息更为完善，不容易产生幻觉。外部的组件则相反，由于大量的训练语料都是公域的信息，比如“responseData?.data?.dataSource” 经常会产生一些幻觉。

当然也有对应的解决方案，就是不断的在prompt中去完善规则，或者给一些bad example，整体来说先阶段仍然需要对promp进行一个长期的优化，也是我们在整个项目中最耗时的一个阶段。
目前我们在业务封装的一些高级场景组件中，拟合的稳定性和准确率大约能达到95%的水平（一线开发者仅需要做少量的修改），对于公有组件（Fuson,AntD等）大概是在80%左右的水平。

Code Review

1. 外部产品

用AI进行Code review其实已经是一个比较成熟的操作，在外部也有很多类似的研发工具产品：
比如gitlab极狐公司推出的CodeRider（https://gitlab.cn/resources/articles/ability_tag/28）
Codium AI公司推出的PR-Agent（https://github.com/qodo-ai/pr-agenthttps://www.qodo.ai/）
这类的商业化企业开发服务工具除了code review以外提供从代码管理到CI/CD的完整解决方案


但是以上的这些外部平台存在以下这些问题：
基本都需要外部的账号登录，比如google账号，github账号，同时也涉及到账号的充值付费
大部分产品的工作流都是依附在Github上的，和其他代码平台的兼容性不够好
数据安全性问题无法完成保障
基于以上的问题和我们考虑自己动手设计一个ai codereview agent或者采用集团内部的其他方案。

2. codereview AI Agent实现

由于大部分的前端场景对于逻辑的处理没有特别的复杂场景，更多是对代码风格，模型在简单的逻辑问题、命名拼写错误等，框架的调用的最佳实践等一些不涉及到文件之间上下文业务逻辑的场景，所以自动动手实现一个AI codereview工具的成本并不高，主要步骤：
1. 在merge request提交的时候触发webhooks
2. 通过code open api获取对应的code changes 
3. 通过prompt引导AI对代码进行审查 
4. 给出的优化建议以评论形式提交在mr上

具体的实现设计可以参考一下以下流程图：

prompt
你将扮演一名资深软件工程师，对同事的代码进行评审。
针对每个文件，判断是否需要提供反馈。若需要，用1-2句话说明反馈内容。若需修改代码，需注明原始代码并提出修改建议。建议后不要添加其他内容。若无反馈，则不对该文件添加评论。
最后，用1-2句话总结整体反馈。
### filename.jsThe name of this variable is unclear.
Original:```jsconst x = getAllUsers();```
Suggestion:```jsconst allUsers = getAllUsers();```//...省略其他example

可以参考的代码规范包括：
https://github.com/microsoft/TypeScript/wiki/Coding-guidelines
https://github.com/airbnb/javascript

以下是一个：

在我们的实际测试使用效果中，AI code review和传统的静态代码扫描缺陷可以形成互补，能更好的发现一些人为的粗心导致的代码实现不够严谨的问题。
但是发现 AI 代码评审存在两大现象：
绝大部分的代码都没有代码缺陷，而这时候大模型总是倾向于编造一些问题来提示我们注意。
由于业务背景、需求文档、技术方案、上下游系统依赖、俗成的约定等信息的缺失，导致人类能判断的代码缺陷而 AI 却找不出来。

3. code平台AI评审助手

除了自己实现以外，目前一些主流的代码托管平台像github也提供了类似的功能，代码托管平台最大的特色在于基于高质量的现有CodeReview数据集对模型进行了微调。

为了在特定领域内提升大模型的表现，微调是很关键的一个步骤，这个步骤依赖于该领域内的高质量数据。相比优质代码数据，CodeReview 的高质量数据更难获取，因为它不仅包含代码数据，还涉及众多的自然语言数据。这些数据通常结构松散，含有二义性，而且缺乏有效的解析工具。其中代码数据多以 unified diff 格式呈现，增加了解析的复杂度。

▐  自动化测试回归

传统自动化测试模式基于脚本驱动，依赖预定义脚本（Python/Java）需人工维护元素定位器。如：“driver.find_element(By.ID, "submit-btn").click()）”，通过DOM结构或控件ID定位元素。一旦UI发生变更可能会导致60%以上的用例失效。基于像素对比（如Applitools）的方案受分辨率/动态内容影响大，另外还要考虑到平均用例的维护成本。

在大模型时代，是否存在面向测试场景的更智能的方案呢？OmniParser V2 （https://github.com/microsoft/OmniParser）是微软推出的下一代视觉解析框架，专为智能UI自动化测试设计。它通过融合 YOLO目标检测 和 Florence-2语义理解模型，实现屏幕元素的精准识别与功能解析。将用户界面的像素空间“分词化”，将其转化为结构化的、可被大语言模型理解的元素。自动标注按钮、输入框等交互控件的位置坐标（±1px精度）和语义描述（支持中英文），并集成 GPT-4o 等大模型生成自动化脚本。

这个产品之前更多被用户数据爬虫的场景，实际可以发挥的场景远不止这个领域，由于是通过视觉模拟的方案，打通了人机的交互形式。理论上可以做一切对电脑进行操作的场景。

基于这样的能力来设计一条自动化测试回归的流程，大致分为如下这个部分：
举一个具体的例子，以clone一个github的某个仓库为例：
通过自然语言描述需求（目前一些比较先进的reasoning模型也可以自己来拆解步骤）：
打开Chrome浏览器
在地址栏输入github.com跳转到github
在搜索栏搜索XXX项目
 跳转到XXX项目后点击code->clone仓库到本地
由于每一步基本都是类似的循环，这里只取其中一步来介绍一下具体的流程：在打开页面后通过OmniParser V2获取完整的页面结构化信息（红框里面的部分），包含了每个元素的类型，是按键，文本还是icon。和具体的坐标信息。


把这个页面的所有信息作为下一步的输入，并且告诉大模型下一步要做什么。

大模型是会根据页面信息，给出可能的操作步骤和推荐的建议。

最后大模型还会输出具体的操作代码：
定位目标元素：
# 筛选可交互且包含"Code"关键字的图标target_icons = [icon for icon in icons if                 icon['interactivity'] and                 'code' in icon['content'].lower()]
坐标转换（以图标75为例）：
# 获取屏幕分辨率（示例为1920x1080）screen_width, screen_height = 1920, 1080bbox = icon75['bbox']  # [x1, y1, x2, y2]
# 计算点击中心坐标center_x = (bbox[0] + bbox[2])/2 * screen_widthcenter_y = (bbox[1] + bbox[3])/2 * screen_height
执行点击：
import pyautoguipyautogui.click(center_x, center_y)  # 点击代码按钮pyautogui.click(center_x, center_y + 80)  # 选择"Download ZIP"选项

以上就是每一步的一个循环，当页面结构发生变化的时候，再次通过OmniParser V2分析新的页面结构和元素，再进行推理，这个过程和真实的人类去操作和理解页面的变化是类似的。有没有汽车自动驾驶领域现在很火热的 “端到端”技术架构的感觉？

除了OmniParser+pyautogui以外，类似的方案还有 browser-use（https://github.com/browser-use/browser-use），从视觉模型的理解和结构化能力来说，OmniParser在发布V2版本以后已经领先于同类型的产品。另外背后有mircosoft站台，未来前景也更加优秀。

我们在自动化测试回归领域还仅限于流程和理论上的探索验证，主要是OmniParser目前几乎不支持中文的识别，但是相信不久的将来，未来的自动化测试模式也会随着AI模型能力的提升更大幅度的提升效率。

▐ 产品化工具

在品牌行业前端内部，我们把上述的能力统一沉淀在了我们自己研发的一个VS Code插件上。根据我们的业务场景进行了深度的定制，包括支持C端通过mgdone的图层结构解析生成代码，和B端不同私有组件库的模式。同时也集成了接口/数据模型的代码生成，并支持一键进行代码拟合。

在出码之后也支持类似Copilot/Cline/Continue等插件的chat模式，在能力上进行了定制和增强，包括根据已经出码的上下文，持续进行代码优化和调整，使用体验比起Cline更加稳定可控。

整体的工作流程图：

用户使用流程：

一些总结和未来展望 

在1月份的下旬开始，我们在品牌行业家享服务和物流的中后台场景全量开始推广使用新的研发模式：在新增的页面开发需求场景中，中后台场景下D2C带来UI编写的效率提升40%，联调效率提升30%，AI代码的采纳率B端场景约在 40%，AI代码覆盖率75%以上。

▐ 大模型技术能力的迭代

上层产品能力的演进最大的驱动力还是基础模型技术的迭代升级
前端AI驱动编码对于大模型的基础能力主要依赖包括：
多模态识别：对交互/视觉设计稿的识别，能正确进行组件的模态识别，尤其是对于弹窗等特殊浮层能理解交互设计的含义。
上下文理解力：在配合代码仓库索引的情况下，对代码上下文有足够的理解力，能读懂代码，在变更的时候准备的进行修改，
推理效率：在进行代码推理生成的响应速度要足够快（目前Cursor采用的仍是定制小参数模型的方案来确保响应速度）。
成本：每次代码生成/修改都会消耗大量的token，如果每次任务执行产生的费用过高，在实际的日常应用中也很难普及。

换句话说，大模型在这4个维度的能力越强，AI编码的效果就会越好。目前随着qwen2.5VL,Deepseek R1等优秀的国产大模型崛起，在模型的上有了越来越多可选项，但是能够在这几个方向上做到都十分优秀的还是寥寥无几，所以尽管现阶段AI的能上进步迅猛，但仍旧是辅助流程的工具，还是需要人来做主导。

▐ AI友好架构设计

将来越来越多的代码会是由AI来编写，在技术架构设计和代码实现的时候，需要越来越多考虑到AI的理解成本。

以前端的业务组件为例：
明确的数据流与接口规范：确保组件状态管理路径清晰，降低AI理解逻辑的复杂度。组件间通信需通过标准化props/events接口，避免隐式依赖。AI 代理在处理代码时，如果能够借助强类型信息理解数据的结构和约束，就能更精准地实现功能，而不需要依赖隐式规则推导。
基于"单一职责原则"构建组件层级：基础UI组件保持功能原子化（如按钮、输入框），业务组件通过组合基础组件实现功能。这种分层结构便于AI识别组件复用场景，做到“代码即文档”
低耦合高内聚实现：采用容器-展示组件模式分离业务逻辑与视图层。组件应具备完整的自描述元数据（如PropTypes），方便AI解析功能边界。组件内部的过度会复用导入导出会增加代码的耦合性，使 AI 更难理解依赖关系。

▐ 未来应用层的发展方向

在面向未来的AI的应用层面，一定是对于整个流程链路的重构，比如：原来有 5 个步骤，目前现在我们做的都是在每个步骤上进行提效，仍处于在单点节点上的优化，而把 5 个步骤通过 AI 提效砍掉 2 个，并且形成新的产品形态或研发范式，才是真正通过AI的能力去解放生产力。

未来的产品研发形态随着模型能力的提升 研发流程过程中真正需要编码的过程会越来少，那么是否还需要把代码Clone到本地，是否需要本地的编译器？

我认为面向不久的未来对于部分的产品需求可能会只需要使用云端工具，面向PRD/MRD/业务需求，通过构建一套由多个专业智能体（Agent）组成的研发助手网络，覆盖从需求分析到代码生成、质量保障的全流程。智能体网络将实现自主决策和协作调用，各智能体根据需求上下文和开发阶段，主动调用相关工具并协同完成代码生产。

AI Agent:接受需求 ==> 编辑代码 ==> 运行效果 ==> 修改&review ==> 提交代码 ==> 完成发布，其实Cursor/Cline等辅助工具目前通过MCP协议，已经在在理论上已经等完成上述的流程。

但我不认为未来会减少对于高级研发的岗位的需求，未来的软件研发的需求会持续膨胀，数字化和数智化会更快更广的普惠到各行各业。

团队介绍

本文作者 珈文，来自淘天集团的天猫品牌行业前端团队。我们团队负责消费电子、3C数码、运动、家装、汽车、奢品、服务等多个行业的项目。我们定位自身不局限于“传统”的前端团队，在AI、3D、工程化、中后台等领域，我们有着持续的探索和实践。




¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术
服务端技术 | 技术质量 | 数据算法



预览时标签不可点

          

    

    
                  

      
            
            
          
  
  

        

      

        
        

      
    

      

        

          
          
微信扫一扫
关注该公众号
        
      
    

  

    
  继续滑动看下一个
  

  

  

    
    

              轻触阅读原文
          
    

      

        

          

            

              

                

                  

                    
                                          
                                        
                  
                  

                    

                      

                        大淘宝技术                      
                    
                  
                
              
            
          
        

        

          

                                                          
        
      
      

    
  
  

    

      

        
        向上滑动看下一个
      
    
  

  

    

    
  

  

  

    

    

      知道了
    
  

  

      

          
          微信扫一扫
使用小程序
      
  

  

  

      

          
      
      

      
      

          取消
          允许
      
  

  

  

    

      
    
    

    
    

      取消
      允许
    
  

  ×
  分析

  

  

    

      
      

        
                

          
        
              
    
    

      
微信扫一扫可打开此内容，
使用完整服务
    
  

    

      

    
    

  
：，，，，，，，，，，，，。 视频小程序赞，轻点两下取消赞在看，轻点两下取消在看分享留言收藏听过