搭建Superpowers代碼審查流水線
整理版優先睇
用Superpowers三個Skill串成代碼審查流水線，依次檢查質量、安全同簡潔，形成閉環
呢篇文章係關於點樣用Superpowers平台嘅三個審查Skill——/review、/security-review同/simplify——串成一個代碼審查流水線。作者指出，AI寫代碼雖然成日都跑到，但質量唔穩定，成日有漏錯誤處理、硬編碼密鑰或者冗餘邏輯。加上好多單兵作戰嘅開發者冇團隊幫手review，所以需要一個自動化嘅審查流程。
整體結論係：將三個專注唔同維度嘅Skill串聯，跟住「審查→驗證→修復→再審查」嘅紀律，可以有效提升代碼質量。順序係先保正確（/review）、再保安全（/security-review）、最後保簡潔（/simplify）。每一關發現嘅問題一定要修復完，重新審查通過先可以入下一關。呢個流水線唔單止係工具，更加係一種紀律。
- 使用三個Skill（/review, /security-review, /simplify）串成流水線，依次審查代碼質量、安全漏洞同冗餘邏輯。
- 每一關都要先驗證反饋嘅準確性，確認屬實之後先修復，修復完一定要再跑一次審查確認通過，唔可以跳步。
- 審查順序有講究：先/review保正確，再/security-review保安全，最後/simplify保簡潔，因為精簡可能會改到結構。
- 以用戶頭像上傳功能做例子，三關分別發現咗唔同問題：文件類型校驗、路徑遍歷、代碼複用，說明瞭流水線嘅價值。
- 流水線適合用喺主分支提交、涉及用戶輸入、數據存儲、API等場景；純UI修改、文檔、hotfix可以跳過或者只跑第一關。
內容片段
/review → 修復問題 → 再跑 /review 確認通過/security-review → 修復問題 → 再跑 /security-review 確認通過/simplify → 修復問題 → 再跑 /simplify 確認通過點解需要流水線？
AI寫代碼有個特點：大概率能跑，但質量不穩定。你叫AI寫一個功能，佢交出來嘅代碼通常正常運行，但仔細睇——可能少咗錯誤處理，可能硬編碼咗密鑰，或者複製咗一段項目入面已經有嘅工具函數。呢個唔係AI能力唔夠，係AI寫完代碼之後唔會自動審查。人寫都一樣：寫完自己review，成日睇唔出問題，因為你心裏知道段代碼想點，會自動補全邏輯跳過漏洞。團隊要有code review，但單兵作戰就冇人幫你review。
Superpowers提供咗三個審查Skill，可以串成一條流水線：/review審查代碼質量 → /security-review掃描安全問題 → /simplify精簡冗餘邏輯。配合verification-before-completion鐵律，三關過完之後，代碼喺質量、安全、簡潔三個維度都過咗一輪檢查。
- 審查角度單一：一個Skill淨係睇一個維度，好似體檢只驗血唔驗肝功能。
- 審查結果冇優先級：混埋一堆建議，你唔知先搞邊個。
- 冇閉環：審查完改完，冇再確認修好。流水線每一關都做：發現問題→修復→重新審查確認→下一關。
第1關：/review —— 代碼質量審查
/review 會基於你嘅git diff進行審查，關注幾個維度：計劃對齊（實現符唔符合需求）、代碼質量（有冇bug、邊界處理）、架構設計、文檔同規範。佢會對照你嘅需求去檢查——你話做A，佢就睇A係咪完整實現，有冇多做B或者漏咗C。
寫完代碼之後直接叫 /review，佢會畀分級反饋：Critical（會崩潰或數據丟失）、Important（可能導致bug或性能問題）、Minor（風格、命名等）。通過標準係Critical同Important全部修復，Minor可以記錄低留畀第3關處理。
- 1 讀完整反饋：唔好睇完第一個問題就開始改。
- 2 理解每個問題：用自己的話複述一次。
- 3 驗證反饋準確性：審查代理可能誤判，要檢查代碼確認問題係咪真係存在。
- 4 評估後實施：按優先級修復（Critical→Important→Minor），但唔好加冇人要用嘅功能（YAGNI原則）。
第2關：/security-review —— 安全掃描
/security-review 專注檢查安全問題：密鑰泄露、注入攻擊（SQL、XSS、命令）、認證授權、數據保護。佢同 /review 嘅審查角度完全唔同，/review 未必發現到安全漏洞。
用嘅時候叫 /security-review，佢會掃描git diff。安全審查嘅誤報率較高，驗證步驟更加重要：檢查被標記嘅代碼係咪真係有漏洞，確認上下文容唔容許攻擊。如果確認係誤報，記錄原因跳過；但如果確認問題屬實，修復優先級比代碼質量問題更高。
- 1 檢查密鑰、密碼、Token有冇硬編碼。
- 2 檢查用戶輸入有冇做轉義或過濾。
- 3 檢查權限校驗係咪完整。
- 4 檢查敏感數據有冇加密，日誌有冇泄露隱私。
第2關通過標準：Critical同Important全部修復，再跑一次 /security-review 確認通過。
第3關：/simplify —— 精簡優化
/simplify 會啟動3個審查代理並行工作：代碼複用代理（揾項目已有工具函數，標記重複實現）、代碼質量代理（冗餘狀態、參數膨脹、不必要嵌套）、效率代理（重複計算、漏掉的併發、內存問題）。佢唔單止畀建議，仲會直接幫你改code，之後你要檢查變更加唔合理。
用嘅時候叫 /simplify，佢自動讀git diff，3個代理並行審查後應用修改。你可以用 git diff 睇佢改咗啲乜，合理就保留，唔合理就用 git checkout 還原某部分。通過標準比較寬鬆：確認自動修改冇破壞功能就得。
- 代碼複用代理：揾出你寫嘅函數同項目入面已有嘅工具函數重複。
- 代碼質量代理：標記嵌套 if-else 可以早返回、唔必要註解等。
- 效率代理：指出可以合併嘅數據庫查詢、同步壓縮阻唔阻塞UI等。
串聯使用同審查紀律
最簡單嘅手動跑法：寫完代碼之後依次跑 /review → 修復 → 再跑確認 → /security-review → 修復 → 再跑確認 → /simplify → 睇變更 → 再跑確認。三關全過先提交代碼。
如果配合Superpowers嘅subagent-driven模式，內置咗規範審查同質量審查，你可以手動加安全同精簡。審查紀律一樣：發現問題→修復→重新審查確認→通過後先算完成。唔好跳過重新審查步驟，因為修一個問題可能引入新問題。
- 1 該跑三關嘅場景：提交主分支、涉及用戶輸入、數據存儲、API、權限控制等。
- 2 可以只跑第1關嘅場景：純UI樣式調整、文檔修改、配置文件。
- 3 可以跳過嘅場景：緊急hotfix（後補審查）、實驗性代碼（唔合併）、自動生成代碼。
- 4 審查結果矛盾時：以 /review 為準，正確性優先於簡潔性。
三個Skill各有專長：/review保正確，/security-review保安全，/simplify保簡潔。串成流水線之後，三個維度都過咗一輪檢查。
/review查質素、/security-review掃安全、/simplify去冗餘——三個Skill串成流水線，code寫完依次過3關，每關發現問題必須修好並重新驗證先至可以入下一關
寫喺前面
AI寫code有個特點：多數都行得通，但質素唔穩定。
你叫AI寫一個功能，佢交出來嘅code通常行得正常。但仔細睇——可能少咗錯誤處理，可能硬編碼咗密鑰，可能複製咗一段project裏面已經有嘅工具函數就可以取代嘅邏輯。呢個唔係AI能力唔夠，係AI寫完code之後唔會自動審查。
人寫code都一樣。寫完自己review一次，成日睇唔出問題——因為你心知呢段code想做咩，會自動補返邏輯，跳過漏洞。所以團隊要有code review：審查自己嘅code通常發現唔到問題。
問題係，好多人用AI編程係單打獨鬥。冇團隊成員幫你review，code質素全靠自己把關。寫完行一次，冇報錯就提交咗。
Superpowers提供咗三個審查Skill，可以串成一條流水線：/review審查code質素→/security-review掃描安全問題→/simplify精簡冗贅邏輯。配合Superpowers嘅審查紀律（收到反饋先驗證準確性、修復之後一定要重新審查確認），三關過曬，code喺質素、安全、簡潔三個維度上都過咗一輪檢查。
呢篇文章講呢三關點樣配、點樣用、收到反饋點處理、以及點樣串埋形成閉環。
一、點解需要流水線，而唔係一個review就夠
你可能喺之前嘅文章見過 /review 和 /simplify 呢兩個Skill。單獨用當然都得，但單獨用有幾個問題：
1. 審查角度單一
/review 關注code質素同潛在bug，但唔會專門檢查安全漏洞。/simplify 關注code冗贅同效率，但唔會幫你揾SQL注入。一個審查工具淨係睇一個維度，好似體檢淨係抽血唔驗肝功能。
2. 審查結果冇優先級
單獨跑 /review，佢會俾你一大堆建議：有緊急嘅安全問題，亦都有「呢個變量名可以更清晰」嘅建議。撈埋一齊，你唔知先修邊個。流水線嘅好處係：每關淨係關注自己嘅維度，問題按關卡分類，修起嚟有順序。
3. 冇閉環
審查提咗建議，你修咗，然後呢？冇再行一次確認修好咗。Superpowers嘅verification-before-completion鐵律係：冇驗證就唔可以話完成。流水線嘅每一關都跟呢個鐵律——審查發現問題→修復→重新審查確認→進入下一關。
三關流水線嘅設計如下：
順序有講究：先保正確，再保安全，最後精簡。因為精簡可能改變code結構，如果先精簡再審查安全同質素，審查嘅就唔係最終code喇。
二、第1關：/review —— code質素審查
佢做咩
/review 基於你嘅code變更（git diff）進行審查，關注幾個維度：
/review 嘅審查唔係泛泛咁睇code，佢會對照你嘅需求或計劃去檢查——你話要做A，佢檢查A係咪完整實現，係咪多做咗B，係咪漏咗C。
怎麼用
寫完code之後，直接調用：
/review
/review 會讀取git diff分析你嘅變更，俾出分級反饋：
實際過程
假設你寫咗一個用戶註冊接口，/review 可能會俾咁樣嘅反饋：
Critical: 密碼沒有做強度校驗，空密碼也能註冊
Important: 錯誤信息直接返回了數據庫錯誤詳情，可能泄露表結構
Minor: 變量名 tmp 可以改為更有意義的名稱
注意：/review 都可能順便發現啲安全相關問題（例如上面嘅信息洩漏）。兩關嘅審查維度有少量重疊，係正常嘅——第2關 /security-review 會做更系統、更專業嘅安全檢查。
第1關嘅通過標準：Critical同Important問題全部修復。Minor問題記錄低，第3關 /simplify 可能會順手處理。
收到反饋後點樣處理
呢一步好多人會忽略——收到審查反饋，唔係直接照改，而係先驗證反饋係咪準確。Superpowers仲有一個配套Skill叫receiving-code-review，專門定義咗「收到審查反饋後應該點處理」嘅流程：
特別要注意：如果審查建議你「正確實現」一個project裏面冇人用嘅功能，應該拒絕。呢個係YAGNI原則——你唔需要佢，就唔好加。
修完再驗
修復問題後，再行一次 /review 確認。呢個係鐵律——冇驗證就唔可以話修復完成。行命令、睇輸出、確認Critical同Important都清零咗，第1關先至算通過。
三、第2關：/security-review —— 安全掃描
佢做咩
/review 關注嘅係「code寫得啱唔啱」，/security-review 關注嘅係「code安唔安全」。佢專門檢查：
怎麼用
/security-review
/security-review 會掃描你嘅code變更，重點檢查安全相關嘅模式。
實際過程
接上面嘅用戶註冊接口，/security-review 可能發現：
Critical: 密碼使用明文存儲，必須使用bcrypt加密
Important: 註冊接口沒有速率限制，可被暴力攻擊
Important: 用戶輸入未做XSS過濾，惡意腳本可注入
呢啲問題 /review 唔一定發現到——佢關注code質素，唔係安全專家。/security-review 嘅審查角度完全唔同。
對安全反饋要更加謹慎
安全審查嘅誤報率比code質素審查高。一個被標記為「XSS風險」嘅code段，可能實際上已經做咗轉義處理。收到安全反饋後，驗證步驟更加重要：
但反轉嚟講，安全問題都唔可以因為「可能誤報」就忽略。驗證後確認嘅問題，修復優先級比code質素問題更高——一個邊界情況可能隻影響少數用戶，一個SQL注入可能影響所有用戶。
第2關嘅通過標準
Critical同Important全部修復，而且修復後重新行 /security-review 確認通過。
四、第3關：/simplify —— 精簡優化
佢做咩
前兩關保正確、保安全，第3關保簡潔。/simplify 會啓動3個審查代理並行工作：
3個代理並行工作，每個淨係睇自己嘅維度，最後彙總結果。/simplify 唔單止會俾建議，仲會直接幫你應用修改——審查完之後佢會自動修改code，但修改後你需要檢查變更係咪合理，再決定係咪保留。
怎麼用
/simplify
佢會自動讀取git diff，分析你最近嘅code變更，3個代理並行審查後彙總結果並應用修改。
第3關嘅通過標準
/simplify 會自動應用修改，但你需要review佢改咗啲咩。用 git diff 查看變更，確認修改合理就保留；如果某處修改唔合適（例如刪咗你有意為之嘅邏輯），用 git checkout 還原嗰部分。標準比前兩關寬鬆：確認自動修改冇破壞功能就得。
五、三關流水線：串埋一齊用
手動行三關
最簡單嘅方式，寫完code之後依次行：
/review → 修復問題 → 再跑 /review 確認通過
/security-review → 修復問題 → 再跑 /security-review 確認通過
/simplify → 修復問題 → 再跑 /simplify 確認通過
三關全部過曬，先提交code。
配合Superpowers嘅Subagent-Driven模式
Superpowers嘅subagent-driven-development模式本身就內置咗兩階段審查：當你用嗰個模式寫code時，每個任務完成後會自動觸發——先派規範審查代理檢查實現係咪符合需求，再派質素審查代理檢查code質素。兩階段審查嘅順序唔可以調轉——先確認做啱咗，再確認做好咗。
喺呢個內置審查嘅基礎上，你可以手動將安全審查同精簡優化加埋入去，形成更完整嘅流水線：
/review）/security-review，手動追加）/simplify，手動追加）前兩步係subagent-driven模式自動完成嘅，後兩步需要你手動觸發。但審查紀律係一樣嘅：發現問題→修復→重新審查確認→通過之後先至算完成。
審查循環
每一關都可能發現問題。發現→修復→重新審查，呢個循環好重要：
/review 發現Critical問題 → 你修復 → 再行 /review → 通過/security-review 發現Important問題 → 你修復 → 再行 /security-review → 通過/simplify 發現優化建議 → 你選擇性修復 → 再行 /simplify → 通過唔好跳過重新審查嘅步驟。修復一個問題可能引入新問題——例如修復安全問題時改咗加密方式，可能影響登錄邏輯。重新審查可以發現呢類連鎖反應。
六、一個完整嘅例子
場景：俾一個React應用加用戶頭像上傳功能。寫完code之後，啓動三關審查。
第1關 /review：
Critical: 上傳文件沒有校驗文件類型，任意文件都能上傳
Important: 上傳失敗時沒有清理臨時文件，會導致磁盤泄漏
Important: 文件大小限制寫在組件裏，應該抽到配置文件
Minor: handleChange 函數超過50行，建議拆分
修復：加文件類型白名單、失敗時清理臨時文件、文件大小限制搬去配置、拆開函數。再行 /review，Critical同Important清零，通過。
第2關 /security-review：
Critical: 文件名直接用用戶上傳的原始文件名，存在路徑遍歷風險
Important: 沒有對圖片內容做校驗，可能上傳偽裝成圖片的惡意腳本
修復前先驗證：路徑遍歷風險確認存在（文件名可能包含 ../），偽裝圖片風險都確認存在（淨係校驗擴展名唔夠）。用UUID重新命名文件、用file-type庫校驗文件實際內容。再行 /security-review，通過。
第3關 /simplify：
代碼複用：項目裏 src/utils/upload.ts 已有通用上傳函數，
你的代碼重複實現了文件校驗和上傳邏輯，建議複用
效率：上傳前先壓縮圖片的邏輯是同步的，會阻塞UI，
建議用Web Worker或requestIdleCallback
修復：複用已經有嘅上傳函數、圖片壓縮改做異步。再行 /simplify，通過。
三關全部過曬，提交code。
對比一下：如果淨係行咗 /review，路徑遍歷漏洞同偽裝文件攻擊唔會被發現。如果淨係行咗 /security-review，臨時文件洩漏同code重複唔會被發現。三關流水線嘅價值在於——每個維度都有專門嘅審查，而且每關發現嘅問題都經過修復同驗證閉環。
七、幾時應該行，幾時唔使行
應該行三關嘅場景
可以淨係行第1關嘅場景
可以跳過嘅場景
審查結果互相矛盾點算
間中會出現呢種情況：/simplify 建議刪除某段code（認為冗贅），但 /review 認為需要保留（處理咗邊界情況）。呢個時候以 /review 嘅判斷為準——正確性優先於簡潔性。如果兩關嘅反饋真係矛盾，返去code驗證：嗰段code到底有冇被使用、有冇處理真實場景。
寫喺最後
三個Skill各有專長：/review 保正確，/security-review 保安全，/simplify 保簡潔。單獨用任何一個，都只能睇到code嘅一個側面。串成流水線，三關過曬，code喺三個維度上都過咗一輪檢查。
流水線嘅核心唔係工具多，係紀律——收到反饋先驗證準確性，確認屬實之後修復，修復後一定要重新審查確認，唔可以跳步。呢種「審查→驗證→修復→再審查確認」嘅循環，比任何單一個審查工具更加重要。
/review查質量、/security-review掃安全、/simplify去冗餘——三個Skill串成流水線，代碼寫完依次過3關，每關發現問題必須修完並重新驗證後才能進入下一關
寫在前面
AI寫代碼有個特點：大概率能跑，但質量不穩定。
你讓AI寫一個功能，它交出來的代碼通常能正常運行。但仔細看——可能少了錯誤處理，可能硬編碼了密鑰，可能複製了一段項目裏已有的工具函數就能替代的邏輯。這不是AI能力不夠，是AI寫完代碼後不會自動審查。
人寫代碼也一樣。寫完自己review一遍，經常看不出問題——因為你心裏知道這段代碼想幹什麼，會自動補全邏輯，跳過漏洞。這也是為什麼團隊要有code review：審查自己的代碼往往發現不了問題。
問題是，很多人用AI編程是單兵作戰。沒有團隊成員幫你review，代碼質量全靠自己把關。寫完跑一下，沒報錯就提交了。
Superpowers提供了三個審查Skill，可以串成一條流水線：/review審查代碼質量→/security-review掃描安全問題→/simplify精簡冗餘邏輯。配合Superpowers的審查紀律（收到反饋先驗證準確性、修復後必須重新審查確認），三關過完，代碼在質量、安全、簡潔三個維度上都過了一輪檢查。
這篇文章講這三關怎麼配、怎麼用、收到反饋怎麼處理、以及怎麼串起來形成閉環。
一、為什麼需要流水線，而不是一個review就夠了
你可能在之前的文章裏見過 /review 和 /simplify 這兩個Skill。單獨用當然也行，但單獨用有幾個問題：
1. 審查角度單一
/review 關注代碼質量和潛在bug，但不會專門檢查安全漏洞。/simplify 關注代碼冗餘和效率，但不會幫你找SQL注入。一個審查工具只看一個維度，就像體檢只查血常規不查肝功能。
2. 審查結果沒有優先級
單獨跑 /review，它會給你一堆建議：有緊急的安全問題，也有"這個變量名可以更清晰"的建議。混在一起，你不知道先修哪個。流水線的好處是：每關只關注自己的維度，問題按關卡分類，修起來有順序。
3. 沒有閉環
審查提了建議，你修了，然後呢？沒有再跑一遍確認修好了。Superpowers的verification-before-completion鐵律是：沒有驗證就不能聲稱完成。流水線的每一關都遵循這個鐵律——審查發現問題→修復→重新審查確認→進入下一關。
三關流水線的設計如下：
順序有講究：先保正確，再保安全，最後精簡。因為精簡可能改變代碼結構，如果先精簡再審查安全和質量，審查的就不是最終代碼了。
二、第1關：/review —— 代碼質量審查
它做什麼
/review 基於你的代碼變更（git diff）進行審查，關注幾個維度：
/review 的審查不是泛泛地看代碼，它會對照你的需求或計劃來檢查——你說了要做A，它檢查A是否完整實現，是否多做了B，是否遺漏了C。
怎麼用
寫完代碼後，直接調用：
/review
/review 會讀取git diff分析你的變更，給出分級反饋：
實際過程
假設你寫了一個用戶註冊接口，/review 可能給出這樣的反饋：
Critical: 密碼沒有做強度校驗，空密碼也能註冊
Important: 錯誤信息直接返回了數據庫錯誤詳情，可能泄露表結構
Minor: 變量名 tmp 可以改為更有意義的名稱
注意：/review 也可能順帶發現一些安全相關問題（比如上面的信息泄露）。兩關的審查維度有少量重疊，這是正常的——第2關 /security-review 會做更系統、更專業的安全檢查。
第1關的通過標準：Critical和Important問題全部修復。Minor問題記錄下來，第3關 /simplify 可能會順手處理。
收到反饋後怎麼處理
這一步很多人會忽略——收到審查反饋，不是直接照改，而是先驗證反饋是否準確。Superpowers還有一個配套Skill叫receiving-code-review，專門定義了"收到審查反饋後應該怎麼處理"的流程：
特別要注意：如果審查建議你"正確實現"一個項目裏沒人用的功能，應該拒絕。這是YAGNI原則——你不需要它，就不要加。
修完再驗
修復問題後，再跑一次 /review 確認。這是鐵律——沒有驗證就不能聲稱修復完成。跑命令、看輸出、確認Critical和Important都清零了，第1關才算通過。
三、第2關：/security-review —— 安全掃描
它做什麼
/review 關注的是"代碼寫得對不對"，/security-review 關注的是"代碼安全不安全"。它專門檢查：
怎麼用
/security-review
/security-review 會掃描你的代碼變更，重點檢查安全相關的模式。
實際過程
接上面的用戶註冊接口，/security-review 可能發現：
Critical: 密碼使用明文存儲，必須使用bcrypt加密
Important: 註冊接口沒有速率限制，可被暴力攻擊
Important: 用戶輸入未做XSS過濾，惡意腳本可注入
這些問題 /review 不一定能發現——它關注代碼質量，不是安全專家。/security-review 的審查角度完全不同。
對安全反饋要更謹慎
安全審查的誤報率比代碼質量審查高。一個被標記為"XSS風險"的代碼段，可能實際上已經做了轉義處理。收到安全反饋後，驗證步驟更重要：
但反過來，安全問題也不能因為"可能誤報"就忽略。驗證後確認的問題，修復優先級比代碼質量問題更高——一個邊界情況可能隻影響少數用戶，一個SQL注入可能影響所有用戶。
第2關的通過標準
Critical和Important全部修復，且修復後重新跑 /security-review 確認通過。
四、第3關：/simplify —— 精簡優化
它做什麼
前兩關保正確、保安全，第3關保簡潔。/simplify 會啓動3個審查代理並行工作：
3個代理並行工作，每個只看自己的維度，最後彙總結果。/simplify 不僅會給出建議，還會直接幫你應用修改——審查完後它會自動修改代碼，但修改後你需要檢查變更是否合理，再決定是否保留。
怎麼用
/simplify
它會自動讀取git diff，分析你最近的代碼變更，3個代理並行審查後彙總結果並應用修改。
第3關的通過標準
/simplify 會自動應用修改，但你需要review它改了什麼。用 git diff 查看變更，確認修改合理後保留；如果某處修改不合適（比如刪掉了你有意為之的邏輯），用 git checkout 還原那部分。標準比前兩關寬鬆：確認自動修改沒有破壞功能即可。
五、三關流水線：串起來用
手動跑三關
最簡單的方式，寫完代碼後依次跑：
/review → 修復問題 → 再跑 /review 確認通過
/security-review → 修復問題 → 再跑 /security-review 確認通過
/simplify → 修復問題 → 再跑 /simplify 確認通過
三關全過，再提交代碼。
配合Superpowers的Subagent-Driven模式
Superpowers的subagent-driven-development模式本身內置了兩階段審查：當你使用該模式編寫代碼時，每個任務完成後會自動觸發——先派規範審查代理檢查實現是否符合需求，再派質量審查代理檢查代碼質量。兩階段審查的順序不能反——先確認做對了，再確認做好了。
在這個內置審查的基礎上，你可以手動把安全審查和精簡優化加進去，形成更完整的流水線：
/review）/security-review，手動追加）/simplify，手動追加）前兩步是subagent-driven模式自動完成的，後兩步需要你手動觸發。但審查紀律是一樣的：發現問題→修復→重新審查確認→通過後才算完成。
審查循環
每一關都可能發現問題。發現→修復→重新審查，這個循環很重要：
/review 發現Critical問題 → 你修復 → 再跑 /review → 通過/security-review 發現Important問題 → 你修復 → 再跑 /security-review → 通過/simplify 發現優化建議 → 你選擇性修復 → 再跑 /simplify → 通過不要跳過重新審查的步驟。修復一個問題可能引入新問題——比如修復安全問題時改了加密方式，可能影響登錄邏輯。重新審查能發現這類連鎖反應。
六、一個完整的例子
場景：給一個React應用添加用戶頭像上傳功能。寫完代碼後，啓動三關審查。
第1關 /review：
Critical: 上傳文件沒有校驗文件類型，任意文件都能上傳
Important: 上傳失敗時沒有清理臨時文件，會導致磁盤泄漏
Important: 文件大小限制寫在組件裏，應該抽到配置文件
Minor: handleChange 函數超過50行，建議拆分
修復：添加文件類型白名單、失敗時清理臨時文件、文件大小限制移到配置、拆分函數。再跑 /review，Critical和Important清零，通過。
第2關 /security-review：
Critical: 文件名直接用用戶上傳的原始文件名，存在路徑遍歷風險
Important: 沒有對圖片內容做校驗，可能上傳偽裝成圖片的惡意腳本
修復前先驗證：路徑遍歷風險確認存在（文件名可能包含 ../），偽裝圖片風險也確認存在（只校驗擴展名不夠）。用UUID重命名文件、用file-type庫校驗文件實際內容。再跑 /security-review，通過。
第3關 /simplify：
代碼複用：項目裏 src/utils/upload.ts 已有通用上傳函數，
你的代碼重複實現了文件校驗和上傳邏輯，建議複用
效率：上傳前先壓縮圖片的邏輯是同步的，會阻塞UI，
建議用Web Worker或requestIdleCallback
修復：複用已有上傳函數、圖片壓縮改為異步。再跑 /simplify，通過。
三關全過，提交代碼。
對比一下：如果只跑了 /review，路徑遍歷漏洞和偽裝文件攻擊不會被發現。如果只跑了 /security-review，臨時文件泄漏和代碼重複不會被發現。三關流水線的價值在於——每個維度都有專門的審查，而且每關發現的問題都經過修復和驗證閉環。
七、什麼時候該跑，什麼時候不用跑
該跑三關的場景
可以只跑第1關的場景
可以跳過的場景
審查結果互相矛盾怎麼辦
偶爾會出現這種情況：/simplify 建議刪除某段代碼（認為冗餘），但 /review 認為需要保留（處理了邊界情況）。這時候以 /review 的判斷為準——正確性優先於簡潔性。如果兩關的反饋確實矛盾，回到代碼驗證：那段代碼到底有沒有被使用、有沒有處理真實場景。
寫在最後
三個Skill各有專長：/review 保正確，/security-review 保安全，/simplify 保簡潔。單獨用任何一個，都只能看到代碼的一個側面。串成流水線，三關過完，代碼在三個維度上都過了一輪檢查。
流水線的核心不是工具多，是紀律——收到反饋先驗證準確性，確認屬實後修復，修復後必須重新審查確認，不能跳步。這種"審查→驗證→修復→再審查確認"的循環，比任何單個審查工具更重要。