从零挖掘多平台红人候选名单：建池、证据画像…

当需要从零构建红人名单、拓展新平台/新垂类、替换流失合作方或识别竞品合作达人时，跨平台挖掘候选创作者并做证据化筛查。

适用场景

解决思路

1. 定义搜索条件：捕获品牌、目标、受众定义、预算/粉丝层级、平台、互动率下限、地域/语言、排除项，以及必需/偏好参数表；若缺少任一必需条件，以 NEEDS_INPUT 停止，仅在用户需要帮助定义受众时才提供 audience-mapper。
2. 执行搜索：围绕话题标签、相似账号、竞品提及和平台原生发现机制展开；原始 handle/主页 URL 只能出现在第 2 步的临时查询块中，保存或交接前必须移除；记录可安全保存的批次，包含 creator_ref、身份状态、可解析时的不透明 handle_ref/source_ref、provider/tool、查询目的、observed_at、窗口和证据标签；若没有公开 handle/链接、用户导出、名册记录或实时搜索连接器可提供候选记录，则产出精确查询包与采集模板，返回 NEEDS_INPUT 并在点名创作者前停止。
3. 初步筛查：按粉丝区间、互动率、时效性、相关性和品牌安全过滤候选池；统计红旗（疑似假粉、争议、竞品排他、不活跃）；这些是发现信号，不是已验证的 STAR 失败或否决，缺乏支撑的适用证据在下游评分中保持 Unknown；按平台阅读线索参考 references/platform-vetting.md。
4. 构建红人画像：对每个合格创作者，先复用显式携带的不透明 creator_ref 或已验证 handle 链接的 creator-registry 聚合 ID；若都不存在，生成一个随机 creator-<UUIDv4> 并在本报告谱系中保持不变，绝不从 handle 或其他身份数据派生；仅当授权工件或已验证注册表链接可解析时才保存不透明 handle/证据 ref，否则保持 identity_status: unresolved，不创建隐藏定位映射，并要求后续会话重新提供原始定位符；然后填写画像（化名身份 ref、字段级指标与受众证据、内容、合作历史、联系路径 ref、证据完整性分诊状态）；冲突保留为并行行，仅在验证交叉链接后合并 provider 身份；将每个易变观察与当前 campaign 的 STAR evidence_window 比较：在窗口内为 current，窗口外为 stale，缺失窗口/日期或没有 STAR 窗口为 unknown；stale 或 unknown 的必需字段保持可见，成为 refresh_required，并强制 triage_state: NEEDS_REFRESH、ranking_status: NOT_RANKED 和 NEEDS_INPUT，绝不发明全局 TTL；不要输出分数、推荐层级或 STAR Suitability 结论；若需单个创作者的深度阅读与联系方式瀑布，使用 references/creator-dossier.md。
5. 汇总发现报告：将画像汇总为统计摘要、描述性平台/粉丝区间分布，以及三个非排名证据队列：READY_FOR_FIT、NEEDS_REFRESH 和 INELIGIBLE（按声明过滤条件）；在 typed Fit 之前不要推荐创作者组合、标注 Priority/Highly Recommended 或对候选做行动排名；若输入仅为两个原始定位符且条件/证据不完整，返回 NEEDS_INPUT 且不保存已审核池；部分检查点需要单独明确保存授权，必须标注 PARTIAL/NOT_VETTED，列出条件/证据缺口，且不含排名、分数、“top”标签或 fit-scorer 交接。
6. 补充洞察：记录垂类内容趋势、竞争格局，以及未来搜索的建议。
7. 内联返回发现报告；保存报告、缓存短名单、以及通过 registry-events.py 以 operation: propose 提交每个值得入册的创作者是三个独立操作，各自需要明确授权；无授权时提供合规路径且不写入任何内容；在已审核短名单存在后，将字段级证据连同 STAR evidence_window、freshness_status 和 refresh_required 列表交给 fit-scorer；若没有当前 STAR 窗口，将 freshness 标为 unknown 而非发明一个；fit-scorer 记录 S1-S10 证据读取，creator-content-auditor 单独决定已验证 STAR 否决并给出 gate 结论。
8. 证据规范化：仅在报告模板中规范化，不通过新的摄取层；对每个事实字段保留 provider/tool、source_ref、observed_at、测量窗口（或 not-supplied）以及一个标签：Measured、Calculated、Estimated、User-provided 或 Proxy；同一字段的冲突值保留为并行观察，不要平均、不要自动偏好最新、不要仅凭名称/handle 合并身份；跨 provider 身份只有在验证交叉链接或用户明确确认后才成为一个创作者。
9. 使用连接器占位符在可提升结果处：~~influencer database 用于批量发现、粉丝/互动指标、受众人口统计；~~social platform analytics 用于原生创作者市场数据、热门声音、相关账号；~~CRM 用于浮现可能的现有合作方匹配以供验证身份链接审查，绝不自动合并记录；~~audience overlap 用于估算创作者受众与品牌受众匹配度。
10. 无密钥候选卡元数据（oEmbed）：YouTube（https://www.youtube.com/oembed?url=<video-url>&format=json）、TikTok（https://www.tiktok.com/oembed?url=<post-url>）和 X（https://publish.twitter.com/oembed?url=<post-url>）无需密钥即可返回帖子标题、作者名/handle 和缩略图，足以临时解析候选并保留不透明的已验证 handle 证据 ref，而非手工复制身份数据；handle ref 与 creator_ref 保持分离：只有显式携带的上游 creator_ref 或已验证 creator-registry 身份链接才能解析聚合，否则创建新的随机不透明 ref 并保留身份缺口；仅元数据，无粉丝或互动指标，因此这些仍依赖 ~~influencer database 或手动导出——但 YouTube 除外，见下条。
11. 实测 YouTube 指标（免费密钥）：python3 "${CLAUDE_PLUGIN_ROOT}/scripts/connectors/youtube.py" channel @handle 返回真实展示的订阅数、总观看数和视频数，youtube.py videos @handle --limit 10 增加每视频观看/点赞/评论，将 YouTube 候选的画像行从 Estimated 升级为 Measured；免费 YOUTUBE_API_KEY（每天 10,000 单位；一次频道检查约 1–3 单位）；ToS 边界：审核具名短名单，不要构建批量创作者数据库——竞争性采集的配额扩展会被拒绝。

适用边界 · 注意事项

• 不适用于对已知短名单进行 STAR 评分或排名——应使用 fit-scorer。
• 当缺少必需搜索条件或没有候选来源（公开 handle/链接、用户导出、名册记录或实时搜索连接器）时，不要虚构候选，应返回 NEEDS_INPUT。
• 在 typed Fit 之前不要输出分数、推荐层级、Priority 标签或行动排名。