如何把審查交給子代理並檢查報告

像"檢查一下頁面"這樣的請求，會留給審查員不少需要自己決定的事：要找行為上的錯誤、評估版面，還是建議換一種寫法。結果您可能拿到一份整整齊齊的意見清單，卻對您手上的任務幫助不大。我們來看看，如何給 Claude Code 的子代理一份清楚的委派任務，之後再檢查它有沒有完成。

如果 reviewer 還沒設定好，請先建立這個角色並完成第一次執行。這裡專注在委派任務本身，以及回應是否完整。

1. 要交給審查員哪些資訊

審查員負責檢查別人的成果，並交回附有依據的意見。在我們的範例中，這是一個已設定好的自訂子代理，名稱為 reviewer，只能讀取和搜尋檔案：Read, Grep, Glob。它會研究程式碼，但不會修改，也不會在瀏覽器中開啟頁面。名稱 reviewer 並不會自動建立這個角色：這裡假設它已經在您的專案中設定好了。

在新的一般執行中，這類子代理不會自動取得您完整的對話歷史。與您對話的主代理會為它另外撰寫一份任務。因此，像"兩件名稱相同的商品算作不同的記錄"這樣的重要要求，必須寫進委派任務，或寫進審查員被指示要讀的文件裡。這個流程在子代理上下文的文件中有說明；這裡講的是啟動自訂角色，而不是帶有對話副本的 fork。

比較一下"看看專案"和"檢查刪除記錄和計數器更新；不要改程式碼"。第二種說法已經清楚指出要看哪裡，以及您不希望它做什麼。剩下的就是說清楚，什麼樣的結果才算正確。

如果只是一次性的簡短檢查，一則訊息就夠了。如果條件很多，或修正後還要重複檢查，比較方便的做法是保存一份任務說明：放在專案旁邊的簡短任務描述。不是十頁的獨立規格書。只是幾個條件，少了它們，審查員就只能用猜的。

您不可能預料到所有問題，也沒有必要。輸入資料不足時，審查員應該在報告中標出缺口，主代理就能再向您確認。好的委派任務能減少誤解，但不保證得到好的答案：即使任務很清楚，模型也可能出錯。

2. 委派任務的四個部分

目標回答的是：要檢查哪些行為。以購物清單頁面來說，就是新增、刪除和項目計數。"讓專案變得更好"範圍太廣：看不出現在哪一種改進才重要。

輸入指出檔案和預期的行為。如果從程式碼看不出是否允許名稱相同，只給 app.js 的路徑是不夠的。這個產品決策需要明確告知。同時也說明要用什麼方式檢查：在我們的例子中只讀程式碼，不開瀏覽器。

界限把這次檢查和相鄰的任務分開。例如，樣式、行動版畫面，以及在不同工作階段之間保存清單，這次都不處理。檔案不修改。如果缺少必要的檔案，就暫停依賴它的那部分檢查並回報，而不是自己編造檔案內容。

結果描述您想拿到什麼：檢查了哪些範圍、有依據的發現，以及限制。不要硬性要求一定要找出五個錯誤。Claude Code 的審查建議特別提到這種設定的風險：要求找缺陷的委派任務，會促使它在工作其實已正確完成的地方也提出意見。

每個分支都補上其他分支沒有的東西：檔案路徑不會說明預期行為，目標也不會規定禁止修改。把這些條件放在一起，審查員檢查時才能逐一對照。

所以，與其說"檢查購物清單頁面"，我們改交出下面這份委派任務。它可以直接用訊息發送，也可以存成專案根目錄下的 REVIEW_BRIEF.md：

# 購物清單檢查
目標：透過程式碼檢查新增、刪除和計數器。
輸入：專案根目錄下的 index.html 和 app.js。
預期：新增的項目會出現在清單中；
計數器等於項目數；刪除一筆記錄
不會刪掉另一筆名稱相同的記錄。
界限：不修改檔案；樣式、行動版畫面，以及在不同工作階段之間
保存清單，都不在這次檢查範圍內。
如果缺少必要的檔案或需求，請指出缺口，
不要自行臆測，並交回可檢查部分的結果。
結果：遵循 reviewer 的格式；說明已檢查的內容
和仍未檢查的內容。沒有發現也可以。

reviewer 的格式緊接著在下面說明。如果您的角色還沒有固定格式，可以把它寫進同一則一次性訊息。欄位名稱不是必要的：重要的是它們幫您記得要寫進去的資訊。

"報告中先列出三個最重要的發現"這種要求，限制的是回應的篇幅，而不是檢查的深度。如果需要這樣的限制，請另外要求它說明是否還有其他發現。在第三條意見之後就停下來，宣布任務已檢查完畢，是不可以的。

3. 要保存在檔案中的內容

具體任務的條件會變：今天檢查計數器，明天檢查清單保存。這些條件放在任務說明裡。而要求指出錯誤位置和依據，幾乎每次審查都用得到。把它在角色說明中寫一次會更方便。

Output contract（結果合約）在這裡指的是事先約定好的回應格式。聽起來比實際上更正式：它只是給審查員的一般指示，不是 Claude Code 的特殊設定，也不是自動品質檢查。格式能幫您在報告中找到需要的資訊，但不會讓這些資訊變得可信。

上方兩個分支負責不同的事：任務說明決定檢查的內容，角色說明則連報告的形式也一併規定。要讓審查員使用已保存的任務說明，就要指示它讀這個檔案。它不會自己去看。最下方得到的是一份報告，它的依據和完整性還需要您評估。

下面這一段可以加到現有角色檔案 .claude/agents/reviewer.md 的文字部分，放在設定之後：

## 結果格式
列出已檢查的檔案和檢查條件。
每個發現都要寫：位置、預期行為、依據、
檢查條件和影響；並說明優先順序。
把程式碼能證實的內容和未經檢查的推測分開。
另外列出限制和缺少的資料。
如果依條件沒有發現問題，就直接這樣寫。

這是說明中的一段，不是完整的子代理檔案。我們的角色只能讀取和搜尋，所以不需要固定的"已修改的檔案"欄位。在範圍更廣的報告中，關於修改的資訊必須反映事實：不能事先規定寫上"已修改的檔案：無"這一行，不管實際發生了什麼。

任務說明保存好之後，向主代理發送這樣的請求：

讓 reviewer 讀取專案根目錄下的 REVIEW_BRIEF.md，
並依照其中的條件檢查指定的檔案。
把最終報告完整交回。

我們明確要求讀取這份文件，而不只是提到它的名稱。但檔案本身並不保證什麼：審查員仍可能漏掉某個條件。保存任務說明的好處是，可以拿它來對照結果，也能重複檢查。需求改變時，請先更新文件，否則下一輪執行會拿舊任務來評估。

4. 如何檢查報告

首先看看實際檢查了什麼。任務說明裡有新增、刪除、計數器，以及名稱相同的記錄彼此獨立。如果報告只談到計數器，那還不是整個任務的結果。即使唯一的那個發現完全正確也一樣。

把任務說明中的每個條件和回答逐一對照會很方便。例如，一份教學用的不完整報告，對照結果如下：

報告中沒有提到名稱相同的情況，不代表那裡沒有錯誤。同時，一個有依據的計數器發現，也補不上任務中漏掉的部分。請附上具體的澄清，把報告退回去：

任務說明中有一項：刪除兩筆同名記錄中的一筆。
報告沒有反映這個條件。請用可用的方式檢查它，
並說明結果的依據，或無法檢查的原因。
其他沒有變化的結論不需要重複。不要修改程式碼。

另外也要評估重要發現的可信度：對照它指出的位置、需求和結論的依據。詳細範例請見關於閱讀審查報告的文章。這裡兩項檢查都需要：委派任務的涵蓋範圍，以及結果是否有依據。報告建議的執行情境，並不等於已經跑過的測試。

在第一個岔路口，我們判斷就這個任務而言，檢查得是否足夠。如果不夠，就要求補上缺少的部分，或只接受已檢查的部分，同樣也要評估它的依據。在第二個岔路口，我們把有依據的結論和有爭議、不正確的結論區分開來。依據不清楚的，值得要求澄清；已證實不正確的意見，或與任務無關的建議，可以駁回。

沒有任何發現的報告，也可能通過這項檢查。例如："已檢查 index.html 和 app.js 中的新增與刪除路徑、相同記錄的獨立性，以及計數器更新。依這些條件未發現問題；沒有在瀏覽器中執行"。這樣的結論並不保證專案裡完全沒有錯誤。它說明的是在所列範圍內的結果，必要時您可以自己核對關鍵路徑。

但如果是"在指定路徑找不到 app.js，無法檢查刪除行為"，代表的是資料不足，而不是沒有錯誤。這時需要提供正確的路徑，再繼續檢查。簡短而誠實的回答，比把缺口藏起來的長篇報告更有用。

接受報告，並不代表要讓它修正所有列出的問題。您認可的是檢查結果有依據；現在要做哪些修改，由您另外決定。

5. 什麼時候需要再跑一輪

如果報告缺少依據，不一定要從頭重新審查。把具體的缺口退回去就好。例如，計數器發現的精簡版本只寫了錯誤名稱，沒有分析函式呼叫。這時對主代理的請求可以這樣寫：

把 reviewer 的報告退回去澄清：在計數器的發現中，
沒有說明刪除之後計數器是經由哪條路徑更新的。
請它檢查這條路徑，並補上結論的依據。
不要修改程式碼。

如果發現更新其實已經在另一個函式中完成，這條意見就應該撤回。不要為了維持原本的條數，再去找別的意見來替代。如果錯誤獲得證實，可以另外發一個請求，讓主代理修正，並指明具體的發現和允許的修改範圍。

修正之後，用同一份任務說明再跑一輪會很有幫助：

讓 reviewer 重新讀取 REVIEW_BRIEF.md，並檢查
目前刪除和計數器的程式碼。先前的發現：
刪除後計數器沒有更新。
請它說明問題是否已解決，以及結論的依據，
並檢查名稱相同的記錄彼此獨立這一點
有沒有受到影響。不要修改程式碼。

現在我們要回答的是一個具體的問題：問題是否已解決，而修正可能波及的相鄰行為有沒有被破壞。要確認頁面上的實際行為，請在瀏覽器中重複同樣的情境。如果這次重新審查仍然只看程式碼，新報告中也要保留這項限制。

報告可能變短、變長，或者沒有新的發現。成功與否不在這裡。重要的是舊的缺陷已經排除、結論以目前的程式碼為依據，而且未檢查的部分仍然清楚可見。決定延後修正？那就保存已確認的發現和延後的原因；程式碼沒變，只為了拿到新回答而重複審查，沒有必要。

6. 從委派任務到經過檢查的結果

使用 Claude Code 時，任務說明能幫您保留自己的期待，而主代理負責把任務交給審查員。固定格式讓回答更容易閱讀。不過您仍然需要參與，具體是這樣：

• 主代理擬定委派任務，交給合適的角色；您設定預期行為和界限；
• 審查員研究檔案，交回結論的依據；而涵蓋範圍和重要發現，由您來檢查；
• 主代理可以根據另外的委派任務澄清報告，或修正已確認的錯誤；您決定要改什麼，以及如何確認結果。

以購物清單為例，最後得到的不只是一句"加上函式呼叫"的建議，而是經過檢查的說明：在什麼操作下數字會過時、更新在哪裡中斷，以及修正後改變了什麼。有了這樣的結果，就能真正著手處理了。