這一季的主軸，是從「做民宿網站」轉成「經營一家民宿的整個數位營運」。三個月前的工作大多還停在「把網站做漂亮、把轉換做出來」；到六月底，它已經是一套自動化的系統：會排名也會轉換的網站、業主看得懂也做得動的每週報告，還有這季新長出來的——一條會自己稽核、自己調整 Google Ads 的流程。
這裡的客戶全都是恆春的民宿業者。季末盤點，一共是九家民宿、五個程式庫，其中三位業者的五間館掛在廣告引擎底下。
兩個新站，跟一個「內容誰來改」的真問題
季初我把一個雙館品牌的站收尾上線，接著從零做了兩個新站。一個是單館民宿，最後一個是涵蓋兩間民宿的傘型品牌。三個站都走同一套 Astro 雙語架構——中文放在根路徑、英文平行、responsive 的 AVIF/WebP 圖片流程、用 Lighthouse 逼效能。
有意思的問題不在頁面本身，而是：上線之後，這些內容誰來改。單館那個站，我做了一套自架的 Decap CMS，用 GitHub OAuth 登入，讓業主不用工程師、也不用 git commit，就能自己上推廣 banner、換季文案、房型內容、調價格。業主能自助跟需要工程師的界線，落在「結構」上：新的頁面模板、新的功能型態、版面結構的改動還是得找我；但內容這種高頻的東西，改動的邊際成本已經接近零。
CMS 花的時間遠比網站本身多。大半時間都在跟 Decap 內建的介面搏鬥——一條 Chrome 一直重新上色的青綠色頂條、清單元件不肯顯示項目名稱、圖片預覽會秀出已刪掉的檔案。把一套第三方後台掰成一個非技術業主真的敢用的東西，是很不起眼的工，我這次預估得太樂觀。
兩館品牌那邊，我後來走了另一條路：自己寫一套 Astro SSR 的後台 app，用 Google OAuth、白名單信箱，做 banner 跟卡片的 CRUD，資料存進 GitHub。目標一樣——內容歸業主——但用兩種方式達成，因為兩邊的限制不同。這才是「可重用」誠實的版本：重用的是模式，不是實作。
分析 agent 長出了骨架
這季最大的一條線，是分析 agent。它一開始是三段式流程（抓取 → 分析 → 產出），從 GA4、每館的業務脈絡文件、後來再加上 Google Search Console 跟 Google Ads 資料，做出一份每週營運報告。然後它又長出了四層我當初沒完全料到需要的東西：
- 一個反捏造的驗證層，任何 LLM 引不回原始資料的數字都會被打回。這一關我修了整季——每週驗證器都會對某個合法字串誤判（一個字面含數字的搜尋字、一個中文年份、一個寫成「55/100」的 PSI 分數），我就再去收緊 strip 規則。到六月改成 fail-open：驗證重試用盡，報告只寄給我人工審核，絕不進客戶信箱。零捏造風險，代價是偶爾要手動看一遍。
- 一個
site-snapshot工具，直接解析每個站自己的元件，盤點 CTA 跟價格，讓報告是根據當前上線的網站在推理，不是根據一份過時的描述。 - 一個
operator-events.yaml事件日誌。這個很關鍵。agent 的業務脈絡文件是靜態的——它只知道上次被告知的內容，跟不上業主實際改動的頻率。這個落差會造成歸因錯誤：AI 會把某個指標波動歸到錯的原因上。解法是一份機器可讀、持續追加的事件日誌。當我把週報裡的某個建議，帶進客戶 repo 裡跟 Claude Code 的一場深入對話、共同設計出一個介入方案，那個決定就寫進日誌。下一次分析跑起來會讀到它——所以評估成效的那個 AI，已經知道發生過什麼、為什麼。
這條閉環——報告揭出問題、人加 AI 的對話把它深化成方案、方案用結構化格式記錄下來、下一次跑再把這筆記錄吃進去——才是真正的產品。我是主導；兩個 AI 系統扮不同角色（一個分析、一個策略夥伴）；它們之間的交接是結構化的，不是用嘴講的。
把點擊代理指標換掉
有好幾個月，轉換指標用的是代理值：網站上的聯絡按鍵點擊——電話、微信、立即訂房這些被 GA4 抓到的點擊——拿來代表真實訂房。這不是一個要「修正」的錯誤。在當時的限制下，它是唯一可行的選項：業主用紙本記訂房，沒有一條低摩擦的路能把真實訂房資料弄進數位系統。
所以我把那條低摩擦的路做出來。一張為非技術業主設計的 A5 紙本表單，讓他用自己的說法記下每一筆電話訂房，年齡當估計、還有「不確定」的選項。再接一個 booking-tracker 整合，把這些真實訂房餵進流程，拆成「已收到訂房」（主要訊號）跟「入住中」兩個視角，還有每館的月住房率分析。六月底，抓取層從點擊代理切成真實訂房資料。代理值完成了它的任務；那個工具補上了代理值原本在填的缺口。
這守不守得住，不是業主紀律的問題，是摩擦感的問題。我的工作是把門檻一直往下壓，壓到「記下每一筆訂房」變成最省力的選擇。這一注目前還沒開牌。
廣告，自己變成了一個產品
季初我沒預見的一塊：Google Ads 這部分長成了一整個子系統。一個手動的廣告健檢 Action，長出了幾十條校準規則——抓出導去站外的 sitelink、被否決的廣告、把地區鎖定的 presence 跟 interest 分清楚、用非 PPC 專家也讀得懂的白話把品質分數講清楚。接著是一條關鍵字優化流程，會建議新增字跟否定字、走 GitHub 的審核介面、核准後執行。再來是五層的關鍵字清理，偵測弱信號、冗餘、零轉換的字。有一條硬限制貫穿每一層：業主同時經營兩間、掛在兩個獨立廣告帳號時，兩個帳號完全分開——不能交叉污染，而這後來在快照資料跨站洩漏時，成了反覆冒出來的 bug 來源。
六月底我上線了第四個站（只做廣告、不碰網站）跟第三個品牌，接好轉換動作設定、用 LLM 生成素材的 PMax 廣告活動骨架，還有一份跨所有客戶的組合層報告。一個 Google Trends 快照工作，現在把共用的恆春市場搜尋趨勢資料，餵進每個站的週報。
這裡有一個對業務面很重要的框架：這些東西沒有 AI 根本不會發生——不是因為取代了一個團隊，而是因為對這一類客戶來說，這些工作以前就是負擔不起。工程、資料分析、廣告優化、定期報告，每一項以前都要專職人力，加起來遠超一家小民宿的預算。AI 讓一個以前不可能的服務，第一次在算盤上划得來。OTA 的份量來自它們的廣告預算、多年累積的信任、還有全職的行銷團隊——對上這些，一個沒有數據分析、沒有廣告策略的孤站，是隱形的。OTA 收的佣金遠比外界想像的高，而且躲不掉。要補上這個落差，需要整套系統，而這一季就是在補這件事。
下一季往哪走
有三條線還開著。真實訂房的資料閉環，需要在日常使用裡證明它守得住——這個指標要有意義，記錄的習慣就得活下去。廣告子系統需要週報已經走過的那種硬化：更少誤報、抓到更多真問題。還有，客戶組合現在夠大了，跨站的管理報告正在變成主要的觀看角度——不再是「這一個站表現如何」，而是「所有客戶裡，下一個最有價值的一小時該花在哪」。那套基礎設施是六月最後一週上線的；下一季，才是它證明自己價值的時候。