公开构建：第9周。Wykra的形状
I’m happy to translate the article for you, but I’ll need the full text of the post (everything after the source line) in order to do so. Could you please paste the content you’d like translated? Once I have it, I’ll provide a Simplified‑Chinese version while keeping the source link, formatting, markdown, and any code blocks or URLs unchanged.
Build in public – 反思
Build in public 总体来说是一个有趣的实验。你会得到新的读者——其中一些甚至会留下来——你开始被邀请加入不同的社区，你的仓库自豪地获得了 EIGHT 颗星，某个时刻你不可避免地会尝试加入某个 LLM 相关的项目，只为获取免费额度，避免自己的钱花得太快。我老实说，我认为每个人至少应该尝试一次这种做法，即使只是为了亲身感受一下内部的真实感受。
与此同时，也有明显的缺点。 在全职工作的同时每周都写更新，需要一种比听起来更难以维持的承诺，因为现实生活总会插足：猫生病、工作紧急情况、自己生病，或者只是太累而无法产出连贯的内容。 过了一段时间后，这种感觉会不舒服地接近第二份工作，我不得不承认，我对写博客的投入可能没有最初想的那么坚定。 老实说，要让 build‑in‑public 系列持续超过几个月，需要么是有钱的叔叔，么是大公司的非常稳固的股票计划。
工作本身并没有停止。 事情一直在推进，系统一直在演进，某个时刻暂停下来，对我们实际构建的内容做一次完整的回顾是有意义的。 是的，我们错过了三次每周更新，但从项目当前的状态来看，我觉得结果相当不错。
Wykra 的功能概述（单段）
在深入细节之前，先简要回顾一下它是如何开始的。Wykra 最初是一个小型副项目，主要出于好玩而在一次挑战中创建，没有任何严肃的期望或长期计划，随后在不知不觉中演变成了现在的模样。
它实际的工作方式：你告诉它类似
“葡萄牙的素食烹饪创作者，Instagram/TikTok 上拥有 1 万至 5 万粉丝”
它就会在 Instagram 和 TikTok 上进行搜索，抓取找到的所有个人资料，将它们交给语言模型进行分析，并返回一个带有评分和简短解释的排名列表，说明每个个人资料为何会出现在该位置。如果你已经有具体的用户名，也可以直接提供，让它帮你判断该用户是否值得联系。
自最初的挑战帖以来，这已经发展成了 Dev.to 上的九篇系列文章。在继续之前，先快速看看这些文章的实际表现如何。
正如你所见，前两篇文章表现相当不错，之后的阅读量逐渐下降。此时的受众大多是已经明确了解自己在看什么并决定继续关注的人。
用户实际看到的内容
此时与其继续解释，不如直接展示一下现在的实际效果。
首先看到的是 wykra.io 的着陆页，它试图在大约五秒钟内说明这是什么东西。说实话，我更为我们竟然有一个着陆页而感到自豪，而不是我们甚至有一个用于邮件的域名。另外，请花点时间欣赏一下这非常好看的紫色 #422e63，说实话，它真的很棒。
我们还有一个由 Google Nano Banana 为我们生成的 logo；它基本上是以图形方式绘制的关联个人资料，这正是这个项目的核心。
之后，你可以通过 GitHub 注册，因为我们仍然需要一种方式来了解谁在使用它，并防止有人一次性抓取价值上百万美元的数据。登录后，你会进入一个聊天界面，界面会保留完整的历史记录，并且非常直白地告诉你搜索可能需要一段时间——在某些情况下最长可达 20 分钟。可惜没有哪个宇宙可以让这种发现只用五六秒就完成。这就是在把网页搜索、抓取和 LLM 调用串联起来时的工作方式。
最终，你会得到系统认为相关的个人资料列表，每个资料都有一个分数以及简短的解释，说明它为何入选。
如果你想核实某个特定个人资料是否真的有价值，还可以请求对该个人资料进行分析。
当你这样做时，你会快速了解该账号的实际内容：基本信息、受众、典型内容风格，以及一个简短的“优缺点”列表，帮助你决定是否要联系。
ic stats，简短的人类语言概述以及关于细分市场、参与度和整体质量的几个信号
它并不是要对任何人作出最终评判；它只是帮你省去打开十几个标签页、滚动二十分钟来判断一个资料是否可信的麻烦。
如果你不喜欢网页版，也可以直接在 Telegram 中使用完整功能。界面和流程完全相同——只是在 Telegram 里而不是浏览器中。
现在，技术细节
对于关心实际实现方式的朋友，这里是技术栈的简要概览。
后端
- 框架： NestJS + TypeScript
- 数据库： PostgreSQL
- 缓存 / 作业队列： Redis
- 爬取： Bright Data（负责 Instagram 与 TikTok 个人资料的获取）
- LLM 调用： LangChain + OpenRouter
- 主模型：Gemini
- 发现模型：带网页插件的 GPT
- 可观测性：
- 指标：Prometheus → 在 Grafana 中可视化
- 错误监控：Sentry
前端
- 框架： React 18 + TypeScript，使用 Vite 构建
- 状态管理： 纯 React Hook（不使用额外库）
- Telegram 集成： 使用 Telegram Web App SDK，使同一 UI 能在浏览器和 Telegram 内部运行，无需维护两个独立的应用。
喜欢图表的人
如果你更喜欢图片而不是段落，这里有一张当前 Wykra 连接方式的粗略示意图。它并不是要美观或最终定稿——只是一种查看各组件所在位置以及数据在系统中如何流动的方式。
从头到尾追踪一次单独请求，可以看到当有人在应用中输入消息时会发生什么：API 接收该消息，长时间运行的任务被推入队列，处理器执行相应操作，调用外部服务，结果被存储，并报告错误。
LLM 调用流程
All LLM calls → OpenRouter API
├─ Gemini 2.5 Flash (primary workhorse)
│ ├─ Profile analysis
│ ├─ Context extraction
│ └─ Chat routing
│
└─ GPT‑5.2 with web plugin
└─ Instagram URL discovery搜索流程
搜索创作者有点像跳舞，因为 Bright Data 可以抓取个人资料，但不允许直接搜索 Instagram。
- 通过网页搜索让 GPT 找到相关的个人资料 URL。
- 使用 Bright Data 抓取并分析这些个人资料。
TikTok
更简单，因为 Bright Data 支持直接搜索 TikTok。
- 将搜索查询发送给 Bright Data。
- 抓取并分析返回的个人资料。
那么，进展如何？
老实说？搜索功能还不够完美。有些结果很好，有些值得怀疑，甚至还有一些边缘情况会让系统表现得有点 странное。当你把网页发现、抓取和 LLM 分析拼接成一个流水线时，这种情况是可以预料的。
我们目前正在进行以下工作：
- 提高结果的相关性。
- 降低运营成本（发现创作者不应该像在烧钱一样）。
这些工作计划在下周完成。
Code: Everything lives here –