示波器即使探棒接在你想觀測的點以外的位置,也能顯示出完全正常的波形。QA 測試也會造成同樣的假信心:綠燈只證明該行程式碼被執行過——不一定代表該行為已被驗證。

AI 可以在幾秒鐘內起草一段程式碼變更,但速度並不能免除問責的需要。當 AI 生成的程式碼進入審查階段時,重要的問題不只是 「有沒有測試?」 而是 「這些測試是否證明了重要的行為仍然正常運作?」

這個區別很重要,因為綠燈的 CI 流水線所創造的信心,可能超過證據本身應得的程度。一個測試可以在實質上未驗證其結果的情況下執行被修改的那一行。程式碼覆蓋率告訴我們執行軌跡經過了哪裡;驗收證據告訴我們它是否抵達了正確的目的地。

情境

想像 Aurora Shop 的折扣模組。它的業務規則很簡單:當顧客同時符合購物車滿額折扣與會員折扣的資格時,系統會套用兩者中折扣較大的那一個——絕不同時套用兩者。在整理這個模組時,一位 AI 程式助理開啟了一個「折扣計算修正」。它將兩層巢狀的 if 區塊替換為計算兩種折扣並選取最大值的邏輯。

這個重構看起來更乾淨。現有的測試是綠燈。但這兩個事實都不能證明業務規則被保留下來。

假設現有的測試套件分別測試「一般顧客獲得購物車折扣」與「會員獲得會員折扣」。這兩個測試依然通過。缺少的正是促成這條規則的情境:一位同時符合兩種折扣資格的顧客。如果沒有任何斷言驗證「只套用較大的折扣」,CI 可以在最重要的行為實際上未被測試的情況下,依然完全綠燈。

這正是為什麼 AI 協助變更的作者需要交付 可審查的證據,而不只是能運作的程式碼。

AI 產出驗收清單

表格中的驗收清單提供了一個實用的架構。首先,作者應該描述行為差異:哪些輸入到輸出的對應關係改變了,以及哪些必須保持不變。審查者接著就能將該描述與 diff 直接比對。如果描述說這次變更只是重組折扣選擇的邏輯,但 diff 同時也改動了捨入或資格判斷的邏輯,這種不一致就值得深入調查。

接下來是風險證據。作者不應只說*「應該沒問題吧」*,而應該指出最可能出錯的地方。對 Aurora Shop 而言,那可能是兩種折扣金額相等的案例、其中一種折扣為零、負數或無效金額進入計算,或是異常大的購物車觸及上限邊界。這些不是隨機添加的額外測試;它們挑戰的是新實作所引入的假設。

作者也應該記錄被否決的替代方案,並提供測試證據。一個特別有力的錯誤修復測試,應該會因為修復所宣稱要解決的原因而在舊實作上失敗,然後在變更之後通過。如果新測試在所謂有問題的程式碼上也通過,審查者就有充分的理由追問:這個測試究竟證明了什麼。

值得注意的是,審查者不需要為了建立信心而把鍵盤從作者手上拿走。作者可以提供實作與測試,而審查者則獨立檢視 diff、重跑一個有意義的邊界案例、檢查 commit 歷史,並詢問哪些分支仍然未被測試。這樣既保留了所有權,又讓證據能被獨立挑戰。

表格中最後關於覆蓋率說明的警告特別重要。「95% 覆蓋率」聽起來很亮眼,但並未透露遺漏的是哪 5%——或者被覆蓋的 95% 是否包含有意義的斷言。對 Aurora Shop 的這次變更而言,知道折扣函式被執行過,比不上知道測試明確示範了:購物車折扣較大時勝出、會員折扣較大時勝出、折扣相等時不疊加,以及相關邊界依照規格運作。

這就是測試存在與重要行為被測試之間的差別。

當 AI 參與程式碼撰寫時,審查因此應該變得更加以證據為導向,而不是更少。作者應該交付行為變更、識別出的風險、被否決的做法、展示這次變更的測試、有意義的邊界案例,以及明確的覆蓋率缺口。審查者接著將這些成果作為驗收證據來評估。

那麼,我為什麼應該簽署一份 AI 起草的 PR?

不是因為 AI 產出了乾淨的程式碼、覆蓋率百分比提升了,或 CI 轉為綠燈。我應該簽署它,是因為這些證據讓我能獨立理解:改變了什麼、可能出什麼錯、哪些邊界被挑戰過,以及測試究竟證明了什麼。簽署一份 PR 意味著接受變更背後的推理,而不只是信任創造它的工具。AI 或許可以起草程式碼,但信心仍然必須透過人類審查者能夠質疑、重現與捍衛的證據來贏得。