# 外部提号数据 API 方案评估 更新时间：2026-05-12 ## 1. 结论 项目的核心需求是“根据客户 Brief 自动找博主”，不是单纯抓取公开内容。因此外部方案优先级应该从“社媒原始采集 API”调整为“商业达人库 / 创作者搜索 API”。 本轮判断： - Just One API 是目前最接近“现成提号接口”的候选方案，尤其适合小红书蒲公英、抖音星图这类商业达人场景。 - TikHub 更适合做内容采样和验证，例如近 10 条笔记、评论、近期活跃度、风格判断，不适合单独承担完整提号。 - KOLRank 或同类企业达人库 API 更适合作为长期数据底座，用于账号信息补全、榜单、监测、回采、订阅和资源库刷新。 - 蒲公英、星图、花火等官方商业平台 API 适合报价、合作状态、订单和投后数据，不适合做全站找号主数据源。 推荐路线： > 本地资源库作为主资产，Just One 做外部商业达人召回，TikHub 做内容采样验证，KOLRank/同类数据商做长期数据底座，官方商业平台做报价和投后回填。 ## 2. 项目需求拆解 当前项目需要支持的“找博主”流程： 1. 解析客户 Brief，抽取平台、行业、关键词、预算、城市、粉丝画像、内容风格、排除项。 2. 从本地资源库和外部数据源生成候选博主池。 3. 对候选博主补全报价、粉丝量、地域、内容标签、粉丝画像、互动指标、近期内容表现。 4. 采样近 10 条内容，判断内容风格、商业浓度、近期活跃度、是否符合 Brief。 5. 融合历史合作、供应商关系、黑名单、客户反馈等本地沉淀数据。 6. AI 重排并输出内部复核版和客户推荐版名单。 难点集中在第 2-4 步：如果完全自研，需要分别封装小红书、抖音、B站等平台搜索、账号主页、内容列表、评论、商业报价、粉丝画像等能力，复杂度高且稳定性不确定。 ## 3. 候选外部方案定位 ### 3.1 Just One API 定位：商业达人搜索 / 蒲公英与星图类数据聚合。 适合承担： - 按关键词、粉丝区间、报价区间、达人性别、粉丝画像、内容标签搜索创作者。 - 获取达人报价、合作状态、商业标签、粉丝基础信息。 - 作为 Brief 到候选博主的第一层外部召回源。 不应承担： - 唯一最终排序。 - 完整内容风格判断。 - 评论正文 VOC 分析。 - 本地历史合作、客户偏好、供应商可信度判断。 注意：API key 属于敏感信息，只应通过环境变量或后端密钥管理配置，不能写入前端、文档或日志。 ### 3.2 TikHub 定位：社媒内容采样和验证 API。 适合承担： - 小红书笔记搜索、笔记详情、评论、用户作品列表。 - 抖音用户搜索、视频搜索、用户主页作品。 - B站视频、评论、用户内容采样。 - 对候选账号做近 10 条内容采样、风格判断、评论/VOC 验证、近期活跃度校验。 不应承担： - 完整商业提号引擎。 - 报价、合作状态、投放适配等商业字段的唯一来源。 ### 3.3 KOLRank / 同类企业达人库 API 定位：长期达人数据底座。 适合承担： - 多平台账号信息补全。 - 账号数据刷新、监测、回采、订阅。 - 榜单和历史表现数据。 - 本地资源库字段补齐与过期数据刷新。 不一定直接适合： - 按自然语言 Brief 一步生成最终名单。 - 近 10 条内容的精细风格判断。 ### 3.4 官方商业平台 API 包括小红书蒲公英、抖音星图、B站花火等。 适合承担： - 官方报价、合作状态、订单状态。 - 授权账号下的投后表现数据。 - 投放复盘和商业可投性校验。 不适合承担： - 全站关键词找博主。 - 任意账号近 10 条内容采样。 - 任意笔记评论正文采集。 - 全站 KOC/KOL 发现。 ## 4. Just One API 初步实测结论 本轮使用小红书蒲公英创作者搜索相关接口做了初步验证。密钥不记录在本文档中。 ### 4.1 DHA / 母婴类 Brief 可行度：A- 验证结果： - `keyword=DHA` 可召回约 3469 个候选。 - 增加女性达人筛选后，可召回约 2392 个候选。 - 返回字段包含达人名、userId、红书号、地域、图文报价、视频报价、最低报价、合作状态、个人标签、内容特征标签。 - 搜索结果里出现了符合预算和人设的账号，例如母婴、妈妈、萌娃、婴幼儿阶段相关标签账号，报价也能落在中腰部预算范围内。 说明： - 对“DHA、母婴、妈妈人设、预算约束、商业合作状态”这类 Brief，Just One 能提供有实际价值的候选池。 - 后续需要继续验证创作者详情、粉丝画像、笔记表现接口，确认是否能稳定覆盖女粉比例、年龄层、阅读中位、CPE、预估阅读单价等硬指标。 ### 4.2 Nest / 城市空间探店类 Brief 可行度：B 验证结果： - 城市探店类需求更依赖地域、同省不跨区、线下到店意愿、空间/家居/生活方式内容匹配。 - Just One 搜索结果中有地域字段，但是否支持严格城市筛选仍需进一步验证。 - 更现实的做法是“关键词召回 + location 后过滤 + 本地资源库补充 + TikHub 内容采样验证”。 说明： - 这类需求不建议只依赖 Just One。 - 本地资源库里的历史合作、城市、供应商、报价可信度会更关键。 - TikHub 可用于核验账号近期是否真的在做探店、空间、家居、生活方式内容。 ### 4.3 实测限制 - 后续调用出现 `INSUFFICIENT BALANCE`，因此创作者详情、粉丝画像、笔记表现接口没有完整跑完。 - `contentTag=母婴,记录生活` 这类中文自由文本参数曾返回 400，推测内容标签需要使用供应商枚举值或字典值，不能直接传中文。 - 搜索结果列表中的部分 `fansCount` 返回 0，不能只依赖搜索列表判断粉丝量，需要调用详情或画像接口补齐。 ## 5. 推荐系统架构 建议在项目中抽象统一的外部数据适配层，不让业务页面直接依赖某个供应商字段。 ```text Brief 解析 -> SearchCriteria 标准查询条件 -> 本地资源库召回 -> Just One CreatorSearchProvider 外部商业召回 -> TikHub ContentSamplingProvider 内容采样验证 -> KOLRank / 企业数据 API 账号数据补全 -> 官方商业平台报价和投后补充 -> NormalizeAdapter 统一字段 -> AI Scoring / Rerank -> 推荐名单导出 ``` 核心接口建议： - `CreatorSearchProvider`：根据关键词、平台、预算、粉丝、性别、地域、内容标签召回候选博主。 - `CreatorProfileProvider`：补全账号主页、粉丝数、地域、报价、合作状态、标签、粉丝画像。 - `ContentSamplingProvider`：获取近 10 条内容、标题、正文、互动、发布时间、评论样本。 - `CommercialDataProvider`：获取报价、合作状态、订单、投后指标。 - `NormalizeAdapter`：把不同供应商字段映射为项目统一的 `CandidateCreator`、`CreatorProfile`、`ContentSample`、`CommercialMetrics`。 - `ProviderHealthMonitor`：记录接口余额、错误率、限流、字段缺失率、数据更新时间。 ## 6. 统一数据模型建议 ### CandidateCreator - `platform`：平台，如 xiaohongshu、douyin、bilibili。 - `externalProvider`：来源，如 local、justone、tikhub、kolrank。 - `platformUserId`：平台用户 ID。 - `displayName`：账号名。 - `profileUrl`：主页链接。 - `location`：地域。 - `fansCount`：粉丝数。 - `contentTags`：内容标签。 - `personaTags`：人设标签。 - `imagePrice`：图文报价。 - `videoPrice`：视频报价。 - `minPrice`：最低报价。 - `cooperationStatus`：合作状态。 - `sourceConfidence`：来源可信度。 ### CreatorProfile - `gender`：达人性别。 - `fanGenderDistribution`：粉丝性别分布。 - `fanAgeDistribution`：粉丝年龄分布。 - `medianReadCount`：阅读中位数。 - `medianEngagementCount`：互动中位数。 - `estimatedCpe`：预估 CPE。 - `estimatedReadUnitCost`：预估阅读单价。 - `recentPostCount`：近期发布量。 - `riskFlags`：风险标记。 ### ContentSample - `title`：标题。 - `contentText`：正文摘要。 - `publishTime`：发布时间。 - `readCount`：阅读。 - `likeCount`：点赞。 - `commentCount`：评论量。 - `collectCount`：收藏。 - `shareCount`：分享。 - `styleTags`：内容风格标签。 - `adIntensity`：商业浓度判断。 - `briefMatchReason`：匹配理由。 ## 7. PoC 验证计划 建议用 3-5 个真实 Brief 做供应商压测，不只看接口是否能返回数据，而是看最终候选名单是否可用。 ### 7.1 测试 Brief - DHA / 母婴：小红书，妈妈人设，中腰部预算，女性粉丝 25-44，关注阅读中位和 CPE。 - 城市空间探店：小红书或抖音，本地/同省，探店、家居、生活方式，关注到店可执行性。 - 护肤转化：抖音，预算 1w 内，测评/种草，关注历史爆文率和转化内容能力。 - B站成分党：B站，专业背书，长视频，关注内容深度和评论质量。 ### 7.2 验收指标 - 每个 Brief 至少返回需求数量 3 倍的候选池。 - 60%-70% 候选具备基本可复核价值，不是明显跑偏账号。 - 关键字段覆盖率达到可用水平：平台 ID、主页、地域、粉丝数、报价、内容标签、粉丝画像、互动中位。 - 内容采样可稳定返回近 10 条内容中的大部分。 - 供应商接口错误、余额、限流、字段缺失可被监控和降级。 - AI 重排后 Top 20 中至少 50% 能被媒介人工认为“可进入复核”。 ## 8. 接入优先级 第一阶段：本地资源库 + Just One - 目标：先验证“根据 Brief 找博主”的外部商业召回能力。 - 范围：小红书、抖音优先。 - 输出：候选池、基础报价、合作状态、标签、地域。 第二阶段：加入 TikHub - 目标：验证近 10 条内容采样、风格判断、评论/VOC、近期活跃度。 - 范围：对 Just One 和本地库召回的候选做二次验证。 - 输出：内容样本、风格标签、风险提示、Brief 匹配理由。 第三阶段：加入 KOLRank / 同类数据底座 - 目标：资源库长期刷新、账号数据补全、监测、榜单、订阅。 - 范围：多平台账号库。 - 输出：稳定的账号基础数据和历史表现。 第四阶段：加入官方商业平台 - 目标：报价可信度、订单状态、投后指标回填。 - 范围：已经授权或已投放账号。 - 输出：官方商业数据和复盘指标。 ## 9. 风险与注意事项 - 供应商数据不是最终真相，需要保留人工复核、来源展示和字段更新时间。 - 搜索接口返回结果可能受余额、限流、枚举参数、平台风控影响，需要做降级策略。 - 不同供应商字段含义可能不一致，例如报价口径、粉丝数更新时间、互动中位统计周期，需要在 `NormalizeAdapter` 里标注来源和口径。 - 内容标签、行业标签、粉丝画像等字段需要维护本地映射表，不能直接把供应商标签暴露给推荐逻辑。 - 密钥必须保存在后端环境变量或密钥管理服务中，前端只调用本项目后端代理接口。 - 对评论正文、用户内容采样等能力，需要评估平台条款、客户授权和数据合规边界。 ## 10. 建议决策 短期不建议投入大量精力自研各平台“找博主”底层 API。 更优选择是： 1. 将 Just One 作为外部商业达人召回的第一候选供应商。 2. 保留本地资源库作为最终可信资产和历史经验沉淀。 3. 用 TikHub 补内容采样和评论验证。 4. 用 AI 做 Brief 条件解析、字段融合、风险解释和重排，而不是直接相信外部 API 排序。 5. 用 3-5 个真实 Brief 完成 PoC 后，再决定是否采购或接入更多供应商。