# AI能不能自动分析竞争对手网站？

URL: https://caijiao.org/posts/188
Source: docs/posts/188.md
Description: 把 HTML 丢进去能反推出路由形态、模板化程度和渲染方式，Omni Calculator 的「计算器抽象成配置、页面由模板生成」就是这么推出来的。但流量结构这类数据它推不出来，TinyWow 约 47% 直接访问只能靠第三方估算。

我把一个竞品站的首页 HTML、两个工具页 HTML，加上它 sitemap 里抽出来的四十个 URL 一起丢进去，问了三个问题：这些页面是逐个写出来的还是模板生成的、页面内容是否可以直出、它大概想覆盖什么范围的搜索意图。

回答得比我想的准，但有个非常清楚的失效边界。

## 能推断出来的技术事实，比想象中多

从 URL 规律上它能看出很多。四十个路径里如果三十八个是同一层级、命名方式高度一致，基本能断定**这些页面不是逐个手写的**，而是某种清单驱动的产物。它会翻 HTML 里的重复结构去验证：如果发现不同页面的正文块状 $\{ \}$ 结构完全一致、只有标题和几个词不同，模板化这件事就确认了。

还有一个它判得挺准的点：同一条 URL 在桌面和移动端 UA 下返回的 HTML 是否一致。不一致说明对方在服务端做了设备适配，而这个信息直接影响抓取——搜索引擎拿到的是哪一版，结果完全不同。

Omni Calculator 的做法正好是这个推断的结论那一侧——它把每个计算器抽象成一份配置（输入项、公式、单位、文案），页面由一个模板统一渲染。这个架构是可以在外部反推出来的：250 多个（实际上它的计算器数量更多）页面的一致性太高了，手写不可能这么稳。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页把 Math 做成了最大的入口，688 个计算器全在这一格后面。*

渲染方式也能看：**把 HTML 里的正文段落数量和 JavaScript 执行后的数量对比**，就能知道骨架是不是服务端给的。这段判断和[前端渲染与抓取](/javascript/)那一节的关系最直接——纯客户端渲染的站，抓下来的 HTML 里几乎没有正文。

## 推断到「架构决策」这一层最有价值

我把佩服的范围限定在这里：**它能反推的是一个工程决策，而不是一个商业判断。**

"这个站把每个工具抽成一份配置、用模板渲染"——这条结论有用，因为它告诉你对方打算用同一套东西覆盖多少个入口，以及它新增一个页面的边际成本有多低。

把这条结论翻译成自己的动作很直接：如果我打算在同类项目里竞争，页面量少于某个规模是完全没有意义的，因为对方的增量成本几乎为零。

这个层级的结论还有一个用法：**估算对手进入一个新领域的成本**。既然页面是配置驱动的，它多做一个品类的代价就几乎为零——这意味着跟它在同一个品类正面碰不是个好主意。

## 我把推断结果拿去核了一遍

反推出来的结论我挑了三条去查。

一是"页面由模板生成"。这条我在 URL 里替换参数验证通过——换一个参数之后返回的页面结构完全一样，只有几个字段变了。

二是"新增一个入口的边际成本极低"。这条没法从外部完全验证，只能从对方的页面增长速度侧面印证。

三是"页面骨架可以直出"。这条抓一次源码就能验，通常也是最确定的一条。

三条里两条能核、一条不能，这个比例基本代表了这类分析的可靠性：**推断往往是对的，但结论得自己拿证据坐实。**

## 推不出来的那部分，它不会说不知道

这是要最留心的地方。

流量、流量来源结构、用户停留、回访比例——这些它没有数据源。我问了，它给了数字，看上去很合理，全是编的。

TinyWow 是个好例子。它现在挂了 250 多个免费工具，第三方估算月访问 180 万到 230 万（2026 年上半年），而它的流量结构是**约 47% 直接访问、约 34% 来自搜索**。最后这组数据非常关键——近一半的人是自己敲域名进来的——但这类数字只有站长本人或者第三方估算工具能碰得到，从 HTML 里永远看不见。

外链数据也是它编得最多的部分。它给出的站点上线时间、作者背景、接过多少外链，全部不可信——这类信息没有任何公开入口可以大规模获取，模型只能编。

所以我的做法是分隔两种问题：**凡是能用 HTML 和 URL 回答的，交给它；凡是需要外部数据源的，一律去查第三方工具，并且标注是估算。**

## 站点配置层面能学的东西最实用

我给它加了一个任务：从 HTTP 响应头和静态资源命名推断对方的部署方式。`Cache-Control` 用的什么策略、静态资源有没有 hash 指纹、有没有 CDN 字段——这些都能从响应头里读出来，而且答案直接等价于一份可以抄的服务器配置清单，落地在 [nginx 静态服务](/nginx/)那一侧。

从 CDN 相关的字段还能看出它有没有前置缓存层。连着刷几次看 `Age` 和 `X-Cache` 的变化，能大致反推出它的命中率结构——这对判断对方承担大量页面的带宽成本很有用。

把拆出来的规律套到自己的站上：如果结论是"对方每个页面都能独立撑起一次搜索落点"，那自己的站也该按同样的粒度组织，[在线工具集合](/tool/)里讲的正是这个粒度问题。

跑得通的一套流程因此是：它能替你把可见的部分拆完，把 hidden 的部分明确交还给你去查。接受这个分工，一次分析的时间能从两天压到两三个小时。

---

*Omni Calculator 与 TinyWow 的架构判断基于其公开页面结构；TinyWow 流量结构与占比为 2026 年上半年第三方估算数据。*
