Expensive Data

2026年10月9日

Code is cheap, show me the data!

为个人爱好做了一周的 Vibe Coding。它是一个很小众的东西，行业产品刚刚到万这个数量级。

项目的代码部分是比较轻的，重的是数据采集的部分。没有行业数据库，没有行业数据标准。只有两个开源的数据集，质量还不够好。因此，需要用这两个数据集作为种子并且通过搜索来找到更置信的数据。

置信度的保证是依赖多个信息源的交叉验证的。对每条数据，需要多次调用搜索和读网页。这是一个研究任务，需要 agent 来做调度/判断/决策。

最初的版本，Opus 给的方案是调用 Claude API 来做数据采集。测试的前5分钟就把10美元花完了。从这里开始，这个项目里 99% 的精力都用来做成本控制了。为此尝试了5个方案。

让数据采集发生在订阅额度里

结果就是，5小时的额度不能说是瞬间吧，10多分钟也打满了。仔细想一下就知道，订阅成本相比 API 不会是数量级的变化。应该先去看成本结构。

脚本代替搜索

让 Opus 解释了一下它的数据采集方案并做成本上的优化。Opus 发现大部分的都可以通过 Shopify 的接口直接拿到一个粗糙的结果。它写了一个脚本来替代之前的搜索方法。因为需要对结果进行校验，所以成本降了，但没有降到可以不考虑成本的程度。

本地模型代替线上付费模型

在我的 MacBook Pro M5 Max 36Gb 上装一个 Qwen27b 来跑。能跑但慢，大部分时间是10 token/s。同时模型本身不具备搜索能力，折腾了一下 modsearch，不够好用，但这个过程中，发现了 antigravity。

用 Antigravity 做数据采集 Agent

下载了 antigravity，发现在 modsearch 里直接用 agy cli 有权限问题，不想折腾。于是直接在 antigravity 里调用 Gemini 来完成 Opus 给它定义好的任务。太慢了，Google。对 Sonnet 来说5分钟的任务，Gemini 用了半个多小时。虽然它在我的 Google AI 订阅里，理论上我可以尽量用它的免费额度。但最终没法用这个方案，主要原因就是因为它慢。

慢，导致我没法实时让 Claude 来检查它的结果。我感觉数据采集和校验本身就是一个很难的任务，模型出问题是正常的。这也是为什么要用一个“第三方”模型来检验。但这个交互需要不断发生，负责采集的模型太慢了，而二者又无法直接通信，并且负责评价的模型还需要我不断的决策。

用速度和成本都更好的 DeepSeek 做数据采集 Agent

装了 DeepSeek Harness 用它接 DeepSeek V41 Flash 来做采集任务，快且便宜，目前来看，质量也不错。

项目还在进行中，我很期待！