requesthunt

requesthunt skill 概览

requesthunt 擅长什么

requesthunt skill 能把模糊的市场问题，转成基于真实用户反馈的需求研究，数据来源包括 Reddit、X 和 GitHub。它尤其适合做产品规划、功能优先级判断，以及 requesthunt for Competitive Analysis：当你需要的是有来源支撑的用户痛点，而不是偏主观的脑暴想法时，它会很有价值。

谁适合安装 requesthunt

这个 requesthunt skill 很适合创始人、PM、增长研究人员，以及需要回答以下问题的 AI agents：

• 竞品之间反复出现的抱怨到底有哪些？
• 哪些功能诉求是真正有用户拉力的？
• 一个品类里最紧迫的痛点是什么？
• 在动手做产品前，应该先比较哪些工具维度？

如果你已经明确了目标市场，但还需要从外部视角补充证据，那么 requesthunt 会比通用研究提示词更有用。

它真正解决的任务是什么

多数用户真正想要的，并不是抽象意义上的“social listening”。他们需要的是一份可直接使用的报告：反复出现的需求、代表性引语、平台分布，以及可用于 roadmap 或竞品定位的明确信号。requesthunt 正是围绕这个工作流设计的：先界定范围，再采集数据，接着检查请求，最后综合形成结论。

requesthunt 和普通 prompting 的差别

它最大的区别在于：你拿到的不是一个让 LLM 猜用户可能想要什么的过程，而是一套可重复执行、由 API 驱动脚本支撑的数据采集工作流。这个 skill 内置了几类聚焦的命令行工具，用于：

• 检查 API 使用量
• 发现 topics
• 触发实时抓取
• 扩展式搜索 requests
• 列出 request 记录以便审查

因此，requesthunt usage 相比让模型凭记忆“研究用户痛点”，可审计性更强。

采用前需要注意的约束

要让 requesthunt install 真正发挥作用，你首先需要一个 REQUESTHUNT_API_KEY，以及可运行 Python 的环境。这个 skill 的效果也高度依赖你的研究范围设定。如果 topic 过宽，输出会很嘈杂；如果 topic 过窄，又可能低估真实需求。

如何使用 requesthunt skill

安装环境与前置条件

仓库里的 SKILL.md 并没有提供一行式 package installer；更实际的安装方式是：准备好环境，然后直接跑脚本。你需要：

• 能访问 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

如果这一步失败，先把鉴权问题解决，再开始任何研究流程。

优先要读哪些文件

如果你想快速上手 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

为什么这个顺序重要：示例文件展示了预期的对话方式和报告结构，而脚本文件则能告诉你 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 明确了综合分析的目标，而不只是“抓点数据”。

推荐的 requesthunt 工作流

一个实用的 requesthunt usage 流程通常是：

1. 检查 API usage
2. 严格定义 scope
3. 对主 topic 触发一次 scrape
4. 用 expansion 搜索更具体的子问题
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。

做 Competitive Analysis 的最佳 workflow

对于 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 和搜索词

好的 topics 应该是“市场形态”的，而不是“功能形态”的。优先从这类 category 开始：

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

然后再搜索用户真实会抱怨的支持性短语，比如：

• code completion accuracy
• calendar booking conflicts
• kanban dependencies

附带的 scripts/get_topics.py 可以帮助你先查看可用 topics，再决定是否要自创 taxonomy。

示例文件能告诉你什么

examples/calendar-app-research.md 适合用来了解“先澄清再研究”的对话流程。examples/scheduling-tools-research-report.md 对安装决策更有参考价值，因为它直接展示了预期终点：一份带有优先级痛点、示例和可执行综合分析的报告。

如果这种报告格式和你的需求比较接近，那这个 skill 大概率是匹配的。

会明显影响输出质量的实用技巧

真正最重要的其实只有三点：

• 明确指定报告用途：roadmap、market map，还是 competitor teardown。
• 把“topic scrape”和“pain-point search”分开做，而不是指望一条查询全搞定。
• 在总结前先审查原始 requests；否则你很容易被那些好听但低频的问题带偏。

常见的安装与执行障碍

大多数采用问题其实都很基础：

• 缺少 REQUESTHUNT_API_KEY
• 一开始的 topic 设得太宽
• 跳过 platform selection
• 误以为 scrape 输出本身就足够做最终综合
• 没有先检查剩余 API quota

如果你预期会高频迭代，scripts/get_usage.py 应该成为日常 preflight 的一部分。

requesthunt skill 常见问题

requesthunt 比普通 research prompt 更好吗？

如果你的目标是基于来源证据的需求研究，那答案是肯定的。普通 prompt 可以帮你组织思路，但 requesthunt 额外提供了一层与真实反馈源绑定的数据采集能力。当你需要的是证据，而不是“看起来合理的假设”时，这点非常关键。

requesthunt skill 对新手友好吗？

中等偏友好。整体 workflow 不复杂，但你需要能接受环境变量配置和运行 Python 脚本。如果你觉得命令行 setup 有点重，那么只有在你会反复做市场研究或产品研究时，这个 skill 才更值得装。

什么情况下不该用 requesthunt？

当你需要以下能力时，不建议使用 requesthunt skill：

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

它最强的场景，是公开需求信号的捕捉和定性模式发现。

requesthunt 只适合产品团队吗？

不是。它也适合验证想法的创始人、做市场扫描的 agency，以及对比不同品类痛点的分析人员。但最清晰、最稳定的适配场景，仍然是产品研究和竞争研究。

requesthunt 可以替代客户访谈吗？

不能。更合适的理解方式是：它是一层快速的外部信号来源。你可以用它发现值得进一步验证的主题，但不要把它当成唯一事实依据。

requesthunt 支持哪些平台？

根据 skill 材料，它覆盖 Reddit、X 和 GitHub。当你既想看广泛讨论，又想看贴近产品的 request 线程时，这个组合很有用。

requesthunt 适合一次性的项目吗？

适合，前提是这个决策本身足够重要，能 justify 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” 就强得多。

把发现阶段和综合阶段拆开

先做一轮采集与检查，再做第二轮综合。很多用户会把这两件事压成一条指令，最后得到一份泛泛总结。更好的顺序是：

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

同时使用竞品词和问题词

requesthunt for Competitive Analysis 的一个常见失误，是过度依赖品牌提及。要提升召回率，应该把 vendor names 和 user-task phrases、frustration phrases 组合起来使用。

明确要求证据阈值

如果你希望报告更可信，可以要求 agent 区分：

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

这类简单要求，往往能明显提升最终决策质量。

扩展 workflow 之前先看脚本

如果你想改进 requesthunt usage，不要只根据文字说明猜参数；先检查脚本的 arguments。脚本文件才是支持参数和预期行为的最佳依据。

拿到第一版报告后继续迭代

把第一版报告当作地图，而不是最终判决。之后再继续细化：

• 补上遗漏的 competitors
• 用更窄的 subtopics 重跑
• 调整 platform emphasis
• 只看 recent signals
• 深挖某个高优先级投诉簇

为利益相关方优化输出格式

可以直接要求 agent 生成更利于决策的章节，比如：

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

这样 requesthunt guide 的输出就不只是“有意思的阅读材料”，而是能直接用于规划的成果。

警惕虚假的确定性

requesthunt 最大的质量风险，不是完全没数据，而是基于不完整数据做出过度自信的综合判断。如果原始证据看起来很薄，或者明显偏向某一个平台，那就应该在 prompt 和最终报告里明确写出来。