💡 核心結論速覽 (TL;DR)
- AdSense RPM 突然暴跌不一定是文章改壞：如果你最近大量用 AI Agent 或 Playwright 打開正式前台，要把「無效流量疑慮」放進第一批排查。
- Playwright 是真瀏覽器自動化：Codex 和 Google Antigravity 2.0 這輪都是用 Playwright 審文章；開正式網址時，可能載入腳本、iframe、圖片與廣告資源。
- 我踩到的雷：我太相信 AI 審計效率，看到流量上升還以為優化成功，後來才發現自動化讀前台文章可能讓 RPM 雪崩。
- 比較安全的做法：下載或匯出 HTML 後，用本機 file:// 給 Playwright 查 DOM；正式前台畫面只做少量人工確認，不讓自動化瀏覽器反覆載入真實 AdSense。
我原本只是想偷一點懶，結果差點把自己的 AdSense 收入效率化到懸崖邊。這篇不是要說 AI Agent 不能用，而是想把我最近踩到的坑攤開：用 AI Agent 審文章很爽，但如果方式不對，AdSense RPM 暴跌可能比文章優化效果更快出現。
如果你是因為 AdSense RPM 突然暴跌、AdSense 收入下降，或後台開始懷疑無效流量才找到這篇，先不要急著把文章全部重改。這篇真正想回答的是：除了文章改壞、廣告版位、季節因素和流量來源，AI Agent + Playwright 反覆開正式前台，也可能是你該排查的廣告流量品質風險。
事情是這樣。我最近突發奇想，想把夜羽凌的部落格裡一些資訊過時的文章重新整理，也順便測試 AI 能不能直接閱讀線上文章，幫我找出哪些地方要更新。我試了 Claude for Chrome，也試了 OpenAI Codex 和 Google Antigravity 2.0。
Claude 的方式比較像請一個助理坐在瀏覽器旁邊，一篇一篇慢慢讀。Codex 和 Google Antigravity 2.0 則更像工程師的做法：用 Playwright 快速打開前台文章、抓 H1、H2、連結、圖片、JSON-LD，再回報哪裡過時、哪裡需要補來源。Google 也在 Gemini 3.5 的官方說明裡提到，Gemini 3.5 Flash 可透過 Antigravity 用在 agentic workflow，所以速度真的很有感。
我很快樂地用這些 AI Agent 做了多篇文章審計，接著把文章資訊更新、段落補強、內鏈修好。那一天我心裡甚至有一種「我終於找到內容維護加速器」的得意。結果第二天打開 AdSense，我看到的不是收入變高，而是 RPM 斷崖式下降。
AdSense RPM 突然暴跌前，我做了什麼 AI Agent 審文章？
我做的事情其實很單純：把一些舊文章交給 AI Agent 檢查，請它們判斷資訊是否過時、來源是否需要更新、內鏈是否可以補強。這種工作以前很耗心力，因為每篇文章都要打開前台、掃段落、查官方資料、回頭改稿。
Claude for Chrome 的節奏比較慢，但它像真人瀏覽一樣逐篇看，回報也比較偏閱讀感。Codex 的審計比較細，會把 HTML 結構、連結狀態、圖片 alt、FAQ、schema 這些技術點列出來。Google Antigravity 2.0 這輪同樣是用 Playwright 搭 Gemini 3.5 Flash 去掃，速度很快，很適合快速掃多篇，但細節沒有 Codex 那麼密。
那時候我只看到「效率」兩個字。我心裡的想法是：如果 AI 可以幫我找出過期資訊，我就能用更短時間提高文章品質。對有大量舊文的部落客來說，這簡直像突然拿到一台內容維護機器。
但我忽略了一個很關鍵的差別：AI Agent 審文章時，到底是在讀本機副本、後台 HTML，還是在用瀏覽器反覆打開正式前台？這個差別，在內容品質上看起來只是小細節，在 AdSense 風險上卻可能是完全不同的世界。
為什麼 Playwright 審線上文章可能踩到 AdSense 無效流量？
Playwright 審線上文章的風險，不在於它叫 Playwright，而在於它會像真正的瀏覽器一樣打開網址。根據 Playwright 官方導覽文件，`page.goto()` 會開啟 URL，並等待頁面載入；文件也提到 load 事件包含樣式、腳本、iframe、圖片等相依資源。
換句話說，如果你讓 Playwright 打開正式前台文章，它不是「讀一份文字檔」而已。它可能會載入前台腳本、圖片、第三方資源，也可能讓真實 AdSense 廣告程式碼進入流程。這就是我現在會把「Playwright AdSense 無效流量」放進排查清單的原因：一次兩次也許不明顯，但如果 AI Agent 快速掃多篇、重跑多輪、每次都開正式網址，風險就會累積。
Google 對無效流量的定義也不是只看點擊。AdSense 官方無效流量說明把可能人為墊高廣告主成本或發布商收益的 clicks 和 impressions 都列入範圍，並提到自動化工具、流量來源、robots 或 deceptive software 都可能被歸在風險裡。AdSense Program policies 也禁止用任何方式人工製造廣告曝光或點擊。
我不能證明自己的 RPM 下跌 100% 就是它造成的。AdSense 本來就會被季節、廣告需求、流量來源、版位、內容調整影響。但當我把時間線拉開看：AI Agent 大量審文章、隔天 RPM 斷崖、流量反而上升、廣告收益沒有同步跟上，這個嫌疑突然變得非常大。
我現在的判斷是：如果你有 AdSense，任何會自動化打開正式前台文章的 SEO 審計，都要先問一句：這次會不會載入真實廣告？如果答案是不確定，就先停。
如果你也在比較 AI 工具怎麼分工，我之前寫過一篇 三大 AI 分工場景對照，那篇可以先拿來判斷任務該給哪一種工具；但牽涉正式網站與廣告的任務，要再加一層風險檢查。
Claude、Codex、Google Antigravity 2.0 審文章差在哪？
三個工具都能幫忙審文章，但它們適合的工作不一樣。Claude for Chrome 比較像慢速閱讀型助理，適合抓語氣、讀者感受、段落是否順。Codex 比較像工程型審計，適合查 HTML 結構、連結、圖片、schema 與可檢索性。Google Antigravity 2.0 搭 Gemini 3.5 Flash 的優勢則是速度快，適合快速掃描多篇文章。
AI Agent | 我用起來的感覺 | 適合任務 | 要避開的雷 |
|---|---|---|---|
慢，但像真人在讀 | 語氣、故事感、段落順序、讀者感受 | 逐篇讀很耗時間，不適合大量批次 | |
細，會把結構問題挖出來 | HTML、內鏈、圖片 alt、schema、QA 腳本 | 若直接用 Playwright 開正式前台，要先擋廣告與限制網址 | |
很快，適合大量掃描 | 快速審計、初步問題列表、多篇文章盤點 | 速度越快，越容易忘記它可能正在打正式站 |
這裡最容易誤判的是：你以為「審文章」是內容工作，其實它同時也是網站流量行為。只要 AI Agent 透過瀏覽器讀正式前台，內容維護、SEO 審計、廣告風險就被綁在一起了。
如果你還在想 Claude、ChatGPT、Gemini 到底該怎麼選，我那篇 三大付費 AI 購買建議比較偏工具選型；這篇則是補上另一個盲點：工具能力越強，越要先定義它不能碰哪裡。
看到 AdSense RPM 暴跌時，我先做錯了哪些排查？
我第一反應是：是不是文章改壞了？所以我又讓 AI 審了好幾次，改了更多段落、補了更多資訊、調了更多版面。現在回頭看，這就是第一個錯誤：我用可能有問題的方法，去排查可能由那個方法造成的問題。
第二個錯誤是把流量上升解讀成優化成功。那天結束時，我看到網站流量上升很多，甚至到後來翻了約 2.5 倍。我很天真地想：文章品質變好了，Google 反應比較快，AdSense 可能只是延遲。結果第三天 RPM 又掉，我才開始懷疑廣告設定。
第三個錯誤是太快去調廣告版位。我花了一天把會擠壓頁面的動態廣告整理掉，這件事本身是好事，因為讀者體驗更穩，版面也比較不會跳。但它不一定是 RPM 暴跌的根因。當根因還沒釐清時，大改廣告設定只會讓排查線索變混亂。
Google 的 AdSense 收益問題排查說明建議先看 page views、coverage、impressions，再從網站層級往產品、版位、格式和平台拆。這提醒我：RPM 掉的時候不能只盯著單一原因，要先把流量、曝光、覆蓋率和改動時間線拆開。
Google 的 Ad serving limits 說明提到，廣告投遞可能因流量品質評估或無效流量疑慮而受限，也就是站長常說的 AdSense 廣告投放受限。Google Ad Traffic Quality 也說明 Google 會用自動化系統與人工審查處理可疑流量，有些可疑模式可能需要一段時間才看得出來。
我現在會給自己的提醒是：看到 AdSense RPM 暴跌，不要先急著「再優化」。先把時間線寫下來：哪一天跑了什麼腳本、哪些頁面被大量打開、廣告設定改了什麼、流量來源是否改變、Policy Center 有沒有提示。這份時間線，比再問 AI 十次還重要。
AI Agent 審文章怎麼改成比較安全？我的本機 HTML 流程
我後來保留 AI Agent 審文章，但改掉最危險的一步：不讓 Playwright 直接打開正式前台文章。重點不是禁用 Playwright，而是把它的工作場景從「正式網站」搬到「本機 HTML」。
現在我會先用 PowerShell 下載文章 HTML，或從 CMS/API 匯出文章內容，存成工作區裡的檔案。這一步仍然會對正式站產生 HTTP request，所以我不會高頻重跑；但它不會像瀏覽器那樣執行前台 JS、載入圖片 iframe 或跑 AdSense。
Invoke-WebRequest "https://你的正式網域/article/example" -OutFile "example.live.html"
接著才讓 Playwright 開本機檔案：
await page.goto('file:///C:/workspace/example.live.html')
這時 Playwright 做的事情就變成 DOM 查詢，例如抓 h1、h2、內鏈、圖片 alt、JSON-LD、FAQ 數量，而不是幫我刷新正式前台。它仍然很適合做 AI SEO 審計、AIO/GEO 機械檢查，只是檢查場域變乾淨了。
我的安全流程大概長這樣：
- 先取靜態內容：用 CMS HTML、API response 或一次性下載 HTML，不用瀏覽器批次掃正式站。
- 在本機審計：用 file:// HTML 給 AI Agent 查 DOM、列問題、比對 meta 與 schema。
- 人工少量看前台：真的需要確認 RWD、圖片實際載入或版面時，自己手動開幾頁看，不讓腳本循環刷新。
- 擋廣告請寫成預設：任何自動化瀏覽器環境都先阻擋 AdSense 請求與正式前台 navigation。
- 留下執行紀錄：哪天跑了什麼、掃了幾篇、是否有廣告阻擋，未來排查才有線索。
如果你原本是用 AI 寫 SEO 文章或優化文章流程，可以先看我整理過的 Claude SEO 寫作工作流，但請把這篇的風險規則加進去：正式前台和廣告程式碼，不應該成為 AI Agent 任意探索的遊樂場。
還能用 AI 做 SEO 審計嗎？我現在會先看這張決策表
可以，而且我反而更確定 AI Agent 很適合 SEO 審計。真正要改的是權限邊界。AI 很擅長幫你找過時資訊、壞連結、標題不一致、FAQ 不夠精準、內鏈不足；但它不該為了做這些事，反覆觸發正式站的真實廣告環境。
審計方式 | 效率 | AdSense 風險 | 我現在的建議 |
|---|---|---|---|
AI Agent 直接開正式前台文章 | 高 | 高，尤其是大量批次與重跑 | 除非已擋廣告且低頻，否則不要用 |
下載 HTML 後用 file:// 審計 | 高 | 低很多 | 我目前最推薦的折衷方案 |
讀 CMS 後台內容或 API response | 中到高 | 低 | 適合內鏈、schema、正文結構檢查 |
人工開前台少量 QA | 低 | 低到中 | 只用在圖片、RWD、互動與版面確認 |
這也牽涉到預算與工具選擇。AI Agent 不是只有月費成本，還有「它替你做了什麼操作」的隱形成本。對靠 AdSense、聯盟行銷或 SaaS 訂閱內容賺錢的站長來說，工具費不是最貴的；最貴的是錯把正式營收環境當測試場。
如果你只是想入門，不一定要一開始就訂滿所有 AI 工具。我那篇 免費 AI 工具清單比較適合先試水溫；等你真的要批次維護文章庫，再升級到 Agent 工作流也不遲。
如果你的 AdSense RPM 也突然下跌，先做這份檢查清單
AdSense RPM 暴跌時最怕慌，因為你越慌，越容易同時改文章、改廣告、改版位、改快取，最後完全不知道哪一個動作有效。我的建議是先做一份不漂亮但有用的檢查清單。
- 先看 AdSense Policy Center：有沒有 ad serving limit、invalid traffic concerns 或其他政策提示。
- 看流量來源：自然搜尋、社群、referral、直接流量是否有異常尖峰。
- 看自動化紀錄：最近有沒有 Playwright、爬蟲、監測工具、AI Agent 批次掃正式前台。
- 看廣告曝光率與頁面 RPM：是全站掉，還是某幾篇掉；是曝光變少，還是單價變低。
- 先停止高風險測試：暫停自動化前台掃描，改用本機 HTML 或後台內容審計。
- 再改版位：確定不是流量品質問題後，再慢慢調廣告位置與使用者體驗。
這件事給我的最大教訓是：效率不是只有「做得快」，還包括「不把別的系統搞壞」。AI Agent 可以幫我快速找出文章過時資訊，也能幫我把 SEO 審計做得更細，但它不能替我判斷營收系統的邊界。那條線，站長自己要畫清楚。
如果你也在用 AI 維護文章庫，下一次按下批次審計前，先檢查三件事：它打的是不是正式前台？會不會載入真實廣告？有沒有本機 HTML 或 staging 可以替代？這三題問完，可能就能少掉一次很貴的踩雷。
FAQ：AI Agent 審文章與 AdSense RPM 暴跌常見問題
Playwright 開自己的網站一定會害 AdSense RPM 暴跌嗎？
不一定。RPM 會受到流量來源、廣告需求、版位、季節與內容變動影響。我的判斷是：如果 Playwright 反覆開正式站、讓真實 AdSense 程式碼載入，就會把本來很好的 AI 審計流程變成高風險行為。至少要把它列為第一批排查項目。
AI Agent 審文章時只下載 HTML，還會算無效流量嗎？
單次下載 HTML 不是瀏覽器互動，也不會執行前台 JavaScript 或載入廣告，風險比 Playwright 直接開正式前台低很多。但它仍然是正式站 request，所以不要做高頻迴圈；更好的做法是讀 CMS 內容、靜態 HTML 副本或 staging。
AdSense RPM 暴跌後要先改廣告版位嗎？
不要一開始就大改。先看 AdSense Policy Center、流量來源、異常流量、頁面 RPM 與廣告曝光率，再判斷是版位、季節、內容更新、流量品質或疑似無效流量。先保留證據，才不會越修越亂。
現在還能用 AI Agent 做 SEO 文章審計嗎？
可以，而且我仍然會用。差別是我不再讓自動化瀏覽器直接掃正式前台文章，而是改成下載或匯出 HTML 後，在本機 file:// 環境做 DOM 查詢，必要時再用人工方式看前台畫面。
結論：把 AI Agent 放回安全邊界裡
這次最大的教訓不是「不要用 AI Agent」，而是不要把正式營收環境當成測試場。能讀後台內容，就不要讓自動化瀏覽器開正式前台；能用本機 HTML，就不要反覆跑正式網址；真的需要看畫面，再用少量人工 QA 確認。
我接下來仍然會用 AI Agent 做內容維護，因為它真的能節省很多審文時間。但我會把工作拆成兩層：內容層交給 AI 檢查過時資訊、內鏈、圖片 alt、schema 和 FAQ；前台層則保持低頻、人工、可追蹤，不再讓 Playwright 無限制掃含有 AdSense 的正式頁面。
如果你的 AdSense RPM 已經突然暴跌，先不要急著重寫文章，也不要一口氣大改廣告版位。更穩的順序是：先停掉自動化前台掃描，留下操作時間線，再查 Policy Center、流量來源、曝光率與頁面 RPM，最後才判斷是不是文章品質、版位或廣告投放受限的問題。
我最希望你帶走的不是恐慌，而是一個很實用的邊界：AI 可以幫你讀文章、整理資料、找過時資訊，但不要讓它在沒有防護的情況下替你「瀏覽」正式營收頁面。這條線畫清楚，AI Agent 才會是加速器，而不是把收入推下去的那隻手。
參考資料
這篇踩雷文是我的實際操作經驗，不代表 Google 對單一網站的官方判定。為了讓讀者能自己交叉檢查，我把文中用來判斷 AdSense、Playwright 與 AI Agent 風險邊界的官方資料列在這裡。
- Google AdSense：Troubleshoot common AdSense earnings issues
- Google AdSense：Ad serving limits
- Google AdSense：Invalid traffic
- Google AdSense：Program policies
- Google Ads：How Google prevents invalid traffic
- Playwright 官方文件：Navigations
- Anthropic 說明：Get started with Claude in Chrome
- OpenAI Codex 官方介紹
- Google Antigravity 2.0 官方頁面
- Google 官方部落格：Gemini 3.5
延伸閱讀
如果你想把這次踩雷變成更完整的 AI 工作流，可以從下面幾篇繼續看。它們分別對應工具分工、AI 工具選型、SEO 寫作流程，以及免費 AI 工具入門。
- 三大 AI 分工場景：哪些任務適合交給 Claude、ChatGPT、Gemini？
- Claude、ChatGPT、Gemini 付費版怎麼選？
- Claude SEO 寫作工作流：從主題、架構到文章優化
- 免費 AI 工具清單：先試水溫再升級 Agent 工作流
最後提醒
AI Agent 是很好的內容維護助手，但邊界要先畫好。訂閱夜羽凌的部落格，之後會不定期收到我繼續踩坑、修坑、把坑寫成檢查清單的文章。
