先寄出诊断报告的外呼，该怎么做

为什么“拜读了您最新的视频”会被当成垃圾邮件

外呼是由我先联系对方的销售，与对方主动来问的入站相反。过去几年在海外最流行的做法叫信号型外呼。信号指的是对方公司近期可观测到的变化：发布了新职位、拿到了融资、创始人上传了视频。侦测到信号，在邮件第一行提及它，就是这套做法的核心。

问题在于，侦测和提及都太容易自动化了。抓取 YouTube 标题、生成摘要、加上一句“最近的视频看得很有感触”，然后转入正题——这样的脚本半天就能写完。于是所有人寄的都一样。在收件人眼里，这句话已经不是“他看过我”的证据，而是“他跑了个工具”的证据。

AB180 负责 GTM（进入市场）的崔贤宗在访谈中直接说，这套打法已经死了。销售最不该做的事之一，就是做所有人都在做的动作，而提及信号恰恰属于此列。同一场访谈里，主持人说他每月收到近 300 封合作邮件，其中 98% 直接丢掉，因为格式全都一模一样。

那还剩下什么？容易自动化的东西已经无法拉开差距。需要的是仍然自动化、但制作本身确实要花力气的东西。这就是本文的主题。

改寄什么——对方今天就能用的文件

第一次接触寄出的东西经历了三个阶段。第一阶段是写一封好邮件。第二阶段是丢出有用的资料：行业报告、可参考的案例。第三阶段，也就是这里要谈的，是直接为那家公司做出一份成品并交过去。

崔贤宗演示的正是第三阶段。他面向海外订阅制 App 创始人，发现他们心里都压着同一个问题——先修哪里，于是把对方 App 的商店评论抓来分析成报告。以访谈中展示的画面为准，那份多邻国报告分析了 1,000 条评论，将其中 118 条归为流失信号，区分了 iOS 与 Android 的差异，梳理出八种反复出现的模式，并给出先动手的顺序。

在收件人看来，这不是广告。这是关于自己公司的内容，回答的是自己本来就在想的问题。所以会被读完。机制到此为止，没有别的。

目标有两个。一个当然是转化成会议。另一个是即使现在不买，等问题真正爆发时第一个想起我。崔贤宗认为后者概率高得多，并把销售的核心定义为“让客户遇到问题时来找我”。

所以设计报告时要留一手：不要全给。留下一段“这部分您现在就能确认，但这部分需要我们的数据才看得到”，对话的理由就出现了。只帮忙不留钩子的资料，收场就是一句谢谢。

评论从哪里来——App Store

从这里开始，就不是访谈里的内容了。视频只展示了成品报告，没有说数据是怎么收集的。以下是实际可用来做出同样东西的路径。

苹果为每个 App 公开了客户评论源。不需要开发者账号，不需要 API 密钥，也不需要登录。知道网址就能在浏览器里打开，返回格式是 JSON。

首先需要对方 App 的数字 ID。它就是 App Store 网页地址里 id 后面的数字，也可以直接用搜索 API 查到。

curl -s "https://itunes.apple.com/search?term=duolingo&country=kr&entity=software&limit=5" | jq -r '.results[] | [.trackId, .trackName] | @tsv'

APP=570060128
for p in $(seq 1 10); do
  curl -s "https://itunes.apple.com/kr/rss/customerreviews/page=$p/id=$APP/sortby=mostrecent/json" | jq -c '.feed.entry[]? | {rating: .["im:rating"].label, version: .["im:version"].label, title: .title.label, body: .content.label}'
done > reviews-kr.jsonl

wc -l reviews-kr.jsonl

500 这个上限从何而来

上面的循环只跑到 10 是有原因的。这个源每页给 50 条评论，而页码只到 10。请求第 11 页返回的不是 JSON 而是错误。所以单一商店、单一国家能拿到的上限就是 500 条。

访谈里的 1,000 条是怎么来的，也在这里得到解释。把网址里的 kr 换成 us 或 jp，就能另外拿到那个国家商店的 500 条。再加上安卓，总量还会高出不少。混用国家时只需注意一点：不同市场的抱怨类型不同，所以要把国家作为字段留在数据里，否则日后无法说出“付费不满集中在日本”这样的结论。

排序也可以换。把网址里的 sortby=mostrecent 改成 mosthelpful，被标记为有帮助最多的评论会排在前面。想看最新版本坏了什么就用时间排序，想看积压已久的不满就用有用度排序。

Google Play 这边怎么做

谷歌没有像苹果那样开放公开源，改用开源包。google-play-scraper 是事实标准，写作时的版本是 10.1.3。这里的 App ID 不是数字而是包名——Play 商店网址里 id= 后面的值（多邻国是 com.duolingo）。

每次调用最多返回 200 条，同时附带指向下一页的令牌。把令牌再传回去即可继续。下面的脚本循环五次，取 1,000 条。

npm init -y
npm i google-play-scraper

import gplay from "google-play-scraper";

const out = [];
let token;

for (let i = 0; i < 5; i++) {
  const r = await gplay.reviews({
    appId: "com.duolingo",
    lang: "ko",
    country: "kr",
    sort: gplay.sort.NEWEST,
    num: 200,
    nextPaginationToken: token,
  });
  out.push(...r.data);
  token = r.nextPaginationToken;
  if (!token) break;
}

for (const r of out) {
  console.log(JSON.stringify({ rating: r.score, version: r.version, body: r.text }));
}

node reviews-play.mjs > reviews-play.jsonl
wc -l reviews-play.jsonl

怎么把 500 条变成报告

原始评论堆本身没有价值，对方自己也能看到自己的评论。价值出现在分类。先把轴定好，全部按轴归类，再数每个轴有多少条、集中在哪个版本——这就是报告的骨架。

五个轴就够了。下面是适用于多数 App 产品的通用起点，可按对方所处品类替换一两个。

分类不由人来做

手工读完 500 条要花一天。那样这套方法就无法规模化，无法规模化就不叫外呼。分类交给模型，人只负责定义轴。

一行命令就够。下面这种写法把刚才生成的 JSONL 直接推入标准输入。

claude -p "以下是 App 评论的 JSONL。把每一行归入流失/功能/付费/缺陷/好评之一。只输出 CSV：分类,评分,版本,原文引用（30 字以内）。判断不清就标为其他，不要新增分类。" < reviews-kr.jsonl > classified.csv

cut -d, -f1 classified.csv | sort | uniq -c | sort -rn

报告里必须保留的东西——原文引用

要求在分类结果旁保留一段原文，是有理由的。只有摘要的报告无法验证，无法验证的文件不会被信任。“付费不满 41 条”远不如“付费不满 41 条，其中一条是这么写的”有力。

同时这也是防止编造的装置。模型可能生成看似合理却不存在的模式，强制附上原文引用会让它当场暴露。至于引用是否真的在源文件里，一次 grep 就能确认。

最终成品不必华丽。一页纸上有四样东西就够：看了多少条、各轴的条数与占比、与版本或国家相关的两三个显著模式、以及先动手的建议顺序。最后这一项，是收件人唯一能带走的可执行项。

邮件正文只改第一行

报告准备好后就写邮件。常见的错误是为每个对象重写整篇正文。时间和成本都涨，质量反而下降。崔贤宗给出的实务规则很简单：标题和问候之后的第一行按对象改，其余照搬反响最好的模板。

第一行的内容从报告里取。分析既然已经做完，“500 条评论里有 118 条是流失信号，其中一半集中在最近两个版本”这样的句子会自动写出来。这和抓来的视频标题不是一个层级的东西，因为那是对方能自己核对的自家数据。

崔贤宗的说法是，重要的不是对方是否真的被特别对待，而是有没有那种感觉。而与那套已死打法的分水岭在于，这里制造那种感觉的原料是真实数据。

为什么没有回信也能继续对话

把报告以链接寄出，并追踪是否被打开。用链接而不是附件的原因就在这里：能留下对方是否打开、看了几次的记录。

这样即使没有回信，下一步也有了。“看您好像打开过，这部分我可以再帮您”和毫无由头的催促邮件完全是两回事，因为它站在对方表现出兴趣这一事实之上。

同样的结构在销售之外也管用。访谈中提到的另一个例子是招募产品访谈对象：先列出近期重度使用产品的用户，第一行只填那个人的使用记录，然后请求十五分钟。原料从报告换成了使用记录，骨架完全一样。

想在这周做出一份来

想把一切都准备齐了再开始，就永远开始不了。跑通一次所需的最小流程如下。

第一，从想提案的公司里挑一家有 App 的。如果没有 App，换原料就是了——招聘启事、网站性能、搜索曝光状况，凡是从外部可观测的东西都能填进同一个位置。

第二，用上面的命令下载评论。光苹果就有 500 条，第一份足够了。到这里十分钟。

第三，按五个轴分类并统计条数。再十分钟。

第四，整理成一页纸：条数、两三个模式、建议顺序，再加几行原文引用。二十分钟。

第五，写邮件。第一行填刚数出来的数字，其余保持平时的模板。以链接寄出并确认打开情况。

完整跑通一份之后，往后只需更换对象。从那一刻起，这套做法才真正成为外呼。第一份耗时长是正常的——而且正因为它耗时，它现在还没被当成垃圾邮件。