设计系统不是一份静态的规范文档，而是一套持续演进的协作机制：从设计规范到组件库、从变更评审到落地实现，都需要可追踪、可复用、可对齐。下面这份清单按“文档站点 / 组件展示 / Token与版本治理”整理常用工具，适合团队快速搭建一套可维护的设计系统工作流。
工具地址：https://storybook.js.org/
免费商用：开源的组件工作台，适合把 UI 组件按状态/交互拆开展示，天然支持可视化回归、文档与示例代码；在设计系统里常用来做“组件真源（single source of truth）”的演示层。
工具地址：https://www.chromatic.com/
需看协议：Storybook 官方生态的托管与可视化回归服务，适合把组件库 PR 评审和截图对比流程标准化；付费方案通常用于团队级设计系统的持续集成。
需看协议：面向设计系统的专用文档平台，支持从 Figma 同步组件与样式、做规范页面与版本发布；适合把“设计规范的阅读体验”和“组件/用法说明”做成可维护的站点。
需看协议：偏工程化的设计系统平台，强调组件、文档、协作与发布一体化；如果团队希望把设计系统当成产品来迭代（含主题、组件规范、发布节奏），它会更贴近工程侧的习惯。
免费商用：开源文档站生成器，适合自建设计系统文档站（规范、原则、组件说明、贡献指南）；配合 Git 流程可实现版本化文档与多人协作编辑。
需看协议：轻量的团队知识库与文档平台，编辑体验好，适合把设计系统的“原则/规范/流程”快速沉淀成站点；与代码仓库/权限体系结合时需注意不同套餐限制。
免费商用：开源的文档站方案，基于 Markdown 即可快速搭建；适合小团队/个人把组件库使用说明、命名规范、变更日志做成可访问的内部文档。
需看协议：更偏“工作台”的知识管理工具，适合把设计系统的治理流程（组件提案、评审记录、里程碑、FAQ）用数据库管理起来；对外发布与权限控制需结合具体方案评估。
工具地址：https://www.atlassian.com/software/confluence
需看协议：企业级协作文档平台，适合把设计系统的流程、规范、决策记录与组织级知识体系打通；如果团队已使用 Jira/Bitbucket，整合成本更低。
需看协议：设计侧组件库与样式库的核心载体，适合通过发布库（Publish Library）管理组件版本、统一命名与描述，并用变更说明推动团队同步；关键是建立“谁能改、怎么提案、怎么发布”的治理规则。
需看协议：设计 Token 管理工具（常见于 Figma 插件生态），适合把颜色、字体、间距、圆角等做成可导出/可同步的 Token；与工程侧（Style Dictionary 等）组合能减少手工对齐成本。
工具地址：https://amzn.github.io/style-dictionary/#/
免费商用：开源的设计 Token 构建工具，可把 Token 转换为多端可用的变量/资源文件（Web、iOS、Android 等）；适合把“设计里的变量”变成“代码里的真变量”。
工具地址：https://github.com/changesets/changesets
免费商用：开源的版本与变更日志管理工具，适合组件库多包仓库（monorepo）做语义化版本发布；与 CI 流程结合后，组件库的升级成本会更可控。
工具地址：https://semantic-release.gitbook.io/semantic-release/
免费商用：开源自动化发布工具，基于提交信息生成版本号与变更日志；适合把设计系统组件库的发布节奏标准化，减少“手动打包发布导致的版本混乱”。
小提示：如果你希望设计系统长期可持续，建议同时建立三条线：设计侧库发布规则（Figma）、工程侧组件库与版本治理（Storybook + 版本工具）、文档与决策留痕（文档站/知识库）。三者打通后，设计系统才会真正“可维护”。
