AIREITER

AI 圖片

FLUX.2 ProGPT-Image 2Wan 2.7 Image ProGPT 4o ImageSeedream 5.0 ProSeedream V5 liteSeedream V4.5更多

AI 影片

Kling 3.0 Motion ControlSora 2 ProKling 3.0 TurboSora 2Kling 3.0Grok Imagine 1.5Veo 3.1更多

LLM

Gemini 3.6 FlashGemini 3.1 ProKimi K3Gemini 3 ProGemini 2.5 ProClaude Opus 5Claude Fable 5更多
即將推出Seedance 2.5
Super ResolutionLyric Video GeneratorGPT Image 2 1K GeneratorGPT Image 2 Product Mockup GeneratorUse GPT-5.6 Online
API 文件價格
部落格更新LLM API GuideClaude API GuideKimi K3 API Guide
範本
  • AIReiter
  • 部落格
  • 把 300 則競品廣告丟給模型,最後只得到四個形容詞?改用這套方法

把 300 則競品廣告丟給模型,最後只得到四個形容詞?改用這套方法

最近更新: 2026-07-31 07:41:06

從公開廣告資料庫撈出 300 則競品標題後,你真正想知道的,通常不是它們「整體感覺如何」,而是競爭對手究竟在主打什麼。最省事的做法,是把 300 則文案全部貼進聊天框,然後問模型:「請總結這些廣告的賣點。」模型很快就會回覆:主打高 CP 值、強調使用者體驗、營造急迫感、採用正向情緒語氣。這四句話,你大概連一則廣告都不用看就寫得出來。

資料本身沒有問題。各平台的廣告資料庫與創意中心都是公開的,你可以用自己的帳號瀏覽,沒有繞過任何限制。問題出在提問方式:你交給模型的是一個整體問題,它自然只能還給你一個整體答案。300 則廣告被壓縮成四個形容詞,壓縮比高到幾乎所有資訊都流失,剩下的只有一些正確卻毫無用處的結論。

要讓大量文案分析產出能用的結果,先得定義什麼叫「能用」。「主打高 CP 值」無法直接執行;但「省錢承諾+數字佐證+時間限制,這種組合出現在本批 40% 的廣告中,且鎖定價格敏感型受眾」就可以直接拿來設定下一支素材的變數。想得到後一種結果,不能一步到位,必須把原本的一步拆成兩步。

為什麼一句「總結賣點」只會得到空話

單次處理會失敗,不是因為提示詞寫得不夠好,而是它在結構上就有問題。

你同時要求模型做兩種本質不同的工作:從每則廣告中擷取資訊,以及替擷取出的資訊分類。擷取偏向確定性判斷,例如這則廣告承諾了什麼、是否提供證據,答案通常相對明確;分類則涉及判斷,哪些承諾該歸為同一類、分類邊界應畫在哪裡,都需要推理。把兩件事硬塞進同一次呼叫,模型最容易走捷徑:跳過逐則擷取,憑整面文字的印象直接摘要,最後吐出一串它覺得你想聽的正向形容詞。

單次處理還有另一個問題:沒有中間產物。你拿到「主打高 CP 值」這個結論,卻無法追溯它來自哪些廣告、占比多少,也不知道有沒有反例。換一批資料再跑一次,結論可能就變了。沒有中間產物的分析,既無法檢查,也無法迭代。

正確拆法:先抽欄位,再做分群

較可靠的流程是兩步,中間插入一層結構化欄位。

第一步,針對每一則文案個別擷取欄位,並寫入固定 schema。至少要有四個維度:核心承諾、證據類型、急迫感手法,以及隱含受眾。這一步每次只看一則廣告,輸出嚴格 JSON,不要任何說明文字。

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

當你完成 300 則廣告的擷取,手上拿著的不再是 300 段文字,而是 300 筆結構化紀錄。此時,「總結賣點」已經從模糊的語意任務,轉變為可以計數、分組與繪製分布的資料問題。

第二步才是分群,而且分的是欄位,不是原始文案。直接對原始文字分群,很快又會回到語意相似性的迷霧裡;對欄位分群,則是在少數離散維度上分組,邊界清楚得多。

分群提示詞的關鍵:強制找出反例

分群提示詞真正的重點,不是叫模型「把這些資料分組」,而是要求它提出反例。

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

第二部分正是這段提示詞最有價值的地方。模型天生傾向迎合使用者;如果不施加壓力,它給出的每個群集都會顯得過度自洽。要求它從自己剛形成的群組中,挑出一筆不太符合的紀錄,會迫使它在覺得工作已經完成後繼續檢查。結果要麼暴露分類邊界過於粗糙,要麼發現第一步的欄位擷取出了錯。

讓模型挑自己毛病的技巧,不只適用於廣告分析。在程式逆向工程裡,這叫做反證據區段:模型辨認出某種演算法家族後,不能直接照單全收,而是要追問「它和標準實作究竟差在哪裡」。原理相同,這也能抑制模型在處理混淆程式碼與辨識演算法指紋時一味附和你的傾向。在文案分群中,反例檢查就是你的反證據區段。

不同步驟,該交給哪一種模型

這兩個步驟對模型的要求正好相反,因此用同一個模型包辦全部工作,純粹是在浪費資源:

步驟

所需能力

建議選擇

model id

逐則擷取廣告欄位(數百到數千筆,每筆一次呼叫)

低成本、高併發、結構化輸出穩定

Claude Sonnet 5

claude-sonnet-5

設定分類(完整讀一次樣本,歸納 enum)

長上下文

Kimi K3

kimi-k3

欄位分群、反例檢查與缺口分析

推理能力強,願意自我質疑

Claude Opus 5

claude-opus-5

頻率歸因(高出現次數是有效,還是跟風複製)

中等推理能力,能根據資料說明判斷

GPT-5.6 Sol

gpt-5.6-sol

成本能差到一個數量級,關鍵就在這個拆分。欄位擷取是唯一會隨資料量線性成長的步驟:300 則廣告就是 300 次呼叫,1,000 則就是 1,000 次。分群則是一批資料只跑一次。把最昂貴的推理層留給只需執行一、兩次的分群,把最便宜的層級用在數百次的擷取,總帳單可能相差十倍。若反過來做,讓昂貴層級跑擷取、便宜層級跑分群,就是我最常見到的浪費:擷取根本不需要那麼多推理能力,分群卻偏偏在便宜層級最弱的地方失敗。

降級究竟能省多少,不必直接相信我,自己跑一輪就知道:

  1. 從已經蒐集好的資料中挑 20 到 30 則廣告。

  2. 擷取欄位:將同一批資料分別交給 claude-sonnet-5 和 claude-opus-5,逐筆比較四個欄位的一致性。

  3. 分群:拿同一批已擷取的紀錄,分別用兩個層級分群,觀察兩件事:反例檢查是否真的在挑群組的毛病,而不是重述候選項;缺口是否能指向下一步可執行的行動。

  4. 結果很容易判讀:如果擷取一致性高,就把這一步降到便宜層級來省錢;如果便宜層級在分群時無法產出有用的反例,這一步就該留在推理層級。

陷阱一:讓模型自己發明分類

最容易踩到的坑,就是在擷取階段不提供 enum,任由模型自行創造分類。

只看單一批次時,這往往看起來沒問題。模型給你的分類名稱聽起來都很合理;問題出在第二批資料:同類型文案進來後,分類名稱變了、粒度不同了、邊界也移動了。當你試著把兩批資料並排看趨勢,會發現它們根本對不齊。第一批的「discount」和第二批的「save money」算不算同一件事?沒人知道。只要分類會隨批次漂移,跨批次比較就是假的。

解法是把「設定分類」和「使用分類」分開。先用長上下文層級一次讀完大量樣本,通常一次數百筆,這正是長上下文模型該做的事,從中歸納出完整且粒度一致的一組 enums;接著人工審核並凍結它。之後所有擷取作業都只能從固定 enum 中選擇,以 unknown 作為兜底,絕不能現場新增分類。擷取提示詞裡那句「pick only from the given enum, do not invent」,就是把這項限制明文化。

一句話總結:分類由你決定,模型只負責填格子。

陷阱二:把出現頻率當成成效

擷取與分群完成後,你很自然會依紀錄數排序,並把最常見的賣點視為「最有效」。這一步錯得很隱蔽。

高頻只能代表「大家都這樣寫」,不代表「這樣寫有效」。廣告裡的跟風鏈條確實存在:某支廣告表現不錯,一週內整個市場就蜂擁而上,創意中心隔夜出現數十個幾乎一樣的標題。你的頻率統計把這些跟風者全部算進去,得出「這個賣點最受歡迎」的結論;但它們也可能正在集體失敗,只是還沒有人先停手。頻率衡量的是從眾,不是效果。

要把頻率與成效拆開,必須替每筆紀錄接上效果資料。公開廣告資料庫中的每個素材通常都會帶有播放數、按讚數、CTR 之類的欄位。真正該排序的,不是原始紀錄數,而是「某個賣點組合中,落在高效能百分位的素材占比」。如何把逐秒留存率與 CTR 百分位讀成有意義的訊號,是另一篇文章的主題。這裡只強調一點:頻率表和效果表必須是兩張表,一旦把它們混成一張,結論就毀了。

模型在這一步的工作是歸因,不是排序。把高頻組合及其效果分布交給中等推理層級,要求它根據數字判斷:「這個頻率高,是因為真的有效,還是因為大家彼此抄襲?」即使歸因判錯,成本也不高,因為最後仍會用真實效果資料驗證。

陷阱三:只分析贏家

第三個陷阱藏在資料來源裡,一不注意甚至不會發現:廣告資料庫與創意中心預設展示的,往往是表現好的素材。像是「hot ads」或「Top Ads」這類入口,本質上就是平台已經替你依成效篩過的倖存者。

你對一堆贏家做分群,找出「成功廣告的共同特徵」,再照著複製,這正是典型的倖存者偏差。因為那些失敗廣告,很可能也具備完全相同的特徵。假設 90% 的贏家都使用「時間限制」,於是你得出「時間限制有效」的結論;但若 90% 的失敗廣告也用了時間限制,這個特徵根本沒有任何辨識力。它只是產業預設做法,與成敗無關。

解法是替贏家加上控制組。公開廣告資料庫通常可依產業、行銷目標與時間區間篩選;用同一組條件找出曾取得曝光、但互動明顯偏低的素材,對它們也做擷取與分群,再與贏家組並列比較。真正有價值的不是「贏家有什麼」,而是差異集合,也就是「贏家有、輸家沒有什麼」。只有出現在這個差異集合裡的特徵,才值得寫進下一支素材。

你不會拿到完整的輸家樣本,這沒關係。即使只有小型的低效能控制組,也遠比只從 Top Ads 得出結論更可信。

最後要交付的是變數表,不是一段摘要

走完這兩步、避開三個陷阱後,最終產物不該是一段「這批競爭對手都在主打 XX」的文字,那只會回到原本的空話。你需要的是一張變數表:

  • 每個維度(承諾、證據、急迫感、受眾)有哪些取值。

  • 哪些組合已被驗證有效,也就是位於差異集合中,且效能百分位高。

  • 哪些組合還沒有人嘗試,也就是從缺口區段挖出的機會。

這張表可以直接作為生成任務的輸入。已驗證有效的組合,用來批量產出變體;空白組合則作為低成本探測。文案維度的變數交給文字模型撰寫腳本,視覺與語調變數交給圖像、影片模型製作素材,從競品文案到自家成品廣告的鏈條便能閉環。這張變數表,正是創意生產流程中的 brief 階段所讀取的內容。

分群不是為了產出一張好看的分類圖,而是為了做出能驅動下一批生產的變數表。

一把金鑰串起四種模型層級

上述流程需要四種層級:負責擷取的低成本高併發層級、用來設定分類的長上下文層級、負責分群的推理層級,以及處理歸因的中等推理層級。它們來自不同供應商,各自有不同 SDK、驗證方式與錯誤格式。只為了在不同步驟切換模型,就讓客戶端串接好幾套介面並不划算;這也是多數人最後乾脆用單一模型處理所有工作,然後落入前述浪費的真正原因:不是昂貴層級在擷取上燒錢,就是便宜層級在分群時找不出反例。

AIReiter把這層複雜性攤平:一把金鑰、一個 OpenAI 相容介面,四種層級都在後面,切換時只要修改請求內容中的 model 欄位。

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

如果你已經使用 OpenAI SDK,只要把 base_url 指向 https://aireiter.com/api/v1,其他設定都不用改。使用 Anthropic SDK 時,則以相同的 key 呼叫 POST /api/v1/messages。

價格方面,Claude 模型價格是定價的 7 折,GPT 模型則是半價;而折扣正好落在這個流程最主要的成本上。欄位擷取是唯一隨資料量線性增加的環節:300 則廣告就是 300 次呼叫,1,000 則就是 1,000 次。它使用最便宜的 Sonnet 層級,再享有 7 折優惠,是節省成本的主力。分群與歸因每批只執行幾次,因此在這裡使用推理層級不會造成負擔;分類設定則使用同一把金鑰可調用的長上下文 Kimi K3,每批一次即可。

  • 取得 API key

  • 免註冊試用:先手動跑幾則廣告,比較便宜層級與推理層級在擷取一致性、分群反例上的表現;確認穩定後,再把流程寫成腳本。

結語

大量廣告文案分析之所以變成一團空話,不是模型能力不足,而是你把擷取與分類塞進了同一次呼叫。

把它拆成兩步:先依照凍結的 enum,逐則擷取結構化欄位,在便宜層級執行數百次;再對欄位進行分群,並強制模型提出反例,在推理層級執行一次。同時留意三個陷阱:不要讓模型臨場發明分類、不要把頻率當成成效、要替贏家建立控制組。最後產出的應是驅動下一批製作的變數表,而不是一句「主打高 CP 值」。

在這套流程裡,模型其實是兩種不同的工具:低成本的擷取器,以及願意質疑自身判斷的分類器。把它們分開,放在對的層級使用,數百則廣告才能產出可執行的洞察;把所有事混交給同一個模型,最後得到的仍然只會是一串形容詞。

>_AIReiter 模型目錄

快速存取與本指南相關的模型 API

Claude Sonnet 5

Chat

一款平衡的 Claude 模型,適合進階推理、程式開發與日常工作。

Anthropic取得 API Key >

Claude Opus 5

Chat

適用於複雜推理、程式撰寫與長上下文專業工作的高階 Claude 模型。

anthropic取得 API Key >

GPT-5.6 Sol

Chat

一款高級 GPT-5.6 文字模型,適用於高要求的程式設計、推理與長篇代理工作。

OpenAI取得 API Key >

Kimi K3

Chat

一款適用於程式碼撰寫、寫作、分析與 agent 工作流程的長上下文推理模型。

moonshot取得 API Key >

GPT-5.6 Luna

Chat

一款平衡的 GPT-5.6 文字模型,適合日常程式撰寫、寫作與代理工作流程。

OpenAI取得 API Key >

最新文章

GPT-5.6 降價後:Luna 與 Terra 現在到底要多少錢?

2026-07-31

Invalid API Key:修正前先判讀 401 與 403

2026-07-31

修正 OpenRouter 429:供應商錯誤還是速率限制?

2026-07-31

DeepSeek V4 Flash vs GLM-5.2:0731 更新實測

2026-07-31
AIREITER

有問題?請聯絡我們
[email protected]

LLM

Gemini 3.6 FlashGemini 3.1 ProKimi K3Gemini 3 ProGemini 2.5 Pro

AI 影片

Kling 3.0 Motion ControlSora 2 ProKling 3.0 TurboSora 2Kling 3.0

AI 圖片

FLUX.2 ProGPT-Image 2Wan 2.7 Image ProGPT 4o ImageSeedream 5.0 Pro

部落格

查看全部 →

公司

隱私政策服務條款退款政策

© 2026 AIReiter。保留所有權利。