Claude Code advisor 教學：主模型遇到卡關時，如何請第二個模型檢查？
Claude Code advisor 可在長任務中取得第二模型意見。本文整理官方啟用命令、配對、狀態、功能旗標與用量，並用檔案與測試檢查真正結果。
長時間使用程式代理，常遇到一種情況：日常修改很順，但一個錯誤反覆出現，模型仍沿著同一個方向重試。最近 X 上關於 Claude Code advisor 的討論受到關注。
這項工具讓目前工作的 Claude 在需要時向另一個模型請教，提供規劃或檢查意見。
實際使用前，應先看官方文件。社群貼文中的省錢比例、速度與組合命令，不能直接當成官方保證。
本文依 Claude Code advisor 檔案整理啟用、觀察與驗收方法，沒有實測某個模型組合的成本差異。
advisor 如何參與目前的工作
官方說明將 advisor 定位為伺服器端的實驗性工具。主模型可以在任務中向另一個通常更強的模型請教，再根據建議繼續。
第二個模型會收到完整對話，包括工具呼叫與結果，因此它看到的不只是一句簡短問題。
主模型仍負責後續工作。advisor 提供意見，不等於另開一個代理完成所有修改。它也不是每次回答都會參與，呼叫時機由模型判斷。這個區別會影響你如何設計需求與觀察結果。
如果主模型已有證據與建議衝突，官方文件描述它可以指出問題並調整。使用者仍應看實際檔案與測試，不能只因兩個模型都看過，就把結論當成已經驗收。
先選一個真的需要第二意見的任務
advisor 比較適合有多個步驟、方向選擇會影響結果的工作。可以從一個反覆出現的錯誤開始，例如測試失敗一直被同一種修改掩蓋，或修改跨幾個相依元件，先需要確認原因。
單純改一個錯字通常沒有太多規劃可檢查。第一輪也不必為了試新功能，把小任務擴大成全面重構。保留原本目的，讓第二意見處理真正的不確定處，才容易判斷它是否有幫助。
先寫下完成條件。修復哪個具體錯誤、哪些行為應恢復、哪個最小測試能證明，都應該清楚。第二個模型看到更完整的標準，才有機會檢查方向，而不只是給出一般建議。
啟用前先核對帳號與模型條件
官方文件說明 advisor 需要 Anthropic API 路徑，可供訂閱與 API 計費帳號使用。所列的第三方雲端模型平臺並不支援。
使用代理閘道時，還要看它是否完整轉送相關請求。本文不把「能使用 Claude」等同於一定能使用 advisor。
主模型與 advisor 也有配對限制。模型家族與版本會更新，應看官方目前的配對表與自己帳號的可用選項。組織若限制可用模型，選擇也需要符合該設定。
不要把某個社群命令貼上，就假設它適用所有環境。
開始時先確認目前主模型。若它已是很強的模型，第二意見的用途可能是檢查，而不一定是節省費用。把目的寫清楚，後面才知道應看成本、方向改善，還是最終錯誤是否減少。
在目前對話中選擇 advisor
互動使用時，可以輸入以下官方命令，開啟可用模型的選擇介面：
/advisor
也可以依相容條件指定模型別名，例如：
/advisor opus
確認介面回報所選模型與是否啟用。官方說明這項選擇通常會儲存為預設，某些情況則只對目前對話生效。這會影響下一次啟動時的狀態，因此試用後應再檢視設定，不要只記得自己曾經輸入命令。
如果系統指出目前配對不支援，先核對模型與版本，按檔案處理。沒有看到呼叫，不一定是任務太簡單，也可能是設定根本未生效。先確認狀態，再討論效果。
官方也說明 advisor 需要取得 Anthropic 功能旗標。如果環境以 DISABLE_TELEMETRY 等設定停用了相關旗標取得，工具可能保持關閉。
先核對組織允許的設定，再依文件排錯，無需自行改動其他環境條件。
只想試一次，可以在啟動時指定
官方也提供單次會話的啟動旗標：
claude --advisor opus
它與儲存的 advisorModel 設定有不同作用範圍。想評估一個任務而不改預設時，這種方式比較容易讓條件清楚。啟動時仍需符合模型、帳號與組織要求。
出現錯誤應讀取原因，而不是自行增加未核對的旗標。
本文只採用官方已描述的 advisor 命令。若社群貼文另外搭配 subagent 或其他引數，應分別查證它們的實際語法與用途。
顧問請教與委派子任務是不同的工作安排，不能只因寫在同一行就當成必要組合。
持續使用時，也可以在對應設定檔指定 advisorModel。第一次試作先採用單次或互動方式即可，避免同時修改多份設定後難以知道哪一份生效。
提示詞可以指出何時需要檢查
例如：「這個錯誤已重現兩次。請先確認失敗原因與受影響範圍，必要時請 advisor 檢查方向。只修改完成修復所需的檔案，修正後跑對應最小測試。若建議與檔案證據不同，請說明衝突。」
這份需求把問題、範圍與完成條件連在一起。它不會強制創造更多步驟，也不要求無關重構。你仍需提供實際錯誤與可重現資料。advisor 能看到完整對話，不代表對話裡原本沒有的條件會自動出現。
官方說明沒有設定可硬性限制或強制呼叫次數。你可以在需求中表達偏好，但不能把「只請教一次」寫成工具已保證的限制。若必須精確控制每一個外部請求，應另行評估合適的執行方式。
看 Advising 與完成狀態
請教發生時，對話會顯示 Advising 與模型資訊。返回後可能顯示 Reviewed、Declined 或 Unavailable。
這些狀態有不同含義：收到檢查、拒絕提供意見，或呼叫失敗，不能全都當成第二個模型已完成審查。
Reviewed 也只是說明顧問看過這份對話。若有可讀建議，官方提供以 Ctrl+O 檢視內容的方法。你應看它指出的方向是否具體，以及主模型後來做了什麼，而不只是看到狀態就結束評估。
出現 Unavailable 時，保留必要錯誤與目前條件，按檔案排查。不要把失敗當成正常「顧問沒有意見」。先讓原本任務保持可追蹤，再判斷是否需要更換配對或關閉這次試用。
建議回來後，回到檔案與測試證據
顧問可能提出一個合理方向，但它仍需經過實際檢查。比如建議某個設定造成失敗，主模型應檢視對應設定與重現結果，而不是把推測直接寫進結論。多一個模型不會消除核對的必要。
如果建議指出缺少資料，先補最小必要內容。完整對話可能很長，但仍可能沒有版本、輸入或正確預期。將這些條件補清楚，比繼續重試同一個模糊問題更有用。
完成後檢查相關變更與最小測試。修復一個模組，就先確認該模組。跨模組修改或新的失敗，再擴大檢查。驗證範圍應對應實際影響，不能只因啟用顧問而增加一整套無關測試。
先保存能重現的失敗，再請顧問查看
一個有用的錯誤描述可以包含觸發操作、實際結果、預期結果與必要版本。比如某個表單在送出後缺少指定欄位，就保留最小輸入與回應，指出是哪一欄。
這會讓主模型與顧問有同一個可檢查問題，而不是只看到「又壞了」。
如果已有兩次失敗修改，簡短列出每次做了什麼與結果。顧問收到完整對話，但清楚摘要仍能幫助追蹤：哪個猜測已被排除、哪個原因還沒有證據。保留真正需要的資料，也能避免主線被大量無關內容淹沒。
得到新方向後，先確認它是否能解釋失敗。需要新增觀察時，只補能區分原因的步驟。不需要為了讓顧問有事可做而重新檢查整個專案。診斷應逐步縮小問題，最後回到原本的完成條件。
升級工具後先確認你使用的入口
官方文件列出不同入口與版本要求。終端互動、桌面或非互動方式可能有不同顯示，因此試用前確認目前版本與對應說明。本文命令是官方語法示例，並非本站已在你的環境完成啟用。
更新後只重測受影響的啟用、狀態顯示與配對。原本已確認的業務邏輯不需要因為工具更新全部重寫。若新的版本改變預設模型，記錄實際選擇，再開始下一個比較任務，讓兩輪結果仍能被理解。
完整對話會帶來額外消耗
advisor 每次讀取目前對話，會產生自己的輸入與輸出用量。對話越長，這項成本越需要注意。主模型較省資源，不代表加上強模型顧問後一定更便宜。還要看呼叫次數與整個任務需要多少修正。
官方將 advisor 消耗計入會話總量。API 與訂閱的計算方式不同，特定模型也可能有額外使用額度條件。第一次試用可以記錄啟用前後與任務完成時的用量，對照同類工作的修正時間。
不要只比較一輪回答價格。若某個組合少重試幾次，整體可能改善。若頻繁請教卻沒有改變方向，總消耗可能增加。需要自己的完整任務記錄，才能決定這種分工是否適合。
一份小型比較表就能開始評估
挑兩個相近的已知問題，保留輸入、完成標準與環境。記錄是否啟用 advisor、主模型、所選顧問、是否實際呼叫，以及最後測試結果。這份表不需要追求廣泛模型排名，只要能回答你的工作問題。
再記錄人工介入與總等待。一次成功但需要大量手動修正，與幾次回合後獨立完成，是不同結果。若某次資料不足，也應單獨記下，避免把任務條件不同誤當成模型能力差異。
樣本少時，結論保持在已觀察範圍。你可以說這次卡關得到具體新方向，不能因此承諾所有任務都會省一半成本。等同類工作累積更多資料，再決定是否設為日常預設。
暫停使用時，確認設定也已關閉
目前對話可以用官方命令關閉：
/advisor off
關閉後看介面回報，確認自己之後的工作條件。若使用的是一次啟動旗標，下一個會話也要檢查儲存設定，避免誤以為關閉這次就代表所有預設已清除。
停止試用不需要把原任務全部重做。保留已確認的修改與結果，再繼續完成原本工作。當沒有需要第二意見的問題時，簡單路徑就足以處理，工具選擇應跟任務需求一致。
advisor、規劃模式與子代理如何選擇
advisor 適合在目前任務中取得第二意見。規劃模式則處理開始執行前的方向安排。子代理可以承擔清楚界定的子任務。三者參與的時間與責任不同，先看工作缺口在哪裡，再選擇相應方式。
如果只是需要一個人檢視某份獨立資料，可以明確安排資料整理。如果主線卡在原因判斷，顧問意見可能更合適。不要為了使用多模型，把原本連續的簡單修改拆成許多難以整合的小任務。
完成標準始終是原本的成果。工具狀態、模型數量與呼叫次數只是過程資訊。檔案是否正確、錯誤是否修復、必要測試是否通過，才是可以交給同事確認的結果。
常見問題：第二個模型看過就能自動放心嗎？
仍應檢視它看到了哪些資料與提出什麼意見。兩個模型可能共享同一份不完整輸入，也可能都接受了一個錯誤假設。把來源與完成標準交代清楚，才能讓第二意見有真正可以檢查的物件。
Claude Code advisor 值得試用的場合，是長任務中的規劃、反覆錯誤與完成檢查。先選一個具體卡關、確認配對與啟用狀態，再用實際變更、測試與總消耗評估。
這比直接採用社群上的省錢口號更能幫你做決定。
