在軟體開發的 PR 流程中,與 AI 工程師一同協作

開場

去年在 DevOps Days Taipei 研討會中,我有分享過類似的概念,當時我還無法實現。而且我覺得當時我提出這個想法的時候,很多現場聽眾目光裡閃爍著的,其實是略帶懷疑的眼神。

什麼概念呢?
我一直希望,能不能在 PR 過程中,Reviewer 只要寫下 Comment,就能有個 AI 工程師在背景直接幫我們改 code? 或是能有一個夜班的 AI 工程師,可以隨時待命,接手白天人類的工作,在晚上完成一些例行性的任務。

現在,這個夢想終於實現了。而且比我想像的還要好用。

讓我們先聊聊 Git 版控時的 PR 流程。如果你有再用 Git 做團隊開發,我相信你一定知道 Pull Request 是整個開發協作的核心。開發者提交程式碼、reviewer 進行逐行檢查、留下 comment、來回討論、最後 approve 或是 request changes。這個流程很務實,也很必要。

但一直有一個問題。

不知道你有沒有算過,從 reviewer 在 PR 上留下 comment,到開發者真正動手修改,中間會經過多久時間?

有時候是幾小時(如果大家都很閒),有時候是一整天(因為有會議、或其他工作),有時候甚至會拖到一兩天(可能是 Developer 沒收信、甚至根本是單純忘了上去看)。這段時間,PR 就這樣卡在那裡,什麼都不能做。CI/CD pipeline 也只能乾等。

更煩的是,有時候那些 comment 其實都是些「小修改」:改個函示名稱、加個錯誤處理、調整一下格式、補個註解。這種事情,說難不難,但要開發者停下手邊的工作、重新進入 context、再去改這些小東西,說實話,挺浪費時間的。

所以我一直覺得:如果可以讓 AI 先做初步修改呢? 那會如何?

主要不是為了取代開發人員,而是在 reviewer 提出建議後,讓 AI 先試著去處理那些「機械性」的修改。再由人類負責審核、判斷、給建議;AI 負責執行、修改、產出結果。這不是挺完美的分工嗎?

實際操作

好,概念介紹完畢,來看看實際上如何運作。

假設今天有個 PR,reviewer 檢查後發現了一些需要改進的地方。就像平常一樣,在程式碼旁邊留個 comment。可能是「AI: 這一段應該要加上錯誤處理或Log」、「AI: 這個OOO變數名稱不夠明確」、「AI: 請加上OOO的單元測試」之類的。

圖片

就是這麼單純。跟平常的 comment 差不多,沒有什麼複雜的指令或格式。寫完之後,按下送出。

接著觸發一個 Azure DevOps Pipeline。
圖片

在這個 pipeline 裡面,我們放置了一個個特別的 task。這個 task 會啟動我們的 AI 工程師。沒錯,就是 GitHub Copilot CLI

它能做什麼呢?它會:

  1. 讀取 reviewer 寫給 AI 的 comment (有 AI: 開頭的)
  2. 理解 comment 的意圖
  3. 分析相關的程式碼
  4. 根據建議進行修改
  5. 產出一份詳細的報告

整個過程大概需要幾十秒到幾分鐘,取決於修改的複雜度。

但重點是,這些都是自動完成的。你可以去泡杯咖啡,或是繼續做其他事情。

等 AI 工程師完成工作後,它會把結果提交到分支上。並且在原本的 comment 底下回覆一個詳細的修改報告。

圖片

這份報告裡面會告訴你:做了哪些修改、為什麼這樣改、有沒有遇到什麼問題、甚至建議的下一步。你可以檢查這些修改是否符合預期,如果 OK ,就直接採用,如果不 OK 就可以提出更具體的修改建議,讓 AI 再改一次。

說實話,我第一次讓這個流程跑起來的時候,內心是充滿激動的。至少我證明了,前兩年在研討會提到的想法是可行的。

討論

這樣的流程對開發團隊的幫助能有多大?

過去,一個 PR 從 reviewer 提出建議到開發者實際修改,可能要等 4-6 小時(如果中間有任何的人為疏忽或忙碌到無法看信件,可能就會等到隔天)。現在,這個等待時間縮短到幾分鐘。更重要的是,Reviewer 可以更快的看到修改結果,進而加快整個開發流程。

而且,AI 工程師不會累、不會抱怨、不會因為「只是小修改」而覺得浪費時間、沒有 context switch 的問題。它就是持續地把工作做完,然後提交報告。對於那些重複性高、規則明確的修改任務,它的表現可能比人類還要穩定。

這裡,有個最近這兩年你必須開始思考的議題。

這些流程並非旨在取代人類開發者,但確實是在重新定義了人類與機器的協作的方式。過去,code review 是「人對人」的同步協作;現在,它變成了「人類智慧 + AI 執行力」的混合模式。Reviewer 專注於架構設計、邏輯判斷、商業價值;AI 負責處理那些瑣碎但必要的細節。

當 AI 可以處理越來越多的「機械性工作」時,人類開發者應該把時間花在哪裡?答案很明顯👉更有價值的思考和決策。設計更好的架構、解決更複雜的問題、創造更有意義的產品。

當你下次在 PR 上留 comment 的時候,可以試著想像:如果現在有個 AI 工程師可以立刻開始處理,會是什麼樣的感覺?

我想,這確實是軟體開發流程的一大變革。
而似乎,這一切才剛剛開始而已。


具體的 Pipeline 配置和使用方式,可以參考底下:
https://studyhost.blogspot.com/2025/10/ado-coding-agent-pipeline-ai-agent.html

影片說明:

留言

這個網誌中的熱門文章

在 ADO Pipeline 中使用 GitHub Copilot CLI:實現全天候24h開發的夢想

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

原來使用 .net 寫個 MCP Server 如此簡單

VS Code的字體大小