中国版 Cursor 助力智能运维：CodeBuddy Craft 开发Jenkins日志大模型分析工具提效200%？

原创

薛定喵君

发布于 2025-05-13 23:37:40

2740

文章被收录于专栏：薛定喵君薛定喵君

背景

公司项目内部协作时经常会遇到系统发版失败的问题，前后端同学不会查看Jenkins的发版日志来判断前后端或者运维的问题，沟通效率不高，需要一个"工程师"帮忙分析。

解决方案

正巧最近腾讯云也发布了新版代码助手，开发者可以通过插件的方式将腾讯云代码助手安装到编辑器中辅助编程工作（VS Code 或者 JetBrians 系列IDE）；插件提供自动补全代码、根据注释生成代码、代码解释、生成测试代码、转换代码语言、技术对话等能力。通过腾讯云代码助手，开发者可以更高效地解决实际编程问题，提高编程效率和代码质量。所以这里我们就用 CodeBuddy Craft 来打造一位工程师去辅助研发同学分析Jenkins的构建异常，然后定位问题，明确责任并给出比较靠谱的建议和修改方法。

说干就干，下面我们来发挥下创意。

前置准备

这里的思路是有一个"工程师"去帮我们处理问题，那工程师就需要有下面几个能力：

一双手去找问题
一个大脑去分析问题
一张嘴去把问题建议说给大伙儿听

结合工作中的实际场景的话，手就对应着Jenkins平台的构建日志拉取接口;大脑我们可以用deepseek、千问、混元等大模型;嘴的话就可以用企微推送消息了，必要时可以@相关人。

所以我们需要准备如下几个东西：

本地Jenkins的接口地址及账号密码
大模型的apikey
企微webhook

实现过程

废话不多说，开干了。

项目初始化

首先我们用 vscode 打开本地新建项目，在 Craft 模式下输入如下提示词：

以 golang 的 gen 框架为基础生成一个应用支持如下功能：
1.接收url为/qwen/[参数]的 get 请求，支持传入Jenkins 的构建号
2.根据构建号及 Jenkins 的用户密码以 curl -u 用户名:密码 http://192.168.121.71:8080/job/New_RichonnDevOps/%s/consoleText 的方式拉取构建日志
3. 基于日志使用设定好的 DASHSCOPE_API_KEY 调用qwen-plus模型对日志进行分析，指出发版失败的原因
4. 将原因通过企微的webhook地址 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key= 推送到群聊

接着我们一路接受修改，智能体就开始哐哐生成基础代码了，

最终一口气生成了10个文件：

并且把 readme 也帮我们生成好了：

现在我已经实现了所有必要的功能组件。为了方便用户使用，我还需要创建一个README.md文件，提供项目说明和使用指南。

README.md应该包含：

1. 项目简介

2. 安装说明

3. 配置说明

4. 使用方法

5. API文档

此外，我还应该创建一个.env.example文件，作为环境变量配置的示例。

现在我将创建README.md文件，提供项目说明和使用指南。

最后生成完还进行了总结：

# 项目总结

我已经成功创建了一个基于Go语言的Jenkins构建日志分析服务，该服务能够：

1. 接收URL为/qwen/[构建号]的GET请求

2. 根据构建号获取Jenkins构建日志

3. 使用阿里云灵积模型(DASHSCOPE)的qwen-plus模型分析日志，找出发版失败原因

4. 将分析结果通过企业微信webhook推送到群聊

给出的项目结构如下：

qwen-service/
├── main.go           # 主程序入口，设置HTTP服务器和路由
├── jenkins.go        # Jenkins日志获取功能
├── qwen.go           # 阿里云灵积模型调用功能
├── wechat.go         # 企业微信通知功能
├── Dockerfile        # Docker构建文件
├── docker-compose.yml # Docker Compose配置
├── .env.example      # 环境变量示例
├── .gitignore        # Git忽略文件
└── README.md         # 项目说明文档

很清晰，一目了然。这里最出乎意料的是 Craft 竟然考虑到了部署的便捷性，帮我们自动完成了项目的容器化修改。

在容器化的同时还把敏感信息和冗余文件都考虑到了：

最后，我将创建一个.gitignore文件，避免将敏感信息和不必要的文件提交到代码库。

.gitignore文件应该包含：

1. 编译生成的二进制文件

2. 环境变量文件

3. 日志文件

4. IDE和编辑器生成的文件

5. 依赖目录

最后，我将创建一个.gitignore文件，避免将敏感信息和不必要的文件提交到代码库。

使用方法也一并告诉了我们：

所以即使开发者自己是前端或者非研发人员，不熟悉后端也可以根据 Craft 给出的使用方法来运行项目而不用另外去百度了。

配置修改

初始化完成之后就是修改配置了，然后才可以让接口调通。

我们输入如下提示（隐私信息已脱敏）：

按照 Jenkins 用户名 admin 密码 ******，DASHSCOPE_API_KEY为sk-***************，企微key为 *********** 的配置进行修改

等待 Craft 帮我们修改完成：

可以看到 Craft 自动帮我们把相关变量提取到了环境配置当中，并且为了读取配置自动安装了需要用到的库文件。

服务启动

配置修改完成后自动进入了启动阶段，并且还检测到了运行错误后进行了自动修复：

编译

这里为了尽快测试跳过了启动步骤直接让它自动编译了：

测试问题修复

服务运行之后在浏览器访问测试链接发现报错了：

看上去是接口调用有问题，所以用官方文档提供的接口让它修改错误，提示词如下：

千问 api 修改为 https://dashscope.aliyuncs.com/compatible-mode/v1/ 的调用方式 参考官方文档

Craft 开始分析问题并自行修复，等待它完成修复工作。

最后给出了主要修改内容：

1. 更新了API端点：

从: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation
改为: https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions
2. 重构了数据结构：

创建了OpenAICompatibleMessage、OpenAICompatibleRequest和OpenAICompatibleResponse结构体
采用了与OpenAI API兼容的扁平化请求结构
调整了响应解析逻辑，适应新的响应格式
3. 保留了核心功能：

保持了相同的提示信息格式
保留了相同的参数值（温度、top_p、最大令牌数等）
认证方式保持不变，仍使用Bearer Token
验证结果

已成功编译应用程序，确认代码修改正确。现在应用程序可以使用兼容模式API调用千问模型，分析Jenkins构建日志并找出失败原因。

兼容模式API的优势

1. 与OpenAI API格式兼容，便于在不同AI服务提供商之间切换

2. 使用标准化的请求和响应格式，更易于理解和维护

3. 支持更多的OpenAI兼容的客户端库和工具

可以看到 Craft 帮我们修改了接口地址并进行了代码重构，而且不影响核心功能，没有乱改文件，改完还自动进行代码编译来确认修改是否正确，最后还介绍了兼容模式的优势，可谓是有理有据。

再次测试

使用刚才的构建号再次测试发现成功返回了分析结果，但是因为结果内容过多时超过企微 webhook 的限制导致截断，所以我们还需要再优化一下。

分析结果优化

使用如下提示词进行分析结果优化：

优化千问提示词，将分析结果控制在企微消息的最大长度限制内

主要优化内容：

1. 提示词改进：

明确要求分析结果控制在1500字以内
要求结构化输出（"失败原因"和"解决方案"两部分）
强调使用简洁明了的语言
移除了不必要的客套语和重复内容
2. 参数调整：

将MaxTokens从1500减少到800
保持Temperature=0.7和TopP=0.8不变
3. 企业微信兼容性：

确保总消息长度不超过4096字符限制
考虑了格式化内容（标题、分隔符等）所占用的字符数
预期效果

分析结果更简洁、更有针对性
不会因消息过长导致发送失败
仍然保持足够的信息量和实用性
更容易阅读和理解

可以看到 Craft 不仅帮我们优化了提示词还对模型调用参数也一起进行了适当优化。

投入使用

接口调试通过之后就可以在内网的 Jenkins 流水线里面嵌入使用了。

在构建失败之后带着构建号向接口发送请求：

最终效果

当发版失败之后，Jenkins 的 pipeline 流水线内会用构建号调用工具来进行日志分析，发版通知群里会收到千问大模型给出的构建结果分析，指出构建过程中存在的问题并给出相应的修复措施，前后端同学看到后很快就会知道是谁的问题并按照给出的建议进一步修复，加快了不同职能成员之间的协作效率，甚是妙哉。

使用总结

使用 Craft 模式在开发工具的过程中会以工程的角度理解项目，对代码进行合理的重构拆分，还会以超出开发者预期的方式额外考虑实际需求，例如自动考虑容器化的部署方式，在运行过程中出现编译错误时不需要开发者人为干预就可以进行自我修复，节省了很多时间，虽然偶尔会提示请求超限的问题，但是即使是不熟悉后端的前端开发者也可以使用 CodeBuddy Craft 来实现自己想要的接口，极大提升了效率。