批量建站之后：同一改动出现 3 次就先进组件库
一、先说结论
我是 Hugozen。有一阵我一口气上了不少工具站，事后才发现一件很蠢的事：同一个 GEO 方面的缺口，在好几个站里各改了一次。
每次改动都不大，每次也都有理由。但把它们加在一起，说明这件事从一开始就该放进共用组件库，而不是在每个站里各补一遍。
我现在定的规则是：同一个改动影响 3 个或以上的站，先进组件库，再分发到各站。
这篇不重复旗舰里讲的协调者模型，那部分见 我怎么用一群 AI bot，一个人跑独立站矩阵。这里只写批量建站之后怎么控制维护成本。
二、为什么会改十几遍
回头看，原因不复杂。
1. 批量上线时，每个站都是「先上线再说」。 速度优先，所以每个站都从上一个站复制一份起步。复制出来的是一份快照，不是一个共享依赖。
2. 缺口是上线之后才发现的。 发现的时候，一批站已经各自有了一份拷贝。这时候每个站都要改一次，而且每次改的细节还会有点出入。
3. bot 很擅长「逐站修」。 这是 AI 协作的一个陷阱。派 worker 逐站改一遍，每一站都能很快交活、验收通过，所以痛感被压低了。人手改十几遍会觉得烦，会逼着你去抽象。bot 改十几遍不觉得烦，抽象就被一直拖后。
所以我现在的判断是：bot 越能干，越要靠规则逼自己去抽象。 成本不在改的那一次，而在后面每次都要再改十几遍，每个站还会慢慢长歪。
三、「三次规则」怎么用
规则本身很简单，用起来有几个细节。
- 第三次出现就动手。 第一次是个例，第二次是巧合，第三次基本就是模式。我不等到一批站才发现。
- 先入 kit，再改站。 顺序不能反。先在组件库里改好，再让各站升级过去。如果先逐站改，库里还是旧的，下一个新站又会带着旧缺口出生。
- 库里只放确实通用的东西。 站与站之间真正不同的部分，比如内容、定价页、各自的功能逻辑，不进库。我也踩过过度抽象的坑：为了凑通用，把参数堆得比直接写还麻烦。
- 升级要有出口。 每个站引入的版本要能看出来，出问题能回退。批量升级时，我会先挑一两个站验证，再铺开，不一把全推。
四、漏斗事件和统计口径也是同一类问题
这次复盘里还暴露了另一类「各站各写一份」：
- 漏斗事件名不统一。 各站按各自习惯起名，到汇总的时候对不上。事件名本来就该是库里的常量，不是每个站自己想。
- 统计只装了基础的页面浏览。 转化类事件只记在自家库里，第三方分析工具里看不到。结果是自家数据和分析工具的数字对不上，我还得先判断该信哪一边。
- 自测流量混进了数据。 后来的做法是给自测流量打上标记（UA 或 UTM），在分析时剔除。我也评估过在分析工具里做内部流量过滤，最后决定不做，原因是维护成本和收益不成比例。
这些全都符合同一个模式：每个站各写一份，写到第三个的时候就该进库了。
五、新页必须过小屏检查，不能只用 curl
批量上线时我最容易偷懒的一步，是验收只看 curl：状态码 200、关键内容在 HTML 里，就算过。
这不够。curl 只能告诉你页面「回来了」，不能告诉你页面「能用」。批量复盘里碰到过的几类问题，都是 curl 看不出来的：
- 广告位在没有广告的时候依然占着一块空白高度，小屏上特别难看。正确做法是没有广告时高度为 0。
- 结账页上放一个「还没开放」的灰色按钮，不只是劝退用户，还量不出点击。未做好的付费选项，要么不摆，要么改成 coming soon。
- 桌面端的上传入口，实际用户的照片多半在手机上。所以加了对实际在手机上的用户更友好的上传入口。这类问题只有真的用小屏走一遍才会发现。
所以新页上线前，小屏检查是必选项：至少在手机尺寸下把主流程走一遍，不是只看首屏。
六、可执行清单
- 同一改动影响 ≥3 个站，先进组件库，再分发。
- 每次修同一类问题的第二次，就在备忘里记一笔「可能进库」；第三次必须动手抽象。
- 上线清单模板化：域名与托管、统计、收录提交、支付状态、小屏检查，都固定成一份可复制的清单，不要凭记忆。
- 漏斗事件名与统计口径放进库里统一定义，不由各站自己起名。
- 自测流量打标记，分析时剔除；先想好以哪份数据为准。
- 新页必须过小屏检查，主流程走一遍，不能只用 curl。
- 批量升级先挑一两个站验证，再铺开；每个站的引入版本可查、可回退。
- 派 bot 逐站修同一类问题之前，先问一句：这个改动该不该先进库？
七、小结
批量建站的好处是快，代价是每个站都带一份拷贝。三次规则不能让你少建站，但能让维护成本别跟着站数一起涨。
整套协作方式的底层逻辑，也就是协调者拆任务、本机 worker 执行、我验收，在旗舰里有完整描述：我怎么用一群 AI bot，一个人跑独立站矩阵。上线之后怎么处理收录和 GEO，可以看 SEO·出海旗舰。
博客的 Agent 协作、SEO·出海、商业化三条线都有更新，可以通过 /posts 订阅 RSS。