vibedollar.net

注册: 发送 6 位邮箱验证码 (无鉴权)。验证通过后由 vibe_verify 发放 API key。 两步注册防滥用: register 只发码, verify 才发 key。

用邮箱验证码完成注册: 发放 API key (Free 档, 不送余额)。

找回 API key 第 1 步: 给已注册邮箱发验证码 (无鉴权)。

找回 API key 第 2 步: 验证码验证后, 把 key 邮件发送到邮箱 (无鉴权)。

查余额/配额 (鉴权)。

邮件通知开关 (2026-08-20): 候选积压时是否发邮件提醒你领取。 默认开启 (有候选会收到 "有 N 个新客户正在等你" 邮件)。 enabled=false 停止此类邮件 (不影响其他邮件)。

标记线索结果 (北极星"有效线索率"数据源)。 outcome: valid (有效/行动) | invalid (无效) | contacted (已触达)

单条已交付线索详情 (回访率埋点: 仅详情级调用记回访, 防翻页虚高)。

已交付线索列表 (回访入口, 列表级不记回访防虚高)。 subscription_id (可选): 只返回该订阅的已交付线索 (工作台按订阅展示 — 2026-09-03 用户: 已交付区混入无关订阅记录); 0/缺省返回全部。

订阅一个产品监控 — 后台持续分析 Reddit, 线索自动积累, 随时 vibe_leads 秒回。 用户只给 product (如 "lawn care scheduling app"), 系统自动完成分析。 创建后立即开始, 之后每天持续运行。 enable_competitor_kw (可选, 默认 True): 开启时包含竞品对比信号 (如 "X alternative" 类帖, 供参考); 关闭时只给直接需求帖 (长尾痛点/求方案), 过滤竞品对比帖。 消耗现有配额: vibe_leads 领取线索时计入月配额。

领取订阅线索 — 秒回已积累的潜在客户线索。 领取后计入月配额。 系统持续跟踪, 线索自动积累, 随时领取。

v3.1 评分回传 (用户定稿): 对候选评分, relevant 才计费进交付。 scores 格式 (用户 agent 用自己的 LLM 评分后按此回传): [{"id": 候选id, "verdict": "relevant|irrelevant", "score": 0-100, "reason": "简短理由"}] - relevant: 计月配额 1 条 → 进 delivered_log (交付列表) - irrelevant: 记反馈回灌 → 该候选关联词降权 → 后续该词的弱候选减少, 推送向你的真实需求收敛 (评分质量 = 你的词表质量 — 认真评, 越推越准; 敷衍评或批量乱评会被一致性护栏识别并降权你的反馈影响, 等于浪费) - 候选本身免费 (vibe_leads 不扣费)。评分请先读 vibe_leads 返回的 body 正文 (不是只看 title) — 判断依据越完整, 你的词表越准。

v3.1 双向评分交互: 查看/回应你与系统的评分分歧 (标准对齐, 免费)。 无 respond_id: 返回该用户的开放分歧列表 (你评的 vs 系统参考评的不一致)。 respond_id + response: 提交你对某条分歧的说明 (标记已回应, 我们据此校准标准)。 分歧 = 你的评分与系统参考评分不一致 — 我们想理解你的标准, 这样推送会更符合你的判断 (类似客户回访)。回复免费。

列出我的所有产品订阅及线索积累状态。

取消产品订阅 (已积累的线索保留, 系统停止持续跟踪)。

回收列表 (2026-09-06 管道持久化): 列出被引擎判不相关 (rejected) 的候选 — 含引擎评分理由/分数, 供人工复核后 vibe_recover_lead 恢复。 subscription_id (可选): 只列该订阅; 0/缺省返回全部。 引擎 reason/score 取该候选最近一次 vibe_submit_score 回传 (scoring_feedback.user_reason/user_score)。 include_body (2026-09-06 A): 列表默认含完整正文 (历史兼容)。前端回收 列表传 false — 只回 220 字预览, 详情正文用 vibe_rejected_body 按需取 (500 条 × ≤40k 全文 = 单次十几 MB 传输 → 首拉 20s 卡顿根因)。

回收候选详情正文 (2026-09-06 A): 列表去正文后按需取单条全文。 lead_id: 回收列表条目 id (vibe_rejected 返回)。仅限归属自己的 rejected 候选; 非 rejected/非归属 → 拒绝。

恢复被误滤的候选 (2026-09-05 评分引擎误杀保护): rejected 状态的候选重新回到待评分 (sent) — 可用 vibe_submit_score 再评一次。仅限归属自己且状态为 rejected 的候选; recovered 后重新计入闸门 (sent 未处理 时锁下一批 — 与正常领取一致)。

订阅词表 (product_keywords): 当前用词 + 命中统计 + 来源标记。 status: all(默认) / active / monitor / removed / retire 命中统计: query_count(检索次数) / hit_count(匹配帖数) / n_pooled(入池数) / avg_score(降权分) / last_observed。 source: auto=系统生成 / manual=你手动添加 (受保护, 不会被自动优化替换)。 F1.5 (2026-09-06 误判反馈闭环 ③): 每词附加 n_delivered/n_valid/n_invalid/ n_contacted/n_rejected + invalid_sample(最近一条典型无效评语) — 溯源 delivered_log↔lead_pool (kw) — 扩词上下文可学习坏词形状。

添加词表条目 (2026-09-08 +source: 区分用户手动 vs 编排器自动生成)。 source (2026-09-08): manual(默认, 用户手动添加 — 受保护, 自动优化永不 替换) / auto (前端编排器/扩词生成 — 与后端 word_initializer 生成词同级, 未来表现差可被自动优化停用)。词已存在时复活: manual 请求强制接管为 manual; auto 请求保留原 source (不得把用户词改回 auto — 对齐 word_pool)。 kw_type: tail(长尾需求) / competitor(竞品对比) / comment(评论信号) / entity(实体核心名词)。添加后下次产品管线匹配即生效。

批量添加词表条目 (2026-09-06 A: 编排器初始词/扩词 + 营销 seed 逐条→1 次调用)。 逐条语义与 vibe_keyword_add 完全一致 (不重复计费/免费工具): kw 空或 >120 跳过; kw_type 白名单外 → tail; 已存在 (含曾 removed) 复活为 active (auto 请求保留原 source — 不把用户词改回 auto; manual 请求强制接管); word_queue 引用联动。单词失败不影响整批; 批内重复词只处理首个。 1 次 MCP 调用 = N 词 — 不逐个占用账号限流窗 (free 5/starter 10/pro 20 per 60s)。 keywords: [{"kw": "...", "kw_type": "entity|tail|competitor|comment"}, ...] 返回 {ok, added, total, results:[{kw, ok, status?, message?, error?}]}。

手动移除词表条目 (status→removed, 不再参与匹配)。 只对手动添加的词生效 — auto 词由自动优化器管理 (移除 auto 词会被 优化器当作普通弱词处理, 语义混乱; 如需停用请先确认其 source=manual)。 force=True (2026-09-08 前端编排器内部): 允许停用 auto 词 — 新架构下自动优化器调度已停, 编排器接管弱词停用职责; UI 手动删除 按钮不传 force, 保护语义不变。

订阅线索来源 sub 命中统计 (lead_pool 聚合, 只读)。 每 sub 显示: 累计候选数 (pooled=new+sent+delivered+rejected) 与 各状态计数 — 直观看出哪个 sub 贡献多/哪个全被拒。

订阅健康 (2026-09-08 前端编排器 / skill agent — 纯查询零 LLM)。 交付承诺驱动: 承诺日线 = 2×(配额/30) (用户定稿: 交付非线性, 2× 余量); 缺口 = 今日入池 < 日线 或 候选存量(new+sent) < 20 → agent 决定扩词补召回。 返回 quota/line/pooled_today/stock/gap/last_opt/collecting_ok + v2.1 delivered_month/delivered_total (交付目标检查 — 主判据 0 输入): delivered_month = 本月 delivered 累计 (vs quota 判达成度) delivered_total = 历史累计 collecting_ok = 今日 post_store 采集到帖 (区分"词面窄需扩词" vs "后端采集不足" — 采集不足时扩词无用, agent 不重复触发)。

记录前端扩词/优化事件到 optimize_events (2026-09-08 — 优化历史落点)。 前端编排器自动扩词应用后调用: 记 date/api_key/tier/product/product_id, 供订阅健康仪表展示"上次优化 · 增 N 停 M"。

手动编辑订阅的供需分析 (sd_json 四段) — 2026-09-06 用户定稿: 评分判定口径 = 用户可编辑的供需 (评分标准/输出格式仍固定)。 四段语义 (注入用户评分引擎 [SUPPLY/DEMAND STRUCTURE]): supply_side 供给侧 — 产品提供什么 demand_side 需求侧 — 目标人群画像 (判定相关性主依据) core_friction 核心摩擦 — 供需间低效 demand_pain 需求方痛点 (第一人称, 判定依据) 空字段保留原值 (部分更新); desc_fetch 只在 sd_json 为空时生成, 手动编辑后不会被后台覆盖。

池外定向搜索探测 (2026-09-07 领域层 agent — 纯数据零 LLM)。 agent 扩词前验证: 该 query 在这些 sub 的 ArcticShift 池外标题搜索能搜出什么 (是否值得扩词 / 发现池外有货 sub)。命中的帖 upsert 进 post_store (幂等, 丰富共享语料) — 不入 lead_pool (入池由 product_match 词驱动负责)。 与 sub_pull 互补: sub_pull 只拉池内 sub, 本工具搜池外。

语料供给状态快照 (2026-09-07 领域层 agent — 纯查询零 LLM)。 agent 判据③输入: 区分"词窄 (需扩词) / 语料边界窄 (池内 sub 增量到自然速率, 需 widen_pool) / 名录旧 (catalog 需月度刷新) / 采集停 (collecting_ok=false) / ArcticShift 限流中 (arctic.limited)"。 返回: sub_pool (active 数 + reserve 分层), 词搜 (last_run/pending), 近 7 天逐日 post_store 新帖 (语料增量趋势), catalog (total/last_updated), arctic (limited/retry_after — 读 DB 熔断 source_circuit, 跨进程共享), pipeline_recent (该订阅最近 5 轮 pipeline 的 matched/pooled — v2.1: 连续 matched=0 → 词在语料捞不到 (词耗尽/词错, agent 换词); corpus_today 暴跌 → 语料 intake 停 (等采集, 非词问题)。