可复用的 UI 组件：命名、变体与布局规则

为什么可视化构建器中的界面一致性会崩塌

可视化构建器能让你快速交付界面。但这种速度也会掩盖外观和行为慢慢偏离的过程。当多人同时构建时，微小选择会叠加：有人加了 12px 的内边距，另一个用了 16px，还有人从旧页面复制了按钮。

你通常会先看到一些早期症状：近似重复的组件、各屏之间会移动的间距，以及同一动作的不同用语（保存、提交、确认）。各状态也经常分叉：一个表单有明显的加载态，另一个没有。错误信息各不相同，“临时修复”出现在某个页面却从未回到共享模式中。

这就是 UI 债的开始。每个不一致看起来都很小，但时间一长会让产品显得不可靠。同时也拖慢团队，因为人们要花更多时间去找“正确”的版本、比对页面，以及在评审后修复细小差异。

在可视化构建器中，组件库是每个人都能从中拉取而不是重复创建的一套共享积木（按钮、字段、卡片、页头、空状态等）。在像 AppMaster 这样的平台里，这通常意味着在可视化 UI 构建器内创建可复用的 UI 片段，然后就它们的命名、配置和放置方式达成一致，这样即便不同人构建页面，界面也能保持一致。

目标不是扼杀创造力，而是让日常部分变得可预测，让选择变成有意为之。防止偏离的四个杠杆是：清晰的命名、合理的变体、基础布局规则（间距、对齐、网格）以及随着应用增长保持库健康的团队习惯。

什么应该做成可复用组件（哪些不该）

并不是每个好看的元素都值得做成组件。如果把所有东西都组件化，人们会浪费时间在库里翻找并调整那些本不该存在的选项。

一个好的可复用组件是你期望在许多页面看到的东西，或者每次都必须在外观和行为上一致。想想用户能立刻识别的模式：主按钮、带帮助文本的文本输入、预览记录的卡片。

一个小而实用的起始集合通常覆盖大部分页面：按钮、输入框、卡片、页面头部和几种模态（确认和表单）。

一个实用的抽取规则可以把决策简化：如果同一 UI 使用了 2 到 3 次，或者它对品牌至关重要且需要完全一致，就把它抽出来。如果只出现一次，就保持在本地。

哪些应保持一次性？与单个页面强绑定的高度特定布局、每天都在改的实验性模块，以及大多数只是内容的部分。例如，一个一次性的引导横幅，带自定义文案和插画，通常不值得组件化。

保持每个组件职责单一。一个组件应只做一件事。一个同时处理权限、账单状态和管理员动作的“用户卡片”会变得难以复用。更清晰的做法是：做一个以展示为主的“用户卡片”，另外把操作按钮和状态芯片拆出来。

在压力下仍然可读的命名规范

当团队快速交付时，命名是最先崩坏的部分。有人复制了 “Button2”，另一个建了 “CTA Button”，第三个用 “BlueButton”。一周后，没人知道哪个应该复用，于是又建了一个新组件。这就是库变成一堆近似重复项的过程。

一个简单的模式能让你在疲惫时也保持一致：Component - Part - State。大多数组件不需要三个层级，但保持顺序一致很重要。

使用团队真实会说的词。如果团队说“Customer card”，不要命名成“CRM Tile”。如果产品叫它“Plan”，不要叫成“SubscriptionBox”。朴实的语言更好搜。

有一条规则能避免很多混淆：不要在同一层混用“外观是什么”和“用途是什么”。选一种方式并坚持。如果按用途命名，就避免颜色词；若按外观命名，就避免业务含义。按用途命名通常更容易扩展。

易于在组件列表中扫描的示例：

• Button - Primary
• Button - Secondary - Disabled
• Input - WithLabel
• Card - Compact
• Modal - ConfirmDelete

把格式规则定好并写下来：Title Case 还是 sentence case，连字符周围是否留空格，不要使用缩写（除非是通用的，例如 “URL”）。在有多人贡献的可视化构建器里，这些小约定能让库在增长时依然易读。

变体：如何在不制造混乱的前提下提供选择

变体让团队在不复制组件的情况下在多处复用同一个组件。关键在于事先决定哪些差异重要，并把其他东西锁死。

从少数变体维度开始，覆盖真实需求。对许多组件来说，三项就够：尺寸（S/M/L）、用途（primary/secondary/danger）和状态（default/hover/active）。如果新选项不符合这些维度，就把它当作新组件，而不是“又一个变体”。

默认值比人们想象的更重要。新页面在有人拖入组件却不改动任何设置时也应看起来正确。设置安全默认（例如 size=M，intent=primary，state=default），避免速度变成随意样式。

对于有变体的每个组件，应记录并执行：

• 支持的维度和允许的取值（保持简短）
• 默认值
• 在各变体间永远不变的东西（内边距、字体、圆角、图标间距）
• 必须包含的状态，如 disabled 和 loading，再加上在可能失败时的 error
• 什么时候应该创建新组件而不是增加变体

举例：在客户门户里有一个 “Submit” 按钮。如果有人做了一个 “Wide Submit Button”，另一个做了 “Rounded Submit Button”，偏差很快就出现。有了规则，你只保留一个 Button 组件，允许尺寸和用途变体，禁止自定义内边距和圆角，并统一定义 Loading（显示旋转器，禁用点击），确保在各处行为一致。

当有人要求“再来一个样式”时，问清楚它解决了什么用户问题。如果答案模糊，它很可能是混乱的借口。

布局规则：每个人都要遵守的间距、对齐和网格

如果布局规则含糊不清，每个页面都会慢慢变成一次性的东西。保持组件一致的最快办法是让间距和对齐变得枯燥：只允许几种选择，并且每次都以相同方式使用。

从间距刻度开始，并禁止其他值。选一小套（例如 4、8、12、16、24），把它当成键盘：你可以演奏很多曲子，但只能用这些键。如果有人需要 “18px”，通常说明组件或网格有问题。

明确说明间距的含义：

• Padding 是组件内部的间距，在各屏保持一致。
• Gap 是容器内项目之间的间距（表单行、工具栏项）。
• Margin 是组件外部的间距，应尽量少用。
• 优先使用 gap 而不是叠加的 margin，这样不会在嵌套时意外成倍增加间距。

对齐规则可以消除无休止的“微调”。一个简单的默认很有用：文本左对齐，标签和输入在同一垂直线上对齐，主要操作位置保持一致（例如模态框底部右侧，表单页脚右对齐）。文字密集行使用基线对齐。仅在图标单排时保留居中对齐。

网格不需要复杂，但必须存在。决定列数和 gutter，并定义小屏时的处理方式（即使是基础的 “桌面 12 栏，移动单栏” 也有帮助）。一旦确定容器宽度和断点，就在这些轨道内构建页面。

常见陷阱包括：每层容器都叠加内边距、页面边距不一致、固定宽度与响应式列混用，以及只修复单个页面的“神奇数字”。

样式 tokens：字体、颜色与无障碍基础

样式 token 是大家共享的选择。当 token 清晰时，即便不同人构建页面，可复用组件也能保持一致。

从排版开始，作为唯一的真理来源。选一套精简的字体规模（字号、字重、行高），然后不要再加。大多数团队只需要几个等级（例如 body、small、caption、title、page heading）。把这些放在一个地方，让新增文本从相同默认开始。

颜色最好按语义命名，而不是油漆编号。“Primary” 表示主要操作，“Success” 表示操作成功，“Warning” 提示注意。避免使用 “blue-500” 这类名称，除非团队已经习惯按色板思考。

避免无障碍问题的基础做法：

• 确保文本与背景之间有足够对比度。
• 触控目标要足够大，适合拇指而不是鼠标指针。
• 错误信息要写明发生了什么以及下一步怎么做。
• 不要只依赖颜色来传达状态。

Tokens 应直接连接到组件变体。像 Primary、Secondary、Danger 这样的按钮变体应切换批准的 token（颜色、边框、文本样式），而不是引入一次性样式。

把 token 列表保持到足够短，让人们真能使用它们。一个好测试：某人能在 5 秒内选对 token 吗？如果不能，就合并或删除。

一个简单的起始集可能包括排版（text.body、text.small、text.title）、颜色（color.primary、color.success、color.warning、color.danger）、间距（space.8、space.16、space.24）、圆角（radius.sm、radius.md）和焦点样式（focus.ring）。

逐步操作：在可视化构建器中建立组件库

组件库不是关于“设计完美”，而是关于消除日常的微决策。当每个人都选择相同的构建块时，即使不同人构建，页面也能保持一致。

一个实用的 5 步推出流程

1. 审计现有内容。选 5 到 10 个真实页面，记录反复出现的重复项：按钮、文本输入、分区标题、卡片和空状态。

2. 选择一小波首批标准化对象。目标是那些到处出现并造成最多不一致的前十项。对许多团队来说，这意味着按钮、输入框、下拉、模态对话框、表头和卡片。

3. 在构建前把规则写下来。简短即可：组件名称、何时使用、允许的变体以及围绕它的布局规则（间距、对齐、宽度）。

4. 重建一次，然后逐步替换。先在可视化构建器中创建新组件并锁定你们同意的变体。逐屏替换旧拷贝，不要试图在一个冲刺内重构所有东西。

5. 添加一个轻量的审核门。由一人（每周轮值）检查新组件和新变体。目标不是管制，而是防止意外分叉。

“够好”的样子

当一位设计师或产品经理能说 “使用标准卡片的紧凑头部” 并且两位构建者产出相同结果时，你就知道方法奏效了。回报是：更少的一次性选择、更少的细微不一致以及更快的页面构建。

有意把库保持小。如果有人请求新变体，先问一个问题：这是一个真实的新需求，还是现有变体换个内容就能覆盖？

导致界面缓慢且不一致的常见错误

大多数不一致不是因为审美差，而是因为复制容易、微调快捷且没人回头整理。结果是一组几乎相同却难以更新的页面。

一个常见陷阱是创建近似重复项而不是增加变体。有人需要“稍高一点的主按钮”就复制组件。一周后又有人复制那个。现在有了三个看起来相近但行为不同的按钮，任何变更都要四处找。

另一个放慢速度的是过度可配置的组件：一个拥有几十个开关的巨型组件。它看着灵活，但变得不可预测。人们不再信任它，转而为“这个场景专用”创建新版本，这违背了初衷。

布局错误造成的损害同样大。最大的问题是职责混淆：组件控制了自身的外部 margin，而页面也在加间距，你就会得到随机的空隙。一个简单规则有帮助：组件定义内部 padding，页面控制组件之间的间距。

通常先暴露的问题包括：命名规则被匆忙打破、状态晚加（loading、empty、error）、一次性微调变成常态，以及不同人用不同方式解决相同布局问题。

每个新页面的快速一致性检查表

在添加任何新内容前，停 60 秒检查基础。一个页面看起来可能没问题，但在背后悄悄破坏系统，而当多人并行构建时，这些小破坏会迅速累积。

• 命名： 每个组件遵循约定模式（例如 Form/Input、Form/Input.HelperText、Table/RowActions）。如果名称不能帮助别人快速检索并放置组件，现在就重命名。
• 所有者 + 目的： 每个共享组件都有一个负责人（人或团队）和一句话的使用说明。
• 仅使用间距刻度： 所有 padding、gap 和 margin 都使用批准的间距步进。如果你因为“看着对”而输入了新数值，先停下并选最接近的刻度。
• 包含状态： 关键交互组件应包含 loading 和 error 状态，而不只是正常路径。考虑 disabled 按钮、输入错误、空列表、重试等情形。
• 不发明新样式： 使用现有的 token 和组件构建页面。如果你想要新的颜色、字号、圆角或阴影，把它当作系统请求，而不是页面级修复。

示例：两个人构建相同功能，有规则和没规则的对比

Maya 和 Leon 在一个客户支持团队。他们需要两个页面：工单列表（快速浏览）和工单详情（处理单个工单）。他们分工在可视化构建器里分别搭建。

没有规则时，每个人做的“卡片”都不一样。Maya 用白色卡、细边框和阴影。Leon 用灰色卡、无边框但加了内边距。一个页面用了圆角主按钮，另一个用了方形按钮和文本链接。状态在一个页面是彩色点，在另一个页面是标签。在详情页，字段没有对齐，因为标签宽度不同，整个表单显得不稳。

评审会变成一次样式争论，简单的更新（比如加“优先级”）需要改动多个一次性布局。

有了规则后，他们从小型共享组件库开始：一个 TicketCard 负责结构和间距，一个 StatusBadge 负责状态样式和对比度，一个 ActionBar 负责一致的主要操作。

现在列表页使用 TicketCard 的紧凑变体显示关键字段和预览行；详情页使用详细变体展示完整描述、时间线和额外字段。结构一致，变体控制显示内容。

最好的部分是你看不到的变化：评审意见更少，不再有人问 “为什么不一样？”，后续更新也更快。当团队把 “Closed” 改名为 “Resolved” 并调整颜色时，只需在 StatusBadge 改一次，两处页面就都会更新。

随时间保持一致（和下一步）

一致性不是一次性设置。随着更多人构建页面，“只为这个页面”的选择会成倍增加，库开始偏离。

一个简单的变更流程能让团队继续前进，同时不把每次按钮微调都变成辩论：

• 提议：说明要变更什么以及为什么（新组件、新变体、重命名、废弃）
• 审核：由设计师或 UI 负责人检查命名、间距规则和无障碍基础
• 批准：明确的同意或否定，并在必要时附带简短说明（例如仅限某个工作流）
• 发布：更新共享库并在一个地方通知变更

决策需要有归属地。一份简短的 “UI 规则” 文档就够了，包含命名约定、官方变体列表（哪些存在、哪些不存在）和不得为之清单（例如：“不要创建第二个具有不同内边距的 ‘Primary Button’”）。

安排每月一次的清理时段。用来合并重复项、移除未使用组件，并把旧组件标记为废弃，避免人们继续抓取错误的版本。

当你看到同一模式出现两次时就重构（例如两个团队做了略有不同的空状态）。对于真正独特、时间敏感且不大可能重复的情况，可以保留一次性实现。

如果你在 AppMaster 中构建，一个实用的下一步是先标准化一个工作流（比如“Create ticket”），再逐步扩展。UI 构建器让你轻松在页面间共享组件，appmaster.io 在需要无代码但仍支持完整应用（而不仅是页面布局）的场景下是一个参考点。