Advisor：換顆腦袋，不用換整個 session
起點是 2026 年 9 月初的一個念頭：平常跑主流程的那顆比較便宜的模型，對它某一次的思考不滿意，當下能做的只有把整個 session 換成強模型讓它重想。那能不能改成只把這一次的思考外包出去？
這種狀況我反覆碰到：主對話裡的模型幹活幹得好好的，偏偏在某一次判斷上給出一個讓人直搖頭的方案。這時候手邊最直覺的處置，往往是把整個 session 換成更聰明、更貴的頂級模型，讓它把整場對話重新想一遍。
但這件事的代價其實很大。後續所有小修改、跑指令、讀小檔的瑣事，全部都得跟著掛在昂貴頂級模型的帳上。為了買單一次判斷失誤，後面所有對話都得跟著陪葬，怎麼想都不划算🤣。
我之前在最強模型不是每件事都該用提過模型分工的概念，也提過「顧問」（advisor）這種做法存在。但真正在終端機裡幹活時，核心問題只有一個：我能不能只把眼前這顆卡住的腦袋換掉，而不用把整場工作打掉重來？這篇講的就是我實際怎麼用顧問。
換一題，不換整場
解法的本質很直接：可換的單位是「這一題」。主流程上的模型繼續負責原本的實作與執行，只有眼前這道需要第二意見的題目，被獨立打包送出去給另一顆模型當顧問。
我把這件事做成自己 Claude Code 裡的一個 /advisor 指令。它不是什麼自動化系統，就是把下面五步固定下來，每次由我手動觸發：
- 說清楚要判斷什麼：把核心爭點獨立出來，不讓顧問在無關脈絡裡瞎猜。
- 確認顧問看得到什麼：這一步講的是工具能力，弄清楚這位顧問能不能自己查本機檔案與跑指令。
- 決定給它什麼材料：這一步講的是打包內容，要不要把我現有的答案一起給它。
- 意見回來逐條裁決：對顧問提的每項意見明確做出處置，裁決的人是我，不是主對話的模型。
- 原流程繼續：把裁決後的結論帶回主對話，繼續原本的工作。
打包與送出的方式看顧問是誰：網頁版是把打包好的文字送進網頁、意見貼回來；本機 agent 與 CLI 則由指令直接派出去、結果直接回來。不管哪一種，最後一步都是我看著意見做決定。
這套動作看似單純，但真正決定顧問有沒有用的關鍵，落在第三步：你到底餵了什麼給它看。所以我先講第三步，再回頭講第二步。
盲審：把自己的答案拿掉
我原本以為給顧問看材料，重點在於資訊給得夠不夠完整，後來才發現根本不是這麼一回事。
一開始的設計裡，材料只有兩條路徑：要嘛由我手動濃縮問題與結論，要嘛由程式自動抽出整段對話正文（只有對話文字，不含工具執行紀錄，所以也不算完整脈絡）。結果把這套設計送去給顧問審查時，顧問直接指出這是個假兩難：
「不是讀原 agent 的摘要，就是讀原 agent 的全部思考。你們沒有留下第三種模式——只給原始任務、可驗證證據、限制條件與產出，刻意拿掉原 agent 的結論與辯護。」
這段意見點破了問題的核心。如果把主對話模型的推論與結論原封不動附上，顧問很容易順著既有思路走，變成在同一個框架裡挑小毛病，抓不到結構層面的盲點。顧問當時也順帶說了一句：給了完整思考的那位顧問，抓到大量細節缺陷，卻沒有退一步問這件事該不該做成這種形式。這是那次意見裡的說法，我沒有另外獨立核對。
這就是盲審模式的由來：保留原始任務、客觀證據與限制條件，但把主對話模型自己的答案與辯解全部拿掉，逼顧問從零開始獨立想一遍。這條意見我接受了，盲審模式和逐條裁決兩項隨後就寫進 /advisor 的流程裡。
要注意的是，盲審不是通則。要顧問自己想一遍，就用盲審拿掉答案；要顧問挑現有答案的錯，就把答案連同理由一起給它。後面那個講顧問的頁面被抓包的例子，用的是第二種。
選顧問看它能查到什麼，不看誰聰明
我把每一個可選的顧問叫一「席」。選席的時候，我自己最容易犯的毛病就是去比誰比較聰明。但決定一席顧問能審哪一層的，只有一件事：它能不能自己查本機資料。
目前我的選單上有三席：
- 帶全套工具的本機 agent（我這裡是 Fable）：適合審實作層。它能自己去翻程式碼、跑指令，核對實作細節與宣稱是否一致。
- 能讀檔跑唯讀指令的 CLI（我這裡是 Codex）：能自己核對證據，所以除了實作層，也查得出方法層的問題。
- 只看得到送進去文字的網頁版（我這裡是 ChatGPT Pro，下面叫它 Web Pro）：適合審思路框架層。它碰不到你的本機環境，只能專注看論證有沒有跳步、問題設定本身合不合理。
順帶提一下，「顧問不動手改檔」這個保證，三席的強度不一樣。網頁版與唯讀 CLI 由執行機制強制擋住；帶全套工具的本機 agent 只靠 agent 定義裡寫的唯讀紀律，是自律，不是機制。這是我知道並接受的取捨，換的是它能自己查證。
能力軸決定「這席能審哪一層」，但同一層裡挑哪一席，就是個人偏好了。我目前最常用的是 Web Pro，理由有三個：第一是思考全面，這是我個人的使用判斷，不是量測結果；第二是它沒有 agent 能力，給的是不同於 agent 的思考角度；第三是截至 2026 年 9 月為止，它的網頁額度與 Codex 的額度是分開計算的，多問幾次不會吃到我派工用的那份。
意見回來必須逐條裁決
用顧問時我自己最大的問題，就是意見看完了、點點頭覺得很有道理，然後轉身回主對話繼續照舊寫程式。這種諮詢等於白做。
顧問給出的意見不是聖旨，但必須被嚴肅處理。我在 /advisor 的流程裡寫了一道規則：顧問提了幾條意見，裁決清單就必須有幾條對應的結果，做決定的是我。
處置方式只有三種：
- 接受：確認意見屬實且具體，並將修改納入後續步驟。
- 拒絕：必須附上明確的反證或具體理由，不能單憑直覺略過。
- 待驗證：必須寫出清楚的驗證方法與驗證時機，不能當作拖延藉口。
如果沒有這道逐條裁決的關卡，顧問的意見就只是終端機裡隨風飄過的字串，完全無法對後續工作產生任何實質拘束力。
當講顧問的頁面被顧問抓包
這套機制有沒有用？最近就有一個非常有趣的真實案例。
我做了一份給同事看的模型分工分享頁，裡面有一節在講顧問怎麼用。發布前為了確認論點嚴謹，我把整份頁面連同結論打包送去給 Web Pro 審，這次要的是挑錯，所以不套盲審。顧問回來的意見裡，直接抓到頁面自己定義上的矛盾：
「文稿用『交出去做事／借進來判斷』區分 orchestrator 與 advisor，卻無法用這個判準區分自己的兩個案例。」
先解釋一下這句在講什麼。頁面把「派工」（orchestrator，把工作交出去）和「顧問」（advisor，把判斷借進來）並列成兩種做法。顧問在回覆附的依據裡寫得很直接：頁面同一章把審查工作列為派工，但後面章節裡那個負責審查的 agent 案例，實際上也是提供判斷、由主流程保留決策與修改，完全符合頁面自己對顧問的描述。「問題不在於兩種做法不能並列——並列不必代表互斥——而是文稿宣稱的分界，在自己的 reviewer 案例上失效。」顧問的結論是：分界劃得比兩者實際的差異更鮮明，不是兩種做法不成立。
這條意見我接受，因為它能回原文直接核對：頁面確實拿了一個自己都無法自洽的標準去劃分概念。後來我把分界改成「交出去的是有驗收條件的工作，還是對自己判斷的第二意見」，頁面也照這條改過了。
那次審查的意見我全部接受，理由全是因為每條都能回文件或原文逐一核對，跟顧問本身的權威毫無關係。除了上面那條邏輯問題，另一條是事實更正：頁面原本寫「subagent 看不到主對話歷史」，但根據 Claude Code subagents 官方文件，有一種 fork 模式會繼承整段主對話。頁面把通則寫成了全稱、漏了例外，回文件一查就一清二楚（非 fork 的自訂 subagent 確實仍不繼承）。顧問也順手把頁面裡那張用量與費用表的數字獨立重算了一遍，結果與頁面一致。
顧問整體的評語是「整體論證大致成立，沒有發現足以推翻模型分工主張的問題。」這正是一次健康的顧問審查：保住整體論證，同時精確挑出一個我自己看不見的定義漏洞。
疊個甲，以及動手前的三個問題
當然，最後照慣例還是要疊個甲。
這篇文章提到的兩個事件，盲審模式的誕生和頁面被抓包，都是單次觀察，大家千萬不要自己腦補，變成「用了顧問就能省下百分之幾的額度」之類的神話。我不想付整場換模型的代價是動機，但省了多少我沒量過。這套用法也還在觀察期，我自己還沒用足夠多的真實任務驗證它。
至於觸發機制，現在依然把觸發權扣在人手上。當時另一個選項是讓它在固定節點自動觸發，我的決定是：「不然先手動好了，真的好用再檢討」🤣。這是先後順序，不是原則。
下次當你對終端機裡 AI 的某次判斷感到猶豫或不滿意時，在急著把整個 session 換成頂級模型之前，不如先停下來問自己三個問題：
- 你要它挑現有答案的錯，還是自己獨立想一遍？（這決定了你要不要用盲審拿掉既有答案）
- 這席顧問看得到什麼資料？（這決定了它適合審實作細節，還是審框架邏輯）
- 意見回來之後由誰最後裁決？（這決定了這場諮詢到底會不會改變接下來的程式碼）
換一題，不換整場。先把單次判斷外包做好，很多時候根本不需要讓整個對話大費周章換腦袋。