AI能不能自动生成网站内容矩阵？

一开始我让 AI “生成一个网站的内容矩阵”，拿到的是一张文章清单：三十个标题，按话题分组。

这东西不是矩阵，是一个列表。两者的区别在于列表是一次性的，矩阵是可以继续长出来的——你删掉一半再问它还能补回来，那才是矩阵。

先定两个轴，页面才会自己长出来

矩阵需要至少两个维度相乘。举个例子：一个格式转换站，横轴是输入格式（PDF、图片、文本、表格），纵轴是动作（压缩、拆分、转换、提取）。十六个格子，每个格子是一个真实的页面、一个真实的搜索意图。

举个我自己画过的表：一个图片工具站，横轴是输入格式（JPEG、PNG、WebP、HEIC），纵轴是动作（压缩、裁剪、转格式、去背景）。十六个格子，当时 HEIC 那一列几乎全空——后来证明这是整张表里最值钱的一块，因为其他三列的竞争早已饱和。

好处立刻出现：格子之间的空位是可见的。你不用绞尽脑汁想"还缺什么文章"，看表格就知道哪一格还空着。

这一步 AI 能帮上忙的是找维度。给它一堆已有的页面和它们的流量表现，让它反推"这些页面一共变了几个变量"，它有时能找到一个我没意识到的轴。

Omni Calculator 把这件事做到了极致

它 2026 年 6 月的估算月访问约 1429 万，覆盖 30 多种语言。按列表的思路撑起这种量级，得写几万篇文章。

Omni Calculator 首页顶部一行字就是定位：Your life in 3925 free calculators。

它的实际做法是把计算器本身变成数据：一个计算器就是一份配置，写着输入项、公式、单位、说明文案；页面由一个模板统一渲染。

这个抽象意味着增加一种语言、增加一个单位体系，都不需要新增页面。30 多种语言的成本是一次性的模板工作，不是三十倍的写作量。

配套的收益是：单个页面可以做得非常窄。它的 /other/test-grade 这一页，主关键词月搜索量 5900，月实际流量 61086——窄到一个具体的评分场景，但能吃下一整个意图的所有说法。这个做法还有一个不太明显的代价：模板一旦定型，页面的可塑性就下降了。想给某个单页加一段独有的内容，就得在模板里事先留一个出口。矩阵铺开之前要把这个出口设计好，否则后面每个特殊页面都得绕开模板，最后又退化成手写的那一套。

/other/test-grade 这类案例正是这种设计的产物：页面极窄，但正因为窄，它才能精确对应一个被搜的句子。窄粒度反而是矩阵能成立的前提。

让 AI 填格子，比让它写文章安全得多

同样是一百个格子，让它产出一百篇文章和让它产出一百份配置，风险完全不在一个量级。

配置是可以被校验的：字段类型对不对、单位在不在允许集合里、公式能不能算出一个合理的值。写个脚本全部跑一遍就有答案。

文章没法这么校验。一百篇里有多少是同一段话换了主语，肉眼没有可靠的判断办法，而这恰恰是最致命的那部分。

这个对比对我影响很大：尽量把内容压成数据，把数据交给 AI 生成，把主观判断留给自己。 能走这条路的项目，应该尽早把模板立起来。

AI 真正能干的活是生成配置，不是生成正文

想清楚模板这件事之后，分工就清楚了。

让它为一个新格子产出配置：这个格子的输入项有哪几个、单位用哪套、边界条件怎么限制、说明文案怎么写。这些是结构化的、可以被 schema 校验的，它的出错率比写散文低得多。

让它检查矩阵的空洞也很好用：把现有格子丢进去，问"还有哪些变量组合没被覆盖，但和现有页面的结构完全同构"。

判断哪些格子有真实需求，它不行

矩阵的代价在这里——笛卡尔积会长出大量语法上存在、需求上不存在的格子。

"马克杯转 Carousel"这种格子AI乐意填，但没有人在搜。判断依据是外部数据：这个词有没有量、排在前头的是什么。这一步必须回到真实的关键词数据上，而不是让它推测。

具体到 HEIC 那一列，“heic 转 jpg” 和 “苹果的照片怎么在电脑上打开” 这两种说法看着毫不相干，指向的却是同一个页面。让 AI 给候选、人来点头，这个组合比我独自做要准。

跑起来之后的两个工程问题

第一个是静态化。 矩阵意味着页面数量级跳一个台阶，几百上千个页面必须能被完整抓取。客户端路由渲染出来的空壳在这里会直接废掉整张矩阵。除了服务端渲染，静态托管那层的路由兜底和 canonical 也要注意，nginx 静态服务里 try_files 那部分是标配。

第二个更致命：每个格子必须有真内容。 如果十六个格子里的正文是同一段话换了个主语，那这个矩阵就是一次性的低投入产出——正好落在搜索质量指南里 Scaled Content Abuse 描述的那种模式上。格子越多，风险越大。

防这件事要靠"每个格子至少有一个不可替换的事实"：这个组合独有的边界条件、这个格式独有的坑、这组参数在极端输入下会怎样。图片、音视频、压缩这类本地处理的格子最容易做到，因为客户端方案本身就带着实测数据，相关的能力边界在 WebAssembly 里可以查到。整套矩阵该怎么按入口粒度组织，在线工具集合的拆解更完整。

十六个格子里最后值得做的通常只有五六个。剩下的先空着比硬填上要好。

Omni Calculator 访问量、语言覆盖与单页流量数据来自 2026 年 6 月第三方估算及其公开案例。