software

Build in Public: 第6周. 尝试添加更多社交平台

发布: (2025年12月18日 GMT+8 23:05)
9 分钟阅读
原文: Dev.to

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原有的格式。

介绍

上周的主题是可观测性。我们添加了指标和仪表盘，以便能够看到系统实际在做什么，而不是仅凭直觉。

所以本周并不是从头开始发明新东西，而是要回答一个非常实际的问题：我们能否将相同的想法扩展到其他社交平台，而不导致整个系统崩溃？

简短回答： 部分可以。

TikTok：相似的问题，不同的形状

快速提醒：Wykra 的构建目标是回答一个非常人性化的问题：“你能帮我找到类似的创作者吗？” 只要描述你需要的网红，我们就去为你寻找。我们已经在 Instagram 上实现了这一功能。本周我们尝试将相同的模式复用到其他平台，首先是 TikTok。

从宏观上看，TikTok 搜索遵循与 Instagram 相同的故事线：

  1. 你发送一段自由文本请求，例如
    Find up to 15 public TikTok creators from Portugal who post about baking or sourdough bread。
  2. API 立即返回一个 task ID，实际工作在后台进行。
  3. 工作进程接手该任务，将你的句子转换为结构化搜索参数，运行一个 Bright Data 数据集爬虫，用 LLM 为发现的个人资料打分，过滤掉无用的，然后把所有结果存储起来，稍后你可以通过 /tasks/:id 获取。

步骤 1 – “输入 vibe，输出 JSON”

我们把原始查询发送给 LLM，要求它提取一个小的 context object（上下文对象）：

  • 细分领域 / 主题
  • 位置（使用标准化的国家代码）
  • 可选的目标创作者数量
  • 几个可以直接放进 TikTok 搜索框的简短短语

如果模型连类别都无法达成一致，我们就直接停止，而不是假装知道该搜索什么。上下文准备好后，我们会生成最多三个搜索词，选择一个国家（从上下文中获取，若没有则默认 US），然后继续。

步骤 2 – 搜索与 Instagram 的区别

在 Instagram 中，我们必须先使用 Perplexity 发现个人资料，然后再进行丰富。TikTok 由于在数据集中提供了合适的关键词搜索，可以跳过这一步。

对于每个搜索词，我们：

  1. 生成一个 TikTok 搜索 URL。
  2. 使用该 URL 和国家信息触发 Bright Data 的 TikTok 数据集。
  3. 轮询直到快照准备好，下载 JSON，然后按个人资料 URL 合并并去重所有个人资料。

整个过程可能需要一些时间，因此它作为一个长期运行的异步任务，存在于我们已经使用的通用 Task 系统中。

步骤 3 – LLM 打分

获取原始个人资料后，LLM 再次介入。对每个个人资料，我们提取基本信息（用户名、个人资料 URL、粉丝数、隐私标记、简介），将这些信息连同原始查询一起发送给模型，并请求：

  • 简短摘要
  • 质量评分（1 – 5）
  • 相关性百分比

任何低于 70 % 相关性 的条目都会被丢弃；高于该阈值的会保存其摘要和评分，并关联到任务中。平台不同，但模式保持不变：结构化上下文 → Bright Data → LLM 打分。

真实请求与回答示例

(为简洁起见省略——原内容包含具体的请求/响应对)

任务、指标以及一点纪律

所有这些都作为一个长期运行的后台作业附加在单个 task ID 上。任务会经历一个简单的生命周期：

pending → running → completed | failed

我们会存储任务记录以及与之关联的所有 TikTok 资料。当你请求 /tasks/:id 时，你会看到原始任务状态以及已分析的资料列表。这在调试时出奇地有帮助：如果 TikTok 为空但任务已完成，问题很可能出在爬取或分析环节，而不是队列。

由于我们上周加入了可观测性，几乎每一步都被包装成指标：

  • 创建、完成或失败的 TikTok 搜索任务数量
  • 队列延迟（任务在队列中等待的时间）
  • Bright Data 调用的时长及其错误率
  • LLM 调用的次数及其费用

YouTube：半小时的厄运旋转器

TikTok 是本周的成功案例。YouTube 提醒我们，并不是所有东西都能顺利接入 Wykra，无论架构在纸面上看得多么清晰。

我们尝试用一个非常温和的测试来接入 YouTube 数据集：

{
  "url": "https://www.youtube.com/results?search_query=sourdough+bread+new+york+",
  "country": "US",
  "transcription_language": ""
}

理论上，这应该表现得很像 TikTok：触发爬取、等待、下载 JSON，然后继续生活。实际上，经过约 30 分钟的旋转后，我们唯一得到的结果是：

{
  "error": "Crawler error: Unexpected token '(', \"(function \"... is not valid JSON",
  "error_code": "crawl_error"
}

所以目前 YouTube 并未真正接入 Wykra：数据集只会一直旋转，抛出爬虫 JSON 错误，且没有任何可存储或分析的有用信息。我们已经向 Bright Data 提交了工单，并将 YouTube 的接入工作推迟，直至问题解决。

Threads: Parameter Present, Logic Absent

Threads 也尝试了自己的实现。计划很简单：运行一次基于关键字的基础发现，大致如下：

{ "keyword": "technology" }

但返回的不是资料，而是：

{
  "error": "Parse error: Cannot read properties of null (reading 'require')",
  "error_code": "parse_error"
}

因此关键字参数存在，数据集也存在，但中间负责将两者连接的逻辑显然缺失。暂时我们把 Threads 当作 YouTube 处理：记录了该问题，并将 “proper Threads support” 移入后期计划。

LinkedIn: 同样的老故事

LinkedIn 与 Instagram 有类似的限制：没有一个好用的关键词搜索可以实现“帮我找出来自 Y 国、谈论 X 话题的人”。你 c

第6周总结

新的平台——TikTok、YouTube、Threads 和 LinkedIn——的表现与我们在 Instagram 上看到的不同。

  • TikTok：大体遵循已有的模式。
  • YouTube 与 Threads：模式被打破。
  • LinkedIn：需要自己的关键词驱动搜索层（例如 Perplexity/LLM 风格的叠加），而不能仅依赖数据集。

“如果我们想实现真正的关键词驱动发现，可能还需要在 LinkedIn 上再加装一个 Perplexity/LLM 风格的搜索层，而不仅仅依赖数据集。”

这将是下周要解决的问题，但现在它已经是一个明确的定义，而不是模糊的“LinkedIn 很奇怪”的感觉。

结论：
目前，拥有几条稳固的流程要好过拥有五条半成品的流程。

如果你想支持这个项目，⭐️ 给仓库加星 并在 X 上关注我——这真的很有帮助。

  • 仓库：
  • Twitter/X：
Back to Blog

相关文章

阅读更多 »