smart-search

智慧搜尋路由分流器

根據話題與情境，將查詢路由分流至最佳的 opencli 搜尋源。此 skill 的核心目標不是記憶命令，而是先定位資料源，再讓 Agent 透過 opencli 自己讀取即時說明文件，避免文件偏離現狀。

強制預檢

每次使用前，必須先執行以下兩步：

• 執行 opencli list -f yaml
• 用 live registry 確認候選站台是否存在，並檢查 strategy、browser、domain

選定站台後，必須再執行以下兩步：

• 執行 opencli <site> -h 查看該站台有哪些子命令
• 若已鎖定某個子命令，再執行 opencli <site> <command> -h 查看參數、輸出欄位、策略

不要在 skill 文件裡硬編碼參數或假設命令簽名；以 opencli ... -h 的即時輸出為準。

主路由規則

只使用這一條規則，不再維護多套優先順序：

1. 當使用者明確指定網站、平台或資料源時，直接使用對應網站。
2. 當使用者沒有指定網站時，優先只選擇一個 AI 源：grok、doubao、gemini 三選一。
3. 當 AI 回傳內容不足、缺少原始資料、需要權威佐證或需要垂直領域結果時，再補充 1-2 個專用源。

單一問題預算與頻率限制

把「單一使用者問題」理解為同一意圖鏈路下的一次問題求解；同一輪追問、澄清、補充條件，若核心問題未變，仍算同一題。

先建立一份站台呼叫紀錄表。每次真正執行搜尋命令後，立刻更新：

• site
• query
• count
• status

計數規則：

• opencli list -f yaml、opencli <site> -h、opencli <site> <command> -h 屬於預檢與說明，不計入搜尋次數
• 一次真正的 opencli <site> ... 搜尋/查詢執行，計為該站台 1 次呼叫
• 同一站台因報錯、逾時、驗證碼、反爬蟲、登入狀態異常而失敗，也算 1 次呼叫，不要無限重試

頻率上限：

• AI 站台硬性限制：同一題內，每個 AI 站台最多呼叫 1 次
• 預設策略仍是只選 1 個 AI 站台，不要把多個 AI 站台串成常規流程
• 只有當使用者明確要求比較多個 AI 站台時，才可以額外呼叫其他 AI 站台；但每個被點名的 AI 站台仍然最多 1 次
• 非 AI 站台預設最多呼叫 2 次
• 非 AI 站台第 2 次呼叫必須有明確理由，例如第一次結果範圍過寬，需要加上時間、地區、類別、排序或關鍵字限定
• 非 AI 站台不要進行第 3 次呼叫；若資訊仍不足，停止擴大搜尋並明確說明缺口

觸發限頻後的處理：

• 記錄：「已跳過：<site> 達到頻率上限」
• 優先改用其他同類站台
• 若沒有合適替代源，則直接基於已收集資訊回答，並說明覆蓋範圍與缺口

查詢結束回報

每次查詢結束後，回答末尾必須追加一段簡短的「搜尋摘要」，至少包含以下三項：

• 使用了什麼網站搜尋
• 每個網站搜了什麼關鍵字
• 每個網站搜了幾次

如果有被限頻跳過的站台，也要明確寫出。

建議使用以下的固定格式：

搜尋摘要
- 網站：<site1> | 查詢詞：<term1> | 次數：<n>
- 網站：<site2> | 查詢詞：<term2>；<term3> | 次數：<n>
- 已跳過：<site3>，原因：達到頻率上限

AI 源選擇

• grok
  適合即時討論、英文網際網路輿論、Twitter/X 語境、熱門時事追蹤。
• doubao
  適合中文語境、字節跳動/抖音生態、生活方式內容、中文熱點與泛中文問答。
• gemini
  適合全球網頁、英文資料、通用資訊檢索、背景綜述。

如果使用者沒有指定網站，預設先判斷語言和語境，再從這三個之中只選一個。

一旦某個 AI 站台已經執行過一次真實查詢，就不要在同一題裡改寫關鍵字後再次呼叫該 AI 站台。若答案不足，優先補充專用源，不要反覆追打同一個 AI 站台。

AI 查詢詞建議

當使用 AI 源時，不要只輸入過短的關鍵字。優先構造成「主題 + 目標 + 限定條件」的查詢。

• 主題
  使用者真正要查的物件、事件、產品、人物、公司、技術名詞。
• 目標
  想要什麼結果，例如總結、對比、原因、趨勢、推薦、原始線索。
• 限定條件
  語言、地區、時間範圍、平台範圍、受眾、價格帶、職缺地點、是否要引用原始來源。

優先使用以下表達方式：

• <主題> + <你要回答的問題>
• <主題> + <時間範圍/地區/語言>
• <主題> + <平台或來源範圍>
• <主題> + <輸出要求>

避免只輸入：

• 單一名詞
• 沒有時間範圍的熱門議題
• 沒有地區限制的購物、求職、旅遊問題
• 沒有平台限制的社群媒體問題

專用源補充時機

當出現以下任一情況時，再補充專用源：

• AI 給出的是摘要，但你需要原始貼文、原始影片、原始商品或原始職缺結果
• AI 涵蓋面不足，漏掉垂直站台資訊
• 需要更高權威性或更強領域相關性
• 使用者明確要求「從某個平台找」

單次查詢通常控制在 1 個 AI 源 + 1 到 2 個專用源，避免結果負荷過重。

處理不可用的源

當站台不可用時：

• 不要因為單一源失敗而中斷整個搜尋
• 記錄：「已跳過：<site> 不可用」
• 退回至同類其他站台，或退回至一個 AI 源
• 始終以 opencli list -f yaml 與 opencli <site> -h 的實際結果為準

不要假設任何站台「絕對可用」。即使是公開站台，也以當前環境中的 live help 和執行結果為準。

參考檔案

根據需要讀取對應檔案：

• references/sources-ai.md — AI 預設源
• references/sources-tech.md — 技術 / 學術
• references/sources-social.md — 社群媒體
• references/sources-media.md — 媒體 / 娛樂
• references/sources-info.md — 資訊 / 知識
• references/sources-shopping.md — 購物
• references/sources-travel.md — 旅遊
• references/sources-other.md — 其他垂直源

只讀取與當前查詢相關的檔案，無須全部載入。