Claude Code + MCP 实战:搞了个自动部署工具,我的发版流程从 20 分钟变成 2 分钟
搞了两天,我把项目的部署流程彻底重构了。
用 Claude Code + 自定义 MCP Server 搭了一套自动化发版工具。以前手动部署一次至少 20 分钟——连服务器、拉代码、切分支、跑构建、重启服务、看日志确认启动成功。现在跟 Claude 说一句话,两分钟搞定。
这篇文章就记录一下我是怎么做的,踩了哪些坑,以及一些真实感受。
为啥要折腾这个
先交代一下背景。
我们项目用的是比较传统的部署方式:SSH 连到服务器 → git pull → docker-compose build → docker-compose up -d。每次发版都要重复这套流程,手速快也得十几分钟。
之前也想过上 CI/CD,但团队小,搞 Jenkins 太重量级,GitHub Actions 倒是轻量,可有些环境(内网服务器)不太好打通。
所以一直将就着。
直到上周我试了 Claude Code 的 MCP 能力——它允许你自己写工具函数,让 AI 直接调用。我突然意识到:部署这件事,完全可以交给 AI 来做。
第一步:写一个部署 MCP Server
Claude Code 的 MCP Server 可以用 Python 写,非常简单。核心就三步:
- 定义一个 Server 实例
- 用
@tool()装饰器暴露工具 - 启动 Server
我写了一个 deploy_mcp.py,专门处理部署相关操作:
import subprocess
import os
from mcp.server import Server
app = Server("deploy-tools")
@app.tool()
def deploy(env: str, branch: str = "main"):
"""部署指定分支到环境(staging / production)"""
cmds = [
f"cd /opt/project && git fetch origin",
f"cd /opt/project && git checkout {branch}",
f"cd /opt/project && git pull origin {branch}",
f"cd /opt/project && docker-compose build",
f"cd /opt/project && docker-compose up -d",
]
for cmd in cmds:
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
if result.returncode != 0:
return f"失败: {cmd}\n{result.stderr}"
return f"✅ {env} 部署 {branch} 成功"
@app.tool()
def rollback(env: str, commits: int = 1):
"""回滚环境到前 N 个提交"""
cmds = [
f"cd /opt/project && git revert HEAD~{commits}..HEAD --no-edit",
f"cd /opt/project && docker-compose build",
f"cd /opt/project && docker-compose up -d",
]
for cmd in cmds:
# ... 省略同理
@app.tool()
def check_logs(env: str, lines: int = 50):
"""查看环境最近的日志"""
result = subprocess.run(
f"cd /opt/project && docker-compose logs --tail={lines}",
shell=True, capture_output=True, text=True
)
return result.stdout[-3000:] if len(result.stdout) > 3000 else result.stdout
if __name__ == "__main__":
app.run()
整个文件不到 80 行。
核心逻辑其实就是把之前手动敲的命令串起来,封装成函数,然后加个 @tool() 装饰器。Claude Code 会自动读取函数的签名和 docstring,理解每个工具能做什么、参数怎么传。
第二步:把 MCP Server 接入 Claude Code
服务端写好了,接下来要在 Claude Code 里注册。
在项目根目录创建 claude.json:
{
"mcpServers": {
"deploy": {
"command": "python",
"args": ["deploy_mcp.py"],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
注意这里用的是 command + args 的 stdio 模式,不是 SSE 模式。强烈建议用 stdio,后面会说原因。
配好之后,启动 Claude Code,输入:
检查一下生产环境的日志,看看最近有没有报错
Claude 会调用 check_logs 工具,返回日志内容。你甚至不需要告诉它用哪个工具——它会根据你的需求自动选择。
第三步:实战演示
配好之后,我的日常发版流程变成了这样:
我:把 main 分支部署到 staging,然后帮我看看日志
Claude Code 会依次调用 deploy("staging") 和 check_logs("staging")。
全程我只需要说一句话。它自己连服务器、拉代码、构建、部署、检查日志。如果有报错,它还会分析日志内容告诉我哪里有问题。
再比如回滚:
我:生产环境刚才那个版本好像有问题,回滚两个提交
Claude 调用 rollback("production", 2)。整个过程透明可见,每一步的输出都会显示在终端里。
说实话,第一次跑通的时候,我盯着终端看了好一会儿——不是代码写的多好,而是这种"动口不动手"的感觉,真的很爽。
踩坑记录
看着简单,但我搞了两天才完全跑通。下面是我踩的几个坑:
坑一:SSE 模式掉线
一开始我用的 SSE(Server-Sent Events)模式启动 MCP Server,结果 Claude Code 挂一会儿就报连接超时。
查了才知道,SSE 没有心跳机制。长时间没交互,连接就断了。生产环境请用 stdio 模式,Claude Code 会自己管理子进程的生命周期,比 SSE 稳定一百倍。
坑二:工具返回值别太长
我的 check_logs 一开始返回全部日志,结果有次日志 2 万多行,直接撑爆了 Claude 的上下文。
解决方案:返回值限制在 3000 字符以内,需要更多就分页。另外,返回值格式一定要用纯文本或简单的 JSON,别搞花里胡哨的格式,AI 解析起来也费 token。
坑三:权限管理
这个最容易被忽视。
MCP Server 跑在服务器上,能访问你的文件系统。我第一次直接把 / 目录暴露给了工具函数——AI 生成代码调我的工具时,差点把我家目录的文件全都列出来了。
安全原则:给 MCP 工具最小权限。 我的 deploy 工具只允许在 /opt/project 目录下操作,其他路径一律拒绝。
坑四:并发冲突
有次我和同事同时在 Claude Code 里调了部署工具,结果俩进程同时执行 docker-compose build,直接报锁冲突。
解决方法很简单:加一个文件锁,同一时间只允许一个部署操作。
import fcntl
lock_file = "/tmp/deploy.lock"
with open(lock_file, "w") as f:
fcntl.flock(f, fcntl.LOCK_EX)
# 执行部署操作
真实感受
这套方案跑了一周了,说几个最直接的感受:
**1. 发版不再是负担。**以前快到下班时间接到发版需求,心里就咯噔一下。现在一句话搞定,心态完全变了。
**2. 回滚勇气变大了。**以前回滚要手动操作,总担心搞错,所以"将就着用吧"。现在回滚也是一句话的事,发现问题果断回滚,线上稳定性反而提高了。
**3. 但别太信 AI。**有一次 Claude 调用 deploy 时,参数传错了环境名——我要部署到 staging,它给部署到 production 了。还好我当时盯着终端看到了输出,及时阻止了。
血的教训:生产环境操作,一定要人肉确认后再放行。 我后来加了一个工具叫 confirm_deploy,先确认目标环境,得到用户确认后才执行。
写在最后
MCP + Claude Code 这套组合,核心价值不是"让 AI 写代码",而是让 AI 帮你干活。
代码生成只是冰山一角。当你的工具能操作数据库、管理部署、监控日志、甚至重启服务的时候,AI 就从"代码生成器"变成了"项目操盘手"。
这周我打算再写一个数据库运维 MCP 工具——让 AI 直接帮我查慢查询、看表结构、甚至做数据迁移。如果能搞定,那日常 80% 的重复操作都可以交给 AI 了。
有进展了我再来更新。
对了,如果你也在折腾 MCP,有什么好用的工具欢迎评论区交流。互相抄作业才是最快的进步方式。
更多推荐


所有评论(0)