---
title: "Web search / fetch"
description: "Gemini CLI Web search 和 Web fetch：搜尋最新資料、讀取指定 URL、比較多個來源，並把網頁知識應用到程式碼。"
verifiedAt: "2026-05-09"
---

Gemini CLI 可以搜尋和抓取網頁。官方工具文件把它拆成兩類：`google_web_search` 用來發現和綜合搜尋結果，`web_fetch` 用來讀取你明確給出的 URL。搜尋負責找線索，fetch 負責深讀來源。

> [!NOTE]
> **搜尋負責發現，fetch 負責深讀**。不要只讓模型憑記憶回答新庫、新版本和新錯誤。

## 1. 搜尋新資料

```text
Search for the React Router v7 loader API documentation and summarize the key changes.
```

適合：

- 新發布的庫。
- 最近變動的 API。
- 報錯資訊。
- GitHub issue / StackOverflow / forum 線索。

Web search 返回的是基於搜尋結果的綜合答案，適合發現資料和建立初步方向。它不等於你已經完整讀過目標頁面。

更穩的提問方式是把目標、時間範圍和來源偏好寫出來：

```text
Search the official docs and recent release notes for Next.js 16 caching changes.
Prioritize primary sources over blog posts, then list the pages I should read first.
```

如果你只問“Next.js 快取怎麼用”，模型可能會混合不同版本的經驗；如果你明確要求官方文件、release note 和最近版本，它更容易把搜尋變成可核驗的入口清單。

## 2. 讀取指定 URL

```text
Read https://example.com/fixing-memory-leaks and explain how to apply it to my code.
```

適合：

- 已知官方文件頁。
- 部落格深讀。
- 遷移指南。
- API reference。

Web fetch 適合你已經知道官方頁面、issue、PR、release note 或遷移指南的 URL。它比“讓模型自己搜”更可控，也更適合教程寫作和程式碼遷移。

讀取指定 URL 時，不要只讓它總結網頁。更好的做法是要求它把網頁結論對映到當前任務：

```text
Fetch this migration guide, then compare it with my package.json and identify only the changes that apply to this repo.
```

這樣輸出會更接近可執行 diff，而不是泛泛的網頁摘要。

## 3. 比較多個來源

```text
Compare the pagination patterns in https://api.example.com/v1/docs and https://api.example.com/v2/docs.
```

適合版本遷移和方案選擇。

## 4. 判斷來源可信度

聯網能力的核心不是“能搜”，而是能不能把來源分層。建議按這個順序處理：

| 來源型別 | 可用方式 | 適合結論 |
| --- | --- | --- |
| 官方文件 / API reference | 主依據 | 引數、限制、支援範圍 |
| Release note / changelog | 主依據 | 版本差異、棄用、遷移步驟 |
| 原始碼 / schema / 型別定義 | 主依據 | 真實欄位、預設值、邊界行為 |
| GitHub issue / PR | 輔助依據 | 已知 bug、臨時繞過、維護者態度 |
| 部落格 / 論壇 / 問答 | 線索 | 問題復現、經驗路徑、排障方向 |

對教程寫作來說，結論必須能回到官方頁、原始碼或本地測試。社群內容可以幫助發現問題，但不應該單獨成為最終說法。

## 5. 應用到程式碼

一條更完整的路徑：

1. 先搜尋官方文件。
2. 再 fetch 指定頁面。
3. 要求 Gemini 解釋適配點。
4. 讓它給修改計劃。
5. 看 diff 後再授權修改。

```mermaid
flowchart LR
    Search["Search"] --> Sources["候選來源"]
    Sources --> Official{"有官方來源?"}
    Official -->|有| Fetch["Fetch 官方 URL"]
    Official -->|沒有| Community["社群來源只作線索"]
    Fetch --> Plan["生成適配計劃"]
    Community --> Verify["繼續找主來源或實驗驗證"]
    Plan --> Diff["授權小範圍 diff"]

    style Fetch fill:#dcfce7,stroke:#22c55e
    style Community fill:#fef3c7,stroke:#f59e0b
    style Diff fill:#dbeafe,stroke:#3b82f6
```

## 6. 輸出檢查

讓 Gemini CLI 聯網後，最後還要檢查輸出是否滿足三個條件：

- **有來源層級**：知道哪些是官方結論，哪些只是社群線索。
- **有適用版本**：標明庫版本、CLI 版本、模型版本或釋出日期，避免舊資料誤用。
- **有本地驗證點**：能轉成命令、測試、最小復現或 diff 檢查，而不是停在解釋層。

如果輸出裡沒有來源、沒有版本、沒有驗證動作，就把它退回去重做：

```text
Redo the answer with source ranking, version scope, and local verification steps.
```

## 7. 風險邊界

- 最新資料必須優先官方來源。
- 社群方案只能作參考。
- 不要讓它把未驗證部落格方案直接寫進生產程式碼。
- 涉及安全、支付、認證、雲許可權時必須二次核對官方文件。
- 搜尋結果可能混入舊版本、映象站、非官方部落格和 AI 生成內容。
- 讀取網頁時要記錄來源和訪問日期，尤其是模型、價格、API、地區和棄用時間。

> [!WARNING]
> **聯網不等於事實正確**：搜尋結果能幫你發現資料，但不能替代官方文件、原始碼、release note、API schema 和本地測試。高風險修改必須回到主來源核驗。

## 8. 接下來去哪

<Cards>
  <Card title="會話與歷史" description="繼續看搜尋和修改後的會話如何儲存、恢復和管理。" href="/zh-Hant/docs/gemini-cli/official/01-cli-workflow/16-session-history" />
  <Card title="Web tools" description="繼續看 Gemini CLI 官方 web search 和 web fetch 工具語義。" href="/zh-Hant/docs/gemini-cli/official/03-tools-mcp/33-web-tools" />
  <Card title="GitHub Action" description="如果要把聯網能力放進自動化，繼續看 GitHub Action 的許可權邊界。" href="/zh-Hant/docs/gemini-cli/official/07-integrations-automation/74-github-action" />
</Cards>

## 官方來源

- [Web Search Tool](https://google-gemini.github.io/gemini-cli/docs/tools/web-search.html)
- [Web Fetch Tool](https://google-gemini.github.io/gemini-cli/docs/tools/web-fetch.html)
- [Gemini CLI Tools Reference](https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/tools.md)
