AI 架站怎麼做？用 ChatGPT 或 Claude 直接建網站與預約系統

TL;DR

• 目前被稱為「AI 架站」的做法大致有三類：請 AI 寫出網站程式碼、使用 AI 生成版面的建站工具、讓 AI 直接操作既有平台。三者能處理的範圍差距很大。
• 請 AI 寫程式碼的路線，卡住的通常不是程式碼本身，而是部署：檔案要放哪裡、網域怎麼指過去、憑證與資料庫由誰負責、之後改一個字要怎麼更新。
• 多數 AI 網站設計工具產出的是靜態版面。線上預約、會員、商品這類需要資料與流程的模組，仍須回到後台手動設定。
• 讓 AI 直接操作平台，前提是平台先開放一道標準介面。目前的共同標準是 MCP（Model Context Protocol），2024 年 11 月由 Anthropic 提出並開源，2025 年 12 月捐給 Linux Foundation 底下的 Agentic AI Foundation。
• 接上之後，網站的建立與後續修改可在對話中完成，AI 的費用計入使用者原本的 ChatGPT 或 Claude 訂閱。
• 權限是這件事能不能放心用的關鍵：逐項授權、保留操作紀錄、限制刪除範圍，比「AI 能做多少」更值得先確認。

目錄

• 「AI 架站」目前有三種不同的意思
• 請 AI 寫程式碼做網站，卡住的通常不是程式碼
• AI 網站設計的限制：版面生得出來，營運模組生不出來
• 讓 AI 直接操作平台，需要平台先開一道介面
• 實際流程：從一句話到可以接受預約的網站
• 權限與風險：AI 改得了什麼、改不了什麼
• 什麼情況適合用這種方式建站

引言

搜尋「AI 架站」會得到兩種落差很大的結果。一種宣稱輸入一句描述就能產出完整網站，另一種只是在既有的編輯器裡加了一個生成文案的按鈕。兩者都用同一個詞，實際能替使用者省下的工作卻不在同一個量級。

差別不在模型好壞。真正決定範圍的是：AI 產出的東西，是停在畫面上，還是能寫進網站實際運作的資料裡。

「AI 架站」目前有三種不同的意思

第一類是請 AI 直接寫出網站程式碼。這是目前最多人嘗試的做法：向 ChatGPT 描述需求，得到一份 HTML 或前端框架的程式碼。畫面在對話裡看起來完整，問題出現在拿到程式碼之後——那是一包檔案，不是一個可以給客人看的網址。

第二類是使用具備 AI 功能的建站工具。輸入行業與風格描述，工具產出一組版型與示範文案，或在編輯器內提供生成按鈕協助撰寫段落。網站本身會上線，但 AI 的作用範圍多半止於版面與文字。

第三類是讓 AI 直接操作既有平台。使用者在自己慣用的 AI 對話介面中提出需求，AI 透過標準介面呼叫平台功能，直接建立頁面、寫入內容、設定模組。這一類出現得最晚，因為它需要的不只是模型能力，還需要平台端主動開放介面。

三者的分野在於「AI 的輸出最後落在哪裡」。第一類落在檔案，第二類落在畫面與文字欄位，第三類落在平台的資料與設定。

請 AI 寫程式碼做網站，卡住的通常不是程式碼

多數人第一次嘗試「用 AI 架站」，是請 ChatGPT 寫一份網站的程式碼。這一步通常出乎意料地順利，真正的難關在後面。

程式碼產出後，它以檔案的形式存在於電腦裡。用瀏覽器打開可以看到畫面，但那個畫面只有自己看得到。要讓客人也看得到，需要處理一連串與寫程式無關的工作：找一個放置檔案的地方、把網域指向那個地方、設定安全憑證讓網址前面出現鎖頭圖示、確認手機開起來不會跑版。

這幾件事各自都有現成的服務可以解決，困難在於它們分屬不同供應商、各有各的設定介面與計費方式，而且出錯時的訊息通常假設閱讀者已經懂了。對沒有相關背景的人來說，最常見的狀況是網站看起來做好了，卻始終停在自己的電腦裡。

接下來還有一層。純粹展示用的網站（只有文字與圖片）確實可以靠靜態託管解決，但只要牽涉到訪客要填東西——聯絡表單、線上預約、會員登入、購物車——就需要一個能接收與保存資料的後端，以及一個資料庫。這是前端與後端的分界：前者決定畫面長什麼樣，後者決定資料存到哪裡、由誰處理。AI 可以把兩邊的程式碼都寫出來，但誰來執行這些程式、資料放在哪一台機器上、費用怎麼算，仍需要有人決定並持續維護。

最後是更新。網站上線之後改動不會停止——換一張圖、調一段文案、加一項服務。走程式碼路線的話，每次改動都要重新產生檔案並重新部署一次；改壞了要有辦法退回上一版；伺服器與套件需要定期更新以維持安全性。這些工作在網站生命週期裡佔的比重，通常比「做出第一版」大得多。

需要說明的是，這不是 AI 能力的問題。把網站送上線本來就包含開發以外的一整套工作，AI 只是讓其中「寫程式」那一段變快了，其餘的部分並沒有消失。判斷自己適不適合走這條路，可以參考從維護責任切入的比較——決定因素通常不是預算，而是後續由誰負責。

使用建站平台的路線，差別在於上述工作已經是預設狀態：網址、憑證、資料庫、寄信服務、備份都已經存在並持續運作，剩下的只是內容。這也是為什麼「AI 直接操作平台」與「AI 產生程式碼」在實務上不是同一件事——前者的產出一寫入就是線上狀態，不存在部署這個步驟。

AI 網站設計的限制：版面生得出來，營運模組生不出來

多數 AI 網站設計工具能處理的範圍，止於視覺與文字。這個限制在純形象網站上不明顯，在需要營運的網站上會立刻浮現。

以預約型商家為例。AI 可以產出一頁排版良好的服務介紹，但下列項目仍需人工設定：每項服務的時長與價格、每週開放預約的時段、預約成立後的通知收件人。少了這些，訪客看到的是一份漂亮的服務清單與一個打不開的預約日曆。

電商與餐飲同理。商品的價格與庫存、菜單的分類與品項，都存放在資料表而非頁面上。頁面上的商品區塊只是容器，實際內容來自另一套設定。

這也是「AI 五分鐘做好一個網站」與「AI 五分鐘做好一個能接生意的網站」之間的落差。前者是版面問題，後者牽涉到平台的資料模組。

讓 AI 直接操作平台，需要平台先開一道介面

要讓 AI 能寫進平台的資料，平台必須先把自己的功能定義成 AI 讀得懂、呼叫得動的形式。這件事目前的共同標準稱為 MCP（Model Context Protocol，模型脈絡協定）——一套讓 AI 應用程式與外部系統溝通的開放規格。

MCP 由 Anthropic 於 2024 年 11 月提出並開源，隨後被 OpenAI、Google DeepMind、Microsoft 等採用；2025 年 12 月捐給 Agentic AI Foundation——一個由 Anthropic 與 Block、OpenAI 共同創立、隸屬 Linux Foundation 的組織。換言之，它已經不是單一廠商的規格。

對使用者而言，這代表兩件事。其一，同一個網站平台可以同時被 ChatGPT、Claude 或其他支援該規格的工具操作，不必為了某個 AI 換平台。其二，AI 的運算費用計入使用者原本的訂閱，平台端不需另行收費。

多數建站服務目前採取的做法，是在自家後台內建一個 AI 面板。差別在於操作的起點：面板式的做法要求使用者進入平台後台，介面式的做法則讓使用者留在原本的工作環境裡。AHHA 選擇的是後者，平台功能以 MCP 對外開放，由使用者自己的 AI 呼叫。

實際流程：從一句話到可以接受預約的網站

以美甲工作室為例。接上之後，使用者在 ChatGPT 或 Claude 的對話中描述需求，實際發生的順序大致如下。

AI 會先詢問幾項無法自行推斷的資訊：實際營業時間、每項服務的時長與價格、聯絡方式。這些屬於商家事實，錯了會直接影響到店客人，因此不由模型推測。

取得資訊後，AI 依序建立首頁與內頁的版面與文案、寫入服務項目與各自的時長價格、設定每週開放預約的時段、補上頁腳的聯絡資訊與搜尋結果要顯示的標題描述。需要配圖時，可從免費圖庫中挑選候選圖片交由使用者確認。

完成後訪客即可在網站上完成預約。後續修改同樣在對話中進行——變更文案、調整版型配色、新增服務或商品、修改營業時段，都不需要回到後台。

值得說明的是修改既有頁面的方式。AI 會先讀回該頁目前的完整內容，只更動指定的欄位，再整份寫回。這個順序的用意是避免其他區塊的設定在改寫過程中遺失。

權限與風險：AI 改得了什麼、改不了什麼

把網站交給 AI 操作，第一個反應通常是擔心而非期待。這個顧慮合理，因此權限設計比功能範圍更值得先確認。

AHHA 的做法是逐項授權：查看網站、閱讀文章、建立草稿、發佈文章、編輯版型與內容、新增服務與商品、取用圖庫，共七項各自獨立，預設只開放唯讀與草稿，風險較高的項目需要使用者主動勾選。每一次操作都留下紀錄，授權可隨時撤銷。

限制的部分同樣明確。AI 無法刪除文章、商品、服務與會員預約等營運資料——這類資料一旦誤刪難以復原，而使用者自行在後台刪除並不困難。覆蓋既有頁面或既有營業時段時，需要再次確認。網域設定與寄信功能不開放。

還有一項不容易察覺但需要注意：AI 在讀取外部網站內容時，可能受到頁面中刻意植入的指令影響，這類手法稱為提示詞注入。因此真正的保障不在於「模型會不會被騙」，而在於即使被騙，它能造成的損害範圍有多大。這也是上述限制存在的理由。

什麼情況適合用這種方式建站

最直接受益的，是已經習慣使用 ChatGPT 或 Claude 處理日常工作、不想再多學一套後台介面的人。其次是需要頻繁調整內容、但每次只改一小部分的商家——這類需求在傳統後台裡，光是找到那個欄位就佔掉大半時間。不確定網站該放哪些區塊的使用者也適用，因為先拿到一個可修改的版本，比對著空白頁面想像容易得多。

反過來說，有幾類工作仍應留在後台。品牌識別檔案如標誌與圖示需自行提供，這不是模型能代勞的事。涉及金流的設定（例如收款帳號）不建議交由對話完成——其他欄位寫錯看得出來，帳號數字寫錯不會有人立刻發現。多語系的開啟屬於一次性設定，在對話中處理反而繁瑣。

另外，AI 產出的第一版仍是初稿。營業時間、電話、地址、價格這類資訊即使由 AI 寫入，仍應自行確認一次——這些欄位寫錯的代價，通常由到現場的客人承擔。

至於平台本身該怎麼選，涉及的考量不只有 AI 支援與否，另有一篇針對 WordPress、客製化與自助架站的比較可供對照。

參考來源

• Anthropic，Introducing the Model Context Protocol（2024 年 11 月）
• Anthropic，Donating the Model Context Protocol and establishing the Agentic AI Foundation（2025 年 12 月）

若想實際確認這種方式是否符合自身需求，可先用一個小範圍的題目測試：請 AI 建立一頁服務介紹，附上三項服務與各自的時長。花費約十分鐘，足以判斷產出的品質與操作節奏是否合用。