tihao-ai/docs/external-creator-sourcing-api-evaluation.md

外部提号数据 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. 推荐系统架构

建议在项目中抽象统一的外部数据适配层，不让业务页面直接依赖某个供应商字段。

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 后，再决定是否采购或接入更多供应商。