日常工作知识库

Appearance

iGit MR 工具从 MCP 到 Skills 的工程化演进 ​

归类：Tools / AI 工程化 / GitLab Review 发生时间：2026-04-22 状态：✅ 已沉淀

一、背景 ​

围绕 iGit / GitLab 的 MR 审查，团队通常会遇到同一类问题：

  • 审查动作高频，但步骤重复
  • 单靠自然语言提示词不稳定
  • 需要真实连接 GitLab API，而不只是生成“看起来像审查”的文本
  • 不同 IDE / Agent 对技能、slash、MCP 的支持并不一致

因此这类能力如果只靠 prompt 很难长期维护，最终需要走向工程化。

二、第一阶段：先把 MR 能力做成 MCP 工具 ​

最早的关键决策不是先做 skill，而是先做 MCP Server。

原因很简单：

  • Skill 解决的是“怎么更方便地用”
  • MCP 解决的是“底层能力到底有没有”

因此第一阶段先把 GitLab 相关动作抽象成结构化工具，例如：

  • 搜索项目
  • 查询 MR
  • 获取 diff
  • 读取评论
  • 生成标准化 review
  • 生成统计与报表

这一步的价值是把 MR 能力从“聊天提示词”变成“结构化接口”。

三、第二阶段：用 Skills 收敛高频入口 ​

只有 MCP 还不够，因为普通用户仍然会遇到两个问题：

  1. 不知道应该调用哪些工具
  2. 不同 IDE 中的入口习惯不同

于是第二阶段开始引入 skills，把高频场景封装成更直接的入口，例如：

  • /igit-mr-review
  • /igit-mr-review-mcp
  • /igit-mr-report
  • /igit-mr-skills

这一步的核心设计不是重新实现能力，而是：

  • 给出默认工作流
  • 约束推荐调用路径
  • 降低用户记忆成本

也就是说，Skills 是能力编排层，不是能力来源。

四、第三阶段：补齐安装与分发链路 ​

当 skills 开始变多之后，新的问题变成了：

用户怎么安装，怎么配，怎么验证自己能不能用？

这时就不能只停留在“有 skill 文件”这一级，而要补齐完整分发链路：

  • npm 包分发
  • 一键安装脚本
  • best-effort 客户端配置
  • 环境变量引导
  • 自检

于是系统继续演进出统一 installer / bootstrap 方案，让用户可以通过固定命令安装完整能力。

对外最终收敛成两条更稳定的安装路径：

bash
curl -sSL https://j1.58cdn.com.cn/epfe/scripts/igit-mr-skills-install.sh | bash
bash
mds skills igit-mr-review

五、第四阶段：补一条不依赖客户端 MCP 的本地 CLI 路径 ​

即使 installer 做好了，仍然会遇到一个现实问题：

  • 有些 IDE 的 MCP 配置不稳定
  • 有些客户端会缓存状态
  • 用户不一定想理解 MCP 注册

所以工程上又补了一条 PlanB 本地 CLI 路径。

这一步最重要的设计点是：

不是重新写一套 MR 工具，而是继续复用同一套底层实现。

做法是把原本注册到 MCP Server 的工具，再挂接到一个本地 registry 上，让它们既能通过 MCP 调用，也能通过本地 CLI 调用。

这样最终形成了双运行时：

  • MCP Runtime
  • Local CLI Runtime

但业务能力仍然尽量只有一份实现。

六、为什么这套演进是“分层增强”，不是“推翻重来” ​

这套架构最关键的地方在于，每一步都没有否定前一步，而是在补齐新的短板：

MCP ​

解决“能力标准化”

Skills ​

解决“用户入口收敛”

Installer / Bootstrap ​

解决“安装和配置成本”

Local CLI ​

解决“客户端兼容性和兜底运行”

所以它不是从 MCP “迁移”到 Skills，而是从单一能力层逐步演进成完整的工程产品链路。

七、当前推荐的用户心智 ​

现在更推荐把用户入口理解成下面这几层：

普通用户 ​

只需要记住：

  • 安装：curl | bash 或 mds skills igit-mr-review
  • 使用：/igit-mr-review

管理员或调试用户 ​

可以额外使用：

  • /igit-mr-review-mcp
  • /igit-mr-skills
  • igit-mr-bootstrap

这能更快判断问题究竟出在：

  • skill 入口
  • MCP 注册
  • 本地 CLI
  • GitLab 鉴权

八、架构示意 ​

mermaid
flowchart TD
    A["GitLab / iGit API"] --> B["统一业务工具实现"]
    B --> C["MCP Server Runtime"]
    B --> D["Local CLI Runtime"]
    C --> E["Skills via MCP"]
    D --> F["Skills via Local CLI"]
    G["Bootstrap Installer"] --> E
    G --> F

九、这套实现最有价值的工程收益 ​

1. 底层能力单一源 ​

MCP 和 CLI 不是两套业务逻辑，而是两种运行时承载方式。

2. 用户入口足够简单 ​

高频用户不需要理解几十个工具名，只要记住少量 slash 入口。

3. 安装路径统一 ​

无论是 shell 一键安装还是 mds skills，都可以收敛到同一套 bootstrap 逻辑。

4. 可调试、可分流 ​

通过 CLI 路径和 MCP 路径并行存在，排障会快很多。

十、推荐实践 ​

如果你要把一套“AI + 研发流程”的能力做成长期可维护的工程体系，比较稳妥的顺序通常是：

  1. 先把核心行为做成结构化工具
  2. 再把高频场景做成 skill / workflow 入口
  3. 再补 installer / bootstrap
  4. 最后再考虑 MCP-less fallback 或本地 CLI 兜底

这样能最大化复用底层能力，同时避免用户体验和工程实现彼此割裂。