最近这段时间我一直在折腾 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.mdSKILL.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 投入产出比哪些规则最值得先写回头看这次实测真正起到作用的关键规则主要就几条色板有限且统一用 token 而不是随意取颜色。间距必须是 8 的倍数不能凭感觉用奇数值。明确“卡片层级最多三层”和“不使用 emoji 表示状态”的负面清单。在输出前强制走一遍自查清单。这几条规则的收益远高于其他细致规则。如果你时间有限建议先写这几条效果足够达到“明显改善”。后续再按项目需求逐步加细则不要指望一次到位。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 一份快速排查速查表现象可能原因解决动作Agent 完全不按规则来规则没被注入上下文在系统提示/任务指令中显式引用 Skill规则执行一半就不执行规则过长或优先级不清精简规则重点规则前置并用强语气界面统一但呆板负面限制过多缺少亮点策略在 Skill 中增加“亮点区间”内容同一 Skill 在不同项目表现差异大基线规范与项目场景不匹调整 color/spacing 数值适配项目组件像拼积木缺整体感没有建立组件层级规则在 Skill 中加入“组件选用与层级”约束响应式表现差规则里缺少断点与布局策略补充栅格的断点定义明确移动端优先还是桌面优先遇到问题时我建议先只调整一条规则再测一轮不要一次改很多地方否则根本没法定位是哪条规则生效。UI 工作标准是一个迭代活健康的做法是每周小修一次让它跟着项目走。6. 我的几点真实感受折腾这一圈下来我自己最大的变化是看 Agent 产出的眼光变了以前总觉得是模型不行现在更多是自我反思——我给它的环境和工作标准够不够专业。事实上很多“丑”确实不是 Agent 的问题而是我们既没有给它足够的规范也没有告诉它什么是不该做的。也想多说一句Skill 不该是只有开发者能搞的东西。只要你经常用 Agent 写界面花半天时间整理项目里最好看的一个页面把它的颜色、字体、间距、组件风格抽出来写成一个简单的标准文件连上你的 Agent效果立刻不一样。这种方式不依赖任何平台纯文件配置就能跑通。这轮实践给我的收获特别大也希望这篇能帮你把 Agent 的 UI 水平往上拉一大截。如果你配好了 UI Skill欢迎来交流你踩过的坑和总结出的好规则。