刚开始做多站的时候，通用模板是个很诱人的词。一套模板写好，站复制出来就是，栏目、组件、样式全是现成的，建站速度肉眼可见地快。吃到甜头之后自然想再进一步：既然通用，那就索性全通用，连配色字体都让三十个站保持一致。这么干了大半年，问题慢慢显出来，读者的反馈倒先到：几个站翻下来，除了站名不一样，像在逛同一家店的不同分店，看完一个没有动力再点开下一个。
通用模板的四层，各归各的
骨架层｜页面类型、栏目结构、路由规则、抓取规范，这一层该统一，是所有站共用的底盘。
组件层｜卡片、表格、表单、导航的交互方式，这一层该统一，一次开发所有站受益。
令牌层｜颜色、字体、圆角、间距这些样式变量，这一层该分站，各站有自己的取值。
内容层｜栏目命名、选题角度、页面元素组合，这一层必须分站，是各站个性真正的来源。
把这四层分开之后，做法就清晰了：前两层统一，后两层分站。模板还是那一套，各站却不再彼此雷同。下面按四层展开，每一层说清楚边界划在哪、依据是什么。
一、四层各自的边界，先画清楚再动手
边界画错的代价，往往在站点铺开半年后才兑现。最常见的两种极端：统一过头，把令牌层甚至内容层也钉死，各站成了复制品；分得太散，每个站连骨架都自己改，通用模板名存实亡，维护成本反而更高。判断某一层该不该统一，有个简单的标准：与站点定位无关的部分统一，与站点定位有关的部分分站。栏目结构、路由规则属于前者，配色、字体气质、选题角度属于后者。
| 层级 | 包含什么 | 统一还是分站 | 判断依据 |
|---|---|---|---|
| 骨架层 | 页面类型、栏目层级、URL 规则、站点地图与抓取规范 | 统一 | 与站点定位无关，统一之后技术规范不出错，维护有公认的一套标准 |
| 组件层 | 卡片、列表、表格、表单、导航的交互方式与代码实现 | 统一 | 交互习惯跨站一致对读者友好，一次开发全站受益，重复开发没有意义 |
| 令牌层 | 颜色、字体、字号、圆角、间距等样式变量 | 分站 | 直接决定观感与气质，同一套取值铺到所有站，读者一眼就能看出是同一批站点 |
| 内容层 | 栏目命名、选题角度、页面元素组合、图片风格 | 分站 | 各站面向的行业与人群不同，内容结构跟着变，统一等于让所有站说同一句话 |
画边界的时候还有一个技术细节要提前处理：通用层里的链接一律用相对路径或域名变量，不要写死绝对地址。这条在单站开发时无所谓，站点一多就要出事，某一段页头代码带着旧站的域名铺到新站上，页面上的链接会集体指向错误位置，排查起来相当费力。骨架层统一，前提是这一层从一开始就不绑死任何一个站。
二、通用层留下的三笔账，都是实打实的
把骨架层和组件层统一起来，收益集中在三个地方，每一笔都能在账面上看到。多站运营拼的从来不是单个站做得多精美，而是整体效率与质量基线，这两项恰好都由通用层决定。
第一笔：交付速度
新站几小时起步
栏目、页面类型、组件全部继承，新站只做内容层配置
第二笔：维护成本
改一处，全站生效
组件修复与规范升级在通用层完成，不用逐站翻改
第三笔：质量基线
技术规范一次做对
URL 规则、标题层级、结构化数据、性能约束在骨架层统一
要让这三笔账持续成立，通用层本身需要按区域拆得干净。常见的做法是把模板切成页头导航、内容主体、侧栏推荐、页脚信息几个独立区域，每个区域自己管样式、自己留变量接口，区域之间通过统一的命名约定衔接。拆开之后有两个好处：改页头不会波及内容区，出问题能快速定位到具体区域；各站在令牌层替换变量时，只需要覆盖对应区域暴露出来的接口，不用碰区域内部实现。
- 每个区域内的取值只引用变量，不写裸值，令牌层替换时才可能干净
- 区域与区域之间的依赖保持单向，主体区可以要页头的数据，页头不反向依赖主体
- 组件命名带区域前缀，批量替换与检索都能定位到范围
- 暴露给各站的接口保持最小，站与站之间的差异集中在接口上，便于统一管理和排查
三、统一过头的代价，读者比系统先察觉
通用层带来的效率让人上瘾，很容易顺势把令牌层也统一了：既然配色好看，所有站一起用；既然字体讲究，所有站一起换。做的人觉得整齐，读者那边却是另一种感受。一个用户因为搜工业设备找到你的站，另一个用户因为搜家政服务找到你另一个站，两个站打开之后布局、配色、字体、图片风格几乎一样，信任感会打折：看起来更像同一家公司的两个入口，而不是两个独立的品牌。
四层全统一
所有站的骨架、组件、配色、字体、栏目设置高度一致，只有站名和正文不同；读者跨站浏览像在看同一份内容的不同副本，停留时间短，回访率低。
前两层统一、后两层分站
骨架与组件一致保证效率和质量；配色、字体、栏目命名、选题角度按站配置；读者进入任何一个站都能感到这是独立的品牌，技术人员的维护体验又不受影响。
行业错配是另一个不常被提起的问题。制造业的站适合克制的深色与规整的表格，生活服务类的站需要更暖的色调与更强的行动引导，这两个行业用同一套令牌，哪边都别扭。通用模板的骨架是空的，观感要跟行业走，令牌层分站正是给每类站点留出这种适配空间。多站做久了会发现，观感上的"合适"比"统一"重要得多。
"通用模板的功夫不在写了多少页代码，在分得清哪一层该省、哪一层不能省。"
四、令牌层怎么分站：一套变量文件，各自取值
令牌层分站的做法，成熟路径只有一条：把颜色、字体、圆角、间距这些取值全部收进变量，通用层只引用变量，每个站配一份自己的变量文件覆盖默认值。切换一个站的观感，换的是那份变量文件，通用层代码一行不动。要避开的反面做法是给每个站复制一份完整的样式文件再逐份改，站一多就会陷入"改了 28 个站，还剩 2 个死活对不上"的泥潭。
/* tokens.css：通用层默认令牌，所有站以此为底 */:root {--color-primary: #1e40af;--color-accent: #0ea5e9;--font-display: "Source Han Sans", sans-serif;--radius-card: 10px;--space-section: 72px;}/* site-a.css：设备制造业站的主题覆盖，深色稳重 */:root {--color-primary: #0f2a3f;--color-accent: #c9a227;--font-display: "HarmonyOS Sans", sans-serif;--radius-card: 4px;--space-section: 88px;}/* site-b.css：家政服务站的覆盖，暖色亲和 */:root {--color-primary: #b45309;--color-accent: #f59e0b;--font-display: "PingFang SC", sans-serif;--radius-card: 14px;--space-section: 56px;}变量覆盖的范围有讲究，四类差异按组分配，比零散地调单个值有效得多：
- 配色族：主色与强调色成对更换，配合中性色的冷暖倾向，一站一组，不跨站混用
- 字体气质：标题字体在一到两款家族中按站选定，正文保持高可读性，不为新奇牺牲阅读体验
- 圆角与密度：圆角大小、区块间距、卡片留白一起调整，制造业偏紧、生活服务偏松，成组出现
- 图片风格：写实场景、产品特写、插画风按站固定，图片处理参数一并写进主题配置
分配的要点是"成组自洽"：一个站里四类差异得往同一个气质上靠，深色配大圆角、暖色配硬阴影这类随机拼接，只会让页面显得杂。定稿之前把每个站缩略着看一遍，站内风格说得通、站与站之间区分得开，这层就算过关了。
五、内容层的差异，才是读者真正看到的差异
观感之外，内容层是各站拉开距离的主战场。同样是服务介绍栏目，制造业的站叫行业应用更贴切，家政的站叫服务项目更直白；一样是 FAQ，设备站的问答围着参数与选型转，本地服务站的问答围着价格与预约流程转。这些差异不需要重构模板，却比换一套配色更容易被读者感知到，因为它们直接对应各站用户关心的事情。
| 内容层元素 | 统一之后会发生什么 | 按站配置的具体做法 |
|---|---|---|
| 栏目命名 | 所有站用一套栏目词，各站行业的语言习惯被抹平，导航显得生硬 | 按行业习惯重命名栏目，保留层级结构不变，只换叫法 |
| 选题角度 | 选题同质化，读者跨站看到相似话题，站与站互相稀释 | 按各站的用户问题清单定选题，同一主题也换角度切入 |
| 页面元素 | 所有站都是同款 FAQ 加同款三栏卡片，页面的信息形状高度雷同 | 按内容类型组合元素：设备站用参数表与选型问答，服务站在线预约与价格问答 |
| 配图与素材 | 同一批素材铺到所有站，同一张图在多个站反复出现，观感拖沓 | 按站独立准备素材库，风格统一在站内，素材不跨站流转 |
观感差异让人第一眼看出不同，内容差异决定读者愿不愿意再点开另一个站。只做前者的站群，跨站跳转率会明显偏低；两者都做到位的站群，各站才能各自积累自己的读者。内容层的配置项最好写进建站清单，新站生成时逐项填写，避免"先上线，内容以后再说"拖成永久状态。
六、通用层一升级，怎么不覆盖各站的改动
分层结构跑起来之后，真正的考验来自维护。通用层发现一个组件问题要修，升级之后怎么保证不冲掉各站调整过的东西？现实中翻车最多的一种情况，是某个站当初直接改了通用层的文件，升级时这份改动被整体覆盖，还得靠日志回捞。根子不在升级动作，在改动没有放进正确的层。
把改动归位，规则只有三条，写进团队的协作约定里：
· 通用层的任何修改都走版本号，改完在当前所有站回归一遍再发布，不允许悄悄改
· 单站的观感调整一律改自己那份令牌文件，改通用层样式被视作违规操作
· 单站确实需要的新结构，先评估能否升级为区域级接口暴露给所有站，避免各站各改一套
升级动作本身也可以流程化：先在测试站应用新版本，按比例抽查几个真实站点的渲染与功能，确认无回归之后再批量推送。推送之后把版本号记录在案，出问题能按版本回退。这些做法在软件团队里属于常识，多站运营的团队往往缺的不是能力，而是把站点当作同一个产品来管理的意识。
改动权限最好和角色挂钩：通用层只有维护者能改，站内令牌与内容配置开放给各站负责人，两类改动的记录分开留存。权限模糊的团队，出问题的第一现场往往不是页面异常，是没人说得清这处代码是谁改的、为什么改。
七、从一套模板到几十个站，四步走完
把前面几层的工作串起来，实际落地的顺序是这样四步。它们之间有依赖关系，顺序颠倒会多返工：先有通用层，才谈得上按站配置；配置齐了再批量生成；生成之后靠版本机制持续维护。
骨架、组件、区域接口、变量清单一次写全，用测试站验证一遍再用
每站一份令牌取值、栏目命名、选题方向、素材库，填写完整再生成
按清单批量出站，按比例抽查观感、内容与链接指向，问题回写到配置
通用层升级走版本与抽查流程，各站改动留在令牌与内容层
用 UC 建站系统做这件事，四步都有对应的落点：通用层的骨架与组件在系统里统一维护，版本升级一处发布、名下站点统一生效；各站的主题令牌与内容配置分开存放，改一个站的观感不会牵动其他站；站点保持独立部署、独立模板，一个站的模板文件与数据各成一体；页面 HTML 直出，结构规范在各站一致落地；多站看板把各站的模板版本、页面状态与改动记录集中呈现，哪个站还在旧版本、哪次升级后哪个站出现异常，一屏就能对照出来。系统承接的是通用层的分发和各站差异的落实，四层里哪些该统一、哪些该分站的判断，以及每个站该长成什么样，仍然由人决定。
速记四条：
· 通用模板分四层：骨架层、组件层统一，令牌层、内容层分站
· 通用层的链接用相对路径与域名变量，绝不写死绝对地址
· 令牌分站靠变量文件覆盖，差异按配色、字体、圆角密度、图片风格成组分配
· 通用层改动走版本与抽查流程，站内改动只落在令牌与内容配置上
现在回头看那三十个站，最有价值的经验其实来自当初那次"全统一"的失败。它逼着我把模板拆成四层，也把一个问题想清楚了：做站群不是把一套东西复制很多遍，是把可复用的部分做到极致，再把该不一样的部分留足空间。这两件事看起来矛盾，分好层之后就是同一件事。
如果你手上也在用一套模板管着多个站，可以先做一个简单的检查：随便挑三个站并排打开，挡住站名看一眼能不能分清。分不清的，问题多半就出在令牌层和内容层没有分家；能分清但维护起来很痛苦的，多半是通用层拆得不够干净。两头都顺了，通用模板才真正开始创造价值。
"通用的是底盘，差异是门面，底盘造得越结实，门面才越有资格各开各的。"
