把一个功能从工具站里拆出来，我才意识到之前的 Vibe Coding 给我挖了多少坑

最近在重构一个小项目时，踩了一轮又一轮坑，想记录一下这次“反 Vibe Coding”的经历。

事情的起点是我前段时间做了一个在线硬件检测站（ 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 或做独立工具站的人一个参考。