Web 工具
Gemini CLI Web search 和 web fetch 工具的職責邊界：搜尋最新資料、讀取指定 URL、引用官方來源和避免社群誤導。
Web 工具讓 Gemini CLI 能接觸即時資料。對新庫、新版本、新錯誤、官方遷移指南，這比憑模型記憶更可靠。
聯網只能降低過時風險，不能自動保證事實正確。安全、認證、計費、刪除資料、生產許可權必須回到官方來源和本地驗證。
search vs fetch
| 工具 | 適合 |
|---|---|
| Web search | 找資料、找官方入口、找近期 issue |
| Web fetch | 讀取指定 URL 的正文 |
google_web_search 接收搜尋 query，返回帶來源的綜合結果。web_fetch 接收包含 URL 和處理要求的 prompt，最多處理 20 個 http:// 或 https:// URL，並透過 Gemini API 的 URL context 獲取內容；API 路徑失敗時會嘗試本機直接 fetch。
google_web_search 返回的是整理後的答案和來源，不是原始搜尋結果列表。web_fetch 則更適合讀取你已經確認的 URL，並儘量保留來源引用。兩者都要用來縮小事實風險，而不是替代你檢查版本、日期和官方來源。
使用順序
- 先搜尋官方文件。
- 再 fetch 官方頁面。
- 如果官方缺失，再看 GitHub issue。
- 社群部落格只作經驗補充。
- 修改程式碼前要求 Gemini 給來源和計劃。
風險
- 搜尋結果可能過期。
- 社群方案可能不適合你的版本。
- 安全、認證、支付、雲許可權必須回到官方來源。
web_fetch可能訪問 localhost 或私有網路地址，面對不可信 prompt 時要謹慎。- Plan Mode 中
web_fetch會要求明確確認，因為外部和私有地址訪問有安全含義。
適合的實戰用法
寫教程時，Web search 用來定位“官方入口”和“最新事實”，Web fetch 用來讀取具體頁面。不要只讓 Gemini CLI 搜尋後直接下結論；高風險內容要要求它給出 URL、釋出日期或版本號，並把事實回寫到教程裡的“官方來源”。
排錯時，先用錯誤資訊搜尋官方 issue、release notes 和 docs，再 fetch 具體 issue 或文件。社群部落格可以提供線索，但不能作為認證、許可權、計費、隱私、刪除資料這類操作的最終依據。
| 來源 | 用途 | 是否可作最終依據 |
|---|---|---|
| 官方 docs / API reference | 引數、限制、支援範圍 | 是 |
| Release notes / changelog | 版本變化、棄用、遷移 | 是 |
| GitHub issue / PR | bug 線索、維護者解釋 | 視情況 |
| 社群部落格 / forum | 排障經驗、關鍵詞線索 | 否 |
| AI 生成摘要 | 初步方向 | 否 |
寫教程時應把 Web 工具產出的事實轉成可點選來源，而不是隻寫“根據搜尋結果”。對高時效內容，還要寫清訪問日期或版本範圍。
教程寫作要求
涉及安裝、認證、計費、配額、隱私、企業控制、刪除資料、釋出動作時，必須 fetch 官方頁面或官方儲存庫檔案。社群內容只能寫在“經驗補充”裡，不能寫成主流程依據。
如果一個頁面需要引用多個 URL，優先讓 web_fetch 一次處理同一主題下的官方頁面，例如 docs、release notes、API reference。超過 20 個 URL 時拆批，並在教程裡按主題歸類來源，不要把一串連結堆在文末。
抓取結果也要二次落地：把“官方怎麼說”改寫成讀者能執行的命令、檢查項和失敗處理。只貼連結不是教程，只是資料清單。
驗收方式
讓 Gemini CLI 對同一問題給出“官方來源優先”的答案，並檢查引用是否來自官方 docs、GitHub repo、release notes 或 issue。對於 fetch，確認它讀取的是你指定的 URL，而不是搜尋結果裡的相似頁面。
接下來去哪
Todos / Planning 工具
聯網拿到事實後，繼續看長任務如何拆計劃和跟蹤進度。
Web search / fetch 工作流
回看日常 CLI workflow 裡的聯網使用順序。
Terms & Privacy
聯網、URL fetch 和資料使用要繼續核對隱私邊界。