Market Recon · 市场与竞品可行性尽调

把一个产品/方向拿去对照真实市场做客观评审。目标不是鼓励也不是唱衰，是让判断落在可核查的事实上，并把结论说到能指导决策的颗粒度。

何时用

「评审一下这个项目/方向可不可行」「我不介意你泼冷水」
「查一下同赛道有谁」「竞品怎么做的、卖多少钱、有多少用户」
「这个 idea 能做吗」「要不要转方向」「抄某产品可行吗」

不适用：纯写代码、纯文案生成、已有明确专门 skill 的任务（先用那个）。

五条铁律（最重要）

先内后外：没读完项目自己的资料，不上网搜。先读 CLAUDE.md/AGENTS.md、docs/ 索引、handoff.md、关键代码，建立事实地基——否则分析会悬空，也会把已知信息当新发现。
要实测，不要印象：竞品必须落到可核查的数字（下载量 / MAU / 收入或 ARR / 定价 / 榜位 / 融资）。每个数字带来源链接。凭记忆得出的判断，显式标注「待核实」，不要伪装成事实。
核实陷阱，不被带偏（见下方清单）：同名产品、把供应商当对手、把没起量的产品当成功对标、把宣传参数当实测、数据过期。
分清三类问题：工程问题（能靠写代码/换方案解决）、市场问题（需求与获客，代码解决不了）、资本问题（要钱要用户量）。把每个死结归对类——这决定了「更努力写代码」有没有用。
给退路和止损门槛，不止给结论：结论要分维度、带证据、可反驳；再给「什么条件下停、什么条件下转、最省钱的验证动作是什么」。用户不介意被泼冷水，介意空泛。

流程

Step 1 · 内部事实地基

读项目自己的资料：定位、核心假设、当前进度、已知风险、技术现状。特别找出产品赖以成立的那一条核心假设（例：「用户愿意每天回来自拍」），后面所有分析围绕它证伪或证成。也读代码/handoff 找出当前卡在哪（技术死结往往比 PPT 更能说明可行性）。

Step 2 · 竞品实测（联网）

按赛道分层找竞品：直接对手 / 上游供应商 / 平台自带能力 / 你对标的那个产品。每家抓：下载量、MAU、收入或 ARR、定价、榜位、主体、融资、是否已转型/停运。

用可用的联网检索（web search / 网页抓取）。
好用的信源：App 数据站（Sensor Tower、data.ai、AppMagic、appstorespy 等）、公司/产品官网、行业媒体与访谈、增长案例站（如 adapty/相关博客）、以及目标市场的社媒讨论（小红书/推特/Reddit/B站）看真实口碑。
数据尽量取近 12 个月；标注采集日期。

Step 3 · 核实与反陷阱

对 Step 2 的每个关键结论过一遍陷阱清单，尤其核对你对标/要抄的那个产品到底成没成——这一条最容易错，且最致命。

Step 4 · 客观拷问（算账）

不停留在定性。至少算三样：

盈亏平衡：固定成本 ÷ 毛利率 ÷ ARPPU ÷ 付费率 ≈ 需要多少 MAU；把这个数和团队真实获客能力对照。
单位经济：单用户 API/云/内容成本 vs ARPU；CAC vs LTV/3。
核心假设分层拆：把「用户会用/会付费」拆成信噪比、可行动性、迁移成本等子问题，逐个查有没有支撑。再叠加：技术死结（是不是物理/工程上做不到，调参无解）、监管与合规成本（备案、资质、隐私法规、平台审核、律师费——常被按 0 估）、赛道结构（免费替代是否已很强、最强玩家是否已转 B 端或退出）。

Step 5 · 结论 · 门槛 · 退路

按输出模板给分维度可行性、止损门槛、退路排序，和「最高 ROI 的下一步」（通常是一个零/低成本的证伪实验，而不是继续开发）。

常见陷阱清单

| 陷阱 | 表现 | 反制 | |---|---|---| | 同名混淆 | 两个不同公司的同名/近名产品被当成一个 | 逐个核对开发者主体、App ID、上线时间 | | 把没起量的当成功对标 | 「某产品验证了付费/裂变」但其实下载量极低、频繁改名 | 查真实下载/评价数；频繁改名蹭 ASO = 没起量信号 | | 把供应商当对手 | 拿一个已转 B 端做 SDK/API 的玩家当 C 端竞品 | 分清 C 端产品 vs 能力供应商；供应商的存在往往证伪「该能力是壁垒」 | | 宣传即事实 | 用官网宣传的维度数/精度当真实能力 | 要 POC/实测/第三方评测，不采信参数表 | | 数据过期 | 引用两三年前的规模/政策 | 标采集日期；法规类查最新版本与生效日 | | 幸存者对标 | 只看跑通的那个，忽略同套路一堆死掉的 | 找同赛道的失败样本，看它们死在哪 | | 把市场问题当工程问题 | 用「再写三个月代码」去解「没人要」 | 归类到市场/资本问题，先做零成本证伪 |

输出模板

## 一、核心价值主张（用户赖以成立的那条假设是什么）
## 二、赛道竞品盘点（分层表格：直接对手/供应商/平台/对标；每格带来源）
## 三、对核心假设的拷问（分层拆 + 算账，逐条给证据）
## 四、可行性判断（分维度）
  - 技术可行性：… / 产品：… / 竞争：… / 合规：… / 商业：…（各一句结论 + 依据）
## 五、结论与建议
  - 止损门槛（什么条件停/转）
  - 退路排序（推荐→次选）
  - 最高 ROI 的下一步（通常是低成本证伪实验）
## Sources（所有引用的可点击链接）

反模式（不要做）

不要不读内部资料就开搜。
不要给没有来源的竞品数字。
不要只夸或只贬——要分维度、带证据、可反驳。
不要用「多写点代码」回应市场/资本类死结。
不要给完结论就停——一定给止损门槛和最省钱的下一步。
不要为了显得客观而堆砌无关信息；只留能改变决策的事实。

一句话自检

交付前问自己：「如果用户拿着这份分析去做决定，每一条结论我都能指出它的证据和来源吗？我有没有把最该先做的那个零成本验证告诉他？」