flaqai App Store 应用机会分析
把关键词转成「用户任务 → 细分方向 → 相关应用 → 有证据的机会假设」。默认交付调研报告及采集数据；PRD、原型、广告投放不属于默认范围。
确定范围
沿用用户给出的关键词、市场、平台和输出语言。未指定时，声明采用美国区 us、iPhone、中文报告、当前采集日期，然后推进；只有缺失信息会显著改变决策时才询问。多个市场分别采集、分别分析，不能混合评分与价格。
从关键词发现应用
设计约 6–10 个检索词，覆盖原词、同义词、用户任务、相邻用途和已知品牌；每个词注明检索目的。不要只查品牌或只看头部。
优先使用本技能的 Python 标准库脚本，无需 API key：
python3 <skill目录>/scripts/collect_app_store.py \ --keyword "ai music" --term "ai song generator" --term "ai cover" \ --term "background music maker" --country us --limit 30 \ --output <报告目录>/data--term可重复；原关键词自动加入。--app-id可重复，用 lookup 补充搜索遗漏的已核实应用。需要评论时，使用--review-app-id ID（可重复）和--review-pages 1。字段、限制与降级方法见 数据采集说明。检查
manifest.json的失败项及apps.json。接口顺序只表示该请求中的位置，不代表 iPhone 搜索排名或榜单排名。结果为候选池，必须人工判断相关性。用
(storefront, trackId)去重；开发者、应用 ID、商店链接一起核对身份。名称相似不能证明官方关系或使用同一模型。将 Apple 官方分类（例如 Music、Entertainment）和 分析得到的细分方向（例如整曲生成、翻唱、视频配乐）分别记录。一个应用可属于多个方向。附入选理由、直接/相邻/替代竞品标记；显著不相关项也记录排除理由。
深挖竞品
选择约 5–8 个有代表性的应用，兼顾头部、同任务竞品、相邻工具与较小产品。每项保留商店、日期、应用 ID、开发者、官方分类、名称、评分及评分数、下载价/币种、版本/更新日期、核心用途、内购证据、来源链接。
- 到实时 App Store 页面补充内购及评论；到开发者官网核实产品身份、关键能力和授权信息。标出「开发者宣称」，实际体验过才能评价实际效果。
- 内购产品名、金额与周期按页面原样对应；周期未公开时标未知。多个同名 SKU 不代表当前新用户购买选项。下载免费不等于使用免费，网站价不等于 iOS 价。
- 比较矩阵使用「已确认 / 未提及 / 待核实 / 明确不支持」；不能把没找到功能当作不存在。价格、模型版本、授权政策需要当前证据。
- 评论尽量覆盖正负反馈。记录实际样本数、星级分布、日期范围、排序方式、评论 ID 和所属应用。按用户任务归纳痛点与正向价值；近期评论不代表全体用户，相同评论 ID 去重，评论数不能当作独立用户数。无法采到时明确标为缺失，不编写“常见抱怨”。
- 对矛盾证据保留来源差异：API 精确评分数与网页四舍五入、商店地区、页面抓取日期、网页与移动端功能都可能不同。
判断机会并交付
使用 分析与报告结构 输出 report.md，附数据文件的相对链接。先给决策结论，再给证据和竞争格局。
- 严格区分 观察事实、推断、待验证假设。评论和竞品收费能产生需求信号，但不能单独验证付费意愿。
- 不用评分数乘系数估算下载、收入、市场规模或增长；没有可靠商业数据就写未知。收入情景只能使用显式假设，不能标成竞品收入。
- 机会排序同时考虑用户问题证据、现有方案覆盖、获客切口、交付成本与验证难度。优先给有依据的 1–3 个方向；证据不足可以结论为暂不进入。
- 每个方向写明目标人群、切入任务、现有竞品/反证、最小验证实验、成功/停止条件及信心程度。不要把主观分数包装为测得的市场指标。
- 收尾检查：来源能定位、市场一致、采集失败已披露、相关性已筛选、功能缺失未臆测、数字可由数据复核。报告仅在静态数据上运行时，不得声称完成实时调研。
参考来源
流程理念参考 froessell/app-store-opportunity-research。本技能独立编写，聚焦关键词发现、数据溯源与竞品判断，不沿用原项目的下载/收入倍数估算或自动原型流程。