在鼎道内部的研发协作中，GitLab 是核心的代码管理与流程协作平台，基于此，这篇文章想写的事情其实很具体，就是怎么在团队内部用 OpenClaw 的 Skill 去自动化 GitLab 的一部分工作流。最开始我并不是为了做一个很大的 AI 平台改造，只是觉得有些流程已经重复到没有必要继续手工处理了，尤其是提测单、上线申请，还有 reviewer 指派之后那段很机械的 code review 前置动作。这些事情规则清楚，文本格式相对固定，本来就适合交给 Agent 去做。
01 打通OpenClaw与私有化GitLab的基础链路
要实现自动化的前提，是让 OpenClaw 能对接鼎道内部的 GitLab（gitlab.dingdao.com），我们从gitlab-cli-skills这套基础能力切入，先完成glab工具的认证登录：
glab auth login --hostname gitlab.xxxx.com
登录流程采用鼎道团队统一的交互规范：协议选择https，允许 Git 复用认证，认证方式优先使用 Token（鼎道 GitLab 的 Personal Access Token 需按权限规范申请）。实际交互流程固定为：
? Preferred protocol: https
? Authenticate Git with your credentials: Yes
? How would you like to authenticate: Token
把 GitLab Personal Access Token 粘进去之后，这一步就算完成了。到这里还谈不上什么自动化，只能算是先把基础设施接上。但这一步是后面所有流程的前提，因为 gitlab-cli-skills 本质上就是通过 glab 去调用 GitLab。
02 改造Skill实现提测 / 上线流程自动化
把基础配置跑通之后，我真正开始动手的地方，其实是对 gitlab-cli-skills 做改造，让它更贴近团队自己的工作流。现成 skill 能操作 GitLab 没错，但团队内部真正麻烦的地方，不是“能不能建一个 issue 或 mr”，而是“建出来的东西是不是符合我们这边的流程要求”。
提测单自动化
我们这边的提测流程是通过 issue 提交的，而且有固定模板，里面还必须带上部署到测试环境的 tag。这个流程本来就很适合自动化，因为需要填写的信息不少，但信息来源又比较明确。所以我在 gitlab-cli-skills 里增加了 glab-test-request 这个 Skill，把提测单模板和对应命令一起封装进去。这样做之后，OpenClaw 不只是帮我“创建一个 issue”，而是按团队提测单的格式去创建 issue。
这个 Skill 里我比较想强调的不是模板本身，而是它开始理解团队的上下文了。比如它会去比较当前 tag 和上一个 tag 之间的 commit diff，再根据新增的 commit message 把提测内容先填出来，同时把提测单指给测试负责人。以前这件事也不是做不了，只是每次都要人自己去翻 tag、看提交、整理文字，再确认有没有漏写。流程一重复，人就很容易省略步骤，或者写成一张别人看不太懂的提测单。把这些约束放进 Skill 之后，提测这件事开始变得像一个可以重复执行的命令，而不是靠记忆完成的动作。
上线申请自动化
我们团队的上线申请是走 develop 到 master 的 MR，而且需求上线和 hotfix 走的审批流程不一样，另外还必须加上 Release Quest 标签，不然上线 CI 不会触发。类似这种规则， 平时发布上下也会占用不少的重复时间。于是我又补了一个 glab-mr-release，把上线申请用到的模板、参数说明和审批差异都写进 Skill 里。这样 OpenClaw 在创建上线 MR 的时候，生成出来的就不是一个“普通 MR”，而是符合我们内部上线流程的 MR。
这两个 Skill 定义下来之后，我自己的感受很直接，OpenClaw 可以很快的完成这两项工作，并且质量也高于手动创建。提测单和上线申请这种事情，一旦能被 Skill 表达清楚，就很适合交给 Agent 自动完成，至少能把大量重复的人力从流程里拿掉。
03 Code Review 自动化
除了提测单和上线申请，我觉得另一个很适合自动化的部分就是 code review。现在很多开源项目都已经在做 agent review，本质上是因为这条链路里也有一段很明显的重复劳动。尤其是被设成 reviewer 之后，先收到通知，再打开项目，再找 diff，再把上下文补齐，这段动作其实不需要工程师反复手工操作。
我最开始查资料的时候，针对 GitLab 的 review agent，大致看到两条路。第一条是走 Webhook。也就是在项目或者群组里配置 Webhook，事件发生后向一个 URL 发 POST 请求，只要 OpenClaw 有对应的接收端点，就能被触发。这个方案的优点很明显，如果其他同事把 reviewer 指给我，就可以直接进入 AI review 流程，链路很顺。
但这个方案在我这里有个很现实的问题，就是我的 OpenClaw 部署在本地，不是一个有公网地址的服务。既然 GitLab 访问不到 OpenClaw，那 Webhook 这条路在当前环境里就没有办法真正落地，所以我最后没有采用。
后来我想到的替代方式，是利用我们现有的邮件通知。因为公司的 GitLab review 工作流本来就会往企业邮箱发邮件，只要有人把 reviewer 指给我，我就能在邮箱里收到通知。这样一来，OpenClaw 不一定非得被 GitLab 直接调用，它也可以通过定时任务去读邮箱，识别出哪些邮件对应新的 review 任务，再继续往下执行。
这里我用到的是 himalaya 这个通用邮件 CLI。它支持通过 IMAP 连接邮箱，所以刚好可以作为这条链路里的入口。我这里是通过 cargo 来安装它的：
cargo install himalaya
安装完成后，himalaya 的配置文件在 ~/.config/himalaya/config.toml。我这边实际使用的结构大概如下：
[accounts.163]
email = "xxx@dingdao.com"
display-name = "xxxx"
default = true
backend.type = "imap"
backend.host = "imaphz.qiye.163.com"
backend.port = 993
backend.encryption.type = "tls"
backend.login = "xxxx@dingdao.com"
backend.auth.type = "password"
backend.auth.raw = "xxxx"
message.send.backend.type = "smtp"
message.send.backend.host = "smtphz.qiye.163.com"
message.send.backend.port = 994
message.send.backend.encryption.type = "tls"
message.send.backend.login = "xxxx@dingdao.com"
message.send.backend.auth.type = "password"
message.send.backend.auth.raw = "xxxx"
这里的 auth.raw 用的不是邮箱登录密码，而是客户端授权密码。对于 163 企业邮箱，在 设置 -> 账号与安全 -> 客户端设置中生成客户端授权密码来获取 token， 然后把它填进配置里。
在这条通路的基础上，我又封装了一个 himalaya-email-checker skill。这个 skill 负责去校验邮件格式，把和 review 相关的邮件筛出来，然后从邮件里提取项目路径、项目 ID 这些关键信息。拿到这些信息之后，再回头调用 gitlab-cli-skills 里的工具去看 diff，最后把 review 结果提交出去。到这里，review 自动化的链路才算真正闭合起来。
04 OpenClaw的核心价值是 “流程可执行化”
在这次实践中，我觉得最有意思的地方并不是某一个 skill 写得多复杂，而是 OpenClaw 在团队里开始承担一种“把流程写成可执行约束”的角色。原来提测单、上线申请、review 通知这些事情，大家都知道怎么做，但真正执行时还是会不断依赖经验、记忆和人工补位。现在把它们收进 skill 之后，很多重复劳动就可以直接交给 agent 去完成，人只需要保留最后的判断和确认。
这也是我最想强调的点。对团队来说，OpenClaw 的价值不一定首先体现在“能写多少代码”，而是把已经稳定存在的内部工作流整理成一套可重复运行的东西。这也是鼎道落地自动化工具的核心思路：先梳理内部标准化流程，再用工具将流程 “固化”，最终实现研发效率的提升。
对有类似私有化 GitLab 部署、内部流程标准化的团队而言，这套基于 OpenClaw 的改造思路完全可复用：只要流程规则足够明确，GitLab 上的绝大多数日常协作动作，都能像鼎道这样被自动化承接。
