GitBook AI 適合需要長期維護產品文件、API 文件、內部知識庫的團隊。它和一般 AI 寫作工具的差別在於：GitBook 不只處理「產生文字」，也處理文件如何被使用者搜尋、被 AI assistant 回答、被 AI agent 讀取。
如果你的文件是產品成長、客服分流、開發者導入的一部分，GitBook AI 的價值會比單純用 ChatGPT 寫幾段說明更明顯。
適合誰用？
| 使用者 | 適合原因 |
|---|---|
| SaaS 產品團隊 | 建立公開文件、功能指南、更新說明 |
| Developer relations | 讓 API 文件更容易被開發者與 AI coding assistant 使用 |
| 客服與成功團隊 | 用文件回答重複問題，降低人工支援壓力 |
| 技術寫作者 | 用 AI 協助檢查缺口、重寫段落、維護多語版本 |
| 內部知識庫團隊 | 讓員工用自然語言查找內部資訊 |
GitBook AI 可以做什麼？
| 功能 | 用法 | 需要注意 |
|---|---|---|
| GitBook Assistant | 讓讀者直接詢問文件內容 | 文件本身要寫清楚，不能期待 AI 猜出沒有寫的內容 |
| GitBook Agent | 協助撰寫、審查、更新與翻譯文件 | 仍需要人審內容正確性 |
| AI Search | 在文件站內用語意搜尋找答案 | 索引更新可能不是即時完成 |
| llms.txt | 讓 AI 工具理解文件結構 | 公開文件才適合放進可被抓取的內容 |
| MCP server | 讓 AI 工具直接連到文件資料 | 要注意公開權限與 API key 管理 |
導入前先問三件事
文件是不是已經有基本結構？
AI 文件工具最怕的是拿到一堆散亂頁面。導入前至少要先整理出 onboarding、核心功能、常見問題、API reference、release notes 這幾類內容。結構越清楚，Assistant 的回答越穩。
你的讀者是人，還是 AI 工具？
現在文件不只給人看。開發者可能會把文件丟給 Cursor、Claude Code、ChatGPT 或其他 agent。GitBook 的 Markdown 輸出、llms.txt、MCP 支援，都是為了讓這些工具更容易取得最新文件。
內容錯誤誰負責？
GitBook Agent 可以協助產生與修改內容，但產品規格、價格、限制、API 行為仍要由產品或工程團隊確認。文件一旦變成 AI 回答的來源，錯誤會被放大。
建議工作流
- 先盤點現有文件，刪掉過期頁面。
- 依使用者任務重整分類，而不是依公司部門分類。
- 在每一頁加入明確標題、摘要、限制條件與下一步。
- 開啟 Assistant 或 AI Search 後，用真實客服問題測試。
- 檢查回答是否能引用正確頁面。
- 再逐步導入 llms.txt、MCP 與多語文件。
不適合的情境
如果你只是偶爾寫幾篇教學文，或文件量很少，GitBook AI 可能會比需求更重。這時候用一般 CMS、Markdown 文件或 Notion 類工具就夠。
但如果文件已經影響客服量、開發者導入速度、AI 搜尋引用機會，GitBook AI 就值得列入評估。