blind-reviewlisted

# /blind-review — 對抗式審查與導讀 要人看一份 AI 寫的改動之前，先做兩件事： **找一雙沒有前情的眼睛去攻擊它**，再**把當初的取捨寫下來**， 最後交出去的不是裁決，是一份**導讀**——告訴人該把注意力放在哪。 > 🤖 Astromech 時刻：R2 插進 Death Star 的接口時，沒讀過任何作戰簡報。 > 也正因為沒有前情，它讀回來的是儀表上真的亮著的那盞燈，不是你以為應該亮的那盞。 ## 為什麼需要 - **自審的上限是脈絡，不只是模型。** 寫東西的那個代理，是沿著一串假設一路推過來的； 叫它「再檢查一次」，它會沿著同一串假設再走一遍，然後確認自己本來就相信的事。 這裡換掉的是**脈絡**——攻擊者拿不到對話，所以繼承不到那串假設。 （想換的是**模型家族**，那是 [`ai-review`](../ai-review/SKILL.md) 的工作。兩者可以疊。） - **人要看 diff 之前，缺的不是裁決是導讀。** 「通過／不通過」告訴你結果， 不會告訴你該盯哪三行。冷讀一份幾百行的 diff，人會平均分配注意力—— 而風險從來不是平均分布的。 - **當初為什麼這樣選，只有主代理知道。** 那些取捨活在對話裡，對話一關就蒸發， 然後半年後沒人答得出「這裡為什麼不用另一種寫法」。導讀是把它落檔的最後機會。 ## 步驟 ### 0. 界定範圍並凍結 先講清楚審的是什麼：某個 PR、某條分支對主線的差異，還是工作區當下的未提交改動。 **記下當下的版本識別碼（提交雜湊，或 diff 的雜湊）並寫進最後的導讀。** ⚠️ 這步是防 TOCTOU 的：送審之後又改了東西，審的就是舊版，而導讀不會自己知道。 沒有識別碼，事後誰也證明不了那份導讀對應的是哪一版。 ### 1. 派攻擊者（子代理，旗艦檔） 給它**只有兩樣東西**：改動本身，加上一句原始需求。 🚫 **不要把對話摘要餵進去**——那正是要隔離的東西。餵了就退化成自審。 工具給唯讀就好（讀檔／搜尋／跑測試），**不給寫入**。攻擊者的產出是意見，不是提交。 攻擊沿兩軸，各自有硬性收件標準： - **正確性** —— 只收「**具體輸入 → 錯誤輸出**」形式的失敗劇本。 🚫 「這裡可能有問題」「建議加強錯誤處理」一律退回：講不出怎麼觸發，就不是發現。 優先攻邊界值、空集合、併發、失敗路徑、以及「安靜失敗」（回報成功但實際沒做到）。 - **簡潔性** —— 重複的邏輯、可以整段刪掉的東西、為了想像中的未來寫的抽象層、 以及**早就存在卻沒複用的既有機制**。這一軸的價值在於：寫的人正忙著讓它跑起來， 沒有餘裕問「這段是不是根本不必存在」。 ### 2. 主代理補「假設與設計決策」 這段**只有主代理寫得出來**，因為只有它經歷過那些取捨。逐條寫，每條四行： ``` 決策：<做了什麼選擇> 當時的選項：<還有哪些做法> 選這個的理由：<為什麼> 什麼情況下這個選擇會錯：<失效條件> ``` 最後一行是重點，也是最容易被跳過的一行。寫不出失效條件，通常代表那不是個決策， 是個沒意識到自己在選的預設值——那本身就值得寫進導讀。 ### 3. 產出導讀（三段，就這三段） 1. **先看哪裡** —— 最多三處，每處給位置（檔案與行）＋一句「為什麼是這裡」。 超過三處等於沒有重點。排序依據是「錯了傷害最大」，不是「改動行數最多」。 2. **假設與設計決策** —— 步驟