審查循環
在同一工作階段內進行的迭代工單-審查循環。你完成工作，召喚一個審查子代理來評論，根據回饋修正，重複直到達到品質門檻。
核心原則： 初稿絕非最終版。迭代式批評比單次通過能產出更好的結果。
平台說明： 此技能最適用於支援子代理生成的代理。 在不支援該功能的平台上，可透過以下方式模擬審查步驟：開啟一個新的聊天對話，僅貼上工作成果（不含先前的推理），並要求其以 1-10 分評分並提供具體回饋。
快速開始
- 說：
「實作 X，使用審查循環」或「對我剛剛寫的檔案執行審查循環」 - 代理完成工作（或讀取現有工作）
- 一個獨立的批評子代理以 1-10 分評分，並提供具體回饋
- 代理根據回饋修正，並重複直到分數 >= 8（預設品質門檻）
- 輸出最終結果，並附上循環摘要
何時使用
- 使用者說「使用審查循環」、「潤飾這個」、「迭代這個」、「/review-loop」
- 品質比速度更重要的複雜實作
- 設計文件、規格或技術寫作
- 需要健壯性的程式碼（安全性、資料管道、財務邏輯）
- 當使用者希望將對抗式批評內建在流程中時
何時不使用
- 簡單修正、快速編輯、單行變更
- 測試為品質門檻的任務（改用 TDD + CI）
- 當使用者只求快速完成時
- 目標為學習而非交付的探索/試驗性工作
- 沒有明確驗收標準的任務——先定義好標準，再使用審查循環
預設值
| 設定 | 預設值 |
|---|---|
| 最少循環次數 | 2 |
| 最多循環次數 | 4 |
| 品質門檻 | 8/10 |
| 工單模型 | （你當前的模型） |
| 審查模型 | （你當前的模型或快速/平衡替代方案） |
模型選擇
審查任務負責評估邏輯與限制。工單任務負責撰寫與修改程式碼。請根據子代理的能力進行選擇。
關鍵規則： 審查者必須永遠 等於或強於 工單者。如果審查者弱於工單者，就無法妥善批評複雜邏輯或發現細微回歸。
| 任務複雜度 | 工單者能力 | 審查者能力 | 理由 |
|---|---|---|---|
| 簡單/機械性（CRUD、格式化、模板程式碼） | 快速/輕量 | 平衡 | 輕量工單者速度快，平衡的審查者能輕易發現問題 |
| 標準（功能、重構、文件） | 平衡 | 平衡 | 成本、速度與品質的良好組合 |
| 複雜（多檔案、整合、設計） | 平衡 | 進階/推理 | 進階審查者能發現細微架構問題，平衡的工單者能夠實作 |
| 非常複雜（安全性、量化、分散式系統） | 進階/推理 | 進階/推理 | 兩者都需要完整上下文與推理能力。審查者必須與工單者能力匹配。 |
黃金法則： 工單者必須足夠聰明，能夠根據審查者的回饋採取行動。如果審查者說「用基於通道的信號量來修正競態條件」，但工單者無法推理並發問題，循環就無法收斂。
升級信號： 如果連續兩次循環得分未改善，且回饋相同，表示工單模型太弱。請升級：
- 選項 A：要求使用者切換到能力更強的模型
- 選項 B：暫時調低品質門檻，並向使用者說明差距
- 選項 C：將任務拆分成較小的子任務，並對每個子任務執行審查循環
預設行為： 由於你（主要代理）就是工單者，請根據任務召喚一個符合或超過你當前能力的審查子代理：
- 大多數任務 → 標準/平衡的審查者
- 專業/困難任務 → 進階/推理的審查者
- 快速檢查 → 快速/輕量的審查者（僅在你也作為輕量工單者時使用）
使用者覆寫
使用者可以透過內嵌參數覆寫任何預設值。請自然解析這些指令：
「實作 X，使用審查循環，品質門檻 9，使用進階模型進行審查，最多 5 個循環」
「潤飾這個，最少 2 個循環，門檻 8」
「執行審查循環，快速審查，最多 2 個循環」
「使用審查循環，推理審查者，品質門檻 9，最少 3 個最多 6 個循環」
解析規則：
- 「品質門檻 N」或「門檻 N」 → quality_gate = N
- 「[模型] 審查者」或「使用 [模型] 審查」 → 審查模型覆寫
- 「最多 N 個循環」 → max_loops = N
- 「最少 N 個循環」 → min_loops = N
- 如果使用者未指定，使用預設值
- 如果使用者說「徹底」或「嚴格」 → 解釋為 quality_gate 8，min_loops 2
- 如果使用者說「快速」或「迅速」 → 解釋為 max_loops 2，quality_gate 6
流程
flowchart TD
A[完成工作] --> B[召喚審查子代理]
B --> C{達到最少循環次數？}
C -- 否，總是繼續 --> E[根據回饋修正]
C -- 是 --> D{分數 >= 品質門檻？}
D -- 是 --> F[最終潤飾]
D -- 否 --> G{達到最多循環次數？}
G -- 是，無論如何停止 --> F
G -- 否 --> E
E --> B
F --> H([完成])
逐步說明
步驟 1：完成工作
像平常一樣完成任務。撰寫程式碼、建立規格、實作功能。盡全力交出最佳初稿。
步驟 2：召喚審查子代理
使用代理工具派遣一個審查者。審查者必須：
- 是一個 獨立的子代理（全新的上下文，不受你推理的影響）
- 只接收 工作成果（檔案、差異）—— 而非你的思考過程
- 以 1-10 分評分，並提供 具體、可操作的回饋
- 預設使用平衡/標準模型（對於複雜/專業任務則使用進階推理模型）
審查者提示模板：
你是一位嚴格的審查者。請對以下工作以 1-10 分評分，並提供具體、可操作的回饋。
## 完成的工作
{任務的簡要描述}
## 審查標準
{任務特定的標準——對這項任務來說什麼是重要的}
標準撰寫範例：
對於 REST API 端點：
- 使用正確的 HTTP 狀態碼
- 所有參數均有輸入驗證
- 已實施身分驗證；無未驗證的存取
- 無 N+1 查詢模式
對於設計文件：
- 問題陳述清晰明確
- 已考慮替代方案及其取捨
- 對實作複雜度無含糊之處
- 成功指標可衡量
對於資料管道：
- 冪等性——可安全重新執行
- 優雅處理結構變更
- 已記錄失敗模式
- 已處理 PII
## 指示
1. 仔細閱讀工作
2. 以 1-10 分評分，其中：
- 1-3：根本上錯誤或缺少主要需求
- 4-6：可行但有重大問題
- 7-8：良好，僅有微小問題
- 9-10：優秀，可準備交付
3. 列出具體問題，並附上檔案:行號參考（若適用）
4. 針對每個問題，解釋為什麼重要以及如何修正
5. 不要禮貌——要誠實且直接
6. 清楚寫出你的分數，格式為「Score: N/10」
## 要審查的檔案
{貼上檔案內容或列出檔案路徑及相關摘錄}
步驟 3：解析回饋
從審查者的回應中，提取：
- 分數（數字）
- 問題（分類為：嚴重 / 重要 / 輕微）
- 具體修正（需要更改的內容）
向使用者報告：
循環 {N}/{最多}: 分數 {X}/10
- {關鍵回饋點摘要}
步驟 4：檢查停止條件
按此順序檢查：
- 如果已完成的循環次數 < 最少循環次數 → 繼續（總是）
- 如果分數 >= 品質門檻 → 停止，進入最終潤飾
- 如果已完成的循環次數 >= 最多循環次數 → 停止，進入最終潤飾
- 否則 → 修正並循環
步驟 5：修正
處理審查者的回饋。修正嚴重和重要的問題。輕微問題為可選。然後回到步驟 2。
重要： 每次修正應有針對性。不要重寫所有內容——只修正審查者標記的部分。在心中維護一個所有先前回饋的清單，以避免回歸。
步驟 6：最終潤飾
一旦循環結束（達到品質門檻或達到最多循環次數）：
- 如果簡單，處理任何剩餘的輕微問題
- 確認最終輸出前後連貫（沒有來自修正週期的痕跡）
- 向使用者報告最終分數和循環次數
根據任務類型調整審查標準
| 任務類型 | 審查者應專注於 |
|---|---|
| 程式碼 | 正確性、邊界情況、錯誤處理、可讀性、無安全性問題 |
| 規格/設計 | 完整性、可行性、無含糊之處、可實作性 |
| 重構 | 無行為變更、無回歸、比之前更乾淨 |
| 寫作 | 清晰度、結構、受眾適切、無廢話 |
| 錯誤修正 | 根因已解決、存在回歸測試、無副作用 |
| 基礎設施 / IaC | 冪等性、最小權限、無硬編碼機密、刪除安全性 |
| 資料庫遷移 | 可逆性、索引策略、資料遺失風險、擴展性表現 |
| API 設計 | 向後相容、身分驗證、版本控制、錯誤契約 |
| 測試套件 | 邊界情況覆蓋率、無測試相互依賴、有意義的斷言 |
兩種操作模式
模式 A：「先做再審查」（完整循環）
使用者給出任務並要求使用審查循環。你完成工作並執行審查循環。
使用者：「實作快取層。使用審查循環，品質門檻 8。」
你：
1. 實作快取層
2. 召喚審查者 → 分數 6，回饋：缺少淘汰機制、無 TTL
3. 修正：加入淘汰機制 + TTL
4. 召喚審查者 → 分數 8，回饋：命名上的小問題
5. 最終潤飾，完成
模式 B：「審查現有內容」（僅審查）
使用者已經完成工作，或者你已經完成工作。僅對現有內容執行審查循環。
使用者：「對我剛剛寫的 auth 模組執行審查循環」
你：
1. 讀取 auth 模組
2. 召喚審查者 → 分數 5，回饋：SQL 注入、無速率限制
3. 修正：參數化查詢、加入速率限制器
4. 召喚審查者 → 分數 8，通過
5. 完成
紅旗
絕對不要：
- 自我審查而非召喚子代理（會產生錨定偏差）
- 跳過修正循環，只因「回饋是錯的」而未提供正當理由
- 過度誇大自己的分數（「我認為這實際上可以得 9 分」）
- 未經使用者同意繼續超過最多循環次數
- 將你完整的推理/歷史提供給審查者（他們必須審查的是 工作，而非你的意圖）
如果審查者錯了：
- 用證據反駁（展示程式碼/測試來反駁回饋）
- 在修正中跳過該特定點
- 在你的報告中向使用者註明
- 不要為了補償而調低品質標準
報告格式範例
--- 審查循環：{任務名稱} ---
循環 1/4：分數 6/10
審查者：缺少輸入驗證、未處理網路逾時錯誤、
函數過長（80 行）。
動作：修正所有三個問題。
循環 2/4：分數 8/10
審查者：乾淨。微小問題：變數名稱 `d` 可以更具描述性。
動作：達到品質門檻（8 >= 8）。最終潤飾。
結果：8/10，2 個循環。完成。
已知限制
- 審查子代理沒有先前循環的記憶——請在每個審查提示中明確包含先前回饋的上下文，以避免重複處理已解決的問題
- 如果審查提示的標準過於模糊，可能出現分數膨脹——請花時間撰寫具體、可衡量的標準
- 此技能無法取代針對安全性關鍵或合規敏感程式碼的人類審查；請將輸出視為強而有力的初稿
- 如果任務定義不明確，循環收斂無法保證——請在開始前定義清晰的驗收標準
成本與速度
- 每個循環 = 1 次審查子代理呼叫
- 一個完整的 3 循環週期，預估時間約為單次實作時間的 1–2 倍
- 與交付有錯誤的程式碼、模糊的規格或觸發後期審查循環相比，這是便宜的
- 大多數審查使用你的預設/標準模型；僅對專業領域（安全性稽核、分散式系統、量化金融）升級使用進階推理模型
授權
MIT —— 可自由使用、修改，並與任何 AI 工具或平台重新發布。若能標註出處，我們會很感激。歡迎貢獻。