一份 Google Ads 帳號的健檢報告，是診斷，不是治療。這幾家民宿帳號的每週分析流程，前半段一直做得不錯——抓出在燒預算的廣泛比對關鍵字、標出該加進否定詞的搜尋字詞、發現某個活動在對著錯的訊號優化。然後就沒有然後了，因為這整條流程從來不碰帳號。結論躺在報告裡，得有人——也就是我——打開 Google Ads 後台，把每一條結論翻成一串點擊。
系統漏掉的就是這個翻譯步驟。不是因為這工作有多難，而是因為這是整個系統裡唯一沒有紀錄、沒有審閱、沒辦法重播的環節。報告知道該做什麼，但帳號不會自己變，除非我親手去改，沒有 diff 可以事後對照。
這篇講的是補上這個斷層——夾在健檢（在〈Teaching the Ads Auditor Not to Recommend What’s Already Done〉那篇講過）和真實帳號之間的執行層。健檢決定「要改什麼」；這一層決定「實際上怎麼套用」，而且不會有人手滑把一筆預算改到錯的客戶 ID 上。
為什麼不直接讓 agent 去呼叫 API？
最直覺的做法是：agent 讀報告、agent 呼叫 Google Ads API、結束。我刻意沒這樣做，理由不是含糊的「小心一點比較好」。
直接呼叫 API 改東西，不會留下任何產物。如果 agent 用一次即時呼叫停掉了十一個關鍵字，唯一的證據是帳號的變更紀錄——埋在後台某個地方，掛在一個 OAuth token 名下，不掛在任何人審過的決策上。動手之前沒有 diff 可以看，一週後覺得哪裡怪怪的時候也沒有檔案可以指。
所以這個 skill 裡那條不能妥協的規則是：永遠不准即時改動。 agent 想做的每一筆改動，都得先寫進一個 git 追蹤的 YAML 檔，放在 sites/<slug>/ads-changes/ 底下，標好日期、限定單一站台。這份 YAML 就是計畫。另一支獨立的 mutation runner 讀這份計畫、執行它。agent 的工作到產出檔案就結束；我要審的就是這個檔案。
這一個設計同時換到三件事。改動在碰到任何東西之前可以先審。事後可以重播、可以稽核。而那個會造成破壞的步驟——真正寫進 API 的那一筆——集中在同一支 runner、同一組防呆裡，而不是散在 agent 當天決定要呼叫的任何地方。
dry-run 在任何人動手寫之前，先讀出真相
整套流程裡我最慶幸自己硬加上去的，是 dry-run。理由是一個很具體的出錯模式：以為自己知道帳號現在的狀態。
報告可能寫「這個關鍵字太廣，收窄一點」。菜的做法是照關鍵字字面去動它。但關鍵字的比對類型不在字面上——一個詞組比對跟一個廣泛比對的關鍵字，在報告裡可能長得一模一樣。預設「全部都是廣泛比對」去動手，就是這樣停錯東西、或是加了一個其實重複的改動。
dry-run 會在寫進任何東西之前，先去帳號查清楚計畫要碰的每一個關鍵字現在的狀態。它不是把計畫印回來給你看的形式手續——它是整份計畫唯一一次跟真實線上狀態對帳的機會。prompt 裡這條寫得很直接：絕不預設比對類型，先查。查這件事就發生在 dry-run。
撐起整套東西的那條防呆：正在轉換的，不准停
下面這條規則，比任何一條都更能說明為什麼這一層得寫成程式，而不是靠我腦袋裡記得：
把任何關鍵字加進停用清單之前，先看它在報告裡有沒有轉換。有的話，不准停——改成加否定詞。
這種錯，在它害到你之前是看不見的。一個關鍵字可以看起來像問題——花費高、搜尋字詞一團亂——同時又正好是真的帶來訂房的那個關鍵字。偷懶的修法是把它停掉。一停，浪費停了，訂房也一起停了。正確的修法是：當一個關鍵字會轉換、但同時也撈到一堆垃圾流量時，讓它繼續跑，用否定詞把垃圾的部分削掉，這樣會轉換的流量活著，浪費在無關搜尋上的錢死掉。
一個人在週末尾聲、手很快、又同時在處理好幾個帳號的時候，就是會犯這個錯。不是因為他不懂這條規則——而是因為這條規則是一堆二十條機械操作裡，唯一需要判斷的那一條，而判斷力正好是你點到第五個帳號後台時最先磨光的東西。把它寫成執行流程裡的硬性前置條件，這個錯就沒辦法默默通過。轉換檢查不是建議；它是關鍵字得先過的一道閘，過了才准靠近停用清單。
工具在哪裡停手，為什麼是刻意的
廣告帳號裡不是每件事都適合用 API 去改，這個 skill 在「它執行的」跟「它拒絕碰的」之間畫了一條明確的線。
能用 API 執行的那一組很窄、而且可逆：新增和刪除否定詞、停用特定關鍵字、用固定比對類型新增關鍵字。這些改動的波及範圍小，要回滾也一目了然。
所有真正有份量的，都留在手動——但有人帶。地理範圍排除和地區鎖定、停用或啟用整個活動（包含 Performance Max）、預算變動、出價策略變更、廣告文案改寫。這個 skill 不去用 API 做這些。它改成產出一步一步的指示，附上確切的後台路徑，讓手動的部分做起來快又不會搞錯，但真正按下扳機去動任何可能搬動真錢、或把活動關掉的東西的，是人。
這條界線不是「API 技術上准不准」。API 准我做的事多得很，是我選擇不自動化。界線在於：一邊是「可逆、波及範圍小」，另一邊是「在它發生之前值得有人盯著看」。
這東西到底為什麼存在
這背後更大的系統，是一套給小型民宿業者用的數位營運堆疊——這種規模的客戶，過去根本付不起。每一層——數據分析、每週報告、廣告健檢——以前都各自要養一個人。疊起來，遠遠超出一家小民宿的預算。是 AI 讓把這些湊在一起這件事，第一次在算盤上划得來。
而這個執行 skill，是讓前面那些東西真的有意義的那一層。一份沒人去執行的健檢，就是一份被讀完然後忘掉的報告。重點從來不是產出更漂亮的診斷——是讓診斷可靠地、可審地流進帳號，不用再仰賴那唯一一個全看我會不會在第五個帳號上累到犯錯的每週步驟。
報告知道哪裡有問題。現在帳號會改了——透過一個我能先讀過的檔案，和一條不會把正在付帳單的關鍵字停掉的防呆。