iT邦幫忙

2026 iThome 鐵人賽

DAY 27
0
Vibe Coding

老闆不會教你的 Vibe Coding 實戰 30 天系列 第 27 篇

老闆不會教你的 Vibe Coding 實戰 30 天|Day 27:PR 流程與 CodeRabbit 自動審查

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20261009/20119486IYmOpE14kF.png

前言

昨天我們快速複習了一下把「預算提醒」這個功能從原本的「不做清單」移出來,然後用 Plan Mode 做了計畫、實作,最後 push 到 main 讓 GitHub Actions 自動部署上線。

但接下來我要來聊一下更正式的一套開發流程,也就是所謂的 PR(Pull Request)流程。

簡單來講,讓我們的系統上傳到 main 被部署之前,可以先經過一些方式來檢查這次的改動,確保不會把線上弄壞,而且這過程是自動的。

什麼是 PR?

Day 25 的時候我有稍微提到分支(Branch),當時儘管我說先不用理解,但這邊我們就要來花點時間理解一下了。

首先在一個正確開發的流程中,我們會把正式環境與開發環境分開:

  • 正式環境: 就是 main 分支,這個分支一 push 就會自動部署到正式網址,也就是對外公開的環境,所以一旦公開就是面向使用者。
  • 開發環境: 就是 develop 分支,這個分支不會自動部署到正式網址,主要是給開發者做測試、驗收、修 bug 的地方。
  • 分支(Branch): 就是從 main 或 develop 分出來的一個副本/草稿,這個草稿可以讓你在上面做改動、測試、驗收,而不會影響到 main 或 develop,常見有 feature 分支、bugfix 分支、hotfix 分支等等。

所以今天開始也會把記帳 App 依照這個流程跑,每次要改任何東西都要從 develop 開一個分支出來,改完先合併回 develop,再測試機測試都沒問題了,再從 develop 合併到 main 上線。

那...什麼是 PR(Pull Request)呢?

簡單來講,你把它理解成一張申請單,意思是我想把這份草稿(feature branch)合併進 develop(或是把 develop 合併進 main),然後這個申請單可能會有一些檢查項目,例如:

  • 自動測試:這次的改動有沒有破壞到原本的功能。
  • AI 審查:這次的改動有沒有安全疑慮、程式碼品質有沒有問題。
  • 人工審查:這次的改動有沒有符合團隊的規範、程式碼風格有沒有問題。

所以我們這邊就是要加上這一個流程,而加上這個流程後,整體就會像這樣:

https://ithelp.ithome.com.tw/upload/images/20261009/20119486eML4f8a3qN.png

初步了解之後,我們就要來導入 CodeRabbit 這個 AI Code Review 服務,讓 PR 一開就自動審查並用中文留言給我們~

CodeRabbit

前面所講的 CodeRabbit(程式碼兔子)是什麼呢?簡單來講,它是一個 AI Code Review 的服務,只要你把它安裝到你的 GitHub 儲存庫之後,之後特定 PR 被開啟,那 CodeRabbit 就會自動幫你審查這次的改動,並且直接在 PR 上面留言。

那......CodeRabbit 身為一個 AI Code Review 服務,不可能是完全免費的吧?畢竟我們前面一直有提到過 AI 最貴的就是「算力」。

所以一點也沒有錯,CodeRabbit 是有付費方案的,而且是依照開發者人數並按月計算,而 Essentials(基本) 方案是每人每月 30 美元(年繳的話是 24 美元)。

不過它對公開的儲存庫是非常大方的,只要你的儲存庫是公開儲存庫,安裝之後就可以免費使用 PR Code Review,也不需要綁定信用卡,但反之,如果是私人的儲存庫,免費方案就只會幫你做 PR 摘要,真正的逐行 Review 就要付費了。

剛好,我們這個 money-note 專案是屬於公開性質,所以就可以直接示範使用。

Note
許多服務免費方案都是建立在開源專案的基礎上,因為開源專案對社群有正面貢獻,所以才會有免費方案,這也是我們這個專案選擇公開儲存庫的原因之一。
而廠商主要賺取的使用者則是付費方案的私人儲存庫,因為這些私人儲存庫通常是商業用途,對廠商來說才有價值,也比較願意付費。

那為什麼 Day 19 已經有 code-reviewer 這個指令了但我們卻還需要使用 CodeRabbit 呢?

因為 code-reviewer 必須你去叫它才會做事,而 CodeRabbit 是掛在 GitHub 上的,只要開 PR 就會自動跑,所以一整套開發流程並搭配前面學的 Hook、CLAUDE.md 之後留成就會有這每一段流程:

https://ithelp.ithome.com.tw/upload/images/20261009/201194865HUeLoT3Z3.png

你可以看到 Review 這件事情一直在我們的流程中,從本機的 code-reviewer 到 GitHub 上的 CodeRabbit 都有,這樣就可以確保每一次改動都經過檢查。

所以講了那麼多,我們該怎麼做呢?很簡單:

  1. 打開 CodeRabbit 官網,點選 Log In,然後點選 Login with GitHub,接著按下 Authorize coderabbitai 授權。
  2. 選擇要安裝到哪個帳號,這邊選你自己的 GitHub 帳號。
  3. 按下 Install & Authorize 就完成了。

https://ithelp.ithome.com.tw/upload/images/20261009/20119486cTkvISVOCo.png

請 AI 加上設定

接下來呢?我們試著開一個 PR,看看 CodeRabbit 會不會自動審查。

但開始之前,我們要來做一些事情,也就是把 .coderabbit.yaml 這個設定檔加到專案裡,這個檔案主要是設定 CodeRabbit 的審查語言、要審查哪些分支等等。

一樣交給 AI 就可以了,請你輸入 /clear 清空對話,接著輸入以下 Prompt:

我要幫這個專案加上 PR 流程,main 是正式環境,develop 是開發環境,請幫我做四件事:

1. 新增 .github/workflows/test.yml,有 PR 要合併進 develop 或 main 的時候,自動跑 npm ci、npm test、npm run build。
2. 新增 .coderabbit.yaml,把審查的語言設定成 zh-TW,並且讓 PR 合併進 develop 的時候也會自動審查。
3. 在 CLAUDE.md 補上規則:以後的改動一律從 develop 開分支、push 分支、開 PR 合併回 develop;要上線時再開 develop → main 的 PR;不要直接 push 到 develop 或 main。
4. 以上做完請 commit 並 push 到 main,這是最後一次直接 push;接著從 main 建立 develop 分支並 push 上去。

https://ithelp.ithome.com.tw/upload/images/20261009/20119486x0KCLyZHFb.png

接著就可以試著建立一個 PR 看看啦~

第一個 PR

CodeRabbit 準備好了,當然要來試著觸發看看,請你輸入 /clear 清空對話,接著輸入以下 Prompt:

請從 docs/TODO.md 挑一個最小、風險最低的需求來做。

製作時,務必遵守 CLAUDE.md 的新規則,從 develop 開一個新的分支來做,做完跑過 npm test 之後 commit,然後 push 這個分支,不要動 develop 跟 main。

push 完之後回到 GitHub 的儲存庫頁面,建立一個 PR,然後稍微等一下你就可以看到 CodeRabbit 自動跑測試、審查,並且在 PR 上留言了~

https://ithelp.ithome.com.tw/upload/images/20261009/20119486zA3bow0i8o.png

這邊也提供範例 PR 給你參考:範例 PR

除此之外,GitHub 本身也有提供額外免費的 Code Review 服務,你只需要在 PR 旁邊的 Reviewers 欄位加上 Copilot 就可以了,這樣 Copilot 也會幫你審查程式碼~

https://ithelp.ithome.com.tw/upload/images/20261009/20119486EEIzo9ouBB.png

試試看:Actions 亮紅燈的時候怎麼辦?

那......到現在基本上都是示範,成功的案例,這樣其實很難看出到底這些東西有沒有效果。

所以我想留個小功課給你,讓你自己試著回去觸發這些 Actions 的錯誤。

你只需要請 AI 在分支上把 formatAmount 輸出的 $ 拿掉,不跑測試直接 push,就可以能看到 Actions 失敗狀況了,這部分我就不示範了,就讓你回家試試看囉~~

CodeRabbit 的留言怎麼處理?

測試過了,那 CodeRabbit 留的那些言呢?

給你一個核心大方向,CodeRabbit 在給建議時,會給高、中、低三個等級的建議,你主要需要專注的點是高跟中,低的部分則可以跟 AI 討論看看是否為必要修正。

因為有些時候 AI 會太過敏感,像是你在程式碼裡面有一個 console.log,CodeRabbit 可能就會建議你把它拿掉,但這個 console.log 可能是你在做測試時需要的,所以這種情況就可以不用理會。

那要怎麼給 AI 去修正 CodeRabbit 的建議呢?幾種方式:

  • 手動複製 CodeRabbit 留言的內容,貼給 AI,請它幫你修正。
  • 叫 AI 直接去看 CodeRabbit 留言的內容,要搭配 Claude in Chrome 套件。

以我自己來講,我就比較常用後者。

結語

那這一篇也差不多了,也來總結一下:

  • 正式環境(main)跟開發環境(develop)要分開,每次改動都從 develop 開分支,先合併回 develop,確認沒問題再從 develop 合併到 main 上線。
  • PR 就是一張申請單,改動要進 develop 或 main 之前,都要先經過自動測試跟 AI 審查這些檢查。
  • CodeRabbit 對公開儲存庫是免費的,而且它掛在 GitHub 上,只要開 PR 就會自動審查,不像 code-reviewer 要你記得去叫它。
  • 除了 CodeRabbit,GitHub 也可以在 PR 的 Reviewers 加上 Copilot,多一個 AI 幫你看程式碼。
  • CodeRabbit 的建議不用全部照修,主要專注在高跟中等級的建議,低等級的可以跟 AI 討論看看是不是真的需要修。

最後也別忘了回去做一下小功課,親手讓 Actions 亮一次紅燈唷。


上一篇
老闆不會教你的 Vibe Coding 實戰 30 天|Day 26:上線後的第一次改版
下一篇
老闆不會教你的 Vibe Coding 實戰 30 天|Day 28:Week 4 收尾之 Token 怎麼省
系列文
老闆不會教你的 Vibe Coding 實戰 30 天 共 28 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言