夜雨聆风01 昨天的问题，其实问错了
这篇文章其实不太像一篇正常的“产品介绍”。没看过的文章可以看昨天写的
找海外网红跟PR Media 太痛苦？我让 AI 帮我们写了一个 Google 结果抓取工具
更像一篇工作日记。
因为这两天我们不是先画一张漂亮的产品路线图，然后优雅地开发。
真实情况是，一会儿觉得“哇，这个好像真的能做”，一会儿又觉得“怎么又不对啊”。一会儿兴奋，一会儿怀疑。一会儿想继续改，一会儿又觉得是不是太复杂了。
尤其是中间有好几次，我其实已经有点急了。
第一次导出来的不是媒体真实链接，而是一堆 Google 搜索分页链接时，我当时的第一反应就是：这不对啊，我要这个干嘛？我们要开发 PR Media，又不是要收藏 Google 搜索页。
还有后来 Smartlead 那个问题。明明页面提示推送成功，HTTP 也是 200。结果打开后台，还是 0。
这种时候最难受。它不是彻底失败。彻底失败反而好办。它是看起来成功了，但结果没有成功。
所以这篇我想记录的，不只是“我们做了一个工具”。更是记录这个工具是怎么一点点被真实需求逼出来的。
昨天我们一开始想做的东西很小。
就是一个 Chrome 插件。
目标也很简单：把 Google 搜索结果批量导出来。
当时想得特别顺，输入关键词，导出前 100 条结果，拿到链接，搞定。
后来发现，哪有这么简单。
一开始我们导出来的是 Google 分页链接，比如 google.com/search?q=electric+bike+review&start=20。
但这个不是我们要的。
我们要的是搜索结果里真正的媒体 URL，比如 Cycling Weekly、BikeRadar、PCMag、NYTimes、CNET。
我们以为自己在做“Google 链接导出工具”。后来发现，我们真正要做的是 PR Blogger 资源开发工具。前者只是导链接，后者是帮团队找人。
02 插件先跑起来，但问题一个接一个
这里其实也有一个沟通磨合。
刚开始说“导出 Google 前 100、前 500 个结果”，听起来是一个很明确的需求。但真正做的时候才发现，这句话里面有两个完全不同的意思。
一种是生成 Google 搜索分页链接。另一种是把 Google 搜索结果里的真实媒体链接抓出来。
前者很容易，后者才有用。
这个过程挺典型的。很多自动化工具一开始做不准，不是因为技术不行，而是因为需求本身还没有被说清楚。
只有真的做出来，看一眼结果，才会立刻知道：不对，这不是我要的。
所以昨天有一段时间，我们就是在反复对齐：到底要导什么？导出来给谁用？拿到以后下一步是什么？
如果下一步是找编辑，那就必须是真实媒体文章链接。如果下一步是找邮箱，那就必须知道域名和作者。如果下一步要发邮件，那就必须能进 Smartlead。
需求不是一开始就写在 PRD 里。很多时候，是被实际工作逼出来的。
昨天的插件做出来后，第一个坑就是页面污染。
Google 页面里不是只有 Google 的结果。浏览器里装了 Semrush、SEOquake、Bing、Whois 这些插件后，导出的 CSV 里会混入很多乱七八糟的链接。
表面看导出了 56 条，实际很多不是媒体资源。
于是我们一点点过滤：去掉插件结果，只保留真实媒体、YouTube、Instagram、TikTok。
中间还遇到过“当前页抓取显示 0”的问题。明明页面上有结果，插件就是抓不到。
图 1：插件阶段，先解决真实结果导出和插件数据污染。
03 今天开始，不只做插件了
插件解决的是“当前浏览器页面”的问题。
但如果要给同事用、给客户演示、以后甚至做成工具，插件不是最好的形态。
所以今天我们把它改成网页工具。
一开始页面还叫 Google Top Results，后来越做越觉得名字不对。它不应该只是搜索结果工具，它应该是 PR Blogger Lead Engine。
04 额度不是无限的，先小批量跑通
一开始页面里有 Top 100、Top 300、Top 500、Top 1000。
看起来很厉害，但不适合测试。因为每跑一次 SERP API 都要消耗额度。
所以我们把测试数量压到 Top 10、Top 20、Top 30、Top 50。
图 3：先小批量验证，不一上来烧完额度。
做自动化，不是一上来把所有事情都自动化。先选一小段，真的跑通。
05 接 Serper.dev，拿真实媒体链接
继续用插件抓 Google，不适合做稳定中台。
所以我们开始接 SERP API。看了 SerpAPI、DataForSEO，最后先用了 Serper.dev，因为它有免费额度，适合 MVP。
接上以后，工具终于可以直接返回真实媒体、Blogger、Creator 链接。
然后又发现返回里有 Amazon、Walmart、BestBuy、Target、eBay 这种电商站。
这些不是我们要开发的媒体，所以又加了电商域名过滤。
06 大媒体要找具体编辑，不是总邮箱
做 PR Blogger 开发，最怕拿到的是媒体总邮箱。
contact@cnet.com 不是完全没用，但效率很低。
我们真正要找的是写这篇文章的人。这个人可能是 writer、editor、reviewer、contributor。
图 4：对于大媒体，我们要找文章作者 Profile，而不是媒体总邮箱。
07 Hunter + Snov.io：找到邮箱还不够
拿到媒体链接后，下一步就是找联系人邮箱。
我们接了 Hunter 和 Snov.io。先从文章页找，找不到去作者页，再找不到按域名查。
查的时候优先匹配 editor、PR、media、marketing、partnership、collaboration。
但邮箱这件事也有坑。Hunter 找到邮箱，不代表 Smartlead 一定接受。
这里还有一个很重要的判断：为什么不是只把邮箱导出来，放到表格里就完了？
因为如果只是表格，后面还是会回到老路。谁发了？谁没发？谁回复了？谁要二次跟进？谁已经拒绝？谁可以继续合作？这些状态如果靠人工记，很快就乱。
所以我们一开始就没有把它当成“找邮箱工具”。它更像线索进入邮件系统之前的中台。
前面负责找媒体、找编辑、找邮箱；后面负责进邮件系统、自动跟进、记录状态。这样 PR Blogger 开发才是闭环。
08 Smartlead：HTTP 200，但后台还是 0
今天最折磨人的部分，是 Smartlead。
这里也想说下，为什么邮件自动化这块我们先选 Smartlead。
一开始我也想过，要不要自己写一个发邮件系统。后来想想，没必要。因为发邮件表面看是“点发送”，真正麻烦的是邮箱预热、每日发送量、退信监控、统一收件箱、自动跟进、退订、黑名单、重复联系人。
这些如果从 0 做，会很重。Smartlead 本身就是做冷邮件自动化的，适合做后半段：导入联系人，挂到 Campaign，设置邮件 Sequence，控制发送节奏，看打开、回复、退信。
所以我们的判断是：前半段我们自己做，因为我们懂 PR Blogger 开发到底要什么样的媒体、什么样的编辑；后半段先接 Smartlead，因为发信和邮箱健康不要重复造轮子。
这个工具不是替代 Smartlead，而是把 Smartlead 前面的线索开发、联系人匹配、邮箱验证这一段补上。
这中间我们也磨合了很久。你可能看到文章里写“接 Smartlead API”，感觉就是一句话。但真实过程不是这样。
先是注册账号，然后找 API Key，然后看 Campaign ID 到底在哪里。你打开 Smartlead 页面问：这个链接里面的数字是不是 Campaign ID？我说是，大概率就是它。
然后填进去，点击推送。页面弹出成功。我们都以为这次稳了。
结果打开 Smartlead：还是 0。
这时候心情其实会有点崩。因为已经不是“功能还没做”，而是“功能看起来做了，但没有按我们想的方式工作”。
于是只能继续拆：是不是账号权限不够？是不是 Campaign 还没配置好？是不是邮箱不符合规则？是不是接口字段传错？是不是额度满了？是不是重复联系人被拦？
后来我们先确认手动 CSV 能不能导。手动能导，说明 Campaign 没坏。再确认 API 有没有收到。HTTP 200，说明接口通了。再看 Smartlead 返回字段，看到 upload_count，说明它收到了；看到 total_leads 是 0，说明导入阶段被拦了。
问题就是这样一点点被缩小的。工具开发很多时候不是“灵感一来就做好了”，而是你在一堆不确定里面，慢慢把问题从一团雾，拆成几个可以处理的小块。
我们接上 API 后，页面显示 HTTP 200，发送给 API 几十条。但打开 Smartlead 后台，Imported Leads Count 还是 0。
图 5：接口通了，但有效导入还是 0。
这种问题最烦，因为它不是完全失败。完全失败还好查，401 是 API Key，404 是 Campaign ID，500 是服务器。
但它是 200。说明 Smartlead 收到了，只是导入阶段没让它进。
09 不猜了，把 Smartlead 字段吐出来
于是我们开始改诊断弹窗。
不能只显示“Smartlead 未返回”。要把原始返回字段都展示出来。
图 6：看到 upload_count、invalid_email_count、is_lead_limit_exhausted 等字段后，问题才变清楚。
这一步之后我们知道，不是网站没推过去，也不是 Smartlead 没收到，而是 Smartlead 内部导入规则把它拦了。
10 新建 Campaign，继续缩小问题
后来我们重新建了一个 Campaign。
手动上传之前的 CSV，有 17 条成功进来了。
图 7：新 Campaign 手动上传 CSV，成功导入 17 条。
这说明 Smartlead 本身能导入，Campaign 也不是完全坏的。
但 API 推送还是 0。
图 8：API 推送仍然是 0，但 Smartlead 接收总数不是 0。
后来我们继续把 is_lead_limit_exhausted、lead_import_stopped_count、error 翻译成中文诊断。
图 9：出现额度相关字段后，继续把它显示成“额度是否耗尽”。
11 加最严格模式：只推送 valid 邮箱
原来默认推送 valid + accept_all + unknown。
日常开发可以，但排查 Smartlead 不够干净。所以加了“只推送 valid 邮箱”。
图 10：排查问题时，先只推送最干净的 valid 邮箱。
这里我也开始意识到一个问题：自动化不是“越多越好”。
不是说能抓 500 条，就一定比抓 50 条高级。也不是说能找到 100 个邮箱，就比找到 10 个邮箱有价值。
对 PR 开发来说，最重要的是：这 10 个邮箱是不是对的人，这个编辑是不是写过这个品类，这个媒体是不是适合品牌，这封邮件发出去会不会显得很冒昧。
如果自动化只是帮你把一堆脏数据更快地推进邮件系统，那不是提高效率，那是在更快地制造麻烦。
所以后来我们一直在加限制。只推送 valid，过滤电商域名，优先找作者 Profile，加内部访问码。这些看起来都是小按钮，但背后都是一次次“啊，这样不行”的结果。
12 发给同事用之前，必须加权限
后来又想到一个现实问题：如果这个网页被转发出去怎么办？
它后面接了 Serper、Hunter、Snov.io、Smartlead，每点一次都可能消耗额度。
所以今天加了内部访问码。
页面可以打开，但只要调用会消耗额度的接口，比如抓真实链接、识别作者、补邮箱、推 Smartlead，都必须输入内部访问码。
一个内部工具，如果没有权限限制，就不是工具，是风险。
13 现在第一版能做什么
输入关键词，自动扩展 PR、Blogger、Review、YouTube、Instagram、TikTok 开发词。
用 Serper.dev 抓真实搜索结果。
过滤 Amazon、Walmart、BestBuy 等电商域名。
识别文章作者和编辑 Profile。
用 Hunter / Snov.io 补邮箱。
按邮箱质量筛选，只推送 valid 邮箱。
推送到指定 Smartlead Campaign。
导入失败时，显示 Smartlead 返回的诊断字段。
加内部访问码，避免额度被乱用。
14 Meltwater 后面要接进去
还有一个后面一定要接进去的工具，是 Meltwater。
这个工具今天没有完全接进去，不是不想接，是因为 Meltwater 更像媒体数据库，不是普通 API 工具。
Hunter、Snov.io 更像邮箱查找。输入一个域名，帮你找到这个公司或者媒体下面可能存在的邮箱。
但 Meltwater 更适合做媒体和记者补充。比如 Google 能告诉我们哪些文章排在前面、哪些媒体写过这个主题、哪些 YouTube / TikTok / Instagram 内容正在出现。
但 Google 不一定告诉我们：这个媒体里面还有谁长期写 ebike？这个作者过去写过哪些智能硬件？这个编辑更偏 3C、家居、户外还是生活方式？这个记者有没有其他可联系信息？
这就是 Meltwater 后面可以补的地方。
第一层：用 Serper / Google 找公开搜索结果。
第二层：用 Meltwater 补记者库、媒体库、历史报道。
第三层：用 Hunter / Snov.io 补邮箱并验证。
第四层：用 Smartlead 做邮件跟进。
这样才像一个真正能用的开发系统。不是今天在 Google 搜，明天在 Meltwater 查，后天又复制到 Excel，然后再手动导入邮件软件。
15 这两天最大的感受
自动化不是一上来做一个完美系统。
自动化是你先把一个每天都很烦的动作拿出来，然后问：哪些是判断？哪些只是重复？哪些可以交给工具？哪些必须人来确认？
我们这次就是这样。
一开始只是想导 Google 搜索结果。后来发现要真实媒体链接。拿到链接后，发现要具体编辑。找到编辑后，发现要邮箱。找到邮箱后，发现要验证。能推送后，发现 Smartlead 不一定接收。能接收后，发现要权限保护。
每一步都是被真实业务推着往前走。
而且我觉得最有意思的是，这两天我们一直在互相推着这个工具往前走。
你不断从业务角度提问题：“这个导出来不是真实链接啊。”“我们要的是媒体里面的编辑，不是媒体总邮箱。”“这个能不能接 Hunter？”“能不能接 Smartlead？”“为什么显示成功，后台还是 0？”“后面能不能做后台？”
这些问题对开发来说都很关键。因为它们不是为了把界面做得更好看，而是为了让工具真的进入业务。
如果没有这些追问，这个东西可能就停在一个很漂亮、但没什么用的小页面。
正是因为你一直在问“那下一步呢”，它才从一个搜索工具，变成了一个开发中台的雏形。
这也是我这两天最大的感受之一：真正有价值的 AI 工具，不是一次生成完美答案，而是在真实工作里不断被使用、被质疑、被修正。越修，越接近业务。
16 下一步
下一步要做后台。
每个品牌一个项目。每个项目保存自己的关键词、媒体、编辑、邮箱、状态。每个同事有自己的账号权限。线索自动去重。Smartlead 推送前先校验。邮件状态能回传。
品牌项目库：每个品牌有自己的关键词、竞品、目标国家、目标渠道。
媒体线索库：保存媒体名、文章链接、作者、作者 Profile、邮箱、社媒链接、流量等级、来源渠道。
联系人验证库：Hunter、Snov.io、Meltwater 查到的信息统一保存，标记 valid、accept_all、unknown、not_found。
开发状态看板：New、Qualified、Sent、Replied、Negotiating、Partnered、Rejected。
邮件自动化：选中联系人后推到 Smartlead 对应 Campaign，后续把回复状态同步回来。
同事协作权限：谁能抓取、谁能补邮箱、谁能推送邮件、谁只能查看数据。
额度控制：限制每天关键词和邮箱查询数量，避免误点把 API 额度用完。
这就不是一个小工具了，而是一个真正的 PR Blogger Automation OS。
昨天还在折腾插件。
今天已经跑出一个自动化中台。
虽然中间一直出问题，但我反而觉得，这说明它是真的进入了业务。
只有进入业务的工具，才会暴露问题。
暴露问题，才有下一版。
今天先到这里。
继续改。
