# 我用AI做了一次完整的关键词研究

URL: https://caijiao.org/posts/187
Source: docs/posts/187.md
Description: 第一版拿到了三百多个词，看着很专业，但没有一个经得起追问：搜索量、竞争度、意图全是猜的。真正能用的是它做聚类和补长尾那一半；Omni Calculator 有一个词月搜索 5900 却带来月流量 61086 的例子。

第一版输出铺满了整个屏幕：三百多个词，按意图分成信息型、导航型、交易型，每个后面挂着月搜索量、竞争度、预计难度。

我做了一件很不礼貌的事——随机挑了十个词，去查这些数字从哪来。**没有一个对得上。** 它们是生成出来的，不是查询出来的。

## 它编不出来的是「事实」，不是「分析」

重做一遍之后，划出来的边界很清楚：**凡是能从语言本身推出来的，它都能做；凡是需要外部数据源的，它一律在编。**

搜索量是外部数据。竞争度是外部数据。某个词现在排在前面的十个页面是谁，也是外部数据。

但"这几个词表达的其实是同一个意图"这件事，是纯语言问题。给它一堆原始搜索词让它聚类，准确率比我手做高，而且快得多。

聚类结果里有一类特别值得看：本来以为是两个意图，被它归成了同一个。这类"疑似重复"往往意味着两个词该用同一个页面去打，而不是写两篇。

## 我最后留下的那一半工作

重做的时候我把它限制在三件事上，效果都不错。

**聚类。** 把两千多条长尾词按意图归成十几组。这一步人做要一下午，它几分钟，而且不会因为疲倦把最后一堆随便塞进某个组。

**补长尾。** 给一个种子词，让它往"动词 + 对象 + 限定条件"的方向展开。这里的好处是它见过大量真实搜索语句的写法，能补出我没想到的介词搭配和口语说法。展开时我会加一句限制：只生成动作性短语，不要"某某推荐""某某哪个好"这类词——前者对应能在页面里当场做完的事，后者对应一篇导购文，两者投入完全不同，混在一起会让后面的筛选失效。

**挑出意图模糊的词。** 让它给每个词标注"用户搜这个词的时候想要的结果形态是什么"——是一段解释、一个可以立刻用的页面、还是一个可以下载的东西。**答不上来的词直接删掉**，因为答案不明确意味着页面形式没法定。

## 为什么那些假数字看着那么可信

原因不神秘：**它们确实符合语言的分布**。某个工具的常见修饰搭配，模型见过成千上万次，它给出来的说法在语感上是对的。人也是这么猜的。

问题是，语感对和数字准完全是两件事。这也是最难察觉的地方——如果你对这个领域不熟，这些词看起来和真的一样。我这次差点直接拿去开工，救我的只有那十个随机抽查。

## 5900 怎么变成 61086

纠偏之后，判断一个词值不值得做，我看的是另一件东西。

Omni Calculator 公开过一个单页案例：`/other/test-grade` 这一页的主关键词月搜索量是 5900，而这个页面一个月的实际流量是 61086。

![Omni Calculator 计算器分类页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页的 Physics 分类挂着 546 个计算器，是 Chemistry 108 个的五倍。*

十倍的差。多出来的部分来自同一个意图下那一大批没人单独统计的长尾说法——同一个需求在不同人嘴里是不同的句子，而搜索引擎把它们都归到了这一个页面上。

这组数字改变了我的取舍标准：**不要看单个词的量，要看这个词背后那个意图一共能覆盖多少种说法。** 单看数字选出来的词，做出来的是一个孤岛页面；按意图选出来的，一个页面能吃下一整片。

## 验证这一步不能省

每个准备开工的词，我现在会做一次交叉：把这个词丢进搜索框，看排在前头的是什么形态的页面。如果前十条全是视频，那我要做的就不是文章；如果前十条全是能做这件事的页面，那说明这个意图的结果是"一个能用的东西"而不是一段解释。

还有一个我必查的：这个词的搜索结果页里广告密度高不高。广告多通常意味着商业意图强、自然结果的点击空间被压缩，对没有品牌的独立站很不友好。

这段属于基础操作，[Google Search Central](/google-search-central/) 的官方文档把常见误判列得很清楚。

工具词尤其容易犯这个错误——看起来像是要解释，实际上用户要的是输入框。这类页面的具体做法在[在线工具集合](/tool/)里有不少现成参照。

还有一个连带的技术判断：如果这个词对应的动作需要大量本地计算（图片处理、格式转码），它适不适合做成纯前端页面决定了能不能承诺"文件不上传"，这类判断可以参考 [WebAssembly](/webassembly/) 的能力边界。

## AI 补长尾有一个系统性偏差

它补出来的词偏书面。真实搜索里有大量口语说法、错拼、中英混搭，而它在补词的时候会不自觉地过滤掉这些——因为它倾向于给出"正确"的表达。

我后来额外加一条要求：故意生成一批带错拼和不规范说法的变体。这些词单个的量都不大，但加总起来可观，而且几乎没有竞争。

## 最后留下十二个词

三百个删到十二个。删掉的大部分是"说出来很好听，但没有对应页面形态"的那些。

这十二个的共同点是：用户搜它的时候脑子里已经有一个具体的动作，而且我能用一屏把这个动作做完。

十二个里后来又删了四个，原因和量无关：上线之后发现做法不对——用户要的是当场用完就走的东西，而我当时准备写的是教程式的页面。形态判断错，词选得再准也没用。

---

*Omni Calculator 的单页词量与流量数据来自其公开案例文章。*
