adversarial-verify

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 也能單獨用——任何時候你產出了重要結論，交付前跑一次。

一句話心法

對自己的答案，預設它有一半機率是錯的，然後去證明它錯。證不倒的，才交付。