Mintlify 是一套把 Git、Markdown／MDX、API reference、搜尋與 AI 工具放在一起的開發者文件平台。它最適合 API、SDK、CLI 與需要版本控管的技術產品。若內容主要是新聞、品牌故事或一般 SEO 文章，使用既有 CMS 通常更省事。
現在評估 Mintlify，不能只看文件網站外觀。Starter 已含 Git sync、Web editor、authentication、API playground 與文件 MCP；Pro 才加入 Assistant、Agent、Automations 與 preview deployments。另一個容易混淆的重點是兩種 MCP：一種讓使用者的 AI 搜尋文件或呼叫公開 API，另一種讓內部 AI 代理修改文件並開 pull request。
Mintlify 怎麼開始？
導入時先做最小可用文件站，不要一開始就把重點放在外觀：
- 建立專案並連接文件儲存庫。
- 先寫
Quickstart，讓新使用者能完成一次成功操作。 - 補齊 authentication、核心概念、API reference、examples 與 troubleshooting。
- 每頁設定明確標題與 description，避免「Overview 2」這類看不懂的名稱。
- 在分支或預覽環境檢查連結、程式碼與導覽順序。
- 上線後用真實問題測 Assistant，再從查詢紀錄找文件缺口。
文件的最低標準是：讀者知道前置條件、可複製的指令能執行、錯誤訊息有解法。AI 功能應放在這個基礎之上。
Starter、Pro 與 Enterprise 怎麼選？
官方方案頁把 Starter 定位給個人和小型團隊，包含 custom domain、Web editor、authentication、MCP server 與 API playground。頁面允許免信用卡開始，並提供第一個月 credits；正式長期成本會依當下方案和 AI credits 用量變動，採購前要用官方報價重新試算。
需要站內 Assistant、Writing Agent、Automations、preview deployments 或 admin APIs 時，才進入 Pro 的範圍。Enterprise 的重點則是 SSO、SCIM、RBAC、audit logs、進階 insights 與企業支援。只有一兩位工程師維護公開 API 文件時，先用 Starter 驗證 Git sync、OpenAPI 與 MCP；多人審核、私有內容和正式治理需求明確後再升級。
Assistant 與 llms.txt 怎麼用？
先看 Assistant。官方文件指出，Assistant 會根據文件站內容回答自然語言問題，附上來源連結，並提供可複製的程式碼。Pro 與 Enterprise 方案會自動啟用 Assistant，團隊可從 Dashboard 匯出查詢 CSV，觀察讀者反覆問哪些問題。
建議用三組問題驗收：
- 入門問題：「如何取得 API key 並完成第一個 request？」
- 錯誤排除：「為什麼收到 401？要檢查哪些設定？」
- 邊界問題：「這個 SDK 是否支援離線執行？」
回答若引用錯頁、漏掉前置條件或混用舊版本，先修文件結構與內容，不要只調整聊天提示。
再看給外部 AI 工具使用的文字入口。Mintlify 會自動維護幾種路徑：
| 路徑 | 內容 | 適合用途 |
|---|---|---|
/llms.txt | 文件摘要與頁面連結索引 | 先找相關文件 |
/.well-known/llms.txt | 同一份索引的標準位置 | 工具自動探索 |
/llms-full.txt | 較完整的整站文字 | 需要大量上下文時 |
頁面 .md | 單頁 Markdown 版本 | 精準讀取一篇文件 |
這些檔案會依文件與 frontmatter 更新，但「可被讀取」不等於「一定會被搜尋引擎收錄」，也不保證模型回答正確。頁面若缺版本資訊、錯誤處理或完整範例，AI 仍可能做出錯誤推論。想先理解規格與 SEO 邊界，可看 llms.txt 完整指南。
Mintlify 的兩種 MCP 差在哪？
文件站 MCP 是面向讀者與 API 使用者的入口。Mintlify 在文件網域的 /mcp 自動建立 server，預設提供文件搜尋。若方案與 OpenAPI 設定允許，也能用 x-mint 明確開放特定 API endpoint 成為 tool；沒有標示的 endpoint 不會自動暴露。公開文件任何人可連，部分或全部受保護的文件則要先在 Dashboard 啟用，使用者驗證後只搜尋自己群組有權讀的頁面。
Mintlify MCP 是面向文件維護者的寫入工具。它讓 Claude、Claude Code、Cursor 或其他 MCP client 提議修改頁面、重整導覽、更新 docs.json 並建立 pull request。官方設計是所有變更先進分支，再經 PR 合併，因此適合納入既有 code review；仍要限制可連線的代理、repository 權限和自動合併設定。
選擇方式很直接：想讓客戶在 AI 工具裡查文件，提供文件站 /mcp；想讓內部代理協助維護文件，連 Mintlify MCP。若要把 OpenAPI endpoint 暴露給外部代理，先從唯讀、低風險操作開始，不要把刪除、付款、權限變更或大量寫入 API 一次開出去。
權限與選型要注意什麼？
私有文件同樣要逐條驗證。Mintlify 文件指出，部分或全部需要登入的站點可以啟用 MCP，連線者要完成身分驗證，搜尋範圍依 user groups 限制。llms.txt、Markdown、MCP 與一般頁面不是同一種請求路徑，上線前應分別用未登入帳號、一般成員與管理員實測回傳內容。
導入前仍要做三件事：
- 把公開文件與內部 runbook 分開，不要只靠隱藏導覽。
- 用未登入視窗測試每個 AI 入口實際回傳什麼。
- 不把 token、客戶資料、內網網址或真正的密鑰寫進範例。
適合度取決於文件類型。有 API、SDK、CLI 或技術整合，而且文件要和程式碼一起 review，Mintlify 很值得評估。希望讀者在站內直接問問題也符合它的強項，但要先確認 Assistant 所需方案。
如果主要內容是內部知識庫、會議紀錄與跨部門文件，GitBook 或既有 wiki 可能更順；新聞、SEO 文章與品牌內容則應留在一般 CMS。最關鍵的警訊是沒有人負責文件來源：Mintlify 可以改善呈現與查找，無法替團隊補寫缺失的操作步驟。
選型時可一起看 AI 文件工具比較、GitBook AI 指南 與 ReadMe API 文件指南。若產品正準備提供 agent 介面，再延伸閱讀 MCP 是什麼。
正式導入前，請一位沒參與撰寫的人照 Quickstart 操作；他應能在 10 分鐘內完成第一次成功呼叫。接著確認所有程式碼範例標明版本、語言與前置條件，錯誤碼、權限和 rate limit 有獨立說明。最後實測 Assistant 是否引用正確版本，以及私有頁、Markdown、llms.txt 和 MCP 在未登入時是否真的無法取得。上線後每月整理高頻查詢，直接把答案補進正式文件。
常見問題
Mintlify 是免費的嗎？
官方允許免信用卡開始，並提供第一個月 credits；Starter、Pro 和 AI credits 的持續價格與用量規則可能調整。評估時應直接查看官方 pricing 與帳號後台，不要用舊文章中的數字決策。
Mintlify 的文件 MCP 和 Mintlify MCP 是同一個嗎？
不同。文件站 /mcp 主要讓外部 AI 搜尋發布內容，並可選擇性呼叫明確開放的 API；Mintlify MCP 讓可信任的內部代理修改文件、導覽和 docs.json，變更會先建立分支與 pull request。
Mintlify 需要會寫程式嗎？
一般編輯可用 Markdown，但儲存庫、分支、MDX 元件與 API reference 仍偏向開發團隊工作流。若內容維護者完全不使用 Git，先確認協作方式是否合適。
有 llms.txt 就會讓 ChatGPT 引用我的文件嗎？
不保證。llms.txt 提供結構化入口，但模型或搜尋產品是否抓取、何時更新及如何引用，仍由各服務決定。內容正確、可公開存取與內部連結清楚更重要。
Mintlify Assistant 會回答文件以外的內容嗎？
它的主要依據是文件與設定的 knowledge base。仍應用真實問題驗收引用與版本；高風險操作不要只依賴 Assistant 回答。