1. 為什么我要自己造一個自動提 PR 的輪子團(tuán)隊里用 Azure DevOps 做代碼托管已經(jīng)兩年多了日常開發(fā)流程里最煩的其實不是寫代碼而是每次改完一堆文件之后那套機(jī)械動作切分支、寫 commit message、push、打開瀏覽器、找到目標(biāo)倉庫、點 New Pull Request、填標(biāo)題、填描述、選 reviewer、關(guān)聯(lián)工作項。一套下來少說五分鐘多的時候十分鐘就沒了而且這十分鐘里你腦子是空轉(zhuǎn)的純純的體力活。一開始我也試過用現(xiàn)成的腳本糊一個比如寫個 bash 把 git 命令串起來再調(diào) Azure DevOps 的 REST API 創(chuàng)建 PR。能用但問題很明顯腳本是死的參數(shù)全靠命令行傳稍微復(fù)雜一點的需求比如根據(jù)改動文件自動推斷 reviewer、根據(jù)分支名自動關(guān)聯(lián)工作項就得改腳本。后來 MCPModel Context Protocol這個概念火起來我意識到這東西天生適合干這種把多個工具串起來、由模型決定調(diào)用順序的活。MCP 本質(zhì)上是一個標(biāo)準(zhǔn)化的協(xié)議讓模型能夠以統(tǒng)一的方式調(diào)用外部工具而 Skill 則是把這些工具能力封裝成模型可以理解和編排的單元。所以這個項目的目標(biāo)就很明確了做一個 MCP 工具把 Git 的本地操作和 Azure DevOps 的遠(yuǎn)端 API 串起來讓模型通過 Skill 編排實現(xiàn)我說一句把這個改動提個 PR它自己把剩下的事全干完。關(guān)鍵詞里的 MCP、Git、Azure DevOps、PR、Skill 這五個詞基本就是這個項目的全部骨架。這篇文章我會把整個實現(xiàn)過程拆開講包括我踩過的坑、為什么這么設(shè)計、以及一些文檔里不會寫的細(xì)節(jié)。先說清楚適合誰看如果你已經(jīng)在用 Azure DevOps 或者類似的代碼平臺日常有大量重復(fù)的提交 PR 操作并且對 MCP 有基本了解哪怕只是聽說過那這篇能直接抄作業(yè)。如果你完全沒接觸過 MCP也沒關(guān)系我會在講實現(xiàn)的時候把必要的背景補上但你需要對 Git 的基本操作和 REST API 的調(diào)用方式有概念。2. 拆解需求這個 MCP 工具到底要解決哪幾件事2.1 把提 PR這個動作拆成原子能力很多人一上來就想做一個一鍵提 PR的大工具我覺得這是錯的。MCP 的設(shè)計哲學(xué)是提供細(xì)粒度的工具讓模型去編排而不是做一個黑盒。所以我先把整個流程拆成了幾個原子操作檢查工作區(qū)狀態(tài)當(dāng)前在哪個分支、有沒有未提交的改動、有沒有未跟蹤的文件。創(chuàng)建并切換分支根據(jù)命名規(guī)范生成分支名比如feature/xxx或fix/xxx。暫存與提交把改動 add 進(jìn)來生成符合規(guī)范的 commit message。推送到遠(yuǎn)端push 到 origin并設(shè)置 upstream。創(chuàng)建 PR調(diào)用 Azure DevOps REST API填標(biāo)題、描述、源分支、目標(biāo)分支、reviewer。關(guān)聯(lián)工作項如果分支名或 commit message 里有工作項 ID自動關(guān)聯(lián)。這六個操作每一個都做成獨立的 MCP tool模型可以根據(jù)實際情況決定調(diào)用哪些、跳過哪些。比如工作區(qū)是干凈的那就不需要 commit直接 push 就行比如分支已經(jīng)存在那就不需要創(chuàng)建。2.2 為什么不讓模型直接調(diào) git 命令有人會問既然模型能執(zhí)行 shell 命令為什么不直接讓它跑git commit -m xxx我試過問題在于不可控。模型生成的命令你沒法保證它每次都正確尤其是涉及路徑、分支名、特殊字符的時候一個引號沒處理好就出問題。而且直接執(zhí)行 shell 命令沒有結(jié)構(gòu)化輸出模型拿到一堆文本還得自己解析容易出錯。做成 MCP tool 的好處是輸入輸出都是結(jié)構(gòu)化的 JSON模型知道每個字段是什么含義調(diào)用之前可以先校驗參數(shù)調(diào)用之后能拿到明確的結(jié)果。比如create_branch這個 tool輸入是{branch_name, base_branch}輸出是{success, branch_name, message}模型一看就知道成沒成。2.3 Skill 在這里扮演什么角色Skill 我的理解是給模型看的使用說明書 編排模板。MCP tool 是能力Skill 是告訴模型在什么場景下、按什么順序、用哪些能力。比如我寫了一個叫auto-pr的 Skill里面描述了標(biāo)準(zhǔn)流程先檢查狀態(tài)再決定是否創(chuàng)建分支再提交再推送最后創(chuàng)建 PR。模型讀到這個 Skill 之后就知道遇到提 PR的請求該按什么套路走。這樣做的好處是流程邏輯不寫在代碼里而是寫在 Skill 的描述里。以后流程要改改 Skill 就行不用重新編譯 MCP server。這也是我覺得 MCP Skill 這套組合最有價值的地方能力與編排分離。3. 環(huán)境搭建Git 與 Azure DevOps 的對接準(zhǔn)備3.1 Git 側(cè)的配置細(xì)節(jié)Git 的安裝和配置網(wǎng)上教程一大堆我就不重復(fù)了只說幾個容易忽略但很關(guān)鍵的點。第一個是用戶身份。MCP server 執(zhí)行 git commit 的時候用的是當(dāng)前系統(tǒng)用戶的 git config。如果你在 CI 環(huán)境或者容器里跑很可能沒配 user.name 和 user.emailcommit 會直接失敗。我的做法是在 MCP server 啟動時先檢查這兩個配置沒有的話就用環(huán)境變量兜底git config --global user.name ${GIT_USER_NAME:-mcp-bot} git config --global user.email ${GIT_USER_EMAIL:-mcp-botexample.com}第二個是憑證管理。push 到遠(yuǎn)端需要認(rèn)證Azure DevOps 支持 PATPersonal Access Token或者 SSH key。我推薦用 PAT因為它在 HTTP 層面工作配置簡單而且可以精細(xì)控制權(quán)限范圍。PAT 的權(quán)限只需要勾選Code (read write)就夠了不要給多余的權(quán)限。第三個是換行符?？缙脚_協(xié)作的時候 CRLF 和 LF 混用會導(dǎo)致整個文件顯示為改動非常煩。建議在倉庫根目錄放一個.gitattributes強(qiáng)制統(tǒng)一* textauto eollf *.bat text eolcrlf3.2 Azure DevOps 的 PAT 與 API 端點Azure DevOps 的 REST API 基地址格式是https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version7.0創(chuàng)建 PR 用 POST請求體大概長這樣{ sourceRefName: refs/heads/feature/xxx, targetRefName: refs/heads/main, title: PR 標(biāo)題, description: PR 描述, reviewers: [ { id: reviewer-uuid } ], workItemRefs: [ { id: 12345 } ] }注意幾個坑sourceRefName和targetRefName必須帶refs/heads/前綴少了會報錯。reviewers里的id是用戶的 UUID不是郵箱也不是顯示名這個 UUID 需要通過 Graph API 查。workItemRefs關(guān)聯(lián)工作項的時候工作項 ID 是字符串不是數(shù)字。PAT 的認(rèn)證方式是 HTTP Basic Auth用戶名隨便填通常填個pat或者空字符串密碼填 PATcurl -u :$PAT https://dev.azure.com/...3.3 MCP Server 的技術(shù)選型MCP server 我選了 Node.js TypeScript原因是官方 SDK 對 TypeScript 支持最好而且 JSON 處理方便。核心依賴就兩個modelcontextprotocol/sdk和simple-git封裝 git 命令。HTTP 請求用 Node 18 自帶的 fetch不需要額外裝 axios。目錄結(jié)構(gòu)大概是這樣mcp-auto-pr/ ├── src/ │ ├── index.ts # MCP server 入口 │ ├── tools/ │ │ ├── git-status.ts │ │ ├── create-branch.ts │ │ ├── commit.ts │ │ ├── push.ts │ │ └── create-pr.ts │ ├── azure/ │ │ └── client.ts # Azure DevOps API 封裝 │ └── config.ts # 配置讀取 ├── skills/ │ └── auto-pr.md # Skill 描述文件 └── package.json4. 逐個實現(xiàn) MCP Tool從 git status 到 create PR4.1 git_status一切判斷的起點這個 tool 的作用是讓模型知道當(dāng)前倉庫的狀態(tài)。返回的信息包括當(dāng)前分支、是否有未提交改動、未跟蹤文件列表、與遠(yuǎn)端的差異。import { simpleGit } from simple-git; export async function gitStatus(repoPath: string) { const git simpleGit(repoPath); const status await git.status(); const branch await git.revparse([--abbrev-ref, HEAD]); return { currentBranch: branch.trim(), isClean: status.isClean(), modified: status.modified, notAdded: status.not_added, created: status.created, deleted: status.deleted, ahead: status.ahead, behind: status.behind, }; }這里有個細(xì)節(jié)status.isClean()只判斷已跟蹤文件的改動未跟蹤文件不算。所以我在返回里單獨列了not_added讓模型自己決定要不要處理。實際用下來模型看到有未跟蹤文件時會主動問用戶這些新文件要不要一起提交這個交互體驗挺好的。4.2 create_branch命名規(guī)范要在這里落地分支命名我定了一套規(guī)范{type}/{workitem-id}-{short-desc}比如feature/12345-add-login。type 可以是 feature、fix、hotfix、chore。export async function createBranch( repoPath: string, branchName: string, baseBranch: string main ) { const git simpleGit(repoPath); // 先切到 base 分支并拉最新 await git.checkout(baseBranch); await git.pull(origin, baseBranch); // 創(chuàng)建并切換到新分支 await git.checkoutLocalBranch(branchName); return { success: true, branchName, baseBranch }; }為什么要先切到 base 再 pull因為如果直接在當(dāng)前分支創(chuàng)建新分支新分支會繼承當(dāng)前分支的狀態(tài)可能包含未推送的提交。先切到 base 并拉最新能保證新分支是從最新的主干切出來的減少后續(xù)合并沖突。注意如果工作區(qū)有未提交的改動checkout會失敗或者把改動帶過去。所以這個 tool 應(yīng)該在git_status確認(rèn)工作區(qū)干凈之后再調(diào)用或者在內(nèi)部先做 stash。4.3 commitmessage 生成與暫存策略commit 這個 tool 我設(shè)計成接收一個 message 參數(shù)而不是讓模型自己拼 git 命令。暫存策略默認(rèn)是git add -A但支持傳入文件列表做精細(xì)控制。export async function commit( repoPath: string, message: string, files?: string[] ) { const git simpleGit(repoPath); if (files files.length 0) { await git.add(files); } else { await git.add(.); } const result await git.commit(message); return { success: true, commitHash: result.commit, summary: result.summary, }; }commit message 的規(guī)范我建議用 Conventional Commits格式是type(scope): subject。這個規(guī)范的好處是機(jī)器可讀后續(xù)可以自動生成 changelog。我在 Skill 里明確告訴模型要按這個格式生成 message實測下來模型生成的質(zhì)量還不錯比如feat(auth): add JWT token refresh logic。4.4 push處理 upstream 和沖突push 看起來簡單其實坑不少。最常見的是新分支沒有 upstream直接git push會報錯。所以要用git push -u origin branchName。export async function push( repoPath: string, branchName: string, setUpstream: boolean true ) { const git simpleGit(repoPath); const options setUpstream ? [-u, origin, branchName] : [origin, branchName]; const result await git.push(options); return { success: true, pushed: result.pushed, branch: branchName, }; }另一個坑是遠(yuǎn)端已經(jīng)有同名分支且歷史不一致。這種情況 push 會被拒絕需要 force push。但 force push 很危險我堅決不在 tool 里提供這個選項。如果遇到這種情況讓模型告訴用戶手動處理這是安全底線。4.5 create_prAzure DevOps API 的封裝這是整個項目最核心的 tool。前面幾個都是本地操作這個才是真正跟 Azure DevOps 打交道的地方。export async function createPullRequest(params: { organization: string; project: string; repositoryId: string; sourceBranch: string; targetBranch: string; title: string; description: string; reviewerIds?: string[]; workItemIds?: string[]; pat: string; }) { const url https://dev.azure.com/${params.organization}/${params.project}/_apis/git/repositories/${params.repositoryId}/pullrequests?api-version7.0; const body { sourceRefName: refs/heads/${params.sourceBranch}, targetRefName: refs/heads/${params.targetBranch}, title: params.title, description: params.description, reviewers: (params.reviewerIds || []).map(id ({ id })), workItemRefs: (params.workItemIds || []).map(id ({ id })), }; const response await fetch(url, { method: POST, headers: { Content-Type: application/json, Authorization: Basic ${Buffer.from(:${params.pat}).toString(base64)}, }, body: JSON.stringify(body), }); if (!response.ok) { const errorText await response.text(); throw new Error(創(chuàng)建 PR 失敗: ${response.status} ${errorText}); } const data await response.json(); return { success: true, pullRequestId: data.pullRequestId, url: https://dev.azure.com/${params.organization}/${params.project}/_git/${params.repositoryId}/pullrequest/${data.pullRequestId}, }; }這里有個細(xì)節(jié)值得說reviewer 的 UUID 怎么來。Azure DevOps 的 Graph API 可以按郵箱或顯示名查用戶GET https://vssps.dev.azure.com/{organization}/_apis/graph/users?api-version7.0返回的是所有用戶列表需要自己過濾。我建議在配置里維護(hù)一個郵箱 → UUID的映射表避免每次調(diào)用都查一遍。這個映射表可以定期更新或者第一次查完之后緩存起來。5. Skill 編排讓模型知道按什么順序干活5.1 Skill 描述文件的結(jié)構(gòu)Skill 文件我用 Markdown 寫因為模型讀 Markdown 最自然。內(nèi)容分三部分適用場景、可用工具、標(biāo)準(zhǔn)流程。# Skill: auto-pr ## 適用場景 當(dāng)用戶要求提交 PR、創(chuàng)建合并請求、把這個改動提上去時使用。 ## 可用工具 - git_status: 檢查工作區(qū)狀態(tài) - create_branch: 創(chuàng)建并切換分支 - commit: 暫存并提交 - push: 推送到遠(yuǎn)端 - create_pr: 在 Azure DevOps 創(chuàng)建 PR ## 標(biāo)準(zhǔn)流程 1. 調(diào)用 git_status確認(rèn)當(dāng)前分支和工作區(qū)狀態(tài)。 2. 如果工作區(qū)不干凈根據(jù)改動內(nèi)容生成 commit message調(diào)用 commit。 3. 如果當(dāng)前在 main 或 develop 等保護(hù)分支調(diào)用 create_branch 創(chuàng)建新分支。 4. 調(diào)用 push 推送當(dāng)前分支。 5. 調(diào)用 create_pr標(biāo)題和描述根據(jù) commit 內(nèi)容生成。 6. 如果分支名或 commit message 里有工作項 ID在 create_pr 時關(guān)聯(lián)。5.2 為什么流程要寫在 Skill 里而不是代碼里這是我在實際使用中體會最深的一點。一開始我把流程硬編碼在 MCP server 里做一個auto_pr的大 tool內(nèi)部按順序調(diào)所有子操作。結(jié)果發(fā)現(xiàn)兩個問題第一靈活性差。有時候用戶只想提交不想提 PR有時候分支已經(jīng)存在不需要創(chuàng)建硬編碼的流程沒法處理這些變體。第二調(diào)試?yán)щy。流程出問題的時候你不知道是哪一步錯了因為所有步驟都包在一個 tool 里。改成 Skill 編排之后模型會根據(jù)實際情況決定調(diào)用哪些 tool。比如它看到工作區(qū)干凈、分支已存在、只是沒推送就會跳過 commit 和 create_branch直接 push 然后 create_pr。這種靈活性是硬編碼給不了的。5.3 處理模型不聽話的情況Skill 畢竟是自然語言描述模型不一定每次都嚴(yán)格照做。我遇到過幾種情況模型跳過了 git_status 直接 commit結(jié)果在有沖突的文件上操作失敗。模型生成的 commit message 不符合 Conventional Commits 格式。模型在保護(hù)分支上直接 commit 而沒有創(chuàng)建新分支。針對這些我的做法是在 tool 層面加校驗。比如committool 內(nèi)部先檢查當(dāng)前分支是不是保護(hù)分支如果是就返回錯誤提示模型先創(chuàng)建分支。create_prtool 校驗 sourceBranch 和 targetBranch 不能相同。這樣即使模型編排出錯tool 層面也能兜住。提示Skill 是軟約束tool 的參數(shù)校驗是硬約束。兩者結(jié)合才能保證流程可靠。6. 實測中踩過的坑與排查過程6.1 push 報 ssh認(rèn)證失敗 的排查第一次跑通流程的時候push 一直失敗報的是 SSH 認(rèn)證錯誤。我一開始以為是 key 沒配好折騰了半天。后來發(fā)現(xiàn)根本原因是倉庫的 remote URL 是 SSH 格式但我的 PAT 是給 HTTP 用的。排查過程是這樣的先git remote -v看 remote URL發(fā)現(xiàn)是gitssh.dev.azure.com:...這種格式。SSH 格式走的是 SSH key 認(rèn)證跟 PAT 沒關(guān)系。解決辦法有兩個要么配 SSH key要么把 remote URL 改成 HTTPS 格式。我選了后者因為 PAT 管理起來更方便git remote set-url origin https://dev.azure.com/{org}/{project}/_git/{repo}改完之后 push 就正常了。這個坑的教訓(xùn)是PAT 和 SSH key 是兩套認(rèn)證體系不能混用。用 PAT 就必須走 HTTPS。6.2 PR 創(chuàng)建成功但 reviewer 沒加上有幾次 PR 創(chuàng)建成功了但 reviewer 列表是空的。查了 API 返回發(fā)現(xiàn) reviewers 字段被忽略了。原因是傳的 UUID 格式不對。Azure DevOps 的 reviewer id 必須是完整的 UUID 格式比如a1b2c3d4-e5f6-7890-abcd-ef1234567890少一段或者格式不對都會被靜默忽略。排查方法是在創(chuàng)建 PR 之后再調(diào)一次 GET 接口查 PR 詳情看 reviewers 字段是不是空的。如果是空的就說明 id 有問題。我后來在代碼里加了一個校驗UUID 必須匹配正則^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$不匹配的直接報錯不靜默忽略。6.3 工作項關(guān)聯(lián)失敗的幾種情況關(guān)聯(lián)工作項也踩過坑。有一次傳了工作項 ID但 PR 創(chuàng)建后工作項沒關(guān)聯(lián)上。查下來發(fā)現(xiàn)是工作項 ID 傳成了數(shù)字類型而 API 要求字符串。改成字符串之后就好了。還有一種情況是工作項不存在或者沒權(quán)限訪問。這種 API 會返回 400但錯誤信息很模糊只說 Invalid work item reference。我的處理方式是在關(guān)聯(lián)之前先調(diào)工作項的查詢接口確認(rèn)存在不存在就跳過關(guān)聯(lián)并在返回里提示。6.4 大文件導(dǎo)致的 push 超時有一次提交了一個幾十 MB 的二進(jìn)制文件push 卡了很久最后超時。這個問題的根源是倉庫里不應(yīng)該有大文件。我的處理方式是在committool 里加一個文件大小檢查超過 10MB 的文件給出警告超過 50MB 直接拒絕提交。const MAX_FILE_SIZE 50 * 1024 * 1024; // 50MB // 在 add 之前遍歷文件檢查大小這個閾值可以根據(jù)團(tuán)隊實際情況調(diào)整。如果確實需要管理大文件應(yīng)該用 Git LFS而不是直接提交到倉庫。7. 一些讓工具更好用的經(jīng)驗補充7.1 配置文件的設(shè)計我把所有環(huán)境相關(guān)的配置抽到一個config.json里包括 organization、project、repositoryId、PAT、reviewer 映射表、保護(hù)分支列表。這樣換一個項目只需要改配置不用動代碼。{ organization: my-org, project: my-project, repositoryId: my-repo, pat: ${AZURE_DEVOPS_PAT}, protectedBranches: [main, develop, release/*], reviewerMap: { aliceexample.com: uuid-1, bobexample.com: uuid-2 } }PAT 用環(huán)境變量占位符避免明文寫在配置文件里。啟動時做一次替換。7.2 日志與可觀測性MCP server 跑在后臺出問題的時候如果沒日志會很難查。我在每個 tool 的入口和出口都加了日志記錄輸入?yún)?shù)、執(zhí)行結(jié)果、耗時。日志寫到文件里按天切割。logger.info(create_pr called, { sourceBranch, targetBranch, title }); const start Date.now(); // ... 執(zhí)行 logger.info(create_pr completed, { pullRequestId, duration: Date.now() - start });有了這些日志排查問題的時候直接看日志就行不用復(fù)現(xiàn)。實測下來90% 的問題看日志就能定位。7.3 冪等性處理網(wǎng)絡(luò)抖動或者超時的時候模型可能會重試。如果 create_pr 被調(diào)用了兩次會創(chuàng)建兩個重復(fù)的 PR。所以我在 create_pr 里加了冪等檢查先查一下源分支有沒有已經(jīng)打開的 PR有的話直接返回那個 PR 的信息不重復(fù)創(chuàng)建。GET .../pullrequests?searchCriteria.sourceRefNamerefs/heads/{branch}searchCriteria.statusactive這個查詢返回當(dāng)前分支所有活躍的 PR如果有就直接復(fù)用。這樣即使重試也不會產(chǎn)生重復(fù) PR。7.4 關(guān)于 Skill 的版本管理Skill 文件我放在 git 倉庫里跟代碼一起管理每次改 Skill 都走正常的 PR 流程。這樣做的好處是 Skill 的變更可追溯出問題可以回滾。另外我在 Skill 文件頭部加了一個版本號方便排查模型用的是哪個版本的 Skill。!-- skill-version: 1.2.0 --模型讀到這個版本號在日志里也會帶上排查問題的時候能對應(yīng)上。8. 關(guān)于這套方案的一些個人體會這套東西跑了大半年團(tuán)隊里現(xiàn)在提 PR 基本都是一句話的事。我最大的體會是MCP Skill 這套組合的價值不在于自動化而在于可編排。傳統(tǒng)的腳本自動化是線性的、固定的而 MCP 讓模型根據(jù)上下文動態(tài)決定調(diào)用哪些能力這才是它真正區(qū)別于腳本的地方。另一個體會是安全邊界一定要在 tool 層面守住。Skill 是給模型看的模型可能理解偏差但 tool 的參數(shù)校驗是代碼是確定性的。force push、刪除分支、修改保護(hù)分支這些危險操作我堅決不在 tool 里提供從源頭上杜絕誤操作。最后說一個我覺得后續(xù)可以擴(kuò)展的方向現(xiàn)在 reviewer 是根據(jù)配置文件靜態(tài)映射的其實可以根據(jù)改動的文件路徑動態(tài)推斷。比如改了src/auth/下的文件就自動找 auth 模塊的負(fù)責(zé)人。這個邏輯可以做成一個獨立的 tool讓 Skill 在創(chuàng)建 PR 之前調(diào)用。不過這個需要維護(hù)一份路徑 → 負(fù)責(zé)人的映射團(tuán)隊規(guī)模小的時候可能不劃算規(guī)模大了就很有價值。