让 AI 从需求直接走到 MR：我开源了一个面向 GitLab 的工作流 MCP

庭風
0 阅读8分钟

如果你已经在用 Codex、Claude Code、Cursor 这类 AI 编程工具，应该很容易遇到一个很别扭的断点：

AI 会写代码，但真正进入团队交付时，流程还是断的。

你还是要自己补 GitLab Issue、拉分支、整理提交、创建 Merge Request、回写 issue 评论、补 issue log，遇到截图类需求时还得自己再做一轮上下文确认。AI 负责了“写代码”这一段，但没有真正接住 GitLab 里的交付链路。

这正是我做 mcp-gitlab-workflow 的原因。

它不是一个单纯的 GitLab API MCP，也不是“再包一层 GitLab REST API”这么简单。它更像一个面向 issue-driven development 的工作流 MCP：既提供高层的交付编排能力，也保留底层原子工具，方便你把 AI 真正接入 GitLab 的需求到 MR 流程。

完整链路大致是这样：

requirement -> issue -> branch -> code change -> MR -> issue update -> issue-log

整体流程图

它解决的不是“写代码”，而是“把 AI 放进 GitLab 交付流程”

我想解决的问题很具体：

当我们把一个需求交给 AI 时，真正麻烦的往往不是让它生成一段代码，而是如何让这段代码进入一个可追踪、可审阅、可回写、可复盘的 GitLab 交付链路。

所以 mcp-gitlab-workflow 做了两层设计：

  • 高层 workflow_* 工具，负责把“需求 / issue 到交付”的常见流程直接串起来
  • 底层 gitlab_* 工具，负责 GitLab API 的原子能力，方便你自己编排

这两层设计是我刻意保留的。

如果你只想快速跑通一条标准流程，可以直接用高层 workflow。 如果你已经有自己的 agent prompt、skill 或 orchestration 逻辑，也可以只拿底层原子工具来拼装。

我更在意的是 guardrails，而不是“全自动”

这篇文章最想讲的，不是这个工具能不能“一键自动开发”，而是它有没有把 GitLab 场景里那些容易翻车的约束考虑进去。

1. 先准备工作区，再进入交付

我在高层流程前面单独放了一个 workflow_prepare_delivery_workspace。

它会先做几件事：

  • 校验本地仓库是否干净
  • 刷新 base branch
  • 在 local_git 模式下创建并切到工作分支
  • 记录当前基线状态，发放一个带有效期的 preparation_key

后续真正交付时，如果基线已经漂移，或者这个上下文已经过期，流程会直接拒绝继续执行，而不是在错误的上下文里“硬做下去”。

这里的有效期目前是 30 分钟，目的很简单：让 agent 在一个明确、可校验的上下文里生成交付结果，而不是假定本地仓库一直没变。

2. 本地交付和远程交付，两种模式都支持

这个项目支持两种 delivery mode：

  • local_git
  • remote_api

如果你希望 agent 在本地工作区里改代码、提交、推分支，适合 local_git。 如果你更想通过 GitLab API 直接提交文件动作，也可以用 remote_api。

我不想把用户绑定在某一种工作方式里。团队的环境不一样，安全要求也不一样，MCP 最好是适配流程，而不是强迫流程适配工具。

3. 遇到 issue 截图，先审阅再改

这也是我很在意的一点。

很多真实 issue 都不是纯文本，而是带截图、标注图、设计稿片段。如果 agent 直接跳过这些图像上下文，最后生成出来的代码往往会偏。

所以在 workflow_issue_to_delivery 里，如果 issue 里带图片引用，流程会要求先调用：

gitlab_get_issue_images(..., include_base64=true)

先把图片取出来并审阅，再继续交付。这不是“增加步骤”，而是在避免 AI 在信息不完整的情况下直接做错事。

4. MR review 也不是一句“帮我看下 diff”

我还单独做了两段式的 MR 审查工作流：

  • 第一步准备 review context，把 prompt、changed files、diff 一起整理出来
  • 第二步基于这个上下文生成 review comment，并且可以选择是否 approve

也就是说，这个工具不只覆盖“从需求到 MR”，还考虑了 MR review 这段经常被忽略的协作流程。

5. 交付结果要回写，而不是停在 MR 页面

很多 AI 编程流程最后都停在“代码已经改完”。

但在 GitLab 团队里，真正有价值的是：

  • issue 被回写了什么实现摘要
  • 哪些文件改了
  • 验收怎么做
  • 本地是否留下一条可追踪的 issue log

mcp-gitlab-workflow 会在交付结束后自动回写 issue comment，并更新本地 issue-log.md。如果 log 文件在仓库里是相对路径，它还会顺手补上 .gitignore，避免把本地跟踪文件误提交进版本库。

下面这几张图是 README 里现成的真实流程截图：

MR 示例

Issue 评论示例

issue-log 示例

快速开始：先把它接到你的 AI 编程环境里

这个项目已经发布到了 npm：

当前 npm 公布版本是 0.1.2。

最短的运行方式是直接用 npx：

{
  "mcpServers": {
    "gitlab-workflow": {
      "command": "npx",
      "args": ["-y", "@chntif/mcp-gitlab-workflow"],
      "env": {
        "GITLAB_TOKEN": "YOUR_TOKEN",
        "GITLAB_API_BASE_URL": "https://gitlab.com/api/v4",
        "WORKFLOW_ISSUE_PROJECT_ID": "YOUR_ISSUE_PROJECT_ID",
        "WORKFLOW_CODE_PROJECT_ID": "YOUR_CODE_PROJECT_ID",
        "WORKFLOW_BASE_BRANCH": "develop",
        "WORKFLOW_TARGET_BRANCH": "develop",
        "WORKFLOW_LOCAL_REMOTE_NAME": "origin"
      }
    }
  }
}

如果你在用 Codex，可以直接这样加：

codex mcp add gitlab-workflow \
  --env GITLAB_TOKEN=YOUR_TOKEN \
  --env GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
  --env WORKFLOW_ISSUE_PROJECT_ID=YOUR_ISSUE_PROJECT_ID \
  --env WORKFLOW_CODE_PROJECT_ID=YOUR_CODE_PROJECT_ID \
  --env WORKFLOW_BASE_BRANCH=develop \
  --env WORKFLOW_TARGET_BRANCH=develop \
  --env WORKFLOW_LOCAL_REMOTE_NAME=origin \
  -- npx -y @chntif/mcp-gitlab-workflow

如果你在用 Claude Code，也可以直接添加：

claude mcp add gitlab-workflow \
  -e GITLAB_TOKEN=YOUR_TOKEN \
  -e GITLAB_API_BASE_URL=https://gitlab.com/api/v4 \
  -e WORKFLOW_ISSUE_PROJECT_ID=YOUR_ISSUE_PROJECT_ID \
  -e WORKFLOW_CODE_PROJECT_ID=YOUR_CODE_PROJECT_ID \
  -e WORKFLOW_BASE_BRANCH=develop \
  -e WORKFLOW_TARGET_BRANCH=develop \
  -e WORKFLOW_LOCAL_REMOTE_NAME=origin \
  -- npx -y @chntif/mcp-gitlab-workflow

如果你的 issue 项目和代码项目是同一个 GitLab 项目，也可以把两个 project id 都指向同一个项目。

具体的参数介绍请移步我的 GitHub 中查看。

两个最值得直接复制的使用场景

场景 1：从需求直接推进到 MR

如果你手里是一段还没落 issue 的需求，可以直接让 agent 显式使用高层 workflow：

使用 workflow_requirement_to_delivery，为后台管理系统新增论坛互动功能。

这种场景适合“我知道要做什么，但还没开始建立交付上下文”的任务。

场景 2：从现有 issue 直接推进交付

如果团队已经把需求整理进 GitLab issue 里，尤其是带了截图或补充说明的情况，可以直接从 issue 出发：

使用 workflow_requirement_to_delivery，查看 [Issue链接] 并完成这个功能

这种方式更贴近真实团队流程，因为它不是“把一段自然语言丢给 AI”，而是“让 AI 接住已经存在于 GitLab 的任务上下文”。

简单的描述即可，调用工具的时候AI会从工具描述，参数描述明白需要怎么做，即便使用国内的模型也能够完整走完整个流程，不会缺漏步骤。

如果你想自己编排，它也不是黑盒

虽然这篇文章一直在讲高层 workflow，但这个项目并没有把自己做成一个黑盒。

底层你仍然可以单独使用这些原子工具：

  • issue 相关：创建 issue、读取 issue、读取 issue notes、补 issue comment、提取 issue 图片
  • 仓库相关：创建 branch、获取文件、批量 commit files、上传项目文件
  • MR 相关：创建 MR、读取 MR、读取 MR notes、获取 MR diff、approve / unapprove MR

这意味着它既可以直接拿来用，也可以被你自己的 skill、agent prompt、自动化脚本继续封装。

如果你已经在做自己的 MCP 编排，这一层会很有用。

当前状态：新开源、已经可用，但还在继续打磨

这里也把现状说清楚。

  • 这个仓库是我在 2026-03-16 创建并公开的
  • 最近一次 GitHub 更新时间是 2026-03-26
  • 当前 npm 版本是 0.1.2
  • package.json 里的测试脚本目前还是 No automated tests configured

所以我会把它定义成：

一个已经可用、适合真实试用的新开源工具，而不是一个已经被大量团队验证过的成熟平台。

我更希望先把工作流方向做对，把高频场景打磨扎实，再继续补自动化测试、更多模板和更完整的生态接入。

为什么我觉得这个方向值得继续做

我越来越确定，AI 编程工具接下来的差异不会只体现在“补全更快”或者“代码写得更像人”。

真正有价值的，是它能不能进入团队实际的研发交付流程，并且在进入流程后仍然保持：

  • 可追踪
  • 可审阅
  • 可回写
  • 可约束

mcp-gitlab-workflow 想做的就是这件事。

不是让 AI 替代 GitLab 流程，而是让 AI 能在 GitLab 流程里更自然、更安全地工作。

试试看，也欢迎直接来提问题

如果你也在用 GitLab 做 issue-driven development，又正好在把 Codex、Claude Code、Cursor 这类工具接进研发流程，可以直接试试这个项目：

如果你有下面这些场景，我会尤其想听反馈：

  • 你希望 AI 严格遵循 GitLab issue -> branch -> MR 的研发流程
  • 你们的 issue 经常带截图、设计稿、验收说明
  • 你想把 agent 输出和 issue comment / issue log 绑定起来
  • 你已经有自己的 MCP / skill / orchestration，希望复用底层 GitLab 工具

欢迎直接提 issue、提 PR，或者告诉我你最想补的场景。

我会继续把这个工具往“真正适合团队交付的 GitLab MCP”这个方向打磨下去。

avatar
文章
阅读
粉丝