9個Skill各自冇問題，問題在於佢哋之間嘅銜接——資訊喺呢度靜靜雞流失，返工喺呢度靜靜雞發生
你遇到嘅可能唔係Skill嘅問題
你可能睇過Superpowers單個Skill嘅介紹。單個Skill的確唔難用——brainstorming會提問，TDD會逼你寫測試，code review會派獨立代理。
但真實項目唔係孤立咁用一個個Skill，而係9個Skill串成一條流水線，一個嘅輸出餵俾下一個。
我最近用Superpowers完整流程開發咗一個Python任務管理API。9個Skill各自行得好順，但最終效果打咗折扣——返工不斷，bug反覆出現，驗證通過咗但質量唔達標。
排查落嚟，原因唔喺Skill本身，而喺Skill之間嘅3個銜接位：
brainstorming到writing-plans：設計文件少寫一句說話，代理就用明文儲存密碼writing-plans到subagent-driven：計劃裏面有模糊詞，代理就「估住做」code-review到verification：審查問題未改完就去驗證，通過咗但唔達標加上5個零星嘅坑，一共8個問題。3個銜接位嘅問題貢獻咗最多嘅返工時間。
呢篇文章淨係講一件事：Superpowers執行效果點解唔達預期，以及點樣防護。
全貌：問題出喺邊度
Superpowers主流程涉及嘅Skill（按照接力順序）：
設計階段：brainstorming、writing-plans執行階段：using-git-worktrees、subagent-driven-development（代理內部行TDD + 雙重審查）收尾階段：systematic-debugging（遇到bug觸發）、verification-before-completion、finishing-a-development-branch3個銜接位標咗喺圖裏面。注意：銜接位唔係Skill，而係Skill之間嘅罅隙。 Skill內部有鐵律保護，冇咁易出錯；但罅隙裏面冇保護，資訊喺呢度靜靜雞流失。
先記住呢3個自檢點，之後逐個展開：
brainstorming做完之後：安全/邊界/依賴係咪明確writing-plans做完之後：每個步驟有無歧義code-review做完之後：審查問題係咪全部處理下面逐個講。
原因1：設計文件漏咗「顯而易見」嘅細節
邊個環節出問題
brainstorming嘅輸出係設計文件，writing-plans嘅輸入都係呢份文件。對於項目入面新加嘅需求，設計文件幾乎係writing-plans唯一嘅資訊來源。 文件冇寫嘅，writing-plans大機率唔知；writing-plans唔知嘅，代理就唔會做。
點樣發生
我嘅項目係「Python任務管理API」。brainstorming階段確認咗呢啲需求：
設計文件寫完咗，我好滿意咁進入writing-plans。
但設計文件冇寫「密碼一定要hash儲存」。
邊個會用明文儲存密碼，呢個係常識。但writing-plans讀到嘅係文件，唔係常識。佢見到「用戶註冊」呢個需求，拆出「實現註冊接口」呢個任務，步驟寫咗「儲存用戶資訊」——冇指定hash。
代理執行時，按最簡單嘅方式實現：直接將密碼存入數據庫。測試通過咗，註冊成功，登入成功。直到code review先發現密碼係明文儲存。
點解Skill冇攔住
brainstorming Skill本身有自審環節，會檢查佔位符同矛盾，但佢關注嘅係功能接口係咪完整，唔會主動檢查安全、性能呢啲非功能需求。認證方式（密碼hash算法）屬於接口層面嘅設計決定，但brainstorming預設唔會逐項確認呢類細節。
問題出喺銜接：設計文件係brainstorming嘅「功能視角」產物，但writing-plans需要嘅係包含實現細節嘅「可執行視角」輸入。 呢個視角轉換，冇Skill負責。
點樣防護
brainstorming結束之後、進入writing-plans之前，加一個5分鐘嘅自檢：
安全自檢（3項）：
認證/授權方式係咪明確（密碼hash算法、JWT過期策略、token儲存方式）數據校驗規則係咪明確（電郵格式、密碼強度、輸入長度限制）敏感數據處理係咪明確（日誌脱敏、錯誤資訊唔泄露內部狀態）邊界自檢（3項）：
6項過完，我嘅設計文件多咗4行：
認證方式：bcrypt hash + JWT（python-jose），token過期30分鐘4行字，我估算咗嚇慳咗大概1個鐘返工。
呢類坑嘅變種
唔止「密碼hash」。任何「顯而易見」嘅實現細節都可能喺呢度流失：
「用戶登入」冇指定hash算法，導致代理用明文儲存密碼「獲取任務列表」冇指定分頁參數，導致一次查10萬條數據，接口超時規律：需求描述越「顯而易見」，實現細節越容易流失。 因為「顯而易見」嘅嘢唔會被寫入文件——但代理淨係讀文件。
原因2：計劃裏面嘅模糊詞令代理「估住做」
邊個環節出問題
writing-plans嘅輸出係一份實現計劃，subagent-driven為每個任務構造代理指令。代理指令係代理唯一嘅資訊來源。 計劃裏面嘅每個詞，代理都會照字面意思執行；計劃冇嘅，代理就自己估。
更重要嘅係，代理唔知道自己唔知啲乜。 「含密碼hash」呢5個字對代理嚟講睇落已經夠明確，佢唔會觸發NEEDS_CONTEXT去問更多資訊——因為佢根本意識唔到仲有「用邊個庫」呢個問題需要問。
點樣發生
writing-plans階段，我為「用戶註冊+登入」拆咗呢啲任務步驟：
睇落冇問題——原因1嘅自檢後我加咗「密碼hash」，寫咗入步驟。
但「含密碼hash」呢5個字係模糊嘅。 用邊個庫，hash幾次，salt點樣生成。代理唔知，就自己揀咗一個：passlib.sha256_crypt。
登入接口嘅代理係另一個新代理，佢都見到「含密碼hash」，都自己揀咗一個庫：bcrypt。
兩個代理揀咗唔同嘅hash庫。註冊時用passlib hash，登入時用bcrypt驗證——驗證永遠失敗，但單元測試各自通過（因為每個代理淨係測咗自己嗰部分）。
直到集成測試先發現：註冊成功，登入失敗。
更常見嘅情況係：同一個庫但用法唔一致。例如註冊代理用 bcrypt.hashpw() 做hash，登入代理都用 bcrypt.verify() 驗證，但傳參順序或編碼方式唔同，同樣導致驗證失敗。呢種細微差異比「揀咗唔同庫」更容易發生，亦更難排查。
點解Skill冇攔住
writing-plans Skill本身有自審環節，會檢查佔位符同規範覆蓋，但佢檢查嘅係「有冇佔位符」，唔係「有冇歧義」。「含密碼hash」唔係佔位符，但佢係模糊詞——兩個代理可以做出唔同理解。
問題出喺銜接：計劃係俾人讀嘅「意圖描述」，但代理需要嘅係「執行指令」。 意圖描述容許模糊，執行指令唔容許。
點樣防護
writing-plans完成之後，加一個5分鐘嘅「代理視角自檢」：扮你係一個零上下文嘅代理，淨係讀計劃，可唔可以冇歧義咁執行每一步。
具體做法：揾出計劃裏面嘅「模糊詞」，替換為「精確指令」。
「含密碼hash」 替換為 「使用bcrypt庫，bcrypt.hashpw(password.encode(), bcrypt.gensalt())，驗證用 bcrypt.checkpw(password.encode(), hashed)"「含JWT生成」 替換為 「使用python-jose庫，from jose import jwt; jwt.encode(payload, SECRET_KEY, algorithm='HS256')"「實現分配邏輯」 替換為 「校驗assignee_id對應嘅用戶存在（調用user_repository.get_by_id），唔存在返回404」「運行測試」 替換為 「運行 pytest tests/test_auth.py -v，確認0個失敗」判斷標準：如果同一個步驟，兩個唔同嘅代理可能做出唔同實現，呢個步驟就係模糊嘅。
我嘅項目，過完自檢後計劃從簡略步驟變成了精確指令。多咗15分鐘寫計劃，但估算慳咗大概1.5個鐘返工。
呢類坑嘅變種
「校驗用戶存在」：查數據庫定係查緩存，緩存同數據庫唔一致時行為唔同「返回錯誤」：返回400定係422，客戶端處理邏輯唔同規律：計劃裏面任何需要代理「判斷」嘅地方，都係潛在嘅資訊流失點。 將判斷變成指令，資訊就唔會流失。
原因3：審查問題未改完就去驗證
呢個原因實際上包含兩層問題：一層係人違反咗鐵律，一層係Skill間嘅資訊斷層。必須分開睇。
邊個環節出問題
code-review嘅輸出係審查問題列表，verification檢查嘅係「你係咪真係跑咗測試、結果係咪通過」。審查問題係咪已經修復，直接影響代碼質量——但verification本身唔檢查審清清單。
點樣發生
任務2（用戶註冊+登入）嘅code review發現咗2個Important問題：
我睇咗呢兩個問題，覺得「電郵校驗後面統一加，響應時間唔影響功能」，就標記咗「已知，後續處理」，直接進入verification。
verification跑咗一遍：32個測試全綠，規範覆蓋逐條對齊，睇落冇問題。
但verification驗證嘅係「測試係咪通過」，唔係「審查問題係咪修復」。 佢嘅職責係確認你唔係空口講「搞掂咗」，而係有測試結果做證據。審查問題係咪修復，唔喺佢嘅檢查範圍內。
到任務5（用戶資料編輯）時，代理都需要校驗電郵——但唔知任務2嘅校驗邏輯係乜（因為根本冇實現），就自己寫咗一套。兩套校驗邏輯唔一致，集成測試時暴露咗。
兩層問題
第一層：人違反咗鐵律。 subagent-driven-development Skill嘅鐵律要求審查問題一定要修復後先可以進入下一個任務。我跳過咗呢條鐵律。但現實中，「已知，後續處理」呢種標記太容易矇混過關——Skill嘅鐵律係靠人執行嘅，人會偷懶。
第二層：verification唔知審查留低咗啲乜。 就算鐵律要求先修再驗證，verification本身都冇機制檢查「有冇未處理嘅審查問題」。佢淨係睇測試結果同規範覆蓋，唔睇審清清單。呢個唔係verification嘅設計缺陷——佢嘅職責就係驗證測試通過，唔係檢查審清清單。但正因為職責係咁，審查同驗證之間需要一個額外嘅銜接環節。
點樣防護
加一個硬規則：verification之前，一定要過一遍審清清單。
每個審查問題一行，標註狀態：
Important: 電郵格式校驗 — 已修復（commit abc123）Important: 響應時間固定 — 已修復（commit def456）全部Important修復後，先進入verification。 呢份清單唔係可選嘅，而係verification嘅前置門禁。
呢類坑嘅變種
Important問題標記「後續處理」，verification通過但質量唔達標，後續任務基於有缺陷嘅代碼開發Minor問題直接無視，小問題積累成大問題，技術債務越積越多規律：審查同驗證之間一定要有一個「修復確認」環節。 跳過咗，驗證就係盲目嘅。
3個原因嘅共性
3個銜接位有一個共同特徵：喺Skill嘅自動流程中，前置Skill嘅產出假設已完成而且唔可以更改，後續Skill唔會回頭補。
brainstorming冇寫嘅，writing-plans唔會自己加上去計劃裏面嘅模糊詞，代理唔會返嚟問「你係咩意思」——因為佢唔知自己需要問乜審查發現嘅問題，verification唔會自動檢查係咪修復——因為佢嘅職責唔包括呢項Skill內部有反饋循環（審查唔通過可以打回頭改），但Skill之間冇——資訊只會流失、唔會補充。如果有人介入返返上一步修正，可以彌補，但Skill本身唔會觸發呢個回退。
防護嘅核心思路：喺每個銜接位加5分鐘自檢，確保資訊唔會喺罅隙裏面流失。
| | |
|---|
| brainstorming到writing-plans | | |
| writing-plans到subagent-driven | | |
| | |
3個自檢，約15分鐘。但慳返嘅返工時間，喺我呢個項目入面遠遠超過呢個數。
自檢方案嘅侷限： 自檢靠人執行，都可能漏。如果你發現自檢清單本身成日漏項，可以考慮將清單固化做模板，每次對照打勾。對於極簡單嘅項目（例如得一個代理嘅單任務），原因2（兩個代理揀唔同庫）冇咁易發生，自檢可以簡化——但原因1同原因3嘅自檢仍然建議做。
其他5個容易踩嘅坑
除咗3個銜接位嘅問題，仲有幾個零星嘅坑都會令執行效果打折扣：
坑1：git-worktree入面唔記得裝依賴。 worktree係代碼副本，唔包含虛擬環境。創建後一定要重新 pip install，唔係代理跑pytest會報ModuleNotFoundError。
坑2：DONE_WITH_CONCERNS唔可以跳過。 任務5嘅代理返回「狀態轉換校驗可能唔完整，淨係校驗咗正向轉換，冇處理回退」。我一開始覺得回退唔需要，跳過咗。集成測試時發現真實場景的確需要回退。代理嘅疑慮唔一定啱，但一定要認真讀一遍再決定——佢嘅誤報率唔高，值得逐條審視。
坑3：驗證證據一定要新鮮。 我話「頭先跑過測試」，AI要求重新跑——因為中間改咗bug，舊結果唔可以證明當前代碼冇問題。「頭先跑過」唔算驗證，一定要用當前代碼重新跑。
坑4：debugging先查根因。 集成測試報401，我第一反應係「token過期咗」，想直接加token refresh邏輯。用systematic-debugging排查後發現：註冊接口同登入接口分別喺唔同嘅配置文件中定義咗SECRET_KEY預設值，兩個值唔一致——註冊簽出嘅token，登入嗰邊驗唔到。醫症狀唔醫根因，bug會換個方式再嚟。正確做法係先定位根因（比較兩邊嘅SECRET_KEY），再修（統一到一個配置源）。
坑5：多個代理修改同一文件。 任務2嘅代理喺 utils.py 入面加咗密碼hash函數，任務3嘅代理都喺 utils.py 入面加咗日期格式化函數。兩個代理各自基於原始文件修改，後提交嘅代理可能覆蓋前一個代理嘅改動。subagent-driven-development會做代碼合併，但如果兩個代理改咗同一文件嘅唔同位置，合併邏輯有時會甩咗其中一個改動。防護方法：喺計劃中明確每個代理負責嘅文件範圍，避免多個代理改同一個工具文件。
最終數據
3個銜接位貢獻咗8個坑入面嘅3個，但返工時間佔比最大（約70%）。呢個唔係巧合——銜接位係資訊流失嘅地方，資訊流失係返工嘅根因。
3分鐘上手
如果你已經識用Superpowers嘅單個Skill，但未跑過完整流程，按呢個順序行，每個銜接位停5分鐘自檢：
/superpowers:brainstorming 做完，自檢：安全/邊界/依賴係咪明確/superpowers:writing-plans 做完，自檢：每個步驟有冇歧義/superpowers:using-git-worktrees 創建隔離空間，記得裝依賴/superpowers:subagent-driven-development 逐個派代理（代理內部行TDD + 雙重審查），認真讀DONE_WITH_CONCERNS，明確每個代理負責嘅文件範圍遇到bug用 /superpowers:systematic-debugging，先查根因code review做完，自檢：審查問題係咪全部處理/superpowers:verification-before-completion 強制驗證，證據一定要新鮮/superpowers:finishing-a-development-branch 合併收尾3個自檢，約15分鐘，慳幾個鐘返工。 如果你淨係做1個，做原因2嘅自檢（計劃有冇歧義）——代理唔會返嚟問你，佢會自己估，估錯咗到審查先發現，審查冇發現就到上線先發現。
掃碼關注「AI智聞說」，每日3分鐘掌握AI新知識
