電商後台真正需要的是 MCP 和 Skills，別在網站後台到處塞 AI 魔術棒按鈕了

去年到今年開始看到相同慘業的幾個有名的大頭 Shopify, SHOPLINE, WordPress，不約而同在產品中加入各種 AI 串接功能，不只是提供各種 API，還有 MCP、CLI 之類的。

我嘗試模仿那些功能概念，也在自己的產品中加入這些玩意後，深感驚豔。
在某些情況下，這是一個雙贏局面:

• 使用者操作起來明顯更順手，直接在 ChatGPT 之類的 AI client 工具內把事情做完，許多原本繁瑣、對品質要求不高的工作，現在能透過自然語言或 AI Agent 快速完成。
• 對 CMS/電商系統開發團隊來說，也彷彿打開了一條新的出路，不再只是不斷堆疊後台功能，而是讓系統開放給 AI「使用」。

新的做法當然也帶來了新的問題，從開發到營運，迎來了更多新的系統管理與架構挑戰。

傳統系統的困境

在當今的線上系統開發中，許多電商網站與 CMS 系統功能越做越專業，卻也越做越讓人痛苦。開發人員花了大量時間堆砌老闆覺得應該要有、使用者覺得應該要有的功能。

程式碼不是資產，而是負債，今天跑得好好的程式，明天就可能因為 PHP 升級版本，或是調整了一些系統設定，某個上游遭遇供應鏈攻擊，造成系統問題而打亂原本的工作安排。

資料篩選條件爆炸與中台黑話?

後台管理介面裡，訂單、會員等各種資料列表頁，已經塞了二三十個篩選條件，但還是有永遠加不完的新選項，永遠開不完的功能討論會議，幾個禮拜後，沒人想得起來那個選項是幹嘛用的。沒人知道哪個選項跟哪個選項組合起來，又會爆出 500 error。

但使用者永遠覺得不夠，永遠會有無法涵蓋到、無法「一鍵產生」的查詢條件，接著便是一些對岸互聯網黑話，什麼數據中台、強調要打通任督二脈，沉澱能力，拉通全鏈路，形成一盤棋。要顆粒度對齊、口徑一致，避免數據孤島，抽象到模型層，賦能前台業務，降維打擊。要構建資產閉環，穿透到底，打標打透，精準觸達，形成閉環再反饋，最終上收下放，靈活調度，持續造血。

導入 MCP 後解決的問題：

• AI Agent 可以直接透過自然語言提出複雜查詢（例如：「找出上週二到週四、台北市、客單價 > 800、買過 A 沒買 B 的用戶」），無需再依賴固定的篩選器 UI 。
• 不再需要把窮舉所有可能的組合並做成 UI 選項，讓 AI 使用 MCP Server 設計好的結構化工具，動態組合查詢條件，大幅減少 UI 複雜度。
• 開發團隊不用再為了「使用者要更細」的資料，製作讓人密集恐懼症發作的操作介面，系統維持輕量，AI 成為「智慧查詢引擎」。

長期來看，部分後台 UI 大幅簡化，只保留常用操作，進階分析全交給 AI 處理。

到處都是魔術棒?

為了展現「我的產品有 AI」，有些系統可能在幾乎所有輸入文字的地方、插入圖片的地方，都加上了一個閃亮的魔術棒按鈕，只要點下去，就能呼叫 LLM 生成商品描述、行銷文案、留言回覆、瞎掰頁面上的企業理念、插入不知所云的 AI 圖片。

開發人員可以昧著良心，接一些來路不明的便宜中轉 API，有什麼問題都甩鍋說是 AI 的問題。也可以花很多心力，找各種成本勉強能負擔、好用、又號稱安全的國內外 LLM API，做了 prompt 工程、做了對話記憶、相容各家的 LLM API 資料格式。

結果上線後，使用者只會說：「還是直接用 ChatGPT Plus 比較好用，一個月才 600 多塊。」於是系統中的魔術棒變成了裝飾品。工程師和產品設計師越努力把 AI 塞進系統，使用者就越覺得「為什麼我要在你們這裡用一個又貴又笨的 AI ?」

導入 MCP 後解決的問題：

• AI（Claude、ChatGPT、Cursor 等）能直接連接到我們的電商系統、官網文章系統，取得即時、真實的上下文資料（商品、訂單、庫存、歷史發文等），而不是生成空泛文字、每次幹什麼事都要人類複製貼上資料給 ChatGPT。
• 生成的內容品質大幅提升，因為 AI 不是憑空想像，而是能真正「看到」資料與透過 mcp 或 skills 開放出來的業務規則。
• 使用者不再需要在系統內，硬是用一個系統商為了節省成本，而做出各種限制的「弱化 AI」，而是可以直接在自己熟悉的 AI 工具（ChatGPT、Claude Desktop 等）中呼叫網站的 MCP Server，體驗遠勝於封閉的魔術棒。
• 工程師不再需要自己維護 LLM 整合問題與各種 prompt 工程，專注做好 MCP Server 即可，讓外部強大 AI 成為系統的延伸大腦。

付費牆正在崩壞?

SaaS 產品最常見的變現思維是：把常用功能拆成基礎版，把真正好用的進階功能藏在付費牆後面。例如:

• 通知預設只能寄 Email，其他通知方式（Slack、LINE、簡訊、Webhook）要付費升級到什麼天龍地虎方案才能用；
• 付費版才能「批次一鍵全選 + 一鍵執行」「排程自動化執行」，普通版要點好幾下，在好幾個頁面之間切換。
• 宣傳頁面上有一堆吸引人的功能，先把客人騙進來，然後那些都是高階方案才有。

產品經理心想：這樣就能好好變現了。但現代的現實是：

• 有概念的使用者，只要把需求丟給 Claude 或 ChatGPT，幾分鐘就能生成一段 Google Apps Script 把通知郵件發到任何地方去。
• 寫一個簡單的 Chrome Extension，就能做到原本要付費升級方案才能做到的事。而且這些自製工具還更靈活、不用每月付訂閱費、不會擔心廠商說下個月起要買什麼方案才能用那個按紐。
• 找像我這樣的外包臨時工，做一個要跟某某某差不多，但是有一些「小地方」要調整的系統。

原本產品設計用來綁住我們的資料、維持產品營運的收費功能，變成了使用者逃離系統的催化劑。

導入 MCP 後解決的問題：

• 使用者可以直接用 AI 撰寫更強大、更靈活的自動化流程 Agent，而這些自動化是建立在我第一手提供的 MCP 工具之上，不用再繞過系統。
• 付費模式可以從「鎖功能」，轉向提供更好、更安全的 MCP 存取權限、更高額度、企業級工具、稽核紀錄等更高價值服務，使用者更願意付費取得官方、穩定、安全的 AI 整合能力。
• 降低用戶自行開發腳本的動機，因為透過 MCP + AI 的組合已經足夠強大且方便，同時減少因自製腳本帶來的資安、相容性、維護問題。

那些大廠的 MCP 做了什麼

我先不要一上來就戳破大家的好夢，不講實際上有什麼問題。也先不談程式碼實作或現實問題，先來看看那些大廠的 MCP 做了什麼。

WordPress

WordPress 6.9（2026 年初）：引入 Abilities API，這是 MCP 的重要基礎。允許 plugin、theme 和 WP Core 去「註冊」自己的能力（Abilities），讓 AI 可以發現並呼叫。

WordPress 7.0（預計於 2026 年中發布，時程一延再延）：把 Abilities API 更穩固地整合進核心，並正式加入 MCP Adapter（官方 MCP 轉接器）。這讓Claude Desktop、Cursor、ChatGPT 等 AI 工具可以更順暢地發現和使用 WordPress plugin/theme/主程式的功能。

在之前如果我要讓 AI 做一個 WordPress 自動發廢文的腳本，還要先整理發文章、傳圖片到媒體庫等一堆操作，究竟需要打哪幾支 WP REST API，用什麼資料格式。

現在回頭來看這些程式簡直就是笑話，但還是可以讓一些 WordPress 無法升級的網站用，或是在 n8n 之類的工作流工具復刻一遍。

SHOPLINE

在上個月(2026年4月)的時候，台灣的 SHOPLINE 粉專發文介紹他家的 MCP。

去查了一下文件，官方的 MCP 主要是 SHOPLINE Developer MCP，目的是幫助開發者與 AI 更快理解和使用 Shopline 的 API，用來快速查文件、產生正確的 API 呼叫範例，降低幻覺發生。
而不是直接做讓店家新增商品、改訂單的 mcp tool。

看起來有點像 SHOPLINE 把本來就有的 Open API 再套層殼，讓 AI 可以更容易使用，而不是讓系統可以無中生有，憑空產生新的功能。

如果用這個 Open API 套殼的概念出發，那我們也可以很快找到其他第三方的套殼廠商，例如 Asgard-ai 的 mcp-shopline。

不過我記得 SHOPLINE 的 Open API 是要再另外購買才能開通的，每年要額外再付幾萬塊。反正大家就記得 SHOPLINE 的 MCP 只有什麼功能，不要聽到就自己嚇自己。

Shopify

在台灣的低成本開電商的圈子可能不是這麼流行用 Shopify，那種免年費的電商平台更有名，畢竟 Shopify 最陽春的版本每年也要台幣幾千塊起，而且能用的台灣金流物流都有限。但畢竟 Shopify 是美股上市公司、慘業龍頭，產品生態系不可忽視。

Shopify 做了一些給消費者使用的 Storefront MCP 和 Customer Accounts MCP server
。

上面式我裝起來測試的範例，找最便宜的商品，平常 AI 碰到使用者丟出這種需求，通常是先用 web search tool 去找網站，然後用 web fetch tool 把網站內容抓下來，經過各種處理後產生回答，中途出問題也沒關係，反正 AI 會一本正經的胡說八道，大家也深信不疑。這下透過 MCP 則是直通商品資料，速度更快，準確度更高。

Shopify 另外還有一套給開發者使用的 Dev MCP server。

如果只論店家編輯人員管理電商網站資料，同樣有一堆第三方廠商開發的 Shopify MCP Server，Shopify 還有跟 Claude, OpenAI 開發的應用程式。

Emdash

Cloudflare 在上個月(2026 年 4 月)推出的新開源 CMS，目前還在開發預覽版。Introducing EmDash — the spiritual successor to WordPress that solves plugin security

官方文章標題直接就跟 WordPress 對幹，一般使用者看到產品 demo 後台，編輯介面大概就跟 10 年前的 WordPress 一樣，也沒有區塊式功能，實在不懂有什麼臉出來嗆聲。

外行看熱鬧，內行看門道，如果是沒什麼人來逛的網站，用 Emdash 架在 Cloudflare 的成本甚至有可能趨近於0，還有 Emdash 的外掛隔離式設計也是非常特殊，以前要是提供這種設計大概只會被人當白痴。

Emdash 最大的特色是強調 AI-native，AI 可以直接管理整個網站，適合那種適合需要大量 AI 輔助內容創作與管理的團隊(怎麼聽起來這麼像生產網路垃圾的內容農場?)。

MCP/CLI/Skills，要開發哪一種給使用者使用?

為啥不讓 AI 直接接 API 就好，慘業又要憑空發明幾種新的格式，主要還是協議層面的標準化問題。

從上面案例我們見識到了一些可能性，這不是傳統那種做個 API 給人用，然後兩邊的工程師整天在爭論狀態碼、資料格式、API 文件維護等等問題。

要讓 AI 能「使用」網站後台，最常見的選擇有三種方式:MCP/CLI/Skills，各有各的優缺點。

MCP(Model Context Protocol)

MCP 是目前最主流的標準，一開始由 Anthropic 在 2024 年底提出，可以讓 AI 直接存取目標資料。有 SSE (Server-Sent Events)、JSON-RPC over Stdio、JSON-RPC over HTTP 三種傳輸方式。

本文實作主要是 JSON-RPC over HTTP 這種的，最接近一來一回的 web api，而且最適合本文討論的應用場景(店家透過 AI 幫忙管理網站)，其他種比較適合完全沒有網路連線，或是要一直跟伺服器保持不斷線的使用場景。

MCP 簡單來說就是多寫一套程式，用 jsonrpc 接收各種規範好的 method 請求，例如 tools/call、tools/list、resources/read、initialize、prompts/list 等等，還有處理每個請求帶上的參數(params)。

在 tools/list 中要定義每個 mcp tool 的 inputSchema。在 initialize 中要定義 instructions 等各種基本資訊，告訴 AI 這個 MCP server 的用途。

然後讓 AI 看那些 instructions 而望文生義，自己知道調用哪個 tool，以及生成呼叫 tool 需要什麼參數。

Skills(Agent Skills)

Agent Skills 又是 Anthropic 在 2025 年 3 月提出的標準，用來讓 AI agent 能夠使用各種技能，在技能包中會有一些定義技能的 md 檔案跟提示詞檔案，還可以放入各種 python 跟 php 檔案，用來輔助執行。

CLI(Command Line Interface)

嗯...CLI 就是 CLI，在電腦上安裝程式和註冊變數之後，就可以在命令列(terminal)中直接使用。可以輸入指令來執行程式。AI 就是透過生成指令和接收指令的回應結果，在某些使用場景下，可以用更高的效率來操作程式。

例如一些 WordPress 的管理操作，還要裝一些付費套件、在 UI 上點老半天? 有些就是 WP CLI 下一些指令就能處理的。但是一般什麼便宜虛擬主機 WP 架站的環境，根本不可能開放這種權限。

這種給 AI 用的 CLI 跟以前那種給人類工程師用的 CLI，也需要有不同的設計思維，例如以前的 CLI 輸出這種資料
ID Customer Total Status
10293 張 1500 Paid
10294 林 2800 Shipped
有的甚至還會加上顏色、各種視覺效果，讓命令列操作也能覺得心曠神怡。

但 AI 後續如果還要排序、篩選、計算、再接其他流程，上面的資料格式就很容易解析錯誤。
給 AI 用的 CLI 最好能強制輸出有結構的資料，而且欄位名稱要清楚、有語意，例如:

{
  "orders": [
    {
      "order_id": 10293,
      "customer_name_masked": "張**",
      "total_amount": 1500,
      "currency": "TWD",
      "status": "paid"
    },
    {
      "order_id": 10294,
      "customer_name_masked": "林**",
      "total_amount": 2800,
      "currency": "TWD",
      "status": "shipped"
    }
  ]
}

錯誤訊息也不能只寫"Invalid argument"，應該明確告訴它哪個參數錯、允許哪些值、下一步可以怎麼修正。

AI 不吃工程師之間那些「看一下就知道」的默契，它需要的是清楚的參數、穩定的輸出、明確的錯誤、保守的預設值，以及可以追溯的執行紀錄。

要選哪一個?

技術上來說這不是三選一的問題，而是可以同時存在的。可以做一個 Skills 當上層，讓 AI 去呼叫 MCP 和 CLI。也可以做個本地 MCP，中途有 tool 會呼叫 CLI。但開發量能不足，總要先挑一個效益最高、問題最少的。

大家應該想到最大的問題在哪了:
1.CLI 跟 skills 會有一包檔案，這包檔案可能需要能被主動強制更新。
2.需要放在使用者的電腦上執行程式。

做出來的 CLI 工具有考慮 Windows 跟 MacOS 系統的差異嗎?
在 skills 資料夾放一些 python 或 php 或 node.js 程式，有考慮過使用者的電腦有沒有安裝執行環境嗎?
如果使用者用的裝置是「你的下一台電腦何必是電腦」，行動裝置 APP 的功能跟電腦上的差異很大，如果 skills 內有一些 CLI, php 程式, python 程式，這根本無法使用，整個流程都要重新規劃。

MCP 的 HTTP 模式幾乎不需要煩惱這些事情，我只需要給一個 URL 和一個 Token 就能用。

當然我知道有些單位特別注重儀式感、人力成本很便宜、最喜歡跑去現場幫客戶安裝、設定、維護，在電話中一步步指導操作，覺得開一個黑黑的終端機視窗在設定看起來很專業，那一定要選擇 CLI 或 Skills，而且日後每次有更新時，還可以找到機會通知客戶。

反觀 MCP 在這點就很爛，貼個網址幾分鐘就設定好，工程師在雲端更新了一堆 tool，使用者也看不出來，對消費者心理和對開發端都是種傷害。

當決定要將功能「產品化」或是「開放給一般人用」時，勢必要考慮到使用者的使用習慣和環境限制。

實際開發問題

在實際開發 MCP server 時會遇到很多問題，但也可以從中更了解事物運作的思維邏輯是什麼，而不是幻想 AI 很厲害。

直接把後端的 API 回應包成 MCP Tool 就能用?

有人可能把事情想得很簡單，把本來的程式直接 include 到 MCP Tool 會呼叫的程式中，本來的程式都不用改，只要調整一些接收跟回應的程式，以後就能出一張嘴使喚 AI ，讓 AI 完全代操作網站後台了?

大錯特錯，例如之前的程式可能有後端 API，例如後端回應一包 JSON，前端程式處理成 UI。

{
  "id": 10293,
  "st": 2,
  "p_type": "A",
  "g_id": 50,
  "amt": 1500,
  "cur": "TWD"
}

使用者的 AI 透過 MCP 拿到這種東西，LLM 根本不知道拿到的 p_type 和 st 是什麼東西?

所以在開發 MCP Tool 或 CLI 腳本中，應該做成類似這種看似比較有語意的格式：

{
  "order_id": 10293,
  "status_text": "已出貨",
  "product_category": "實體商品",  
  "group_id": 50,
  "amount": 1500,
  "currency": "TWD"
}

或者乾脆直接回傳一段可讀的文字：

"訂單 #10293 目前狀態為 [已出貨]，總金額為 1500 台幣。"

當然人類交待給 AI 的任務能不能成功，就看使用者的 LLM 能不能理解這些資訊。
搞不好有的 LLM 把上面的資料解讀成這張訂單有 1500 件商品，出貨人員的性別認同(Gender Identity)是 50 號(以 Facebook 的 50 幾種性別來分)。

有些 AI client 軟體只認 OAuth 驗證方式

之前在各種 AI coding 工具用過 MCP，設定方式通常是:

• 打開軟體設定，絕對可以看到一眼看到設定 MCP 的地方，這些程式開發工具不會把專有名詞另外改名包裝成什麼「自訂你的 AI 智能體」之類給新手看的名詞。
• 用 npx add mcp 某某的指令進行安裝
• 像 Cursor, Windsurf, Antigravity 之類的，就是直接改一個 json 檔案
• 像 GitHub Copilot 還有一個「MCP 伺服器市集」，有上架在裡面的，滑鼠點一點就裝好了。

那換成一般使用者用的 AI 軟體，要怎麼安裝 MCP?

在 Claude Desktop 中，根本不叫 MCP，要在 Settings>Developer>Edit Config 中設定，然後又要改 JSON 檔案。(claude_desktop_config.json)，在 mcpServers 加一組類似這樣的東西

  "web-admin-mcp": {
      "command": "npx",
      "args": [
          "mcp-remote",
          "https://example.com/XXXXX/mcp",
          "--header",
          "Authorization: Bearer ${MCP_TOKEN}"
      ],
      "env": {
          "MCP_TOKEN": "blahblah"
      }
  }

到了 ChatGPT 就更麻煩，要先到設定>應用程式，打開開發者模式，然後建立應用程式，一打開發現設定介面長這樣子

呃...我是用 Authorization: Bearer 驗證，根本沒設計成用 OAuth 驗證，不過幸好跟 OpenAI 同一家的 Codex 可以設定用 Bearer 驗證的 MCP Server。

然後御三家的最後一家 Gemini，在連結的應用程式中根本沒得自訂 MCP server，只有 Gemini CLI 或其他產品線才有。

然後像 OpenCode 是要找到 C:\Users\{使用者名稱}\.config\opencode\opencode.json 這個檔案，然後參考官方文件 mcp-servers/#遠端看要怎麼打。

還有一些普通人使用的免費版 AI，根本找不到要如何設定。例如 Monica、Windows Copilot(不是 Copilot Studio) 等等。

再來是一些免費開源模型，tool calling 的能力非常差，有興趣的可以關注 Berkeley Function-Calling Leaderboard。還有一些二三四線的 AI 軟體，除了聊天對話的基本功能之外，像 MCP 之類的進階功能要嘛沒做，要嘛 bug 滿天飛，根本沒辦法用。真的不要怪大家為什麼免費 AI 這麼多，有人還都要花錢去買那幾家 AI。

不是給個清單，AI 就會自己組合資料

一開始設計了一些清單型 tool，例如列出商品資料、列出不含個資的訂單資料。

但是跟串好 MCP 的付費 AI Claude 或 ChatGPT 提問:
「這個月哪個商品賣最好?」
「依照銷售預測，哪些商品可能會即將庫存不足?」

我覺得 AI 可以自動撈出商品資料、撈出訂單資料，剔除訂單退貨或未付款什麼的，然後自動去重、排序、計算。聰明的 LLM 還會把同一商品的 XXX(五包入)和 XXX(十包入)當成同一個商品來計算。

想像很美好，但實際發生的:

• 很抱歉，目前透過 XXX 的工具，沒有辦法查詢商品銷售排行或歷史訂單明細，工具名稱是什麼？確認後告訴我工具名稱，我可以直接嘗試呼叫看看！
• 呼叫列出訂單的 tool，什麼日期跟訂單狀態條件都沒設(我剛不是說要查本月的嗎?)，查了第一頁訂單，隨便胡亂回應一下就結束了。
• 看系統紀錄真的有去撈資料，但是 AI 就直接回應「抱歉，我無法回答這個問題」，因為資料量太大了
• AI 有回應，但完全不對，發現差不多是整理到一半，大概超過推理量或某種系統行數限制，然後就開始胡亂回應。

我還是要再乖乖做一堆 mcp tool，取名 rank_products_by_sales 之類的簡單易懂的好名字，讓 AI 對於熱銷商品、庫存不足、瀏覽數高的商品之類的查詢需求，才真的知道要呼叫哪一個 tool，快速做出回應。

不過 LLM 還有各種特產，例如 lost in the middle, positional bias，都會導致就算 MCP 提供了正確資料，AI 還是回應得亂七八糟。

嚴格的資料格式限制

讓 AI 使用 MCP 編輯網站資料，不是天馬行空讓 AI 隨意亂填，仍然是一個蘿蔔一個坑，並且需要更嚴格的坑位限制，還要想辦法引導 AI。畢竟 AI 可以說不幹就不幹，出錯時反覆來回操作，花的也是人類付錢買的 AI 費用。

首先在每個 tool 的 description 就要寫好工具介紹:

[
    'name' => 'create_xx',
    'description' => '建立新的 XX 資料。標題為必填；slug 可省略（系統將自動根據標題產生）；封面需傳入媒體庫的 media_id；狀態僅限：public (公開), hide (隱藏), member_only (僅限會員)。',
    'inputSchema' => [
        'type' => 'object',
        'properties' => [
            'data' => [
                'type' => 'object',
                'properties' => [
                    'title' => [
                        'type' => 'string',
                        'description' => '資料標題',
                        'minLength' => 2,
                        'maxLength' => 50   
                    ],
                    'slug' => [
                        'type' => 'string',
                        'description' => '網址代號',
                        'maxLength' => 30,  
                        'pattern' => '^[a-z0-9\-]+$' 
                    ],
                    'media_id' => ['type' => 'integer', 'description' => '封面圖片 ID'],
                    'status' => [
                        'type' => 'string', 
                        'description' => '狀態：public|hide|member_only',
                        'default' => 'public'
                    ]
                ],
                'required' => ['title'] // 僅強制要求標題
            ]
        ],
        'required' => ['data']
    ]
]   

Schema Reference

然後接下來開始祈禱，AI 看這個這個介紹會知道 media_id 真的會給出數字，不是UUID，不是直接填一串 URL，祈禱 AI 會自己知道去尋找相關的 tool，祈禱能找到列出媒體物件和上傳媒體物件的 tool，祈禱正確使用媒體物件的 tool，祈禱 AI 會自己推理出完成一個任務時，中途可能需要的工具鏈。

再來可以在 inputSchema 一一補上每個參數的格式限制，例如日期、數字、字串格式是怎樣等等。當然如果資料格式不正確，網站端的系統就會回應錯誤。當然上游資料出錯，AI 還是有可能會瞎掰一些回答來唬爛人類，例如新增資料的資料格式不對，AI 還瞎掰說已經新增完成。

然後要讓 AI 寫入資料到網站，例如在頁面插入一個聯絡表單、更新商品數量、展示清單等，這些都需要非常嚴格的資料格式限制。否則網站後台編輯介面或前台頁面吃到那些不正確的資料，就會出現奇怪的問題，上面這些規格書 prompt 般的限制，實際上還是常常形同虛設，我們要上一些強硬的手段。

一種是白名單法，例如:

• 把正確的參數通通列出來，例如參數叫 columns_desktop, columns_mobile 之類的，避免生成 perViewDesktop, perViewMobile 之類不存在的 json key 名稱。
• 然後開一個 tool，告知 AI 要做某些操作時，要先呼叫 tool，去查白名單上的可用名稱，
• 在資料儲存時，驗證 AI 是否生成了白名單以外的 json key 名稱，顯示明確的錯誤訊息，祈禱 AI 可以自我修正。

另一種是自動修正法，AI 愛把 block_type 寫成 type，那我們就做幾套正規化程式，會自動把它轉回 block_type。
當然這種規則要做的話，是絕對列舉不完的，最適合拿來整我們基層人員，先決定一種一定會有問題的策略，然後日後出問題，再把第一線執行的人狗幹一頓，非常完美的背鍋流程。

我們不能控制 LLM 到底要生成什麼，只能在生前...生成之前先引導它，並在生成後想辦法修正。白名單法、正規自動修正法，都只能算是一些防線。現實是哪天真的要用到 type 時，可能還要 debug 老半天，為什麼資料都會被自動轉換? 喔，原來是在背後偷偷改了。

效能與連線問題

網站可能沒有多少訪客，但只要同時好幾個編輯人員在使用 MCP 更新商品、瘋狂查詢數據、自動檢查並修改站內資料，就可能造成系統負載過高。

ChatGPT 或 Claude Desktop 等各種 AI client 軟體都有各自的健康檢查機制，從網站 access log 可能會看到那些 mcp 專用的 endpoint，不定時就被自己的 IP 瘋狂連線。然後店家端人員透過 AI 使用 MCP 時，經常瞬間就造成大量 API 請求，有機會一不小心就升高系統負載。

這種現象對於一堆網站放在同一個共享資源的系統環境架構，這不只傷了鄰居的和氣，如果網站還有用到一些按照請求數計費的 serverless 架構，收到帳單肯定爽翻了。但客人會因為這個功能而願意多付錢嗎? 夢話去夢裡面說吧。效能優化有千百條路，但是就看現實讓不讓人走那些路。

所以我又先加了個 rate-limit 機制，限制 mcp 一天只能被呼叫幾次。

但是用量用完後也不能全部封鎖，不然 ChatGPT 或 Claude Desktop 在每次啟動時或中途檢查時，一旦發現 mcp server 無法連線，就會一直跳警告。

所以還得做成宣告 tool 相關的 method 要能正常通訊，例如 initialize 和 tools/list 要正常接受請求並回應，等到其他真正的 tool 被呼叫時，才跳 429 error 的警告訊息。

做 MCP 才不是讓 AI 直接讀寫資料庫

在前幾點破除了一些迷思，例如開發 MCP 不是把本來的 API 包一層就完事了；不是把資料直接產生一個大清單，AI 就知道要怎麼用。而是要重新思考如何讓 AI 更好地使用這些功能。

那可能有人以為做這種讓店家端用 AI 管理網站的 MCP Server，就是讓 AI 直接讀寫資料庫?
雖然市面上有些工具（如 Chat2DB）標榜讓 AI 生成 SQL 讀寫資料庫，但在網站營運場景中，這是非常危險且低效的。

基本邏輯是使用者端的 AI 根本看不到網站程式碼，不知道資料庫欄位名稱 p1~p12 是拿來幹嘛用的，這件事只有網站自己的程式碼才知道。

例如有些資料是用加密字串存在資料庫的，AI 直接查詢 SQL 只會得到一堆亂碼，只有透過 MCP 呼叫後端，利用現有的解密邏輯，AI 才能拿到可閱讀的資訊。

現代網站常將一些難以正規化、會無限擴充變動的東西，存在單一欄位的 JSON 中。AI 很難精準地寫出 JSON_EXTRACT 或操作特定的 key name 來達成任務。我們必須先把這些複雜性封裝起來，而不是直接讓 AI 亂動 JSON 結構。

本文討論的功能是讓 AI 新增編輯刪除資料，讓 AI 有資料庫刪除權限顯然不是一個好主意，AI 可能因為理解錯任務、選錯 tool、填錯參數、誤判使用者意圖，就把不該刪的資料送進刪除流程，還可能在刪除失敗或回傳訊息不清楚時，自信滿滿地跟使用者說「已經完成」。還是讓 AI 操作只能 soft delete 的程式就好。

現實是又要每個管理發一組金鑰，然後根據每個金鑰控制不同的使用權限，沒有訂單權限的人自然也不能操作訂單相關的 mcp tool，開發成本和維護成本都直線上升。

觀測性問題

當 AI 透過 MCP 執行操作時，我們需要確保這些操作是可追溯的，但這件事比傳統網頁後台麻煩很多。

在人類操作後台時，至少我們大概知道使用者是誰、登入哪個帳號、從哪個頁面點了哪個按鈕、送出了哪個表單。一般系統操作紀錄可能只記錄執行了什麼動作，例如匯出會員資料、修改訂單狀態、幾點幾分用什麼裝置登入，甚至為了節省系統資源，一堆東西實際上都沒紀錄。

即使系統紀錄做得很陽春，access log 裡看到一堆 GET、POST 請求，發生問題時時間點的 URL path，大概還能猜出使用者走了哪些路徑。

但 MCP 不是這樣。

我無法知道使用者在 ChatGPT、Claude、Cursor 或其他 AI client 裡實際輸入了什麼 prompt。撈網站 access log 內的 User-Agent 字串，也沒有老老實實寫著 ChatGPT、Claude Desktop、Cursor，有些甚至只是一般的 node、Python/3.12 aiohttp/3.13.5、Go-http-client/2.0，或經過其他中轉工具送過來。

MCP 走的是 JSON-RPC，在 access log 看起來只是一片沒意義的 POST 海。

這邊的 log 要記錄的東西又跟傳統的操作 log 不同:

• 我們需要紀錄這是哪一個管理員的金鑰在發出請求
• 紀錄上要能區隔出人類在網頁上操作，還是透過 MCP 操作的。
• MCP log 需要紀錄 AI 呼叫了哪些 tool, param 帶了什麼資料，mcp server 當下執行了什麼，回應了什麼，發生問題時才能快速定位到問題的根源。

更麻煩的是 AI 是不可能背鍋的，例如 mcp server 已經有正確回應資訊

{
  "orders": [
    { "total": 5000, "customer": "張**" },
    { "total": 8000, "customer": "林**" },
    { "total": 12000, "customer": "林**" }
  ]
}

然後 LLM 在回覆給人類時說：「最高消費是張**的 12,000 元。」

從工程的角度看，資料回傳是正確的。
從使用者角度看，AI 給了錯誤答案。
從產品責任角度看，使用者只會覺得「這個 AI 功能有問題」。

我們不可能像傳統管理方式一樣，把 LLM 叫進辦公室，問他最近怎麼常常出錯? 也不可能把 LLM 的主管叫進辦公室，問他是怎麼管理和訓練底下的人的? 也不可能把 OpenAI、Anthropic 或 Google 的 CEO 叫來給老闆罵。最後能被叫進辦公室的，通常還是做這套 MCP 程式的人。

紀錄做得不夠完整，MCP 一開始看起來很方便；但只要出一次資料錯亂、錯刪商品、錯改價格、錯發文章，後面就會變成工程師、編輯人員之間的大型甩鍋現場，只有問題源頭的 AI 供應商毫無責任，畢竟已經有免責聲明。

Open AI 的使用條款和 Anthropic 的使用條款都有定義他們的產品叫輸入輸出服務，

You may provide input to the Services (“Input”), and receive output from the Services based on the Input (“Output”). Input and Output are collectively “Content.”

Generally. You may be allowed to interact with our Services in a variety of formats (we call these “Inputs”). Our Services may generate responses (we call these “Outputs”)

然後這些輸入輸出的內容不保證正確性，請自己查證。

真的要為了 AI 而 AI 嗎?

如果可以做一個完全沒有 UI 的管理後台，只提供 MCP tool，這樣可行嗎? 當然不可行。

也許有些操作很適合這種 AI 組合技，例如同時設定了網站編輯的 MCP、SEO 工具的 MCP、文案撰寫的 skills，只要提出一個主題大綱，AI 來幫你完成一連串的任務，這樣效率會比人類一個一個操作來得高。

但有些操作硬要在 AI 中使用，例如在 ChatGPT 裡面挑選商品照、列印單據? 所有功能都仰賴 ChatGPT/Claude Desktop 能不能把資料顯示成表格、圖片、列表等格式，這都是控制權不在我的事情。

還有些操作在傳統的 UI 上一目了然，例如選了 A 選項後，就有相關的一些選項會出現，一些選項會鎖住，這對使用者是直觀的引導。但是在 AI 中。需要使用者透過發問、對話，AI 才會回答，效率不見得有比較高，就像現在用一些 AI 工具做圖一樣，花了半小時想把文字往上移一點，右邊留白多一點，在傳統的設計編輯流程，這不就是選中圖層移動一下的事情?

然後程式端要製作更多錯誤提示訊息，例如用 500 字說明哪些選項是互斥的，只能怎樣選才是對的，現在是在玩 MUD 文字遊戲還是密室逃脫啊?

有些極度敏感的操作，在傳統網頁後台 UI 處理時，資料只會存在於「伺服器」與「瀏覽器」之間。一旦改用 MCP，這些資料就必須流經 AI 廠商的伺服器。為了符合有些行業的資安要求，或是有些單位的內控管理，這類敏感資料任務應禁止開放給 AI，或是做一堆去識別化設計。

MCP 可能讓後台更簡單，但不一定讓系統更簡單

對系統開發而言，殘酷的現實是維護成本的倍增。一旦決定擁抱 MCP，等於專案程式碼中從此多了一個平行宇宙。

未來只要網站核心功能一改版、資料庫結構一調整，不只要改網站前後台的前後端程式，還要額外去照顧那一套 MCP Server 的程式碼。

而且設計 MCP Tool 的邏輯跟寫一般 Web App 完全是兩回事。寫一般網頁後台一個要點是「防呆」（防範人類的不小心與亂點），但寫 MCP 是「防幻覺」（防範一個自作聰明、極度自信、還會自己腦補欄位格式的超級大腦）。我要教 AI 怎麼分步驟拿資料、怎麼在報錯時自我修正，這兩者的防禦機制、錯誤提示設計，甚至是效能考量，完全不在同一個維度。

普通網頁後台，背後偷改欄位、改流程，使用者可能根本不會發現，改 UI，最多是使用者重新適應。
但要是 MCP 亂改 tool 名稱、改 schema、改回傳格式，可能會讓使用者原本在 ChatGPT、Claude 裡設定好的工作流失效。
甚至 AI 之前學會的操作模式，也會因為 tool description 或 schema 變動而變不穩。

一堆功能要重新設計，把複雜度從人類可見的 UI 搬到 AI 可操作的標準協議，這本身就是一個工程。工程化問題很累，但做這種「看不到的東西」，通常是沒辦法成為有功的猴子的。

小型店家反而更適合 MCP？

聽到層出不窮的技術名詞，很容易以為這又是大公司、有工程團隊、有資訊部門才玩得起的東西。但實際做下去後，我反而覺得，小型店家可能才是最容易感受到 MCP 價值的人。

原因很簡單，小型店家的人力槓桿太嚴重。一個人可能同時要當美編、客服、攝影、行銷企劃、商品上架人員、網站管理員。這些工作本來就已經大量離不開 ChatGPT：寫商品描述、改活動文案、想社群貼文、生成留言回覆、整理 FAQ、產生 SEO 標題，最後再把內容複製貼上回網站後台。

網站後台多了 MCP 功能串接 AI，讓原本已經在 ChatGPT 裡完成的工作，不必再靠人工搬運。以前是「叫 ChatGPT 寫好，再自己貼回後台」；現在可以變成「在 ChatGPT 裡整理好內容，直接建立文章草稿、更新商品描述、調整頁面區塊」。對小型店家來說，這是少開幾個分頁、少貼錯幾次欄位、少浪費半小時的實際差異。

反而大型公司未必適合這種高度自由的 MCP 操作。(理論中的)大公司有專門的行銷、設計、編輯、工程，每次發文或改活動頁，都要做幾張 PPT，經過法務與主管審核流程，根本不可能有一個人用自己的 ChatGPT 直接改正式網站資料這種事發生。

對大型組織來說，MCP 比較可能被設計成內部受控的草稿產生器、資料唯讀的查詢工具、審核流程入口，而不是讓 AI 直接編輯公開的網站資料。

所以這種工作流程的適用對象，是決策路徑越短、角色越混合、越常依賴 ChatGPT 這種工具完成日常工作的團隊，越容易感受到 MCP 的價值。

結語

說到底，搞了這麼多 MCP、Skills，有時候退一步看，真的會懷疑是不是一場工程師跟資訊慘業的自嗨與技術噱頭?

我們好像已經走到 AI Agent、自動化工作流、MCP 跟 Skills 滿天飛的時代，但走到第一線，可能還是公司一堆人共用一個帳號，或是註冊一堆帳號薅羊毛用免費額度，或是使用 Google 企業信箱或微軟 Office 365 裡面「附贈」的 AI，在聊天跟多個分頁裡複製貼上、上傳文書檔案、叫 AI 幫忙想一段文字、整理表格。

把 AI 深度整合進系統，絕對是個迷人的技術挑戰，確實能在某些情境下摧毀傳統系統 UI「資料篩選條件爆炸」之類的痛點。

但如果在投入開發前，沒有想清楚客群有沒有對應的數位素養，或是團隊沒有量能去扛下另一套系統的維護與 SRE 災難，那真的不要「為了 AI 而 AI」。

畢竟，比起一個動不動因為 LLM 格式出錯或而無法操作的高級 MCP，使用者可能還是覺得那個在聊天視窗裡剪剪貼貼的自己，更有掌控感跟安全感吧。