假設一位想轉職的行銷人員米娜，在一個線上課程網站問 AI 助理：「我只熟試算表，平日晚上有空，想在六週內學會做自動化報表。哪門課適合我？八月還有哪一班能報？」
這個問題裡其實藏著三種不同的工作。比較課程內容、判斷哪門課適合她的背景，只需要讀網站上公開的課程介紹。確認八月是否還有名額，需要查一筆會變動的資料。至於替她報名、刷卡，那是替人動手，而她根本還沒要求這件事。
最近很多網站在討論要不要做 API 或 MCP，好讓 AI 能「接進來」。這個問題該怎麼回答，取決於 AI 要完成的那件事屬於哪一種：讀、查，還是做。三種入口要承擔的責任差很多，而多數網站最該先修的，往往是最不起眼的那一層：讓 AI 讀得懂的公開頁面。
先弄清楚 MCP 解決的是什麼
MCP（Model Context Protocol）是一套讓 AI 應用連接外部資料、工具與工作流程的開放標準。它回答的是「怎麼接」，不會替網站回答「該開放什麼」。
提供 MCP 開發服務的 Cloudflare，在自家文件裡就直接提醒：不要把 MCP 伺服器當成整套 API 的包裝，而要針對使用者的具體目標設計工具；少量設計良好的工具，往往比一大堆細碎的工具更好用，權限也要窄。換句話說，連提供這項技術的廠商都建議，先想清楚 AI 要完成什麼，再決定開哪些門。
讀、查、做這三種入口不是一條升級路線，並不是開好讀的入口，就該接著開查、再接著開做。它們對應的是三種不同的責任：讀的入口出錯，AI 給出錯的介紹；查的入口出錯，AI 給出過期的答案；做的入口出錯，世界上就真的多了一筆錯的報名或付款。入口越深，網站要承接的後果就越多。
讀：多數網站真正的缺口在這裡
米娜要的第一個答案，來源是公開的課程介紹，用不到資料庫。AI 能不能給出有理由的推薦，取決於這些頁面本身是否一致：課程名稱、先備能力、學習成果、上課時段，在不同頁面上說的是同一件事嗎？頁面的標題、說明、日期、語言版本，是不是指向同一份內容？已經下架的課程，頁面會不會還顯示「熱烈招生中」？
這些問題有現成的工具可以處理。Google Search Central 說明，列出網站重要頁面與更新時間的 sitemap 檔案，能幫助搜尋引擎發現頁面與多語版本；rel="canonical" 則是告訴搜尋引擎，一組重複或高度相似的頁面裡哪一個是正本。它們都不是新技術，也不必為 AI 另外開發。
如果課程頁彼此矛盾，加一個 MCP 只會讓矛盾更快被 AI 讀到。在讀這一層，該做的是先把內容修好。
查：只開一扇回答一個問題的窗
名額、庫存、價格、配送狀態，這些資料會變。讓 AI 從網頁版面去猜這些數字，網站一改版就會出錯，這時才值得提供穩定的唯讀查詢。
這扇窗要開得很窄。米娜的例子裡，AI 只需要查得到候選課程的代碼、八月班次、平日晚間的時段、剩餘名額、資料更新時間，以及「額滿」「尚未同步」「查無班次」「暫時故障」這幾種狀態。學員名單、付款紀錄、內部備註、修改名額的功能，都不屬於這次任務。
最後那幾種狀態特別重要。查詢失敗時，AI 必須能說「目前無法確認」，而不是拿一筆舊資料當作答案。測試時可以刻意拿掉查詢工具：AI 應該仍能依公開內容推薦課程，但要坦白說明它無法確認現在的名額。
做：先準備好批准與收拾的方法
報名、退款、改設定、寄通知，這些動作會用某個人的權限，改變外面世界的狀態。開這種入口之前，要先說清楚：用誰的帳號、對誰做、參數是什麼、能不能撤回、會不會通知對方、出錯時怎麼補救。
OpenAI 給開發者建立 AI agent 用的工具組 Agents SDK，在說明「人在迴圈中」的批准機制時，示範的做法很具體：敏感工具執行前先暫停，把工具名稱和參數列出來給人看，由人針對這一次呼叫批准或拒絕，再從保存的狀態繼續。重點在「這一次」。只留一個籠統的「同意」，事後就無法知道當初批准的是哪個對象、哪組參數。
流程如果可能做到一半失敗，還要先記下已經發生的效果、能不能安全重試、由誰負責補救，參考〈自動化卡在半途，先查清楚再決定能不能重跑〉。這些準備缺一項，做的入口就還不該開。
從一項真實任務開始判斷
與其開會討論「我們要不要做 MCP」，不如挑一項真實的任務，寫下它的完成條件，然後問：這件事裡，哪些部分只需要讀，哪些需要查，哪些需要做？
米娜的任務在拿到推薦理由和一個可報名的八月夜間班次時，就已經完成。把「做」拿掉，她的答案一點也沒少，這正說明這項任務需要的最低入口是讀加上一扇窄窄的查詢窗。只有當她接著說「幫我報名這一班」，而且身分驗證、個資、逐次確認、付款、防止重複報名、失敗補救都有人負責時，才值得重新評估做的入口。
對多數網站來說，下一步往往不是開發新介面，而是挑幾個 AI 最常被問到的頁面，檢查它們說的是不是同一件事。如果你的 AI 也會替團隊改程式，同樣的分層判斷可以參考〈一張 issue 能不能交給 coding agent，看你寫不寫得出第一個 diff〉。
AI 整理卡
請 AI 幫你判斷一項網站任務需要哪一層入口 這段提示詞會先請你描述一項真實任務，再把它拆成讀、查、做三部分，最後只建議完成任務所需的最低入口。
我想判斷我的網站是否需要為 AI 開放新的入口（例如 API 或 MCP）。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/agentic-web-needs-machine-readable-doors/
文章的看法是：先把一項真實任務拆成「讀公開內容」「查會變動的資料」「替人動手」三部分，只開完成任務所需的最低一層；多數網站要先修的是讀得懂的公開頁面。
請先問我 3 個問題：
1. 使用者會請 AI 在我的網站上完成的一項真實任務是什麼，怎樣算完成；
2. 回答這項任務需要哪些資料，哪些是公開頁面上就有的，哪些會隨時變動；
3. 這項任務會不會用到某個人的帳號去報名、付款、修改或寄送東西。
根據我的回答，請輸出：
- 把任務拆成讀、查、做三部分，各列出需要的資料或動作；
- 讀的部分：我的公開頁面可能有哪些不一致需要先修；
- 查的部分：一個只回答這項任務的唯讀查詢需要哪些欄位與錯誤狀態；
- 一行結論：完成這項任務需要的最低入口是哪一層；
- 如果需要做的入口：列出事前必須準備的批准、紀錄與補救方式，但不要替我設計實作。
不要假設我的網站有我沒提到的資料或功能。
建議只是起點，開放哪一層入口，要由負責這些資料與後果的人決定。
參考來源
- Model Context Protocol：What is the Model Context Protocol (MCP)? — https://modelcontextprotocol.io/docs/getting-started/intro [accessed: 2026-10-11]
- Cloudflare Docs：Model Context Protocol (MCP) — https://developers.cloudflare.com/agents/model-context-protocol/ [accessed: 2026-10-11]
- Google Search Central：Learn about sitemaps — https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview [accessed: 2026-10-11]
- Google Search Central：How to specify a canonical URL with rel=“canonical” and other methods — https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls [accessed: 2026-10-11]
- OpenAI Agents SDK：Human-in-the-loop — https://openai.github.io/openai-agents-python/human_in_the_loop/ [accessed: 2026-10-11]
