日常工作知识库

Appearance

iGit MR 工具分享提纲与精简架构图 ​

归类：Tools / AI 工程化 / GitLab Review 发生时间：2026-04-22 状态：✅ 可直接复用

一页版结论 ​

这套 iGit MR 工具的演进，不是简单把一个 MCP 项目“改成 skills”，而是逐步补齐完整产品链路：

  1. 先把 MR 审查能力做成结构化工具
  2. 再把高频场景封装成 skills
  3. 再把安装与环境配置收敛成 bootstrap
  4. 最后补一条不依赖客户端 MCP 的本地 CLI 兜底路径

最终得到的是一套“双运行时、单能力源”的工程体系：

  • 对 IDE 友好：MCP + skills
  • 对安装友好：installer + bootstrap
  • 对兼容性友好：本地 CLI fallback

适合 10 分钟分享的提纲 ​

1. 背景问题 ​

  • MR 审查是高频动作，但提示词天然不稳定
  • 只靠聊天难以保证可复用、可自动化、可审计
  • 不同 IDE 对 slash、skills、MCP 的支持并不一致

2. 第一阶段：为什么先做 MCP ​

  • Skill 解决“怎么更方便用”
  • MCP 解决“底层能力到底有没有”
  • 所以第一步先把 GitLab 行为抽象成结构化工具

3. 第二阶段：为什么还要做 Skills ​

  • MCP 工具太底层，普通用户不该记一堆工具名
  • 高频场景需要统一入口，比如 /igit-mr-review
  • Skills 的价值是入口编排，不是能力重写

4. 第三阶段：为什么还要做 Installer / Bootstrap ​

  • 用户真正的问题常常不是“功能有没有”，而是“怎么装、怎么配、怎么验证”
  • 安装链路必须统一，不然 skill 和能力会脱节
  • 所以需要把 skills 安装、MCP best-effort 接入、env、自检收敛成一条链路

5. 第四阶段：为什么还要做本地 CLI ​

  • 客户端 MCP 配置不稳定
  • 用户不一定愿意理解 MCP
  • 需要一条“不依赖 IDE 配置也能跑”的兜底路径

6. 最终设计原则 ​

  • 单一业务能力源
  • 多种运行时承载
  • 少量高频入口暴露给用户
  • 安装路径统一

精简架构图 ​

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

分享时可以重点强调的 4 个点 ​

1. 不是“从 MCP 改成 Skills” ​

更准确地说，是在 MCP 之上补了一层更好用的 skills 和安装体系。

2. 底层能力只有一份 ​

MCP 和 CLI 是两种运行时，不是两套业务逻辑。

3. 用户入口必须收敛 ​

普通用户不应该理解几十个工具名，只需要记住少数高频入口。

4. 真正难点往往在安装与兼容性 ​

一个 AI 工具想长期可用，安装器、配置、自检和兜底路径往往比 prompt 本身更重要。

可直接复用的结束语 ​

我们这次并不是把“AI 能不能做 MR 审查”当成问题来解，而是把“如何把一套 MR 审查能力稳定交付给团队使用”当成真正的工程问题来解。

所以最终交付的不是一个 prompt，也不是一个单独的 MCP server，而是一整套：

  • 能力层
  • 入口层
  • 安装层
  • 兜底层

这也是这类 AI 工程体系能否真正落地的关键分界线。