把北極星指標從網站點擊換成真實訂單，是這套系統目前最重要的一次校正。但校正完一件事，底下的問題就更清楚了。
這篇不是在說系統現在哪裡好。是在說系統的設計裡，還有三個拉扯沒有解開——兩個是已知的技術債，一個是現階段沒有好答案的開放問題。把它們寫下來，是因為假裝它們不存在比承認它們更危險。
張力一：診斷的邊際成本趨近於零，但執行的沒有
這套系統解決的是「知道該做什麼」的問題。週報跑出來，業主收到的是具體的行動建議——哪個廣告要調、哪個頁面的聯絡流量在下滑、下個月哪幾個週間的空房需要提前應對。
但行動清單上有一欄是「需要技術人員」。而且這一欄不是例外，是常態。
原因是架構現實：客戶站點用的是 Astro 靜態生成，不是傳統 CMS。要改房型說明、調促銷文案、更新頁面內容，需要的不是「在後台輸入」，是 Git commit 和重新部署。這讓業主的可操作範圍，和 AI 給出的建議範圍，之間永遠存在一段缺口。
這個矛盾沒有辦法靠「AI 更聰明的建議」解決。它是執行側的結構性問題。
值得說清楚的是：高頻率改動的部分已經解了。業主可以從 CMS 直接發促銷橫幅文案、本月主打說明、特殊節日訊息，不需要找任何人。這一層的邊際成本確實已經趨近於零。
還沒解的，是更結構性的那些：新頁面、新功能類型、版型異動。這些目前還是要走程式碼路徑。張力存在，但範圍比一開始看起來窄——那個「需要技術人員」的欄，現在指的是真正的工程工作，不是把文案打進後台這類的事。
系統現在做到的是「無人值守分析」加上「業主可自助的內容更新」。真正結構性的工程工作還在外面。
張力二：真實訂單進了 GA4，但歸因是模型化的
把訂房資料接進來之後，Smart Bidding 現在拿到的是真實訂房訊號，而不是點擊事件。這是進步。但要誠實說清楚這件事背後的架構。
流程是這樣：業主在 PWA 確認一筆訂房，server 打一支 GA4 Measurement Protocol 事件，帶上這筆訂房的轉換金額。GA4 收到，Google Ads 自動同步，Smart Bidding 把這筆訊號用進出價優化裡。
缺口在哪：那支事件用的是匿名 client_id，不是業主當初從廣告點進來那一刻記錄的 gclid。Google Ads Conversion API 要求 gclid 才能做點擊路徑匹配。沒有 gclid，歸因走的是模型化路徑——Google 的算法估算「這筆訂房最可能來自哪個廣告或關鍵字」，而不是確定地知道。
對 Smart Bidding 的實際影響：夠用。Smart Bidding 本來就設計在模型化歸因下工作，它需要的是「真實訂房訊號 + 對應的金額」，不是完美的點擊路徑。週報的宏觀關聯分析（這週花了多少廣告費、收到了幾筆訂單）也是真實的，只是不能精準說「這個關鍵字帶來了這幾筆訂單」。
初期方向：在客人初次從廣告點進網站時，把 GA4 的 client_id 存進 session storage；業主後來在 PWA 確認那筆訂房時，把這個 ID 帶進 Measurement Protocol 事件。這不解決 gclid 缺口，但讓 GA4 能把這筆訂房和之前的瀏覽 session 關聯起來，歸因品質會有明顯改善——不需要換架構，只需要在前後端之間傳一個值。
張力三：驗證器擋住了數字幻覺，下一個敵人是邏輯幻覺
週報裡的每一個數字，現在都能追回系統真正抓到的某個值。驗證器會掃過產出的文字，把沒有來源的數字擋下來，讓模型重跑，不通過就不出給業主。這個機制有效。
但它擋不住另一種錯：數字是真的，推論是歪的。
假設本週訂單數量為零，上週也是零。驗證器會確認這兩個零都是真的。但它沒辦法擋住一份邏輯通順、語氣專業、卻建議「加碼投資本月表現最好的關鍵字」的報告——因為這個建議在文字層面沒有說謊，只是商業邏輯上毫無意義。
語言模型的危險不只在捏造數字，也在用正確的數字做出符合文法、符合分析慣例、卻缺乏實際商業判斷的結論。這種「邏輯幻覺」比數字幻覺更難被看出來，因為它的表面是完整的。
初期方向：加第二輪語意審查——不是比對浮點數，而是讓另一個 LLM 扮演懷疑論者，把報告的行動建議逐條對照業務常識規則核查。「若連續兩週訂單為零，建議不得為『維持現狀』」、「若廣告支出上升但聯絡事件下滑，分析必須包含對廣告方向的明確質疑」。這些規則不能用程式碼 hard filter 來做，因為邏輯幻覺的出現方式太多樣，要用另一個 LLM 的語意理解來擋。
兩個 LLM，一個寫報告，一個審報告。這是現在看到的方向。
這三個張力在設計上都是已知的——不是意外，是在現有條件下的折衷。把它們寫清楚的理由，和當初把點擊換成訂單的理由一樣：看清楚邊界在哪裡，才知道下一步要往哪走。