三個月前我從一個民宿網站開始，只是隱約覺得這些業者需要的不只是一個訂房頁面。現在我替九家分布台灣各地的民宿跑著自動化的數位運營——五個網站、每週一早上自動送出的數位週報、定期分析關鍵字成效的廣告健檢系統。
這篇是這段過程的回顧，以及我學到的東西。
問題的起點
台灣民宿在一個奇怪的市場裡競爭。Booking.com、Agoda 這些 OTA 平台帶來流量，但每筆訂單都要收取遠比外界想像高的佣金。大部分的小型業者知道這個問題存在，但又卡在一個更深的困境：OTA 之所以能帶流量，靠的不只是一個平台，而是三件事同時成立——龐大的廣告預算持續在各渠道曝光、多年累積的品牌信任感、以及專業的數位與行銷團隊全職經營。
就算業者自己請人做了一個形象網站，在沒有廣告、沒有 SEO 策略、沒有數據分析的情況下，這個網站只是一個存在著但沒有人找得到的頁面。光有網站並不夠。
真正的問題不是沒有網站，而是缺少整套數位運營能力：能在搜尋引擎被找到的網站、不需要懂工具也能看懂的數據報告、有依據的廣告投放——同時又不需要養一個他們負擔不起的行銷團隊。
這就是我最後建起來的那套東西。
五個網站、九家民宿
第一件要解決的事是部署架構。有些民宿是單一地點，有些是兩三個房源共用一個品牌。五個 repository 最後涵蓋了九個房源。
其中一個 — Firebase Hosting，靜態輸出。單一地點、不需要伺服器端邏輯的物件。速度快、維護成本零，Cloudflare 在前面做 CDN。
另外四個 — Railway 跑 SSR。需要即時房況顯示、動態定價或其他無法預先渲染的內容。Railway 處理 Node.js runtime；Cloudflare 在前面做快取和防護。
技術選型全部統一用 Astro 6 + Tailwind v4。Astro 的 island 架構讓我可以出大量靜態頁面，只在需要的地方加互動元件。Tailwind v4 是重大改版——不再需要 tailwind.config.js，所有設定移到 CSS 裡。花了一天適應，之後比 v3 還快。
我還做了一個用 GitHub REST API 驅動的後台管理介面。民宿業主需要自己更新房型說明、定價和照片，不能每次都打電話給我。Contentful 或 Sanity 這類 CMS 意味著要教他們用新工具。GitHub API 的做法是做一個自訂表單，直接寫回 repo——commit 記錄自動成為修改稽核紀錄，CI 負責觸發重新部署。
第二層：讓 GA4 真正被使用
這九家民宿都裝了 GA4。沒有一家業主真的在看。
這在中小企業和數據工具之間是很常見的模式。資料在那裡，儀表板在那裡。但打開 GA4、找到正確的報告、記住上週的數字、把這些轉化成一個決策——對於一個本業是經營民宿的人來說，這個摩擦力太大了。
解法是一套每週一早上自動執行的 TypeScript 分析系統。它從 GA4 Data API 拉資料，算好週比和月比的差值，連同各物件的業務背景一起送給 Claude 分析。
業務背景是關鍵。每個民宿有一個 business-context.md，記錄旺淡季、關鍵的轉換事件、業主真正在意的指標，以及當地的情境（附近的節慶、對那個地區特定的連假效應）。Claude 讀著這些背景和標準化後的數字，產出的報告會說：「這週自然搜尋流量下降 15%，與端午連假吻合——付費流量維持穩定，所以這不是廣告的問題。」
業主每週一收到中文報告。不需要登入任何工具，不需要解讀儀表板。問題從「發生了什麼？」變成「我應該做什麼？」——後者是容易得多的對話。
第三層：沒有行銷團隊也能管廣告
廣告的問題不一樣。業主在跑 Google Ads——有些每個月花三到五萬台幣——但沒有系統化的方式評估哪些關鍵字有效。決策靠感覺，或者根本不做決策。
廣告健檢系統是一個 Python 系統，每週從 Google Ads API 拉關鍵字成效資料，送給 Claude 分析，產出結構化的建議：哪些關鍵字應該新增、哪些應該刪除、哪些繼續觀察。輸出進一個 Google Sheets 庫存表——每個關鍵字有一列，記錄狀態（Active 或 Removed）、新增日期，以及每個決策的原因。
選擇 Sheets 是刻意的。我可以用資料庫。但資料庫意味著資料住在一個只有我能看到的地方。Sheets 意味著業主可以自己打開、往下滾、看到每個關鍵字決策的歷史。這套系統感覺是他們的，不是 Wayne 在控制的黑盒子。
我寫了一條規則：新增的關鍵字有 14 天保護期。如果一個關鍵字跑了不到兩週，沒有足夠的資料評估它——Claude 做出的建議只是在噪音上加噪音。保護期把這個情況過濾掉。
這件事實際上需要什麼
直觀的答案是「好工具和 AI」。但這低估了真正的挑戰。
工程上的問題——API 串接、自動化 pipeline、部署設定——總共花了幾天，可能一週。花更長時間的是針對每個物件的具體情況校準輸出。一份對恆春海景民宿有效的報告，不見得對南投山區的民宿管用。business-context.md 現在還在持續迭代，因為我還在學每個業主真正在意什麼。
另一件花時間的事：讓業主信任輸出到願意根據它做決策。一份準確但被歸檔不看的報告，只是昂貴的自動化。目標是他們真的會依賴的系統——這意味著根據什麼觸發了真實的決策對話，反覆調整格式、語言、細節程度。
為什麼現在一個人可以做到這些
三個月、五個 codebase、九個客戶、三套每週自動執行的系統。幾年前這件事大概率不會發生——不是因為沒有人想做，而是這些業者根本負擔不起讓它發生的成本。工程師、數據分析師、廣告優化、每週的報告產出——每一個環節以前都需要專門的人力，加在一起遠遠超出小型民宿的預算邊界。
AI 工具改變了一個人單獨能做到的事。Claude 處理分析層，那部分以前要嘛需要專職分析師，要嘛需要極度剛性的規則邏輯。GitHub Actions 處理排程，那部分以前需要常駐的基礎設施。Astro 的架構處理效能優化，那部分以前需要仔細的手工調整。
AI 沒有做到的：判斷這些業者真正需要什麼、設計系統架構、弄清楚業主為什麼不看 GA4、發現 Sheets 方案會讓廣告系統比資料庫更有信任感。這些是判斷，需要理解問題的人來做。
我不斷發現的模式是：AI 以我一個人跟不上的速度處理執行；關於執行什麼的決策，仍然需要理解問題的人。這個組合，是三個月做到這個規模的原因。
現在跑著什麼
五個網站。每次 commit 觸發自動部署。九家民宿收著自動化的數位週報。有跑 Google 廣告的物件有廣告健檢。業主有後台可以自己操作，不需要打電話給我。
這套系統繼續在跑。新物件加入的時候，我加一個 site config 和一個 business-context.md，自動化就自己接上去了。
這件事沒有做完——它永遠不會有做完的一天。但基礎在那裡，不需要我每天盯著它。這一直是目標。