给AI Agent配一套UI工作标准，彻底告别千篇一律的界面

最近这段时间我一直在折腾 AI Agent 开发，一个感受特别深：AI 写代码的能力早就不是瓶颈了，写 UI 才是。你让它搭个内部工具、做个数据看板、写个表单页面，它交出来的东西十有八九是那种“一眼 AI 味”的界面——白底卡片、蓝色渐变按钮、圆角拉满、居中排列，功能挑不出大错，但就是丑得千篇一律。

一开始我也以为是模型不行，后来反复试下来才发现，问题根本不在模型，而在流程。你根本没有给 Agent 一套“UI 工作标准”。它不知道项目的视觉基线是什么、不知道配色怎么定、不知道组件该怎么组织，于是只能调用训练数据里最普遍的默认审美。后来我参考了很多 Agent 开发者的做法，给 Agent 装了一套 Skill，用类似“工作规范”的方式把 UI 设计的约束、流程和品味标准注入进去，产出质量立刻上了一个台阶。这篇我就把完整思路、配置方法和踩坑记录分享出来，给同样在折腾 Agent UI 的朋友做个参考。

1. 先搞清楚：Agent 写的 UI 为什么这么丑

想解决问题，先得知道病根在哪。我拆过很多 Agent 生成的界面，无论是用 Claude、GPT 还是开源模型通过 Agent 框架跑出来的，丑的规律几乎一模一样。这不是巧合，背后是模型行为和缺少约束共同作用的结果。

1.1 不是模型不行，是“默认行为”在拖后腿

模型生成界面时，本质上是在做“最可能的下一个 token”的预测。训练数据里出现频率最高的网页、后台模板、开源组件示例，决定了它首选的视觉方案。所以你会发现，Agent 默认产出的 UI 高度趋同：

• 页面永远是一个居中的大容器，背景不是纯白就是浅灰。
• 标题下面紧跟一行浅色描述文字，像是固定格式。
• 按钮喜欢用蓝紫色渐变，鼠标悬停效果基本没有。
• 功能模块用卡片堆叠，卡片之间间距忽大忽小。
• 状态提示偏爱 emoji，配上一段“积极向上”的文案。
• 表格、侧边栏、导航这些复杂组件一旦涉及，就开始生硬拼接。

有朋友会觉得“功能实现了就行，丑点没关系”，但如果你做的工具要给别人用，UI 就是第一印象。丑的界面会让用户怀疑工具的可靠性，这是很现实的损失。

1.2 缺的不是审美，是“基线”和“品味”

做设计的人都知道，好的界面背后有两个层面：一个是基线（baseline），也就是颜色、字体、间距、圆角、组件库这些可以被量化成规则的东西；另一个是品味（taste），也就是面对具体场景时，什么风格合适、什么元素该弱化、什么细节能体现出质感。

Agent 默认的问题，恰恰是两层都没有。它脑子里既没有你项目的颜色令牌和间距系统，也没有“这个内部工具应该简洁克制、那个官网应该活泼一点”这类场景化判断。于是所有界面都滑向同一个默认值，这个默认值又恰好是训练数据里最平庸的那一档。

要解决，就要把这两层内容显式地交给 Agent。这也是我后来转向 Skill 方案的根本原因。

1.3 为什么 UI 问题特别适合用 Skill 解决

UI 问题看着很主观，其实特别适合做成标准化工作流。因为构成“好看”的要素可以被拆解成可验证的规范，比如主色、辅助色、字号层级、间距倍数、栅格、圆角值、阴影层级、组件复用规则。这些东西一旦白纸黑字写清楚，Agent 就是能照着执行，而且执行得比人还稳定。

另一个原因是，UI 生成是一个“从无到有”的任务，Agent 在每一步决策时都需要参考标准。如果你只在任务指令里写一句“把界面做得好看些”，它根本不知道该怎么做；但如果给它一套结构化的 UI 工作标准，它的每一步决策都有据可依，产出自然就稳定了。这就是 Skill 的用武之地。

2. 重新认识 UI Skill：它不是插件，是“职业素养”

很多第一次接触 Skill 概念的人容易把它理解成插件，或者单纯的一段 Prompt。其实都不准确。Skill 更像是一套打包好的“职业工作标准”，它让 Agent 在特定任务里具备专业从业者应有的行为方式。

2.1 Skill 和 Prompt 的区别在哪里

直接写提示词之所以不够用，有两方面原因。一是系统提示词会被任务对话冲淡，尤其对话轮次一长，后面的约束很容易被忽略；二是提示词里装的东西太杂，设计规范、代码逻辑、业务需求混在一起，模型很难分清优先级。Skill 的思路不一样，它把某一类任务的标准独立成一个模块，在合适时机被加载和使用。就好比你给新人一份岗位手册，而不是在每天布置任务时重复一遍公司规定。

UI Skill 就是一份给 Agent 的岗位手册，里面写清楚“咱们这个项目做界面时，必须遵守哪些视觉规则”“按什么顺序思考布局”“什么情况下用哪些组件”“完成后要自查哪些项目”。Agent 拿到这份手册，工作方式会变得非常接近一个按规范做事的设计师。

2.2 一个 UI 工作标准里应该包含什么

我自己的实践下来，一套有实效的 UI Skill 至少应该覆盖以下几个方面：

• 视觉基线规范：色板、字号梯度、间距系统、圆角与阴影规则、栅格与对齐方式。
• 布局思维流程：拿到需求先想信息层级，再定布局骨架，后选组件，而不是一上来就写代码。
• 组件选用约定：哪些场景用哪些组件，什么时候应该克制堆砌，什么时候可以做视觉强调。
• 审美底线的负面清单：例如“不要使用纯黑 #000 作为文字色”“不要在同一界面里出现超过三种强调色”。
• 自查清单：交付前按清单检查一遍配色、间距、对齐、反馈状态、响应式表现。

从这套结构能看出来，UI Skill 不只是告诉 Agent“好看的模板长什么样”，更重要的是给它一套决策框架，让它自己推导出当前场景下最合适的视觉方案。这也是“工作标准”比“素材库”有效的原因。

2.3 底层逻辑：约束越大，发挥越稳

很多人担心，给 Agent 立太多规矩会扼杀创造力。但 UI 生成这件事恰恰相反。模型的默认输出本身就带有很强的随机漂移，如果没有任何约束，你以为它是在自由发挥，实际它是在撞大运。给出一套清晰的约束后，模型反而能把能力集中在真正需要判断的地方，比如信息层级的处理、内容的重点表达、交互的合理性。

我自己的体会是，一套好的 UI 标准，应该像设计体系那样有弹性也很严格。严格的部分是那些用于保证一致性的规则，弹性的部分则是留给你和模型在具体项目里做取舍的地方。真正有效的 Skill 不应该是死板的大全，而是一套有优先级、能指导决策的框架。

3. 实操：给 Agent 装一套 UI 工作标准，手把手配置

下面进入正题。我会按自己实测通过的方式，从建基线、写规则、整合工作流到验证效果，完整走一遍流程。

3.1 第一步：先定“基线规范”，数据要具体

一套 UI 工作标准最核心的是 baseline，也就是可以量化的视觉规范。这一步偷不得懒，不能用“好看一点”“高级一点”这类模糊描述，必须给出确切值。

我用的基线模板大概是这样的，你可以直接复制改：

colors: primary: "#2563EB" primary_hover: "#1D4ED8" success: "#16A34A" warning: "#D97706" danger: "#DC2626" bg_canvas: "#F8FAFC" bg_surface: "#FFFFFF" text_primary: "#0F172A" text_secondary: "#475569" border: "#E2E8F0" typography: font_family: ui-sans-serif, system-ui, sans-serif size_sm: 13px size_base: 14px size_lg: 16px size_xl: 20px size_2xl: 30px heading_weight: 600 spacing: base_unit: 8px space_xs: 4px space_sm: 8px space_md: 16px space_lg: 24px space_xl: 40px radius: radius_sm: 6px radius_base: 10px radius_lg: 16px shadow: shadow_sm: 0 1px 2px rgba(15, 23, 42, 0.06) shadow_md: 0 4px 12px rgba(15, 23, 42, 0.08) shadow_lg: 0 12px 32px rgba(15, 23, 42, 0.12)

这些值不是我随便拍的，参考了很多成熟设计系统的惯用数值。主色选了偏蓝的 #2563EB，是因为它在浅色背景下对比度好且容易搭配；基础字号用 14px，更适合数据密集的工具类界面；间距统一用 8 的倍数，能保证节奏感。

你完全可以根据项目调，但原则是必须有明确值，尽量控制在 10 个关键标记以内——规则一多，模型就会挑着执行，执行质量反而下降。

3.2 第二步：写 Skill 规则文件，包含负面清单

光有数值还不够，还要把行为规则写清楚。我建议把 Skill 文件拆成两个部分，一部分是可见规范，一部分是执行流程。

一个典型的 Skill 目录结构长这样：

ui-workplace/ SKILL.md standards/ visual_baseline.yaml layout_flow.md component_rules.md checklists/ ui-review.md

SKILL.md 是入口文件，作用是让 Agent 理解这个 Skill 的使用场景。里面写清楚：这个 Skill 适用于哪些情况，在开始任何界面工作前必须先阅读哪些文件，完成任务后必须用哪个自查清单。以下是一个简化但可行的范例：

# UI Work Standard Skill 当需要生成、修改前端界面时，必须使用本 Skill 的规范和流程。 步骤： 1. 阅读 standards/visual_baseline.yaml，使用其中的颜色、字号、间距、圆角等令牌。 2. 按 standards/layout_flow.md 的顺序进行布局推导。 3. 完成实现后，使用 checklists/ui-review.md 逐项自查。 负面清单（绝对禁止）： - 不要使用纯黑色文字（#000），正文采用 text_secondary 或 text_primary。 - 不要在同一屏中使用超过三种强调色。 - 不要堆叠超过三层嵌套卡片。 - 不要使用 emoji 作为状态图标。 - 不要在使用主按钮时同时使用多个渐变按钮。

负面清单是让 UI 产物脱胎换骨的关键。模型生成的界面丑，很多时候不是因为缺少“正向能力”，而是缺少“负面约束”。它不知道哪些做法在专业设计里是被视为不专业的，一旦你明确写出来，执行效果立竿见影。

3.3 第三步：把 taste 也变成可执行的规则

写到这里，很多朋友会问：就凭这些，UI 就会美吗？如果只是给一套 token 和几行禁令，产出可能确实不会太差，但也很难出彩。要让界面有质感，还需要给 Agent 注入一些 taste 层面的规则。这里的关键是“把品味换算成行为”，而不是谈论抽象的美感。

我常用的方法是在 layout_flow.md 里写清楚推导顺序，比如：

1. 想清楚页面的核心任务（用户进来要完成什么？） 2. 确定信息层级（最重要的内容/操作放在上方，次要信息置底）。 3. 选择布局骨架（左右分栏 / 单列流式 / 卡片网格），依据场景密度决定。 4. 组件选择遵循“最少而够用”原则，能用基础元素表达就不额外封装。 5. 细节收尾：按钮文字用动词 + 目标，如“保存配置”“新建项目”；空状态要给出下一步动作；异常反馈要有人话提示。

这些规则看着简单，但对 Agent 的影响非常大。你会发现，它在做界面时会先思考再动手，而不是一上来就写一个 500 行的庞大文件。给 Agent 装 Skill，本质上是改变它的工作动线，而不是只给它一个结果模板。

3.4 第四步：把 Skill 接进 Agent 工作流

配置好结构之后，就是接入的问题了。不同的 Agent 开发框架接入方式不同，但大致可以分为三层。

第一类是文件型接入，适用于 Claude Code、Codex CLI 这类以文件夹/仓库为工作区边界的工具。做法是把 Skill 目录放进项目根目录或 Agent 配置的 rules 目录，然后在全局指令里写一句“处理 UI 相关任务时必须加载 ui-workplace Skill”，Agent 就会在需要时读取对应文件。

第二类是平台型接入，适用于自己基于 OpenAI、Anthropic 等 API 搭建 Agent 的项目。做法是在系统提示中声明可用的 Skill 清单，然后把 Skill 文件内容作为检索增强的一部分，在用户任务命中 UI 场景时自动注入到上下文。这里有一个关键点，不要把所有 Skill 内容都塞进系统提示，只注入当前任务需要的部分，否则上下文会被稀释。

第三类是手动指令触发，适用于临时项目或不想改配置的场景。最简单的方式就是在任务开头加一句“参照 ui-workplace Skill 中的 UI 标准来实现”。我也建议在前期测试时先用手动触发，因为方便反复调试。

接入完成之后，你给 Agent 下一个“帮我做一个数据看板”的任务，它的工作方式会和之前截然不同。

4. 实测记录：装上 UI 工作标准后的产物变化

光说不练没什么说服力，我把自己的测试过程和结果整理出来，你可以直观看到差异。

4.1 改造前：典型的“默认审美”产物

我在同一套 Agent 框架里，用同样一个任务指令生成一个“项目进度管理面板”。安装 UI Skill 之前，Agent 的产物长这样：

• 背景是纯白，内容区居中的大卡片，宽度占满。
• 标题“项目进度管理”下方一行浅灰色说明文字，左右两端对齐。
• 四个统计卡片用四种颜色的 icon（蓝、绿、橙、红），配四个不同的浅色背景块。
• 进度条是 Bootstrap 风格，蓝色条纹式填充，任务列表的优先级用黄/红两种文字标签表示。
• 没有任何状态空态，也没有按钮悬停反馈，底部按钮和页边距不统一。

功能层面，该有的都有，细看也没有明显 bug，但整个页面给我的感觉就是“散”。视觉元素之间没有关联，色彩的选用没有逻辑，组件分布随意，典型的学生作业味。

4.2 改造后：规则约束下的产物

在安装 UI 工作标准后，同样一句话，产出变成了下面这个状态：

• 画布背景换成浅灰蓝 #F8FAFC，内容区域用白色表面卡片承载，层次立刻清晰。
• 统计卡片统一使用同一种卡片样式，只通过数据文字和辅助色做区别，视觉集中度明显提升。
• 进度条改成单色、圆角、线性填充，没有条纹和多余装饰。
• 优先级标签统一成同色系浅背景加深色文字，整体氛围更加克制。
• 空状态显示了“还没有任务，点击创建第一个项目”的引导按钮。
• 整个页面的间距明显是按 8 的倍数走的，看起来齐整舒服很多。

说实话，第一次看到输出的时候我是有点惊讶的，因为这些改变没有依赖更强大的模型，只是换了一种指导方式。可见给 Agent 一套 UI 工作标准，比自己反复修改提示词有效得多。

4.3 投入产出比：哪些规则最值得先写

回头看这次实测，真正起到作用的关键规则主要就几条：

1. 色板有限且统一，用 token 而不是随意取颜色。
2. 间距必须是 8 的倍数，不能凭感觉用奇数值。
3. 明确“卡片层级最多三层”和“不使用 emoji 表示状态”的负面清单。
4. 在输出前强制走一遍自查清单。

这几条规则的收益远高于其他细致规则。如果你时间有限，建议先写这几条，效果足够达到“明显改善”。后续再按项目需求逐步加细则，不要指望一次到位。

5. 常见问题与排查实录

配置 Skill 和真正用好 Skill 之间，还有一段距离。我在实际使用中踩过不少坑，总结如下，希望能帮你少走弯路。

5.1 Agent 无视 Skill 规则怎么办

这是被问得最多的问题。表现为明明写了规范，Agent 生成的界面还是我行我素。后来我发现问题不在规则内容，而在规则注入位置。如果规则只是放在项目 README 或者某个不起眼的地方，Agent 压根不会主动去翻。

解决办法是把这个小原则记牢：Skill 是一份手册，但首先得让 Agent“知道它存在”。在系统提示里显式声明、把 SKILL.md 放在项目根目录、在任务指令里引用，三种方式至少要做一种，否则规则等于不存在。另外，规则本身要用“必须”“禁止”这类强判断语言，少用“建议”“可以”，模型对强指令的遵循程度明显更高。

5.2 规则写得太抽象，模型执行效果差

还有一个常见问题是规则写得像散文，比如“界面要有现代感”“色彩搭配要舒服”。这类描述在人类读起来没问题，但模型没法把“现代感”转换成具体的视觉参数。Agent 在处理这种指令时，会退回默认审美，产出自然不够理想。

解决思路是强制自己把一切描述转写成可检验的指标。举个例子，与其写“界面要有现代感”，不如写“按钮使用 10px 圆角，卡片阴影用 shadow_md，背景使用 bg_canvas”。写规则的过程本身就相当于做一份设计 token 的整理。模型能执行得好，前提是你给它的指令足够确定。

5.3 UI 风格统一了，但总感觉缺少亮点

这是另一个极端：规则执行得很好，颜色也统一、间距也整齐，但页面看起来有点死板，缺少让人眼前一亮的细节。这个问题我也遇到过，后来发现是负面清单写得太满，把发挥空间压没了。

解决办法是在 Skill 里设置“亮点区间”，比如允许一个页面有一个视觉重点：可以是主色块的大面积使用、一个特殊字号的数字展示、或一个超出常规卡片的宽表格。规则约束整体一致性，再留一个明确的自由度给 Agent 做细节发挥，产出的质感会明显上一档。

5.4 一份快速排查速查表

遇到问题时，我建议先只调整一条规则再测一轮，不要一次改很多地方，否则根本没法定位是哪条规则生效。UI 工作标准是一个迭代活，健康的做法是每周小修一次，让它跟着项目走。

6. 我的几点真实感受

折腾这一圈下来，我自己最大的变化是看 Agent 产出的眼光变了：以前总觉得是模型不行，现在更多是自我反思——我给它的环境和工作标准够不够专业。事实上，很多“丑”，确实不是 Agent 的问题，而是我们既没有给它足够的规范，也没有告诉它什么是不该做的。

也想多说一句，Skill 不该是只有开发者能搞的东西。只要你经常用 Agent 写界面，花半天时间整理项目里最好看的一个页面，把它的颜色、字体、间距、组件风格抽出来，写成一个简单的标准文件，连上你的 Agent，效果立刻不一样。这种方式不依赖任何平台，纯文件配置就能跑通。

这轮实践给我的收获特别大，也希望这篇能帮你把 Agent 的 UI 水平往上拉一大截。如果你配好了 UI Skill，欢迎来交流你踩过的坑和总结出的好规则。