在軟體開發的 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的...