10 个站点，1 个团队，0 错配。这不是口号，是工程问题。当品牌方手里有多个门店品牌、多个业务线时，每个站点都要独立的 AI 知识库，但又不能用 N 倍人力去维护。本文讲清楚多站点内容分发的工程化方案。
多站点的痛点
一个连锁集团旗下可能有茶饮、烘焙、零售三个品牌，每个品牌独立站点、独立域名、独立 AI 知识库。痛点集中在三处：
- 内容错配：茶饮的促销文案误发到烘焙站点，品牌调性瞬间崩塌
- 权限混乱：谁能编辑哪个站点，靠口头约定，迟早出事
- 模板浪费：每个站点从零搭，重复造轮子，维护成本随站点数线性增长
解法是：内容矩阵 + 权限模型 + 模板复用，三件套。
内容矩阵设计
把所有内容按”品牌 × 类型 × 场景”三个维度组织成矩阵：
# 内容矩阵示例
matrix:
brands: [tea, bakery, retail] # 3 个品牌站
types: [product, blog, faq, case] # 4 种内容类型
scenarios: [brand, industry, geo] # 3 类场景
# 理论上 3×4×3=36 个内容桶，实际按需启用共享层与专属层
内容分两层，这是”0 错配”的根基：
| 层级 | 内容 | 分发策略 |
|---|---|---|
| 共享层 | 行业洞察、GEO 方法论 | 多站点共用，按品牌调色 |
| 专属层 | 产品手册、客户案例、促销 | 单站点独占，严格隔离 |
共享层写一次，按品牌变量（配色、名称、logo）渲染到 N 个站点；专属层绝不跨站。茶饮的案例永远进不了烘焙的站点，靠的是数据隔离，不是人的自觉。
权限模型
RBAC 四角色
roles:
admin: # 集团管理员：全站读写 + 权限分配
scope: "*"
actions: [read, write, publish, grant]
editor: # 品牌编辑：单品牌读写
scope: "brand:tea"
actions: [read, write, publish]
reviewer: # 审核员：单品牌读 + 审核发布
scope: "brand:bakery"
actions: [read, approve]
viewer: # 只读：跨品牌只读
scope: "*"
actions: [read]边界铁律
- 编辑只能看自己品牌的内容桶，跨品牌请求直接 403，不返回任何数据
- 发布动作必须双重确认（编辑提交 + 审核员放行），单人无法直接上线
- 所有操作留审计日志，谁在何时改了什么，可追溯到秒
权限模型不是限制效率，是保护边界——10 个站点里只要有 1 个错配，损失就盖过另外 9 个的正确。
模板复用
内容模板
把高频内容结构沉淀成模板，变量化驱动：
<!-- 产品页模板 -->
# {{product.name}}
适用场景：{{product.scenarios}}
核心能力：{{product.capabilities}}
合作生态：{{product.integrations}} <!-- 一律"合作"关系 -->
数据来源：{{product.trust.source}}每个品牌填自己的变量，页面结构完全一致，维护成本只有 1 份模板 + N 份变量。改版时改模板，所有站点同步生效。
发布模板
发布流水线也模板化：构建 → 校验 → 预览 → 发布，每个站点复用同一条流水线，只是目标域名不同。新增站点只需注册域名 + 填变量，不动流水线。
0 错配的工程实践
“0 错配”不是靠人盯，是靠工程兜底。四道防线：
- CI 校验：每次提交自动检查内容里的品牌标识是否匹配目标站点，不匹配直接阻断流水线
- 预览环境：每个站点独立的预览域名，发布前必须肉眼确认
- 灰度发布：先发 10% 流量，监控 AI 蜘蛛抓取是否正常，无异常再全量
- 回滚开关：一键回滚到上一版本，错配影响控制在分钟级
# CI 校验脚本示意
check_brand_match() {
local file=$1 target_brand=$2
grep -q "brand:${target_brand}" "$file" \
|| { echo "品牌标识不匹配，阻断发布"; exit 1; }
}某美业集团用这套方案管理 12 个门店品牌站点，3 人团队稳定运营 8 个月，内容错配事件为 0，新站点上线周期从 2 周缩短到 2 天。
多站点 GEO 不是把单站点的活乘以 N，而是用矩阵化、模板化、权限化的工程体系，把边际成本压到趋近于零。
