为什么做这个？

说实话，用了 Claude Code 一段时间之后，我发现一个挺尴尬的事。

AI 能帮我写代码、改 bug、重构项目，但部署、测试、CI/CD 这些活儿还得我自己手动来。

就像请了一个很厉害的厨师，但端菜上桌还得我自己来。不对劲。

所以我一直在想，能不能让 Claude Code 不只是"写代码"，而是能真正参与到完整的开发工作流里。

今天（2026-02-18）看到 Claude 官方推出 MCP Apps 的消息时，我突然意识到 —— 时机到了。

MCP 是什么？

MCP（Model Context Protocol）是 Anthropic 推出的一个开放协议，简单说就是让 AI 能调用外部工具的标准方式。

以前的 AI 工具是封闭的，每个都有自己的插件系统。MCP 想做成"通用接口"，就像 USB 一样，一个工具所有 AI 都能用。

但这东西到底有多实用？我决定自己试试。

我的目标

我想让 Claude Code 能直接：

1. 构建 Docker 镜像 —— “帮我 build 一下这个项目的镜像”
2. 运行测试 —— “跑下测试，看看有没有挂”
3. 查看 git 状态 —— “我改了哪些文件？”
4. 未来甚至部署 —— “部署到预览环境”

如果成了，以后我只需要跟 Claude 说句话，它就能帮我完成一整套 DevOps 流程。

开始折腾

第一步：让 Claude 能"看到"我的工具

MCP Server 可以用 HTTP 或 stdio 两种方式通信。我一开始想写 HTTP，觉得这样可以用浏览器测试。

结果搞了一小时，Claude Code 根本不识别。查文档才发现 —— Claude Code 只支持 stdio 模式。

好，改。

import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const transport = new StdioServerTransport();
await server.connect(transport);

然后要在 Claude Code 的配置里加上：

{
  "mcpServers": {
    "devops": {
      "command": "node",
      "args": ["/path/to/my/server.js"]
    }
  }
}

重启 Claude Code，输入 /tools，看到我的工具列表出现了！

🎉 第一步搞定。

第二步：实现 Docker 操作

这个看起来简单，不就是 execSync('docker build ...') 吗？

结果 —— 权限问题。

Docker 用的是 Unix socket /var/run/docker.sock，普通用户默认没权限访问。报错信息是：

Cannot connect to the Docker daemon

解决方案是把用户加入 docker 组：

sudo usermod -aG docker $USER
newgrp docker  # 或者重新登录

Linux 上搞定了，但 macOS 上又出问题。Docker Desktop for Mac 用的是虚拟机，socket 位置不一样，权限管理也更复杂。

我暂时加了个检测：

if (process.platform === 'darwin') {
  // macOS 需要额外处理，暂时还没完全解决 😅
}

以后有时间再搞。

第三步：Git 工作流

Git 操作倒是顺利，直接用 child_process 执行 git 命令就行。

但我发现一个有意思的事：Claude Code 原生的文件编辑能力已经很强了，但让它"知道" git 状态，能做出更聪明的决策。

比如：

• 用户说"提交更改" → Claude 先检查 git status，确认有文件要提交
• 用户说"回滚到上一个版本" → Claude 先 git log 查看历史

这种上下文感知让交互更自然。

目前的成果

折腾了一晚上，现在 Claude Code 可以：

功能	命令示例	状态
构建 Docker 镜像	“build docker image for this project”	✅
查看容器状态	“show me running containers”	✅
查看 git 状态	“what files did I change?”	✅
运行测试	“run the tests”	✅
代码检查	“check code style”	✅

📁 代码开源在这里：https://github.com/YaBoom/claude-devops-mcp-zyt

踩过的坑

1. stdio vs HTTP：一开始搞错传输方式，浪费了一小时
2. Docker 权限：跨平台兼容性比想象中复杂
3. 日志输出：MCP 协议用 stdout 通信，日志必须写到 stderr，不然会干扰协议
4. 错误处理：Docker 构建可能产生大量输出，要设置好 maxBuffer，不然会溢出

这些坑都记录在项目的 experiments/ 目录里。

还没做完的事

说实话，这个项目距离" production ready"还远着呢：

• 部署功能只搭了框架，没实现具体逻辑
• macOS 上的 Docker 支持还不完善
• 没有错误重试机制
• 日志格式有点乱
• 测试覆盖率几乎为零

但我觉得先做出来、开源、分享，比追求完美更重要。

这代表了什么？

今天的纽约时报发了一篇文章讲 “Vibecoding” —— 用 AI 工具生成代码的新趋势。

我觉得这个概念可以延伸：不仅是"生成代码"，而是让 AI 参与到整个软件生命周期。

VibeDevOps？可能吧。

想象这样一个场景：

你：“帮我部署最新版本到 staging”
Claude：“好的，我先 pull 最新代码，运行测试，build 镜像，然后部署。测试通过了，已部署到 https://staging.example.com”

这听起来像是科幻，但 MCP 协议让这一切成为可能。

想试试吗？

git clone https://github.com/YaBoom/claude-devops-mcp-zyt.git
cd claude-devops-mcp-zyt
npm install
npm run build

然后在 Claude Code 的配置里加上 MCP Server 路径，重启即可。

详细配置看 README。