别再给AI报分支名了，它现在自己去Git里查

以前我每次派活给编码智能体，都得先自己搞清楚当前发布到了哪一步，再把分支名写进提示词：从 develop/1.65.0 拉一个 feature 分支，改完往 develop/1.65.0 提 MR。明天同一个版本可能已经进了 alpha，再过一阵又到了 beta，分支名就得跟着换。

问题在于，发布阶段这件事从来没进过 Git、CI 和 Jira。它活在人的脑子里，活在我手动维护的一张 Confluence 表格里。我把它变成可计算的东西，先给自己做了个门户，再给智能体做成一个 MCP 工具。

先说清楚背景。这套 Git Flow 里，每个版本有一条自己的分支链：develop/1.65.0 → alpha/1.65.0 → beta/1.65.0 → prod/1.65.0。同时会有好几个版本在跑，一个在开发、一个在测试、一个在 beta、一个在生产。老版本上的修复，必须往新版本里带。

分支存在，不等于阶段到了

最直觉的算法是"找最新的那个已存在分支"，这条路走不通。新版本立项时，所有阶段的分支是一次性建好的，prod/1.65.0 从第一天就存在，哪怕这个版本才刚开始开发。

得换一个信号：按流程，版本是靠哪个动作往前推的。在这套流程里，这个动作是往对应阶段分支合并了一个 MR。目标分支按 阶段/版本 命名，MR 关联一个 Jira 任务。如果 alpha/1.65.0 上合过匹配的 MR，说明版本到了 alpha；如果之后 beta/1.65.0 上也出现了，那就是到了 beta。

工具的做法是：找出标题、分支名或描述里带 Jira key 的已合并 MR，把目标分支和版本、阶段顺序对上，取有证据的最靠后那个阶段。以 1.65.0 为例，develop 有证据、alpha 有证据、beta 和 prod 没有，结果就是当前阶段 alpha，基准分支 alpha/1.65.0。

这不是 Git 的通用属性，是我们对"发布状态"的定义。它成立的前提是流程事先约定好了。团队推进阶段的方式不一样，需要的证据就不一样。

智能体那边：一个回答"从哪开始"的 MCP

我不想让智能体从本地检出里猜发布状态，不想让它随手挑默认分支，也不想把每个项目的怪癖塞进提示词里让它背。它需要一个工具，回答一个具体问题：这个 Jira 任务从哪开始干，MR 往哪提。

这个工具是我写的 MCP 服务，叫 Delivery Manager。名字容易误导，它不替代真正的交付经理。人还是负责规划发布、在 Jira 里设 Fix Version。MCP 接的是一个已经排好期的任务，在既有发布流程里算出该怎么处理。

给它项目、版本和任务 key，它去查 GitLab，判定当前阶段，返回干活用的参数：fixVersion、currentStage、baseBranch、baseBranchExists、featureBranch，以及 mergeRequest 的 targetBranch。智能体不需要理解 1.65.0 今天为什么在 alpha，它拿到的是核实过的基准分支和 MR 目标分支。

我给智能体定的规则很硬：不许自己选基准发布分支，唯一来源是发布 MCP。以下情况一律不开工——任务没有 Fix Version；当前阶段判定不出来；需要的发布分支不存在；GitLab 不可用；任务不在"To Do"状态，也就是还不算准备好可以实施。

最后一条真触发过一次，场景很接地气：我自己忘了把任务挪到正确状态，活就停了。这不是工具出错，是它拒绝为了开始写代码而绕过流程。

算法不是从 MCP 开始的

在 MCP 之前，我有一张 Confluence 表格：行是版本号，列是阶段和操作。版本往前走，我就填个日期，把一个格子的绿色填充去掉，再涂另一个。它的准确性取决于我，而 GitLab 早就把我手动抄的每个动作都记下来了。

我是 Android 开发者，没写过 Web 门户。我在 ChatGPT 里聊了这个想法，拿到一段实现提示词，丢给编码智能体，gitlab-panel 门户就这么起来了。它从 GitLab 数据里拼出图景：一张版本为行、阶段为列的矩阵。

矩阵显示两个方向的变更流。横向是同一个版本在阶段间流动；纵向是门户去校验"老版本的修复必须到达新版本"这条规则——它比较相邻版本的分支，找出老版本有、新版本没有的提交，合并提交会被过滤掉。这条规则以前只是团队的一项义务。

从矩阵里的一个箭头，门户还能发起一次"pour"，也就是我们说的在阶段分支之间或版本之间搬运变更。我确认源、目标和变更内容，门户用已有的 Jira 任务或建一个子任务，把它移到 CodeReview，这一步失败就停；然后从源分支建一个临时 feature 分支，往目标提 MR。Squash 是故意关掉的，这样提交历史以后还能用来核对提交是怎么在版本间移动的。门户还会在流水线成功后尝试开启合并，但这不保证，有些步骤可能要人看一眼。

门户不判断某个版本该不该进下一个阶段。测试报就绪，交付经理规划后续并创建 pour 任务。自动化的是决策之后的动作。

两套实现，没有共享库

门户和 Delivery Manager 是两个独立项目，代码库分开。我没让 MCP 依赖一个跑着的门户。

需要 MCP 的时候，我让做门户的智能体讲清楚阶段判定算法在源码里的确切位置：文件、方法、逻辑。我把这份说明交给另一个做 MCP 的智能体，它把领域思路搬了过去。于是现在有两套实现，依赖同一套流程和同一份 GitLab 历史，但两者之间没有自动的代码同步。阶段顺序是另一个妥协：MCP 里从项目的发布分支和已知阶段名推出来，再固定在空间设置里；门户里则有单独的界面来管。

它可能错在哪

这套计算建立在三个假设上。

• 阶段是最远的那个已确认跃迁。往 beta/ 合了一个 MR，就意味着版本到了 beta。算法不会从任务名去反推业务逻辑。
• 版本只往前走。我的模型里没有从 beta 回退到 alpha，所以最靠后的已确认阶段就是当前阶段。团队如果会正式回退阶段，这个算法不够用。
• 没有确认 MR 时，取第一个已存在的阶段。这是新建版本的正常状态：分支都在，还没发生过搬运。这是有意设的兜底，不是被证明过的跃迁。

工程上的限制也有：两套实现意味着改一条规则得手动在两边移植。阶段检查没有并进之前那个 jira:check 的 CI 脚本，现在由别的工具来做。我也没统计过省了多少小时，所以不会报百分比。

变化本身不用数字也好描述。以前我要记住发布阶段、更新表格、向人或智能体解释分支、在 GitLab 里跑一串动作。现在状态来自历史，门户显示不一致的地方，智能体去问 MCP，而不是来问我。

我会复用的几条

• 挑出 Git 里那个能当作阶段证据的事件。对我来说是带任务 key 的 MR 合进了 阶段/版本。如果分支是提前建好的，分支存在就不是证据。
• 明确说清还没有证据时怎么办，以及哪些移动算法不建模，比如回退。
• 给智能体一个回答"从哪到哪"的工具，而不是把分支名写进提示词。
• 把停止条件列出来。工具没法给出有依据的答案时，正确动作是停下，不是猜。
• 推进阶段的决定留在人手里，自动化决策之后的动作。