requesthunt

requesthunt skill 概覽

requesthunt 擅長解決什麼

requesthunt skill 能把模糊的市場問題，轉成以真實使用者回饋為基礎、可追溯證據的需求研究，資料來源涵蓋 Reddit、X 與 GitHub。它特別適合用在產品規劃、功能優先排序，以及 requesthunt for Competitive Analysis 這類情境：當你需要的是有來源依據的痛點訊號，而不是帶主觀色彩的腦力激盪。

哪些人適合安裝 requesthunt

這個 requesthunt skill 很適合創辦人、PM、成長研究人員，以及需要回答下列問題的 AI agent：

• 競品之間反覆出現的抱怨有哪些？
• 哪些功能需求真的有使用者拉力？
• 某個類別裡最急迫的痛點是什麼？
• 在動手做產品前，應該先比較各工具的哪些面向？

如果你已經知道目標市場是誰，但需要從外部視角取得證據，requesthunt 會比通用研究 prompt 更有用。

真正要完成的工作

使用者通常不是想做抽象的「社群聆聽」。他們要的是可直接使用的研究報告：重複出現的需求、代表性引言、平台分布，以及可用於 roadmap 或競品定位的具體訊號。requesthunt 就是圍繞這個流程設計：先定義範圍、再收集資料、接著檢視 requests，最後綜合整理出發現。

requesthunt 與一般 prompting 的差異

requesthunt 的核心差異，在於它提供的是可重複執行、由 API 驅動腳本支撐的資料蒐集流程，而不只是讓 LLM 猜測使用者可能想要什麼。這個 skill 內含聚焦的命令列工具，可用來：

• 檢查 API 使用量
• 探索 topics
• 觸發即時 scraping
• 透過 expansion 搜尋 requests
• 列出 request 紀錄供人工檢查

因此，相較於直接要求模型憑記憶「研究使用者痛點」，requesthunt usage 的過程更容易稽核與追溯。

導入前要注意的限制

在 requesthunt install 真正派上用場之前，你需要先備好 REQUESTHUNT_API_KEY，以及可執行 Python 的環境。這個 skill 的輸出品質也非常依賴你怎麼界定研究範圍：topic 太廣，結果會很雜；topic 太窄，則可能低估實際需求。

如何使用 requesthunt skill

安裝情境與先決條件

這個 repository 並沒有在 SKILL.md 中提供一行式套件安裝指令；實務上的設定方式，是先準備好環境，再搭配 scripts 使用。你需要：

• 能存取 skills/requesthunt 資料夾
• python3
• 從 https://requesthunt.com/settings/api 取得 RequestHunt API key

先把 key 設到 shell 設定中：

export REQUESTHUNT_API_KEY="your_api_key"

接著驗證連線是否正常：

cd skills/requesthunt
python3 scripts/get_usage.py

如果這一步失敗，先把 auth 問題排除，再進行任何研究流程。

優先要讀哪些檔案

如果你要快速上手 requesthunt guide，建議依照這個順序閱讀：

1. SKILL.md
2. examples/calendar-app-research.md
3. examples/scheduling-tools-research-report.md
4. scripts/get_usage.py
5. scripts/scrape_topic.py
6. scripts/search_requests.py
7. scripts/list_requests.py

這個順序很重要：前面的 examples 會讓你知道預期的對話方式與報告長相；後面的 scripts 則告訴你 API 實際接受哪些輸入。

requesthunt 需要你先提供哪些輸入

這個 skill 在你一開始就提供以下五項資訊時，效果最好：

• research goal
• target products or competitors
• platform preference
• time recency preference
• report purpose

弱的輸入像是：research calendar apps.

強的輸入像是：Analyze scheduling and booking tools, especially Cal.com and Calendly, across Reddit, X, and GitHub. Focus on user pain points, feature gaps, and complaints from the last 12 months for competitive analysis.

如何把模糊目標改寫成高品質的 requesthunt prompt

你可以用這種結構來寫 prompt：

Use requesthunt to research [category].
Focus on [competitors or adjacent products].
Prioritize [pain points / feature requests / complaints / unmet needs].
Use [reddit, x, github].
Bias toward [recent feedback / broad history].
Deliver a report with recurring themes, representative quotes, platform distribution, and implications for roadmap or positioning.

這樣做能明顯提升輸出品質，因為它不只縮小搜尋範圍，也替 agent 設定了明確的綜整目標，而不只是丟一個 scraping 任務。

建議的 requesthunt workflow

實務上好用的 requesthunt usage 流程通常是：

1. 檢查 API 使用量
2. 把研究範圍收斂清楚
3. 對主題觸發一次 scrape
4. 針對特定子問題做帶 expansion 的 search
5. 列出 requests 進行檢查
6. 人工或搭配模型做主題分群
7. 產出附帶 citations 或 quotes 的報告

這個順序可以降低一種很常見的失敗情況：最後報告看起來很完整，但實際上是建立在很薄弱的資料上。

你實際上會用到的核心指令

這個 skill 常用的指令如下：

python3 scripts/get_usage.py
python3 scripts/get_topics.py
python3 scripts/scrape_topic.py "ai-coding-assistant" --platforms reddit,x,github
python3 scripts/search_requests.py "code completion" --expand --limit 50
python3 scripts/list_requests.py --limit 20

實務上建議先用較廣的 topic 進行 scraping，再用更窄、更具體的詞做 search。

requesthunt for Competitive Analysis 的最佳流程

在做 requesthunt for Competitive Analysis 時，不要只用競品名稱搜尋。應該把以下幾類詞搭配使用：

• category term
• competitor names
• job-to-be-done phrases
• pain-point phrases

例如可以這樣規劃查詢：

• scheduling-tools
• Calendly
• Cal.com
• round robin scheduling
• rescheduling
• buffer time
• availability rules

這樣才能同時抓到明確提到品牌的抱怨，以及那些沒有指名廠商、但其實反映未被滿足需求的使用者描述。

如何選 topics 與 search terms

好的 topics 應該貼近市場類別，而不是直接從功能切入。可以先從這類 category 開始：

• ai-coding-assistant
• scheduling-tools
• project-management-tools

接著再搜尋使用者實際會抱怨的輔助詞，例如：

• code completion accuracy
• calendar booking conflicts
• kanban dependencies

內建的 scripts/get_topics.py 能幫你先看有哪些可用 topics，再決定是否要建立自己的分類方式。

範例檔案會告訴你什麼

如果你想看先澄清需求、再進入研究的對話流程，examples/calendar-app-research.md 很有參考價值。若你是在評估是否值得安裝，examples/scheduling-tools-research-report.md 更重要，因為它直接展示了預期終點：一份包含優先痛點、具體例子與可行綜整的研究報告。

如果那種報告格式正好接近你的需求，這個 skill 大概率就適合你。

真正會影響輸出品質的實務技巧

有三個技巧比其他細節都更關鍵：

• 明確指定報告用途：roadmap、market map，或 competitor teardown。
• 把「topic scrape」與「pain-point search」分開做，不要只靠一次 query。
• 在摘要前先檢查原始 requests；否則很容易被吸睛但低頻的問題帶偏。

常見的設定與執行阻礙

多數導入問題其實都很單純：

• 缺少 REQUESTHUNT_API_KEY
• 一開始選的 topic 太廣
• 跳過 platform selection
• 誤以為 scrape 輸出本身就足夠做最終綜整
• 沒有先確認剩餘 API quota

如果你預期會做高頻率迭代，scripts/get_usage.py 應該成為你的標準 preflight 步驟。

requesthunt skill 常見問題

requesthunt 真的比一般研究 prompt 更好嗎？

如果你要做的是有來源依據的需求研究，答案是肯定的。一般 prompt 可以協助你整理思路，但 requesthunt 多了一層直接連到真實回饋來源的蒐集機制。當你需要的是證據，而不是看似合理的假設，這個差異就很重要。

requesthunt skill 對新手友善嗎？

算是中等。整體 workflow 不複雜，但你至少要能接受 environment variables 與執行 Python scripts 這類操作。如果你覺得 command-line 設定偏重，這個 skill 仍可能值得用，前提是你會持續重複做市場或產品研究。

什麼情況不適合用 requesthunt？

當你需要以下能力時，不建議使用 requesthunt skill：

• first-party analytics
• statistically representative survey research
• deep financial benchmarking
• private customer support data analysis

它最強的地方是在公開需求訊號與質性模式探索。

requesthunt 只適合產品團隊嗎？

不是。它也很適合拿來做創業點子驗證的 founders、執行市場掃描的 agencies，以及比較不同類別痛點的 analysts。不過最明確、最典型的使用情境，仍然是產品研究與競品研究。

requesthunt 可以取代 customer interviews 嗎？

不行。更好的定位是把它當成快速的外部訊號層。你可以先用它找出值得驗證的主題，但不應把它當作唯一的真實來源。

requesthunt 支援哪些平台？

根據 skill 內容，它的目標平台是 Reddit、X 與 GitHub。當你希望同時看到較廣泛的討論，以及貼近產品需求的 request threads，這樣的組合很實用。

requesthunt 適合一次性的專案嗎？

可以，前提是這次決策的重要性高到值得做 setup。若只是一次性的輕量腦力激盪，一般 prompt 可能更快；但只要錯誤優先排序的代價不低，requesthunt install 就很容易說服自己投入。

如何改進 requesthunt skill

用更窄的研究框架驅動 requesthunt

想提升 requesthunt 結果，最快的方法就是降低模糊性。Research AI tools 很弱；Compare user complaints about AI coding assistants, especially code completion, context retention, and pricing friction 就強很多。

把 discovery 與 synthesis 分開

先做一輪收集與檢查，再做第二輪綜整。很多使用者會把兩件事壓成一條指令，最後只拿到很空泛的摘要。更好的流程是：

1. collect topic data
2. inspect requests
3. identify themes
4. write conclusions

同時使用 competitor 與 problem terms

requesthunt for Competitive Analysis 很常見的失誤，是過度依賴品牌名稱。若要提高召回率，應把 vendor names 和使用者任務描述、挫折描述一起搭配。

明確要求 evidence thresholds

如果你想讓報告更可信，可以要求 agent 清楚區分：

• repeated themes
• isolated anecdotes
• high-signal quotes
• uncertain findings

這個簡單要求，往往就能大幅提升決策品質。

擴充 workflow 前先讀 scripts

如果你想把 requesthunt usage 做得更好，請先看 script 的參數設計，不要只靠文字說明去猜。script 檔案才是目前支援哪些參數、預期行為是什麼的最佳來源。

第一版報告之後要再迭代

把第一份報告當成地圖，而不是定論。之後再進一步細化：

• 補上遺漏的 competitors
• 用更聚焦的 subtopics 重跑
• 更換 platform emphasis
• 只看 recent signals
• 深挖某一個高優先級的 complaint cluster

為利害關係人優化輸出格式

可以要求 agent 產出讓決策者更容易採取行動的段落，例如：

• top pain points
• evidence table
• representative quotes
• implications for roadmap
• opportunities by competitor weakness

這樣就能把 requesthunt guide 的輸出，從「有意思的閱讀材料」提升成「可拿來規劃的工作成果」。

留意過度自信的風險

requesthunt 最大的品質風險，不一定是資料不足，而是用片段資料做出過度自信的綜整。如果原始證據看起來太薄，或明顯偏向單一平台，請在 prompt 與最終報告中都明白寫出來。