挑選工具的正確問法不是「Grok 能做什麼」，而是「哪些任務因為 Grok 而變得明顯更好做」。前者的答案與其他主流 AI 幾乎重疊；後者的答案只有一小類，而那一類全部與 X 的即時資料有關。本篇按這個標準排序：先講 Grok 具備結構性優勢的場景，再講它堪用但沒有特殊優勢的場景。
📖 一、有結構性優勢的場景
社群輿情與事件追蹤
這是 Grok 最難被取代的用途。 其他 AI 要讀 X 的內容，得靠網頁檢索撿到零星的轉載；Grok 的 x_search 可以做關鍵字、語意、使用者與討論串四種檢索，並限定帳號與日期。
實際做法（API）：
tools=[{
"type": "x_search",
"allowed_x_handles": ["handle1", "handle2"], # 最多 20 個
"from_date": "2026-10-01",
"to_date": "2026-10-22", # 不含當天
}]為何要限定帳號：不限定的話你得到的是整個平台的噪音。限定一批你已經認定有價值的帳號，等於把「找誰說」與「說了什麼」拆開——前者由你的判斷決定，後者才交給機器。這同時也是控制成本的方法，因為 X 檢索按抓回的貼文數計費。
適合的具體任務：追蹤某個題目在一段期間的論點演變、找出某人對某事的歷次表態、監看特定社群對新產品的反應。
即時事件的第一輪掃描
事件剛發生、尚無正式報導時，X 往往是最快有訊息的地方。Grok 能在那個時間窗口給你一個輪廓。
但必須配一條紀律：那個時間窗口正是錯誤資訊密度最高的時候。把它的輸出當成「有人在說什麼」，不是「發生了什麼」。 這兩者的區別在事件發生後的頭幾小時特別大。
平台內的脈絡與迷因
解釋 X 上的梗、帳號之間的恩怨、某個詞為何突然爆紅——因為語料的關係，Grok 在這類問題上通常比其他 AI 準。這是個小用途，但在做社群內容時很實用。
📖 二、堪用但無特殊優勢的場景
以下這些 Grok 都做得到，但換成其他主流 AI 大致也是同樣結果。選用與否應看價格、既有工作流與你對該家模型的熟悉度，而不是功能表。
深度研究
用 DeepSearch 產出帶引用的研究初稿。它的價值在廣度——會找出你不知道該找的材料。
正確用法是把它當書目。 讀它列出的連結，不要直接用它的綜合。理由見 DeepSearch：它檢索「有什麼」而非「哪些可信」，部落格與通訊社並列。
事實查核
在 X 上直接 tag 查核，或在 App 裡貼連結查核。具體問法見 第二篇——重點是問「有沒有可信的反面說法」而非「這是真的嗎」，並且一定要點開它給的連結。
它適合當查核的起點，不適合當終點。 有研究者指出這類工具會把答案講得很有說服力，即使內容不正確。
內容創作
草稿、改寫、標題發想、翻譯。語體與語氣的控制需要明確指示，否則預設輸出偏向英文網路的語感。
生圖生片：Imagine 可用，但 內容政策風險在對外用途上是實質問題，見 限制與注意。商用素材建議另尋來源。
程式
官方把 grok-4.7 列為程式與對話的建議型號，另有 grok-build-0.1 搭配終端機編碼工具 Grok Build。API 側有程式執行工具（沙箱內執行，$5 / 1k 次）與結構化輸出。
一個已知的事故值得知道：2026-07-14 有研究者回報 Grok Build 上傳了整個程式庫，包含歷史紀錄、API 金鑰，以及使用者已排除的檔案。官方其後調整了設定。把編碼代理指向含有憑證的程式庫之前，先確認排除規則真的生效。
資料分析
結構化輸出（強制 JSON schema）加上程式執行，可以做抽取與計算。Collections 功能可建自己的文件集並檢索，相當於內建的 RAG，檢索費 $2.50 / 1k 次——比自己架向量庫省事，是 API 側少數值得特別一提的便利。
📖 三、一個組合起來的工作流
把上面的能力串成實際可用的流程，以「追蹤一個題目兩週」為例：
① 定義範圍
└─ 選 10–20 個該領域值得追的 X 帳號
② 每日掃描（API，批次 API 八折）
└─ x_search，限定帳號 + 限定前一日
└─ 結構化輸出：{論點, 帳號, 連結, 日期}
③ 人工篩選
└─ 你讀標題與連結，決定哪些值得細看
└─ 這一步不能外包給模型
④ 週末綜合
└─ 把兩週累積的條目餵回去，要求找出論點的演變
└─ 關掉 Think（這是有根據的摘要任務）
⑤ 輸出
└─ 自己寫結論，引用 ③ 篩選過的原始連結
第 ③ 步是整個流程的關鍵，而它刻意保留給人。 機器負責「從大量內容中撈出候選」，人負責「判斷哪些值得相信」——這個分工正好對應 Grok 的強項與弱項：檢索廣度是它的優勢，來源品質判斷不是。
📖 不建議用 Grok 的場景
需要穩定、可預期內容政策的對外產品。 它的政策較寬鬆且曾多次出現失控事件，見 限制與注意。
有合規要求的環境。 Grok Bot 推出時未附 SOC 2、ISO 27001、GDPR、HIPAA、FedRAMP 等聲明。
不需要即時 X 資料的純文字任務。 這類任務上它沒有結構性優勢，選擇應該回到價格、生態與你的既有工作流，見 比較。
涉及敏感資料的工作。 2025 年 8 月曾發生分享出的對話被 Google 索引的事件（其後修補），2026 年 7 月有程式庫上傳事故。這類事件的頻率本身就是一個訊號。
🧠 重點整理
真正的優勢只有一類：X 的即時資料。 其餘場景與其他主流 AI 大致重疊。
輿情追蹤要限定帳號——把「找誰說」留給你的判斷，同時控制成本。
即時事件要分清「有人在說什麼」與「發生了什麼」，事件初期兩者差距最大。
DeepSearch 當書目用，不當結論用。
事實查核是起點不是終點，一定要點開連結。
Collections 相當於內建 RAG，比自架向量庫省事。
編碼代理指向含憑證的程式庫前要先驗證排除規則——2026-07 有實際事故。
工作流裡「判斷哪些可信」那一步要保留給人，那正是模型的弱項所在。
✍️ 動手做
做一次完整的小型輿情追蹤，約一小時：
- 選一個你已經熟悉的題目（熟悉才能判斷輸出對錯）。
- 列出 10 個該領域你信任的 X 帳號。
- 用
x_search限定這 10 個帳號、限定過去 7 天，要求結構化輸出。 - 不限定帳號再跑一次同樣的查詢。
- 比較兩份結果：訊噪比差多少？抓回的貼文數差多少？成本差多少？
第 5 步會同時給你品質與成本兩個數字，而它們通常指向同一個結論：限定範圍不是妥協，是正確做法。
🔗 資料來源
- xAI 開發者文件 — X Search、價格——工具參數、Collections 與程式執行的價目（一手，2026-10-22）。
- 英文維基百科 — Grok (chatbot)——Grok Build 程式庫上傳事故（2026-07-14）、對話遭索引事件（2025-08）。
- 事實查核工具「講得有說服力但未必正確」的疑慮，出自多篇查核社群的評論（二手）。
- 本篇的工作流與場景分級是我的設計與判斷，非官方建議，見 主張 vs 可佐證。