背景
近期公司针对其它部门对AI Coding引入的提议,决定调研其可行性和落地效果。调研了通义千问、Deepseek两个AI coding模型,落地到项目的应用层工具分别是Vscode插件通义灵码和ROO CLINE。期望效果是:不敲一行代码完成需求。
通义灵码
其它部门引入的是通义灵码的企业版,听说效果很好。因为内网企业版网络打通不了,优先使用个人版来测试。直接支付宝扫码登录完成认证。
通义灵码-灵动指间,快码加编,你的智能编码助手
TONGYI Lingma-Your AI Coding Assistant. Type less, Code more.
通义灵码,是一款基于通义大模型的智能编码辅助工具,提供行级/函数级实时续写、自然语言生成代码、单元测试生成、代码注释生成、代码解释、研发智能问答、异常报错排查等能力,并针对阿里云 SDK/API 的使用场景调优,为开发者带来高效、流畅的编码体验。
- 兼容 Visual Studio Code、Visual Studio、JetBrains IDEs 等主流 IDE;
- 支持 Java、Python、Go、C/C++、C#、JavaScript、TypeScript、PHP、Ruby、Rust、Scala 等主流编程语言。
通义灵码除了面向个人开发者的提供了个人版之外,还提供了企业标准版、企业专属版,满足企业客户智能编码的诉求,可前往了解更多企业版信息。
因为智能问答对我的测试需求作用不大,主要使用AI程序员来测试。
构建新项目
构建空目录fit-mx,打开Vscode开始构建。组织语言话术,多次尝试发现无法在人工不参与的情况在从0生成项目。需要人工根据对话框的建议、指令操作来完成。测评来看是这个插件和Vscode契合度不够,严重影响大模型的使用效果。
已有项目基础上开发业务
既然从0开始不行,那就从一个空框架开始。手动构建一个ant design的空框架。
在未对接API的情况下,效果如下图,通义灵码针对设计图片有一定解析能力,不过识别后转代码效果一般,需不断组织语言调整。
企业版
紧接着切到企业版,通过上传知识库方式尝试模型优化,发现在生成代码上编码风格、规范上参考了知识库中模板项目。因为其它原因未在这个方向上持续构建知识库。
使用总结(片面)
在整体业务显示上确实提高了很大效率,避免了相似代码之间的Copy,但当生成到80%预期后,剩下的20%调优很难处理好。除过专业需求提问方式外,生成的效果也有一定折扣,很多细微场景无法实现。
因为TONGYI Lingma插件使用上人工介入程度比较大,这个插件设计中心放在辅助开发上,实现方式上和期望结果(不写一行代码)有差距,所以不在这个方向上继续尝试。有使用的比较好的jy可以给些建议,喷喷也行~
ROO CLINE
编程工具 Roo-Cline134
-
基本信息:Roo-Cline 是一款基于 Cline 的自主编码 Agent,是 Cursor 的开源替代工具,主要在软件开发领域为开发者提供帮助。
-
核心功能
- 自动审批功能:用户可设置自定义的.clinerules 指令,控制 Roo-Cline 自动处理命令、浏览器操作、文件写入等,减少人工干预。
- 兼容性强:支持 OpenRouter、OpenAI、Google Gemini 等主流 API 供应商,还可通过本地模型配置,能实时跟踪 API 使用情况和支出。
- 终端命令执行便捷:充分利用 VSCode 的最新集成,用户可在终端直接执行命令并接收输出,对于长时间运行的进程,有 “运行期间继续” 功能。
- 浏览器互动出色:能自主启动浏览器,进行点击元素、输入文本等页面操作,并可记录每一步,实现屏幕截图和控制台日志的捕获。
-
实验性功能
- 可拖拽图片进聊天:能将设计稿等图片拖入聊天窗口,据此生成代码。
- 可删除聊天信息:可清理冗长的聊天记录,保持聊天窗口整洁。
- 增强提示按钮:适用于 OpenRouter 模型,帮助优化提示语以获得更精准代码。
- 其他功能:有反馈音效、可调整浏览器设置、快捷复制历史提示、OpenRouter 压缩支持、系统提示包含当前时间、文件系统监控器、多语言支持等。
-
备注: 在使用上来看,实验性功能并没完全实现。
配置
Vscode集成插件并配置
构建新项目
构建空目录fit-mx,打开Vscode开始构建。提需求(使用Ant Design)生成项目框架,一键执行。ROO CLINE在经过个人允许后,操控Vscode的终端完成指令执行,异常问题多次检查并自动修复。
接入业务
提出需求逐步构建,如下步骤:
- 配置本地开发项目Proxy
- 生成登录页面及交互
- 生成拦截器相关Token业务
- 生成概览页面(因为不识别设计图,一个模块依次构建生成)
- 生成云主机列表、详情页面
- 生成退出功能
- 一键国际化整个项目
- 补充刷新Token机制
具体过程远远没有上述八步那么简单,每一步都进行了多次提问调优。当多次在宏观角度的调优无法满足需求时,就要人工介入,提出专业术语的调优意见,基础也能实现需求。
一些场景提问(仅供参考)
// 增加云主机关机、开机功能
云主机列表增加开机操作,接口为/xxx/v1/{projectid}/vmHost/{id}/power,method:POST,传参使用FormData默认传type:'start_up'
云主机列表增加关机操作,接口为/xxx/v1/{projectid}/vmHost/{id}/power,method:POST,传参使用FormData默认传type:'power_off'
接口url中projectid参数取Cookies中的projectid,id参数取操作行数据的id。操作都是高危操作增加交互
// 云主机列表增加搜索功能
云主机列表增加搜索功能,以searchKey字段名,keyword字段值组合形式增加名称搜索功能,传参拼在url后面,没有值时不传这两个参数
// 设置登录背景图
将D:\xxxx\portal_xxx\src\assets\newlogin\login.jpg图片放置到项目中替换成登录页面的背景页
// 概览增加云主机数量和状态模块
概览增加云主机数量和状态的Card模块,放置在告警统计右边。接口/xxxx/v1/dbproxy/getInstanceStatusStats,返回值:
{
"exception": "",
"data": [
{
"status": "ACTIVE",
"vm": 17,
"bm": 0
},
{
"status": "SHUTOFF",
"vm": 3,
"bm": 0
},
{
"status": "other",
"vm": 0,
"bm": 1
}
],
"localeMessage": "操作成功",
"message": "操作成功",
"userConfig": [],
"status": 10000
}
整体布局和设计
图标和数量:左侧有一个云主机的图标,直观地表示该模块的主题是云主机。旁边是云主机的总数 “20”,使用较大的字体突出显示,让用户一眼就能看到云主机的总量。
状态分类和数量:右侧通过不同颜色的圆点和文字分别展示了不同状态的云主机数量,“正在运行 17” 用绿色圆点表示,“关机 3” 用灰色圆点表示,“其他 0” 用橙色圆点表示。这种颜色区分的方式能够快速帮助用户识别不同状态的云主机数量分布情况。
前端实现要点
数据绑定:前端通过调用后端接口获取云主机的数量和状态数据,并将这些数据绑定到相应的 DOM 元素上进行展示。例如,总数 “20”、各状态的数量和文字描述都是通过数据绑定来动态更新的。
样式设计:使用了简洁明了的样式,包括合适的字体大小、颜色搭配和图标设计,以确保信息的清晰易读。颜色的选择(绿色、灰色、橙色)符合常见的状态表示习惯,增强了用户的理解。
// 全系统国际化
全系统国际化,并且在顶部导航增加国际化切换下拉框,支持英文和中文两种语言
// 提取工具函数
把项目中清理Cookies相关逻辑提到utils中作为工具函数,在业务中按需引入
// 调整概览云主机数量和状态样式
1. 概览云主机数量和状态Card中在不影响标题位置情况下让其它内容水平垂直居中
2. 让云主机数量和状态中图标与云主机总数那个区域完全分离,并且放置在那个区域左侧,同时放大图标
3. 继续调整图标、云主机总数、各个状态云主机数量显示区域间隔,保持间隔一致
// 调整告警统计样式
调整告警统计模块,下面列表状态、内容、时间放置到一行,内容部分溢出省略并使用浮框提示,内容部分尽可能占用空间
// 清理项目中调试日志
去除项目中多余的日志
执行
分析用户需求,分解成清晰执行逻辑
// 修改云主机列表分析
1. 用户反馈了一个新的需求:在云主机相关页面数据中去掉单位G,因为表头已经存在单位G。
2. 需要修改云主机详情页面,去掉内存和磁盘数据的单位G。
3. 从文件列表中可以看到云主机详情页面文件是src/pages/vmHost/detail/index.tsx。
4. 需要查看该文件内容,找到内存和磁盘数据的显示位置
// 修改云主机详情分析
1. 需要修改内存和磁盘数据的显示,去掉单位G。
2. 内存数据在line 152显示,当前格式为`${(detail.memory / 1024).toFixed(1)} GB`
3. 磁盘数据在line 153显示,当前格式为`${detail.disks} GB`
4. 需要去掉这两个字段的单位G。
5. 修改云主机详情页面文件。
执行过程会对执行文件逐行运行,找到合适的位置添加/修改/删除代码。在ROO CLINE对话记录中可以清晰看到执行日志及相关文件,在右侧代码区域可以清晰看到逐行执行动态及最终的变更代码。
存在问题
在使用测试过程中,虽然最终达到了预期(不写一行代码完成需求),但是期间出现的问题还是比较突兀。
- 根据api调用收费(和通义千问对比而言,不过收费相对低于其他大模型)
- 使用过程中存在卡顿、卡死问题(下午卡顿很明显)
- 上下文过程存在token长度超过最大限制,必须新建任务
- 在解决问题上偶尔存在Error A、Error B方案切换着改的问题,需人工审查、继续提问才会给出Success C方案
- 不具备浏览器错误日志自动分析能力,手动复制输入解决能力有有限
- 不具备图片分析能力(可以使用豆包把图片解析成前端工程师语言输入)
- 针对大任务的执行,如果你拆分成小任务执行,会出现上下文超出最大限制,上下文在新任务中丢失问题(eg:项目完成国际化),除过上下文丢失还存在某些文件执行了一半,出现编码异常的场景,解决起来相对就麻烦一些(eg:出现npm依赖包安装一半问题)。
- 偶现插件崩溃现象,需重启项目恢复
其中问题2最为严重,严重影响效率,问题7也很突兀,不过可以进行拆分成小任务规避。
实现效果
目前简单实现了登录、概览、云主机列表、详情、认证退出、国际化功能。
老项目应用
如果直接在现有项目基础上使用,使用准确性会进一步降低。只能以AI辅助编程方式去使用,存在问题如下:
- 现有项目中存在大量二次封装的组件,读取上下文后识别能力相对较低,无法在细节上正确使用
- 项目本身在演进过程中存在一些独有的编码规范和组织形式,AI无法在复杂分层中将逻辑串起来(无法识别整个项目将代码组织层级顺利串起来,eg: React项目中的service / modal / pages的调用链)
- 对于老项目应用来说,本身已经存在大量代码,检索识别上下文的速度将大大降低,对提问的方式和范围将要求更细致,否则将会浪费大量token,效率反而更差。其次检索到相似元素的概率会大大提高导致准确性相应降低。
如何在老项目中能使用好AI呢?那就要下放编码的权利,规矩是给人定的不是给AI定的,只要能达到效果,打破自己的强迫症尝试去接受AI的编码,质量和效率都会得到一定保证。当然很多企业会尝试训练适配的大模型,如何训练好,也将会应用的更好。
后记
计划继续在服务端、APP、小程序多端尝试,进一步深度使用。同时在同事口中出现,我们要失业的问题,这个问题在以前的观念中,觉得有些可笑,经过测评来看,某些业务场景上确实存在失业风险,起码效率提升很大。不过整体来看暂时失业不了,AI辅助开发并不是银弹,它现在更像一个有知识没想法的天才少年,你需要告诉它思路和方向,它才可以很好工作。需要人去持续点拨、引导,有时还是需要人亲自上手。地球还是需要我来修修补补,我是机器瓦力。