這篇記錄一次「趨勢出來當天就接上」的完整過程：WebMCP 是什麼、跟 MCP 差在哪、我在官網實際做了哪四個工具、為什麼第一版刻意只做唯讀、要不要記錄 AI 查了什麼的取捨，以及讓另一家 AI 審七輪攔下哪些我自己看不到的問題。文末有一段可以直接貼給你自己 AI 的委託指令。
・有自己的網站，想讓訪客帶來的 AI 好好認識你、查得到你的東西的人
・聽過 MCP 或 WebMCP，想看一個真實上線案例長什麼樣的人
・不會寫程式，但想知道怎麼把這件事交辦給 AI 做的人
・一個四步驟的判斷順序：先有索引、只做唯讀、漸進增強、有記錄就揭露
・一段可整段複製、貼給你自己 AI 的委託指令（含審查與不准部署的護欄）
・「檢查器自己也要被檢查」：跨家審七輪實際抓到的三類問題
一、先講 WebMCP 是什麼：把「給 AI 的服務台」直接蓋在網頁上
過去 AI 幫你逛網站，靠的是讀頁面上的字、辨識畫面，再自己推測該怎麼操作。對 AI 來說，網站是一份要自己想辦法看懂的文件。
WebMCP 改變的是網站的角色：網頁可以直接告訴來訪的 AI「我這裡有幾個工具，你可以直接用」。運作方式用白話講就三步：
- 網站在頁面裡放一份工具清單。每個工具寫清楚名字、用途、要給什麼資料，像櫃檯上擺好的服務項目牌。
- 訪客的 AI 走進這一頁，就看得到這份清單。支援 WebMCP 的瀏覽器會把清單交給 AI。
- AI 要用就直接呼叫。工具的程式在訪客自己的瀏覽器裡執行，把整理好的答案直接回給 AI。AI 不用再爬整個網站猜結構，網站也不用把全部內容塞給它。
技術上，網站是用瀏覽器的新介面 document.modelContext.registerTool() 把工具登記給支援的環境；不寫程式的讀者，記得「頁面主動提供工具清單」這個概念就夠。
比如購物網站可以提供「搜尋商品」「加入購物車」；我的知識官網提供的是「搜站內文章」「查分類」這種查詢工具。
三件要誠實講清楚的事
- 它目前仍是草案。WebMCP 是 W3C 社群草案（Community Group Draft），規格還在改，距離正式標準還有一段路。
- 支援的環境還很少。截至 2026 年 8 月 30 日：OpenAI 已在 ChatGPT 內建瀏覽器用 Site tools 這個功能實作 WebMCP；Chrome 149 起則開放限期的實驗計畫（origin trial）讓網站報名測試。兩者狀態不同，而大多數人的瀏覽器現在都感覺不到差別。
- 工具跟提供它的頁面綁在一起。以目前 OpenAI 的做法與我採用的註冊方式，AI 離開或關掉那一頁，工具就可能用不到了；所以我把同一組工具分別掛到三個主要頁面。
那為什麼還要當天就做？因為我的網站本來就有一整層是做給 AI 讀的，WebMCP 剛好補上缺的那一塊。
二、我的網站本來就有「給 AI 讀的層」，缺的是「給 AI 用的層」
我的官網一直有三個東西是專門做給 AI 的：一份 AI 接待說明（agent.html，AI 讀了就知道怎麼代替我介紹這個網站）、一份給 AI 的網站摘要（llms.txt）、一份公開內容目錄（site-index.json，全站兩百多筆）。這套做法我叫它 AXO：讓網站從「一本放著等人翻的型錄」變成「會接待訪客 AI 的主人」。
WebMCP 補的就是這一塊。接待說明還在、索引還在，只是現在櫃檯上多了工具：AI 可以直接問「幫我搜『會議記錄』相關的內容，只要前五筆」，拿到的就是五筆乾淨的結構化資料，每筆附正式網址。
三、我實際做了什麼：四個工具，全部唯讀
| 工具 | 給 AI 做什麼 |
|---|---|
search_knowledge | 搜站內公開內容：文章、課程、案例、技能包、資源、服務入口。連我學員的口語問法（像「定妝照」）都查得到，因為它直接沿用站內搜尋既有的別名庫 |
get_knowledge_item | 用精確編號拿單筆資料與正式網址 |
list_knowledge_taxonomy | 列出全站的分類方式與每類有幾筆 |
get_site_capabilities | 自我介紹：這個站是什麼、開放哪些入口、資料邊界在哪 |
幾個設計決定，順序照重要性排
只做唯讀。報名、表單、付款都沒有。AI 代替訪客「做事」需要更嚴謹的確認機制，先把「查」做穩，才有資格談「做」。
不支援的瀏覽器完全無感。開頭先偵測環境，不支援就安靜退場，不留任何錯誤。新能力是加分，不能讓現有訪客付代價。
不另外建一份資料。工具跟站內搜尋讀同一份索引、同一份別名庫，大幅減少兩邊答案分岔的機會。
價格不寫進工具。價格的真相只在官網服務方案頁，工具只給連結；寫死在程式裡的價格，改版時很容易漏掉沒同步。
四、過程裡最有價值的一段：讓另一家 AI 審了七輪
這次的工作方式是我平常的半人馬做法：我拍板方向與邊界，AI 施工，然後讓另一家的 AI 當審稿者。我的施工方是 Claude，審稿方是 OpenAI 的 Codex，前後審了七輪才拿到兩個 APPROVE。
七輪聽起來多，但每一輪都抓到真問題。挑三個講：
它抓到「說一套做一套」。工具對外公告只接受 1 到 10 的整數，但實際程式碼會把 2.7、字串「2」、甚至 true 都悄悄當成合法值。使用上暫時沒差，但規格與行為不一致，之後很可能變成難追的 bug。改成嚴格驗證，不合規格就明確回報錯誤。
它抓到「檢查器自己是假的」。我寫了一支驗證腳本宣稱「保證這支程式沒有偷偷送資料出去」，Codex 指出那個檢查有好幾種寫法可以繞過：檢查存在，但擋不住它宣稱要擋的事。這種「有問題卻顯示全綠」的檢查比沒有檢查更危險，因為它給你假的安心。最後改成直接執行程式驗證行為，還放了誘餌欄位：故意餵假的 IP 和帳號進去，斷言它們絕不出現在記錄裡。
它抓到「宣告跟事實對不上」。我在給 AI 讀的說明裡寫「本站沒有回傳機制」，但同一版我加了匿名使用記錄，兩句話自相矛盾。改成誠實版：明列會記錄哪幾個欄位（查詢字串、命中數、時間、來源、工具名），明寫沒有 IP 與帳號。
- 怎麼設計讓兩個 AI 互審？：三種不同程度的審查機制設計：這次用的跨家審做法，那篇有三種難度的完整指令範本，教你依任務風險挑審查深度。
五、一個真的要取捨的決定：要不要記錄 AI 問了什麼
做到一半有一個決策點：工具要不要記錄「來訪的 AI 都查了什麼」？
不記的話，工具照樣把查詢結果回給 AI，只是站方不另外保存任何查詢紀錄，這是最保守的版本。代價是我不會知道 AI 都在問什麼、哪些問法查不到東西，等於這一層裝了卻沒有回饋，之後要不要投資、往哪補內容，全靠猜。
我最後選擇記，但有三個條件：匿名（只記查詢字串、命中數、時間、來源與工具名，沒有 IP、沒有帳號）、沿用既有機制（跟站內搜尋的記錄同一套，不另建系統）、誠實揭露（給 AI 讀的每一層說明都明寫會記錄什麼）。查不到東西的問法會自動進缺口排行，第一線的修法很便宜：補一條別名就好。
六、這對 SEO 有幫助嗎？目前沒有證據顯示有直接幫助
先把期待管理好：目前沒有任何官方證據顯示 WebMCP 是 Google 的排名訊號，也沒有「會被 AI 引用」的保證。想靠裝這個讓搜尋排名變好，會失望。
它改善的是另一件事：當訪客帶著他的 AI 來到你的網站時，那次體驗的品質。AI 少掉好幾個步驟就拿到結構化資料，每筆都附正式網址，引用你的連結時比較容易對到正確的頁面。這些是體驗層的改善，跟排名機制是兩回事。
另一個收穫：護欄變硬了一階。以前我對來訪 AI 的約束寫在接待說明裡，屬於「拜託你不要亂講」；現在工具層的約束寫在程式裡，價格查不到就是查不到。從口頭請求變成程式限制，當然，程式限制的效果仍取決於實作跟測試有沒有做扎實，這次那七輪審查就是在補這一塊。
- 網路上一半以上的訪問已經不是人了，你的內容準備好被機器讀了嗎？：為什麼「訪客的 AI」值得當一種正式受眾來經營，那篇講的是大環境，這篇是實作。
七、你想照做的話：判斷順序與一段可以直接貼的委託指令
記四個原則就夠，細節交給你的 AI：
- 先有公開索引。這是地基，不裝 WebMCP 也有用；索引本身也可以交辦給 AI 盤點。
- 第一版只做唯讀查詢。會改變狀態的工具（報名、留言、付款）留給想清楚確認機制之後。
- 漸進增強。不支援的瀏覽器必須完全無感。
- 有記錄就要揭露。記什麼、不記什麼，寫在給 AI 讀的說明裡。
然後把下面這段貼給你自己的 AI（要能讀寫你網站程式碼的那種，例如 Claude Code 或 Codex）：
最後一行是認真的。這次的七輪審查，在上線前實際攔下了三類落差：規格與行為不一致、檢查器有洞卻顯示全綠、對外宣告跟實作對不上。功能表面上都會動，這三類落差，都是在第二家審查時被抓到的。
邊界與不保證
- WebMCP 是 W3C 社群草案，API 可能再改；改了我就得跟著改，這是採用早期規格的固定成本。
- 目前只有少數環境支援（例如 OpenAI 的 Site tools、Chrome 的 origin trial），多數訪客的 AI 暫時用不到。
- 工具只在掛載它的頁面生效；我第一版只掛三頁（首頁、全站搜尋、agent.html），觸及面刻意窄，等有真實使用信號再擴。
- 本文寫的是知識型內容網站的做法。電商、預約制服務這類「工具要能做事」的網站，確認機制的設計比這篇難得多，不能直接套。