参考架构

以下是推荐的设置方案，而非客户案例。请选择与您最接近的模式并加以调整。

1. 多品牌集团

一家控股公司，拥有多个品牌网站，每个品牌有各自的团队。

Organization: Group
├── Site: brand-a   (Development, Production)   editors: Brand A team
├── Site: brand-b   (Development, Production)   editors: Brand B team
└── Site: brand-c   (Development, Production)   editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand

• 一个组织，每个品牌一个站点。 内容、媒体、令牌和成员绝不会在站点之间交叉。
• 每个品牌保留自己的网站代码和契约，以及各自的组件和设计令牌。Atlas 绝不强制使用统一的设计。
• 品牌编辑人员只在自己的站点上拥有角色。集团数字化团队批准生产环境的发布版本。
• 每个网站都有自己的交付令牌和 Webhook，因此一个品牌的部署或故障不会影响另一个品牌。

2. 受监管或审批繁重的公司

金融、医疗、能源或与政府相关的团队，每项公开更改都需要签批。

• 编辑人员和市场人员起草；审核人员/发布者在开发环境中发布；一个更小的群体批准生产环境的发布版本。
• 对敏感操作启用手机审批。
• 每个发布版本都经过检查（契约同步、无发布问题、站点健康、近期备份）并签名。回滚只需一个操作。
• 导出审计日志用于您的合规记录。
• 在上线之前商定线索保留规则，并注意目前保留规则和 CRM 推送仅涵盖开发环境的线索。
• 请在签约之前与我们确认托管位置和数据保留期限（请参阅安全）。

3. 运营客户网站的代理机构

一家代理机构为多个客户构建和维护站点。

• 建议每个客户一个组织，使每个客户拥有自己的数据、成员和套餐。代理机构员工以成员身份受邀加入。
• 在代码中构建您自己的组件库，并在各客户契约之间复用，同时使用客户专属的设计令牌。
• 使用通过 MCP 连接的 AI 编程智能体进行内容迁移；由客户的审核人员发布。
• 交接是安全的：客户的编辑人员只能更改类型化字段，绝不能更改代码。

4. 单个企业网站

一个公司网站、一个小型市场团队和一名外部开发人员。

• 一个组织，一个站点。开发人员连接网站并一次性编写契约。
• 市场团队编辑页面、新闻和译文；市场负责人批准生产环境的发布版本。
• 只有在需要新组件或页面类型时才需要开发人员。

所有模式的共同点

• 您的网站代码、托管和部署仍由您掌控。
• 先在开发环境；只有通过已批准的发布版本才能进入生产环境。
• 内置回退，使站点在 Atlas 无法访问时保持在线。
• 交付令牌放在服务器上，并在过期之前轮换。