如何透過代理進行程式碼審查

想像一個購物清單頁面：能打開，可以新增項目，按鈕看起來也正常。但畫面能用，不代表程式碼裡的每件事都想清楚了。開發者會另外安排時間檢查程式碼，找出漏掉的錯誤，並討論當初的做法。這項工作可以交給代理，它能做得很好。只是得先向它把任務說清楚。

1. 團隊如何審查程式碼

在一個小團隊裡，一位開發者接到任務：做一個購物清單，可以新增項目，也能逐筆刪除。他寫好程式碼，試著加入麵包和牛奶，再刪掉麵包。一切正常。在把工作交出去之前，他又把自己的修改重讀一遍：拿掉一段忘了刪的程式碼，改掉一個看不懂的名稱。這就是自我檢查。

接著他請同事看看程式碼。同事懂這門程式語言，會去讀：新增是怎麼實作的、程式怎麼挑出要刪除的記錄、清單裡其他項目會發生什麼事。這種檢視稱為程式碼審查，也就是 code review，負責檢查的人則稱為審查員。

同事發現：程式是依名稱挑選要刪除的購物項目。如果清單裡有兩筆"牛奶"，點其中一筆可能會把兩筆都刪掉。作者測的是麵包和牛奶。這種情況他只是剛好沒碰到。

審查員在對應的程式碼旁留下意見："現在會刪掉所有同名的購物項目。我們允許重複的記錄嗎？如果允許，就應該只刪除選取的那一筆"。作者釐清了需求：重複記錄是允許的，因為可能是替不同的人加的。討論之後，他改了挑選記錄的方式。同事再看一次修正，確認意見已經處理好了。

圖中是一輪有意見的審查：程式碼從作者交到同事手上，再退回去修正。如果再看一次後還有疑問，就重複討論和修改。等到沒有實質性的意見，同事就核准這次變更。

這就是一般的工作循環：寫好、給人看、收到意見、討論、修正。有時意見好幾條，有時一條也沒有。也有作者說明了自己的做法，同事就撤回問題的情況。審查並不要求接受每一條意見。

這樣的審查也會討論程式碼好不好懂：下一位開發者能不能看懂，改一條規則是不是得動好幾個地方。同事也順便了解程式新增的部分是怎麼構成的。對專案的了解就這樣慢慢分散到不同人身上，而不是只留在作者一個人手裡。

這裡很容易把審查和測試搞混。一個人加入兩個購物項目再按下按鈕，是在檢查執行中程式的行為。讀刪除相關的程式碼，弄清楚它會挑出哪些記錄，則是在做審查。審查時也可以執行程式來驗證猜測。這兩種方法是互補的。

2. 如何將程式碼審查委託給代理

現在想像購物清單是 Claude Code 依照您的描述寫出來的。您說得出頁面上應該發生什麼，但看不懂它的程式邏輯。審查中技術的部分也可以交給代理：它會讀檔案，再用白話解釋意見。

團隊故事裡的角色照樣存在。有程式碼的作者，也有另外接到任務的審查員。在 Claude Code 中，您可以用子代理來做這件事：它是一個助手，主代理把具體的工作交給它。在我們的例子裡，它負責讀程式碼並回報意見。

請作者再檢查一次自己的成果也有用。獨立的審查員則帶來另一種視角：他接到的任務就是評估結果。把需求交給他，讓他知道哪些做法是可以接受的。例如，禁止重複的購物項目，形式上能消除刪除的問題，卻會改變頁面原本預期的行為。

Claude Code 的審查建議提到，要安排獨立的審查員並給出明確的標準。同一份建議也提醒，把重點放在影響功能正確性和需求的意見上。我們把這套做法套用到專案的一小部分。

要安排一次審查，您要做的事不多：描述期望的行為，再選出要修正哪些已確認的問題。讀程式邏輯、找原因、分析技術上的反對意見，這些都可以交給代理。

圖中有三種角色：您設定需求並決定要改什麼，主代理安排工作並修正程式碼，審查員負責研究程式碼和意見。主代理把需要的資料交給他們，再把結果帶回給您。如果沒有已確認的問題，修正的步驟就略過。下面用三個請求走完這個流程。

最後您會拿到三樣東西：一份看得懂的問題說明、複查的結果，以及修正報告。就算某條意見最後證明是錯的，也不算白忙：您避開了一次不必要的修改。

如果您想為這類審查設定一個固定的助手，可以參考建立並啟動子代理的教學。至於怎麼替它準備更詳細的任務說明，請看關於任務說明和結果格式的文章。

請求 1. 檢查寫好的程式碼

在專案資料夾中啟動 Claude Code。接下來三個請求都送到主工作階段：由主代理自己把工作轉交給助手。這裡和後面都用教學用的購物清單當例子；換成您的專案時，請改寫行為描述。

請一個獨立的子代理審查目前專案中
購物清單的程式碼。檢查新增和刪除記錄。
需求：允許重複的名稱；只刪除
選取的那一筆記錄；不能新增空白的購物項目。

閱讀目前的程式碼和專案中相關的部分。
找出違反這些需求的錯誤。
不要修改程式碼。不要加入新功能。
每一條意見都用簡單的話說明：
可能出什麼問題、在什麼操作下發生、你為什麼這樣判斷。
標出程式碼中的位置，方便另一個代理之後查證。
如果沒找到問題，就直接這樣寫。列出檢查過的內容
和仍然不確定的部分。把報告存到 REVIEW_REPORT.md。
我不懂這門程式語言：說明結論時不要要求我讀程式碼。

REVIEW_REPORT.md 就是一份普通的文字報告。檔名是我們自己取的，換成別的也行：有了它，下一個請求才知道要複查哪些意見。"不要修改程式碼"這條要求把檢查和修正分開；寫入報告則是允許的。

在我們的例子裡，一個有用的回答可能是這樣："如果新增兩個同名的購物項目，刪除其中一個會把兩個都刪掉。程式碼是依名稱挑選記錄的，所以兩筆相符的都會受影響"。這只是教學用的回答範例，不是您專案的檢查結果。

後果您看得懂：使用者會失去原本想留下的記錄。檔名和程式碼位置是給下一個代理找原因用的。這一段您不必自己研究。

3. 如何複查審查意見

擔任審查員的代理也會出錯。例如，它寫道："清單裡可以加入空白的購物項目"。聽起來很有說服力。但程式的另一個部分早就檢查過空白輸入，只是它沒有讀到。這條意見描述的是一個不存在的問題。

這種說得很有把握、內容卻是編出來的說法，通常稱為 AI 的幻覺。在審查裡它特別麻煩：代理可能會提出修正，您就把時間花在修改原本就正常運作的程式碼上。所以程式碼寫完要複查，針對它的意見也同樣要複查。

第一步我們已經做了：請人看過作者的成果。接下來把報告連同目前的專案交給另一位審查員。他的任務是查明每一條意見是否成立。他可以不同意第一位審查員。

請求 2. 檢查審查員的報告

請另一個子代理依照目前專案的程式碼
和上一個請求中的需求，複查 REVIEW_REPORT.md。
把這些需求明確交給它。

針對每一條意見，查明所描述的問題是否存在。
檢查相關的程式碼：需要的處理可能已經有了。
不要把第一份報告當成證據。如果得出結論需要
實際執行來驗證，就用現有的手段執行。
不要修改專案的程式碼。

每一點都標明：已確認、已推翻
或暫時無法確定。用好懂的話說明依據。
把讀程式碼得到的結論和實際執行檢查的結果分開。
沒做過的檢查不要寫成做過。
把結果存到 REVIEW_CHECK.md，並簡短地向我說明。

完成後，您會有一份 REVIEW_CHECK.md，裡面是複查的結果。在我們的教學例子裡，第二個代理可能確認同名的問題，並推翻空白輸入那條意見："空字串在新增記錄之前就會被擋下來。第一位審查員漏看了這項檢查"。

這樣就比較容易決定下一步。刪除的問題可以交去修正。空白輸入依這條意見不必修改。如果代理寫的是"暫時無法確定"，請它說明缺了哪些資訊。有時這是要問您的問題：例如，兩筆相同的記錄應該算一個購物項目還是兩個。

複查能幫忙濾掉編出來的意見，但不保證它們完全消失。兩個代理也可能犯同一個錯。所以回答裡要有依據：審查員在專案裡具體找到了什麼，或執行後得到了什麼結果。光是一句"同意上一個代理"是不夠的。

4. 修正與重新審查

現在選出要修正的項目。要做這個決定，只需要了解問題會怎樣影響頁面原本預期的運作。在我們的例子裡，多刪掉一個購物項目顯然是個困擾，所以就挑這一條。加上排序功能的建議可以晚點再說。反正它跟修正刪除也沒關係。

把選定的意見完整交給代理，免得它還要猜您說"修正第一個錯誤"指的是什麼。也請它在修改後再次檢查結果。這正是團隊故事的延續：同事再看一次修正後的版本。

請求 3. 修正並檢查結果

修正 REVIEW_CHECK.md 中已確認的問題：
刪除一個購物項目時，所有同名的記錄都會消失。
應該只刪除選取的那一筆記錄。允許重複的名稱。
審查中的其他建議現在先不要實作。

修正後，用現有的手段檢查購物項目的新增
和刪除，包括兩個同名項目的情況。
接著請一個獨立的子代理重新審查修正後的程式碼：
原因是否已經排除，新增和刪除是否仍然正常。
把原始需求和這次要修正的問題說明交給它。

用簡單的話向我說明改了什麼、做了哪些檢查，
以及重新審查的結果。
如果有沒能檢查的部分，另外列出來。
不要用新的改進擴大任務範圍。

換成您自己的專案時，把關於購物項目的那一段換成您報告中已確認的意見。其餘的流程可以照用：修正、檢查、另外請人看過結果。

好的結論會講出具體的事情："現在每一筆記錄都會單獨刪除。用兩個同名項目測試時，第二筆記錄仍然留在原位。重新審查沒有發現先前的錯誤原因"。只有做過對應的檢查，才能這樣寫。如果代理只讀了程式碼，它應該明白說出來。

您也可以打開頁面，試試平常會做的操作。這不需要懂程式語言。這是對看得見的結果多做一次檢查；修正的技術審查仍然由代理負責。如果它沒辦法實際執行，報告裡會留下清楚的限制說明，而不是一句"保證一切正常"。

不必把每一輪都變成沒完沒了的修改。如果選定的問題已經排除、檢查過，重新審查也沒發現相關的錯誤，這項任務就可以結束了。就這樣。新的想法值得另外討論。