作品分享｜結合即時爬蟲的 AI 品牌洞察工具

行銷人員的市場研究，是一場複製貼上馬拉松

如果你在廣告代理商工作，你大概看過這個畫面：

行銷人員手動從各社群平台複製資料的日常

同事打開 Dcard，一篇一篇往下滑，看到覺得有趣的文章或留言，反白、複製、切換視窗、貼到筆記區。然後繼續滑，繼續複製。Threads 也是一樣的流程，再來是 PTT，接下來是各種論壇。這樣花個兩三個小時，「資料庫」總算整理得差不多，再把這堆文字全部餵給 ChatGPT，請它幫忙發想 insight。

SEO 人員那邊也有類似的流程，而且近年工作內容又多了一層複雜度。除了傳統的關鍵字研究，現在還要顧及 AEO——也就是讓客戶的內容被 Google AI overview 引用，確保品牌在 AI 時代也有足夠的曝光。

AEO（Answer Engine Optimization，答案引擎優化）是 SEO 在 AI 時代的演進。以前做 SEO，目標是讓網頁排在 Google 第一頁；現在 Google 推出 AI Overview，使用者的問題直接被 AI 摘要回答，不一定會點進任何網站。AEO 的核心目標就是讓品牌內容被這個 AI 摘要引用，成為 AI 回答問題時的來源之一，而不只是爭取傳統的搜尋排名。

光是關鍵字這塊，就要打開 Google Keyword Planner 從月搜量開始篩選，哪些值得做、哪些競爭太激烈、哪些跟品牌有關聯，每個都要人工判斷。判斷完還要逐一搜尋這些關鍵字，確認 SERP 長什麼樣、AI overview 有沒有出現、品牌有沒有被提到，這些都要一一點開確認。

SERP（Search Engine Results Page，搜尋結果頁）就是你在 Google 打完關鍵字按下搜尋後看到的那一頁。這一頁的內容比大多數人想像的豐富很多：搜尋框下方會出現推薦搜詞（Autocomplete），頁面本身則包含 AI Overview（Google AI 直接生成的摘要回答）、自然搜尋結果（傳統的網站排名列表）、相關問題（People Also Ask）、以及頁面底部的相關搜尋（People Also Search For）。對行銷人員來說，同一個關鍵字的 SERP 裡藏著大量資訊：使用者真正在找什麼、Google AI 目前怎麼回答這個問題、哪些網站被引用，這些都是市場研究的重要原材料。

這兩個流程有個共同點：耗時、重複，而且每次都要從頭來過。在我們公司，這些流程是每個提案或專案開始前一定要完成的事，而這個「複製貼上馬拉松」幾乎每個行銷人員都經歷過。

我在公司 Tech Innovation team 內的任務就是觀察大家的日常痛點，開發出好用的工具來幫助大家優化工作流程，這種高重複高耗時的工作流程非常值得被優化。

定義工作步驟，並透過實際數據支援 LLM 給出更棒的 insight

觀察了不同行銷人員的工作方式之後，我們發現一件有趣的事：大家做市場研究的流程其實高度相似，只是每個人都在用自己的方式重新走一遍。

SEO 人員幾乎都會去 Google Keyword Planner 查月搜量、看競爭程度；Planner 幾乎都會到社群媒體翻文章、找大家在討論什麼。步驟一樣，每次都要從頭手動來過。

我們決定把這些重複的步驟整理出來，定義成幾條固定的工作流。

但整理的過程也讓我們發現另一個問題：光靠和 LLM 對話來發想關鍵字或 insight 是不夠的。LLM 給得出建議，但給不出「現在真的有多少人在搜這個」、「社群上大家實際在討論什麼」。而行銷人員在對客戶提案時，insight 背後必須有真實數據支撐，不然就只是一個說法而已。

所以這個工具要實現的事情有兩個：一是把行銷人員共同的工作流包起來，不用每個人自己重新摸索 prompt 怎麼下；二是在 LLM 分析的同時，串接即時爬蟲抓取真實的社群數據與搜尋數據，讓每一個 insight 和關鍵字背後都有數據可以說話。

三個模組，覆蓋一條完整的市場研究工作流

根據使用情境，我們決定把這些工作流拆成三個模組來解決。

Search Insight、AI Search Insight、Social Insight 三個模組各自對應不同的工作情境

Search Insight 負責處理 SEO 人員的關鍵字研究流程。從輸入種子關鍵字開始，工具透過 LLM 和即時爬蟲同時展開相關字，再串接 Google Keyword Planner 取得月搜量、競爭程度和 CPC 範圍。拿到這批關鍵字之後，LLM 依使用者意圖自動分群，呈現搜尋這個主題的人背後有哪幾種不同需求、各自市場規模多大，讓 SEO 人員判斷哪些意圖值得優先佈局、哪些群組還有空間切入。

Search Insight 工作流：從種子關鍵字出發，透過 LLM 擴展、爬蟲驗證、Keyword Planner 數據補充，最終分群呈現使用者意圖

AI Search Insight 處理的是 AEO 監測工作。使用者輸入品牌名稱和相關搜尋問題，系統自動爬取 Google AI Overview 和 ChatGPT 的回答內容，分析品牌在每個問題裡有沒有被提及、以正面還是負面方式提及、官網有沒有被引用。模組同時分析 Google AI 傾向引用哪類媒體，讓行銷人員知道該優先佈局哪個渠道，才有機會進入 AI 的引用池。

AI Search Insight 工作流：爬取 Google AI Overview 與 ChatGPT 回答，分析品牌提及率、情緒傾向與官網引用，並回推媒體佈局建議

Social Insight 對應 Planner 端的工作。Planner 做市場研究時，最耗時的一步就是手動到各社群平台翻文章、找討論、整理洞察。這個模組自動從 Threads 抓取真實貼文，交給 LLM 提煉出有意義的使用者洞察，每一個 insight 背後都保留原始貼文連結可以追溯，讓 Planner 對客戶說明洞察來源時有真實數據支撐。

Social Insight 工作流：從 Threads 批量爬取真實貼文，經 LLM 提煉成有原始貼文佐證的使用者洞察

三個模組各自解決對應的需求，但也可以串接使用——Search Insight 找到的關鍵字，可以直接帶入 AI Search Insight 做品牌分析；Social Insight 挖掘到的使用者洞察，也可以反過來補充關鍵字的方向。我們希望它不一定是三個獨立工具，也可以是一條完整的市場研究工作流。

由於這個專案目前是公司的內部工具沒有對外開放，因此只能以影片和圖片來 demo 實際使用情況。

Search Insight —— 關鍵字發想與研究

這個模組主要幫助使用者快速探索關鍵字，以及根據市場需求去區分關鍵字群組，進而取得以市場需求為導向的關鍵字組。

行銷人員在做關鍵字研究時，通常從幾個自己已經熟悉的詞開始，然後就卡住了。人工發想關鍵字容易有盲點，光靠 Google Keyword Planner 又需要自己先有詞才能查，於是就陷入一個先有雞還是先有蛋的問題。Search Insight 要解決的就是這個起點困境。

Step 1：擴展關鍵字視野

使用者輸入幾個種子關鍵字，如果連從哪裡下手都不確定，可以先用「協助我發想關鍵字」的功能，輸入品牌或品類，讓工具生成一批候選詞。

這一步背後同時跑兩條路：一條是 LLM 根據內部 SEO 人員訪談後整理出的 prompt，針對輸入的主題詞水平擴展出一批候選關鍵字；另一條是透過我們自己開發的爬蟲插件，即時抓取 Google SERP 上「people also search for」的真實字詞。

這個爬蟲瀏覽器插件是由內部（我！）開發的，支援從 Google 搜尋、Google Maps、Dcard、PTT、Threads、YouTube、Instagram、Facebook 等主流平台自動擷取公開資訊與留言。使用者無需手動複製貼上，即可快速批量收集各站點的文章、討論串、搜尋結果等結構化資料，大幅提升資料蒐集與研究的效率。有空再來寫文章和大家分享開發這個插件的辛酸血淚 QQ

兩條路是非同步並行——LLM 呼叫和插件任務同時啟動，網站下達指令給瀏覽器插件開始執行爬取任務，插件完成後批次回傳結果，兩邊都結束後才做合併去重。LLM 負責從語意和意圖角度擴展視野，插件負責從真實搜尋行為驗證這些詞確實有人在搜，兩者各有角色，互補不互斥。

候選詞確認後，系統串接 Google Keyword Planner API 批次查詢每個關鍵字的月搜量、競爭程度、競爭指數和 CPC 範圍，讓使用者在一張表格裡就能判斷哪些詞值得投入。

Step 2：把關鍵字整理成以需求為導向的資訊

拿到幾十個零散關鍵字之後，當然可以直接根據這些搜量資訊協助判斷要選哪些關鍵字，但我們可以透過 AI 來幫助我們更聰明地利用這份清單。

這些關鍵字會被 LLM 自動分群成幾個意圖群組，每張卡片代表一種市場需求，顯示該群組的關鍵字數量與總搜尋量。使用者可以直接看出搜尋這個主題的人背後有哪幾種不同的需求、各自的市場規模大概多大，做內容規劃時比單看月搜量更有參考價值。

分群的 prompt 對輸出結構有嚴格約束：2 到 8 個大分類、每個大分類 2 到 5 個子分類，且每個關鍵字都必須被歸入某個子類。這個結構透過 Zod schema 在 API 層強制驗證，LLM 如果輸出不符合格式會直接拋錯，不讓格式錯誤的資料靜默流入後續流程。使用 Vercel AI SDK 的 generateObject，LLM 的輸出本身就是結構化物件，不需要額外的 JSON 解析或清理（很好用，但要做好錯誤處理）。

Step 3：依搜尋意圖分類，對應使用者的搜尋旅程

關鍵字分完群組後，收集到的問題和搜尋詞會進一步被分類成資訊型、商業型、導航型、交易型四種意圖。這個分類方式參考了內部 SEO 人員實際的工作習慣：他們在規劃內容時，不是以單一關鍵字為單位，而是以「使用者當下在搜尋旅程的哪個階段」為單位去思考。

這四種意圖分類來自 SEO 領域長期使用的搜尋意圖框架：資訊型想了解某件事、商業型在比較選項、導航型想找特定品牌、交易型已準備採取行動。把關鍵字依意圖分類，SEO 人員可以看出同一個主題下使用者搜尋旅程的全貌——哪個階段已有內容覆蓋、哪個階段還是空白，進而針對不同意圖規劃對應的內容策略。

點選不同意圖分類，可以看到該類型下的子群組和對應的問題清單。商業型的使用者正在比較品牌、尋找推薦；資訊型的使用者還在了解基礎知識；交易型的使用者已經準備好要採取行動。同一個主題下，這幾群人想要的內容完全不同，行銷人員可以針對不同階段的使用者去規劃對應的內容策略。

Step 4：看 Google 實際給了什麼答案

選定想深入研究的關鍵字群組後，工具會透過瀏覽器插件批次爬取每個關鍵字的 SERP 頁面，收集推薦搜詞、自然搜尋結果、People Also Ask、相關搜尋。

這份資料也可以直接匯出成 JSON，銜接自己習慣的 LLM 做進一步分析。平台的定位之一是把最難收集的原材料備好，後面怎麼用由研究人員自己決定。

走完這四步，使用者會得到這些資料：一份有數據支撐的關鍵字清單、一張以市場需求為單位的意圖地圖，以及每個關鍵字對應的真實 SERP 樣貌和 AI Overview 內容。搜集完這些資訊，過去可能要花一天人工整理的事情，在這個流程裡壓縮到幾十分鐘內完成 👍🏻✨

AI Search Insight —— 品牌曝光分析

傳統 SEO 的核心目標是「爭取 Google 自然搜尋前幾頁」。但當 Google 開始用 AI Overview 直接回答使用者的問題，這個目標可能已經無法滿足品牌方了。

品牌主和 SEO 團隊真正需要知道的是：當使用者問 AI 這些問題時，我的品牌有沒有被提到？被怎麼說？有沒有引用到我的官網？競品的曝光狀況又如何？這個模組就是用來回答這些問題的。

從關鍵字到 AI Overview 原始資料

使用者可以直接把 Search Insight 跑出來的關鍵字匯入，或是自行新增想監測的關鍵字和相關問題字句。確認好監測範圍後，系統啟動瀏覽器插件，逐一造訪這些搜尋詞的 SERP 頁面，即時爬取 AI Overview 的完整內容。

爬取下來的 AI Overview 不是以整篇文字儲存，而是切分成段落級的結構化物件。這個設計靈感來自 SerpAPI 回傳的原始結構——每個 text block 帶有獨立的 id，references 陣列是一份 id → 來源連結 的對應表。這樣的粒度讓後續的品牌比對和情緒分析可以精確到段落層級，而不是只能對整篇內容做模糊判斷。

// SerpAPI 回傳的原始 AI Overview 結構
// text_blocks 是段落陣列，每個 block 有 reference_indexes 指向引用來源
// references 是一份 index → 來源連結 的查找表
 
const aiOverview = {
  text_blocks: [
    {
      type: "paragraph",
      snippet: "無線吸塵器的主要優點是機動性高，不受電線限制，適合快速清理。",
      reference_indexes: [1, 3],
    },
    {
      type: "list",
      title: "選購重點",
      list: [
        { snippet: "電池續航：建議選擇 40 分鐘以上", reference_indexes: [2] },
        { snippet: "吸力（Kpa）：家用一般 20Kpa 以上已足夠", reference_indexes: [2, 4] },
        { snippet: "集塵容量：0.5L 以上較不需頻繁清空", reference_indexes: [3] },
      ],
    },
  ],
  references: [
    { index: 1, title: "吸塵器選購指南 2024", link: "https://example.com/guide", source: "ExampleBlog", snippet: "..." },
    { index: 2, title: "Dyson V15 完整評測", link: "https://example.com/dyson-review", source: "ReviewSite", snippet: "..." },
    { index: 3, title: "無線吸塵器比較表", link: "https://example.com/compare", source: "PCHome", snippet: "..." },
    { index: 4, title: "吸力單位 Kpa 詳解", link: "https://example.com/kpa", source: "TechNote", snippet: "..." },
  ],
};

品牌別名自動比對

設定要監測的品牌時，使用者只需輸入品牌名稱和官網，系統會自動從關鍵字資料中推斷出這個品牌可能出現的所有稱呼——正式名稱、中文翻譯、縮寫、暱稱都涵蓋進去。這樣當 AI Overview 寫的是「三星」但使用者輸入的是「samsung」，系統也能正確匹配，不會遺漏任何曝光。官網引用的比對同樣處理過，提取 domain 層級做匹配，不同路徑的官網頁面都能被計入。

量化分析：品牌在每個問題的曝光長什麼樣

比對完成後，系統針對每個搜尋問題和每個品牌，逐段分析 AI Overview 的內容。每個段落獨立判斷有沒有提及品牌、提及是正面還是負面、有沒有引用官網，最終換算成提及率和引用率。

這些分析表格背後串接了多個 prompt，每個 prompt 負責不同的分析維度，最後彙整成使用者看到的量化結果。這裡有個心得是，能靠程式計算就靠程式，又快又可靠，而需要人類判斷的部分（例如情緒分析）就由 LLM 協助。

媒體引用分析：Google AI 在引用誰的內容

除了品牌自身的曝光，這個模組也分析 AI Overview 的引用來源。系統從所有 AI Overview 的引用連結中提取 domain 和媒體來源名稱，再由 LLM 依媒體屬性分類，計算每個媒體的跨問題引用次數和佔比。

通訊行、評測網站、內容媒體各佔幾成，這份資料讓品牌主看到的不只是「我被提到幾次」，而是「Google AI 在這個議題上傾向引用哪類媒體，我應該優先佈局哪裡才有機會進入 AI 的引用池」。

各問題結構分析：反推 Google AI 的答題邏輯

系統讓 LLM 去解析每個搜尋問題的 AI Overview 內容，分析這篇回答背後的核心意圖是什麼、Google AI 組織答案的邏輯是什麼、引用了哪種類型的來源。換句話說，就是用 AI 去解析另一個 AI 的輸出。

對行銷人員來說，這個分析在解決：如果我想讓我的內容被 Google AI 引用，我應該寫什麼、怎麼寫、鎖定哪個意圖。從結果反推內容策略，比盲目猜測演算法喜歡什麼可能更有依據。

段落情緒判斷：除了知道有沒有被提到，更重要的是知道怎麼被提到

每個段落獨立由系統判斷有沒有提及品牌、提及的方式是正面還是負面，並對應到該段落引用的來源連結。

品牌方可以具體看到 AI 在哪些問題上對自己的品牌有正面描述、哪些問題上出現了負面評價、哪些引用來自自己的官網，進而決定哪些內容值得加強佈局、哪些負面敘述需要被特別處理。

一鍵產出 Google Slides 報告

各個表格區塊的分析做完之後，所有表格和洞察可以一鍵匯出成 Google Slides 完整簡報。授權完成後系統依章節順序自動產生投影片，整份報告可以直接拿去開會或交給客戶，省去人工整理的時間。

簡報的顏色、字級、版面配置全部集中定義在統一的 config 裡，確保每次產出的格式一致。目前支援 13 種章節類型，每種章節對應一個獨立的渲染邏輯，章節間採順序產生而非同時並發，避免寫入衝突。各個分析表格在畫面渲染完成後會自動註冊最新資料，確保匯出時拿到的永遠是當前狀態，不會有資料不同步的問題。

AI Search Insight 要解決的問題是：品牌在 Google AI Overview 裡有沒有被提到、被提到是正面還是負面、哪些問題完全沒有曝光。這些過去要人工一筆一筆搜尋確認，十個關鍵字就得重複十次，還要自己歸納，現在能全部自動化就快多了 🥹

Social Insight

Planner 在做市場研究時，最耗時的一步就是手動到社群平台翻文章、找討論、整理洞察。Social Insight 要解決的就是這件事。

使用者輸入關鍵字，工具呼叫瀏覽器插件去 Threads 搜尋，批次爬取相關貼文的內容和互動數據。以「拍照手機」為例，一次可以收集到三百篇以上的真實貼文，同時帶回每篇的按讚數、留言數、轉發數，讓 Planner 不只看到大家在說什麼，也知道哪些討論引發了最多共鳴。

收集完成後，LLM 會自動將這批貼文依洞察分群，相同需求和討論方向的貼文被歸為同一類，每個群組附上一句說明，描述這群人在意的是什麼。以「拍照手機」為例，分析結果識別出「對高品質拍照與錄影的強烈需求」、「跨品牌間的拍照體驗比較與選擇焦慮」等幾個核心需求面向，每個分類下都可以展開看原始貼文。每一個洞察背後都有真實貼文可以追溯，Planner 對客戶說明時有原始數據可以佐證。

除了自動分群，使用者也可以針對這批貼文直接提問。輸入一個問題，系統會從所有收集到的貼文裡找出相關的內容，列出對應的貼文作為佐證，並整理成一張洞察表格，每個洞察旁邊都附上原文片段和貼文連結。想知道「消費者的正面評價有哪些」或「大家對拍照功能有什麼要求」，直接問就可以拿到有原始貼文支撐的答案。

寫在工具開發完成之後

這是我第一個「全 AI」開發的專案，但人為參與比我想像得多

很特別的是這個專案不同於以往「PM 開好規格、設計師出設計稿、工程師交付程式碼」的流程，主管希望以最低成本、最快速開發來完成這個 MVP，因此這個工具僅由 PM 告知功能清單（同時也感謝 PM vibe 出產出簡報的 app script，讓我可以把這些邏輯導入到專案中），沒有設計師參與的情況下，UI 並沒有被嚴謹要求，程式碼的部分也先以完成業務需求為首要目標，越快完成專案讓這個 MVP 可以快速被內部試驗是最重要的事情。

因此開發流程變成是，我自己先依照對規格的理解和腦海中的工具樣貌，用 Lovable 生成一個 UI 雛形，覺得方向大概對了之後，就逐一以模組為單位慢慢把功能補上去。雖然說可以 AI 開發，但我自己認為人為參與還是相當多的。

Lovable 是一款主打「用說的就能寫程式」的 AI 網頁開發工具。它能根據自然語言指令自動生成高品質的 React 與 Tailwind CSS 程式碼，並即時預覽畫面。開發者可透過對話快速迭代 UI 介面與功能，大幅縮短從想法到原型的開發週期。

舉例來說，拿到 PM 需求時，我會將業務需求由人工轉換為工程規格，再把這些需求文字轉化成很詳細的 prompt，並準備好 AI 需要的背景資料，有意識地選擇「Plan mode」然後詳細閱讀它的計劃，這個過程也會再經歷一些修正，像是提醒 AI 已經有共用元件可以使用、記得多做錯誤和重試處理，最重要的是確保它的計劃與業務邏輯一致。當 plan 完成後，執行「Ask before edits」一步一步監督 AI 撰寫的內容。

另一個高度人為參與的地方就是除錯。有時請 AI 協助 debug，它會在一個莫名其妙的地方打轉，可以感覺到它越繞越遠，這個時候我自己跳下去偵錯往往比繼續跟 AI 來回快很多；還有我也發現 AI 很喜歡亂用 useEffect，我已經好幾次把它寫的邏輯挪到更適合的地方去（例如併入事件監聽的邏輯），這種地方還是需要人工監督（真不可置信），AI 不會主動意識到這樣寫有問題。

發現自己以往沒發現的能力

在和 AI 一來一往的協作中，我發現我越來越有「感覺」，我能知道它會需要哪些 context 與限制，以及它在哪些部分容易出錯我需要更多地檢查。

舉例來說，如果今天要開發功能 A 的進階版，我會刻意先在同一個 chat 裡詢問 AI 關於功能 A 的背景，確認它理解正確後，再請它實作進階版。因為我知道這個 chat 的 context 裡已經有它需要的所有資訊，不需要再另開一個對話從頭解釋。

也很認同 prompt engineering 其實就是 context management 這件事，當越來越知道 AI 擅長的地方、容易搞錯的地方，還有它需要什麼樣的前情提要和輔助資訊，通常都能夠和 AI 協作地很良好！（很自豪的是，AI 越來越少和我確認「是不是這樣」，當它越來越少和我二次確認，我就能確定自己給它的資訊是足夠且清楚的）。

最難的還是「要開發什麼」，而不是「如何開發」

打開社群軟體，不管是不是工程師的人都在展示他們做的酷東西。在這個十幾秒就能完成一個網站的時代，開發本身的門檻非常低廉。但我越做越確定的是：真正稀缺的從來都是人們的想法，知道要做什麼、為什麼要做、做給誰用。

這個專案裡我認為最難的部分，是去訪談那些實際做市場研究的人，聽懂他們在說什麼，再把那些說出來的東西梳理成可以拆解的工作流。你當然可以自己想像，或是讓 AI 扮演這些使用者角色，但工具終究要給真實的人用，沒有什麼可以取代實際和他們互動、請教、觀察的過程。

至於那些老生常談或設計方法，使用者訪談、user story、放聲思考法，在這個專案裡都派上了用場。這些東西幫助我把一個模糊的想法變成一個真正好用的產品。AI 可以幫你把產品做出來，但告訴你要做什麼的，還得是人而不是 AI。