為什麼 AI 與開發工具值得獨立成為規則集

當你使用 Clash Verge Rev、Mihomo 或其他支援 Clash.Meta 核心的用戶端時，所有流量最後都會經過同一套規則判斷。剛開始使用時，把常用網域、代理策略與直連條件全部寫在單一 YAML 設定檔裡，看起來最直接；但隨著 AI 服務、套件倉庫、程式碼平台和公司內部工具逐漸增加，這份檔案很快會變成難以閱讀的長清單。你可能只是想新增一個模型 API 網域，卻不小心改動了其他服務的優先序；也可能在更新訂閱後，原本手動加入的規則被覆蓋，導致問題隔幾天才被發現。

更適合長期維護的方式，是把規則依照用途拆成可獨立更新的 Rule Provider。例如，AI 服務可以放在 ai-services.yaml，開發平台放在 developer-tools.yaml，本地網路或公司域名則交給另一份私有規則集。主設定檔只負責指定 provider 的來源、更新頻率與套用順序，具體網域清單則透過 Git 管理。這樣做的價值不只是檔案變短，更重要的是每次修改都有範圍、有紀錄，也能在出現異常時快速回到上一個版本。

本文使用 AI 服務與開發工具作為例子，說明如何設計規則集、如何處理 YAML 的優先序，以及怎樣利用 GitHub Raw 來源與 Clash 連線紀錄完成驗證。這些方法同樣適用於串流服務、工作協作平台、套件下載站或需要固定出口的專案環境。請先確認你的規則集來源可信，並依照所在地法律、公司政策與各服務條款使用代理功能。

Rule Provider 的組成：來源、格式與策略群組

一份可用的自訂規則集，通常包含三個互相配合的部分。第一是規則來源，也就是本機檔案或可透過 HTTPS 取得的遠端 YAML；第二是格式宣告，用來告訴 Mihomo 這份資料是網域規則、完整規則還是 IP 規則；第三是策略群組，決定命中的流量要送往哪個代理群組。三者缺一不可：只建立了 provider 卻沒有在主規則中引用，規則不會生效；只寫了網域但策略名稱拼錯，則可能在載入時報錯或落到意料之外的分支。

用途 建議檔案 常見內容 策略設計
AI 服務 ai-services.yaml 模型 API、登入授權、控制台與官方文件網域 AI-Proxy 或手動選擇的穩定節點
開發平台 developer-tools.yaml 程式碼託管、容器映像、套件索引與文件站 Dev-Proxy，必要時分成 Git、Registry 兩組
本地與公司網路 private-direct.yaml 內網域名、區域網路、私有 DNS 後綴 DIRECT，並放在代理規則之前

規則集本身不應過度追求「把所有可能網域都列進去」。AI 平台常會改用新的 CDN、登入端點或遙測主機，開發工具也可能因版本更新而增加新的下載來源。與其複製一份看似完整、實際上很快過期的網域大全，不如先收集你的程式實際連線紀錄，再把已確認的必要網域加入。對通用後綴可以使用 DOMAIN-SUFFIX，但對容易與其他服務共用的頂級網域，應改用更精確的 DOMAIN 或 DOMAIN-KEYWORD，避免代理範圍過大。

用 GitHub 管理規則：公開與私有內容要分開

如果規則只在自己電腦上使用，本機 YAML 已經足夠；但只要你有兩台以上裝置，或需要與團隊同步，GitHub 就能提供清楚的版本歷史。建議建立一個專門的規則儲存庫，而不是把規則散落在個人筆記、聊天記錄或多份訂閱設定中。每次修改用一個容易理解的 commit 訊息，例如「加入新的模型 API 網域」或「移除已停用的套件鏡像」，日後看到某個服務突然無法連線時，就能先對照變更時間，而不是從數百行 YAML 裡猜測。

公開儲存庫適合放一般性的網域規則，但不要把訂閱網址、認證資訊、API Key、內部域名或公司主機名稱提交到 Git。即使後來刪除檔案，敏感資料也可能仍保留在 Git 歷史中。比較穩妥的做法，是把公開規則與私有規則拆成兩個 provider；公開部分使用 GitHub Raw URL，私有部分留在本機，或放在有存取控制的內部 Git 服務。對外提供規則檔時，至少使用 HTTPS，並確認 Raw URL 指向的是實際 YAML，而不是 GitHub 的 HTML 預覽頁。

payload:
  - DOMAIN-SUFFIX,openai.com
  - DOMAIN-SUFFIX,anthropic.com
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

規則檔格式要配合核心版本。使用網域型 provider 時，內容通常只需放規則項目；若你的客戶端要求完整格式，則可依目前 Mihomo 文件加入對應的 payload 結構。不要直接把不同格式的檔案混在一起，也不要只因為副檔名是 .yaml 就假設所有客戶端都能解析。提交前可先在測試設定中載入，確認縮排、逗號、冒號與策略名稱都沒有問題。

小提示：GitHub Raw 內容更新後，Clash 是否立即取得新版本取決於 interval、快取與用戶端實作；若要即時驗證，請在介面中手動更新 provider，再查看規則集的最後更新時間。

動手設定：建立 AI 與開發工具的分流規則

以下流程以已經匯入訂閱、並且能正常看到代理策略群組的 Clash 用戶端為前提。先備份目前設定，再建立兩份小型規則集，不要一開始就把整個工作環境的網域全部搬過來。這樣即使設定失敗，也容易判斷是 provider、引用方式，還是策略群組本身造成問題。

  1. 先確認策略名稱。在 Clash Verge Rev 的代理頁面記下實際存在的群組名稱，例如 AI-Proxy、Dev-Proxy 或訂閱提供的自動選擇群組。YAML 裡的名稱必須完全一致，包括大小寫、空格與符號。
  2. 建立規則檔。在 Git 儲存庫內新增 ai-services.yaml 與 developer-tools.yaml。第一份先放你確定會使用的模型 API、登入與控制台網域；第二份則加入 GitHub、GitLab、套件註冊站或容器映像服務，不要把整個 googleapis.com 或 azure.com 後綴粗略納入。
  3. 在主設定檔宣告 provider。於 rule-providers: 下填入每份規則的 URL、類型與更新間隔。URL 內不要直接嵌入私人 Token；若來源需要驗證，應改用適合的私有部署方式。
  4. 引用規則集。在 rules: 中使用 RULE-SET,ai-services,AI-Proxy 與 RULE-SET,developer-tools,Dev-Proxy 這類條目。名稱必須與 rule-providers 下的 key 對應，不能把檔案名稱、顯示名稱與 provider key 混為一談。
  5. 重新載入並觀察連線。先在規則模式下重新載入設定，再開啟一個實際會發出請求的 AI CLI、IDE 擴充功能或 Git 操作。確認連線紀錄中的目的地、命中規則與最終策略，三者都符合預期後才擴大規則範圍。

一個常見的主設定概念如下，實際欄位名稱請以你使用的 Mihomo 版本與設定模板為準：

rule-providers:
  ai-services:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/example/rules/main/ai-services.yaml
    path: ./providers/ai-services.yaml
    interval: 86400

rules:
  - RULE-SET,private-direct,DIRECT
  - RULE-SET,ai-services,AI-Proxy
  - RULE-SET,developer-tools,Dev-Proxy
  - MATCH,Proxy

最後的 MATCH 是兜底規則，不代表所有流量都應該永久走代理。你可以依所在地網路環境與使用需求選擇 DIRECT 或其他策略，但必須清楚知道它會接住前面所有沒有命中的請求。測試期間若把兜底策略設得過於寬鬆，容易誤以為某個 provider 成功命中；因此最好透過連線紀錄和規則匹配資訊雙重確認。

規則優先序：避免 AI 與開發工具互相覆蓋

Clash 規則一般採用由上而下的首次命中邏輯。也就是說，一旦某個請求符合上方規則，後面的 provider 就不會再參與判斷。這是規則集最容易出現問題的地方：你可能已經建立了精確的 AI provider，但前面早就有一條寬泛的直連規則，例如某個大型公司的整體網域後綴，結果 AI API 還沒走到新規則就被送往 DIRECT。

建議採用「本地例外在前、具體服務居中、廣泛兜底在後」的順序。內網與區域網路規則通常應放在最前，避免 TUN 或系統代理影響本機服務；接著放 AI、開發平台等明確用途的 provider；再放廣泛的國家或地區規則；最後才是 GEOIP、IP-CIDR 和 MATCH。如果兩份 provider 可能包含同一個網域，要事先決定誰的責任更清楚，而不是讓結果取決於檔案更新順序。

  • 精確網域優先：先處理明確的 API、登入端點與套件註冊站，再處理較大的網域後綴。
  • 不要依賴檔名暗示優先權：ai-services.yaml 排在檔案清單前面，不等於它在主規則裡先命中。
  • 將 DIRECT 視為明確決策：不要把直連當作「沒有設定」，因為一條寬泛的 DIRECT 也會攔截後面的代理規則。
  • 保留一個穩定兜底：當 provider 更新失敗時，仍要有可預期的 fallback，而不是讓核心因設定不完整而停止載入。

AI 服務尤其要注意登入與 API 不一定使用同一個網域。你在瀏覽器開啟控制台成功，不代表終端機的 API 請求也命中了同一條規則；同樣地，Git 操作可能連到程式碼平台、物件儲存與 OAuth 授權端點。遇到登入畫面能開、實際推理或 git clone 卻逾時時，應先在連線列表逐筆找出真正的目的地，而不是不加分析地把整個頂級網域送進代理。

除錯與長期維護：從命中紀錄找出真正問題

規則集失效時，先不要立刻切換全域 TUN 或更換節點。第一個問題是「請求有沒有進入 Clash」；如果連線列表完全看不到相關請求，問題可能在系統代理沒有開啟、終端程式沒有讀取環境變數、IDE 使用獨立網路程序，或需要 TUN 才能接管。第二個問題是「命中了哪一條規則」；若記錄顯示網域被前面的 DIRECT、GEOIP 或其他 provider 接走，就要調整順序。第三個問題才是「選定的代理策略是否可用」；只有前兩步確認無誤後，換節點才有診斷價值。

終端工具可以用最小化測試來縮小範圍，但不要把 API Key 寫進命令列歷史或公開截圖。以支援 HTTP Proxy 的工具為例，可以先測試 DNS 與 TLS 是否完成，再確認 HTTP 狀態碼；若工具本身不讀系統 Proxy，則要在當前 Shell 明確設定 HTTPS_PROXY，並留意 NO_PROXY 是否把目標域名意外排除。Windows PowerShell、macOS Terminal、Linux Shell 和 IDE 內嵌終端的環境變數來源可能不同，應分別驗證。

維護方面，建議為每份 provider 設定責任範圍與更新規則。網域真的不再使用時就刪除，服務改用新端點時則留下 commit 訊息；每次更新後，至少測試一個 API 請求、一個程式碼下載動作和一個不應走代理的內網服務。若 provider 由多人維護，可在儲存庫加入 README，記載每個網域的用途、加入日期、驗證方式與負責人，避免未來有人只看到一串域名卻不知道刪除它會影響哪項功能。

當遠端 provider 暫時無法下載時，Clash 可能繼續使用本機快取，也可能在重新載入時回報錯誤，行為取決於核心與用戶端版本。因此不要把遠端檔案當成唯一且不可替代的配置來源。重要環境可保留最近一次已驗證的本機副本，並在 GitHub Actions 或其他 CI 流程中檢查 YAML 語法、重複網域和格式一致性。這種自動化不會保證每個服務永遠可用，但能先阻擋縮排錯誤、空檔案和未定義策略等低階問題。

發布前檢查清單與實務取捨

完成自訂規則集後，可以用下面的清單做最後一次對照：

  • 規則來源使用 HTTPS，且沒有提交訂閱連結、Token、API Key 或內部主機資料。
  • 每個 provider 都有清楚的用途、格式、更新週期與本機快取路徑。
  • RULE-SET 名稱與 provider key 完全一致，策略群組名稱也確實存在。
  • 本地直連、AI 服務、開發平台、廣泛兜底的優先序已經明確記錄。
  • 至少從瀏覽器、終端機或 IDE 中各選一種實際請求，確認命中規則與策略。
  • Git commit 能說明變更原因，並且保留可回退的上一個穩定版本。

與把所有條件堆在單一 YAML 的做法相比，獨立 Rule Provider 的初始準備時間確實較長；你需要建立儲存庫、整理網域、理解格式，還要留意遠端更新失敗的情況。但對經常使用 AI API、GitHub、套件倉庫和 IDE 擴充功能的開發者來說，這項投入能換來更清楚的責任邊界。某個服務異常時，你可以先停用一份 provider 或回退一個 commit，而不必把整個代理設定恢復成全域模式。

不少只提供簡單開關的同類代理工具，遇到 AI 登入、開發平台多網域與終端環境變數混用時，往往只能在「全域」和「直連」之間反覆切換，既難追蹤也容易影響其他應用程式；相比之下，Clash 的 Rule Provider、策略群組、連線紀錄與 YAML 可讓你把 AI 和開發工具拆開管理、逐筆驗證並透過 Git 保留歷史。如果你正想把這套可維護的分流流程帶到自己的 Windows、macOS 或 Android 環境，先選擇符合平台的用戶端會是自然的下一步。

立即免費下載 Clash，開啟流暢上網新體驗 →