用一个具体楔子产品做引流，验证「一句话 → 拉方案 → 自动装进项目 → 跑通任务」这条核心链路，并用一套指标体系判断我们做的是一个工具，还是一个平台。
01 · 我们在做什么
不推抽象的「平台 / 方案市场」，而是用一个有痛点的具体产品当楔子去打。MCP 与平台是藏在后面的交付管道。
核心机制：用户的 Claude（Claude Code）一次性安装平台 MCP 之后 —— 只要说一句「我要一套小红书自动化营销流程」，Claude 就通过 MCP 找到对应方案、自动拉取并装进项目、构建出自动化工作流跑通任务。
MCP = 唯一集成点 · 自然语言 = 搜索框 · Claude 自己 = 安装器。用户几乎零操作，摩擦低，激活天花板高。
验证这个具体方案（如小红书营销）有没有人要、能不能跑通、有没有价值。
跑通楔子的人，会不会自然扩展去拉第 2、第 3 个方案。这才是「平台」成立的证据。
02 · 为什么定指标
工具看激活 + 留存就够；平台必须额外看两件事 —— 用户跨方案扩展（需求侧网络）、社区产生新方案（供给侧网络）。
北极星
来的 N 个人里，跑通了 ≥1 个方案的人数占比（aha 率）。
| 类型 | 指标 | 防止它骗你 |
|---|---|---|
| 护栏 1 | 跨方案扩展率 — 拉 ≥2 个方案的用户占比 | 防止做出「一个小红书工具」却以为是平台 |
| 护栏 2 | 方案跑通成功率（按方案维度） | 防止靠运气跑通、掩盖质量问题 |
| 前导信号 | 用户主动求「还不存在的方案」的次数与内容 | 测供给侧苗头，并直接告诉你下一批做什么方案 |
03 · 用户走过的每一步
入口从「平台注册」塌缩成「冲着具体方案来」。两个红点是这次内测最该盯的流失坑。
04 · 完整指标清单
1 个北极星 + 2 个护栏 + 1 个前导信号，外加你新增的活跃 / 供给 / 渠道指标，全部并入。
| 指标 | 类型 | 看什么 / 目的 | 数据源 | 频率 |
|---|---|---|---|---|
| MCP 安装数 | 拉新 | 渠道有效性、获客基线 | MCP 激活日志 | 每日 |
| 安装 → 首拉率 | 激活 | 装了之后是否真开始用 | MCP 日志 | 每日 |
| 首拉 → 跑通率（aha） | 北极星 | 核心价值是否兑现 | MCP 日志 + 结果回传 | 每日 |
| 每日方案查询数 | 活跃 | 需求热度、用户在找什么 | MCP query 日志 | 每日 |
| 7 日方案下载数 | 活跃 | 使用强度 | MCP pull 日志 | 滚动 7 日 |
| 用户活跃度（DAU/WAU、人均查询/下载） | 活跃 | 是真需求还是一次性 | MCP 日志按用户聚合 | 每日 |
| 拉 ≥2 个方案用户占比 | 护栏 | 平台 vs 工具的需求侧证据 | MCP 日志按用户聚合 | 每日 |
| 方案跑通成功率（按方案） | 护栏 | 质量与信任基础 | 结果回传 | 每日 |
| 跑了什么技能 + 反馈是什么 | 质量/产品 | 报表核心、定位问题方案 | 执行日志 + 反馈群 | 实时/每日 |
| 上传过新方案的用户数 | 供给 | 平台能否自增长 | 平台上传日志 | 每日 |
| 7 日上传方案数 | 供给 | 供给侧网络苗头 | 上传日志 | 滚动 7 日 |
| 用户主动求新方案次数 | 前导 | 下一批做哪些方案 | MCP 未命中日志 + 反馈群 | 每日 |
| 邀请码 → 渠道归因 | 渠道 | 分渠道切片所有指标 | 邀请码绑定关系 | 每用户 |
| NPS | 传播 | 口碑、能否降 CAC | 期末问卷/访谈 | 期末 |
05 · 逐阶段执行
准备期建议放在 15 天之外先做掉，否则宣发当天用户涌进来接不住。每阶段带验证点，达成才算过。
BILI-xxxx），安装时绑定 user↔渠道06 · 数据从哪来
大量动作发生在用户本地的 Claude 里，平台唯一能稳定看到的是 MCP 调用日志 —— 所以埋点要埋在 MCP 调用层。
07 · 为下一轮分渠道做准备
本轮主打 B 站，但归因机制现在就建好、几乎零成本，下一轮多渠道直接复用。
| 环节 | 做法 |
|---|---|
| 发码 | 每个渠道一个邀请码前缀：BILI-xxx（B站）、WX-xxx（私域）、KOL-xxx（合作 UP） |
| 绑定 | 用户安装 / 激活 MCP 时填邀请码，后端记录 user_id ↔ channel |
| 切片 | 所有漏斗指标都能按渠道拆：哪个渠道来的人 aha 率高、扩展率高、留存好 |
| 下一轮 | 用本轮基线判断渠道用户画像与推广 ROI，决定加投哪个渠道 |
08 · 每天看什么
观察期每天一份，5 分钟扫完就知道哪里出问题。
| 板块 | 内容 |
|---|---|
| 漏斗当日 | 新增安装 / 首拉率 / aha 率 / 扩展率，及环比变化、最大流失点 |
| 活跃 | 当日查询数、7 日下载数、人均查询/下载、DAU |
| 跑了什么技能 | 技能名 × 调用次数 × 成功率，标红失败率高的方案 |
| 反馈 | 群内 + 回传反馈，按方案归类；阻断性问题置顶 |
| 供给信号 | 当日上传方案数、用户主动求新方案的原话清单 |
| 渠道切片 | 各邀请码渠道的安装与 aha 率对比 |
10 · 拿到指标的前提
不做这几件事，上面所有指标都是纸面的。按 50 人内测的量级，做 MVP 级别即可，别过度工程化。
| 要建的能力 | 具体做什么 | 支撑哪些指标 | MVP 做法 |
|---|---|---|---|
| ① MCP 服务端埋点 | 每次 query / pull / install 都落一条事件：user_id、邀请码、query 原文、命中方案、是否成功、时间戳 | 安装数、首拉率、查询数、下载数、匹配准确率 | 写一张 events 表，事件 append 进去即可 |
| ② 结果回传通道 | 方案模板内置「完成上报」一步，跑完让 Claude 回调 MCP 上报 success/fail + 技能名 | aha 率、跑通成功率、跑了什么技能 | 一个 report 接口 + 方案里加一行上报指令 |
| ③ 未命中日志 | query 没匹配到方案时，单独记原文 | 用户主动求新方案（前导信号） | 匹配为空时打一条 miss 日志 |
| ④ 邀请码系统 | 生成带渠道前缀的码，安装时绑定 user ↔ channel | 全部指标的渠道切片 | 一张码表 + 安装时写入关联 |
| ⑤ 上传方案通道 | 记录谁、何时上传了新方案 | 上传用户数、7 日上传数（供给） | 上传时打一条日志（本轮大概率≈0，正常） |
| ⑥ 看板 / 日报 | 把上面事件按天聚合成漏斗与活跃数 | 所有指标的呈现 | 先用 SQL 查 + 每天手工导一份 CSV，不必先做仪表盘 |
| ⑦ 反馈群记录 | 群内反馈按方案归档，主观体验补埋点盲区 | 反馈、NPS、求新方案 | 一个群 + 一个共享表手动记 |
一句话排序：① 埋点 和 ② 回传 是必须先做的（没有它们北极星就是黑的）；③④⑤ 是顺手加的日志，成本极低；⑥⑦ 用最土的办法（SQL + 表格）先跑，等下一轮人多了再做正式仪表盘。
11 · 具体到人
按 4 个角色拆，每个角色对应明确交付物。团队小可一人兼多角色；若是一个人，就按这个顺序自己切角色排期。
| 角色 | 负责事项 | 关键交付物 | 主要阶段 |
|---|---|---|---|
| 工程 / 后端 | MCP 埋点、结果回传、未命中日志、邀请码、上传通道、出 SQL 看板；扛并发与修阻断 bug | events 表 + report 接口 + 每日数据导出 | 阶段 0 / 全程 |
| 产品 / 方案 | 打磨旗舰楔子（小红书）到「即装即跑」、补齐 ≥10 个种子方案、写 onboarding 与回传指令 | 种子方案库 + 3 分钟跑通指南 | 阶段 0 重 |
| 运营 / 增长 | B 站物料与发布、招募、引导落地页、反馈群答疑、收集求新方案原话 | 视频 + 落地页 + 反馈归档表 | 阶段 1–2 重 |
| 数据 / 复盘 | 每日看漏斗出日报、盯流失点、组织中期访谈、写复盘报告（可由工程或运营兼） | 每日日报 + 《内测复盘报告》 | 阶段 2–3 重 |
典型一周节奏（观察期）：工程每天上午导数据 → 数据中午出日报 + 标流失点 → 运营下午盯反馈群 + 推用户做新手任务 → 产品当天修问题方案 → 工程当天修阻断 bug。每天一个闭环。
12 · 出问题怎么办
提前想好「如果 X，就 Y」，出状况时不慌、不临时拍脑袋。
| 情况 | 触发信号 | 应对 |
|---|---|---|
| 招不满 50 人 | D5 仍 < 30 人 | 追加私域/社群渠道、找垂类 UP 合作、延长招募 3–5 天；必要时降到「30 人也能得结论」 |
| MCP 装不上（坑 1） | 安装成功率 < 60% | 出一键安装脚本 + 录安装视频；群里 1v1 兜底；按失败的 OS/环境归类集中修 |
| 意图匹配不准（坑 2） | 查询命中率低、用户说「搜不到」 | 人工兜底回复正确方案、补关键词/别名、临时把旗舰方案置顶 |
| 方案跑不通（aha 低） | 跑通率 < 50% | 紧急修最高频方案；把宣发收窄到「最稳的那 1 个方案」，先保核心链路通 |
| 装了不用（激活低） | 安装多但首拉率低 | 群里发「新手任务」引导第一次使用、私聊 push、onboarding 里加默认示例 |
| 反馈处理不过来 | 群消息刷屏 | 反馈分级，只先修「阻断性」；体验性问题记录排期、不当场改 |
| B 站没流量 | 播放/点击远低于预期 | 换内容形式（实操演示 > 讲概念）、找 UP 合作、把流量导回私域慢慢转化 |
| 服务扛不住并发 | MCP 报错率升高 | 限流 + 分批放量（先放 20 人跑通再放剩下），别一次性全放 |
09 · 别踩的坑
产品硬门槛是「用户得有 Claude Code 且会用」，国内小众。B 站曝光大但精准用户可能少 —— 内容里要设「资格筛子」，落地页第一步就筛。
50 人样本小，本轮聚焦 1 个旗舰楔子，把人都灌进同一条链路。多楔子 A/B 留到下一轮。
50 人里几乎没人会真写新方案，上传数本轮大概率接近 0，属正常 —— 重点测「主动求新方案」这个前导信号。