| name | adversarial-verify |
| description | 把你剛產出的結論、code、修復、或設計，spawn 一個獨立 agent 去「對抗式複查」—— 預設它有高機率漏抓，任務是找漏洞而非肯定。 觸發時機：剛完成一個重要結論/修復/架構設計，交付前想確認；或改了高風險的核心。 手動召喚：/adversarial-verify。hook 只能提醒、不能真的開第二個 agent 去驗，這個 skill 補上。
|
adversarial-verify — 對抗式自我驗證
把「我覺得做對了」變成「我讓一個專門找碴的獨立視角驗過了」。
為什麼需要它
模型（包括很強的）對自己剛產出的東西有確認偏誤——傾向相信自己對。single-pass 的結論，
經獨立對抗複查後被推翻的比例出乎意料地高（經驗上常達半數）。
最便宜的保險，就是在交付前花一次 spawn，讓一個「預設你錯」的視角來挑。
什麼時候用
- 剛下了一個重要結論（「根因是 X」「這個沒人用可以刪」「要重構 N 週」）
- 剛做了高風險改動（動核心模組、動很多人依賴的東西、不可逆操作前）
- 剛產出要交付/發布的東西（給別人的報告、要 merge 的 PR、要上線的設計）
簡單、可逆、低風險的事不必每次都驗——那會變成儀式。
怎麼做
步驟 1：把待驗證的東西列成清單
把你的結論/改動拆成一條條可單獨檢驗的 claim。例如：
- 「
foo.py:42 的 cache 沒生效」← 一條
- 「這個 module 沒有 caller，可以刪」← 一條
- 「這次改動不會影響登入流程」← 一條
模糊的「我覺得整體 OK」沒法驗——拆成具體 claim 才驗得動。
步驟 2：spawn 獨立 agent 去 refute（不是 review）
關鍵在 prompt——叫它反駁，不是「幫我看看」：
以下是一組待驗證的 claim。你的任務是「推翻」它們，不是肯定。
預設每一條都有 60% 的機率是錯的。對每一條：
- 用 ls / grep / 讀真實檔案 / 跑指令 去找「它是錯的」的證據
- 找不到反例，才勉強標「暫時成立」
- 絕對不要用「想的」或「應該」——必須是真實 evidence
不確定時，預設站在「它是錯的」這一邊。
待驗證 claim：
1. ...
2. ...
「找碴」的 prompt 比「review」的 prompt 抓到多得多——因為後者會傾向附和。
步驟 3（重要的話）：多視角驗
如果這個結論很關鍵，不要只用一個 agent 從一個角度。派不同 agent 用不同 lens：
- 正確性：邏輯/事實對嗎？
- 安全性：有沒有引入風險？
- 可重現：宣稱的問題真的會重現嗎？跑一次看看
- 邊界 case：極端輸入、空值、並發下會不會壞？
不同 lens 抓到的是不同類的漏，redundant 的同款 agent 抓不到。
步驟 4：收斂
- 被推翻的 claim → 丟掉，別嘴硬找補
- 存活的 claim → 才是可交付的
- 如果大部分被推翻 → 警訊：你原本的整個框架可能就錯了，回去重想，不是補一條條
一句話流程
拆成具體 claim
→ spawn 獨立 agent「預設你錯，去 refute，必看真實證據」
→ （關鍵結論）多 lens 各派一個
→ 被推翻的丟掉，存活的才交付
跟 deep-work 的關係
deep-work 的階段 2（對抗式反思）可以直接呼叫本 skill 來挑戰計畫。
本 skill 也能單獨用——任何時候你產出了重要結論，交付前跑一次。
一句話心法
對自己的答案，預設它有一半機率是錯的，然後去證明它錯。證不倒的，才交付。
