以前我們也是等一批 Ticket 做完，才坐下來一起 review。

結果就是：Review 的時候發現第一個 Ticket 的架構方向有問題，接下來五個都是建在那個錯誤上面。這時候修正成本已經是即時發現的六到十倍，開發者剛花了三天卻要整個打掉，士氣很難不崩。

後來我們設計了「即時 Review 機制」，核心就一句話：Ticket 完成就 Review，不累積。

三個原則

即時觸發。Ticket 完成的當下就觸發，不是等 Wave 結束，不是等今天收工。錯誤的架構決策會在下一個 Ticket 開始前就污染後續設計，等不起。

30 分鐘完成。這個時間限制是設計訊號：如果一個 Ticket 的 Review 超過一小時，代表那個 Ticket 太大，應該在規劃時就拆。

標準清單。16 項固定檢查項，分功能正確性、架構合規性、測試通過率、文件同步性四類。不管誰 Review、什麼時間點，標準都一樣。

怎麼跑

觸發：完成實作、驗收條件全滿足、測試 100% 通過、靜態分析零錯誤，狀態標為「Review 中」。

執行：30 分鐘內跑完 16 項。功能正確性（10 分鐘）、架構合規性（8 分鐘）、測試通過率（5 分鐘）、文件同步性（2 分鐘），最後 5 分鐘記錄結果。

偏差糾正：發現問題就照固定流程走——暫停、記錄根因、建修正 Ticket、執行、再 Review。流程結構化是關鍵，「發現問題不知怎麼辦」是問題被忽略的主因。

問題分三級

P0（阻塞）：功能錯誤、架構偏差、測試失敗。必須在 Review 通過前修正。

P1（重要）：邊界處理缺失、文件不完整。建 Ticket 追蹤，當前 Ticket 可先通過。

P2（建議）：命名改善、程式風格。記錄即可。

分級的目的：Review 保持快速，重要問題不被跳過。

超時是訊號

Ticket 完成後 2 小時內開始 Review，目標 30 分鐘，最長 1 小時。超時代表 Ticket 範圍太大，不是 Reviewer 的問題。這個標準幫助我們持續校正 Ticket 的粒度。

最明顯的變化

導入前，「Review」這件事是模糊的——知道應該做，但時機不固定、標準不一、出了問題也不清楚怎麼處理。

導入後，偏差被控制在單一 Ticket 的範圍內，沒機會擴散。另一個意外收穫是，16 項清單讓我們對「品質」有了共同語言，Review 結果可以比較、可以追蹤，不再靠個人感覺。

即時 Review 的目的是把修正成本壓到最低。問題在最小範圍被抓到，代價才會真的小。