Building several brands from one pipeline, don't treat each as a fresh start. One system, many skins: every brand generates from the same semantic tokens; only primitives (colour, type, radius) change per brand. A fix propagates everywhere.
Consolidate periodically — token systems drift. Across many brands and over time, tokens fork, one-off values creep in, and the systems diverge. Schedule a recurring consolidation pass:
- Re-extract and compare the live sites (use Dembrandt's extract + drift/compute-drift tooling, plus plain visual inspection and benchmarking against each other and against current design trends and best practice).
- Fold divergences back into the shared semantic layer where they should be common; keep genuinely brand-specific values as primitive overrides only.
- Feed in a point of view. Consolidation isn't just mechanical de-duplication — bring UX / visual-design opinion and a clear direction for where each product should go, not just where it is.
When design eras conflict, recency is the tiebreaker. A product built over years carries pages from different design generations. The newest pages and components are the best available evidence of current design intent — migrate old toward new; never average the eras into a compromise style. Recency is a default, not a verdict: the newest surface can be an unreviewed one-off. Confirm with the user before promoting a style to canonical or marking an old one deprecated.
Deprecate on touch, not big-bang. Keep a short list of deprecated styles — the old radius, the old shadow, the retired button variant. When work already touches an old-generation page, lift it to the current style in the same pass. Every touch moves the product one page closer to one system, with no rewrite project on the roadmap.
Two or three occurrences make a pattern. When the same visual treatment appears independently in 2–3 places, it is no longer a coincidence — name it, tokenise it, and make it available everywhere. Promoting it is cheaper than a fourth hand-rolled copy. Once promoted, the pattern belongs to the design language: new components may use it as-is or adapt it, as long as the adaptation stays recognisably true to the original.
Track feature usage and deprecate the dead weight. The same discipline applies to features, not just tokens: instrument what actually gets used, and deprecate the features/components with little real usage rather than maintaining them forever. A shared system stays healthy only if it's pruned — every unused component is drift waiting to happen and a cost on every future change.
通过一个流水线构建多个品牌时，不要将每个品牌视为全新项目。采用一套系统，多套皮肤：每个品牌都从相同的语义令牌生成；仅原色（颜色、字体、圆角）因品牌而异。一处修复可同步应用到所有品牌。
定期整合——令牌系统会逐渐偏离。 随着时间推移，多个品牌的令牌会分叉，出现一次性值，系统逐渐分化。安排定期整合流程：
- 重新提取并对比实时站点（使用Dembrandt的提取+偏离计算工具，再结合直观视觉检查，并与彼此及当前设计趋势和最佳实践进行基准对比）。
- 将差异合并到共享语义层中（应通用的部分）；仅将真正品牌特有的值保留为原始覆盖项。
- 注入明确观点。整合不只是机械去重——要融入UX/视觉设计理念，明确每个产品的发展方向，而非仅停留在当前状态。
当设计时代冲突时，以最新版本为优先。 一个历经多年开发的产品会包含不同设计时代的页面。最新的页面和组件是当前设计意图的最佳体现——将旧页面迁移至新风格；切勿将不同时代的风格平均成折中方案。最新版本是默认选择，但并非最终结论：最新的界面可能是未经审核的一次性内容。在将某一风格提升为标准或标记旧风格为弃用前，需与用户确认。
按需弃用，而非一次性大整改。 保留一份简短的弃用风格列表——旧圆角、旧阴影、已淘汰的按钮变体。当修改涉及旧时代页面时，同步将其升级为当前风格。每次修改都让产品向统一系统迈进一步，无需制定重写项目计划。
出现2-3次即形成模式。 当同一视觉处理方式独立出现在2-3个地方时，不再是巧合——为其命名、生成令牌，并推广至所有场景。推广该模式比第四次手动实现更划算。推广后，该模式属于设计语言：新组件可直接使用或调整，只要调整后仍能识别出与原始模式的关联性。
跟踪功能使用情况，弃用无用功能。 这种原则同样适用于功能，而非仅令牌：统计实际使用的功能，弃用使用量极少的功能/组件，而非永久维护。只有不断精简，共享系统才能保持健康——每个未使用的组件都是潜在的偏离源，会增加未来所有变更的成本。