有個負責稽核 Google Ads 帳戶的 LLM，表面上運作得很正常：每週都生出條理清楚、論證完整的建議。問題出在——有好幾條建議，其實早就做完了。
有一週它建議把某支搜尋活動的多媒體聯播網外溢關掉，但那個設定八天前就關了。另一週它建議在一個多元成效活動的素材資源群組裡補上受眾訊號，那個群組已經掛了七組受眾。每一條建議單看都站得住腳。它們的共同點是：拿過去 30 天的花費當證據，去評斷一個已經不存在的設定狀態。
這件事為什麼重要，要從報告的用途說起。這份每週 Google Ads 健檢，是為三組民宿業者、共五館經營的一套數位運營系統裡的一塊。這些都是恆春的小型業者，他們不可能各自請一個廣告分析師、一個資料工程師，再養一套每週出報告的流程——這些角色過去各自都要專職人力，加起來遠遠超出小生意的預算。整套系統能成立，是因為 AI 做了分析師的「讀資料」，人做「判斷」。但一份每週都叫業者去把自己做過的事再做一次的報告，會侵蝕系統唯一在賣的東西：你可以信它，不用每次自己再檢查一遍。
從過時的輸入推出的正確結論，還是錯的
模型沒有亂講。它就是照提示詞做的：讀 30 天績效、找漏洞、給修法。陷阱在於績效資料是落後紀錄。如果一支活動在視窗的前三週把預算燒在多媒體聯播網上，業者第四週把它關掉，那 30 天的數字還是會顯示那筆浪費。一個只看得到花費的推理者，會非常正確地診斷出一個早就被解決的問題。
直覺的修法是在提示詞裡加一句：「先確認設定是不是已經關了。」這沒用，因為模型根本沒有那個欄位可以看。抓資料那一層只拉了花費、轉換、點閱率這些「結果指標」，沒拉產生這些結果的「當前設定值」。你沒辦法叫模型去核對它從來沒拿到的資料。
修正點在抓資料那一層，不在提示詞
所以這次改的，是把當前設定值跟結果一起抓進來。多媒體聯播網那個案例，就是去抓 campaign.network_settings.target_content_network——這支活動現在到底還有沒有在跑 Display 的即時布林值。受眾訊號那個案例，就是去數每個多元成效素材群組實際掛了幾組受眾，這樣模型在建議「補第四組」之前，就知道已經有七組了。
接著把提示詞改寫，讓這些值變成關卡，不是參考。多媒體聯播網那條規則現在開頭就是一道硬性前置檢查：如果 targetContentNetwork 是 false，整條 finding 直接跳過——不要建議去關一個已經關掉的東西；那筆歷史花費是設定改之前燒掉的。只有當它還是 true，模型才往下走它以前一上來就跳進去的花費分析。受眾訊號那條規則也分層：四組以上代表「已經夠了，不要建議補」；一到三組才建議；零組是最高優先。
順序就是重點。模型先讀當前設定，再讀歷史結果。一個熟練的提示詞工程師會直覺想到「叫模型小心一點」。真正的槓桿是結構性的：模型只能對它看得到的狀態小心，而它只有在「檢查」是第一道指令時，才會先檢查。
同一個陷阱，又出現三次
一旦你看懂這個失誤模式，它在每一個「推理者碰上落後資料」的地方都會冒出來。一個看起來像帳務異常的單日花費尖峰，如果發生在活動上線當天，其實只是「活動開跑」的結構必然。從五天樣本外插出來的月度平均花費,如果樣本裡含一次還沒穩定下來的預算調整，讀起來就像個穩定預測值。每一個都用同樣的處方:在模型被允許把某件事叫做「異常」之前，強制先查 recentChanges——帳戶自己的變更歷史。如果尖峰那天剛好有一筆 CAMPAIGN CREATE，那就不是異常，那是上線第一天。如果月度推算是建在不到兩週、或橫跨預算重設的樣本上，模型就必須把它標成僅供參考，而不是當成預期值呈現。
這些都不是什麼提示詞的小聰明。它們是同一個洞見反覆套用：一個從歷史外插的推理者，除非你把那段歷史裡發生過的事件交給它、並逼它先讀，否則它一定會把因果搞錯。
用機器可讀的變更紀錄把迴圈接起來
這就是系統從單向報告變成回饋迴圈的地方。Ads API 本身會暴露它的變更歷史，所以 Wayne 在後台改的設定，會自動出現在 recentChanges 裡。但不是每個動作都活在 Ads API 裡。當業者為了暑假促銷發了一則 LINE 廣播，或分析流程抓到某個離峰平日空檔、Wayne 把回應收斂成一套更精準的方案——這些東西,讀活動指標的模型都看不到。
分析 AI 讀的那份商業背景文件是靜態的。它只知道上一次有人更新它時被告知的內容，而那份更新的頻率，根本追不上實際運營決策發生的頻率。這個缺口是結構性的——而 operator-events.yaml 存在的目的，就是補這個缺口。這是一份持續往後追加、機器可讀的事件日誌，記下每一個平台外的動作：一則促銷廣播、一次調價、一次手動聯繫。下一次分析跑起來會讀它,所以當某一週詢問量上升,模型已經知道有一則廣播發出去了,不會把成長全算到廣告花費頭上。迴圈就這樣接起來:AI 點出問題,Wayne 和第二個 AI 把回應想深,決策寫進日誌,下一次分析就帶著這個脈絡開始推理。
另一條路——讓模型從吵雜的結果資料裡自己去推測發生了什麼介入——正是整件事一開始要避開的陷阱。你不會靠「請推理者猜猜看改了什麼」來修一個輸入過時的問題。你把改了什麼、用它讀得懂的形式記下來,在它開始推理之前。
這個迴圈能不能撐住，取決於紀律：每一個平台外的動作都得真的被記下來。現在這還是手動追加,它能運作,是因為做這件事的人懂得為什麼下一份報告要靠它。誠實的答案是,系統的準確度只跟那個習慣一樣好——這跟任何還沒自動化的運營紀錄,面對的是同一個限制。