OTA 的強勢不是單一因素造成的。廣告預算的規模、長年累積的品牌信任、全職的數位行銷團隊——三個條件疊加，讓小型業主根本無從正面競爭。更重要的是，她的網站不需要在搜尋結果頁擊敗 OTA。需要的是：當客人透過搜尋找到她之後，能不費力地完成直接訂房。那道缺口不是內容品質的問題。是營運持續性的問題——有人要跑廣告、設轉換追蹤、定期稽核關鍵字。沒有人做這件事，不是因為技術難，是因為把這件事做對的持續成本，一直都超過這個規模的業主能吸收的數字。
這就是 AI 工具在這裡真正解決的問題：把策略編碼成技能，之後每個需要它的客戶都從這個基礎出發。
四個禮拜，三份技能：astro-promo-admin、ga4-ads-tracking、keyword-optimize。三份都是 Claude skill 檔案——執行提示、決策紀錄、程式碼模板。合在一起蓋住完整的營運迴圈。第一個客戶的案子付了建立這些技能的成本，之後的每個案子都從已解決的問題出發。
第一版寫死的前提
astro-promo-admin 在 Astro 5 站上建一套完整的促銷後台。業主用 Google 帳號登入，登入資格只存在部署環境的 env 白名單裡，沒有自助申請頁面、沒有資料庫管理介面。業主編輯促銷內容之後，修改透過 GitHub App 提交回 repo，網站自動重建。換季改橫幅，不需要打電話給工程師。
主流程是一天的工。能乾淨裝進任何客戶專案的版本，花的時間更長。
兩個問題都是在試圖重用程式碼時才出現的，第一次建的時候完全看不到。
第一個：Astro i18n 手動 routing 模式需要 middleware 檔，否則 build 直接失敗。但 middleware 模式和 standalone 模式在自訂 server 部署下的行為不同。自訂 server 通常負責靜態資源的壓縮快取；standalone 模式把整個 server 替換掉，靜態頁的 Lighthouse 分數因此悄悄退步。技能現在偵測部署設定，自動選對應的 Astro adapter 模式：middleware 模式保留既有靜態路徑，只把管理後台的請求送進 SSR；standalone 適合想讓 Astro 接管整個 server 的情境。選哪個看起來只是一個 config 欄位的差距，結果是靜態頁效能究竟守不守得住。
第二個：Railway 這類平台在前端加 TLS proxy，轉給 Node 的是 HTTP。Astro 內建的 origin check 比對 scheme 加 host——proxy 讓 scheme 變成 http，每個 mutating POST 都被 403 擋住。技能關掉內建 check，改用只比對 host 的同源驗證。部署在任何 proxy 後面都能正常運作。
然後是第一次在新站示範的時候。業主第一次按下發布，腳本靜靜失敗，什麼都沒提交。新站沒有資料檔可以寫入。第一次執行時先建立空白資料，是一行修補。這一行只在新客戶正盯著你、等你示範產品的那一刻才觸發。那也是最不能讓事情無聲爆掉的時候。現在這一行在技能裡，標記為必須有、不得省略。
只在第一個客戶環境正常運作的技能不是技能，是一份有隱藏前提條件的腳本。
限制寫進執行提示，不寫進文件
ga4-ads-tracking 安裝 GA4，視需要加上 Google Ads 轉換追蹤。兩條規則寫成了執行上的硬性限制，不是清單項目。
技能拒絕重用任何現有的 GA4 Measurement ID。如果業主還沒有獨立的 GA4 property，技能在這裡停下，帶她建好再繼續。多個客戶的流量進同一個 property，資料合流後分不開。這個決定通常是出於好意做的，結果是週報數字從第一天就沒有意義。那些資料不會回來。
技能也稽核網站上每一個可點擊的聯絡方式——電話、LINE、訂房連結——然後替每一個寫事件追蹤。同時把「所有 CTA 都要有追蹤事件，沒有追蹤事件的 CTA 視同 bug」這條規則寫進專案的工程規範。沒有這個粒度，你沒辦法告訴業主哪個管道帶來詢問。那是她唯一真正根據它行動的數字。GA4 裡有多少頁面瀏覽，對她決定任何事都沒有幫助。
GA4 事件和 Google Ads 轉換各自用獨立的 send_to 目標，兩條線不互相污染。Ads 那條線若哪天業主停投，拔掉不影響 GA4 設定。
清單在壓力下容易被跳過。execution prompt 裡的硬性限制不會。
先驗證輸入，再讓 LLM 推理
keyword-optimize 是一條完整的 TypeScript pipeline，不只是提示詞。
流程是這樣的：呼叫 Google Ads API 拉過去 N 天的搜尋字詞資料（最少 60 天，建議 60–90），爬取業主網站的首頁和 nav 連結頁（最多五頁）抽取設備、容量、地點的特徵，然後把兩組輸入一起送給 LLM，要求輸出結構化 YAML。這份 YAML 是人工審核用的，不直接送進 Ads。確認沒問題後，另一支腳本先做 dry-run 預覽，再加 --execute 真的打 API 送出修改。
在這一切開始之前，Phase 0：確認帳號 API 存取正常、確認資料時間窗口有足夠歷史、確認搜尋字詞報表有內容。三個裡任何一個不對，LLM 的輸入就是殘缺的。推出來的建議看起來合理，但沒有真實流量支撐。
六條鐵則管著輸出。有曝光但在足夠時間窗口內零轉換的關鍵字，要暫停，不是繼續優化。競品名稱出現在搜尋字詞且有轉換信號，保留——那是正在評估我們的客人，不是誤點的。曝光次數低於門檻的關鍵字，不論 LLM 多確定，先擱置。新接的帳號架構混亂，可以開 cleanup 模式——拉完整帳號歷史，判斷力道更大。每條鐵則都帶著理由。
加理由，是因為觀察到 LLM 在規則只有指令沒有 why 的情況下，很擅長找理由繞過去。是 why 讓規則守住。
輸出是一份有支撐數據的 YAML：哪些搜尋字詞觸發了廣告、哪些在浪費預算、建議做哪些修改。業主不需要登入 Ads 後台就能看懂並行動。
第二個客戶繼承的東西
Middleware 模式偵測、空白資料的初始化、獨立 property 的硬性限制、六條帶著 why 的 LLM 鐵則——都是在第一個案子裡付成本學到的。技能把它們帶進下一場。下一個客戶從已解決的問題出發，帳單不需要再為重新學這些邊角案例付費。
這就是 AI 工具在這裡真正改變的東西。這個規模的業主之前買不起正確執行的數位行銷——不是因為技術太難，是因為讓每個聯絡方式都有追蹤、讓關鍵字定期根據真實搜尋行為調整、讓業主能自己管行銷內容、讓廣告帳號有人持續看著——這些加在一起的持續成本，超過她的預算。
AI 沒有讓某個環節單獨變便宜。讓這件事成立的，是把策略編碼進技能之後，每增加一個客戶的邊際成本幾乎歸零。那是讓這套作業在這個規模的客戶身上，第一次變得可行的原因。