用 MCP 把 Jenkins 变成 AI 队友：一次对话完成自动化发布
关键词：MCP、Jenkins、Claude Code、自动化部署、DevOps
一、背景
日常开发中，发布流程通常是这样的：
- 切到要发布的分支
- 打开 Jenkins 找到对应 Job
- 点「Build with Parameters」
- 手动填分支名、选环境、确认 appid...
- 点构建，然后切回浏览器等结果
这套流程有几个痛点：
- 重复劳动：每次都要手动填参数，分支名还容易拼错
- 上下文切换：从 IDE 切到浏览器，思路被打断
- 容易误操作：选错环境、选错 appid、忘记切分支
- 参数记不住：不同 Job 的参数名、可选值不一样，全靠肌肉记忆
既然我们已经在用 Claude Code（AI 编程助手），能不能让它直接帮我们发版？
答案是：用 MCP 把 Jenkins 接入 AI 助手，再通过一个 SKILL 把发布流程固化下来。
二、什么是 MCP
MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 AI 助手能够通过标准化的方式连接外部工具和数据源。你可以把它理解为「AI 世界的 USB-C 接口」------只要有对应的 MCP Server，AI 就能使用那个工具。
对于 Jenkins，社区已经有现成的 MCP Server：@kud/mcp-jenkins，它封装了 Jenkins 的 REST API，暴露成一组 MCP 工具供 AI 调用。
三、配置 Jenkins MCP
在项目根目录的 .mcp.json 中添加 Jenkins MCP Server：
json
{
"mcpServers": {
"jenkins": {
"command": "npx",
"args": ["--yes", "@kud/mcp-jenkins@latest"],
"env": {
"MCP_JENKINS_URL": "http://jenkins.internal.example.com/",
"MCP_JENKINS_USER": "dev",
"MCP_JENKINS_API_TOKEN": "your-api-token-here"
}
}
}
}三个环境变量：
| 变量 | 说明 |
|---|---|
MCP_JENKINS_URL |
Jenkins 地址（内网域名） |
MCP_JENKINS_USER |
Jenkins 用户名 |
MCP_JENKINS_API_TOKEN |
API Token，获取方式见下方 |
API Token 获取方式：登录 Jenkins → 右上角头像 → Security（或 Configure）→ API Token → Add new Token，生成后复制保存（Token 只显示一次，离开页面后无法再次查看）。
配置完重启 Claude Code，MCP 工具就自动加载了。可用的工具包括：
jenkins_list_jobs--- 列出所有 Jobjenkins_get_job_parameters--- 获取 Job 参数定义jenkins_trigger_build--- 触发构建jenkins_get_build_status--- 查询构建状态jenkins_get_console_log--- 获取构建日志- 等等
权限最小化原则
建议为 AI 发布创建一个专用的 Jenkins 账号，只授予**「只读 + 触发构建」**权限：
| 操作 | 权限 |
|---|---|
| 查看 Jobs / 构建历史 / 日志 | ✅ |
| 获取 CSRF crumb | ✅ |
| 触发构建 | ✅ |
| 读取 / 修改 Job config.xml | ❌ |
| 创建 / 删除 Job | ❌ |
| 系统管理 | ❌ |
这样即使 Token 泄露，影响范围也仅限于触发构建，不会破坏 Jenkins 配置。
四、用 SKILL 固化发布流程
光有 MCP 工具还不够------AI 需要知道「发布」这件事的完整流程：怎么选 Job、怎么确定分支、参数怎么填、什么时候需要人工确认。
我们通过一个自定义 SKILL 把这些经验固化下来。
SKILL 是什么
在 Claude Code 中，SKILL 是一份可复用的任务流程文档。当用户说「发布」「部署」时，AI 会自动加载对应的 SKILL，按文档里定义的步骤执行。
整体流程
arduino
用户说"发布"
│
▼
① 确定 app_branch（用户指定 > git 当前分支）
│
▼
② 根据分支前缀路由 Job
│
▼
③ 调 API 拉取 Job 实时参数定义（不硬编码）
│
▼
④ 合并参数值（用户指定 > Job 默认值 > 留空）
│
▼
⑤ 展示发布摘要表格，等待用户确认（强制）
│
▼
⑥ 触发构建，输出队列 ID / 构建号 + Jenkins 链接
│
▼
完成（不轮询结果）关键设计点
1. 分支 → Job 自动路由
不同项目的分支名有前缀约定，根据前缀自动选择对应的 Jenkins Job：
| 分支前缀 | Jenkins Job | 用途 |
|---|---|---|
mini-* |
dev_mini_deploy |
微信小程序发布 |
h5-* |
dev_web_deploy |
H5 页面发布 |
匹配不到时不猜，列出所有 Job 让用户手动选择。
2. 参数实时拉取，不硬编码
Job 的参数可能随时调整（加字段、改默认值、改可选项），所以每次都通过 API 获取实时参数定义：
bash
curl -s -u "$USER:$TOKEN" \
"$JENKINS_URL/job/<jobName>/api/json?tree=property[parameterDefinitions[name,type,defaultParameterValue[value],description,choices]]"从返回中提取参数名、类型、默认值和可选项，而不是在代码里写死。
3. 参数合并优先级
用户明确指定的参数 > Job 默认值 > 留空用户只说「发布」而没有指定其他参数时，全部使用默认值，不反复询问。但 app_branch 是必填项，必须从分支路由步骤获取。
4. 触发前强制确认（最重要的安全闸门）
在真正触发构建之前，必须以表格形式展示发布摘要，等待用户明确回复「确认」后才执行：
markdown
## 发布确认
| 项 | 值 |
|---|---|
| Job | dev_mini_deploy |
| app_branch | mini-feat-20260805 |
| env | outDev（默认） |
| appid | wx********（默认，测试环境） |
| 其他参数 | 全部默认 |
回复"确认"执行发布。以下情况额外加醒目警告：
- 主分支：分支为 master/main 时提示「即将发布主分支」
- 生产环境：参数值含 prd/pre/production 时提示「即将发布到生产环境」
- 正式 appid：检测到正式环境 appid 时提示「即将发布正式版」
- Job 进行中：目标 Job 有构建在跑时提示「本次将排队」
5. 触发后不轮询
触发构建后，只输出「已触发」摘要和 Jenkins 链接，不轮询构建结果。理由：
- 构建可能跑几分钟到十几分钟，轮询浪费 token 和时间
- 用户可以直接点链接看实时进度
- AI 的职责是「触发」，不是「监控」
五、MCP 不可用时的降级方案
MCP 工具偶尔会因为网络、npx 下载慢等原因不可用。这时候自动降级到 curl 方式，保证发布流程不被阻塞。
1. 获取 CSRF crumb
Jenkins 默认开启 CSRF 保护，触发构建前需要先获取 crumb：
bash
CRUMB=$(curl -s -u "$JENKINS_USER:$JENKINS_TOKEN" \
"$JENKINS_URL/crumbIssuer/api/json" \
| python3 -c "import sys,json;print(json.load(sys.stdin)['crumb'])")crumb 有时效性，每次触发前现取，不要复用旧 crumb。
2. 触发构建
bash
curl -s -u "$JENKINS_USER:$JENKINS_TOKEN" \
-H "Jenkins-Crumb:$CRUMB" \
-X POST "$JENKINS_URL/job/<jobName>/buildWithParameters" \
--data-urlencode "app_branch=<branch>" \
--data-urlencode "key2=value2" \
-D - -o /dev/null -w "\nHTTP_CODE: %{http_code}\n"成功返回 201 Created，响应头的 Location 字段就是队列项 URL，从中提取队列 ID。
3. 错误码处理
| HTTP 码 | 含义 | 处理 |
|---|---|---|
| 201 | 已入队 | 输出已触发摘要 |
| 400 | 参数错误 | 检查参数名/值，对照 choices |
| 403 | 权限不足 | 告知用户，不重试 |
| 404 | Job 不存在 | 检查 jobName 拼写 |
| 500 | Jenkins 内部错误 | 稍后重试 |
六、实际使用效果
配置完成后，发布流程变成了：
bash
👤 帮我发个版
🤖 已读取当前分支 mini-feat-20260805，将路由到 dev_mini_deploy。
## 发布确认
| 项 | 值 |
|---|---|
| Job | dev_mini_deploy |
| app_branch | mini-feat-20260805 |
| env | outDev（默认） |
| 其他参数 | 全部默认 |
回复"确认"执行发布。
👤 确认
🤖 ## 已触发构建
| 项 | 值 |
|---|---|
| Job | dev_mini_deploy |
| 构建号 | #324 |
| 分支 | mini-feat-20260805 |
| 环境 | outDev |
| 链接 | http://jenkins.internal.example.com/job/dev_mini_deploy/324/ |
构建任务已提交，可点击链接查看实时进度。全程不离开 IDE，不用开浏览器，不用记参数名。
七、总结
整个方案的核心思路：
- MCP 打通工具层：让 AI 能调用 Jenkins API
- SKILL 固化流程层：把发布经验、路由规则、安全检查写成 AI 可执行的步骤
- 人工确认做安全闸门：AI 负责准备和展示，人负责最终决策
- 降级方案保证可用性：MCP 挂了也能用 curl 完成发布
这套思路不仅适用于 Jenkins，也可以推广到其他运维场景------只要系统有 REST API，就能通过 MCP 接入 AI，再通过 SKILL 把操作流程标准化。
AI 不会取代运维，但会用 AI 的运维会取代不会用 AI 的运维。 🚀