事情的起点是我前段时间做了一个在线硬件检测站（ keyboard / mouse / screen / audio 一起的那种），本意很简单：
不想再为了测个外设去下载几百 MB 的驱动或 exe 。
https://hardwaretest.org/
当时被 “Vibe Coding” 洗脑得比较彻底，基本模式就是：
👉 我提需求，AI 搭架构、写代码、补 UI 。
确实快，但也埋下了不少雷。
为什么要把 Polling Rate 单独拆出来
上线一段时间后我发现一个现象：
比如单个功能鼠标 Polling Rate test
但它被放在一个“工具合集站”里，反而不利于理解，也不利于搜索
更关键的是：在 Google Search Console 里看到大量 URL 被判定为
Duplicate / canonicalized → 展示量接近 0
继续深挖后才发现真正的问题不在内容，而在架构。
原站点在用 AI 做 SEO 优化时，并没有跟上 Google 最新的 SEO 判定节奏：
多个页面的原始 HTML 高度同质
canonical 被统一指向首页
meta / description 复用
在 Google 眼里，本质上“只有一个页面存在”
这类问题代码是完全合法的，页面也能正常访问，但对搜索引擎来说几乎是致命的。
用「 claude code 的 SEO skill 」重做之后，差异非常明显
后来我干脆推翻了原有那套 AI 自动生成的 SEO 结构，重新来了一遍：
每个 URL 都有独立的 HTML 结构
canonical 明确、单一、不再偷懒
meta / description 按搜索意图人工设计
JSON-LD / FAQ 不再模板化堆叠
这一步完全不是“多写点代码”就能解决的，而是要理解 Google 当前是怎么判断页面价值的。
在按正确的 SEO 方法重构后，
GSC 里的重复页、被合并页数量出现了非常明显的变化，收录质量差异也肉眼可见。
所以我干脆做了一件更彻底的事
与其在一个工具站里修修补补，不如：
把 Polling Rate 这个需求完整拆出来
做成一个单用途、极简的网站
架构、SEO 、页面生成全部自己兜底，不再让 AI 自动决定
最终就是这个站：
👉 https://mousepollingratetest.com/
功能非常单一，只做一件事：
围绕一个明确的搜索意图，提供一个不需要安装、即开即用的检测工具。
一点体会
这轮折腾下来最大的感受是：
AI 能把开发效率拉高很多
产品边界、SEO 结构、长期演化路径，必须人来兜底
如果不 review ，坑只会在你以为“已经完成”的时候慢慢显现。
这次算是给自己交了一次学费，也顺便记录一下，给同样在折腾 Vibe Coding 或做独立工具站的人一个参考。
