回列表
AI 程式碼審查流程
山葵組在自家開發流程導入 AI 程式碼審查：每個 GitLab Merge Request 依該專案的審查規則自動檢查，產出結構化的問題清單與分數，並與審查單、任務狀態串接。AI 負責第一輪檢查，最後由審查人決定是否通過。
從原本到改成
Before / After
案例背景山葵組做了什麼
審查人要逐行看完整份變更
AI 先做第一輪檢查，列出問題與位置
審查標準因人而異
依各專案的審查規則檢查
MR、審查意見與任務狀態分散各處
審查單串起 MR、討論與任務
修改後重審要從頭看一次
只審新提交，並追蹤上一輪的問題
指標功能
依專案規則審查
每個專案有自己的審查規則文件，規則可標註適用的路徑，例如資料庫遷移、排程指令。AI 只取與本次變更相關的段落來審查，重點更集中，也能控制成本。
結構化問題清單與分數
輸出固定為結構化格式：每個問題的檔案、嚴重程度與修正建議。分數由程式依問題清單計算，避免分數與列出的問題對不上。
增量審查與問題追蹤
修正後再送審，只檢查新的提交，並逐項判斷上一輪的問題是否已解決；審查規則更新時則整份重審。
大型變更分段處理
送審前先估算變更大小，過大時依路徑分段審查再合併結果。產生檔與鎖定檔自動略過，看不到內容的檔案會明確列出，不讓 AI 推測。
審查單與任務串接
一張審查單可關聯多個 MR，GitLab 的開啟、推送與合併狀態自動同步。審查狀態（開發中、送審、要求修改、通過、已合併）反映到對應任務，審查結束前任務不會被視為完成。
人工把關與紀錄
AI 審查結果提供審查人參考，最後由審查人決定通過或要求修改。每一輪送審、審查與討論都留下紀錄。
導入 AI 審查的設計原則
- 輸出結構化，分數由程式計算：問題清單固定格式，分數依清單推算，結果可比較、可追蹤。
- 規則依路徑取段，只送相關內容：避免把整份規則與無關的程式碼一起送出，降低干擾與成本。
- 先估算再呼叫，看不到的不猜：過大的變更分段或拒絕，缺少內容的檔案明確標示，交給審查人判斷。