r/PPC 上有一條帖，向那些真的把 AI 工具接上客戶帳戶寫權限的人問了四個問題：它做錯了什麼、你怎麼做治理、它真的省下工時了嗎、六十天後你關掉了哪些功能。回答匯到了一個比工具推薦有用得多的東西——一份控制項清單。
這就是那份清單，寫成你可以拿去要求任何一家廠商的樣子，包括我們。
七項控制
1. 給建議之前先重新讀一遍
拿十分鐘前加載的資料做計劃的 Agent，會自信地對一個已經不存在的狀態動手。大家最常報告的失敗不是「決策差」，而是自信地用了錯輸入：API 文件里有那個字段，但在它剛好查的那個介面上返回 undefined，然後被靜默當成零。要求：支撐這次改動的讀取，必須發生在同一輪里。
2. 寫入前給 diff，不是給描述
Agent 的敘述不是證據。「我會把表現差的那幾個降出價」是一句話；3 個定向的出價 1.40 → 0.95 是一個 diff。只有後者能被審閱。
3. 爆炸半徑上限
最貴的失敗很少是「一次改錯」，而是「一次改錯被施加在四百個對象上」。要求單次呼叫有硬上限，並且在呼叫前校驗——不是靠叮囑模型「小心一點」。
4. 人工確認只用在實質性變更上
什麼都要確認，結果就是把你訓練成什麼都直接點過去；兩個月後你得到一個不再起審批作用的彈窗。這道閘必須能區分「可逆的編輯」和「動錢」。
5. 分級歸宿主，不歸工具
如果一個動作的風險等級來自工具自己的描述，那麼任何能寫描述的人都能給自己降級。一個自稱「只是改個小設定」的工具，不應該能靠措辭繞開審批。未知或自定義動作應該預設落到「敏感」，而不是「安全」。
6. 一份能交給客戶的審計記錄
問題不是「某處有沒有日誌」，而是「人家要的時候，你能不能拿出一份不可篡改的『誰在什麼時間改了什麼』」。產品遙測不算。
7. 回滾路徑，在需要之前就建好
每個有後果的動作都應該帶一把鍵，能找到並回滾它所屬的那一批。出事之後才開始想怎麼撤，就是一個糟糕的小時變成一個糟糕的星期的方式。
這些閘都攔不住的那種失敗
上面每一項管的都是執行。diff 告訴你改了什麼，日誌告訴你誰和何時，回滾把它撤掉。但它們都不能把「對的建議」和「錯的建議」分開——兩者進來時長得一模一樣，而錯的那個往往論證得更漂亮。
有一個被廣泛轉發的例子：一位賣家原本 ROAS 健康地做到 3.5–4x，聽信模型去重構廣告結構，結果虧了錢。最高贊的回復說清了原因：模型不知道你的庫存位置、合約約束和帳戶歷史。另一條評論說得更直：它們不知道怎麼在兩個都對的選項之間做選擇。找規律是這些模型真正強的地方，在兩個都站得住腳的策略之間做決定不是。
第二種攔不住的是反復橫跳：用三天資料抬價，兩天後又砍下去，定向永遠得不到一個穩定讀數。規模化跑這套的人會強制每個定向 5–7 天冷卻期，並表示這比換任何模型都管用。
Orkas 目前覆蓋到哪裡
Orkas 是一個本地優先的多 Agent 桌面應用。它的電商連接器——Shopify、Amazon Seller Central、eBay、Etsy、TikTok Shop、Shopee、WooCommerce、Walmart 等——都走宿主持有的策略層。下面八項已實現，四項沒有。我們寧可你在這裡知道，而不是在一次錯誤寫入之後。
| 控制項 | 狀態 | 實際存在的東西 |
|---|---|---|
| 四檔動作風險分級 | ✅ | 每個連接器動作都是 R / W / H / D——讀、寫、高影響、破壞性 |
| 寫入前預覽 | ✅ | 寫操作帶預覽確認，不會直接發出 |
| 涉錢變更要重新確認 | ✅ | 高影響動作被標為外部或財務變更，必須重新確認 |
| 爆炸半徑上限 | ✅ | 單次呼叫能碰多少個對象有硬上限，執行前校驗 |
| 純只讀連接 | ✅ | 連接器可以被限制在列能力、描述動作和讀取 |
| 分級由宿主判定 | ✅ | 風險來自宿主的固定表，按動作的精確身份匹配；工具自述不能括大信任 |
| 未知動作預設從嚴 | ✅ | 未分類動作按高影響處理；沒有可信策略的電商動作直接拒絕，不執行 |
| 產品邊界硬屏蔽清單 | ✅ | 一份固定清單，無論授予什麼權限都不暴露 |
| 按動詞分權（建立 / 編輯 / 暫停 分開） | ❌ | 權限按風險等級分檔，不是按動詞拆開 |
| 金額級 spend cap 或預算變動上限 | ❌ | 上限是對象數量，不是金額 |
| 回滾路徑 | ❌ | 未實現。回滾一批需要手工 |
| 可導出的不可變審計日誌 | ❌ | 連接器呼叫有遙測埋點，但那不是能交給客戶的審計記錄 |
如果最後四項是你的硬要求——最常見的情形是你在替客戶管廣告帳戶，而客戶隨時可以要審計——那 Orkas 今天不滿足，你應該在每一筆寫入上都留人。
另一條路：乾脆不要寫權限
很大一部分工作的重點不是寫，是分析。把報表導出來，放進本地工作區，讓 Agent 讀。不需要開發者應用，不需要排審核隊，迴路里不出現帶寫權限的憑證。而且這恰好是在交出任何不可逆的東西之前，最快弄清楚「它對我有沒有用」的辦法。兩個現成例子：把供應商追蹤號和訂單對賬，以及周度店鋪復盤的場景頁。
為什麼這件事難買多於難做
平台 API 通常是免費的，門檻是審批而不是價格。亞馬遜自己的 Ads MCP server 要求你有生效中的 Ads API 憑證；Shopify 要求一個與店鋪同組織的商家自建應用；TikTok Shop 要求一個通過賣家開發者審核的 Custom App；eBay 要求 Developers Program 的正式環境 keyset 和你自己的簽名密鑰。對一個單乾的賣家來說，這每一項都是一個項目，不是一個表單——這就是為什麼那麼多人走導出路線，從來沒接過任何東西。那是個合理的選擇，任何值得用的工具也應該在那個模式下好用。