# 如何用 AI 分析 SaaS 競品：4 組可直接複製的提示詞

> 用 4 組以證據為先的 AI 提示詞分析 SaaS 競品評論、定價、更新紀錄和社群討論，避免把零散線索寫成確定結論。

Source: https://tomako.ai/zh-tw/blog/analyze-saas-competitors-with-ai
Updated: 2026-09-18

競品分析不一定要從昂貴工具開始。公開評論、定價頁、更新紀錄和社群討論，已經能提供不少實用線索。以下 4 組提示詞會幫你區分反覆訊號和個別抱怨，跨來源核對發現，再把它們整理成值得驗證的產品假設。

## 開始前，先守住幾條界線

使用者評論和論壇貼文適合用來發現問題，但不能代表整個市場。反覆出現的問題要和單一抱怨分開。重要發現至少要再用另一種來源核對，才能放進公開定位。

還有一條很重要：使用者的抱怨可以證明痛點存在，卻不能證明你的產品已經解決了這個痛點。

## 四個分析角度

| 分析角度 | 輸入資料 | 可以幫助你了解什麼 |
| --- | --- | --- |
| 評論分析 | 公開使用者評論 | 反覆出現的流程問題和個別抱怨 |
| 定價分析 | 目前的定價頁與方案限制 | 已寫明的功能門檻、用量限制和可比較的價格變化 |
| 更新紀錄分析 | 有日期的更新紀錄與目前的產品主張 | 公司在這段期間選擇公開哪些變化 |
| 社群用語 | 公開問題和相關討論 | 使用者如何用自己的話描述問題 |

這些資料只能提供線索，不能直接給出市場結論。把不同來源放在一起，看它們是否指向同一個問題。

## 1. 從使用者評論中找出操作阻力

二星和三星評論常會寫出較具體的使用問題，因為評論者通常真的試過產品。不過，這仍是一組有偏差的探索樣本，無法說明問題在所有客戶中有多普遍。

只處理你有權使用的內容。移除姓名和個人資料，保留來源連結供自己查核。把評論交給 AI 前，也要查看平台目前的使用條款。

### 提示詞 1：擷取評論證據

```markdown
你正在為一位獨立軟體開發者分析使用者評論。

只能分析下方提供的文字。不要使用你對這家公司或產品的外部知識。

競品名稱：[競品名稱]

評論：
"""
[貼上 15-25 則簡短評論摘錄。先移除個人資料，只貼評論文字，不要貼上整頁 HTML。]
"""

規則：
1. 只有至少兩則彼此獨立的評論提到同一個底層問題，才能標記為「反覆出現的問題」。
2. 只有一則評論提到的問題，標記為「個別線索」。
3. 只有評論者明確表示正在尋找、已經改用或考慮改用其他產品時，才能標記為「尋找替代產品的觸發點」。否則標記為「僅為操作阻力」。
4. 每項發現都要附上原文引用，以及提到該問題的評論數量。
5. 不要根據缺少的資訊推測使用者意圖、市場規模或產品影響。
6. 某部分沒有足夠證據時，寫「提供的文字證據不足」。

請輸出：

### 反覆出現的問題
每項包含：
- 簡明描述
- 提到該問題的獨立評論數量
- 一到兩段原文引用
- 原文提到的操作流程或使用情境

### 個別線索
列出只出現一次、但值得繼續調查的問題。不要把它們寫成趨勢。

### 明確的替代產品觸發點
只列出評論者明確表示正在尋找或已經選擇其他產品的情況。

### 比預期更難完成的工作
找出評論者認為混亂、緩慢、不穩定或步驟過多的流程。

### 證據界線
說明這組樣本無法證明什麼。
```

原文引用適合留在研究筆記中。若要把使用者用語放進公開文案，盡量改寫。只有具備必要脈絡和使用許可時，才直接引用原句。

## 2. 分析定價，但不要為了找機會而曲解它

定價頁可以顯示明確限制，但很容易被錯誤比較。月繳和年繳價格可能不同。有的產品按帳號席次收費，有的則按用量收費。地區和稅費也可能改變總價。

比較前，先記下頁面日期、幣別、地區、計費週期、計費單位和方案限制。

### 提示詞 2：定價與方案分析

```markdown
你正在分析 [競品名稱] 的公開定價和方案結構。

只能使用下方提供的資訊。沒有列出的功能，不要自行判斷它是包含或不包含。

定價記錄日期：[日期]
幣別和地區：[幣別 / 地區]
計費方式：[月繳、年繳、按帳號席次、按用量或其他]

定價資料：
"""
[貼上相關定價表、方案限制和超額費用。不要貼上整頁 HTML。]
"""

規則：
1. 只有計費週期和計費單位一致時，才能直接比較價格。
2. 資料允許時，同時列出可比方案之間的價差和漲幅百分比。
3. 分開說明固定費用、帳號席次費用、用量費用和超額費用。
4. 頁面沒有寫明的功能或限制，標記為「提供的定價資料未說明」。
5. 沒有使用者證據時，不要把某項限制寫成不公平、隨意或不適合使用者。
6. 無法完成某項比較時，寫「缺少可比較的資料」。

請輸出：

### 已寫明的功能門檻
列出明確限制在較高方案中的功能。

### 可比較的價格變化
每項包含：
- 比較的方案
- 計費單位
- 價格差額
- 可以計算時，列出漲幅百分比
- 增加的用量或功能

### 值得繼續調查的方案錯配
如果某項核心功能必須連同團隊管理或治理功能一起購買，請列出這些情況。除非使用者證據證明它確實造成問題，否則標記為「待驗證假設」。

### 入門付費方案的限制
只根據明確寫出的資訊製作表格。證據支援幾列就寫幾列，不要為了湊數補上缺漏項目。

### 證據界線
說明只看這張定價頁，無法得到哪些結論。
```

輸出結果可能指出一群值得繼續研究的使用者，但不能證明他們願意購買另一款產品。

## 3. 把更新紀錄當成公開公告，而不是內部資源報告

公開更新紀錄只能說明公司選擇公布了什麼。它不能完整反映研發投入、維護工作或內部優先順序。

你仍然可以把近期更新和產品目前的主張放在一起比較，但結論要保持克制，並記下樣本涵蓋的期間。

### 提示詞 3：比較更新紀錄與產品主張

```markdown
你正在比較 [競品名稱] 的公開產品主張和更新紀錄。

只能分析下方提供的文字。更新紀錄是一份經過選擇的公開資料，不是所有研發工作的清單。

目前的產品主張：
"""
[貼上 2-4 則目前首頁或產品頁的主張，包括功能承諾或定位說法。]
"""

更新紀錄樣本：
"""
[貼上有日期的更新內容。只貼更新文字，不要貼上整頁 HTML。]
"""

規則：
1. 寫明樣本中最早和最晚的日期。
2. 只描述這段期間公開宣布的內容。
3. 某項功能沒有出現在樣本中，不代表它遭到忽視、停止維護或放棄。統一寫「本次樣本未記錄」。
4. 每則更新只分配一個主要類別。確有需要時，可以再加一個次要類別。
5. 不要推測團隊規模、研發投入、產品路線優先順序或客戶採用情況。
6. 文字不足以支援比較時，寫「提供的文字證據不足」。

請輸出：

### 樣本範圍
說明分析了多少則記錄，以及涵蓋的日期範圍。

### 公開宣布的工作方向
按產品領域或使用流程分組，並統計這組樣本中的公告數量。

### 更新類型
替每則更新分配一個主要類別：
- 穩定性改善或 Bug 修正
- 流程改善
- 管理或治理功能
- 串接整合
- 面向使用者的新功能

### 與目前產品主張的關係
針對每項主張，標記相關工作為：
- 本次樣本有記錄
- 本次樣本未記錄
- 資訊過於模糊，無法分類

### 證據界線
說明公開更新紀錄無法證明什麼。
```

這項分析較適合幫你提出下一個問題，例如：產品近期更新後，某個流程是否仍然讓使用者覺得麻煩。不要把它寫成「競品已經停止投入某項功能」。

## 4. 把社群用語變成待驗證的定位

社群討論可以顯示使用者遇到問題時會怎麼描述。這些說法有助於理解用語和情境，但抱怨貼文本身不能證明市場需求，也不能證明你的產品成效。

### 提示詞 4：根據證據產生定位構想

```markdown
你要協助一位獨立軟體開發者，把社群研究整理成待驗證的定位構想。

只能使用下方提供的留言。不要使用你對競品、產品類別或開發者產品的外部知識。

社群留言：
"""
[貼上 5-10 則簡短的公開留言或問題。先移除個人資料，不要貼上整頁 HTML。]
"""

可選的產品證據：
"""
[貼上測試結果、展示觀察或已經核實的產品能力。沒有就留空。]
"""

規則：
1. 把使用者問題和開發者自己的產品主張分開。
2. 一則留言可以支持痛點，但不能證明開發者的產品已經解決了它。
3. 沒有證據支持的結果或比較，標記為「待驗證假設」。
4. 保留使用者採用的技術用語，但沒有許可或足夠脈絡時，不要把有辨識度的原句直接放進公開文案。
5. 留言只支持少量構想時，就減少輸出數量。
6. 沒有足夠發現時，寫「提供的文字證據不足」。

請輸出：

### 有證據支持的問題描述
最多列出三個問題。每項附上原文引用，並在原文有說明時寫出相關使用者或流程情境。

### 候選標題
最多寫三個簡明標題，並為每個標題標記：
- 有證據支持：痛點和承諾的產品結果都有證據
- 待驗證假設：產品結果還沒有獲得證明

### 比較假設
製作一張表，包含：
- 使用者工作
- 已觀察到的阻力
- 可能更簡單的做法
- 證據狀態

### 下一步要驗證的問題
列出目前阻礙開發者公開做出確定主張的最小問題集合。
```

## 一個簡短範例

下方四則評論是虛構範例，只用來示範這套方法如何運作，並不來自任何真實產品的使用者。

```text
評論 A：「工作區資料較多時，CSV 匯出會逾時。」
評論 B：「完整匯出會失敗，我們只能拆成幾批處理。」
評論 C：「我們升級方案只是為了 API 存取權，不是為了更多帳號席次。」
評論 D：「第一次同步前，設定流程要經過好幾個頁面。」
```

較克制的分析應該得到以下結果：

| 發現 | 狀態 | 證據 | 可以怎麼說 |
| --- | --- | --- | --- |
| 大量資料匯出可能失敗，或需要分批處理 | 反覆出現的訊號 | 評論 A 和 B | 這組樣本中有兩則評論提到大量資料匯出問題 |
| API 存取權可能和不需要的容量綁在一起 | 個別線索 | 評論 C | 一位評論者表示，升級是為了 API 存取權，而不是更多帳號席次 |
| 設定流程可能步驟過多 | 個別線索 | 評論 D | 一位評論者認為初次設定流程較長 |

這組樣本支持繼續調查匯出穩定性，但不支持「多數客戶都因為匯出故障而離開」這種說法。它也不能證明一款更簡單的競品就能贏得這些客戶。

下一步是從另一種來源尋找同類匯出問題，和遇到問題的使用者交談，再測試自己的產品能否穩定處理相同的資料量。完成這些查核後，才能把發現寫成產品承諾。

## 從線索走到可信的定位

四組提示詞只能產生一次研究快照。可以按照以下順序繼續：

```text
收集公開資料
    |
    v
擷取有來源支持的線索
    |
    v
區分反覆訊號和個別線索
    |
    v
用另一種來源核對重要發現
    |
    v
透過使用者訪談或產品測試驗證
    |
    v
寫出範圍明確的定位主張
    |
    v
在相關社群討論中提供協助
```

### 先選一個具體流程

不要因為評論裡出現很多抱怨，就把它們全部放進產品路線圖。先選一項對目標使用者真正重要的工作。

### 到其他來源中核對

至少再找一種來源確認同一個問題。如果使用者評論、社群問題、產品文件或支援資料都指向相似的阻力，這個假設更值得調查。不過，多種來源彼此印證，仍然不代表它能反映整個市場。

### 分開驗證問題與解法

詢問受影響的使用者：問題多久出現一次？他們目前怎麼避開？付出了什麼成本？接著再測試你的產品能否做到準備公開承諾的結果。痛點證據和產品成效證據是兩件事。

### 寫出最克制的真實主張

除非你有公平而且最新的比較，否則不要直接說「比某個競品更好」。較穩妥的寫法是說明具體工作、已經驗證的結果和適用對象。

### 先提供協助，再介紹產品

參與相關討論時，先回答問題或提供可行的解法。只有產品確實能幫上忙，而且社群允許推薦時，才提到自己的產品。

如果你正在決定把上市精力放在哪裡，可以先比較 [Product Hunt、Reddit 和 Hacker News](/zh-tw/blog/product-hunt-vs-reddit-vs-hacker-news) 的特點和限制。

這套流程跑順後，可以把它安排在固定的小段時間，避免競品研究打斷產品開發。[獨立開發者的每日 30 分鐘行銷流程](/zh-tw/blog/daily-marketing-routine-solo-founders) 提供一種安排方式。

## Tomako 可以怎麼協助

手動分析適合用來判斷哪些訊號真的有用。接下來更難的工作，是保留這些背景，並把經過篩選的線索整理成團隊可以審閱的成長工作。

[Tomako](https://tomako.ai) 是服務軟體公司的主動型 AI CMO。它把產品背景和經過篩選的市場訊號，整理成團隊可以審閱、執行並從結果中學習的成長工作。

Tomako 可以把選定的訊號整理成可審閱的機會，並準備草稿或後續工作。團隊仍然掌握策略、品牌判斷和重要的對外操作。

可以先用本文提示詞手動驗證這套方法。工作開始重複後，再[了解 Tomako](https://tomako.ai) 如何協助研究和準備工作。

## 最後檢查一次

公開發布根據競品資料寫成的主張前，請確認：

- 每項發現都能回到原始文字。
- 反覆訊號和個別線索已經分開。
- 已記錄樣本數量和日期範圍。
- 重要假設至少獲得另一種來源支持。
- 沒有把使用者痛點寫成自己產品成效的證明。
- 定價比較採用相同的計費週期和單位。
- 沒有把更新紀錄中缺少的內容當成功能被放棄的證據。
- 公開文案沒有超出證據範圍。

競品分析應該幫助你減少不確定性。證據不足時，正確的結果是提出更好的問題，而不是寫出更強的結論。