泛用设计的代价：默认 UI 与 agent 生成的设计

同一个站你看过一百遍了。一样的圆角、一样的灰底白卡、一样的渐变 hero 加 CTA。不难看，但也和上季度上线的每一个产品长得差不多。

这和内容上的老问题一样：没有约束的 agent 产出泛用文案。同样的逻辑正在 UI 上重演。默认组件库和没被教过你约束的 agent，会收敛到同一套视觉语言。泛用的代价不是「丑」——是没有区分度。看不出谁做的、为什么做的。

默认值是你没做过的选择

当你用一套 UI 套件——Tailwind UI、shadcn、没做主题的 Radix 原语——你会得到一致性，也会得到「所有人选择的平均」。间距、字阶、圆角、颜色都由库作者或模型训练分布决定。想快、不在乎身份时这很有用；想要一个感觉像你的产品时就是陷阱。

Agent 会放大这种效果。让它做一个 dashboard 或落地页，它会用到处见过的那套原语拼：卡片、徽章、弹窗。没有 design token、没有风格指南，agent 就不知道「你的」UI 长什么样，只能产出平均值。和内容问题一样：不给方向就是一种方向——往中间靠。

解决办法不是不用库或不用 agent，而是加约束，把「合法输出」的空间收窄。

Design token 是最直接的杠杆。颜色、间距、字体、圆角有单一事实来源，既给人 guardrail，又给 agent 一份规格。

当 token 写明「primary 是 #0f172a」「card 圆角 0.375rem」，agent 不用发明，只在系统里组合。输出能保持品牌感，因为品牌被编码进去了。

和语气一样，UI 也需要「要这样」和「别这样」。「表格用紧凑变体」是模式；「同一视图里不超过两种强调色」是反模式。两者都减少 agent（或初级开发）要做的决定，错误地方的决策越少，越不容易滑向泛用。

我在实际项目里见过：有一小套明确的 design token 和简短「要/不要」清单的，做出来的 UI 有意图感；靠「弄好看点」或裸组件库的，做出来像模板。差别不在天赋，在约束。

教 agent 写作语气的那套思路，同样适用于产品和界面。你不是给 agent 一张白布然后指望奇迹，而是给它一套系统：token、组件使用规则、以及「做完长什么样」的示例。

把反模式写清楚，让 agent 知道要避免什么。在输出算完成前跑一遍 checklist——对比度、层级、一致性。

这些工作对人也有用。一套够让 agent 跟的 design system，通常也够一个团队跟。把约束写下来的过程会逼你想清楚自己到底在意什么。

默认值不再隐形，而是显式的。你可以改。

泛用的代价是可以避免的。默认 UI 和没有约束的 agent 会继续产出千篇一律的站，直到我们把设计像内容一样对待：需要编码的意图。Token、模式、反模式。不是少自由，而是边界更清晰，让边界内的产出真的像你。