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

如果你已经在用 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 里现成的真实流程截图：

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

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

npm: www.npmjs.com/package/@ch...
GitHub: github.com/chntif/mcp-...

当前 npm 公布版本是 0.1.2。

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

perl 复制代码

{
  "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，可以直接这样加：

ini 复制代码

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，也可以直接添加：

ini 复制代码

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 出发：

css 复制代码

使用 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 这类工具接进研发流程，可以直接试试这个项目：

GitHub 仓库：github.com/chntif/mcp-...
npm 包：www.npmjs.com/package/@ch...
English README：github.com/chntif/mcp-...
中文 README：github.com/chntif/mcp-...

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

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

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

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